Herding Cats

Risk Handling

An agile thought leader provided an advanced outline of a paper on integrating risk and real options for an upcoming conference. A comment was made that traditional project management tries to "avoid" risks. Risk management has four options for "handling" a risk, with Avoidance being one:

1. Control the risk - lower the probability of the risk event occurrence.
2. Avoid - eliminate the opportunity for the risk to occur.
3. Assume - acknowledge a future risk event and accept the potential consequences without efforts to control it.
4. Transfer - reduce the risk exposure by reallocating the risk from one part of the system to another part.

The framework in which these "risk handling" options are available is guided by one of two concepts.
The DoD Risk Management Guide

Or the Software Engineering Institute Continuous Risk Management Guidebook:

    Both provide clear and concise guidance on how to management a Risk Management program, the elements of that program, and the artifacts that are produced during the operation of the program.
    So when something is mentioned about "risk management," looking at one or both of these framework may provide insight into how to conduct risk management in your project.

Books needed for Program and Project Management (Update)

While working on a government proposal over the holidays - as is typical for the government to put out the RFP and then go on vacation - I came across another book that is needed for the Program Office Library

• Assumption Based Planning - A Tool for Reduce Avoidable Surprises, James A Dewar, Cambridge University Press. This is a book all complex system development managers need to read and put to use. The concept is that planning in the presence of uncertainty requires a formal "assumptions" management process. This sounds simple, but in fact is a complex adaptive systems problem. For those in the agile world who use the term CAS and likely have little understanding of the theory, this is a book for the planning management processes needed to develop system in the presence of uncertainty.

Josh Nankivel asked for some suggestions of books on project management. In my experience most of he books on project and program management are too simple for any practical use. Over the years (30 years) I've had a different approach to books. First I'm the son of a University Librarian. I grew up in a house where books were scattered everyone. My mother read many books in parallel, a habit I enjoy. She also taught me to buy book I had no use for at the moment. Because when you needed them it was too late. This means reading things in preparation for some future need. In my short lived physics career and my longer lived technical management career, this advice has severed me well.
    Two other important quotes were:

Don't peak too soon
This too will pass

This is what mothers are for.
    My list to Josh is:

• The Handbook of Program Management, James T. Brown. This is a real handbook, with specific advice on managing programs from a professional program manager. I've posted a review for a more detailed background. This is the first book to buy, since it shows what is needed to successfully manage a Program. This is not a project management book however.
• For project management The Management of Projects, Peter W. G. Morris is my favorite. This is not a handbook nor a how too book, It is a history of project management. As such it is a guide of what has worked and not worked in the past.
• A similar book is Anti-Patterns in Project Management, Brown, Malveau, McCormick, and Mowbray, John Wiley. The anti-patterns speak to what not to do in software development projects.
• Systems Engineering: Coping with Complexity, Stevens, Brook, Jackson, and Arnold is a systems engineering book. Every non-trivial project is really a systems engineering problem. This book is a good introduction to the concepts of SE.
• Performance Based Earned Value, Paul Solomon, John Wiley & Sons. This is one of the best EV books to own. Paul integrates technical performance measures with EV to provide tangible evidence of physical percent complete.
• Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan. For any whoi has struggled with "getting back on track," this book provide detailed steps.
• Project Delivery System: 4th Edition, CH2M Hill. This book was used during my Rocky Flats PMO job. It is written for construction projects, but is applicable to other projects, including software. PDS is the CH2M Hill project management method. Project management is what CH does and they do it well. Learning from a firm that earns their living successfully managing high risk projects is a good place to start. You order this book from Amazon, since it is not in the store.
• Beyond Bullet Points, Cliff Atkinson. There are two versions of this book. I personally like the 1st version best. The 2nd version removes some of the structure I like. This is not officially a project management book, but the information on how to build a Power Point presentation is directly applicable to building a credible project plan.
• How to Lie with Statistics, Darrell Huff. This is available in paper back. This boo allows the project manager to recognize the "lies" that are produced in status reports, budget forecasts, and other tools used to hide progress, risk, and productivity. 
• Effective Risk Management: Some Keys to Success, Edmund Conrow, AIAA Press. This is a heavy weight risk management book. By heavy weight I mean it is heavy reading. But it also contains everything you need to effectively manage risks - both technical and programmatic. I had the privilege to work with Dr. Conrow on the Crew Exploration program. He's the author of the risk management section of the DoD PMBOK and several risk management guides for DoD.
• Augustine's Laws, Norm Augustine, Viking. This is a look at larger government programs from the view of the President of Martin Marietta Corporation. Norm's Laws have general applicability to enterprise IT and REP projects in many cases.
• Herding Chickens, Dan Bradbary and David Garrett, is a clever book with some good ideas,
• The Office of Government Commerce has several handbooks useful to project managers:

• Skills Framework
  
• Skills Framework Assessment Guide
• Portfolio Management Guide
• Project, Program, Portfolio Management Maturity Model (P3M3)

These are guides for developing project, program, and portfolio management processes. They are far superior to the PMI PMBOK approach for too many reasons to enumerate here. But take a look at the home site to see if anything there can be but directly to use.

• The two agile project management book I'd recommend are Kevin Aguanno's Managing Agile Projects and Mike Cohen's Agile Estimating and Planning. I have a review of Mikes book here.

The 5 P's of Managing Projects

    Proper Preparation Prevents Poor Performance. This simple phrase describes the core behavior of all project related work. The notion that “emergence” is the driver of the participants in a project requires careful consideration. The technical or business requirements of the outcomes of the project are always “emergent” in some form. To be otherwise would require a percent set of activities, materials, technology, and personnel. This of course is simply not possible.

    Failing to understand the subtleties of the continuous emergence of requirements means failing to understand any project requires planning to deal with these emerging requirements. This emergence also pertains to the tools and processes used to manage and deliver the project. emergence is applicable to all elements.

    Preparing for Emergence is the critical success factor in project work. Proper preparation is foundation of programmatic and technical risk management. This means asking and answering the “if – than” question, rather than the “what – if” question.
“If – Than” means knowing what can go wrong and how to respond to the following:

• Variation – comes from small influences to the project work and technology within the bounds of normal variances. Attempting to manage these variations is usually a waste of time. Instead knowing the boundaries of these variations and providing “margin” for them in the cost, schedule, and technical performance domains is proper preparation.
• Foreseen Uncertainty – are identifiable influences on the project that may or may not occur. Alternative plans are needed to respond to these foreseen uncertainties.
• Unforeseen Uncertainty – are influences that cannot be identified during the project. These are sometimes called “unknowns unknowns.” Since there is no Plan B, a no Plan all together is needed.
• Chaos – are events that have influenced the project before the project started. The very definition of a project is a set of stable drivers – requirements, stakeholders, technologies, processes.

A Bold Faced Lie

    Watching TV today and saw an ad for the Cadillac Escalade Hybrid compared to the Mini Cooper - S I assume. The ad by GM claimed the Escalade gets better millage than the Mini - 20MPG in town.
    I don't own a mini, but I do own a Honda Civic SI, with a comparable engine and drive train. 198HP and a 6 speed manual transmission and a very snappy response curve when you can heal and toe the drive train.

    While the SI is not as snappy as the Volkswagen GTI and certainly not comparable to the STI WRX or Evo-10 which have near race car performance, it is a scary ride when pushed to the limit. with a 8,900 RPM red line in a slight drift in the off ramp, a close ratio 6 speed and moderate breaking, it does have a near "no body roll" turning behavior. It'll kick ass in the unaware BMW and Audi driver waiting for the light to change in the common Colorado intersection, where two lanes go down to one in a few hundred feet. Chirping the tires in the first 3 gears is common. Add high performance snow tires and it's a fun ride for commutes and general back country road driving.
    The ad GM wants us to believe that GM has cracked the code for mileage in a SUV platform. When you go to the EPA mileage site you can compare the two vehicles. Turns out though the some kinds of numbers are being cooked.
2009 Mini S - 26MPH city and 34 highway. I can get 33 out of the SI on a 50 mile commute on flat highway. Down to 28 highway on the Denver to Breckenridge route. No tongue in the 2 liter Honda engine, so 5th gear running at 5,600 RPM going up I-70 to the tunnel.
    Having owned a Suburban (350, automatic) it had crappy torque as well. Our Honda Pilot out performed the Suburban in all ways except pure volume.
    The Esclade hybrid is rated at 20MPG city and 21MPG highway. It also give up towing capacity.
The Mini convertible is much less 23 City and 29 Highway. But both Mini's are turbo charged and the SI is not - if it were, it would produce 230HP and be really scary.
    So what's with GM. Are they trying to convince us that the Esclade is now a "green" car?
    Lies and damn lies is my response. I'll record the ad next time its on to do a more detailed assessment. I was some dumb founded when I foirst saw it, I forget to push record on the DVR.

Self Organized does not mean Self Directed

    Esther Derby writes about self organizing teams in StickMinds.com. I too have heard "leading agile consultants" speak about the virtues of self organizing teams. They usually speak in the absence of any context, business domain, and many times in the absence of experience other than managing trivial projects. By trivial I don't mean unimportant. I mean projects that have mission critical behaviors. ERP, Enterprise integration, product development with multiple moving parts (hardware, software, COTS parts, regulatory compliance in some way). Non-Trivial means some measure of coordination between all the moving parts is needed for success.
    The fundamental missing element in most of the "leading agile consultants" understanding is:

There is a difference between self organizing and self directing.

This is the role of management. This is not "directing" in the Command and Control sense. It is directing in the "required business value" sense.

Esther has some good points, but a broader context for management is needed:

• In self organizing teams serve their customers, who "manages" the customer, when the customer is not prepared to behave in a "well manner" way?
• If there is more than one self organizing team working on the same project, who coordinates the activities between these teams?
• When there are conflicts in resources, funding, requirements, who coordinates the resolution?

In Esther's Soccer Team analog, it is suggested the team members organize themselves on the field and respond according to the emerging play of the other team. Maybe Esther hasn't watched children's soccer, but there is a coach on the side lines directing the play. At the professional level, the coach is still on the sideline. Not directing each play, but certainly coordinating the players, guiding the flow of the game by substitutions, timeout consultations, and reinforcing all untold number of hours "practicing" these supposed "emerging" plays prior to the game.
    Esther speaks of the roles of a self organizing team.

• Managing work and monitoring progress
• Managing team membership
• Setting direction within the organization 

The paragraphs that follow describe a reasonable approach to these activities. Emphasizing that "setting direction" is rarely the self organizing teams role, when there are external customers or larger business issues - enterprise IT and ERP being two examples.

A Nice Overview of an Agile approach to projects

Mike Cottmeyer gave a webcast on an approach to managing projects with agile techniques. This talk has some good points. But like many of these presentations, the non-agile project examples are "notional" at best. This means they are simple examples, and not likely representative of real projects.
    Notional is good at laying the foundational for an educational process. But Notional usually looses it impact when a "real" project environment comes into play. The presentation above has several over simplified statements:

1. The PM is the center of the project. This is one of those notional concepts found in books about how Agile is better. Any sufficiently mature project manager knows that being the PM means having people perform at their best as a "team," not as subordinates of the PM. This arrangement takes place through the Chartering process, where all the participants discover what roles they play, what the basic deliverables are, and what other participants depend on them and what dependencies they are accountable for. This is the essence of team building.
2. Mike suggests that we stop putting activities into the project plans. This is wonderful IFF (if and only if) there are no dependencies between these activities. That is, they can be performed in nay manner chosen by the team. If however there are dependencies between the activities, the place to discover these is during the construction of the network of activities. It may be a tautology in agile, that activities have no dependencies. If so, Mike's on to something regarding the defining the context of an agile project.
3. Focusing on outcomes is always a good thing. This is the very essence of Earned Value, Deliverables Based Planning, and Integrated Master Planning / Integrated Master Scheduling found in DoD projects.
4. Iterative Planning is nearly the same as rolling waves mandated by DoD 5000.2. This has been around awhile, but for some reasons missed by those not thinking very well about what project management planning really means. The key of course is to define in some tangible measurable way, in units meaningful to the customer.
5. Daily standups, yes this is good. But daily may or may not be the right frequency. Knowing the right frequency us a challenge, but answering the question - how long am I willing to wait to find out we're late? is a good start.

But read this presentation, try out some of the ideas, see if they have applicability for you.

Bad Decisions? Yea, That's the Problem

On the current PMI site there are several Blog's. Greg Balestrero, the PMI President points to a McKinsey Survey on IT and Michael Hatfield speaks about the core problem of failed projects.
    Michael states

So, what is the main causal factor? (After listing several causes that are not the problem) The project manager and/or project team made bad decisions.

    But what does this means really. How can we make good decisions? Yes we know the ability to make good decision is critical to a project's success. Michael states the delivery of cost and schedule information is important. Yes, that is important. But I have been directly involved in several ERP projects where cost and schedule information was available and the projects were still 100% overrun in time and cost.
    The problem is not that the information is not available. If it is not available there are serious other problems. The problem is there is not actionable outcomes from having this information. Management decisions are uninformed. Management decisions are driving in the dark. Maybe driving in the rear view mirror at best. Having cost and schedule information from last months numbers is just that - driving in the rear view mirror.
    Here's what's really needed:

1. A description of what "done" looks like for every deliverable and every incremental progress measure that moves the project forward to that deliverable. Here in defense this is called "describing the increasing maturity of the program."
2. Having some measure of physical percent complete. These means having tangible, physical evidence that something has been accomplished. Like the previous post, these means testing the system against the requirements. Testing the code in the absence of this approach is nonsense.
3. Making informed forecasts using probabilistic models of cost, schedule, and techncial performance. Techncial performance is "product performance," in some unit of measure traceable to the products quality or ability to perform. The simple example in defense is the mass of the space craft. Does the mass fall within the boundaries of error at this point in its design maturity? If not, it's going to cost more, or take longer, or both to get that issue under control.

    So Cost and Schedule data is necessary. But it is not sufficient. Techncial Performance data is needed. And then actionable decisions based on future performance estimates - using some form of probabilistic modeling (Monte Carlo is mandated by DoD) - for what is going to happen in the future if we kepping doing what we did in the past. This is how to make use of the "driving in the rear view mirror" data.

Test Requirements, Don't Test Code

A recent post from a DO-178B blog made a powerful statement that just struck me a correct.

The only effective testing mechanism is testing requirements - not code. In fact, the very idea of testing code without a reference to a requirement is ridiculous.

The concept of Testable Requirements has been around for some time in the defense and space business, including a paper from Paul Solomon, connecting Performance Based Earned Value with Testable Requirements.
    So what does it mean when some says "code testing," or in the agile vernacular "write the tests first." Are there requirements - written requirements - for these tests to be "tested" against what?

Risk Management in Five Easy Pieces

Risk management is essential for any significant project. and is useful for any project where an unfavorable outcome is undesirable. Certain information about key project cost, performance, and schedule attributes are often unknown until the project is underway. The emerging risks that can be identified early in the project that impact the project later, are often termed “known unknowns.” These risks can be mitigated with a good risk management process. For risks that are beyond the vision of the project team a properly implemented risk management process can also rapidly quantify the risks impact and provide sound plans for mitigating its affect.

Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties. Outcomes are categorized as favorable or unfavorable, and risk management is the art and science of planning, assessing, handling, and monitoring future events to ensure favorable outcomes. A good risk management process is proactive and fundamentally different than issue management or problem solving, which is reactive.

The Five Pieces are:

1. Hope is not a strategy
2. All point estimates are wrong 
3. Without integrating Cost, Schedule and Technical Performance you’re driving in the rear view mirror
4. Without a model for risk management, you’re driving in the dark with the headlights turn off
5. Risk Communication is everything

Risk Management is How Adults Manage Projects

This title has been posted before. It's good to remind yourself every once in awhile of the phrase. I'm headed to the nations capital during the inauguration to work a program as the Senior Risk Adviser. This position supports the Program Manager and his staff in the context of programmatic and technical risk.
    This brings me to a quote:

"A good project plan has some form of contingency, mitigation, or alternative action built in to allow time for critical decisions" David Mercer, National Grid, Warwick, England (Liquefied Natural Gas plants and transmission system of 4,100 miles of pipeline)

Not only decision time, but recovery time for less than planned technical and programmatic performance.
Planning is Necessary but not sufficient, You have to Have a Credible Plan
    An agile thought leaser once side in a quote in a book

do the planning, but throw out the plans

which is course is completely wrong, "It isn't even right enough to be wrong," as Wolfgang Pauli says.
    Plans are the strategy for the successful completion of the project. Success almost always means the delivery of the deliverables that provide the business value the customer ordered. So if you have a Plan, what are the risks that will prevent the successful delivery of the deliverables that represent the business value? What are the mitigation's and or retirement's of those risks? Are those mitigation's and or retirements budgeted, resourced, and scheduled? If not, you don't have a credible plan. In fact your Plan is now a risk unto itself.
    If you follow the agile thought leaders advice "do the planning, but throw out the plans," you late and over budget before you start, and most likely the value you're trying to deliver is going to disappoint as well.

US Auto Industry

Every one's go some kind of comment on the current Auto Industry debacle. Some informed. Some not so. Some simple rants - informed or not. So philosophical. Some just more of the same.
    OK, here's mine.

In my titled role in a small firm, and a similar titled role in a very large firm, if I came to my boss or to the board in the midst of a financial, product acceptance, and quality crisis with a totally lame response that sounded like

Gee I have no Plan-B, just give me the money I need now to fix my problem

I'd be fired on the spot.

Why are we still talking to these knuckle heads? Why does the board even allow them back in the building. Add to the three the UAW guy, who in 2006 took home $158,126, who figured out how to con the big 3 into paying his member 95% of their salary for NOT working.

This is a self inflicted problem

Book Review Time (Again)

    I'm review a book The Handbook of Program Management, Dr. James T. Brown. It's a book about Program Management (from the title), but it's really a book about program success criteria.
    Like some other book reviews, my style is to read every word and make comments on the sentences, paragraphs, and chapters they form. This is annoying to some. But a book is a powerful tool for moving forward in the profession of project management. Books can provide the needed tools for making this happen.
    Here are some past reviews while waiting for this one.

Probability and Statistics in Project Estimating

Bill Duncan posted a piece on PM Student titled Estimating Effort. It's a multiple part series that addresses some of the issues around estimating cost and schedule in a project context. Multipart pieces are ineffective in the medium of a Blog. But Project@Work did this all the time, so we'll have to wait for the next installation to discover the real meat. In the mean time, I've skipped to the end in the best Atkinson tradition.

    In the first installment Bill states:

Many of the terms in estimating are used inconsistently or  imprecisely.

This is the case in most project management domains, especially IT. An estimate is defined as

A judgment or opinion as to the quantities of a person or a thing

The example of "guessing" the gender of a 6'6" person and a 5'2" standing outside your door is slightly off, since the variability involved in estimating are not in place in this example. The variability between two people standing outside the door in terms of the gender is 0. The persons are either male or female.
    This introduces the misunderstanding common in all naive estimating processes of confusing statistics with probability. Several posts in the past are background

• Confidence Intervals
• More Statistics
• Mean or Median

Understanding the differences between probability and statistics is critical to understanding how to make credible estimates of cost, schedule, technical performance, and finally project risk from these variables. What the project stakeholders want to know (or should want to know) is: What's is the confidence we'll come in on-time, on-budget, and the project will produce working results (be they products or services).

A Clever PMP Study Guide

Most PMP study guides are boring. I mean real boring. Boring beyond belief.
Here's one that isn't

Headfirst PMP

Earned Value for Time and Materials

Earned Value for discrete contracts is obvious. It's use for Time and Materials and IDIQ (Indefinite Duration and Indefinite Quantity) contracts is discourages in the guidance found in the 7 March 2005 Memorandum from the OUSD(P):

5. EVM is discouraged on firm-fixed price, level of effort, and time and materials efforts, including contracts, subcontracts, intra-government work agreements, and other agreements, regardless of dollar value. If knowledge by both parties requires access to cost/schedule data, the first action is to re-examine the contract type (e.g., fixed price incentive). However, in extraordinary cases where cost/schedule visibility is required and cannot be obtained using the Truth in Negotiations Act, the program manager shall obtain a waiver for individual contracts from the Milestone Decision Authority. In these cases the program manager will conduct a business case that includes rationale for why a cost or fixed price incentive contract was not an appropriate contracting vehicle.

This said, it may be an easy out to say - No EV.

An 28 April 2008 memorandum states

The application of EVM to work efforts that are not discrete in nature (non-schedule based), such as level of effort, time and materials, and services, should be considered on a case-by-case basis.  In cases where the nature of the work does not lend itself to the meaningful use of EVM, it may be appropriate to waive the EVM requirement.  When EVM is waived, the program manager will implement an alternate method of management control.

What method used for "management control" to replace EV needs to answer the questions:

• What does "Done" look like? - when the money runs out? Or the time runs out? Both? When the contract is canceled for lack of performance?
• How can we know we are actually providing "value" (earning this value) for the customer?
• What "value" should be earned during the performance of a T&M contract?
• If we are spending money and passing time, what is the customer getting for this?

These are answers that Earned Value provides. But getting these answers in the absence of Earned Value requires the use of some other performance measurement process.

Latest Earned Value Papers

The current Earned Value concepts are described in a set of new papers:

• Project Duration Forecasting: Comparing Earned Value Management Methods with Earned Schedule, Walter Lipke
• The Two Mist Useful Earned Value Metrics: The CPI and TCPI, Quentin Fleming and Joel Koppleman
• In the Fall Edition of the Measurable News, the magazine of the PMI College of Performance Management.
  • "Does Project Performance Stability Exist?: A Re-examination of CPI and Evaluation of SPI(t) Stability?,"Kym Henderson
  • "Integrating Systems Engineering with Earned Value," Paul Solomon
  • "The Trouble with Earned Schedule," Wayne Abba

These papers and many others in this topic provide visibility into the complexities of Earned Value. These complexities should in no way prohibit the application of Earned Value. In fact they should encourage the application of Earned Value for all the right reasons.
    What they show is managing projects is a profession, with professional tools, with the expectation of professional results.

Irreducable Functions of Program Controls

I'm updating a PPT for a briefing next week on what we do when we're doing Program Controls. Here's a short summary:
    During Program Execution insight is provided into the contractors performance for both technical and programmatic performance. The Performance Measurement Baseline is properly integrated with the Earned Value Management System through sound program management practices to provide the Program Manager the ability to:

• Identify and assess actual progress versus the planned progress – this is done through the Earned Value processes at the Task level.
• Monitor the program critical path and develop workarounds to problem areas – the concept of a Critical Path is more than the path through the program with zero (0) or small Total Slack.
• Assess program maturity – program maturity is best assessed through Technical Performance Measures (TPM).
• Assess the status of risk management activities based on the inclusion of the program risk mitigation activities in the Integrated Master Plan (IMP) and Integrated Maseter Schedule (IMS) – this programmatic risk starts with the modeled variance in the duration of tasks.
• Assess the progress on selected Key Performance Parameters (KPPs) and Technical Performance Measures (TPMs) – the units of measure for the Technical Performance Measure needs to be connected with the Key Performance Parameters of the Integrated Master Schedule.
• Provide an objective, quantitative basis for the performance assessment – the IMP and IMS should be the basis of objective and quantitative performance programmatic measures of the aspects of the program.
• Develop and support “what–if” scenarios, and to identify and assess candidate problem workarounds – alternative paths, cost models, and risk adjusted estimates to complete are the raw materials for the “what if” assessment of the IMS.
• Provide better insight into potential follow–on efforts that were not part of the original contract award.  For example, the contractor should be able to more clearly define the activities, new interfaces, and other clarifying information necessary for a potential program increment or contract option.

It's the last bullet that is the critical success factor for Program Controls. Without independent insight into the actions needed to keep the program on track, get the program back on track, and determine where in time the program will go off track, the program manager's only stratgey for success is - HOPE.