Herding Cats

End of Year Round Up

For some unknown reason I feel compelled to write an end of year round up. The top 10 lists, the favorites for the year, that email Christmas letter, are all some cliche. But over the course of the year, I've come to understand more about the management of programs and the program controls activities. This understanding is from reading, listening, and practicing what I read and herd.

So here's some background on that increased understanding.

My Favorite Blogs (of the 300 or so I have Goggle Reader pointed to)

• Eight to Late - a fellow physics person who works in the project side of things. Some of the best though out technical analysis of project behavior there is.
• Musing on Project Management (John Goodpasture) - John and I share many things, including a relationship through Management Concepts where his books are in the lobby.
• Shift Happens (Michael Clayton) - Mike book is a wonderful starting point for managing risk.
• Crossberry Blog (Paul Ritchie) - I've been following Paul since he was at SAP. Great PMO and general PM advice.
• The Earned Value Management Blog (Darryl Schwago) - a REAL earned value blog. Wish mine was a good.
• Learning Leader (Patrick Mayfield) - Pat is a former artillery officer in the Canadian Forces, and we share similar views of the world about PM.
• PMStudent (Josh Nankivel) - Josh's WBS book is the starting point for any credible WBS. Buy it, use it, read how to build it right.
• Agile Management (Jurgen Appelo) - Jurgen is nothing if not thought provoking. Good stuff, and lots of off the wall stuff, but out there making the point that management needs to change.
• I Love Charts - lots of good PM charts useable in training and briefings. Always needed to get away from the boring crap we usually produce.
• Gapping Void (Hugh MacLoed) - the best thought provoking drawings in the world. I've used several (with written permission and attribution) in heavy duty briefings for flag officers. He now has business cards

My years favorite Books

• Measuring Time, Mario Vanhoucke - improving project performance using earned value.
• The Monty Hall Problem - how we totally misunderstand the notion of Bayesian statistics.
• Gödel's Theorem - a guide to the misuse of Gödel's theorem. Mandatory reading for any thinking they know anything about Gödel's Theorem.

With the end of 2011 several events have taken place:

• The Second Version of the PMI Earned Value Management Practice Guide includes Earned Schedule. Even a year ago this would unheard of.
• Programmatic Risk and Opportunity Management are now on the table at the National Defense Industry Association (NDIA) as a candidate for an Intent Guide.
• The discussion of Agile on Federal Contracts started with a Webinar at Management Concepts.
• The notion of Immutable Principles of Project Management has taken hold in several domains, contexts, and firms.

So for just a final reminder, the principles, books, blogs, web sites are applicable to any project, in any domain, and any context in that doman.

Answering these questions depends on the method and process of the project. For a full-up EVMS Ansi 748B project the answers will be different than for a Scrum based agile software development project, and different again for a community food share project at our Parish.

But the answers need to be credible, measurable, and thorough.

Building the Perfect Schedule

I'm speaking at the Denver Professional Development Symposium in April of 2012. The topic is Building The Perfect Schedule. LinkedIn has a thread on schedule float and margin. There are several other threads around on scheduling, margin and risk.

The place to start for guidance in scheduling is NDIA (National Defense Industry Association) Planning and Scheduling Excellence Guide (PASEG).

The PMI briefing is based on the notion that a schedule can be built that is credible.

This of course with the description of DONE is units meaningful to the buyer. It's the buyer that says what done looks like. Capturing that description of DONE in sufficient fidelity is a critical success factor.

DONE is not described by the tasks performed in the execution of the  project. DONE is described by the tangible evidence from the Outcomes that fulfill the project's mission and vision in terms of a set of Capabilities that can be put to work by the buyer for their purposes.

When we see scheduling and the supporting planning as a mechanical process, then we'll end up with a typical schedule. A rats nest of tasks, linkages, dependencies. All failing to describe how we will recognize we're making progress to plan.

All successful projects must answer those 5 Immutable questions that must always be answered if the project has any probability of success.

No matter the project management or product development method, success comes from credible answers to those 5 Immutable Principles. In all cases the schedule support those answers. This means that the method used to schedule - from agile sticky notes to the 100,000 activity network - must also support those 5 immutable principles.

Project Governance Using the Program Management Office

Lynda Bourne has post on Project Governance. She suggests some processes for good governance and references some papers on the topic. Governance is one of the role of the Program Management Office. Here are 4 paradigms for the PMO, the details of the 4 paradigm, and the value proposition of the PMO.

Quote of the Day - Good Leaders Are Rare

I found this not only motivating, but guidance for everyday life as well.

From Robin Greenspan's news letter via ExecuNet.

Handling Risks

The traditional term in Risk Management is Risk Mitigation. That is you mitigate the risk.

As a verb Mitigate \ˈmi-tə-ˌgāt\ means

to cause to become less harsh or hostile. To make less severe

Using this definition, we come back to the question that always exists:

• What are the units of measure of harsh?
• How can we measure that we are in fact making the risk less severe?
• In the pursuit of mitigation what are the impacts on cost, schedule, and the technical performance of the outcomes of the projects

To answer these questions we need a map that shows the consequences of mitigating a risk. This map must show the connections between the risk mitigation work and the standard work. It must show the impact of risk handling on cost and schedule in the presence of Management Reserve.

Making these impact visible is part of the overall Integrated Master Plan (IMP). The IMP is the strategy for the successful completion.

So Here's the Steps

1. Build the Risk Registry in the standard way.
2. Identify each risk and it's impact in the outcomes of the Work Packages
3. Determine how to handle the risk
4. If the handling strategy is to Buy Down the risk, the construct a Work Package, assign budget and place that Work Package in the Control Account and on the Integrated Master Schedule
5. If the handling strategy is to Mitigate when the risk comes true, then put a lean on Management Reserve for that risk and be prepared to BCR (Budget Change Request) the Control Acccount with a new Work Package to deal with the risk.

But no matter what you do, make all the risks visible, make all the handling strategies visible, for all planned work, put it on baseline. For all risk handling work awaiting a decision, identify the handling strategy and the funds needed to do the handling, and the source of those funds.

 

5 Immutable Project Success Processes (Again)

As the year comes to an end, it's time to remind ourselves of the 5 Immutable principles of any project success.

1. Identify Needed Capabilities that achieve the program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measures of Effectiveness (MoE) meaningful to the customer.
2. Define The Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer. Define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology.
3. Build The Performance Measurement Baseline describes the work to be performed, the budgeted cost for this work, the organizational elements that produce the outcomes from this work effort, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical Performance plan.
4.  Execute the PMB’s Work Packages in the planned order, assuring all Performance assessments are 0%/100% complete before proceeding. No rework, no transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.
5. Apply Continuous Risk Management for each Performance Based Management process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

These are assembled into a cohesive Performance Based Management method, applicable to nearly ever project.

This approach starts with defining the outcome of the project. These outcomes are the capabilities.

What does a Capability Sound Like?

• We need the capability to pre‒process insurance claims at $0.07 per transaction rather than the current $0.11 per transaction.
• We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.
• We need the capability to change the Wide Field Camera and the internal nickel hydride batteries, while doing no harm to the telescope.
• We need the capability to fly 4 astronauts to the International Space Station, dock, stay 6 months, and return safely.
• We need the capability to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and guidance capabilities in the helicopter.
• We need the capability to comply with FAR Part 15 using the current ERP system and its supporting work processes.

What is a Requirement?

A Requirement is …”A statement identifying a capability, a physical characteristic, or a quality factor that bounds a product or process need for which a solution will be pursued.” — IEEE Standard 1220–2005.

When we speak about requirements we need to remember

The hardest single part of building a system is deciding what to build …

... No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

– Fred Brooks “No Silver Bullet,” 1987

The Performance Measurement Baseline

The PMB is time–phased network of activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the outcomes from this work, and the Performance measures showing this work is proceeding according to plan.

The Plan and the Schedule look like this...

• The Plan is the strategy to successfully complete the project, described through Significant Accomplishments and their Accomplishment Criteria.
• The Schedule is the sequence of the work activities measured by the Accomplishment Criteria, that follow the Plan of the Significant Accomplishments.
• A credible Plan and Schedule means there is a statistical model of cost, schedule, and technical Performance of outcomes as the foundation of the credibility of the project’s probability of success.

Executing the PMB

With the PMB in hand it needs to be executed. This is done with 5 simple steps

1. Perform the authorized work -Using the Work Package sequencing, release work to be performed as planned.With the responsibility assignments, identify the accountable delivery manager to guide the development of the products or services for each Work Package.
2. Accumulate and report work package performance -Using Physical Percent Complete or Apportioned Milestones, capture measures of progress to plan for each Work Package. Report this Physical Percent Complete in a centralized database for each Work Package and the project as a whole.
3. Analyze Work Package Performance -Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance.Construct cost and schedule Performance indices from this information and the Physical Percent complete measures.
4. Take Corrective Action -With Cost and Schedule Performance indices, construct a forecast of future Performance of cost, schedule, and technical Performance compliance.Take management actions for any Work Packages not performing as planned.
5. Maintain the Performance Baseline - Record past Performance based on Work Package completion criteria. Record past future forecast Performance estimates in a historical database. Forecast next future Performance estimate against the Performance Measurement Baseline. Report this next future Performance estimate to the project stakeholders.

For Each of These Process apply Continuous Risk Management

1. Identify Risk, Issues, and Concerns
2. Analyze, evaluate, classify, and prioritize the risks
3. Plan what should be done about each risk - the risk handling strategy
4. Track and monitor risk metrics and verify and validate the risk handling processes are being effectivey applied
5. Make management decisions using this information

Fail Forward

I was reading a Bloomberg News article while stuck at the airport heading home. Waiting for the inbound flight Denver where they had 2 feet of snow today. The artilce used the term fail forward. The concept is around innovation and the culture of innovation.

There were example of famous lack of innovation stories. The Western Union internal memo stating This telephone has too many shortcomings to be considered as a means of communication. The wireless music box has not ... commercial use, was the response to David Sarnoff's request to investing in the radio.

These may be urban legends, but Edison did hire dozens of "inventors" to helo him fail forward and share what they learned from these failures.

What Does This Mean For Projects?

It an obvious tennet of agile to fail early and fail often. But that is just a buzz word phrase in practice. It's of no real value in the absence of a PLAN for failure.

Remember a Plan is a strategy for the successful execution of the project. And Strategy is a hypothesis that needs a test to move forward. This is where the fail forward takes place in an actionable manner.

One program I've worked is a BioPharma contract with the US Army for an anti-virus. The Integrated Master Plan has multiple steps to fail forward in the development and testing of a molecule that is the basis of the drug. The researchers are seeking failure in a sense. They having paths they are taking - with intent - to fail forward.

So what this means is:

• We need a risk buy down plan - this plan performs specific work to buy down or retire the risk that the outcome of the project will not be reached on time or on budget. The outcome must of course be compliant with the Technical Performance Measures, otherwise no one will call the project a success.
• We need specific Measures of Effectiveness (MoE) and Measures of Performance (MoP) for the increasing maturity of the product or service the project is producing. These measures have been described before

So the fail forward paradigm must define how you are going to perform work the actually moves the project forward. Edison did not randomly go try out things in his search. He had a Plan and Strategy. It was not a random walk in the woods looking for the solution.

There were 1,000's of trials. 10's of 1,000's of attempts to invent Radar as described in the book Tuxedo Park. All the processes were fail forward, not self organized, self actualized, self guided. But structured, organized, intent of the command efforts to discover something that was not discoverable without failing forward.

This is were the agile approach is at its most powerful.

We know what Done looks like - a blub of light, a radar systems where non existed before. Richard Rhodes The Making of the Atom Bomb describes similar efforts to Fail Forward.

The critical concept, many times missed or mis-used in the agile world, comes from the MoE paper referenced above.

The design of a system is an ill-posed problem that has no solution without a set of criteria to guide choices.

Without this set of criteria to guide the choices, the project wanders aimlessly in the forest of all options. This is the role of a Capabilities statement. The role of a Strategy for fulfilling those capabilities.

The agile notion of Epic provides this. It shows what done looks like in units of measure meanigful to the decision makers. It shows how the fail forward in the pursuit of DONE.

So ask the simple question

What is the Plan that shows the sequence of processes or activities we are going to need to fail forward?

 

Your recovery Plan is Not Thorough and Not Credible

When I encounter a triage situation, like the one starting in January, I'm always surprised at how many steps it took for the program to get to the ditch. Small, simple steps that led them over the cliff without even knowing it.

The discussion usually starts with blaming the tool. In the program management and program controls business PROCESS IS KING. Many decades ago, we used to do the program perform by hand with a quadrille pad and a pen. So tools only make the work effort more efficient, not necessarly more effective.

When we're managing a program we need both thorough and credible processes for the plan to

GET  BACK TO GREEN and KEEP THE PROGRAM GREEN

Thorough Processes

For the GET TO GREEN plan to be thorough it must:

• Identify and classify sources of all data and the variances for that data. This means that measures of Physical Percent Complete must be used for all work activities at the Task level.
• Assure all related systems and processes have bi-directional traceability between the work being performed and the data the provides visibility into that work.
• Identify underlying / system-related cause(s) of gaps in this data traceability.
• Continuously focus on opportunities to improve systems, processes, and people, and if none are apparent, can explain why.
• Define a plan to address any and all opportunities to improve or explains why the organization isn't addressing those opportunities.
• Explain — when improvement plans are justified — who will carry out the plan; when that person(s) will carry out the plan; and the methods for measuring result.

Credible Processes

For the GET TO GREEN plan to be credible it must:

• Involve people closely associated with all aspects of the systems and processes under review.
• Receive support, authorization, and encouragement from senior leadership.
• Present findings that are consistent and whose conclusions the Root Cause Analysis developed during the triage process.
• Consider relevant external examples of working systems, processes, and people skills needed to keep the program GREEN. No need to invent something new.

The challenge them becomes how to KEEP THE PROGRAM GREEN. Again Process is King. Know working management processes are available for any program or project domain. If the processes are not applied correctly, consistently, thoroughly, and credibly, then the project or program will be back in the ditch soon.

I have a colleague who has a phrase he uses on troubled projects. In his best southern (below I-10) Louisiana accent, he says...

How do ya know you'rer in the ditch? The weeds are hitting the windshield. Turn the wheel to the left and get out of the ditch. From then on try and keep the car between the white lines.

Quote of the Day

One approach to control optimism is to have an unassailable understanding of the facts.

When there is optimism in the air, then asking and answering fact based questions clears the way to understanding if that optimism is founded in fact.

There is no better place than on a project to seek a fact based discussion. This starts with the planned description of physical percent complete.

One this day we plan to have 40% of all the database interface code complete, integrated, tested, and checked into the source cde control system. By tested we mean tested against the pre-planned Unit and Integrated test procedures. By checked in we mean the code is complete and ready to be put to use by others.

Come that day, we can check to see if what we planned to do, we actually did.

If yes, we get 100% credit for spending our planned budget. If no, then we can't be on schedule, on budget, or compliant with the technical performance plan.

Only tangible evidence of physical percent complete is a credible indicator of progress to plan.

Denial Just Ain't a River in Egypt

The Mark Twain quote is a good starting point for risk management. The picture below is from Formal Risk Management, David Nicholls in the Data and Analysis Center for Software, 1/1/2004. The DACS is a Department of Defense (DoD) Information Analysis Center (IAC), serving the DoD for over 30 years. As an IAC, the DACS is Center of Excellence, and technical focal point for information, data, analysis, training, and technical assistance in the software related technical fields.

We've all seen these excuses for not doing risk management, for not handling the risks, for not retiring the risks before they become issues.

I'm working on an NDIA Program Management committee that is building a Risk Management Practice Guide (not the official name yet). The committee is trying to frame a set of practices for good risk management on National Defense programs (hence the National Defense Industry Association), without defining the prescriptive steps. Instead to make the practices descriptive in the same way the Earned Value Management Intent Guide.

The problem of course is that many organizations see Risk Management as a necessary evil, rather than a project management method. The best description of how to think about risk management is Tim Lister's How Much Risk is Too Much Risk

The notion Lister states is that Project Management is Risk Management. All other activities in the project are data generating or data producing. The verb management is about managing risk.

The Power of an Integrated Master Plan (IMP)

The current issue of Defense Acquisition Research Journal has an article "Better Schedule Performance Assessments Derived from Integrated Master Plan-Referenced Schedule Metrics."David Bichman outlines the benefits of measuring progress Baseline Execution Index (A measurement used to indicate the efficiency of actual work that has been completed measured against the baseline) and Critical Path Length Index (a measure of the relative efficiency to complete a milestone on time).

The concept of an Integrated Master Plan has been mentioned here before:

• You need a map to tell the outcome,
• IMP/IMS and Deliverables Based Planning, 
• What does an IMP/IMS look like? The Grammar of "Done," 
• What does a Master Schedule Look Like?,

These speak to the structure of a program based on Program Events, Significant Accomplishment, and Accomplishment criteria.

The Accomplishment Criteria are outcomes of the Work Packages in the Integrated Master Schedule (IMS).

• What is a Work Package,
• Schedule Work Packages First, Not Tasks,
• Work Packages Are Our Friends.

The Critical Success Factor here is to define what DONE looks like in units of measure meaningful to the decision makers. This means:

• Tangible evidence of physical progress to plan at the level where management can impact the outcome. This is typically at the Work Package level. Tasks inside the Work Package belong to the people actually performing the work. Let them manage this work, arrange it in the way they see fit, and control the staff assignments of their team.
• Arrange the Work Package nose to tail, meaning that the Work Package produces an outcome - a single outcome - that is complete by its pre-defined definition of complete. This outcome moves the project to the next step in its increasing maturity. The complete Work Package outcome does not mean the project is complete. This outcome is one step along the way for the project being done.
• Adjust all measures of performance - cost, schedule, and technical performance - for risk using a probabilistic model of this risk.
• Measure the physical percent complete at intervals that allow corrective action to take place. This interval should answer the question how long are you willing to wait before you find out you are late? Assess progress to plan at a shorter interval than that to make sure you have time to correct the cost, schedule, and technical performance in time to Stay GREEN.
• If you can't correct in time, define the actions needed to Get Back To GREEN and place those actions in the Integrated Master Schedule.

An Example of Looking Outside the Limits For Those Pesky Swans

I found a nice example for the discussion of Fault Tolerance to Black Swans. The J-2X engine will power the current manned spaceflight vehicle - once an actual launch vehicle is available. This engine must start in space - a non-trivial problem.

From the parabolic Arc article

The Dec. 1 test firing focused on characterizing the new engine’s combustion stability, a critical area of development. During the test firing, a controlled explosion was initiated inside the engine’s combustion chamber to introduce an energetic pulse of vibrations not expected during nominal operations. Data from this and future combustion stability tests will help engineers understand more about the engine’s performance and robustness during engine operation.

Note the phrase a controlled explosion that was used to introduce a disruptive event that would not be expected during operation. But IF it ever happened, the last thing you want is the engine that puts into orbit after main vehicle separation to not work.

It's the thought process - the disciplined thought process - of finding the boundaries of the pesky swans.

More Black Swans

Some time ago there was a discussion around Black Swans and the knowability of low probability - high impact events. The Black Swan is a metaphor that encapsulates the concept that an event is a surprise (to the observer) and has a major impact. The Wild Swan is a concept that better describes what we encounter in our project work. Without a domain and a context in that domain, any discussion fails to be applicable and turns into a "populist" philosophy story.

For the Back Swan, the event is rationalized by hindsight. The critical understanding here is the surprise to the observer. Francis Bacon suggested our minds are wired to deceive. This mention of the observer rarely occurs in the popular discussion of Black Swans.

Beware the fallacies into which undisciplined thinkers most easily fall--they are the real distorting prisms of human nature.

The term undisciplined thinkers is a Root Cause of most failures. It is common to use the term Black Swan to describe some correlation that we believe (in Bacon's way) cannot be explained.But when applying a little discipline, research, and most importantly fact checking is turns out what was Black may actually be White or possible Gray.

In the current issue of Strategy & Business is an article How to Prepare for a Black Swan: Disruptor analysis can help assess the risk of future catastrophic events. (Free registration required). The clip below provides insight into the concept of a Black Swan and repeats the problem of not understanding the paradigm of black swans - a surprise to the observer.

Let's start with the Fukushima Daiichi power plant black swan. The popular press reported the earth quake was unexpected. Let's look at some articles - NOT from the popular (or populist) outlets. IEEE Spectrum is a monthly magazine of the IEEE. A special issue was dedicated to the accident.

While the earthquake itself is a complex topic, the problems at the power station are more important.

• The seawall had no safety margin.
• The diesel generators in two of the units were in the basement. The other 3 units had them on the 3rd floor. It was cheaper to put them in the basement.
• There was not back-up for the back-up power.
• The spent fuel rods were kept on site because of the politics of the disposal process, just like they are in the US.
• The killer event was that the gravity feed for reactor cooling was enabled when the earthquake struck. It was cooling the core too fast so it was turned off. Several minutes later the wave breached the sea wall, flooded the basement. The valves to turn in the gravity fed cooling loop of course required electricity. The core melted.

The earthquake was possibly unpredictable - we'll have to wait and see what the science says. But the power station and the policies were unprepared for many things, starting with the loss of site power. This is the case in many locations in the US as well. Site power is needed to control the reactor to shut down. So it went down hill from there.

The first discussion of Black Swans was prompted by Rumsfeld's comment about unknown unknowns in regards to Iraq. Like Vietnam (my war) the decision makers had little understanding and little interest in understanding the social and political ramifications of their actions. The country of Iraq is synthetic, created through the British Mandate of Mesopotamia in 1920. Tribal groups were assembled into a country. When the US came and liberated Iraq, those tribes emerged and started killing each other as well as the liberators to the surprise of the observer.

Like Vietnam, students of Iraq informed the decision makers of the hornets nest that would be released when the dictator was removed. See Fire in the Lake: The Vietnamese and the Americans in Vietnam

Black Swans ≠ Unknown Unknowns Only if it is UNKNOWABLE

The role of fault tolerant systems is to survive in the presence of failure. Fault tolerant systems are used for Emergency Shutdown, turbine controls, boiler controls. I have some experience in the domain of Fault Tolerant Systems.

This background informs (colors) my view of the notion of unknown unknowns. If you're going to venture into a realm of high risk, high consequences, you'd better damn well have considered all those improbable events that can cause your system to fail. And then in the end design that system to be fault tolerant.

So here's how it works:

• Acknowledge that Black Swans are surprises to the observer and get more observers. In fact seek out the experts in the field and have them seek out their experts and perform the needed processes to confirm that you have exhausted all the sources of faults in your system or you idea before proceeding. Table 5 of Reliability of Instrumented Safety Systems is an example.
• When the external system fails, the system in control must be not only be fault tolerant, it must fail safe. That is the system cannot fail to danger.
• If you - the observer - were surprised, ask how could that have been? Did you make every effort possible to determine causal factors that would create a fail to danger outcome? Maybe you couldn't afford to do that. Maybe you were incapable of doing that? Maybe you didn't have time to do it? Maybe you had too much hubris (in Rumsfeld's case) to admit you should be doing it. If it didn;t do all these you can't call the outcome a Black Swan.

In the absence of this approach, those pesky black swans are going to bite and bite hard.

A Counter Argument

Matthew Squair's wonderful blog has a post about probabilistic design and aviation safety. Here he restates John Downer's argument that once the risk of an extreme event has been ‘formally’ assessed as being so low as to be acceptable it becomes very hard for society and it’s institutions to justify preparing for it (Downer 2011).

So the revisiting the Black Swan and Fault Tolerant and Fail Safe concepts...

5.(a) … (1) in any system or subsystem, the failure of any single element, component, or connection during any one flight should be assumed, regardless of its probability…

This means we MUST consider that all possible failures will happen and engineer the system to deal with this. This is the failure mode of Fukushima Daiichi. The improbable was possible.

 

Two Mandatory Readings

The Association of Project Management (APM) has produced a guide for integrating Risk and Earned Value.

I sit on a NDIA Committee in the Program Management Steering Committee (PMSC) that is addressing the same issue - how can risk and opportunity be integrated with Earned Value.

The core issue here is what does it mean to be managing a program using earned value if the risk of completing on time or on budget is not considered in the Performance Measurement Baseline?

The establishment of the Performance Measurement Baseline is described in a anchor diagram.

1. Establish the project context
2. Develop the Statement of Work and initial WBS
3. Develop the top down budget and schedule
4. Identify the strategic level risks
5. Perform  the initial risk analysis
6. Revise the top down budget and schedule
7. Integrated the WBS and OBS
8. Create control accounts and perform risk analysis
9. Update the initial Performance Measurement Baseline
10. Update and baseline the project risk register
11. Approve the PMB and the Management Reserve (MR)

The second must read document is the new - Version 2 - Practice Standard for Earned Value Management. I started working on the agile and EVM appendix, but discovered the PMI Practice Guide is not based on ANSI-748B. Fortunately the Practice Guide dropped that appendix, so it was a moot point.

What is important is that the Earned Schedule Appendix made it thanks to the work of many, but especially Kym Henderson.

What's interesting though is ANSI-748B is mentioned 3 times.

• Page 8 - contingency
• Pages 46 and 47 - contingency reservers
• Page 52 - contingency

This contingency paradigm is common in construction and the Department of Energy.

No where else in the Practice Guide is 748B mentioned. I find this a big gap, since 748B desribes 32 criteria for a successful EVM System.

The chapters of the Practice Guide address many of the criteria found in 748B

• Organize the project
• Assign responsibility
• Develop schedule
• Establish budget
• Determine measurement methods
• Establish Performance Measurement Baseline (PMB)
• Analyze project performance
• Maintain PMB

These activities can be found in the 32 criteria shown below. The colored items are the 11 mandatory criteria needed for the success of any project independent of Earned Value.

1. Define the WBS - Chapter 3.4.3

2. Identify the organizaiton - Chapter 4

5. Integrate the WBS and OBS - Chapter 4.3.2

6. Schedule the work - Chapter 5

7. Identify the products and milestones - Chapter 2.4 (basics), Chapter 3.2.1 (Charter)

8. Set the time phased budget - Chapter 6

16. Record the direct costs - Chapter 9.2.2

23. Determine variances - Chapter 9

25. Sum data and variances - Chapter 9

26. Manage action plans - Chapter 10

28. Incorporate changes Chapter 10

Quote of the Day

Remarkable Claims Require Remarkable Proof

‒ Carl Sagan

Risk Retirement

I posted a series of articles on Projects @ Work around the 5 Questions a Project Manager must ask and answer for success. In that material there was a discussion of Buying Down Risk process. This is different than risk mitigation or other handling processes.

The concept of buying down risk starts with a little understood concept.

When the risk becomes and an issue and must be mitigated there is good chance there will be no time or money remaining to "handle" the risk.

The approach shown here is the make the risk go away before it becomes a issue and has to be handled.

In this example there is a risk that the weight of the vehicle will not be compliant with the planned weight at this point in the program. Each Technical Performance Measure has an upper and lower bound for its target compliance as the program moves from left to right. This is the very essence of emergence. On day one of the program it may not be possible to say exactly what the weight, or the MTBF (in the example below) is going to be sometime in the future. The program has to buy down the risk that this might not occur as planned.

The key here is as planned. For any credible Integrated Master Schedule to be in place, we must know the day and the cost to reach a pre-defined Technical Performance Measure.

This is the curse of many IT projects. The term technical debit is commonly used to describe the mortaging of the future from the failure of the past to show up on time, on budget and on performance specification.

So if we're outside the planned performance bands on the day we planned to be inside the performance bands, than we're late, over budget, and we can measure how far out of specification we are. With this knowledge, we CAN NOT say we are on budget and on schedule. If we're using Earned Value Management, we can't take credit for Cost and Schedule performance if we are not compliant with the planned technical performance.

So, Back to the Question

Buying down risk means spending time and money to stay inside the lines so we are not over budget, behind schedule and off specific, when it comes time to be on-budget, on-schedule, and meeting the performance measures.

Buying down risk is the same as having fire inspections to improve the likelihood that there will NOT be a fire in the warehouse. Not all risks need to be bought down, but for those that will cause your project to burn to the ground, it is advisable to make them go away before they become issues.

Idea Farmers

I just discovered a nice phrase from Jurgen Appelo. IDEA FARMERS.

When someone asks what is my contribution to the profession, the project, the problem, or the situation, I can usually come up with something in short order.

Either through:

• Direct hands on experience - having done it this year with my own efforts applied to the solution. This is a "touch labor" approach the solving the problem.
• A bit of research in the archive - having done it in the past 3 years. Again with a touch labor effort, but the gory details are starting to fade. But are artifacts remaining, reports, data, charts, etc. to show what was done, and what resulted that benefited the customer.
• A deeper search in the archive - having done in the past 5 years. The artifacts are there, but the details are starting to fade.
• Knowing how to do it from the principles - trained, certified, participated in the solution.
• Knowing someone that I know that has done it - the "golden Rolodex" of trusted source of help. This is a critical point in supplying the solution. Someone else provided the solution, but how they did it at the detail level may be different than I would do it. So absolute trust is needed to proceed.
• Knowing where to look - "Google" is our friend - look it up, read guidance, look for example.
• have a book on the shelf - read, study, connect the dots.
• pure intuition - it makes sense to do it this way.

The notion of a Thought Leader is bestowed not stated. So Idea Farmer is better. I tend to associate with Idea Farmers. When presented with a "situation," good Idea Farmers can come up with something quickly, test that idea against the reality of the situation, and get started toward the eventual solution with that guidance.

But there are of course issues with the Idea Farmer aprpoach.

• The ideas have to be credible - the result has to work in some way useful. The means any olde cocka-mamy idea won't work. The notion of Hey let's try this isn't going to produce credible results. There are many ideas otu there that "sound" good on paper, in a book, or at a seminar. That are in fact bad ideas.

Hey let's fill the cracks in the elevator door with a can of that sealant. OK sound good let's put 20 cans around the door. Opps, the sealant goes exothermic and catches fire.

• The ideas have to be actionable in ways useful for the problem at hand - having a idea that is a principle is nice for bar room conversation. Having an idea you can take out into the shop as we would say in the spacecraft business is needed.It has to be out to work to produce some kind of result that can be tested to determine if the idea is a good as we think it is.

Let's introduce agile development to our $200M ERP roll out project. Yep sounds good lots of people are saying this is the way the world is going. Hey anyone here ever done agile on a $200M ERP roll out before? Nope, well let's learn how to do this quickly because the big bosses think it's a good idea too.

• The ideas have to be provably correct to some level of fidelity - once there is some first level test that the idea might work, we need some way to prove it can be scaled to meet the actual solutuon demands.

The outcomes have to be know to some level of fidelity before we start committing other peoples more. Hey, why don't we switch from this application to this other really nice application I saw in a demo last week? What are to "show stoppers" in that application? Gee I didn't really hear any from the sales person when they were demo'ing the product at the trade show.

In the end the Idea Farmer has to possess several attributes for success:

1. Done this before in the problem domain
2. Have demonstrated success with the idea in the presence of all the problem that exist in the current problem.
3. Have measurable success in units meaningful to the decision makers.

From an upcoming Quote of the Day

Remarkable Claims Require Remarkable Proof

If you've got an idea that you've farmed from somewhere else, you'd better be able to show it'll work in the current problem. Otherwise the idea farmer may be useful for collecting ideas but not that useful for solving problems that someone is interested in solving.

This separates the educator from the practitioner. The educator is a powerful introduction to the topic. The practitioner may also be an educator - possibly not as good or well versed in the art of teaching and motivating the students - but can get the job done, while mentoring and coaching others along the way.

Quote of the Day

A well designed system does what it should and doesn't do what it should not

The notion of a system is missing from many discussions. These include the application of Agile. Finding the place in the system means first defining what the system is, what the components of the system are, and how they are connected and interaction.

This starts with what are the desired capabilities of the resulting outcomes. These capabilities are usually missing from the development process, which is focused on User Stories, Features, Scenarios. These have no structured or organized home in which to ask questions about their interactions, dependencies, and collaborative aspects.

Chaos, Complexity, and Entropy

When we hear about complex systems, chaos and how those systems are models of the domains we work in - software development, people based systems, systems of systems - the paper above may provide somoe insight on the limits of extending these principles into the popularizations of these principles.

• Complex system contain elements that interact nonlinearly
• These elements are interdependent
• The structure of these system spans several scales
• Such systems are capable of emergent behavior
• Complexity involves the interplay between chaos and non-chaos
• These systems involve the interplay between cooperation and competition

This is all restating the obvious, but care is needed in drawing broad conclusions.

Knowing the underlying structure of the system is the starting point. Does the system under study have linear and non-linear interdependencies? Does the system exhibit emergent behavior BECAUSE of these interdependencies or is there some other processes?

Questions like this needs some assessment before broad statements like ...

What we call “systems” are nothing more than figments of our imagination… abstractions in our minds.

The system of river fish in the Gunnison Valley is not a figment of our imagine. It is a system even when our college son is not thereto study it when he is home for Christmas. It's still a system, interacting in a non-linear manner - of water flow from Taylor Reservoir and the November snow fall and melt), through interdependent elements - of rock formations, tree roots, river bottom structure, and the Colorado Department of Wildlife hatcheries, on several scales - from the feeding flies for the trout, to the bears, to the fisherman, exhibited in an emergent behavior, with the complex interplay of chaos and non-chaos, and most of all with competition and cooperation - between the natural habitat to the man made attempts to preserve the river.

Just a remider about risk

If you are not managing the project with Risk Management, than you're driving in the dark, with the lights off, while looking in the rear view mirror.

From The Integrated Project Management Handbook, Dayton Aerospace, Feb 2002.