What’s different about IS project management?

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