Immutable principles of project management (fw pmi)(v4)

Copyright ® 2010, Lewis & Fowler, All Rights Reserved I’d like to thank you for inviting me to speak at your workshop. My contribution to this topic is from the point of view of a program controls manager in the aerospace and defense business. The programs we work are software intensive, but not in the way commercial software projects are. The software on our programs is embedded in other systems – avionics, flight controls, ground management systems of aircraft and spacecraft. Other parts of our firm work programs for commercial enterprise IT. The principles I’m going to introduce you to today are applicable to all projects no matter the domain or the context in that domain. From software, COTS IT, construction, any project where the outcome is critical to the success of the participants. The 5 Immutable Principles of Project Management 1/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved There are three outcomes for this talk. 1. I’m going the suggest there is common misunderstanding that software development and project management are the same thing. 2. There are 5 irreducible principles for managing any project, no matter the domain or the context. 3. And, as software developers, along with the project manager, if you are not answering the questions from these irreducible principles, you’re probably doing project management and your project is in jeopardy and you may not know it. The 5 Immutable Principles of Project Management 2/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved We’ve all seen the numbers. We’ve all been told how bad things are. 77% of project failures are due to poor planning or poor project management. Here’s one more look. But we’re here to work on only one of the aspects of the “money flushing” part of your project activity We’re here today to talk about the project management aspects of projects. The planning, scheduling, costing, management verbs of projects. These are called the Programmatic Elements of the project. Versus the technological aspects. As a program manager I’m very interested in the technology. But my job is to make sure the programmatic aspects work, so the technology has a chance of actually showing up on time. The 5 Immutable Principles of Project Management 3/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So first let’s review what is a project. It’s a one off event. It’s not operations. It’s not repeatable processes – although the processes that manage projects are repeatable, the project itself is a one time occurrence. The reason this is important is that projects are a “one chance to get it right” type of endeavor. Operations has several chances to get it right. Maybe a lot of chances. Sometimes only a few. But never just one. Now there is another word here – probability. Projects have a probability of success. There is no guarantee. We’d like this probability to be as high as possible. For some projects the probability is high – close to 100%. For some projects the probability, while acceptable, is actually low. There is 1 chance in 149 of losing the mission for the Orion Manned Spaceflight program with specific types of launch vehicles. What’s the probability of having your Enterprise ERP project rollout fail in a way that causes an unrecoverable loss to your company? Good question. How can you improve the probability of success for your project? Another good question. The 5 Immutable Principles of Project Management 4/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Mr. Blaise’s quote is applicable to almost every major project we’ve encountered. It’s sad but true that we simply don’t know how to stop work once we’ve started. The work shop today is not about that decision though. It’s about applying the principles of project management, so we don’t have to treat projects in such a “black and white” manner. The 5 Immutable Principles of Project Management 5/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Management is a verb. When applied to an object, like a project, this verb is the actions needed to control and guide the development of the outcomes of the project. No matter what your approach, self guided or all the way to formal project management methods, projects need a framework in which to make progress. The definitions here define the boundaries of the processes applied to the project. The 5 Immutable Principles of Project Management 6/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we put these terms together we arrive at the basis of today's work shop. We need knowledge, skills, tools, and techniques in order to increase our Probability of Project Success (PoPS). The five (5) immutable project management principles are independent of all these things. At the same time they apply to any and all these things. And finally they are independent of any project domain and any context in that domain. With the concept of Project + Management in hand, let’s look at the domain and context in those domains for applying this verb and noun. The 5 Immutable Principles of Project Management 7/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved The notion of simplicity has entered the discussion around project management methods, tools, processes, and other elements. On one end we have Leonardo’s quote about simplicity being the ultimate sophistication. On the other we have Mencken’s reminder that complex problems and their solutions are connected in ways we may not actually understand. Searching for simplicity in the absence of understanding the “system” usually leads to disappointment. When we’re walking through our immutable principles today, let’s keep in mind the connection between simplicity and complexity and the solutions we need to address this complexity. The 5 Immutable Principles of Project Management 8/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Here’s an idea that we don’t always consider upfront when we look for processes and principles. The amount of risk a project can tolerate is directly related to the business domain and the context of the project within that domain. Understanding the tolerance for these risk levels are critical to choosing and applying any software development method. However, the five immutable principles presented here are juts that, immutable. They must be present in some form no matter the product development method, the level of risk tolerance of the domain and the context within that domain. The risk tolerance for cost is defined as the ability for the customer to absorb changes in the planned cost through management reserve and the application of additional funds. The risk tolerance for schedule slippage is defined as the ability to still produce value for the customer in the presence of a late or slipping schedule. The risk tolerance for Technical Performance means the customer is willing to accept technical capabilities that are less than planned. With this background, let’s look at the five (5) immutable principles. The 5 Immutable Principles of Project Management 9/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved The five immutable principles of project management are: 1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now. 2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. 3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable. 4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments. 5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete. The 5 Immutable Principles of Project Management 10/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we confuse product development with project management, we’ve missed answering the 5 immutable principles questions. We skipped directly to the “doing” part of the project. The “managing of the doing” is not the same as the “doing.” Both are needed of course. If we only have the “doing” part, then the project is guided by the immediate outcomes of the development process. The project outcomes “emerge” as it progresses. This is the basis of some forms of Agile. There may be broader goals, but the development team only responds to the “next” increment. Many projects are successful applying this product development method as a replacement for project management. The other approach – and this is a context sensitive approach – is to define the needed capabilities, the requirements needed to fulfill those capabilities, and the work plan to make those requirements appear. This does not mean the fidelity of the requirements is complete. Some could be vague, some could be altered as we proceed. But the end-to-end goal is defined with enough fidelity to assure the customer we understand what DONE looks like. 11

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Our first step here is to separate a Plan from a Schedule. The PLAN is a procedure used to achieve an objective. It is a set of intended actions, through which one expects to achieve a goal. The SCHEDULE is the sequence of these intended actions, needed to implement the PLAN. But we don’t what to mix the PLAN with the SCHEDULE. The PLAN is the strategy for the successful completion of the project. In the strategic planning domain, a PLAN is a hypothesis that needs to be tested along the way to confirm we’re headed. The SCHEDULE is the order of the work to execute the PLAN. We need both. PLANS without SCHEDULES are not executable. SCHEDULES without PLANS have no stated mission, vision, or description of success other than the execution of the work. The 5 Immutable Principles of Project Management 12/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we say “where are we going,” we should be talking about physical outcomes – the deliverables. When we say deliverables, what deliverables are we talking about? The deliverables should be those that fulfill the requirements. So what are the requirements? As our quote says here, the single hardest part of building a system is deciding what to build. No matter what method you use to make these decisions – from the agilest of methods to the most formal, we need to have the requirements stated in a form that is testable, verifiable, and traceable to the PLAN and SCHEDULE. The 5 Immutable Principles of Project Management 13/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Here’s some words that we’ll encounter during the development of requirements. These are not the only words of course, but these words are important ones. One critical set of words are “Stated” versus “Real.” Stated requirements are any requirement that is written down – that is stated. “Real” requirements are of course requirements that are really needed by the system to fulfill its business case. Other words are important as well. “Verified” and “Validated” are a pair. One of the requirements words that causes much extra work is “derived.” A derived requirement is one that is not primary, but is secondary. As such it may not be obvious that it is a requirement. There are requirements words that should be avoided. The first one – that may not be obvious – is “Customer.” Which customer? How do we know what the customer wants? One simple way out of this is to state the requirement, that we think is a customer requirement, in terms of a business requirement. Complete with a business reason, business case, business payback, other business reasons. Of course there are phrases that should be avoided as well. “User Friendly” has started to be purged from the vocabulary – at long last. But “flexible” and “reliable” are still hanging around. The 5 Immutable Principles of Project Management 14/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved The key here is that requirements tell us something about where we are going. But requirements come in all shapes and sizes. Here’s 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. It’s a $35B, that’s 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 doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. If soldiers can’t do their job – there’s a BIG PROBLEM. The 5 Immutable Principles of Project Management 15/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Let’s start our exercise with a topic that should be familiar to you – flying to the moon. We flown to the moon and returned safely before. It can’t be that hard. Yea right. We’ll use the current moon mission as a framework to ask and answer the questions posed by the five (5) immutable principles. The 5 Immutable Principles of Project Management 16/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved For the moment, let’s use a simpler analogy to connect with something more tangible. Let’s pretend we want to go on a hike. A nice hike to the saddle just to the right of the peak above this lake. That saddle is Pawnee Pass. It’s just west of Boulder Colorado, and a bit south of Rocky Mountain National Park. We’d like to go to Pawnee Pass in a single day – there and back. Not get too wet if it rains. Not be too hungry. And have a good time along the way with our hiking group. That’s our mission. The 5 Immutable Principles of Project Management 17/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved These two words should be tattooed on your wrist. If we don’t have a Plan, our schedule is not credible. Plans are not Schedules. And Schedules are not Plans. A Plan is the 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.  It’s 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 Management 18/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Plans are strategies. They tell us the flow of the project in terms of deliverables and the increasing value and maturity of those deliverables. I’m going to introduce some new words here that we’ll use later. They are just words for now, so their exact meaning is not important. This is similar to the Value Stream Map found in Lean Six Sigma. The “map” is the flow of the Significant Accomplishments in the project or program. For these Accomplishments, there are a set of Criteria that define the “exit conditions” for the underlying work. Defining these criteria BEFORE defining the details of the work is the basis of the Planning process. This is a top down-first approach . It is NOT a Top Down only approach, just the 1st step in the process. But with the Accomplishments and the Criteria defined, there is a notional view of what “done” looks like. Measureable in some units meaningful to the project management team and the stakeholders in the project. This focus on the definition of “done” is important for several reasons: 1. “Done” is a measure of 100% done, not partially done, not almost done. But DONE. This is the concept of “starting with the end in mind,” popularized by Covey. 2. Along the way to DONE, there are measures of “getting to done” that are “mini-dones.” These “maturity assessment points” are the way to measure physical percent complete in terms of the product maturity rather than the consumption of resources or passage of time. The 5 Immutable Principles of Project Management 19/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Now that we know about the existence of a Plan, what is the Schedule? Why is it different from a 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 there’s 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 you’d expect at this point. But we’ll 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 Management 20/62

Copyright ® 2010, Lewis & Fowler, 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 context’s. Using the example on the previous page, let’s 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 21/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Know that we know something about our “mission,” “vision” – going to the moon, let’s see if we can answer the question of “how” do we get there? The 5 Immutable Principles of Project Management 22/62

Copyright ® 2010, Lewis & Fowler, 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 don’t ask and answer the question, we’ll 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 Management 23/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Now that we know where we’re 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 are 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 dealing 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 Management 24/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Once we recognize that time is not money and money is not time, the next eye opener for all project work is there is a natural statistical variability of both these elements. So no matter what software development method you are applying inside a project management set of processes, you must come to grips with the statistical nature of cost, schedule, and technical performance. This area is called Programmatic Risk and its cousin Technical Risk. The Programmatic Risk concept is not well understood outside the defense and space business. There it is mandated that Programmatic Risk be managed – DID 81650 describes this mandate. The Monte Carlo simulation method is the way to assess the behavior of the network of activities, but there subtleties beyond just the simulation of the network. The Monte Carlo tools don’t easily model the coupling and correlations between the work activities in a proactive manner. There are other tools for modeling the network, but they are also outside this presentation. The 5 Immutable Principles of Project Management 25/62

Copyright ® 2010, Lewis & Fowler, 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 small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda). 2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties. 3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed. 4. Chaos – appears in the presence of “unknown unknowns.” “Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000. The 5 Immutable Principles of Project Management 27/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Project duration and costs are random variables drawn from some underlying probability distribution. In probability theory, every random variable is attributed to a probability distribution. The probability distribution associated with a cost or duration describes the variance of these random variables. A common distribution of probabilistic estimates for cost and schedule random variables is the Triangle Distribution. Using the Triangle Distribution for the costs and durations, a Monte Carlo simulation of the network of activities and their costs can be performed. Monte Carlo methods are used to numerically transform and integrate the posterior quantitative risk assessment into a confidence interval. The result is a “confidence” model for the cost and completion times for the project based on the upper and lower bounds of each distribution assigned to each duration and cost. The 5 Immutable Principles of Project Management 28/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved If risk management is how adults manage projects, here are some principles of project risk management. These five principles are simple, obvious, but difficult to implement. This reason they’re difficult is that most people shy away from risk. Managing in the presence of risk does not come naturally. It is a learned behavior. And once learned it has to be practiced. But before it can be learned and then practiced, “managing in the presence of risk,” must become part of the business culture. Some cultures doe this better than others. NASA is probably better than others. But even NASA has moved a risk adverse culture in the past decades. 1. Hoping that something positive will result is not a very good strategy. Preparing for success is the basis of success. 2. Single point estimates are no better than 50/50 guesses in the absence of knowledge of the standard deviation of the underlying distribution. 3. Without connecting cost, schedule, and technical performance of the effort to produce the product or service, the connection to value cannot be made. 4. Risk management is not an ad hoc process that you can make up as you go. A formal foundation for risk management is needed. 5. Identifying risks without communicating them is a waste of time. The 5 Immutable Principles of Project Management 29/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Project Managers constantly seek ways to eliminate or control risk, variance and uncertainly. 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 small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda). 2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a mitigation plan for these foreseen uncertainties. 3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed. 4. Chaos – appears in the presence of “unknown unknowns.” “Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2000. The 5 Immutable Principles of Project Management 30/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved The use of point estimates for durations and costs is many times the first impulse in an organization low on the project management maturity scale. Understanding cost and durations are actually “random variables,” drawn from an underlying distribution of possible value is the starting point for managing in the presence of uncertainty. The Triangle Distribution is used as a subjective description of a population for which there is only limited sample data, and especially where the relationship between variables is known but data is scarce. It is based on the knowledge of the minimum and maximum and a “best guess” of the modal value (the Most Likely). Using the Triangle Distribution for the costs and durations, a Monte Carlo simulation of the network of activities and their costs can be performed. Monte Carlo methods are used to numerically transform and integrate the posterior quantitative risk assessment into a confidence interval. The result is a “confidence” model for the cost and completion times for the project based on the upper and lower bounds of each distribution assigned to each duration and cost. This approach to estimating provides insight into the behavior of the plan as well as sensitivity between the individual elements of the plan. The 5 Immutable Principles of Project Management 31/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved In many descriptions of project management – cost, schedule, and quality are considered as the “Iron Triangle.” Change one and the other two must change as well. It turns out this is too narrow a view of what's happening on a project. It’s the Technical Performance Measurement that replaces Quality. Quality is one of the Technical Performance measures. Technical Performance Measures describe the status of technical achievement of the project at any point in time. The Planned technical achievement is part of the Performance Measurement Baseline (PMB) in the same way the Planned Value (BCWS) is part of the PMB. The TPMs use the techniques of risk analysis and probability to give program managers the early warning needed to avoid unplanned costs and slippage in schedule. Systems engineering uses technical performance measurements to balance cost, schedule, and performance throughout the life cycle. TPMs compare actual versus planned technical development and design. They also report the degree to which system requirements are met in terms of performance, cost, schedule, and progress in implementing risk handling. The 5 Immutable Principles of Project Management 32/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Risk Management means using a proven risk management process, adapting this to the project environment, and using this process for everyday decision making. Technical performance is a concept absent from the traditional approaches to risk management. Yet it is the primary driver of risk in many technology intensive projects. Cost growth and schedule slippage often occur when unrealistically high levels of performance are required and little flexibility is provided to degrade performance during the course of the program. Quality is often a cause rather than an impact to the program and can generally be broken down into Cost, Performance, and Schedule components. The framework shown here provides:  Risk management policy.  Risk management structure.  Risk Management Process Model.  Organizational and behavioral considerations for implementing risk management.  The performance dimension of consequence of occurrence.  The performance dimension of Monte Carlo simulation modeling.  A structured approach for developing a risk handling strategy. The 5 Immutable Principles of Project Management 33/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved It does no good to manage risks if the results are not communicated to all the participants. Risk communication is the basis of risk mitigation. This plan needs to address the following:  Executive summary – a simple summary of the program and the risks associated with the activities of the program. Each risk needs an ordinal rank, a planned mitigation if the risk is active (a risk approved by the Risk Board), and the mitigations shown in the schedule with associated costs.  Program description – a detailed description of the program and the risk associated with each of the deliverables. This description should be “operational” in nature, with the consequences description in “operational” terms as well.  Risk reduction activities by phase – using some formal risk management process that connects risk, mitigation and the Master Schedule. The efforts for mitigation need to be in the schedule.  Risk management methodology – using the DoD Risk Management process is a good start. This approach has proven and approved by high risk, high reward programs. The steps in the processes are not optional and should be executed for ALL risk processes. The 5 Immutable Principles of Project Management 34/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Risk Management is a full time effort. Even if it is a part-time job. Someone needs to “own” the risks and the process around risk management. Someone or a collection of “someone's” needs to have risk management in their mind(s) at all times. Risk Management is not something you can do once and them forget. The risks don’t just go away. They are forever there, even if they are mitigated, retired or bought down. The 5 Immutable Principles of Project Management 35/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we ignore the fundamental statistical nature of project work, we are creating risk. This risk comes not from the underlying probabilities, but from our ignorance of this process. We believe, wrongly, that our estimates are static point values – a single number representing the estimate. We fail to take into account the statistical processes that drive this number. Durations, costs, technical performance. When we fail to make these variances visible we are managing our project with a “head in the sand,” just like this guy. 36/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Many speak about risk management as part of the project management process. But do they do risk management as part of the project management process? Test yourself and anyone who claims to be doing risk management The 5 Immutable Principles of Project Management 37/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So let’s look for some impediments in our project to fly to the moon. There are many of course, but let’s see if we can come up with some that are not so obvious. The 5 Immutable Principles of Project Management 38/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Measures of progress are one of the difficult topics in project management. Typically we measure progress by the consumption of resources and the passage of time. We talk about “budget,” being “on budget,” being “over budget.” We talk about the passage of time. “We’re on schedule,” “we’re late,” “our schedule is slipping.” These are all necessary things to talk about. But they are not sufficient for our project’s success. The 5 Immutable Principles of Project Management 39/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Performance measurement is the comparison of actual performance against an integrated baseline plan consisting of integrated cost, schedule and technical goals. The baseline used for performance measurement should be a single, integrated plan, because the analysis of cost performance must include schedule considerations and the evaluation of schedule performance must include technical performance considerations. Given a project where some tasks are on schedule, some are ahead of schedule and some are behind schedule, overall project status is virtually impossible to determine. It is no wonder that many project managers are literally “flying by the seat of their pants” without a good feel for where the project stands at any given point in time. A systematic, organized process for collecting performance information and presenting it in a clear manner on a regular basis is essential to the project management process. The 5 Immutable Principles of Project Management 40/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved With the information from the previous 4 irreducible principles, we now need to confirm we are making progress. The key principle here is “planned progress.” We must pre-define what progress we must make at any specific point in the project, otherwise all we can determine is the passage of time and the consumption of money. Preplanning the progress is the basis of “performance based” measurement for both project processes and technical products. Like Kent Beck’s (eXtreme Programming) advice we need feedback on our progress. There is only one kind of feedback for projects – measures of physical percent complete. No soft touchy feely measures of progress. No hand waving measures. Physical, tangible evidence of progress. Something that can be physically shown to the customer. Something that is compliant with the planned technical outcomes at this point in the plan. Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as well with the Integrated Master Plan and Integrated Master Schedule. So looking at two extremes of the spectrum – one a software development method and the other a mega-program procurement method. Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.” The 5 Immutable Principles of Project Management 41/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved For successful measurement of progress in a project we need to have:  Tangible evidentiary materials measure progress to plan.  Pre–defined existence of this evidence in meaningful units of measure established before starting work.  Progress is defined in these same units of measure. The 5 Immutable Principles of Project Management 42/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved There are many opinions about measuring progress to plan. Here’s what some authors have said. The 5 Immutable Principles of Project Management 43/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Let’s talk a bit about a common fallacy in the project management world. The notion of the “iron triangle” has fallen into disrepute lately. We all should know about the iron triangle. It connects cost, schedule, and quality – or some 3rd element in place of quality. Actually the variable in place of quality is “Technical Performance Measures” (TPM). Technical Performance Measurement (TPM) is a technique for predicting the future value of a key technical performance parameter of the higher- level product based on current assessments of products lower in the system structure. Continuous verification of actual versus anticipated achievement of technical parameters confirms progress and identifies variances that might jeopardize meeting a higher-level end product requirement. Assessed values falling outside established tolerances indicate the need for management attention and corrective action. A well thought out TPM program provides early warning of technical problems, supports assessments of the extent to which operational requirements will be met. The 5 Immutable Principles of Project Management 44/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we say “project management” we have to say “management” in terms of measuring progress to plan. The question is how to measure progress to plan? How do we define what the planned progress “should” be, what actual progress we made to date, and how much work there is to go? With the remaining progress to go, what should or pace be to arrive at the end of the project at the planned time? The 5 Immutable Principles of Project Management 45/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Pulling essential cost, schedule and technical performance information together in a meaningful, coherent fashion is always a challenge facing the project manager. If this cannot be done, management information will be fragmented, will not contribute effectively to project management, and may actually mislead the manager by presenting a distorted view of project status. Performance measurement is the comparison of actual performance against an integrated baseline plan consisting of integrated cost, schedule and technical goals. The baseline used for performance measurement should be a single, integrated plan because the analysis of cost performance must include schedule considerations and the evaluation of schedule performance must include technical performance considerations. Performance measurement is the art of determining, organizing, and presenting cost, schedule and technical performance information in a way that contributes to making those tradeoffs. It is a systematic, organized process for collecting performance information and presenting it in a clear manner on a regular basis. The 5 Immutable Principles of Project Management 46/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved We hopefully have all heard the term “earned value,” and maybe even seen the term in use. Here is the cheat sheet for the Earned Value variables and the formulas used to calculate the indices needed to manage a project using Earned Value. We won’t get into the details of EV. But EV is one of the best measures of project performance available. Is straight forward to apply. Provides credible forecasts of future performance and has natural connections to Scrum and some other agile software development methods. The 5 Immutable Principles of Project Management 47/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved The use of Earned Value, Earned Value Management, with an Earned Value Management System connects cost and schedule into a performance measurement system. The cost and schedule performance indices are used to forecast future program performance in the presence of unchanged technical performance. By using Earned Value in conjunction with probabilistic risk analysis of cost, schedule, and technical performance measures, a forecast of future cost and schedule impacts can be made. The primary motivation for earned value is to stimulate action on the part of the project or program manager to make changes that will alter the course of performance and bring the project or program into conformance with the value proposition as defined in the charter. 48/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved There are some other motivations as well:  Earned Value tools help the project manager measure and assess the accumulation of value throughout the project implementation.  The purpose of earned value is to give the project manager information sufficiently early so poor performance can be corrected before it impacts the value performance of the project.  Cost centric earned value systems are robust measures of project performance in the measurement system are in place to provide the necessary data for analysis.  Time centric earned value systems are a substitute for cost centric systems when the cost collection measures are not available. Managing Projects for Value, John Goodpasture, Management Concepts, 2002. 49/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Performance measurement is the comparison of actual performance against an integrated baseline plan consisting of integrated cost, schedule and technical goals. The baseline used for performance measurement should be a single, integrated plan, because the analysis of cost performance must include schedule considerations and the evaluation of schedule performance must include technical performance considerations. Given a project where some tasks are on schedule, some are ahead of schedule and some are behind schedule, overall project status is virtually impossible to determine. It is no wonder that many project managers are literally “flying by the seat of their pants” without a good feel for where the project stands at any given point in time. A systematic, organized process for collecting performance information and presenting it in a clear manner on a regular basis is essential to the project management process. The 5 Immutable Principles of Project Management 50/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved If we’re going to be successful measuring performance of the project, we must have tangible measures of progress. These means the evidence must be defined upfront, so we can recognize it when it arrives. If we don’t define the evidence up front, then we fall victim to the “emergent” measure of progress. Or worse, progress is what we have done this week. The units of measure of progress must be meaningful to the project participants. Numbers and statement of progress are of no value if we can’t make decisions with this information. The 5 Immutable Principles of Project Management 51/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved When we use traditional forecasting based on cost and schedule adherence, we ignore the “technical performance” of the product we’re building. We’re on schedule, we’re on budget, the thing we’re building doesn’t work exactly as we had planned. So how can we be on-schedule and on- budget? We can’t. We’re driving in the rearview mirror. This can be done, but you usually run over something stinky. The 5 Immutable Principles of Project Management 52/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved We need a way for forecasting the future performance of the project, from it’s past performance. The risk adjusted past performance. We need to drive the car by looking out the front windshield. Or in this case the windshield of the Shuttle. The 5 Immutable Principles of Project Management 53/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So let’s look at how we can measure progress to plan in a way that provides us with information about the future performance of the project. The 5 Immutable Principles of Project Management 54/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Since we visited the principles and done some sample exercises with the principles to get a feel of how they could be applied. Now we need to connect these principles with the practices. Here’s some examples how to make these connections. 1. The statement of where we are going doesn’t have to be complex. But it must address the details appropriate for the problem. 2. A Master Plan and Master Schedule show “how” we’re going to get there on-time, on-budget, and on- specification. 3. These Plans and Schedules, have all the needed resources defined and loaded into the Work Packages. 4. With this Plan and Schedule, we can now define the risks and their mitigations or retirement plans. 5. Finally we’ll ALWAYS measure progress as physical percent complete. There, now we’ve connected principles with practice. The 5 Immutable Principles of Project Management 55/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Project management means being able to state with confidence these any time someone asks you “how are you managing the project?” If you cannot say this with a straight face, then you need to take action to start to move in that direction. The 5 Immutable Principles of Project Management 56/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved There are also a few “laws of physics” for projects. The first is late starts mean late finishes. If you start late you’ll likely finish late if you don’t have schedule margin. How much schedule margin is needed? Good question. There are ways to find out. Some fancy some simple. But for sure if you have no margin and you start late you're late. Same goes for budget. While we said before we need to measure progress as physical percent complete, the units of measure must be meaningful to the stakeholders. As an undergraduate physics major we used to play a joke on our TA – which I got back in spades a few later when I was a TA. The joke in classical mechanics is to do all the calculations in the right units of measure – Standard International (SI) units. Then convert those to olde English measures. Volume in cubic meters can be converted to Hogs Heads. Or kilometers per hour to furlongs per fortnight. So we need to consider what the stakeholders really want to know. This turns into a metrics problem and is outside the scope of this brief talk, but it must be addressed if you’re really managing the project. But as the bullet says – time and money – are good starting points. Finally a universally applicable principle is to never confuse effort with results. The customer paid for results. The 5 Immutable Principles of Project Management 57/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So now we can understand that we need all three measures Cost, schedule, and technical performance to establish the basis of credibility. Each measure must be statistically adjusted for its particular probability distribution. Each measure must have a model of how it interacts with all the other measures. Each measure must describe the work processes that are used to increase the maturity and therefore the probability of program success. A simple static model the program is not credible. A dynamic model is the beginning of this credibility. The 5 Immutable Principles of Project Management 58/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So what happens if we don’t get all these principles put into practice. We tried really hard, but didn’t make it. What happens is you reduce the Probability of Project Success (PoPS). How much, depends on the project. What are the impacts, depends on the project. But why do it. Why not make every attempt to do it right? The 5 Immutable Principles of Project Management 59/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved So we’ve arrived at the end of our short time here. What did we learn? There are 5 immutable principles of project management, no matter the project domain and context. We need to confirm are project is applying these principles, and look for the evidence in the form of practices for each principle. Hopefully I’ve conveyed the notion that project management is not the same as product development. Both are needed, some times more than the other depending on the context and the domain. If I’m building a web site I approach the project management and development method differently than if I’m building the terminal guidance control software for an autonomous Mars Lander The 5 Immutable Principles of Project Management 61/62

Copyright ® 2010, Lewis & Fowler, All Rights Reserved Here’s my contact information. If you have questions that weren’t answered here, would like a soft copy of this briefing or any others from today or last night’s PMI Chapter meeting, please drop me a note. The 5 Immutable Principles of Project Management 62/62

http://herdingcats.typepad.com	536
http://www.google.com	1
http://translate.yandex.net	1

Immutable principles of project management (fw pmi)(v4)

by Glen Alleman on Jul 25, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 538

Statistics

Immutable principles of project management (fw pmi)(v4) — Presentation Transcript