Whats different about IS project management - PowerPoint PPT Presentation


PPT – Whats different about IS project management PowerPoint presentation | free to download - id: a8261-OTI5Y


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Whats different about IS project management


Where Software Projects Differ. Traditional projects emphasize dependency ... Bulk of Cost on Large Software Projects is Primarily Communications Costs ... – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 33
Provided by: michaell80


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Whats different about IS project management

Whats different about IS project management?
  • William R. Mussatto
  • CyberStrategies, Inc.
  • mussatto_at_csz.com

  • 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
  • Doesnt 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
  • 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
  • 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
  • Bulk of Work in Integration and Test
  • different from traditional projects
  • Scope of Software Tasks Varies with
  • varying in cost and complexity by factor of 10
    for same requirements

Defining Dependencies Among Tasks
  • Software Tasks Often Exhibit Partial-Finish-to-St
    art Dependencies
  • Task A must be X complete before starting Task
  • for traditional projects, X100
  • 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
  • Software Project Costs Nonlinear
  • linear example construction industry _at_ 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 RD 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • not really full-time project managers
  • potential conflict of interest
  • lack authority that counterparts in aerospace
  • 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
  • in some cases
About PowerShow.com