1 / 32

What’s different about IS project management?

What’s different about IS project management?. William R. Mussatto CyberStrategies, Inc. mussatto@csz.com. Topics. Software Intensive / People Intensive Projects Information Technology Projects. Software Intensive Projects. The Nature of Software Five Basic Steps of Project Planning

yamin
Download Presentation

What’s different about IS project management?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. What’s different about IS project management? William R. Mussatto CyberStrategies, Inc. mussatto@csz.com

  2. Topics • Software Intensive / People Intensive Projects • Information Technology Projects

  3. Software Intensive Projects • The Nature of Software • Five Basic Steps of Project Planning • where software projects begin to differ from other projects • Differences in Tracking and Control

  4. The Nature of Software • Always Something New • reuse, yes, but ... • Pure Mind Stuff • Extremely Malleable • Complexity and Functionality Gravitate to Software

  5. The Nature of Software • Doesn’t Wear Out • Defects Designed In • Defects Hard to Detect

  6. Five Basic Steps in Project Planning • Decomposing Project into Tasks • Defining Dependencies among Tasks • Estimating Resource Requirements for Each Task • Performing a Risk Analysis • Scheduling the Project Source: William H. Roetzheim, “Managing Software Projects: Unique Problems and Requirements”, from Paul Dinsmore, editor, The AMA Handbook of Project Management.

  7. Five Basic Steps in Project Planning Where Software Projects Differ • Traditional projects emphasize dependency definition and scheduling • evidence: commercial PM software • Software projects emphasize resource estimation and risk analysis

  8. Decomposing the Project into Tasks • Large Portion of Software Project Consists in Deciding What to Do • 30% • not true of traditional projects • Three Different Kinds of Decomposition Orientations • concept, capability, implementation

  9. Decomposing the Project into Tasks • Concept-Oriented • rough, generic outline of project requirements • ballpark estimates • accurate to within +/- 50% • Capability-Oriented • after functional requirements analysis • before top-level design • accurate within +/- 25%

  10. Decomposing the Project into Tasks • Implementation-Oriented • after software design is well advanced • post top-level design • fairly accurate • provided skill sets of programmers are well understood • Essential Incompleteness of Software Tasks • never know when they are really finished

  11. Decomposing the Project into Tasks • Actual Construction of Software Only 10-15% of Effort • Bulk of Work in Integration and Test • different from traditional projects • Scope of Software Tasks Varies with Interpretation • varying in cost and complexity by factor of 10 for same requirements

  12. Defining Dependencies Among Tasks • Software Tasks Often Exhibit “Partial-Finish-to-Start” Dependencies • Task A must be X % complete before starting Task B • for traditional projects, X=100 • for software projects, X ranges from 25 to 75 • Dependencies Not So Rigid

  13. Defining Dependencies Among Tasks • Dependencies Arise from People, Not Tasks • different skill sets • different work habits • have to allocate right persons to specific tasks

  14. Estimating Resource Requirements • Area of Major Difference with Traditional Projects • Software Project Costs Nonlinear • linear example: construction industry @ $50/foot • software costs linear as long as number of people involved remains fixed • jumps in nonlinear ways when more people are added

  15. Estimating Resource Requirements • Complexity • The Rule of 7 +/- 2 • Sheer Combinatorics of Relations • Bulk of Cost on Large Software Projects is Primarily Communications Costs

  16. Number of Interactions and Relationships

  17. Performing a Risk Analysis • Risk Analysis of Paramount Importance to Software Project Managers • Software Projects Always Creating Something New • Usually Pushing State of the Art in Some Area • especially true of embedded, real-time software • like R&D projects, this usually involves risk

  18. Performing a Risk Analysis • Successful Project Managers Consider Risk for Each Task in WBS • typically for risk avoidance • early prototyping • assigning top talent • contingency planning • Risk Measurement: Measure of Severity times Probability of Occurrence • subjective nature of probability

  19. Performing a Risk AnalysisFive Risk Considerations • Technical • software fails to realize intended functionality • Schedule • Cost • Network Risk • ripple effect on other tasks • Overall Risk

  20. Performing a Risk Analysis Software Project Managers Probably Need to Spend More Time on Risk Consideration than Traditional Project Managers

  21. Scheduling the Project • Later Developments Can Cause Previously Completed Tasks to Become Incomplete Once Again • later software module impacts design of previously completed modules • try to minimize

  22. Scheduling the Project • Close Coupling of Cost and Schedule • software projects are dependent on expensive labor • engineers do the construction work! • Workers are highly mobile. • Workers have different skill sets.

  23. Scheduling the Project • Some Estimates of Cost and Schedule Relationship for Software Projects • with schedule compression, costs increase as an inverse fourth power (according to some researchers • cutting schedule in half increases cost by factor of sixteen! • adding requirements while holding the schedule fixed amounts to the same effect

  24. Differences in Tracking and Control • Greater Technical Astuteness Required of Software Project Managers • must understand top-level aspects • Quality Control Very Important on Software Projects • Customer Expectations Must Be Carefully Managed • creeping featurism, aka requirements creep

  25. Software Engineering Institute • SEI CMM - Capability Maturity Model • Level 1: Initial • Level 2: Repeatable • Level 3: Defined • Level 4: Managed • Level 5: Optimizing

  26. Software Engineering Institute • Higher Levels Not Easy to Reach • expensive and time consuming • Most Organizations at Level 1 • Very Few at Level 5 • less than a dozen worldwide

  27. Software Intensive ProjectsSummary • Software Is Very Complex • Software Projects Are People Intensive • Resource Estimation and Risk Analysis Major Factors Software Projects • Functional Baselines Shift in Software Projects • SEI CMM Step in Right Direction

  28. IT Projects:Characteristics • Rapid Market Change • Rapid Technology Change • Distributed Systems • networked systems • many different organizations Source: Otto, Dhillon, Watkins, “Implementing Project Management in Large-Scale Information Technology Projects”, from Paul Dinsmore, editor, The AMA Handbook of Project Management.

  29. IT ProjectsHow IT Projects Differ • Fuzzy Scope Definition • interrelationship and interdependency of business functions • use of text to define scope • difficulties in defining end deliverables • frequent changes in business requirements during project life cycle

  30. IT ProjectsHow IT Projects Differ • Multiproject Environment Challenges • finite resource pool to draw from • specialized technical talent has to be shared across multiple projects • leads to more intensive conflict resolution • resource management needs to be done continuously to control costs

  31. IT ProjectsHow IT Projects Differ • Organizational Structures • Weak Matrix Structure • project managers often serve as functional managers • not really full-time project managers • potential conflict of interest • lack authority that counterparts in aerospace have • Some Benefits • faster reaction time • more control over direct subordinates

  32. IT ProjectsSummary • IT Projects Are Software Intensive • Software projects are people intensive • Subject to Rapid Technological Evolution • Constrained by Incompatible Organization Structures • in some cases

More Related