Successfully reported this slideshow.
Your SlideShare is downloading. ×

5 immutable principles webinar

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Thank you for attending our webcast today.
This topic should be one we all are familiar with, since it is nearly impossibl...
Nearly every business activity is based on a project in some way.
Even the operational aspects of a business are projectiz...
I’m going to present 5 Immutable Principles today that are the foundation of
project success.
These Principles are “Immuta...
Advertisement
Advertisement
Advertisement
Advertisement
Loading in …3
×

Check these out next

1 of 24 Ad

5 immutable principles webinar

Download to read offline

This is a familiar topic to all in the project management business. We usually start our project management quest with capturing requirements, building a schedule to deliver them, executing that schedule, and making adjustments along the way when we’re not staying on schedule.

This is a familiar topic to all in the project management business. We usually start our project management quest with capturing requirements, building a schedule to deliver them, executing that schedule, and making adjustments along the way when we’re not staying on schedule.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to 5 immutable principles webinar (20)

Advertisement

More from Glen Alleman (20)

Recently uploaded (20)

Advertisement

5 immutable principles webinar

  1. 1. Thank you for attending our webcast today. This topic should be one we all are familiar with, since it is nearly impossible to not have experienced a project failure at least once in our career. We usually start our project management quest with capturing requirements, building a schedule to deliver them, executing that schedule, and making adjustments along the way when we’re not staying on schedule. The principles I’m going to speak to you about are universal. Applicable to any project, of any size, in any domain. What you’re going to hear is not the solution to avoid project failure. It is the framework for project success. The actual mechanics of managing a project are based on these principles. The practices used in this management should be based on the se principles. And of course the process ad tools should implement the practices. 5 Proven Approaches for Mitigating Project Failure Page 10:44
  2. 2. Nearly every business activity is based on a project in some way. Even the operational aspects of a business are projectized through processes, procedures, and business management governance. Today I’d like to focus on the types of projects Land speaks of. The really important ones that are nearly impossible. I was a participant in one of those projects – Rocky Flats Environmental Technology Site. The name of the site was a nice marketing term for the cleanup of a nuclear bomb factory. It was nearly impossible. And manifestly important The previous contractor had spent $4B and not done much. When Kaiser-Hill (a joint venture between ICF Kaiser and CH2MHill) won the contract for $7B, they had a plan that was dramatically different from the past attempts to cleanup and close the site. This plan focused on applying the 5 Immutable Principles, defining the “packages of work” that delivered the outcomes, measuring progress as physical percent complete, and risk adjusting everything to produce a credible Estimate to Complete on a weekly basis for 5,000 staff working on site. Page 21:06 5 Proven Approaches for Mitigating Project Failure
  3. 3. I’m going to present 5 Immutable Principles today that are the foundation of project success. These Principles are “Immutable” because they must always be present. They are the foundation on which the Practices and Processes are built. We won’t look at the Practices and Processes, but they are critical to the success of any project as well. Those are available in the book from AMACOM. Page 30:20 5 Proven Approaches for Mitigating Project Failure
  4. 4. There are nearly unlimited reasons for project failures. Root Cause Analysis is the means to separate the symptoms of project difficulties from the actual causes of those difficulties. If the Root Cause is not found, prevented or corrected, it will reappear. This is a short list of Root Causes. You’ll likely have your own list, but I suspect it will overlap with these. 4 5 Proven Approaches for Mitigating Project Failure
  5. 5. With this background, let’s start with the 5 Immutable Principles of Project Success. I would suggest these are applicable in any technical domain. Any project management method. Any business domain. They are universal and Immutable – meaning they don’t change over time. They are permanent principles that must be applied for the success of any project. The Principles are in the form of questions in this example. There are more formal statements about the Principles, but starting by asking 5 questions shows how the principles can be applied in any situation. When there is not a credible answer to the question, this is an indication there is likely trouble on the project and the probability of success has been lowered. Page 50:40 5 Proven Approaches for Mitigating Project Failure
  6. 6. With the Principles and Practices, we need Processes to put to work. Some of you may recognize these as part of the Earned Value Management processes in EIA-748-C. But there are also the basis of all good project management work. You really can’t be managing a project – in any credible manner – if you are doing these 11 processes. • What are we building? • Who’s on our team? • Who’s doing what? • What’s the sequence of the work? • What are the outcomes of that work? • What’s the budget for the work to produce those outcomes? • What did it cost to produce each outcome? • What was the difference between our budget and the actual costs? • What’s the total differences for the entire project? • What are we going to change to get back on budget and schedule? • Did we record these changes? 6 5 Proven Approaches for Mitigating Project Failure
  7. 7. We keep using the term Deliverable. Here’s what that means. It means the customer bought something they can put to work to fulfill a business case or accomplish a mission. The deliverables, taken individual are just individual functions of the project. Taken as whole, they provide a set of capabilities that can be used by the customer to accomplish something. Along the way, each deliverable increases the maturity of the projects capabilities. We can start with a few deliverables. The customer may or may not be able to accomplish something with those deliverables, but their presence may be necessary for further deliverables to provide a capability. There is a myth in the agile development business, that Value products need to be delivered starting on day one. This may be appropriate for simple projects. But most complex systems have pre-conditions for success. We need to install the Database Server before we can use build databases. We have foundation activities on which we build other capabilities. So the challenge is to determine the order of the needed capabilities to reach the needed maturity at the time that maturity is needed 7 5 Proven Approaches for Mitigating Project Failure
  8. 8. So let’s revisit our 5 Immutable Principles once more with the Practices and Processes in hand. • What does our customer need to fulfill their business case or accomplish their mission? • What are the technical and operational requirements that must be delivered to fulfill that mission? • What’s the schedule for that work? • How are we going to measure progress to plan? • What impediments are we going to encounter along the way and how are we going to deal with them, so they don’t impact the success of our project? This is the basis of Capabilities Based Planning. It’s the capabilities that are delivered. These are enabled by through the deliverables appearing tin the right order, fulfilling the right requirements, each building on the previous requirements and capabilities. 8 5 Proven Approaches for Mitigating Project Failure
  9. 9. Traditional project management is a good foundation for all project work. Performance-Based Project Management® adds another paradigm to that foundation – we measure progress to plan in terms of performance outcomes. This separate Output (effort, cost, deliverables) from Outcomes (the capability to do something needed for success). Performance-Based Project Management® is risk based, from Tim Lister’s advice Risk Management is How Adults Manage Projects. 9 5 Proven Approaches for Mitigating Project Failure
  10. 10. Here’s how to assemble the Practices to increase the probability of project success. This is a simple diagram, showing the order of work. • Answer the question Why Do We Need This – by defining the needed capabilities. If you start with requirements, you may or may not know why those requirements are there. What there purpose is. These capabilities have Measures of Effectiveness. • Identify the requirements that produce the capability to do something. These requirements have Measures of Performance. • Layout all the work in the right sequence – this can be an agile sequence, with current releases, future release, sprints and the like. But knowing what capabilities we’ll need for project success is a Critical Success Factor, no mater what development method you use. • Execute that sequence of work and measure physical percent complete to plan. • Along the way, make sure you have all the risks identified, handled, and the results included in future planning processes 10 5 Proven Approaches for Mitigating Project Failure
  11. 11. So let’s move to the next step. Applying the Practices and Processes 11 5 Proven Approaches for Mitigating Project Failure
  12. 12. The first Principle is to assure we know what Done looks like. This sounds like a simple process. But turns out to be the root cause of most project failures. Done is not described in any meaningful units of measure for the decision makers. Our first response is usually to make a list of features and functions for the product or service produced by the project. This is necessary but far from sufficient to describe Done. We don’t know how these features and functions interact, how and when they provide value to the customer. The interdependencies are next. We need to show how each feature or function is dependent – if it is – on other features and functions. This usually starts with the Work Breakdown Structure (WBS) showing all the deliverables from the project. The WBS needs a WBS Dictionary to show how we are going to measure the performance, quality, compliance of these outcomes with each other and the customer. But the WBS and its Dictionary are not enough to know what Done looks like. We need to know what Capabilities are being provided by the project. What is the customer going to DO with these outcomes? How are they going to satisfy the business needs or mission? The Capability to do something is what the customer bought. Page 121:08 5 Proven Approaches for Mitigating Project Failure
  13. 13. These Capability statements are clear and concise. Long before we ever arrived in the moon, Robert Goddard knew what capabilities were needed to get there. On October 19, 1899, Goddard climbed a dead tree to trim some branches. He was 17. He is quoted as saying … “I imagined,” he later recalled, “how wonderful it would be to make some device which had even the possibility of ascending to Mars, and how it would look on a small scale, if sent up from the meadow at my feet. . . I was a different boy when I descended the tree from when I ascended, for existence at last seemed very purposive.” He had in his mind what capabilities were needed to fly outside the Earths atmosphere. He knew some of the units of measure that had to be fulfilled to do this. If we don’t have some vision of the project at the Capabilities level, we really can’t say what Done looks like. We can describe the technical aspects, but we can’t say what we are going to do with those technical aspects. This definition of Capabilities is a Systems Engineering role. There are formal processes to elicit these Capabilities through the Concept of Operations, Scenarios, and Use Cases, making tradeoffs between cost, risk, schedule, and technical performance, and balancing all the feasible alternatives. The result is the Measures of Effectiveness which tell the customer the project will meet the needed capabilities. Page 131:15 5 Proven Approaches for Mitigating Project Failure
  14. 14. With the needed Capabilities we can now develop a plan and schedule for the work. Knowing how to get Done on–budget and on–schedule means knowing what requirements will have to be fulfilled. Poorly formed requirements contribute as much as 25% to the failure modes of programs and projects. This starts with Fact Finding, Gathering and Classifying the Requirements, Evaluating and Rationalizing the Requirements, Prioritizing them, and Integrating and Validating the Requirements. With this in hand we can start building the packages of work that implement the requirements. The result is a Plan and a Schedule. The Plan is the Strategy for the proper delivery of the Capabilities produced by the project. The Schedule is the sequence of work needed to implement the Strategy. Both are needed. The Plan is emergent, since it is a strategy. The Schedule tests this strategy on short term boundaries, with measures of physical percent complete. Both the Plan and the Schedule must be capable of responding to change as new information about requirements, program performance, and risks emerge. But the needed capabilities should remain stable if we are to have a baseline on which to execute our project. Page 141:05 5 Proven Approaches for Mitigating Project Failure
  15. 15. The Plan can be very simple or it can be complex. Here’s a plan that took us to the moon and back. This picture shows a simple concept. Build the launch vehicle, the fuel to power it, the space craft on the top, train the astronauts, do the testing, and fly. The Plan shows the 6 major systems , their approximate duration in years, and the dependencies between them are all that is needed to confirm the feasibility of the project. Notice the longest activity is the training of the crew. No one had ever flown in space before all the way to the moon and back. So training was high risk and critical to success. Page 150:35 5 Proven Approaches for Mitigating Project Failure
  16. 16. One view of the Plan is the vertical integration of the deliverables. This is the deliverables traceability view. At the bottom is our deliverable. The deliverable is produced by work contained in a work package. A Work Package says its name. it produces a single outcome. The technical capabilities needed for the project’s success are produced by the Work Packages. Finally these Technical Capabilities produce business or mission capabilities needed by the customer for project success. This traceability is necessary for a credible Plan and Schedule. It is also necessary for a credible project delivery process. This traceability tells everyone what Done looks like and how we are going to get there. Page 160:35 5 Proven Approaches for Mitigating Project Failure
  17. 17. With the Plan in place and the “packages of work” identified in the Schedule, we can construct a picture of how we are going to reach Done. This picture is not like the typical horizontal scheduling activities we see in all the scheduling tools. This picture starts with the vertical integration of the deliverables as they progress through their maturity life cycle. This is called the Integrated Master Plan. This Plan shows the Measures of Effectiveness and Measures of Performance we need to achieve to reach a specific level of maturity. This notion of levels of maturity can be seen is we use some words Preliminary is a work. We all know what preliminary means. It means we’re not done yet. We have a preliminary design, we have a preliminary cost estimate, or a preliminary list of subcontractors. We know enough about the project to make some decisions, but we need more details before we can say for sure the cost, the design, and the subcontractors are all in place. This incremental approach allows us to move foreword without all the details, while still having visibility into what Done looks like. Since many projects are discovery driven, planning needs to be increasing maturity driven without the planning horizon. Page 171:08 5 Proven Approaches for Mitigating Project Failure
  18. 18. Projects are executed by people. People consume time, money, and materials. How can we know if we have enough of everything we need for success? We need a Plan of course, in this case a Resource Management Plan, showing people, funding, and materials, and when and where we need it. We can start with a simple list. This gets us to write it down. Next we need to assign people and money to the needed resources. How many of each special skill type will we need for this project. In the end though, we need to lay out these needs against the schedule of work. We need to resource load the schedule. This sounds like a lot of work and it is. But without this in place we really have no idea if the project is feasible. Page 180:40 5 Proven Approaches for Mitigating Project Failure
  19. 19. We usually start by identifying risks. But risk is the result of uncertainty. There are two types of uncertainty – reducible uncertainty and irreducible uncertainty. We can do something about reducible uncertainty. We can buy more knowledge about this uncertainty – it is epistemic. We can run tests, build prototypes, look at what others have done. The risk that results is reducible. The irreducible uncertainty is part of the world around use. This uncertainty cannot be reduced – it is Aleatory uncertainty. The only way to deal with this uncertainty is through margin. Cost margin, schedule margin, technical margin. We have to start by identifying these uncertainties and associating them with the risks. Then the impacts of the risk are identified along with their dependencies. The probability of occurrence and the probability of their impact can be assessed. With these impediments in hand we can take actions to either protect our project with margin or spend money to retire or handle the resulting risk. Page 190:57 5 Proven Approaches for Mitigating Project Failure
  20. 20. With our Plan, Schedule, Resources, and Risk Management Plan, we can now determine how we are going to measure progress to these plans. The customer bought outcomes, deliverables, capabilities. We need to describe these in a way the customer understands. Units of measure that are meaningful for making decisions. These are best described as Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal But these alone are not sufficient for the success of the project. We need Measures of Effectiveness (MoE), Measures of Performance (MoP), and Key Performance Parameters (KPP). MoEs are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. MoPs characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. KPPs represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. Page 201:09 5 Proven Approaches for Mitigating Project Failure
  21. 21. If we don’t have a plan. If we don’t have the proper resources available at the needed time. If we don’t handle risks if we don’t have measures of physical; percent complete. We can’t have confidence the project will be successful. Without these elements, the probability of project success is reduced. Possibly to the point of project failure. Without these elements, we have created risk to our success with no handling plans. It is this unmitigated risk that creates the unanticipated growth in our Estimate At Completion. Page 210:29 5 Proven Approaches for Mitigating Project Failure
  22. 22. Over a large number of complex, high risk programs there have been a small number of root causes discovered for failure. There are shown here. Reading them they seem obvious. Dealing with them is more difficult . But we must deal with them and we must have information needed to deal with them. This information comes from the tools and processes used to manage the project. Scheduling, cost, risk, performance measurement, and forecasting tools and the processes used to apply them. Only when all this information, integrated though a single “lens” can we have the needed visibility to take corrective action to keep the project GREEN. Stay on schedule, stay on budget, comply with the technical requirements. Or if not, know about the variances soon enough to take corrective action. Page 220:41 5 Proven Approaches for Mitigating Project Failure
  23. 23. Let’s quickly review the 5 principles of project success in the time remaining. What does done look like? The customer needs to know what capabilities will be possessed when the project is done. The capabilities produce the business value or fulfill the mission objective. How do we get there? We need a plan and a schedule. We need to sequence the work properly in the order to produce continuous value. Are there enough resources? People, material, facilities? Are they the right people, does the material arrive at the needed time, are the facilities adequate to produce the needed outcomes? What are the impediments to progress? Risk management is how adults manage projects. Do we have a risk register? Do the risks have handling plans? Is the cost and schedule baseline adjusted for these risks? How do we measure progress? The only way is tangible evidence of physical percent complete. This means “show me” the outcomes and show me they meet the specifications, on the planned day for the planned cost. If not we’re late, over budget, and out outcomes probably don’t work right. Page 230:57 5 Proven Approaches for Mitigating Project Failure
  24. 24. 24 5 Proven Approaches for Mitigating Project Failure

×