Immutable Principles Of Project Management (V7 Final Cmu)


Published on

Published in: Business, Technology

Immutable Principles Of Project Management (V7 Final Cmu)

  1. 1. I’d like to thank Martin for inviting me again to speak to you about project management.  My contribution is from the point of view of a program manager in the aerospace and  defense business, rather than a software development manager. 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. 1
  2. 2. 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, you are not answering  the questions from these irreducible principles, you re probably doing project  the questions from these irreducible principles, you’re probably doing project  management and your project is in jeopardy and you may not know it. 2
  3. 3. 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 this 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. There  must be present in some form no matter the software 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 to 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  tec ca capab t es t at a e ess t a p a ed technical capabilities that are less than planned. 3
  4. 4. As a framework for defining the process areas of a software development project, CMMI  DEV V1.2 is a good starting point. Not that we are suggesting CMMI DEV be applied to your projects, just that if we need a list  of the processes that should be found on a project, this is a one. Note that the Engineering Process Areas are where software development activities are  found. There are other process areas in the CMMI model, needed for project success. 4
  5. 5. Colorado Springs PMI Risk Management in Five Easy Pieces Colorado Springs, Colorado May 8th , 2008 The five irreducible principles of project management are: 1. Know where you are going by defining “done” at some point inf 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. a ust be easu ed u ts o p ys ca pe ce t co p ete 5
  6. 6. When we speak about project management in the context of product development or  service providing, we apply these 5 questions to the “project” as a whole. Ignoring for a  minute the development method used to actually produce the product or the service. If we start with the method, then we will miss the critical success factors for the project  and focus on the means rather than the end. 6
  7. 7. 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 to cost  an schedule. And most importantly the interactions between the requirements can be  an 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 component (if you  can call them that) arrange 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  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 buildings housing the “battle space management command.” Software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. Soldiers can’t o  their job – BIG PROBLEM. 7
  8. 8. 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  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  o t e p e ous page to t e c ed y co p e p og a a so s o o t e p e ous page. The SCRUM method is shown in its common diagram. But below it is the method used for  product development 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. While few here – I’ll assume work in the  DoD 5000.02 context, there are direct connections between SCRUM and this approach. 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. 8
  9. 9. No 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  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  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. 9
  10. 10. There are many phrases about managing in the presence of risk. Tim Lister’s is a good one. Another is Kent Beck’s Optimism is the disease of software development, feedback is the cure. Getting feedback is built into Scrum. It is also built into DoD 5000.02. The two opposite  ends of the development method spectrum – both share the same core values. 10
  11. 11. If risk management is how adults manage projects, here are some principles (sub  irreducible principles) of project 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 cultural. 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  S g e po t est ates a e o bette t a 50/50 guesses t e abse ce o o edge o 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 processes that you can make up as you go. A formal  foundation for risk management is needed. 5. Identifying risks without communication them is a waste of time. 5 Identifying risks without communication them is a waste of time 11
  12. 12. 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 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. Sc u does t s by p ede Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as  g t e outco es o t e te at o o 5000 0 does t s as well with the Integrated Master Plan and Integrated Master Schedule. So looking 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.” 12
  13. 13. Project management means being able to say these any time someone asks you “are you  managing the project?” If you can say this with a straight face, then you need to take action to start to move in that  direction. 13
  14. 14. So let’s look at how these 5 irreducible principles can be connected to some software  development methods. I’ve picked 4 development methods that I’ve familiar with and used on real projects. For agile, I’ll assume the usual suspects – Scrum, XP, Crystal, DSDM. These all have  methods, very formal methods by th way, of capturing what the customer wants to have  done, planning that work – using a time boxed, level loaded staffing profile. The  measurement of progress is again time boxed with the notion of “velocity” used to forecast  the next period of performance. Just as an aside “velocity” is a unitless measure and not  tied to any actual business metric, money for example. There is literature in CrossTalk about connecting Agile with Earned Value. I’ve presented papers and so has Paul Solomon  – Performance Based Earned Value and the former EVM Director on B‐2, about EV and  agile. it is a “must read” set of papers. The IMP/IMS method is a DoD planning, scheduling, cost management, and technical  performance management method that can be applied to every project. Agile shares many  f t th d th t b li d t j t A il h of the attributes with IMP/IMS.  RUP has formal and informal processes that cover all 5 of the principles and of course  Prince2 does as well So if your only speaking about software development methods then the principles can be  covered. But of course you’ll be missing the other non‐irreducible measures of project  management. But that a story for another time t B t th t t f th ti 14
  15. 15. After discovering 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 the time 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. 15
  16. 16. 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  bl di t id th f thi b i f t lk b t it t b dd d if ’ ll 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.  16
  17. 17. So we’ve arrived at the end of our short time here. What did we learn? There are 5 irreducible 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 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 build the terminal guidance control software for an autonomous Mars  Lander 17