Establishing the performance measurement baseline (pmi fort worth)(v4)

8,908 views
8,841 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,908
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
204
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Establishing the performance measurement baseline (pmi fort worth)(v4)

  1. 1. Fort Worth PMI Symposium July 15th and 16th, 2010 Thank you all for coming to the work shop today. The title of the Work Shop title speaks about the Performance Measurement Baseline. This may be a new term for some of you. After our four hours today, I’m hoping it will be a term you'll be using back on your own projects. Let’s define what we mean at this point in the work shop. At the first slide. The Performance Measurement Baseline is a time-phased budget plan for accomplishing work, against which the project performance is measured. It includes the budgets assigned to scheduled work , their budget spreads, and the applicable indirect budgets. This budget plan is derived from a resource loaded Master Schedule. These resource loads, along with other information, are contained in Work Packages. You’ll hear many times the phrase “cost and schedule.” I want you to start thinking about what it sounds like when you say “schedule and cost.” It’s the schedule – the sequence of the Work Packages – that is the basis of the cost. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 1/62
  2. 2. Fort Worth PMI Symposium July 15th and 16th, 2010 This will be our agenda for the next four hours. We’ll have a quick survey of where we’re going, some background on the concept and then we’ll walk through the six steps needed to establish the Performance Measurement Baseline. The outcome of these six steps is an understanding of how to put the information to work on your projects. Along the way we’ll have hands on exercises that will demonstrate the processes and outcomes for each of the six (6) steps in building the Performance Measurement Baseline. Our exercises will define the PMB for a home toaster. It’ll be a nice toaster, but we’ll touch each of the steps in enough detail, that you’ll be able to replicate them on your real projects. So let’s get started. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 2/62
  3. 3. Fort Worth PMI Symposium July 15th and 16th, 2010 Here’s how we are going to build our Performance Measurement Baseline. It’s a simple process in principle. But of course in practice, it’s always harder in practice. We’ll use the exercises to pull out these practices from the principles, but let’s have a quick look first at the principles. 1. Build a Work Breakdown Structure. 2. Define the Work Packages that produce the deliverables at the terminal nodes of the WBS. 3. Arrange these Work Packages in some logical sequence. 4. Assign the resources needed to complete the Work Packages in a timely manner. 5. Turn this whole collection of information into a credible Performance Measurement Baseline (PMB). One final step is to perform the continuous risk management processes inside these five (5) steps, so we actually increase our probability of success. The key here is “increasing the probability of success.” We need to remember this phrase. It’s the inverse of many of the efforts made to manage projects. Connecting actions with outcomes is the Critical Success Factor. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 3/62
  4. 4. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s look at a broader context of the five (5) essential process areas for managing any project. Other project management paradigms have even other process areas – Prince2 for example. But the process areas here have emerged over the course of several decades of managing defense, large construction, and enterprise IT projects. These five (5) processes are: Identify the needed capabilities – this is commonly missing from many projects. A capability is not the same as a requirements. One way to think of this in the Enterprise IT is the ask “if I had the system, it was free, it worked on Monday, what would I do with it? Once you’ve defined the needed capabilities, you need to identify the technical and operation requirements needed to enable these capabilities. Then comes establishing the Performance Measurement Baseline. And then the execution of the PMB. At each process, we must apply continuous risk management in place and operational. The other 4 processes areas are work shops unto themselves, so for today, we’ll concentrate on building the PMB and assume the other 4 areas are in place. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 4/62
  5. 5. Fort Worth PMI Symposium July 15th and 16th, 2010 The term “baseline” has an important role here. It is a “controlled” document that contains the agreed on information about the future performance of the project. When we say “baseline,” we really mean three baselines.  The Technical Baseline is the agreed on set of technical requirements. These can be changing or they can be frozen, or any place in between.  From the technical requirements baseline, we have the work needed to implement them in the Schedule Baseline.  From this work we can establish the Cost Baseline. All three baselines are connected in an inseparable relationship, change one and the other two are impacted. This is sometimes called the “iron triangle.” Trying to make tradeoffs between the three variables can be done early in the project. Once underway, trade offs between these three baselines and the belief that there will be no negative impacts is a Ponzi scheme. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 5/62
  6. 6. Fort Worth PMI Symposium July 15th and 16th, 2010 What we’re here for today is to build the Performance Measurement Baseline. The core elements of the PMB are Work Packages. Work Packages are “lumps of work,” that produce a single outcome. The idea of the single outcome has important attributes. If we have multiple outcomes, it’s hard to measure progress with 0% or 100% completion criteria. If we have multiple outcomes who’s accountable for each outcome? Try as hard as possible to have a single outcome for each Work Package. Once we’ve connected the Work Package with an outcome, we can ask other questions:  How long will it take?  How much will it cost?  Who’s accountable for delivering the outcome?  What are the risks involved in delivering this outcome?  What dependencies are there for this Work Package or other Work Packages or external items? We need to answer these questions, if we ever have a chance at having a credible PMB. By credible I mean “believable.” It doesn’t have to be “right,” there are few “right” answers. It has to be feasible and it has to be credible. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 6/62
  7. 7. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s move to the six (6) steps needed to build this “credible” Performance Measurement Baseline. These six (6) steps are all mandatory. They need to be performed in the defined order. They need to perform their internal detailed steps in the right order as well. But first let’s have a look at what is going to take place from this point forward. Since this is a workshop, we’ll be doing workshop things. This means I’ll be asking you questions, you’ll be engaging me in the answers, and I’ll be drawing pictures on these flip charts of those answers. The Work Shop is designed to produce useable output that you can take back to your projects and put to work in some form. So let’s get started. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 7/62
  8. 8. Before we start with the Performance Measurement Baseline development, let’s talk a bit about the predecessor activities we saw on Page 4. Capabilities are not that well known outside government and large construction projects. But they are a critical success factor of any project. In the IT world a simple example of a capability would be the “process invoices from our top tier suppliers.” How do we do this – we don’t know. But we need to posses this capability to have some business benefit. General Patton stated the capability he needed. We need to state the technical and business capabilities needed that result from the project. We need to have these capabilities made public. They need to be the backbone of WHY we are doing this project. When things start heading for the ditch – and they will – the stated capabilities bring us back to reality. 8/62
  9. 9. Fort Worth PMI Symposium July 15th and 16th, 2010 Here’s a page from our Deliverables Based Planning ® method handbook. This method is applied in a variety of domains and contexts in those domains. The critical success factor for Deliverables Based Planning® is to focus on the deliverables. Not on the effort, the technology, the resources. These items are important. But the customer paid for the deliverables. By customer I mean the general notion of a customer. A business customer, a government customer, an internal customer. The units of measure for these deliverables must be meaningful to the customer. This is the reason to start with the Capabilities Based processes shown in slide 4. We’ll assume these have been defined, and the technical and operational requirements defined. Now we’re taking those requirements and building the Performance Measurement Baseline that will make them appear. These 6 steps are “immutable” in that they are all needed and they need to be performed in the proper order. This doesn’t mean they not iterative and incremental, but each step takes information for the previous step. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 9/62
  10. 10. Fort Worth PMI Symposium July 15th and 16th, 2010 The first step is the obvious one. What are these deliverables and what are the components of each deliverable? What are the products that represent these deliverables? What are the processes that build these products? This is the role of the Work Breakdown Structure (WBS). The best place to start with learning about how to build a WBS is the MIL- HDBK-881A. You can find that on the web. In 2011 this “handbook” will be migrated to a Standard, which means it will be mandatory for many domains For the moment, ignore all other descriptions and advice for building the WBS. Always start with the guidance that has WBS in its title. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 10/62
  11. 11. Fort Worth PMI Symposium July 15th and 16th, 2010 Here’s a “notional” starting point. We have a business need, that was provided prior to establishing the Performance Measurement Baseline. The need is “Process Invoices for Top Tier Suppliers.” In order to fulfill this “mission need” or provide this capability, we’ll need to do two more things:  Capture the invoices electronically.  Route them to payables. For each of these “accomplishments” (we’ll talk in a bit what that term means), we’ll to produce a few deliverables:  We’ll need to verify the receipt of materials – that is we the system to provide a way to verify the receipt of materials.  We’ll need to update the “on hand” balance for the materials.  Verify the payables account information.  And then schedule the payment. These “terminal nodes” are the deliverables for the software elements – in this example. In any example, the terminal nodes should be a single unit of functionality, a “thing” that is functional or parts for things that are functional. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 11/62
  12. 12. Fort Worth PMI Symposium July 15th and 16th, 2010 These terminal nodes are the deliverables. To get them delivered we need to do work. The work is performed in a Work Package. So what is a Work Package? A Work Package is simply a task / activity or grouping of work. A WP is the point at which work is planned, progress is measured, and earned value is computed. It can be translated into different terms in different companies and functions. It can be a design job, a tool design package, a build-to-package, a shop order, a part number, a purchase order or any other definable task / activity at whatever level control is normal for project management with in the company. – Defense Acquisition University. The Work Package is a “lump of work” that produces an output. Preferably a single output that fulfills a requirement, which in turn enables a capability to exist that the customer can make use of. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 12/62
  13. 13. Fort Worth PMI Symposium July 15th and 16th, 2010 The WBS is a framework for specifying project deliverables . It defines the project in terms of hierarchically related, product- oriented elements. The goal is to develop a WBS that defines the logical relationship among all project elements to a specific level (typically Level 3) of indenture that does not constrain our ability to define or manage the project and resources. Other attributes include: a. A product-oriented tree composed of hardware, software, services, data, and facilities. b. A WBS displays and defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product. c. A WBS can be expressed to any level of detail. However, the top three levels are the minimum recommended any project or contract needs for reporting purposes unless the items identified are high cost or high risk. Then, and only then, is it critical to define the product at a lower level of WBS detail. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 13/62
  14. 14. Fort Worth PMI Symposium July 15th and 16th, 2010 A good WBS is easy to recognize, but hard to build. A bad WBS is also easy to recognize but hard to correct. Here’s some attributes:  When someone says “I have a WBS,” test that they do by looking for the artifacts from these statements.  If someone says “we don’t need no stink’in WBS,” ask how they would recognize the artifacts from these statements. I’ll repeat this again, the WBS IS the Project. The WBS does what it says – it is the breakdown of the work needed to produce the product or service. It is the breakdown of the processes that go along with the work to build the products. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 14/62
  15. 15. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s connect the dots between the WBS and the Work Packages that guide the activities that produce the artifacts of the WBS. This picture shows where the Work Package lives in this process. We take our notional WBS and for each terminal node make a Work Package. The Work Package contains many things, but the first thing it contains is the list of work needed to produce the deliverable. This might be called a schedule, but let’s not go there yet. Let’s just get the list of work activities, maybe their sequencing. And most of all the list of “named” deliverables produced by the Work Package. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 15/62
  16. 16. Fort Worth PMI Symposium July 15th and 16th, 2010 Here’s our two (2) step process for producing a Work Package. Remember the Work Package is the “lump of work” that produces the desired outcomes needed by the customer to enable a desired capability. In this case – Process Invoices for the Top Tier Customers. These steps are simple:  Define what is being delivered in some clear and concise manner.  Define the effort and duration for doing the work that produces the deliverable. That’s it, it’s that simple. OK, maybe there’s a few more details, but at the top level that’s all there is. You may not have noticed, but this definition process is for a single Work Package. A Work Package at the terminal node of the Work Breakdown Structure. These Work Packages can be built in parallel by the project team. We haven’t connected them in a schedule yet. They should be – must be – independent from each other. Other wise our WBS tree is ill-formed. A terminal node would have multiple parents . Only baby cats and dogs can do that – not a WBS. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 16/62
  17. 17. Fort Worth PMI Symposium July 15th and 16th, 2010 When we are defining the deliverables we need to capture some more data. Here’s the start of that data capturing process. First a description of what it is we’re delivering. Then a name for the deliverable itself. This deliverable can be a “thing,” in the sense of a “thing” with a part number. It can be a report, ir can be a process applied to a “thing.” in all cases it is something tangible, something you can point to. Then a critical step must be taken. We need to state how we will recognize that our “thing” is complete, how it is whole, how it is DONE. We need to write down the criteria for DONE and assign that criteria to a Milestone or some other means of assessing the DONE-ness of the “thing.” This assessment must have some unit of measure of DONE. We can’t just say DONE. What do we mean when we say DONE? The answer has to be recognizable to everyone on the project. The DONE-ness of the Work Package is the “exit criteria.” It is the evidence that the Work Package is complete. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 17/62
  18. 18. Fort Worth PMI Symposium July 15th and 16th, 2010 With our definition of DONE, we can start to define how long it will take to get to DONE for the “thing” produced by the Work Package. This example is done in a table. We have the name of the “thing” being produced, we have an estimated “effort” and a duration over which that effort is applied. This is called the “period of performance.” we must separate effort from duration. But most importantly, we have the confidence in the duration and the effort. The method used here is a geometric scale of confidence  1 means we have good confidence – this means we know the scope, the duration and the effort is some level of confidence. This level is dependent on the domain and the context in that domain. But for now let’s say it’s to the 80% level.  2 means we know two of the following – duration, effort, scope.  5 means we only know one of the following – duration, effort, scope. The reasons for the 1, 2, and 5 and not 1, 2, and 3 has to do with attributes of geometric series rather than linear series. It’s outside the scope of this Work Shop to speak about this, but it is critical to avoid using linear series to rank things. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 18/62
  19. 19. Fort Worth PMI Symposium July 15th and 16th, 2010 With this simple example, here the contents of a “real” Work Package. Now let’s remember the advice from Yogi. The advice about there being a difference between theory and practice. You'll have to decide what content you want in your Work Package’s, but this list has been developed over many years of use. So when you find something new and useful to add, please call me and I’ll add it here. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 19/62
  20. 20. Fort Worth PMI Symposium July 15th and 16th, 2010 There are all kinds of fancy tools for managing stuff like this. The best tool of all is Excel or Word. Keep it simple. The nice thing about word is you can make a template file and send it around to all your Work Package builders and they can work on these in parallel. The Excel way is cleaver, but doesn’t support parallel work very well. No matter the tool, make these documents “controlled documents.” Version numbers, archive all previous versions. Publish the updates to a public place. Put these on a wall – the “wall of truth.” Walk the wall when you have questions about the content. Make this a “group” process – a group ownership of the content. Building the Work Packages successfully sets the stage for all the efforts that come next. If you don’t invest time here, you’ll be disappointed with the future outcomes. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 20/62
  21. 21. Fort Worth PMI Symposium July 15th and 16th, 2010 So now we’ve got our first cut at the Work Package content. Let’s visit an important concept. In many cases, we tend to name things in a short hand notation. Test, Develop, Integrate. MSFT Project provides 255 characters for the NAME field and another bunch of characters in the NOTES field. We need to use these to make clear and concise phrases about what we are doing. This chart comes from the guidance used to construct the Integrated Master Plan and Integrated Master Schedules mandated on Aerospace and Defense contracts. It uses a grammar that makes it clear what we are doing, what we are doing it to, what the outcome is, and most importantly what the planned technical maturity of the “thing” will be when we finish the work. Since only the last work efforts produce the final product or service, the previous work efforts result in partially complete – in terms of the overall project – outcomes. Preliminary, Initial, Testable, are typical adjectives for the work. When you start speaking in a grammar like this, the clarity of DONE results. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 21/62
  22. 22. Fort Worth PMI Symposium July 15th and 16th, 2010 Now for some heavy lifting. When it comes to estimating there are two basic schools of thought. 1. Estimating is a black art, it never results in any credible outcomes, is a waste of time, and I really don’t want to commit to do it. 2. The numbers I produce are padded enough to protect me from all the stuff I just said above. Well here’s a 3rd option. We can estimate with some level of confidence almost anything in the universe using a simple process. Here’s an example. Suppose you want to estimate the duration of a software development deliverable.  Could you do this in a week? Of course not, are you nuts.  How about a year? Sure, that’s a no brainer.  OK, how about 6 months? Well that seems like it might be possible if we have what we need.  Uhm, how about 3 months? Nope too short.  Well how about 4 months? Yea that sound better. In 5 questions we’ve got an answer to within 15%. Move that up to 20% and the work can be done between 4 months and 5 months. Repeat until done. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 22/62
  23. 23. Fort Worth PMI Symposium July 15th and 16th, 2010 Now that we’re starting to assemble the Work Packages, we need to define what DONE looks like and how we are going to measure this DONE. The measures of completion need to be tangible evidence from the Work Package. The number of planned drawings, some kind of working software, a paved road, a flying machine. Something that can be measured. Something that can be defined up front. A primary attribute of the Work Package approach is the notion that the what is delivered is 100% complete for the definition of what DONE looks like for that Work package. Defining DONE is part of the Work Package definition. DONE can be a partial deliverable, a piece of another deliverable, really anything that moves the project forward in its maturity. The key is that the deliverable is “pre defined” in the Work Package description and all progress is measured against this description. There is no opportunity to have a partially complete – by the definition of DONE – deliverable. The project planning then focuses on producing outcomes rather than effort. These outcomes support the increasing maturity of the product that fulfills the requirements developed prior to starting the PMB efforts. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 23/62
  24. 24. Fort Worth PMI Symposium July 15th and 16th, 2010 Now for our first exercise. Let’s start with a project and a simple set of deliverables. Our project is to build a toaster. We all know what as toaster does – it toasts bread. The result is toast. But if we wanted to build one – or actually many, what would the Performance Measurement Baseline look like? Let’s start with the WBS for this toaster. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 24/62
  25. 25. Fort Worth PMI Symposium July 15th and 16th, 2010 With our Work Packages, durations, work efforts, deliverables, and associated information, we need a single integrative responsibility to look after each Work Package. The Work Package Manager is the single point of accountability for the delivery of the Work Package content. She can make assignments in any way needed, but in the end, there is only one person “Accountable.” Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 25/62
  26. 26. Fort Worth PMI Symposium July 15th and 16th, 2010 The common Responsible, Accountable, Informed, Consulted (RACI) diagram is important for all projects. It says who does what. But Responsible is not the starting point. It’s who’s Accountable. With the named accountable person, responsibility flows from there. Make this document public – put it on the wall. Walk the RAM when there is a question about who is doing what. Make this a public process, so everyone knows who is doing what. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 26/62
  27. 27. Fort Worth PMI Symposium July 15th and 16th, 2010 Just a reminder of what this person is accountable for. It’s always about the deliverables. There are other activities of course, but the deliverables are what the customer bought. This is why the planning and scheduling process stops at the Work Package. With the Work Package manager being accountable for the deliverables, “how” the work package is executed must be the role of the Work Package Manager and her team. Within the project governance guides, you want to push down the accountability to those doing the work. They can’t do this work in any arbitrary way, but they must be accountable for the outcomes. On our large projects, Work Packages have a period of performance (start- end), assigned resources, and a budget profile. The Work Package Manager may have a detailed schedule, or just a bunch of notes stuck to the wall. This is called a “supplemental schedule.” The details are not on baseline. The Work Package is. Below this level detailing out the work is the role of the Work Package manager. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 27/62
  28. 28. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s take a quick look at what a RAM (Responsibility Assignment Matrix) looks like. Remember the role of the RAM is to make visible the Accountabilities for the deliverables of the project. The RAM is an “information radiator.” It “says its name,” the responsibility (accountability) assignment matrix. When you don’t have one of these hanging on the wall, confusion reigns , work overlaps, and gaps appear in the work effort. This may appear to be too controlling, too “managerial.” If it’s just you and two friends in the same room with the customer, then you’ve got an implicit RAM. Move outside the room, have work done in different parts of the building, or have work done in different parts of the city, state, country, continent and not have the RAM – trouble follows Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 28/62
  29. 29. Fort Worth PMI Symposium July 15th and 16th, 2010 That section was easy, but now we have some heavy lifting to do. We need to put the Work Packages in a logical sequence. By this I mean the order of work that maximizes (or minimizes) something for the project. It could be maximum use of the resources. The minimum time to market. The maximum business value. The maximum mission capabilities – getting the highest needed features in the hands of the user at the earliest possible time. What ever this “maximization” is (or it could be a minimization as well), it must be shown in some visible form. We’re back t o the BIG VISIBLE CHART approach. This can be a formal drawing hanging on the wall, sticky notes, a white board with doodles on it. But it has to be visible. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 29/62
  30. 30. Fort Worth PMI Symposium July 15th and 16th, 2010 With the Work Packages in place, documented to some level of detail, the estimated durations, and work efforts, it’s time to lay them out in some order of execution. We need to identify the predecessors and successors of the “lumps of work.” Note the tasks – that’s an issue for the Work Package Manager. The order needs to be logical in the sense that the products produced by the Work Packages can be consumed by the next Work Package. With this sequence, we can ask questions about the flow of value, the impacts on resources, the general logic of how the work progresses toward DONE. At this level of granularity, the emerging Master Schedule comes out. This is then the basis of the Work Authorization process. The authorization of work is not used to prevent work from being performed, but to assure the work is performed in the agreed on order. Performing work “out of order,” creates lots of problems, not the least of which is outcomes sit idle while others are waiting for materials. This is a “work flow” issue and needs to be addressed to ensure the best effectiveness from the resources. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 30/62
  31. 31. Fort Worth PMI Symposium July 15th and 16th, 2010 Here’s a really simple example. But simple examples should be moved into simple practices. While there are many networks of Work Packages around, complexity should be there only when there is a reason. The Work Packages for building the manned spaceflight systems in the Orion project are complex. Large ERP deployments around the world are complex. These are extreme examples. The majority of project management work should be just moderately complex. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 31/62
  32. 32. Fort Worth PMI Symposium July 15th and 16th, 2010 When we say “well formed” what does that mean. We know now that units of measure of DONE are needed to answer a question like that. So what are the units of measure of a “well formed” network? All the work is arranged finish to start. There are lots of ways to make connections. But Finish To Start should be the overwhelming majority of connection logic. The reason is simple, future work should not start until the previous work is complete – 100% complete. There should be no constraints in a perfect schedule. This is not possible of course, but minimum constraints should be your goal. This makes for a “dynamic” schedule. A schedule that can react to any changes – freely. The next concept is a bit subtle. The concept of “increasing maturity” may be new in some domains. This means that the products or services produced by the Work Packages increase in their maturity as the project moves from left to right. This maturity is the technical maturity. Performance, stability, and things like that. This is obvious as an after thought. Actually planning this maturity is much better. This maturity process has connections with “value stream maps.” The value of the work stream increases from left to right. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 32/62
  33. 33. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s take a short diversion here for a critically important concept. Leads and Lags in the schedule are restricted in most defense projects. NAVAIR, the Navy’s aviation arm, allows 5 days lead or lag in the Integrated Master Schedule between any two Work Packages. On a 5 year project 5 days might as well be zero (0) days. The reason to restrict leads and lags is the follow on work activity then uses partially complete products. This is the source of “rework.” When the predecessor activities finally complete, there is likely more work done and likely changes in that work. The successor work then has to readjust for these changes. If there is intermediate output needed by successor work, split the Work Package and produce 100% of the maturity for the intermediate output. By “thinking” in terms of “increasing maturity,” leads and lags can be removed. The project is a work flow of increasing maturity. We want to maximize this value within the constraints of schedule and cost. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 33/62
  34. 34. Here’s a picture of “real” Work Packages being arranged by “real” Work Package managers, on a “real” project. This is a simple process. Brown paper, sticky notes, hand written Work Package descriptions. This process is called Product Development Kaizen. The critical idea is to have collective ownership of the arrangement of the Work Packages, while having single accountability of the contents of each Work Package by the Work Package Manager. Arranging the Work Packages is a full contact sport. When complete, leave the sticky notes on the wall for all to see. You will move these into a project scheduling tool of course, but even then you should have a “plot” of these Work Packages. 34
  35. 35. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s see how we can arrange our work packages in some logical order in the next 5 minutes. It may be obvious, but there might be some subtle issues as well. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 35/62
  36. 36. Fort Worth PMI Symposium July 15th and 16th, 2010 Money, we need money. Hopefully other people’s money. Budgeting is a painful process for all projects. Whether it’s our money or someone else's money. Budgeting drives work, capabilities, progress, event features. We’ve waited this long to talk about budget, because we need to know what DONE looks like at some high level before we can ask how much does this cost. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 36/62
  37. 37. Fort Worth PMI Symposium July 15th and 16th, 2010 Putting budget to Work Packages at this point is real simple. We’ve got definitions of the deliverables, the needed resources assigned – at least in lumps – to the Work Packages. Now it’s simple to budget. From the head count, assign a labor rate, possibly forward adjusted for all the changes – and see what number comes out for each Work Package. In Earned Value terms – which we’ve avoided so far – this is the Budgeted Cost for Work Schedule – BCWS. No matter what cost performance management system we are using, we’ve now got the “budget spreads” defined for each Work Package. Put this number back into the document that describes the Work Package. This is one advantage of building the Work Packages in Excel, you can now do math on the budget numbers. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 37/62
  38. 38. Fort Worth PMI Symposium July 15th and 16th, 2010 But in the end this budgeting process needs to be in the project tool. You’ll never get cost and schedule integrated if you don’t start the integration on day one. NEVER separate these pieces of data. If you do, you’ll never get them back together. It is important to remember that we set the duration (period of performance) of the Work Package up front from the planning process. Now is NOT the time to be making changes to the contents of the Work Package. You missed that opportunity when we baselined the Work Packages. We can assemble the sequence with sticky notes – my preference. Or with a scheduling tool. The reason to do the assembly on the wall with sticky notes – or printed cards is better – is you can rearrange the Work Packages very easily and that be a group effort. With this sequence we can then go through and spread the resources we have, or figure out what resources we need, or any combination. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 38/62
  39. 39. Fort Worth PMI Symposium July 15th and 16th, 2010 The inverse approach which is useful sometimes is to take the resources we’ve got an lay out the sequence. This is how agile projects plan work. Moving stories from the “to do” column to the “worked and completed” column on the cork board. In both cases, we’re bound by the resources, budget, periods of performance. In both cases we know what DONE looks like – we’re never confused about that. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 39/62
  40. 40. Fort Worth PMI Symposium July 15th and 16th, 2010 Let’s not do too much effort here, just enough to get the idea of allocating budget to the Work Packages. If we let to tool do the math we can have MSFT Project calculate the total project cost, from the Work Package cost for projects that have a Not To Exceed target. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 40/62
  41. 41. Fort Worth PMI Symposium July 15th and 16th, 2010 Now comes something that is rarely seen outside government projects. What are the units of measure – the meaningful units of measure – for the completion of the Work Package, and the project as a whole? We MUST define these before we start any work. There’s a simple reason for this – if we don't define DONE up front, we won’t recognize DONE when it walks in the door. Think of the GPS navigation paradigm. The driving navigation product “knows” when you’ve arrived at your destination, even if you don’t recognize the building. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 41/62
  42. 42. Fort Worth PMI Symposium July 15th and 16th, 2010 The first thing to do when defining the units of measure of DONE is to agree that they must be “objective.” Tangible Evidentiary Materials is the formal word. They have to be tangible. Something you can touch, see, smell, look at. A simple example can be around drawings. Our Work Package produces 10 drawings for our workshop example toaster. We say the period of performance for these drawings is 2 weeks. Assuming a linear production of work, we should see 5 drawings at the close of business Friday for the first week. We defined this Measure of Performance (MoP) in the Work Package. On the Friday afternoon, you can walk over to the drafting area and ask to see the 5 drawings that are planned to be completed. If you see the 5 hanging in the stick- file, then you are 100% complete for the planned 50% completion point in the Work Package. The Estimate to Complete is now 50% - the other 5 drawings – and with the past performance of “on time,” you can naively assume you’ll get the next 5 at COB next Friday. It may serve you better if you went to visit the drafting department over lunch on Wednesday to see if 2 ½ drawings are done – this answers the question how long are you willing to wait before you find out you’re late? Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 42/62
  43. 43. Fort Worth PMI Symposium July 15th and 16th, 2010 In the file that contains all the project information, we need to write down what these success criteria or exit criteria are, so no one forgets what we agreed to when we planned out the Work Packages. The term “earned value method” is on this slide and we haven’t mentioned its use – and we won’t go there for now. But EV is a critically important measurement tool for any type of project. This is a topic for another workshop, but I want to plant the seed around EV. EV measures physical percent complete against planned percent complete in ways no other project management performance measurement process can. Agile’s story points are Uncalibrated, Lean and Critical Chain’s “value flow” is Uncalibrated. EV measures progress to plan in units of “money.” And money is what project management is all about. Copyright ©, 2010, Lewis & Fowler, All Rights Reserved 43/62

×