Document 7587998

Download Report

Transcript Document 7587998

What’s different about IS project management?

William R. Mussatto CyberStrategies, Inc.

[email protected]

Topics

 Software Intensive / People Intensive Projects  Information Technology Projects

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

The Nature of Software

 Always Something New  reuse, yes, but ...  Pure Mind Stuff  Extremely Malleable  Complexity and Functionality Gravitate to Software

The Nature of Software

 Doesn’t Wear Out  Defects Designed In  Defects Hard to Detect

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.

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

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

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%

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

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

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

Defining Dependencies Among Tasks

 Dependencies Arise from People, Not Tasks  different skill sets  different work habits  have to allocate right persons to specific tasks

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

Estimating Resource Requirements

 Complexity  The Rule of 7 +/- 2  Sheer Combinatorics of Relations  Bulk of Cost on Large Software Projects is Primarily Communications Costs

Number of Interactions and Relationships

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

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

Performing a Risk Analysis Five Risk Considerations

 Technical  software fails to realize intended functionality  Schedule  Cost  Network Risk  ripple effect on other tasks  Overall Risk

Performing a Risk Analysis

Software Project Managers Probably Need to Spend More Time on Risk Consideration than Traditional Project Managers

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

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.

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

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

Software Engineering Institute

 SEI CMM - Capability Maturity Model  Level 1: Initial  Level 2: Repeatable  Level 3: Defined  Level 4: Managed  Level 5: Optimizing

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

Software Intensive Projects Summary

 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

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.

IT Projects How 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

IT Projects How 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

IT Projects How 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

IT Projects Summary

 IT Projects Are Software Intensive  Software projects are people intensive  Subject to Rapid Technological Evolution  Constrained by Incompatible Organization Structures  in some cases