Immutable principles of project management

Copyright ® 2012, Glen B. Alleman, All Rights Reserved All projects are disappointments. That’s 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 didn’t 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 management 1/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved The five immutable principles of project success 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 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. In units meaningful to the decision makers.The 5 Immutable Principles of Project Management 2/36

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. 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 3/36

Copyright ® 2012, Glen B. Alleman, 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 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.  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 4/36

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 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 5/36

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 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 6/36

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 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 7/36

Copyright ® 2012, Glen B. Alleman, 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, 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 Management 8/58

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 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 handling 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 9/36

Copyright ® 2012, Glen B. Alleman, 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. The 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 to 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 everyone’s time.The 5 Immutable Principles of Project Management 10/36

Copyright ® 2012, Glen B. Alleman, 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 11/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Performance measurement is the comparison of actual performance against an integrated baseline plan consisting of the 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. And therefore a critical success factor for the project itself.The 5 Immutable Principles of Project Management 12/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved For successful measurement of progress to plan 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.  All units of measure must be meaningful to the decision makers.  The Technical Performance Measures must be traceable to the requirements, the capabilities and back to the Measures of Effectiveness (MoE).  MoE’s are how the customer measures progress. The customer didn’t buy the development environment, or even the code produced by the development environment. The customer bought the capabilities that the software implements. Or any product, not just software.  One example is the program of the Hubble Robotic Service Mission (HRSM). The customer Goddard Space Flight Center bought the capability to fly to Hubble, do not harm to the telescope, change the Wide Field Camera, and connect the umbilical cord of th external batteries latched to the towel bars on the ass end of the telescope.  That’s what done looked like, that’s what Frank Cepollina bought for his telescope.The 5 Immutable Principles of Project Management 13/58

Copyright ® 2012, Glen B. Alleman, 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 14/36

Copyright ® 2012, Glen B. Alleman, 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 15/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved When we say “project management” we have to say “management” in terms of measuring progress to plan. This is not always the first image of a Project Manager. Many times we think of a personnel coordinator, a facilitator, all those soft skills that are taught at the PM conferences. But at the end of the day, the customer has little concern about that. It is assumed that all that is handled. It is considered hygiene, part of the normal operations. The customer wants to know  When will you be done?  How much will it cost?  Will it work the way the customer wants it to work? With a good plan, a schedule, a description of the needed capabilities and related requirements, the needed resources to deliver on the requirements and all the impediments to progress identified and handling plans - 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? Without clear and concise answers to these question all the other aspects of project management are going to add little to the probability of success. This is the source of most project failures, the dreaded Death March of Ed Yourdon.The 5 Immutable Principles of Project Management 16/58

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Performance measurement is the comparison of actual performance against the planned performance in 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 17/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Project management means being able to state with confidence these phrases 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 18/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved All projects are over budget, behind schedule, and many times don’t deliver what was promised. This is the realm of projects. The BIG problem is when this comes as a surprise, when it comes too late to do anything about it, when there is no margin for schedule slips, cost over runs, or technical performance shortfalls. That’s when projects should be labeled as troubled. If you’re late but have schedule margin and use that margin to cover the lateness, then you’re not late. If you’re over budget but have contingency funds to cover your over budget condition, then you’re not really over budget, you just used your contingency. By The Way, Management Reserve is not the same as contingency, but that is another topic. You’re product doesn’t meet the 90th percentile of performance, but your design will still function if the product performs at the 80th percentile of the performance band on the first release. Without defining these margins, contingencies, performance bands up front, you’ll never know if you’re actually performing well or not. But most importantly, you don’t have a leg to stand on with your customer when you are actually late, over budget, and in a performance short fall. 20/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Here are 16 program management processes that must be in place for any business that depends on managing projects for revenue generation. For the moment we’ll only talk about 7 of these. Planning, measuring performance of the Plan, requirements, finance, earned value, scheduling and risk. 2. You need a plan to know where you are going. 3. You need some way to measure progress of that plan 6. Earned Value tell you how you can measure physical percent complete and with that forecast future performance. 7. Requirements tell you what things you need to produce to meet the plan. 8. You need a schedule of the work, how it will be performed, and what order it will be performed in. 9. Finance, so one has to fund your project and will be asking what you did with their money. 10. Risk is how adults manage projects 21/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved The 5 Immutable Principles of project success are based on 5 process areas of project management. The five process areas are the basis of Performance Based Management(sm), they are: 1. Identify the capabilities needed to fulfill the mission, vision, business case, or any other forward looking description of the project. 2. Identify the technical and operational requirements needed to enable the capabilities to be fulfilled. 3. Define the cost, schedule, and technical performance measures of the work activities needed to implement the requirements. 4. Determine how the work activities will be measured to assure their planned performance is being achieved. 5. Identify and handle the impediments to progress for the project. 22/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Capabilities are where the business value is. Capabilities drive requirements, but rarely do requirements by themselves have value to the business. The business wants a capability. A capability to do something with the outcomes of your project. There are lots of ways to implement a capability, so focus first on establishing a baseline set of capabilities before you start developing requirements and solving the perceived problems. Capabilities are what you would do with the resulting system. The business would put it to work making money, satisfying customers, running the business, running the products the business produces. If you don’t know want capabilities you need to produce from the project, you rally can’t talk about the business value, and therefore you really can’t speak about what DONE looks like in are meaningful way other than the passage of time and consumption of money. 23/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved The first step in identifying requirements that fulfill the needed capabilities is to separate “product” requirements from “process” requirements. The product could be a service as well, but the product (or service) is not the same as the process that delivers the service that may be enabled by the product. We can see there are several components of this separation. While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our efforts on important parts of requirements management, and reduce the overall effort of managing these requirements.Copyright © 2012 24/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved The Baseline of the project is actually three baselines: 1. The technical baseline assures that all the deliverables are identified. Even if the details are not know, the needed capabilities must be defined in some meaningful manner. Otherwise the project will have no way to control the scope. 2. The schedule baseline says when the needed capabilities will be available 3. The cost baseline says how much each of these capabilities is planned to cost. 25/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved When we talk about Plans and Schedule, we need to speak about outcomes in terms of needed capabilities and then speak about how we are going to produce those outcomes through “work.” The work that produces an outcome, produces a “Deliverable.” A tangible evidence that the customer has received a capability. This is the picture of the Integrated Master Plan and the Integrated Master Schedule. The Plan is needed first. It tells us what DONE looks like in terms of capabilities. What capabilities we’ll posses when the project is done. Most importantly it tells how the maturity of these capabilities evolves over time. The Integrated Master Schedule shows the packages of work that must be performed in a specific order to produce the needed capability. Both the Plan and the Schedule are needed. If you have the Plan without the schedule, then you know what done looks like, but not how to get there. If you have the schedule and not the Plan you cannot determine if your work is increasing the maturity of the desired capabilities. 26/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved With the Work Packages defined in the Integrated Master Schedule, shown below the line in the previous slide, the execution of the work is straight forward. So simple in fact, you just have to do the work in the order is says to do it. This sounds too simple of course, but this is where the Planning process pays off. Just like an Agile development process using sticky notes and iterations, the project agrees what work is going to be performed in what order – the iteration in the example of Scrum. Work Packages in the example here. It turns out that formal project management using Work Packages is very close to Scrum in many ways. 27/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Continuous Risk Management, when performed successfully, provides a number of benefits:  Prevents problems before they occur – identifies potential risks and deals with them when it is easier and cheaper to do so – before they are issues.  Improves product or service quality – focuses on the program’s objectives and consciously looks for things that many effect quality throughout the program lifecycle.  Enables better use of resources – allows the early identification of potential problems – proactive management – and provides input into management decisions regarding resource allocation.  Promotes teamwork – involves personnel at all levels of the program.Copyright, Glen B. Alleman 2012 28/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved No matter what method you are using for the management of your project, someone outside your project has an interest in how things are going. This interest is usually measured in units different from yours as a project manager or as a developer. Here are 11 critical activities needed to answer almost any question from anyone in your organization about how is it going? 29/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Performance Based Management(sm) method provides the tools, processes, and training needed to increase the probability of success of projects. This approach is unique in its integration of the critical success factors for projects, no matter the domain. This approach answers the following 5 immutable principles:  Where are we going? Do we have a definitive description of the needed capabilities and the requirements needed to deliver those capabilities?  How do we get there? What is the sequence of the work efforts to achieve the plan?  Do we have enough time, resources, and money to get there? Are the resources properly allocated to the sequence of work activities?  What impediments will we encounter along the way? Have we captured the risks and their handling plans for all the critical work activities?  How do we know we are making progress? Can we measure progress to plan in units meaningful to the decision makers?Copyright, Glen B. Alleman 2012 30/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Performance Based Management(sm) method provides the tools, processes, and training needed to increase the probability of success of projects. This approach is unique in its integration of the critical success factors for projects, no matter the domain. This approach answers the following 5 immutable principles:  Where are we going? Do we have a definitive description of the needed capabilities and the requirements needed to deliver those capabilities?  How do we get there? What is the sequence of the work efforts to achieve the plan?  Do we have enough time, resources, and money to get there? Are the resources properly allocated to the sequence of work activities?  What impediments will we encounter along the way? Have we captured the risks and their handling plans for all the critical work activities?  How do we know we are making progress? Can we measure progress to plan in units meaningful to the decision makers?Copyright, Glen B. Alleman 2012 31/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved With the principles and practices in place, the next step is to put them to work on your projects. This is a call to action. Start with agreeing to measure all progress to plan (you do have a plan right) with tangible evidence of physical percent complete. This means the phrase show me has to be used all the time. You have to define what done looks like in fine grained increments with pre- defined units of measure. Otherwise you’ll never recognize done when it arrives, if it arrives. Planning is a dynamic process that must deal with change, emergent situations. The planning horizon can not be further in the future than you have capabilities to manage. Otherwise your plan is bogus. You need a mission and a vision of what done looks like to guide your plan, to anchor your efforts. But don’t be fooled by plans that state outcomes beyond the horizon if you actually haven’t been beyond the horizon to see what it looks like out there. 32/36

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Now comes the part where all the soft skills come into play. You need to be ruthless about the 5 principles and the 5 processes, without appearing to be ruthless. This is where good project managers excel. I personally am not one of those people. I’ve grown up in the weapons systems business, with a prior military background, worked on large programs where people die if things go wrong. Or people die when things go right (Intercontinental Ballistic Missiles). But in many domains, IT being one, people skills are critically important. But these principles and practices are universal. In order to make them work though, the Project Manager must adhere to the principles first and the practices that result. 33/36

Copyright ® 2012, Glen B. Alleman, 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 LanderThe 5 Immutable Principles of Project Management 35/36

Here’s the five practices needed forsuccess with the five immutable principles.These practices are general purpose forall project domains and independent ofany development method.The five principles contain the activitiesneeded to implement the principle. Thereis of course much more detail needed. Butthis is a framework and not the step bystep methods, thats several 100 orepages of overview. 37

Here’s the next level down of 3 morelevels.The idea here is that increasing fidelity ofthe produced outcomes requiresincreasing fidelity of the processesneeded to produce those outcomes. Theygo hand in hand.For example to Identify NeededCapabilities, you just can’t say IdentifyNeeded Capabilities, there are 4majorsteps to do that1. Define capabilities as operational concepts, means a clear and concise definition of how the capability with be used in production. This is usually some narrative. I want to fly to Hubble and fix the wide field camera.2. Then we need scenarios or use cases describing all the activities that will take place while using this capability.3. Trade offs between needs, risks, and costs have to consider all the interactions. This is the Anlysis is Alternative (AoA) described in Systems Engineering.4. Then the actual trade offs must be performed. A trade space built where quantitative assessment can be performed. 38

Here’s another view of connectingthe Five Principles with the FivePractices while building the NeededCapabilties. 39

And another view.Multiple views of the same process andproblem are always needed. 40

For the IT world, here’s a way toassemble the deliverables basedplanning into a business process. 41

A way to show how capabilities candrive requirements and howcapabilities can be connected tobusiness benefits. 42

An example of a ProductDevelopment Kaizan for a spacecraft. 43

From the sticky note a Mind Mappingtool is used to capture the stuff onthe wall.From there this tool – MindJet – canproduce a schedule directly. You stillhave to hook up the work, assigndurations, and resources, but thetopology of the project – the ProgramArchitecture is captured during theKaizan process. 44

Another view of a Value Stream Map,showing how the maturity of products andservices move from left to right. 45

Time: 00 :00Total: 00:00 This is a picture of a Plan for the project. This is a real project. It is a health insurance claims processing system integration. It shows what capabilities we would like to have, the order of those capabilities, the preconditions for each capability, and the outcomes of each capability when it is available. This is the Integrated Master Plan. It is NOT the Integrated Master Schedule. But having this Plan is critical to developing the Integrated Master Schedule. If you look back to the early slides in this session you’ll see similar charts. People standing in front of a board of sticky notes were doing the same thing. The process lays out the “value flow” for the project. This is the mythical “value” spoken about in many Agile development processes. We can monetize the presence of a capability and assign that monetary value to a section of the business case. With this “value flow” we can identify the needed capabilities, the technical and operational requirements that must be in place to enable these capabilities and finally the “packages of work” needed to produce the solutions that meet those requirements.Glen B. Alleman, PMI Mile High Symposium, 2012 46/38

Time: 00 :00Total: 00:00 Using the topology from the previous slide, we can now see what the Plan looks like. The Data in Marts for ERP Ready is a capability needed by the business. This capability can be put to work. The business case can monetize this capability and we can connect our development efforts with the production of this monetized value. In order to arrive at this capability, we need several Significant Accomplishments: Billing is complete. Internal process complete. Data store look up complete. Data marts complete. Portals and others complete. Each of these Significant Accomplishments has a set of Work Packages (not shown here) that must be completed. The Exit Criteria of these Work Packages is called the Accomplishment Criteria. The Accomplishment Criteria, Significant Accomplishments, and the Milestones or Events that release the Capability are the Integrated Master Plan (IMP). The Work Packages and their internal Tasks, when placed in the right sequence are the Integrated Master Schedule. If we look back at the topology of the IMP and IMS, we now have the language needed to describe: What DONE looks like? How to get to DONE? What resources we need on the way to DONE? The impediments along the way? The measures of progress to plan? We’ll have answered the 5 immutable questions in a single integrated document – the Integrated Master Plan / Integrated Master Schedule.Glen B. Alleman, PMI Mile High Symposium, 2012 47/38

Time: 00 :00Total: 00:00 The perfect schedule has some attributes we need to understand before we start. The schedule tells us what DONE looks like in units of measures meaningful to the decision makers. This phrase units of measure meaningful to the decision makers will be at the heart of everything we do today. The schedule shows us what work needs to be done to produce the outcomes needed for the project to be successful. Actually it shows us the work that needs to be done that increases the probability of success for the project – since all project work is probabilistic. The schedule shows us what resources are needed to do that work. The schedule must show us what are the impediments to performing that work. What are the risks to the project’s success. And finally the schedule shows us how we are measuring the tangible evidence of progress to our plan. This evidence and these measures are usually not part of the traditional approach to scheduling. In that traditional approach, work is planned left to right, resources assigned – you do have a resource loaded schedule right?. And then that work is executed. What we’re going to learn today is that another paradigm is needed in order to increase the probability of success. This paradigm is called the Integrated Master Plan or IMP. The IMP is used – and many times mandated in large defense and NASA programs. But it is also found in Enterprise IT programs. Project like ERP.Glen B. Alleman, PMI Mile High Symposium, 2012 48/38

Time: 00 :00Total: 00:00 The critical understanding here is that all the activities in the schedule are probabilistic processes. All the numbers, duration, cost, technical performance are random numbers drawn from a probability density function – a probability distribution. If we don’t acknowledge this, we’ll be disappointed in ways we may not understand. We’ll be surprised when we are late and over budget. We’ll be surprised when the project starts to fail and we didn’t see it coming. We’ve all seen this, we’ve probably been on projects that behaved this way. We may have even been the Project Manager for a project like that. So we’re half way through our talk today and it’s time to start looking forward.Glen B. Alleman, PMI Mile High Symposium, 2012 49/38

Time: 00 :00Total: 00:00 Here’s the first look at connecting the dots for the perfect schedule. We’ll assume we have identified the needed capabilities, derived the requirements – all requirements are derived requirements by the way – and these requirements mapped to the Work Breakdown Structure terminal nodes and onto Work Packages. This WBS to Work Packages mapping starts in the upper left here. One Work Package for one outcome in the WBS. This is a critical success factor. If we have more than one outcome for each Work Package, we’ll have mixed apples and oranges when it comes to measuring Physical Percent Complete of the Work Package. With the Work Package, we can now define the work activities – the tasks – inside the Work Package that actually do the work. Here’s where we need to pay attention. Those tasks inside the Work Package are usually not on baseline. That is the schedule of the tasks is the responsibility of the Work Package Manager. The reason is that the sequence of Work Packages is what drives the perfect schedule. The Work Package Manager looks after resource assignments inside the Work Package, the order of the work inside the Work Package, and reporting the progress to plan inside the Work Package. Here’s the next piece requiring attention. The measure of progress for the tasks in the Work Package is measured as 0% or 100%. This may be new to many here today. But this is basis of the Earned Value Management guidance in most ANSI–748B System Descriptions. The details of the motivation are beyond this short time period, but here’s the best reason. 0%/100% is simple to measure – either you’re done or you’re not. Not opinion, not rationalization of the work effort. You finished the work in the task or you didn’tGlen B. Alleman, PMI Mile High Symposium, 2012 50/38

Time: 00 :00Total: 00:00 Here is the conclusion of todays talk. There are 8 steps to building a credible schedule Have a credible Work Breakdown Structure. This means all the outcomes of the project are in the WBS. What’s not in the WBS is the functional organizations (like QA, development, support), the functions (like design, code, test). Only things are shipped to the customer. The Project Events or Milestones. The places in the plan that a capability is produced or an assessment of progress in terms meaningful to the customer take place. The Significant Accomplishments needed to meet the success criteria of the Events. Define what needs to be done to provide a capability that can be put to use by the customer. The Accomplishment Criteria are the exit criteria of the Work Packages that contain the Tasks. State this criteria in measures of physical percent complete against the Technical Performance Measures, the Measures of Effectiveness, and Measures of Performance. The Work Packages say their name. They are Packages of Work that produce a single outcome. Determine the interdependencies between these Work Packages to minimize cost and schedule, maximize produced value, reduce programmatic and technical risk, and provide visibility to the decision makers. Resource load the Work Packages, assign all costs, and define risk handling strategies Update the schedule in the presence of risk, uncertainty, and past performance.Glen B. Alleman, PMI Mile High Symposium, 2012 51/38

An integrated program managementsystem has these components. 52

The notion of Technical PerformanceMeasures is critical to the success ofmeasuring physical percent complete.http://slidesha.re/iiRIw0 is a link to thePMI Technical Performance Measuresmaterials. 53

To put this all together the items in thepicture are needed. Only then can youhave a clear and concise of what Donelooks like, how to get there, how tomeasure getting there, and how thehandle the risks along the way. 54

Copyright ® 2012, Glen B. Alleman, All Rights Reserved Connecting principles with practice is a critical success factor for ay approach to increasing the probability of project success. Practices without principles provide the opportunity to modify the approach without understanding why. Principles without practices are interesting discussions without measurable business benefits. Both are needed, both must be present for success. But you most start with the principles, then move to the practices. Without the principles, there is no way to test the practices to confirm they are on solid footing when they need to be adapted to the situation. 55/36

Copyright ® 2012, Glen B. Alleman, 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 56/36

http://herdingcats.typepad.com	2814
http://feeds.feedburner.com	58
http://www.newsblur.com	9
http://prlog.ru	6
http://www.herdingcats.typepad.com	3
http://translate.googleusercontent.com	2
https://www.rebelmouse.com	2
http://feeds2.feedburner.com	1
http://www.thrivingonsystems.com	1
http://dev.newsblur.com	1
http://miclark	1

Immutable principles of project management

by Glen Alleman on Jul 04, 2012

Accessibility

Categories

Upload Details

Usage Rights

11 Embeds 2,898

Statistics

Immutable principles of project management Presentation Transcript