Docstoc

Michael Hatfield Project Management - PDF

Document Sample
Michael Hatfield Project Management - PDF Powered By Docstoc
					   CPM-600: Principals of Project
           Integration
Integrating the Project’s Technical Components
                  (Lesson A)


        Michael Hatfield PMP, CCC
             David Post PE

               IPMC 2002 Fall Conference
             Professional Education Program
  Lesson Objectives

This lesson will provide an overview of
   project definition, change control,
   configuration management, work
     authorization, and information
management as major components of
 the project integration responsibility.
The Context of Integration
I The bad news: Project Management
  Integration is a very tall order.
I The good news: It’s been done before,
  and the people who pulled it off left a
  roadmap for us.
I The Software Engineering Institute’s
  (SEI) Capability Maturity Model
    SEI-CMM Five Phases
I Phase I: Chaos, uncoordinated
I Phase II: Very basic capability, but
  consistently applied
I Phase III: Documented, repeatable
I Phase IV: Seamless, exportable
I Phase V: Routine discovery of new,
  ground-breaking solutions to PM
  problems
 Ready for More Structure?
The PMBOK Guide’s 9 Areas:

I Scope         I Human Resources
I Cost          I Communication

I Schedule      I Quality

I Risk          I Procurement
                I Integration
In Moving from Phase I to
  Phase II, it’s all about

         SCOPE!
In moving from Phase I to
        Phase II:
I Stress consistency over more advanced
  capability
I Scope definition leads all other efforts
I The WBS must be valid (no Functional
  or Organizational Breakdown Structure
  Elements, multiple roll-up paths, etc.)
Of the 9 Areas, what needs to be
       implemented first?
                          I   Cost needs a
I   Scope definition          moderate scope
    needs no other            capability
    advanced capability
                          I   Risk needs an
                              advanced scope
                              capability
                          I   Schedule needs a
                              moderate scope
                              capability
                          I   The “soft” disciplines
                              are similar
    OK, how do we do this?
I The Project Plan contains the strategy
  for capturing scope and establishing the
  baselines.
I The Work Breakdown Structure
  captures the scope in a way that
  supports baseline establishment and
  integration.
How to Write a Project Plan
Sample outlines are available in:
I DOE 413.3
I DOD, NASA Documents
I PMI, CPM
I But, really, the Project Plan is not as
  important as knowing...
How to Write a Work Breakdown
           Structure
 A valid WBS element contains the
   following characteristics:
 I Specific output or service
 I Discernible beginning and ending date
 I Resources are dedicated to it
 I One person or organizational structure
   unit is responsible for its completion
    About the entire WBS:
I All of the project’s work is captured in
  the WBS
I No work associated with the project is
  not captured in the WBS
I Lower-level elements roll up to higher
  levels, integrating detailed work with
  higher-level project objectives
Lowest-level WBS elements serve as the basis
     for the Cost & Schedule baselines

 Three types of Cost     The Schedule Baseline
   Estimates:              contains duration
 I Order of Magnitude      estimates, along
 I Budget
                           with schedule logic -
                           what happens in
 I Detailed
                           which order
Once these steps are over:
I   Make sure that all WBS elements are
    scheduled and cost-estimated
I   Load the cost estimate into the scheduling
    software, element by element
I   At this point the essential tri-fecta is in place:
    integrated cost, scope, and schedule
I   It is now possible to implement a Work
    Authorization System and a Project
    Management Information System
       Signs of Trouble
I If one of the baselines changes without
  impacting the other two
I A WBS Element Manager cannot give a
  straight answer to the question “What
  percent complete are you done?”
I Progress claimed on work not contained
  in all three baselines
Work Authorization Systems should:

 I Notify/Activate the resources planned to
   accomplish that piece of scope
 I Notify the accounting system to open
   charge accounts/cost centers to accept
   actuals
 I Modify the Performance Measurement
   System to begin collecting status
Work Authorization Systems should
              not:

 I Allow work to begin before its planned
   date
 I Accept actual charges from
   unauthorized activities
 I Be maintained informally, with no audit
   trail
A Project Management Information
          System should:

I Use Earned Value to measure the
  performance of all active work
I Be able to realistically predict, at
  current rates of performance, how long
  the activities will take and how much
  they will cost
I Roll-up the information through the
  WBS to indicate overall project/program
  health
A Project Management Information
       System should not:

I Be used to attempt to manage assets
I Indicate a change in planned figures
  without an approved BCP in place
I Fail to include a comprehensive
  Variance Analysis Report for any out-of-
  threshold variance
Generic Management Information
      System Architecture


               Information Flow


Collect Data   Process into Information   Deliver Info



                        Feedback Loop
Project Management Information
      System Architecture


             Information Flow


Estimating System Scheduling System Reporting System



           Change Control/Feedback Loop
   Change Control and
Configuration Management
Change is inevitable, so...
When presenting a BCP, present a new or
  modified
I WBS (scope impact)
I Cost Plan (resource impact)
I Target File (schedule impact)
Each of these represent quantifications of
  the exact same work.
Depending on the size of the
   Impact of the Change
I A change control board reviews high-
  impact changes
I Smaller changes can be handled
  internally, but still formally
I Establish the level of change that is to
  be addressed internally/externally, and
  document it in the Project Plan
Configuration Management
defends you from the most
 dangerous threat to your
         project:

      SCOPE CREEP
    More signs of trouble
I An activity claims some percent
  complete prior to its baseline start date
I Actual costs are being incurred from
  activities that shouldn’t have started yet
I No actual finish on activities that show
  100% complete
Variance Analysis and Integration
 Variances are our friends. Just find out
  what’s causing it:
 I   Was it in-scope, but not in the baseline? (contingency
     event)
 I   Was it out-of-scope? (scope creep)
 I   Was the baseline mis-estimated? (management
     reserve)
 I   Was it really poor performance? (management action)
 I   Or, did the scope change? (BCP prep time)
    Moving from Phase II to
           Phase III
I Stress establishing the documentation
  and training to enable the system to
  repeat itself in other projects
I Establish self-assessing protocols or
  systems to verify inter-baseline integrity
I The Acid Test: If the heroes who got
  you here go away, do your PM systems
  unravel?
       Integrating Risk
I Once again, we need at least a
  moderate capability in Scope
I Risk management quantifies the impact
  of in-scope, unbaselined work
I Therefore, we need to know exactly
  what is in the scope in order to know
  what is not in the scope
     Three types of Risk
        Assessment
I Risk Type classification
I Decision-Tree Analysis
I Monte Carlo Simulation
These depend on (at least) a moderate
  capability in Scope, and basic to
  moderate ability in Cost and Schedule.
Risk Management Systems should:

I Quantify foreseeable in-scope events
  that could impact project cost or
  schedule
I Contain time and cost estimates that
  can be used to create a contingency
  budget
I Provide an audit trail in case a
  (legitimate) contingency event occurs
Risk Management Systems should
            not:

I Allow negative variances to be covered
  by contingency funds (other than
  legitimate contingency events)
I Attempt to quantify external non-
  technical risk events (unknown
  unknowns)
I Exclude any part of the WBS
   Are we integrated yet?
It all proceeds from the Work Breakdown
   Structure:
I Each element is estimated (integrated Cost
   Baseline)
I Each element is captured in a Critical Path
   Schedule network (integrated Schedule
   Baseline)
I Each element is evaluated as to potential risk
   events that could impact cost and schedule
   (integrated Risk Analysis)
   Are we integrated yet?
Since the baselines are all consistent with the approved
   WBS,
I Scheduled WBS elements have appropriate resources
   (ideally, residing in the CPM software), integrating
   Cost to Schedule
I Costed WBS elements have resource estimates for the
   impact of potential Risk Events, integrating Risk to
   Cost
I Scheduled WBS elements have time estimates for the
   impact of potential Risk Events, integrating Risk to
   Schedule
        We are integrated!

Cost                             Each Element’s
                                  Alternatives
                                                                   Risk
                                    Costed

                  Each Element
                     Costed                       Each Element
                                                   Alternatives
                                                    Evaluated
                                   Scope
      Each                        (WBS)                           Each Element’s
                                                                   Alternatives’
    Scheduled                                                          Time
 Element Costed                                                     Estimated
                                 Each Element
                                  Scheduled




                                 Schedule
Any questions?

				
DOCUMENT INFO
Description: Michael Hatfield Project Management document sample