Managing Cost Overruns on projects - PowerPoint PPT Presentation

Loading...

PPT – Managing Cost Overruns on projects PowerPoint presentation | free to download - id: 20737d-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Managing Cost Overruns on projects

Description:

... and expectations expressing each stakeholders' interests (ISO 9001,etc.) WHAT IS A PROJECT ? ... is a failure as well or does not make it to the close-out ... – PowerPoint PPT presentation

Number of Views:766
Avg rating:3.0/5.0
Slides: 194
Provided by: raji6
Learn more at: http://www.apegga.org
Category:

less

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

Title: Managing Cost Overruns on projects


1
Managing Cost Overruns on projects
Managing Cost Overruns and Project Management
  • Rajiv Dua BSc.(Eng), PMP

2
Today's AGENDA
  • Introductions
  • Seminar Objective
  • Seminar Content
  • Introduction to Project Management
  • The Triple Constraint and the nine knowledge
    areas
  • The processes of project Management
  • Cost Overruns
  • Some methods of overcoming Cost Overruns

3
Seminar Objective
  • To provide a basic understanding of the
    fundamental project management principles as per
    the Project Management Institute (PMI) with
    particular reference to the Triple Constraint.
    With this knowledge attempt to discuss Cost
    Overruns in projects and discuss some methods to
    overcome these opportunities.

4
Cost Overrun definition
  • Cost Overruns are the additional percentage or
    dollar amount by which actual costs exceed
    estimates

5
Questions?
  • What kind of Cost Overruns do some of you think
    you have in your respective organizations?
  • Why do you think this is or has happened?

6
What is a Project?
  • A project is a temporary endeavor undertaken to
    create a unique product or service or result

7
Project Attributes
  • A project has a unique purpose.
  • Every project should have a well-defined
    objective.
  • A project is temporary.
  • A project has a definite beginning and a definite
    end.
  • A project requires resources.
  • Resources include people, hardware, software, or
    other assets.

8
Project Attributes
  • A project should have a primary sponsor or
    customer.
  • A project involves uncertainty

9
Project Manager
  • A Project Manager is the key to a projects
    success.
  • Project Managers work with the Project Sponsors,
    Project team and other stakeholders involved in a
    project to ensure successful completion of the
    project.

10
Definitions
  • Project Manager
  • Project Sponsor
  • Project Team Members
  • Functional Line Managers
  • Stakeholders Internal and External
  • Steering Committee

11
Project Characteristics
  • Four Key Characteristics
  • It is an answer to a business opportunity or
    problem
  • It has a specific objective...
  • It must be approved to proceed
  • It consumes resources...
  • It is confined by definable boundaries
  • It has defined scope, budget, schedule...
  • It goes through distinct stages
  • It has a beginning, a middle and an end...

12
Triggers of a project
  • Projects can be created to answer to a business
    opportunity or problem
  • It has a specific, usually time-sensitive
    objective...
  • A project objective can be internally or
    externally triggered
  • Internal triggers e.g. a condition impacting the
    operation of an organization
  • high costs
  • poor quality
  • new products or services
  • Efficiency of employees
  • External triggers e.g. a condition imposed on the
    organization
  • regulations, codes
  • competing products
  • external decisions

13
WHAT IS A PROJECT ?
  • It is confined by definable boundaries
  • It has defined scope, budget, schedule...
  • Boundaries defining a project include
  • Scope What IS and IS NOT included as part of the
    project
  • Budget How much can be expended for direct and
    indirect costs
  • Schedule Start and end dates for each
    deliverable
  • Quality Qualitative terms, conditions and
    expectations expressing each stakeholders
    interests (ISO 9001,etc.)

14
WHAT IS A PROJECT ?
  • It goes through distinct stages
  • It has a beginning, a middle and an end...
  • From a project management perspective there are
    three main stages
  • Initiation
  • Execution
  • Wrap-up

15
PROJECTS vs. OPERATIONS
  • Projects differ from ongoing operations in the
    following ways
  • projects start and end
  • projects are focused on one objective
  • projects have short term strategies
  • projects end!!
  • ongoing operations are focused on continuing
    support of an organization
  • ongoing operations have long term strategies
  • ongoing operations focus on multiple objectives
  • ongoing operations dont (normally) end!!

16
Project Constraints
  • Every project is constrained in different ways by
    its scope, time goals, and cost goals.
  • Scope What is the project trying to accomplish?
  • Time How long should it take to complete the
    project?
  • Cost What should it cost to complete the
    project?
  • These limitations are referred to as the Triple
    Constraint of project management.
  • Managing the triple constraint means making
    trade-offs between project scope, time and cost
    goals for a project.

17
Project Constraints
18
Operations and Projects
  • Operations are existing systems and functions
    whereas Projects are one-time multi-disciplinary
    resource configuration.
  • Operations focus on Maintaining, whereas
    Projects focus on Change.

19
What is Project Management?
  • Project Management is the application of
    knowledge, skills, tools and techniques to
    project activities in order to meet or exceed
    stakeholder needs and expectations from a
    project.

20
Project Management Framework
T
Stakeholders The people involved in or affected
by the projects activities. These include the the
project sponsor, project team, support staff,
customers, users, suppliers and even opponents to
the project.
21
Project Management Framework
T
Knowledge Areas the NINE key competencies that
project managers must develop.
22
Project Management Framework
T
Scope Management involves defining and managing
all the work required to successfully complete
the project.
23
Project Management Framework
T
Time Management includes estimating how long it
will take to complete the work, developing an
acceptable project schedule, and ensuring timely
completion of the project.
24
Project Management Framework
T
Cost Management consists of preparing and
managing the budget for the project.
25
Project Management Framework
T
Quality Management ensures the project will
satisfy the stated or implied needs for which it
was undertaken.
26
Project Management Framework
T
HR Management concerned with making effective
use of the people involved with the project.
27
Project Management Framework
T
Comm. Management involves generating,
collecting, disseminating and storing project
information.
28
Project Management Framework
T
Risk Management includes identifying, analyzing
and responding to risks related to the project.
29
Project Management Framework
T
Procure. Management involves acquiring or
procuring goods and services that are needed for
a project from outside the performing
organization.
30
Project Management Framework
T
Project Mgmt. Integration is an over-arching
function that affects and is affected by all of
the other knowledge areas. (This is where it is
all brought together.)
31
Project Management Framework
T
Tool and Techniques these assist the project
managers and their teams in carrying out the
management functions of the 9 Knowledge Areas.
Examples of these include WBS Diagrams and Gantt
Charts.
32
A Systems View of Project Management
  • Many IT professionals are to busy with their
    day-to-day activities and often become frustrated
    by an organizations politics and red tape and
    they often ignore key business issues.
  • Using a holistic (systems management) approach,
    helps them integrate business and organizational
    issues into their project planning, and helps
    them look at projects as a series of phases.
  • This ensures that project managers do a better
    job of planning and developing the project, which
    leads to increased project success.

33
Project Phases and theProject Life Cycle
  • A project life cycle is a collection of project
    phases.
  • Project phases vary by project or industry, but
    some general phases include
  • Concept
  • Development
  • Implementation
  • Close-Out
  • The first two phases focus on planning and are
    often referred to as project feasibility.
  • The last two phases focus on deliverables and are
    often referred to as project acquisition.

34
Project Phases and theProject Life Cycle
  • Concept Phase
  • A high-level or summary project plan is developed
    to briefly describe the project and why it is
    needed.
  • A rough cost estimate is developed.
  • A rough overview of the work involved is
    developed in a work breakdown structure format.
  • Work Breakdown Structure (WBS) an outcome
    oriented document that defines the total scope of
    the project.
  • At the concept level the WBS document breaks the
    work tasks out to no more than three levels (3
    level WBS).

35
Project Phases and theProject Life Cycle
  • Development Phase
  • A more detailed project plan is developed.
  • A more accurate cost estimate is developed.
  • A more thorough WBS is developed.
  • Implementation Phase
  • Project team delivers the required work.
  • A very accurate cost (or final cost) estimate is
    developed.
  • This phase is where the bulk of the projects time
    and money should be spent.

36
Project Phases and theProject Life Cycle
  • Close-out Phase
  • All of the work is completed and all project
    activities are wrapped up.
  • There should be a formal customer acceptance of
    the entire project and the products it produced.
  • A lessons learned document is created for
    reference in similar future projects. (This
    should be done if the project is a failure as
    well or does not make it to the close-out phase.)
  • This phased approach minimizes the time and money
    spent developing inappropriate projects. A
    project must pass the concept phase before
    continuing into the development phase and so on.

37
Project Phases and theProject Life Cycle
38
Organizational Frames
  • Project managers often do not spend enough time
    understanding the political context of a project
    in an organization.
  • To improve the success rate of IT projects,
    project managers must develop a better
    understanding of people and organizations.
  • Organizations can be viewed as having four
    different frames
  • Structural Frame Organizational chart
  • Human Resources Frame shortage of IT and
    Unrealistic schedules
  • Political Frame Conflict and Power struggles
    for resources
  • Symbolic Frame - Organizational Culture

39
Organizational Structures
  • Most organizations focus on the structural frame.
  • Most people know what an organizational chart is
    and can follow them.
  • New managers typically try to change the
    organizational structure when other changes are
    needed, and to carve out their piece of the pie.
  • There are three general classifications of
    organization structures
  • Functional
  • Project
  • Matrix

40
Organizational Structures
41
Project Managers Influence
Project Characteristics Organization Type Organization Type Organization Type Organization Type Organization Type
Project Characteristics Functional Matrix Matrix Matrix Project
Project Characteristics Functional Weak Balanced Strong Project
Project managers authority little or none limited low to moderate moderate to high high to almost total
Percentage of performing organizations personnel assigned full-time to project work virtually none 0-25 15-60 50-95 85-100
Project managers role Part-time Part-time Full-time Full-time Full-time
Common title for project managers role Project Coordinator/ Project Leader Project Coordinator/Project Leader Project Manager/ Project Officer Project Manager/ Program Manager Project Manager/ Program Manager
Project management administrative staff Part-time Part-time Part-time Full-time Full-time
42
Top Management Is The Key
  • Top management commitment is crucial to the
    projects success for the following reasons
  • Project managers need adequate resources.
  • Project managers often require approval for
    unique project needs in a timely manner.
  • Murphys Law is understood which relates to
    Management Reserves
  • Project managers require cooperation from
    stakeholders in other parts of the organization.

43
Top Management Is The Key
  • Project managers must have cooperation from
    people in other parts of the organization.
  • Project managers often need someone to coach and
    mentor them on the finer points of leadership.

44
Project Management Process Groups
  • Project management can be viewed as a number of
    interlinked processes.
  • A process is a series of actions directed toward
    a particular result.
  • The five project management process groups are
  • Initiating processes
  • Planning processes
  • Executing processes
  • Controlling processes
  • Closing processes

45
Process Groups
46
Project Management Process Groups
  • Initiating processes
  • These processes are used to initiate every phase
    of the project life cycle including the close-out
    phase.
  • In the concept phase it is used to define the
    business need for the project, the project
    sponsor, and the project manager.
  • To end a project the initiating processes are
    used to ensure that all work is completed, the
    customers acceptance of the work, the lessons
    learned document is created and that resources
    are reassigned.

47
Project Management Process Groups
  • Planning Processes
  • Used to devise and maintain a workable scheme to
    accomplish the business need that the project was
    to address.
  • Project plans are created to define each
    knowledge area as it relates to the project at
    that point in time. (As the project travels
    through its life cycle.)
  • The processes are also used to account for
    changing conditions on a project and in an
    organization, project plans are often revised
    during each phase of the project life cycle.

48
Project Management Process Groups
  • Executing processes
  • These process are used to ensure the coordination
    of people and other resources follow the project
    plan and produce the deliverables of either the
    project or the phase that the project is
    currently in.
  • Executing processes include
  • developing the project team
  • providing leadership
  • verifying project scope
  • assuring product quality
  • disseminating information
  • procuring resources and delivering the work.

49
Project Management Process Groups
  • Controlling processes
  • These processes are used to ensure that the
    project objectives are met.
  • Projects must be continually monitored and their
    progress measured against the project plan to
    ensure corrective actions are taken when
    necessary.
  • Controlling processes include performance and
    status reviews.
  • Controlling processes are also used to follow
    project changes and ensure that the changes are
    identified, analyzed and managed in accordance
    with the project plan.

50
Project Management Process Groups
  • Closing processes
  • These processes are used to formalize the
    acceptance of the project or phase and bring it
    to an orderly end.
  • This often involves archiving project files,
    documenting lessons learned and receiving formal
    acceptance of work delivered.
  • These phases are not discrete, one-time events,
    but occur at varying levels throughout every
    phase of the projects life cycle, and even vary
    in activities and time for each separate project.

51
Project Management Process Groups (PMBOK 2000)
52
Relationships Among Process Groups and
Knowledge Areas PMBOK 2004
PMBOK Guide 2004, p. 69
53
Relationships Among Process Groups and Knowledge
Areas (contd)
54
Project Integration Management
  • Project Integration Management - the processes
    involved in coordinating all of the other project
    management knowledge areas throughout a projects
    life cycle.
  • The main process involved in project integration
    management include
  • Project Plan Development
  • Project Plan Execution
  • Integrated Change Control

55
Project Integration Management
  • This diagram shows how project integration
    management pulls together and focuses the
    knowledge areas throughout the projects life
    cycle and guides these elements toward successful
    completion.

56
Project Integration Management
  • Project integration management must occur within
    the context of the whole organization, not just
    within a particular project but on-going
    operations
  • Project managers must always view their projects
    in the context of the changing needs of their
    organizations and respond to requests from senior
    managers.
  • Project integration management involves
    integrating knowledge areas within the project
  • Integrating different areas outside the project.

57
Project Charters
  • After deciding what project to work on, it is
    important to let the rest of the organization
    know.
  • A project charter is a document that formally
    recognizes the existence of a project and
    provides direction on the projects objectives
    and management.
  • Key project stakeholders should sign a project
    charter to acknowledge agreement on the need and
    intent of the project a signed charter is a key
    output of project integration management.

58
(No Transcript)
59
(No Transcript)
60
Sample Project Charter
61
Sample Project Charter (contd)
62
Scope planning
  • Involves creating documents that detail the basis
    for future project decisions, including the
    criteria for determining if a project or a phase
    is completed successfully
  • Output of the scope planning process
  • Scope statement
  • Scope statements supporting detail
  • Scope management plan

63
PreliminaryScope Statements (PMBOK 2004)
  • A scope statement is a document used to develop
    and confirm a common understanding of the project
    scope.
  • It is an important tool for preventing scope
    creep
  • The tendency for project scope to keep getting
    bigger.
  • A good practice is to develop a preliminary or
    initial scope statement during project initiation
    and a more detailed scope statement as the
    project progresses.

64
Contents of a Preliminary Scope Statement (2004)
  • Project objectives
  • Product or service requirements and
    characteristics
  • Project boundaries
  • Deliverables
  • Product acceptance criteria
  • Project assumptions and constraints
  • Organizational structure for the project
  • Initial list of defined risks
  • Summary of schedule milestones
  • Rough order of magnitude cost estimate
  • Configuration management requirements
  • Description of approval requirements

65
Further Defining Project Scope
66
Project Management Plans
  • A project management plan is a document used to
    coordinate all project planning documents and
    help guide a projects execution and control.
  • Plans created in the other knowledge areas are
    subsidiary parts of the overall project
    management plan.

67
Attributes of Project Plans
  • Just as projects are unique, so are project
    plans.
  • Plans should be
  • Dynamic
  • Flexible
  • Updated as changes occur
  • Plans should first and foremost guide project
    execution by helping the project manager lead the
    project team and assess project status.

68
Project Execution
  • Project execution involves managing and
    performing the work described in the project
    management plan.
  • The majority of time and money is usually spent
    on execution.

69
What Went Wrong?
  • Many people have a poor view of plans based on
    their experiences. Top managers often require a
    project management plan, but then no one follows
    up on whether the plan was followed. For example,
    one project manager said he would meet with each
    project team leader within two months to review
    their project plans. The project manager created
    a detailed schedule for these reviews. He
    cancelled the first meeting due to another
    business commitment. He rescheduled the next
    meeting for unexplained personal reasons. Two
    months later, the project manager had still not
    met with over half of the project team leaders.
    Why should project members feel obligated to
    follow their own plans when the project manager
    obviously did not follow his?
  • Could this cause cost overruns?

70
Integrated change control process
71
Change Control on Information Technology Projects
  • Former view The project team should strive to do
    exactly what was planned on time and within
    budget.
  • Problem Stakeholders rarely agreed beforehand on
    the project scope, and time and cost estimates
    were inaccurate.
  • Modern view Project management is a process of
    constant communication and negotiation.
  • Solution Changes are often beneficial, and the
    project team should plan for them.

72
Change Control Boards (CCBs)
  • A formal group of people responsible for
    approving or rejecting changes on a project.
  • CCBs provide guidelines for preparing change
    requests, evaluate change requests, and manage
    the implementation of approved changes.
  • CCBs include stakeholders from the entire
    organization.

73
Making Timely Changes
  • Some CCBs only meet occasionally, so it may take
    too long for changes to occur.
  • Some organizations have policies in place for
    time-sensitive changes.
  • A 48-hour policy allows project team members to
    make a decision and have 48 hours to seek
    approval from top management. If the team
    decision cannot be implemented, management has 48
    hours to reverse a decision otherwise, the
    teams decision is approved.
  • Another policy is to delegate changes to the
    lowest level possible, but keep everyone informed
    of changes.

74
What is Project Scope Management?
  • Scope refers to all the work involved in creating
    the products of the project and the processes
    used to create them.
  • A deliverable is a product produced as part of a
    project, such as hardware or software, planning
    documents, or meeting minutes.
  • Whats in and whats out

75
Creating the Work Breakdown Structure (WBS)
  • A WBS is a deliverable-oriented grouping of the
    work involved in a project that defines the total
    scope of the project.
  • A WBS is a foundation document that provides the
    basis for planning and managing project
    schedules, costs, resources, and changes.
  • Decomposition is subdividing project deliverables
    into smaller pieces.

76
Sample Intranet WBSOrganized by Phase
77
Intranet WBS in Tabular Form
1.0 Concept 1.1 Evaluate current systems 1.2
Define requirements 1.2.1 Define user
requirements 1.2.2 Define content
requirements 1.2.3 Define system
requirements 1.2.4 Define server owner
requirements 1.3 Define specific
functionality 1.4 Define risks and risk
management approach 1.5 Develop project
plan 1.6 Brief Web development team 2.0 Web Site
Design 3.0 Web Site Development 4.0 Roll Out 5.0
Support
78
Figure 5-4. Intranet Gantt Chart Organized by
Project Management Process Groups
79
Approaches to Developing WBSs
  • Guidelines Some organizations, such as the DOD,
    provide guidelines for preparing WBSs.
  • Analogy approach Review WBSs of similar projects
    and tailor to your project.
  • Top-down approach Start with the largest items
    of the project and break them down.
  • Bottom-up approach Start with the specific tasks
    and roll them up.
  • Mind-mapping approach Write tasks in a
    non-linear, branching format and then create the
    WBS structure.

80
Sample Mind-Mapping Approach
81
Resulting WBS in Chart Form
82
Scope Verification and Change Control
  • Many IT projects suffer from scope creep caused
    by scope changes. As a result it is very
    important to verify the project scope and
    minimize scope changes.
  • Scope Creep The tendency for a projects scope
    to keep getting bigger and bigger, thereby
    dragging out the completion date of the project.
  • To minimize or prevent scope creep, the projects
    scope should go through a scope verification
    process.

83
Scope Verification
  • Scope Verification This involves formal
    acceptance of projects scope by the
    stakeholders.
  • To receive this acceptance the project team
    members must develop clear documentation of the
    projects products and procedures for evaluating
    those products.

84
Scope Verification Scope Change Control
  • Inevitably there will still be changes made to
    the projects scope which will have to be managed
    through a scope change control process.
  • Scope Change Control involves controlling
    changes to the project scope.
  • To minimize scope change control, it is crucial
    to do a good job during scope verification.
    However, as a project manager you should still
    expect and prepare for requested changes that
    come from the customer.
  • The following table shows the Top 10 factors that
    cause problems for IT projects.

85
Scope Verification cause for Cost Overruns
Factor Rank
Lack of user input 1
Incomplete requirements and specifications 2
Changing requirements and specifications 3
Lack of executive support 4
Technology incompetence 5
Lack of resources 6
Unrealistic expectations 7
Unclear objectives 8
Unrealistic time frames 9
New technology 10
86
Project Management
  • Project Time Management

87
The importance ofproject time management
  • Many projects can be determined failures in terms
    of meeting scope, time and cost projections.
  • In one study the average time for unsuccessful
    overruns of IT projects ran at 222. A follow up
    study showed that this overrun period had been
    reduced to nearly 65.
  • Most project managers state that scheduling
    issues are the main reasons for conflicts during
    a projects life cycle.

88
Importance of Project Schedules
  • Managers often cite delivering projects on time
    as one of their biggest challenges.
  • Fifty percent of IT projects were challenged in
    the 2003 CHAOS study, and their average time
    overrun increased to 82 percent from a low of 63
    percent in 2000.
  • Schedule issues are the main reason for conflicts
    on projects, especially during the second half of
    projects.
  • Time has the least amount of flexibility it
    passes no matter what happens on a project.
  • The Standish Group, Latest Standish Group
    CHAOS Report Shows Project Success Rates Have
    Improved by 50, (www.standishgroup.com) (March
    25, 2003).

89
Conflict Intensity Over the Life of a Project
90
Project Time Management
  • One of the reasons that schedule problems are so
    frequent is due to the time it takes to perform
    respected tasks that are underestimated.
  • Once the project schedule is in place schedule
    performance can be calculated by subtracting the
    estimated time for completing a task, from the
    actual time it really took to complete.
  • However, one of the things to keep in mind when
    doing this, is to include the approved changes or
    (changes to the baseline) to the calculation.
    This usually reduces the gap between the
    estimated and the actual times.

91
Project Time Management
  • Project Time Management The process required to
    ensure timely completion of a project
  • For project managers, time is the least
    forgiving, and least flexible variable in the
    project.
  • Time cannot be stopped, no matter what changes
    have been requested, what resource conflicts are
    occurring, or what problems have been
    encountered.
  • As a result, project time management is
  • Considered one of the most difficult tasks to
    both improve and successfully achieve.
  • Considered critically important in determining
    the overall success of a project.

92
Project Time ManagementThe Basic Processes
  • The main processes involved in project time
    management include
  • Activity definition.
  • This involves identifying the specific activities
    that the project team members and stakeholders
    must perform to produce the project deliverables.
  • In some projects identifying all of the tasks is
    a feat unto itself. Therefore it is very
    important to ensure that as many as possible are
    identified, because those that are missed will
    ultimately throw the project of schedule.

93
Project Time ManagementThe Basic Processes
  • Activity sequencing.
  • This involves identifying and documenting the
    relationships between project activities.
  • It is important to know which tasks can be
    performed at the same time and which ones are
    dependant on a previous task being completed
    first.
  • Activity duration estimating.
  • This involves estimating the number of work
    periods that are needed to complete individual
    activities. (Remember an unwritten rule is a work
    package can represent about 80 hours of work.)
    remember this comes from the WBS.
  • Here the project manager must work closely with
    his team leaders to take a best guess at how long
    it will take to complete a task. They must be
    careful not to estimate to much or to little.

94
Project Time ManagementThe Basic Processes
  • Schedule development.
  • This involves analyzing the activity sequences,
    activity duration estimates, and resource
    requirements to create the project schedule.
  • Here the activity sequences and activity duration
    estimates are double checked and matched to
    available resources. Once it is verified the
    projects schedule is committed to documentation
    for sign-off. (At this point the project schedule
    is almost law.)
  • Schedule control.
  • This involves controlling and managing the
    changes to the projects schedule.
  • This is where the law gets broken, and most often
    this is where the proverbial back of the project
    gets broken.

95
Project Time ManagementThe Tools and Techniques
  • The completion date that the project manager and
    team members come up with may not reflect the
    completion date in the project charter.
  • If this is the case the project manager must go
    back to the project sponsor or customer and
    renegotiate changes to the triple constraint.

96
Activity Sequencing
  • There are three basic reasons for creating
    dependencies, often called the types of
    dependencies, among project activities. They are
  • Mandatory dependencies.
  • Discretionary dependencies
  • External dependencies

97
PDM Network Diagram
98
Gantt Chart for Software Launch Project
99
Sample Tracking Gantt Chart
100
The Importance Of Network Diagrams
  • The construction of a network diagram is
    fundamental to determining the overall project
    completion date.
  • Gantt charts display planned and project
    schedule information but dont display
    relationships between tasks and dependencies.
  • A network diagram displays dependencies and is
    required to perform critical path analysis.

101
Importance of Critical Path
  • Critical Path Method predicts total project
    duration and allows project managers to make
    trade-offs where necessary.
  • If the project manager knows that one of the
    projects tasks is behind schedule then they can
    decide what to do about it. For example
  • Should they try to renegotiate the schedule?
  • Should they allocate more resources to make for
    lost time?

102
Slack
  • One of the techniques that allow project managers
    to make these trade-offs is by determining the
    free slack and total slack for the project.
  • Free slack is the amount of time an activity can
    be delayed without delaying the early start of
    any immediately following activity.
  • Total slack is the amount of time an activity may
    be delayed from its early start without delaying
    the planned finish date.

103
Critical Path Method (CPM)
  • Critical path method is a tool which will help
    combat schedule overruns.
  • What does the critical path really mean?
  • The critical path is the earliest time by which a
    project can be completed.
  • It is the longest path through a project network
    diagram, and has the least amount of slack or
    float.

104
Performing Critical Path Analysis
Critical Path Approach
Build A
Dur 15
Analysis
Design
Build B
Implement
Dur 10
Dur 25
Dur 20
Dur 15
Build C
Dur 30
Critical Path 10 25 30 15 70
days Clearly, Design is on the Critical path
since future activities Cannot proceed unless the
design is completed The Critical path is the
longest path through the project and also when
the schedule is least flexible
105
Time Management Scenario
  • Create a wireless Triple Play system i.e.. One
    that can handle VOIP, Data and Broadband (Video)
    services. Your company has 1000 employees all of
    whom have computers with Intranet access
    requiring Triple Play services
  • The executive team has given you a budget of
    100,000 and completion date of 6 months.
  • Dates are from January 1st 2006 June 30th 2006
  • Time management process to follow.

106
Time Management Assignment
  • During the planning phase you will
  • Brainstorm a high level Activity/WBS list of 20
    high level activities/WBS (Work Packages) and
    display them on the wall.
  • Create a form of Activity Sequencing relationship
  • Estimate your Activity Durations
  • Evaluate and show your Critical Path
  • Hire a Project Manager
  • Delegate activities/Tasks
  • To show the above create a Network diagram (PDM)
    Create your own Assumptions and Constraints
  • Use 8.5x11 sheets for activities
  • Put outputs on the wall

107
Shortening Project Schedules
  • It is common for stakeholders (mainly the project
    sponsor and/or customer) to want the projected
    schedule shortened.
  • There are several techniques which the project
    manager can use to perform this task once the
    projects critical path has been determined
    including
  • The critical path duration can be shortened by
    allocating more resources to the tasks or by
    changing the projects scope.

108
Shortening Project Schedules
  • Crashing (Expert or Full Time) is another
    technique used, and it involves making cost and
    schedule trade-offs to obtain the greatest amount
    of schedule compression at the least incremental
    cost.
  • For example a task that was supposed to take two
    weeks by a part-time resource could be performed
    in a week by a full-time resource. This would
    shorten the project schedule by a week at no
    extra cost.
  • If a full-time resource was unavailable to
    perform this task then a temporary resource could
    be hired to perform the job in one week.
  • The schedule would be shortened by one week and
    the cost hiring a temp resource should only
    increase the project costs slightly.
  • The main advantage of crashing is that the
    projects schedule is shortened, however the
    disadvantage is that it often raises the overall
    project costs.

109
Shortening Project Schedules
  • Fast Tracking Parallel is another technique
    used to shorten a project schedule, and involves
    performing project tasks in parallel.
  • Most project tasks are setup to be performed in
    sequence or with a slightly overlapping time
    frame.
  • With this technique it is important to be aware
    of how the tasks in the schedule affect one
    another, and to be able to determine which tasks
    can be fast tracked due to a low risk of
    potential problems further down the schedule.
  • The main advantage of fast tracking is a
    shortened project schedule. The main disadvantage
    is that unforeseen problems with performing some
    tasks to soon can greatly lengthen a project
    schedule. (E.g.. Overlapping or being to anxious)

110
Assignment
  • From your WBS/Activity list in PDM format the
    Sponsor has asked you because of financial
    constraints to bring back the date of your
    current end date by 2 weeks thus saving the
    company resource costs.
  • Is this possible?
  • Alter your PDM to reflect this.

111
Critical Chain Schedules
  • Critical chain scheduling is a fairly complicated
    yet powerful tool that involves critical path
    analysis, resource constraints, and using buffers
    to make changes in tasks estimates.
  • Example of resource constraints
  • One person assigned to two tasks which are to be
    completed at the same time by the same person,
    critical chain scheduling (and common sense)
    acknowledges that one of these tasks needs to be
    delayed or another resource needs to be brought
    in to do it.

112
Multitasking Example
113
Critical Chain Schedules- Buffers
  • Project Buffers This is additional time added to
    the entire project before the projects due date.
  • In most cases individual tasks have additional
    time added to them to ensure adequate time to
    completion.
  • In critical chain scheduling this additional time
    is removed from the tasks themselves and added to
    the project time overall.
  • Also, the critical path is padded with feeding
    buffers to prevent delay as well.
  • Feeding buffers are addition time added to
    critical path tasks that are preceded by
    non-critical-path tasks.

114
Critical Chain Schedules Parkinson's Law
  • Typically task estimates in critical chain
    scheduling are shorter than with traditional
    scheduling techniques because individual tasks do
    not contain their own buffers.
  • This means less occurrence of Parkinsons Law.
  • Parkinsons Law states that work(task) expands to
    fill the time allowed to perform the task.
  • The feeding buffers and project buffers protect
    the date that really needs to be met by the
    project completion date.

115
Example of Critical Chain Scheduling
116
Program Evaluation and Review Technique (PERT)
  • A technique used to estimate project duration
    when there is a high degree of uncertainty about
    individual activity duration estimates.
  • PERT uses probabilistic time estimates, which are
    duration estimates using optimistic, most likely,
    and pessimistic task duration estimates instead
    of specific or defined estimates

117
PERT Analysis
  • The PERT analysis method is based on a project
    network diagram, normally the PDM method, and a
    weighted average for each project task is
    calculated using the following formula

optimistic time (4 x most likely time)
pessimistic time

PERT weighted average
6
  • PERT applies the critical path method to a
    weighted average duration estimate.
  • It involves more work because it requires
    several duration estimates.

118
PERT Formula and Example
  • PERT weighted average
  • optimistic time 4X most likely time
    pessimistic time
  • 6
  • Example
  • PERT weighted average
  • 8 workdays 4 X 10 workdays 24 workdays 12
    days 6
  • where
  • optimistic time 8 days
  • most likely time 10 days
  • pessimistic time 24 days
  • Therefore, youd use 12 days on the network
    diagram instead of 10 when using PERT for the
    above example.

119
Controlling changes to the project schedule
  • Reality checks on scheduling Review the draft
    schedule, progress meetings with stakeholders.
  • Working with people issues
  • Empowerment To give someone authority or even
    accountability
  • Incentives
  • Discipline
  • Negotiation

120
The Importance of Project Cost Management
  • IT projects have a poor track record for meeting
    budget goals.
  • The 2003 CHAOS studies showed the average cost
    overrun (the additional percentage or dollar
    amount by which actual costs exceed estimates)
    was 43 percent.
  • U.S. lost 55 billion in IT projects in 2002 from
    cancelled projects and overruns compared to 140
    billion in 1994.
  • The Standish Group, Latest Standish Group
    CHAOS Report Shows Project Success Rates Have
    Improved by 50, A Standish Group Research Note
    (3/25/03).

121
What Went Wrong?
According to the San Francisco Chronicles
front-page story, Computer Bumbling Costs the
State 1 Billion, the state of California had a
series of expensive IT project failures in the
late 1990s, costing taxpayers nearly 1
billionIt was ironic that the state that was
leading in the creation of computers was also the
state most behind in using computer technology to
improve its services. The Internal Revenue
Service (IRS) managed a series of project
failures that cost taxpayers over 50 billion a
yearroughly as much money as the annual net
profit of the entire computer industry. Connect
icut General Life Insurance Co. sued PeopleSoft
over an aborted installation of a finance
system. Lucas, Greg, Computer Bumbling
Costs the State 1 Billion, San Francisco
Chronicle (2/21/99). James, Geoffrey, IT
Fiascoes . . . and How to Avoid Them, Datamation
(November 1997). Songini, Marc L., PeopleSoft
project ends in court, ComputerWorld (September
2001).
122
Cost of Software Defects
It is important to spend money up-front on IT
projects to avoid spending a lot more later.
Collard, Ross, Software Testing and Quality
Assurance, working paper (1997).
123
Cost Management Principles
  • Profits
  • Life cycle costing
  • Cash flow analysis
  • Tangible and intangible cost/benefits
  • Direct and indirect costs
  • Sunk costs
  • Learning curve theory
  • Reserves
  • Earned value analysis

124
Types of Cost Estimates
125
Cost Estimation Tools and Techniques
  • Basic tools and techniques for cost estimates
  • Analogous or top-down estimates.
  • Bottom-up estimates
  • Parametric modeling

126
PROJECT PLANNING ESTIMATING
PROJECT MANAGEMENT
127
Surveyor Pro Project Cost Estimate
128
Surveyor Pro Software Development Estimate
129
PROJECT PLANNING ESTIMATING
  • Guidelines
  • Where possible, use multiple techniques for
    verification
  • Analogous estimating top down estimating (using
    actual costs of similar projects)
  • Parametric modeling using project
    characteristics in a mathematical model
    projecting costs (10/sqft)
  • Bottom up
  • Computerized tools
  • Procurement estimating Vendor bids
  • Use a systematic approach
  • Use multiple estimators
  • Document assumptions and techniques used

130
PROJECT ESTIMATING GUIDELINE
  • Guidelines for estimation effort
  • Opportunity evaluation and project initiation
    represent 5-10 of project effort
  • Analysis and design represent 50 - 60 of the
    total effort
  • Construction represents 30 - 40 of the total
    effort
  • Implementation and evaluation represent 5 - 15
    of the total effort
  • These numbers are guidelines only.

131
PROJECT PLANNING ESTIMATING
  • Guidelines
  • Retain estimates and assumptions for future use
  • Use comparison techniques for explaining
    variances and arriving at consensus
  • Top down approaches underestimates
  • Bottom up approaches overestimates
  • Always express estimates in terms of effort then
    dollars

132
Problems With Cost Estimates
  • Despite the use of sophisticated tools and
    techniques many IT project cost estimates are
    still very inaccurate.
  • This inaccuracy is even more prevalent in IT
    projects involving new technology and software as
    there are no previous historical examples to
    compare with.
  • There are typically four reasons attributed to
    inaccurate cost estimates.

133
Problems With Cost Estimates
  • Developing an estimate for a large software
    project is a complex task requiring a significant
    amount of effort.
  • This is because many estimates must be prepared
    quickly, before system requirements are clearly
    defined and before proper analysis can be
    performed.
  • A process to be followed can be as follows
  • Before the project begins a rough order of
    magnitude (ROM) budget estimate should be
    prepared.
  • This estimate is followed by a more accurate
    (typically higher cost) budget estimate.

134
Problem With Cost Estimates
  • This in turn is followed by the definitive
    estimate which, again, typically shows that it
    will cost more to do the project than previously
    estimated.
  • Something to consider
  • As with schedule management the project manager
    must insist and ensure that proper cost estimates
    and analysis be performed before the project
    begins and that the definitive estimate needs to
    be revised and updated as necessary throughout
    the project

135
Problems With Cost Estimates
  • The people who develop software and hardware cost
    estimates often do not have enough experience
    with cost estimation, especially for large
    projects.
  • Not enough accurate project data available on
    which to base estimates because organizations do
    not properly archive and manage historical
    information.
  • To overcome these issues IT people should receive
    training and mentoring on cost estimating.
  • A proper archival and management system needs to
    be developed and used for important historical
    project information.

136
Problems With Cost Estimates
  • Human beings have a bias towards underestimation.
  • One of the reasons projects are underestimated is
    that senior IT employees often make estimates
    based on their own abilities and forget about
    junior team members working on the project.
  • Another issue is that estimators typically forget
    about are integration and testing costs. This
    occurs often in areas where the team is only
    producing a small component or module within the
    whole project.
  • To overcome these problems project managers and
    senior managers must review the cost estimates
    given to them by team members and ask questions
    to make sure the estimates are not biased. (I.e..
    Get stakeholders or team members involved).

137
Problems With Cost Estimates
  • Management might ask for an estimate, but are
    really requesting a number to help them create a
    bid to win a major contract or get internal
    funding.

138
Surveyor Pro Project Cost Baseline
139
Cost Budgeting
Project budget estimates for business replacement
and explanations
140
Cost Overruns Globally
  • Australia Problems with the installation of an
    ERP system at Crane Group Ltd. led to an
    estimated cost overrun of 11.5 million.
  • India As many as 274 projects currently under
    implementation in the Central sector are
    suffering serious cost and time overruns.
  • Pakistan Pakistan has sustained a cost overrun
    of Rs 1.798 billion (over 30 million U.S.
    dollars) in the execution of the 66.5 megawatt
    Jagran Hydropower Project in the Neelum
    Valley.
  • United States Northern California lawmakers were
    outraged over Governor Arnold Schwarzenegger's
    announcement that commuters should have to pay
    construction costs on Bay Area bridges. Maybe it
    takes the Terminator to help control costs!
  • Songini, Marc L., Australian Firm Wrestles With
    ERP Delays, ComputerWorld (July 12, 2004).
  • Srinivasan, G., 274 Central sector projects
    suffer cost, time overruns, The Hindu Business
    Line (May 4, 2004).
  • Mustafa, Khalid, Rs 1.8 billion cost overrun
    in Jagran hydropower project, Daily Times
    (November 19, 2002).
  • Gannett Company, Governor Refuses to Pay for
    Bay Bridge Cost Overruns, News10 (August 17,
    2004).

141
Cost Control and measurement to help avoid Cost
Overruns
  • There are many different accounting approaches to
    measuring cost performance, however, project
    managers most often use the earned value analysis
    (EV) approach.
  • EV is a project performance measurement technique
    that integrates scope, time and cost data.
  • Given a cost performance baseline the project
    manager and their team can determine how well the
    project is meeting scope, time and cost goals by
    entering in actual information and comparing it
    to the baseline.

142
Cost Control Actual Information
  • The actual information includes whether or not a
    WBS item or work package or activity was
    completed or approximately how much of the work
    was completed

143
Earned Value Analysis or Earned Value Management
  • An important part of the budget cost control
    process in any project is performing an earned
    value analysis(EVA).
  • Earned value management (EVM) analysis involves
    calculating three values for each activity or
    summary activity in the WBS. These values
    include
  • The Planned Value (PV or BCWS).
  • This is also called the budgeted cost of work
    scheduled (BCWS).
  • This is the portion of the approved total cost
    estimate planned to be spent on an activity
    during a given period.
  • The Actual Cost of Work Performed (ACWP or AC).
  • This is also called the actual cost.
  • This is the total direct and indirect costs
    incurred in accomplishing work on an activity
    during a given period.

144
Earned Value Analysis
  • The Earned Value (EV), formerly called the
    budgeted cost of work performed (BCWP).
  • This is the percentage of the work completed
    multiplied by the planned value.
  • Earned Value (EV) PV (to date) X percent
    complete
  • Cost variance (CV) this is the budgeted cost of
    work performed (EV) minus the actual cost of
    work(AC) performed.
  • Cost Variance (CV) EV AC
  • Schedule variance (SV) this is the budgeted cost
    of work performed (EV) minus the budgeted cost of
    work scheduled (PV).
  • Schedule Variance (SV) EV PV

145
Earned Value Analysis
  • Cost performance index (CPI) this is the ratio
    of budgeted cost of work performed (EV) to actual
    cost of work scheduled (AC) and can be used to
    estimate the projected cost of completing the
    project.
  • Cost Performance Index (CPI) EV / AC
  • Schedule performance index (SPI) this is the
    ratio of budgeted cost of work performed (EV) to
    budgeted cost of work scheduled (PV), and can be
    used to estimate the projected time to complete
    the project.
  • Schedule Performance Index (SPI) EV / PV
  • Note that when the analysis is performed negative
    numbers for cost and schedule variance indicate
    problems in those areas.
  • In this event, the project is costing more then
    planned or taking longer then planned.
  • Likewise, CPI and SPI of less then 100 indicate
    problems in the projects cost and schedule.

146
Earned Value Analysis
Earned Value (EV) PV(to date) X (RP) percent
complete Cost Variance (CV) EV AC Schedule
Variance (SV) EV PV Cost Performance Index
(CPI) EV / AC Schedule Performance Index (SPI)
EV / PV Estimate At Completion (EAC) BAC /
CPI Estimate Time to Complete (ETC) Original
Time Estimate/ SPI
147
Rate of Performance
  • Rate of performance (RP) is the ratio of actual
    work completed to the percentage of work planned
    to have been completed at any given time during
    the life of the project or activity.
  • Brenda Taylor, Senior Project Manager in South
    Africa, suggests using this approach for
    estimating earned value.
  • For example, suppose the server installation was
    halfway completed by the end of week 1. The rate
    of performance would be 50 percent (50/100)
    because by the end of week 1, the planned
    schedule reflects that the task should be 100
    percent complete and only 50 percent of that work
    has been completed.

148
Earned Value Calculations for a One-Year Project
After Five Months
149
Earned Value Analysis
This example shows a project summary activity for
purchasing aWeb Server over a one week period
for 10,000.
150
Earned Value Analysis
The Planned Value (PV) is 10,000 and the Actual
Cost
About PowerShow.com