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