Increasing The Probability of Success
           Integrating Process, People, and Tools


                      Dallas MPU...
It’s Not Really About Tools




 You’ve seen all kinds of demonstrations of project tools
 This will not be one of them
...
Today's Learning Objectives
                                                   Cost, Schedule, Technical
                ...
So What Are the Real Problems With IT Projects?




                                                  4
Here’s The Fundamental Problem With All Projects
 Having and using tools is necessary but far from sufficient
 Understan...
The Three Fundamental Elements Of All Projects
        People                   Process                 Technology




 P...
5 Processes For Successful Enterprise IT Projects
            1
                Identify Business
    Why               Ne...
Connecting The Dots For Project Success




                              Continuous Risk
                              Ma...
Let’s Skip the Processes and
People and Move To Our Topic




  What tools are needed to support
    the People and Proces...
Requirements Management Tools




Developing precise and accurate requirements is a crucial step in the
    success of a d...
Schedule Management Tools




                       A Schedule is NOT a Plan
 A Plan is the strategy for the successful c...
Cost Management Tools




                       Time is NOT Money
Money can be preserved, Time is lost starting the 1st D...
Risk Management Tools




Risk Management is How Adults Manage Projects
                — Tim Lister
                     ...
Integrating Tools For Project Success




                          Plan
            Integrated elements for project
     ...
 A Defined Set Of Business
How to Produce Value
                           Capabilities
  by Integrating Tools    A Stru...
Before We Move On To Some Solutions, There Are
      Some Questions We Need To Answer

   Do we know what the customer wa...
To Reach Done We MUST Know What Done Looks Like

 The Way To Describe DONE is to build a WBS that:
  Is product or servic...
Building The WBS In MSFT Project
 Don’t use the WBS field, it wants to do things its
  way, use a custom TEXT field
 Bui...
Guidelines For Building A “Good” WBS
                                  The 100% rule – all work in
                      ...
Using MindManager® To Build The WBS
                     Capture the contents of this
                      “Map” in the ...
The Output Of MindManager®
                 The MSFT Project WBS can
                  be derived directly from
         ...
What’s In A Name? The WBS Dictionary
                         The WBS dictionary is
                          the guide t...
Connecting The WBS With Work Packages
 WBS
                                                                               ...
Building A Credible Schedule

 What are the units of measure for “Credible?”
 “What does DONE look like?”
  The schedule...
It’s The Not Work Effort We’re After
         It’s “What Does Done Look Like?”




The schedule must speak in units of mea...
Sample Schedule Health Check




     http://www.steelray.com/index.html   26
The Risk Management Paradigm

MANAGING RISK WITH A STANDARD PROCESS    RISK MANAGEMENT IN FIVE EASY STEPS

               ...
Two Types Of Project Risk
 Technical risk                                     Programmatic risk
  – The risk that the pr...
The Risk Register
 This tool is free, approved by DoD and used on highly visible, mission critical
  programs and comes w...
Monte Carlo Simulation (Risk+) Of A Schedule Date
 No single point estimate of cost or schedule can be credible without
 ...
Monte Carlo Simulation (Crystal Ball) Of A Cost
 The same approach is taken for cost analysis
 Cost Risk, Schedule Risk,...
Resource Loaded Schedule?

            Resource loading individual tasks
             is a waste of time and effort
     ...
Capabilities            Requirements           Master Plan            Execution
       MindJet                  MindJet   ...
Ok, It Is About Tools After All
                  … Sort Of




 But only after you’ve established all the business and
 ...
The Starting Point for Building a Credible
             Schedule in MSFT Project
          Work Description               ...
Work Coded
                                                               Deliverables
            To WBS

               ...
The Next Tool After Project
   PERTChart Expert




       www.criticaltools.com   37
The Next Tool Is a Monte Carlo
         Simulator for Programmatic Risk
                                                  ...
The Final Tool That Integrates Everything
                                                     Put the all
         Capabi...
Input                         Tool                     Outcome
                                                           ...
Upcoming SlideShare
Loading in …5
×

Dallas Mpug

1,944 views

Published on

The three elements of project management, people, processes, and tools must focus on processes first.
Without a process, the tools have no purpose.
Without a process, the people are unguided, or at best self guided

Published in: Technology, Business
2 Comments
2 Likes
Statistics
Notes
No Downloads
Views
Total views
1,944
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
2
Likes
2
Embeds 0
No embeds

No notes for slide

Dallas Mpug

  1. 1. Increasing The Probability of Success Integrating Process, People, and Tools Dallas MPUG May 6th, 2009 Glen B. Alleman VP, Program Planning and Controls Lewis & Fowler www.lewisandfowler.com Increasing the Probability of Success for Enterprise IT Projects Starts with Credible Information About the Performance of the Project. This information comes from tools. 1
  2. 2. It’s Not Really About Tools  You’ve seen all kinds of demonstrations of project tools  This will not be one of them  We’re going to talk about what happens before tools application – the business reasons for using tools  We’ll see screen shots to show how some tools can be applied 2
  3. 3. Today's Learning Objectives  Cost, Schedule, Technical Performance†, and Risk are inseparable elements of a project  Process integrates these inseparable variables  People are the source of all information, need, and the consumers of business value  Tools can be used to implement processes, but only the right processes will return the value from the tools 3 †Technical Performance includes all non-cost and schedule elements of the project
  4. 4. So What Are the Real Problems With IT Projects? 4
  5. 5. Here’s The Fundamental Problem With All Projects  Having and using tools is necessary but far from sufficient  Understanding the principles of project management is the next step  Dealing the statistical nature of project work is the starting point for successfully applying tools to the problem of “managing in the presence of change” 5
  6. 6. The Three Fundamental Elements Of All Projects People Process Technology  People pay for  Processes guide the  Tools are the glue to solutions to development integrate processes problems, not the activities toward the with people.  Tools transform data tools and processes business goals.  Processes provide that produce those into actionable solutions. boundaries which information for the  The processes and control the action of stakeholders. tools are simply the individuals and “cost” of doing groups. business, provided by the supplier. 6
  7. 7. 5 Processes For Successful Enterprise IT Projects 1 Identify Business Why Needs Operational Needs Capabilities Based Plan System Value 2 Stream Identify Requirements What Baseline Technical Technical Performance Requirements Measures 3 Establish a Performance PMB Measurement Baseline Technical Performance How Measures Earned Value Where Performance 4 Execute the When 0% /100% Performance Who Measurement Baseline Changes to Changes to Changes to business strategy requirements project plan 5 Continuous Risk Management Process 7
  8. 8. Connecting The Dots For Project Success Continuous Risk Management is the glue that connects all elements of Enterprise IT project management 8
  9. 9. Let’s Skip the Processes and People and Move To Our Topic What tools are needed to support the People and Processes? 9
  10. 10. Requirements Management Tools Developing precise and accurate requirements is a crucial step in the success of a development project or new business process. — Visual Studio 2008 Extensibility Site 10
  11. 11. Schedule Management Tools A Schedule is NOT a Plan A Plan is the strategy for the successful completion of the project; The Schedule is the description of the work to produce that success. Both Plans and Schedules are needed! 11
  12. 12. Cost Management Tools Time is NOT Money Money can be preserved, Time is lost starting the 1st Day of the Project 12
  13. 13. Risk Management Tools Risk Management is How Adults Manage Projects — Tim Lister 13
  14. 14. Integrating Tools For Project Success Plan Integrated elements for project success Cost Schedule The Enterprise Program Management System Performance Technical 14
  15. 15.  A Defined Set Of Business How to Produce Value Capabilities by Integrating Tools  A Structured Requirements Flow with the People and Down Tree  A Well Defined Work Breakdown the Processes Structure  Clear And Concise Descriptions Of Deliverables  Work Packages To Produce These Deliverables  Measures Of Physical Percent Complete  Continuous Risk Management At Every Step  An Integrated Digital Environment  Training To Recognize What “done” Looks Like  The Will To Make All This Happen 15
  16. 16. Before We Move On To Some Solutions, There Are Some Questions We Need To Answer  Do we know what the customer wants?  How much will it cost when it is done?  When will we be done?  What stands in our way to reaching done?  Who works on what parts of the solution?  Can we speak about our progress in units of measure meaningful to the customer? 16
  17. 17. To Reach Done We MUST Know What Done Looks Like The Way To Describe DONE is to build a WBS that:  Is product or services oriented  Includes all work in the project  Logically aggregates each element of the product and those elements below it  Reflects the manner in which the work will be done The WBS becomes the framework for Cost, Schedule, and Technical Performance Measurement. The WBS is the organizational structure for the Work Packages This sounds simple at best and possibly lame at worst. But without a description of what the project is delivering, you might as well not even start. You’ll just be wasting everyone’s time and money. 17
  18. 18. Building The WBS In MSFT Project  Don’t use the WBS field, it wants to do things its way, use a custom TEXT field  Build the WBS in a logical manner with a tool that support hierarchical decomposition – MindJet®  The WBS is derived from the requirements, not from the functions that implement the requirements  The WBS states in unequivocal terms what “done” looks like – when all the deliverables are delivered we’re done 18
  19. 19. Guidelines For Building A “Good” WBS  The 100% rule – all work in the WBS  Mutually exclusive elements – no overlapping scope – a pure hierarchy tree  Planned outcomes, not planned actions – define the deliverables and their components  Levels of detail – The 80-hour rule for each end item – Work should cross only one accounting period How long are you willing to wait before you find out you’re late? 19
  20. 20. Using MindManager® To Build The WBS  Capture the contents of this “Map” in the Product Development Kaizen  Focus on the “product” decomposition not the functional decomposition  This is an iterative and incremental process  Have the stakeholders in the room  Connect the WBS with the “needed business capabilities” by asking why do we have this product element here? www.mindjet.com 20
  21. 21. The Output Of MindManager®  The MSFT Project WBS can be derived directly from the Mind Map structure with a mouse click  This example uses the WBS field, but that’s discouraged  Use a text field and a template 21
  22. 22. What’s In A Name? The WBS Dictionary  The WBS dictionary is the guide the “Done”  It states what the evidence is for the product or service  Enter this information into the Notes field for each project activities  Print this report for the WBS Dictionary  Use this to assess what is being delivered 22
  23. 23. Connecting The WBS With Work Packages WBS A decomposition of the work Business Need Process Invoices for Top needed to fulfill the business Tier Suppliers requirements 1st Level 1st Level Electronic Invoice Routing to Payables Department Submittal 2nd Level 2nd Level Material receipt Payables Account verification Verification Terminal Node in the WBS 2nd Level 2nd Level “On hand” balance defines the products or Payment Scheduling Updates services of the project Work Terminal node of the Deliverables defined in WP WBS defined by a Work Package Package Deliverables Tasks and Schedule Tasks within the Work Package produce the 1 2 5 A Deliverables 3 6 B 4 Management of the Work Package Tasks is the responsibility of 100% Completion of deliverables is the WP Manager. the measure of performance for the These are not held in Work Package the master plan 23
  24. 24. Building A Credible Schedule  What are the units of measure for “Credible?”  “What does DONE look like?” The schedule is the description of the work needed to produce value to the Stakeholder  The schedule must be a logical flow of the increasing value produced by the work effort  The durations must have statistical measures associated with the static durations  The “reader” must be able to recognize how the “value flow” is constructed 24
  25. 25. It’s The Not Work Effort We’re After It’s “What Does Done Look Like?” The schedule must speak in units of measure meaningful to the stakeholders – business value and physical percent complete 25
  26. 26. Sample Schedule Health Check http://www.steelray.com/index.html 26
  27. 27. The Risk Management Paradigm MANAGING RISK WITH A STANDARD PROCESS RISK MANAGEMENT IN FIVE EASY STEPS 1. Hope is NOT a strategy 2. No single point estimate of cost or schedule can be correct 3. Cost, Schedule, and Technical Performance are inseparable 4. Risk management requires adherence to a well defined process 5. Communication is the #1 success factor http://www.sei.cmu.edu/risk/index.html 27
  28. 28. Two Types Of Project Risk  Technical risk  Programmatic risk – The risk that the project – Cost overruns will fail to meet its • The project will exceed performance criteria its planned budget • Hardware and software – Schedule overruns failures • The project will exceed • Requirements failures its planned completion date Date: 9/26/2005 2:14:02 PM Completion Std Deviation: 4.83 days Samples: 500 95% Confidence Interval: 0.42 days Unique ID: 10 Each bar represents 2 days Name: Task 10 1.0 0.16 Completion Probability Table Cumulative Probability 0.9 0.14 Prob Date Prob Date 0.8 0.05 2/17/06 0.55 3/1/06 0.12 0.7 Frequency 0.10 2/21/06 0.60 3/2/06 0.10 0.6 0.15 2/22/06 0.65 3/3/06 0.20 2/22/06 0.70 3/3/06 0.5 0.08 0.25 2/23/06 0.75 3/6/06 0.4 0.06 0.30 2/24/06 0.80 3/7/06 0.3 0.35 2/27/06 0.85 3/8/06 0.04 0.2 0.40 2/27/06 0.90 3/9/06 0.02 0.1 0.45 2/28/06 0.95 3/13/06 0.50 3/1/06 1.00 3/17/06 2/10/06 3/1/06 3/17/06 So much for our strategy of Completion Date winning through technical Risk+ is at: www.deltek.com dominance 28
  29. 29. The Risk Register  This tool is free, approved by DoD and used on highly visible, mission critical programs and comes with a manual  But commitment is mandatory to maintain content and make decision on this content http://www.mitre.org/work/sepo/toolkits/risk/index.html 29
  30. 30. Monte Carlo Simulation (Risk+) Of A Schedule Date  No single point estimate of cost or schedule can be credible without understanding the statistical variances  Without this schedule modeling information – Hope is Your Strategy Most Min Likely Max Date: 10/4/2005 1:58:06 PM Completion Std Deviation: 1.55 days Samples: 23 95% Confidence Interval: 0.63 days Unique ID: 143 Each bar represents 1 day Name: Construction Schedule Margin 1.0 0.35 Completion Probability Table 0.9 0.30 Prob Date Prob Date 0.8 0.05 2/6/06 0.55 2/9/06 Cumulative Probability 0.25 0.7 0.10 2/6/06 0.60 2/9/06 Frequency Target Date 0.6 0.15 2/7/06 0.65 2/9/06 0.20 0.20 2/7/06 0.70 2/10/06 0.5 0.15 0.25 2/7/06 0.75 2/10/06 0.4 80% confidence 0.30 2/8/06 0.80 2/10/06 0.3 0.10 0.35 2/8/06 0.85 2/10/06 0.2 0.40 2/9/06 0.90 2/10/06 “The purpose of modeling is to 0.05 0.1 0.45 2/9/06 0.95 2/10/06 relentlessly expose the inevitable 0.50 2/9/06 1.00 2/14/06 2/3/06 2/9/06 2/14/06 outcome of our assumptions” – Completion Date Anonymous 30
  31. 31. Monte Carlo Simulation (Crystal Ball) Of A Cost  The same approach is taken for cost analysis  Cost Risk, Schedule Risk, and Technical Risk are inseparable  Managing in the absence of this understanding means, Hope Is Your Strategy Combined Cost Modeling and Technical Uncertainty Cost = a + bXc Cost Modeling Uncertainty Cost Estimate Historical data point $ Cost estimating relationship Standard percent error bounds Technical Uncertainty Cost Driver (Weight) www.oracle.com/crystalball/index.html 31
  32. 32. Resource Loaded Schedule?  Resource loading individual tasks is a waste of time and effort  Resource allocate at the Work Package level  Let the Work Package manager assign, allocate, and manage these resources within the Work Packages  Use this resource allocation as the basis of the labor spreads  The WP Manager keeps these balanced by looking at the labor spreads in the Resource View 32
  33. 33. Capabilities Requirements Master Plan Execution MindJet MindJet Project Project  Map of  Flow down of  Deliverables  Physical Percent dependencies requirements from connected to Complete recorded between Capabilities Requirements and in Master Plan  Produce Excel of  Embedded Risk capabilities Capabilities  Group capabilities  Work Packages details for mitigations into business traceability define one identified in Text  Connect benefits deliverable Field  Trace capabilities to  Technical  Technical requirements with stakeholder needs Organizational Performance Performance Structure Measures reportable from  Tradeoffs visible embedded in notes MSFT Project with dependencies field Continuous Risk Management  MITRE risk management tool  Risk+ or @Risk for Project Tool 33
  34. 34. Ok, It Is About Tools After All … Sort Of  But only after you’ve established all the business and programmatic processes  Then and ONLY THEN can the tools provide value to the organization 34
  35. 35. The Starting Point for Building a Credible Schedule in MSFT Project Work Description Work Arrangements  Work Packages derived from WBS  Finish to Start relationships the vast and Deliverables, never bottom up majority of the work  All work contained in schedule  All constraints are AS SOON AS produces outcomes. Never build a POSSIBLE (ASAP)  Task durations are approximate as a functional schedule (design, code, test) start.  Work Packages are linked through a  Schedule margin is EXPLICIT in the connection tasks, that represent the schedule NEVER buried in the intermediate outputs duration estimates  Activities inside Work Packages  No widows or orphans in the schedule  All work flow to deliverables describe end to end work for the  Resources are “assigned” inside the deliverable  Zero duration tasks represent the Work Packages and balanced by hand deliverables through the Resource Usage view  All work “trees up” to deliverables  Measures of progress focused on deliverables, not the passage of time 35
  36. 36. Work Coded Deliverables To WBS Finish to Start Only IT-1 PAX River Test Van Risk Buy Down Activities Embedded Risk Mgmnt Gate Review & Publish “Quick Look” for FA-18 Test Range Instruments Complete Task Names State what is being done Durations on week Show Slack boundaries No Negative! The Schedule MUST read a literature. Informing the reader what is happening, what is the result of the work (Deliverables), how risk is dealt with, and when the deliverables are planned to be “Delivered.” NEVER EVER CONFUSE EFFORT WITH RESULTS 36
  37. 37. The Next Tool After Project PERTChart Expert www.criticaltools.com 37
  38. 38. The Next Tool Is a Monte Carlo Simulator for Programmatic Risk Planned Completion 12/1/2010 In order to credibly assess the programmatic risk, the schedule must be properly formed. The schedule health check and basic structural integrity described in the previous slides is the starting point 80% Confidence of completing on or before 12/10/2010 38
  39. 39. The Final Tool That Integrates Everything Put the all Capabilities programmatic data under Requirements change control Derived from Capabilities Risk mitigation or retirement in the schedule WBS WBS Formal risk management in RM Tool Credible Work Work Packages to Packages produce sequences to deliverables in the produce delivered WBS terminal value needed by nodes the business Increasing the Probability of Success Means Thoughtful Actions 39
  40. 40. Input Tool Outcome Connection between Requirements Capabilities Identification requirements and Management business value Connection between Requirements Requirements requirements and Management Management planned work Traceable costs to Work Breakdown Structure deliverables Measures of Physical Deliverables Percent Complete Microsoft Work Packages of Project Allocated effort and Deliverables Or measures of progress Project Server In line description of risk Risk Mitigation Plans retirement plans Cost spreads for Work Align cost and schedule Packages with deliverables Risk Identification and Connection between risk MITRE Risk Management Tool Management and mitigation efforts 40

×