Whats different about IS project management - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Whats different about IS project management

Description:

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
Category:

less

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

Title: Whats different about IS project management


1
Whats different about IS project management?
  • William R. Mussatto
  • CyberStrategies, Inc.
  • mussatto_at_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
  • Doesnt 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-St
    art Dependencies
  • Task A must be X complete before starting Task
    B
  • for traditional projects, X100
  • 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 _at_ 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 RD 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 Analysis Five 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 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

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 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

30
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

31
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

32
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
About PowerShow.com