Immutable principles of project management

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)


Principles and practices of increasing the probability of program success

Transcript of Immutable principles of project management

  • 1.Copyright 2012, Glen B. Alleman, All Rights Reserved All projects are disappointments. Thats why they call it a project. All projects push the boundaries of schedule, cost, and technical performance, otherwise it would be called production. We need to face up to this. We need to acknowledge that projects are managed in the presence of uncertainty. Uncertainty drives risk. Risk drives cost, schedule, and technical performance. We must manage in the presence of risk. This starts with having NO, I mean NO surprises. Is something goes wrong that was a surprise, a REAL surprise, them someone didnt do their job. A risk was ignored. A risk was overlooked. A risk was hiding in plain site. Risk management is the primary role of project management. And By The Way, agile is not a risk management process unless it has a risk register, a probabilistic assessment for those risk and the impact of those risks, and a monetized outcome for the handling strategy for each risk in the Risk Register. Risk is an Uncertainty that Matters. Risk is any uncertainty that if it occurs will affect achievement of objectives. The role of risk management is to reduce or eliminate the surprise of being over budget, behind schedule, and not have your thing work. Risk management means knowing bad things are going to happen soon enough to do something about them. The other four principals of success are in support of risk management1/36

2. Copyright 2012, Glen B. Alleman, All Rights Reserved The five immutable principles of project success are: 1. Know where you are going bydefining done at some point in thefuture. This point may be far in thefuture months or years from now. Orcloser in the future days or weeks fromnow. 2. Have some kind of plan to get towhere you are going. This plan can besimple or it can be complex. Thefidelity of the plan depends on thetolerance for risk by the users of theplan. 3. Understand the resources needed toexecute the plan. How much time andmoney is needed to reach thedestination. This can be fixed orvariable. 4. Identify the impediments to progressalong the way to the destination.Have some means of removing,avoiding, or ignoring theseimpediments. 5. Have some way to measure yourplanned progress, not just yourprogress. Progress to Plan must bemeasured in units of physical percentcomplete. In units meaningful to thedecision makers.The 5 Immutable Principles of Project Management2/36 3. Copyright 2012, Glen B. Alleman, All Rights Reserved The key is requirements tell us something about where we are going. But requirements come in all shapes and sizes. Heres a sample of two extremes. A small project and a not-small project. The small project is straight forward in terms of requirements. There is a list of them on the flip chart. They are likely well understood. They probably can be estimated in terms of cost and schedule. And most importantly the interactions between the requirements can be intuited with a little effort. The project on the right is a different class of effort. This is the top level components (if you can call them that) of the Future Combat System. Its a $35B, thats billion with a B program to restructure the entire US Army Battle Space Management processes. I help one of the teams the Class I team build their Performance Measurement Baseline and get that information into a cost and schedule management system, so they can use Earned Value Management to manage their program. FCS is a software intensive system, where software is in everything from small hand held devices to major facilities housing the battle space management command. If the software doesnt work, the FCS doesnt work. Soldiers cant do their job. If soldiers cant do their job theres a BIG PROBLEM.The 5 Immutable Principles of Project Management 3/36 4. Copyright 2012, Glen B. Alleman, All Rights Reserved These two words should be tattooed on your wrist. If we dont have a Plan, our schedule is not credible. Plans are not Schedules. And Schedules are not Plans. A Plan is a Strategy for the successful delivery of the project. Plans state what is to be done (programmatically what, not technically what). Schedules state how it is to be done programmatically how it is to be done. While this may seem subtle or maybe not even useful, it is critically important for several reasons: The plan shows how the project produces increasing value and increasing maturity of the products. This value and maturity is meaningful to the business. Its is the road map from the beginning to end, INDEPENDENT from the actual durations of the work. The Plan speaks to What we are doing. The schedule is the driving instructions for the vehicles on the roads, following the map. The execution of the schedule is the actual driving of the vehicle by the driver along with the passengers. All three are needed, no one can be missing, all three interact with each other.The 5 Immutable Principles of Project Management4/36 5. Copyright 2012, Glen B. Alleman, All Rights Reserved Now that we know about the existence of a Plan, what is the Schedule? Why is it different from the Plan? The Schedule shows the work needed to produce the deliverables in the Plan. This sounds like a tautology a statement of the obvious. But theres more to it than that. This work is ONLY the work needed to cause the exit criteria to appear of each individual definition of the criteria for named Accomplishment. In a previous slide we mentioned the definition of the Accomplishments come first. With these definitions and most importantly the order in which these Accomplishments must be accomplished I know this is not as clear as youd expect at this point. But well need to use an example before we get back to the details. For now think of the schedule as the description of how the individual Exit Criteria from the lumps of work are to be accomplished.The 5 Immutable Principles of Project Management5/36 6. Copyright 2012, Glen B. Alleman, All Rights Reserved Now that we know where we want to go, the next question is how to get there. How do we build the products or provide the services needed to reach the end of our project. There are numerous choices, depending on the domain and the context of the project in that domain. For the software domain there are many contexts. Using the example on the previous page, lets look at two methods. These are the extreme ends of the spectrum of contexts and methods. They can serve to focus the discussion on project management rather than product development methods, by hopefully disconnecting project management from product development so we can look at them separately. In the first software development context a list of features, SCRUM is a popular approach. But there are many more software based project, possibly more complex than the example from the previous page to the wickedly complex program also shown on the previous page. The SCRUM method is shown in its common diagram. But below it is the method used for product procurement in the US Department of Defense DoD 5000.02. The products are not actually developed by the DoD (except in rare cases). But are instead, procured. So acquisition management is guided by this process. Both are iterative, both are incremental, both can deal with emerging requirements, both make use of test driven planning, and both have clear and concise measures of physical percent complete.The 5 Immutable Principles of Project Management 6/36 7. Copyright 2012, Glen B. Alleman, All Rights Reserved Now that we know some things about what capabilities we need and how we might cause these capabilities to appear at the appointed time and place for the planned cost and schedule, do we know what we need to be successful? We need to constantly ask this question. If we dont ask and answer the question, well find out what is missing when they arrive on our doorstep. At that point it will be too late. It is not too late to acquire them, but too late to acquire them within our planned schedule and planned budget.The 5 Immutable Principles of Project Management7/36 8. Copyright 2012, Glen B. Alleman, All Rights Reserved Now that we know where were going and how to get there do we have all we need to reach the end? Staff, time, money, the necessary skill and experience and the proper management support. These are all obvious on any project at least any well managed project. But there are always underlying issues with answering these questions. The first is that management, as well as the development organization, is always optimistic about the outcome. This is the very nature of project management. Why be pessimistic? Well maybe not pessimistic, but how about realistic? What do we mean when we say realistic? One good word is credible. Credible could be optimistically credible or pessimistically credible. But either way we have a credible understanding of what it takes to reach the end. One part of credible is knowing what the risks and uncertainties are and how we are going to deal with them. Managing in the Presence of these uncertainties is critical to reaching our goal. Risk and uncertainty never go away. They are always there. They are unavoidable.The 5 Immutable Principles of Project Management8/58 9. Copyright 2012, Glen B. Alleman, All Rights Reserved Project Managers constantly seek ways to eliminate or control risk, variance, and uncertainty. This is a hopeless pursuit. Managing in the presence of risk, variance and uncertainty is the key to success. Some projects have few uncertainties only the complexity of tasks and relationships is important but most projects are characterized by several types of uncertainty. Although each uncertainty type is distinct, a single project may encounter some combination of four types: 1. Variation comes from many smallinfluences and yields a range ofvalues on a particular activity.Attempting to control these variancesoutside their natural boundaries is awaste (Muda)