Herding Cats

How To Manage In The Presence Of Risk

When We Say Risk What Do We Really Mean?

The term risk is tossed around way too easlily these days. Just like we toss around complexity, complex, or those other terms that have self induced confusions - leadership versus management, complex versus complexity, coaches versus mentors, responsibility versus accountability or agile versus lean. When we assume - wrongly that definitions don't matter, we're just being lazy.

So back to risk. First of all risk is based on uncertainty. There are two types of certainty

• Aleatory Uncertainty - that arises through the natural, unpredictable variation in the performance of the system under study.
• Epistemic Uncertainty - due to a lack of knowledge about the behaviour of the system that is conceptually resolvable.

We must distinguish between these two types of uncertainty when starting our probabilistic risk assessment for project work. The next understanding is about probabilities.

"probability is fundamentally the same concept regardless of whether it appears in the model of the worldor in the subjective distributions for the parameters. There is only one kind of uncertainty stemming from our lack of knowledge concerning the truth of a proposition, regardless of whether this proposition involves the possible values of the hydraulic conductivity or the number of earthquakes in a period of time. Distinctions between probabilities are merely for our convenience in investigating complex phenomena. Probability is always a measure of degree of belief."

In,  Mosleh, A., Bier, V. M., and Apostolakis, G. (1988). A critique of current practice for
the use of expert opinions in probabilistic risk assessment. Reliability Engineering and
system safety, 20, 63-85.

So How Do We Manage In The Presence of Uncertainty

This first thing to do is NOT assume that the system is emerging in a random manner. That notion provides no support for those funding the project. We must have a PLAN to determine is the project is headed in any direction that will result in it be DONE in any form acceptable to those providing the money.

So we need to start by answering the question what is the probability of some future event. The notion that we can't ask and answer this question is one of those other nonsense concepts. Of course we can ask and answer. You do it all the time. What's the probability of rain today is answered by loking outside or maybe looking in this mornings paper, or even on your Android at weather.com.

Our first step is to not try to manage the Aleatory Uncertainty but to understand the probability distributions resulting from this uncertainty and manage in the presence of this uncertainty.

What's the probability of completing on of before May 3rd, 2013? Good question. What uncertainties are in the current schedule? What's the probability of this projects costing $136M or less on or before May 3rd, 2013? Good question. What uncertainties are in the Basis of Estimate?

Next for Epistemic Uncertainty, we must discover what we don't know. This is called mitigating the risk or buying down the risk. This is one way Agile is connected to risk management. Let's build this gadget and see what happens. From that we'll know more and can remove some of the risk when we build the real thing. This by the way is called prototyping - Dah, been doing that for centuries, don't know software development didn't figure that out.

As an aside there is another approach using Evidence Theory, for managing in the presence of risk. This approach requires more advanced understanding of the project attributes, so for now the approach described here will be the starting point.

Just as an aside

There are differences between terms, this is why we have dictionaries.

One of my favorites is Accountability versus Responsibility. We use a Responsibility Assignment Matrix (RAM) on our programs. It is required by the ANSI-748-B Guidelines. It states who is doing what. But Accountability is not the same as Responsibility. The Accountable person is just that singularly accountable for the outcome. The person - the single point contact for making things happen. No group accountability. The group can share responsibility. But only one can be accountable. This is a notion not well understood in many domains.

Agile versus Lean - ask the Agile and Lean folks for the difference. They are distinctly different at their core. Lean manufacturing may contain some agile processes. Lean Aerospace defined at the Lean Aerospace Initiative is now called the Lean Advancement Initiative.

Management versus leadership - read the US Army Field Manual FM6-22 titled Army Leadership, Competent, Confident, Agile. Notice FM 6-22 is about agility on the battlefield, interesting? Wounder if all those agile management "leaders" have read how real agile leadership works when lives are at stake?

Leadership is the process of influencing people by providing purpose, direction, and motivation
while operating to accomplish the mission and improving the organization. Management is about the processes used to lead. There can be managers, but they most likely follow a process.

Complex versus complicated has nice clean, well established dictionary definitions. I know there is a tendency to make up new words and claim credit, by read Beyond the Hype to see that it's generally a bad idea.

So in the end the Program Manager is Accountable for managing in the presence of risk. The PM can have others Responsible for managing the risks - the Risk Manager. But in the end when the launch vehicle blows up on the launch pad, it's the Program Manager who is accountbale. Our when JP Morgan looses $2B is a risky trade it is Jamie Diamond who is accountable.

 

Trust but Verify and Other Realistic Approaches

Lately there have been several voices that resonant with my World View. Ronald Regan's "trust but verify" is a phrase many times forgotten in our project management and process improvement world. I came across Carol Deckers through a twitter reference from Dan Galorath. Dan provides estimating tools used in our aerospace and defense world and other places like enterprise IT.

The notion of "trust but verify" is close to show me you can produce what you claim you can produce. In the management processes applied to our programs, we start with the Federal Acquisition Regulation, which is essentially based on "trust but verify."

• We have a Validated Earned Value Management System (EVMS). The validation is provided by the Defense Contract Management Agency (DCMA). This validation is the basis of the trust to the customer (the federal givernment) that the numbers provided to them (the customer) each month come from the people, processes, and tools that have been verified. But even with that there is a surveillance process that verifies this trust.
• When the defined capabilities of the product or service produced by the program are agreed on, the Contract Officer (CO) and the contractors management have a "trust but verify" arrangement, with periodic Technical Interchange Meetings (TIM) and periodic Integrated Program Management meetings to "verify" that the trust placed in the contractor to do what is planned to be done is there.

So we're back to the core issue

When an initiative is suggested we need to Trust there is a credible outcome. Otherwise, we'll be spending all our time worried that it won't work. But this trust has to be based on something real:

• It's been done before
• It has references in our domain and context
• The outcomes from the past performance are close to what we're looking for
• The person or firm has a track record of success in this are - this is call past performance

And we need to verify

• There are working examples of the process and its outcome
• Those working examples are close enough to what we want that we can "trust" it can be made to work here
• The numbers for the stated benefits can be verified in ways that give us confidence they are actually true.

This is the source of my constant suspicions around 2.0 and 3.0 effort from individuals with ancedotal experiences and a good publisher. This happens about once a year for the past decade or so. First was Project Management 2.0. The old project management processes were failing. Turns out the project failures for the most part come from failing to follow the old project management processes. I loved one of the suggestion of PM 2.0 that social media was the answer to better project management. Yea let's manage out projects with Twitter. This BTW is the antithesis of agile, where face-to-face is the starting point.

Then the hordes of new and innovative business and change management processes. SoI always start with Beyond the Hype approach to assessing the suggestion. I know some will say you're way to conservative here, You'll never make progress with that attitude. Well we manage other peoples money when managing our programs, so yep you're right.

Shouldn't Complexity Theory and Emergent Systems Start with the Mathematics?

The answer of course is a resounding yes. If we can calculate something we don't have to rely on hand waving, references to populist articles that do their own hand waving, or at least references to dead people who did the hand waving before.

The very notion that a stranger is going to spend good hard earned money to make changes to something that actually belongs to someone else - possible share holders - in the absence of some sort of verification that that hard earned money is going to get returned some time in the future - is well - out of their freck'in mind.

This approach to social systems is based on the belief there are enough people out there who don't have the accountability to the share holders, a contract officer, a government procurement officer, or someone themselves accountable to look after the money, is common. It's common because those getting really excited about changing the world aren't always the ones accountable to those pesky shareholders and contract officers.

That's not to say the world doesn't need changing, because it does. The world needs people who expect it to change from their own ideas. The world needs people who come up with completely new ways to make things happen. But the world is also a cruel task master when it comes to funding these ideas. Ideas that a cheap when they don't involve spending money.

Like getting together at Starbucks to scheme on how to do things better. Like let's fix our status meeting process. That doesn't take much money, just effort. Or let's restructure our organization and not focus on earnings per share instead focus on having harmony among the product development teams first so we can improve EPS sometime in the future. Ah, you'd better have the CFO, CEO and Chairman of the Board, and the Investor Relations VP at Starbucks before you jump off that cliff.

Without some notion of the credibility of the idea of how to change anything, it simply doesn't happen. This of course doesn't stop people from trying, never has, never will. But being cranky and disappointed should not come as a surprise - change is hard.

There is a critical difference between something being possible and something being possible. It may be possible to change to world but is it probable in the domain and context you work. If not probable, it's best to look for work somewhere else.

If We're Going To Make Improvements, We Have To Be Able To Calculate Real Numbers

There are nearly unlimited sources of advice on how to make improvements to nearly anything we could imagine. Not just personal improvements, but business improvements, management improvements, project improvements, technical improvements, world improvements.

I have a bias here shared by many of my colleagues. This bias stems from our domain, for the simple reason, we work where measurement dominates the conversation. We share a World View that performance performance improvement or even performance sustainment starts and ends with measuring things.

Measurements we'd find in the work we do, include but are far from limited from some basic questions that very person accountable for spending someone elses money must ask:

• When will we be done and what is the confidence in that number?
• How much will the thing we're building cost when we're done and what is the confidence in that  number?
• How many people do we need to finish this work on time?
• What can go bad and how are we going to avoid the consequences when it does?
• What can go bad and how are we going to prevent it from going bad?
• When we're done, when will we break even on our investment and what is the confidence in this number?

But that are other measurements in our domain too.

• If we switch from this business system to another business system what will be the tangible evidence we made the right decision?
• If we adopt this new and supposedly innovative method of managing people, what will be the tangible evidence that things have improved and what is the unit of measure of that improvement?
• If we hire a training firm to improve our communication skills, how will we recognize we earned back our investment?
• If we change our organization structure and even our organization how are we going to know we made the right decision?

These questions come about because we work for people who spend either their own or other peoples money. If you're spending your own money (not someone else's) the importance of these questions is less, maybe even nonexistent. It's your money, spend it as you please. But the people that hire us almost always spend someone else's money. Many times they spend the money of a sovereign - the governments money.

The starting point for a look into this world of being accountable for other peoples money, is the book Making the Impossible Possible: Leading Extraordinary Performance, The Rocky Flats Story. This title contains the essence of our World View - Heliotropic Abundance and Positive Deviance and how Complex Projects in the presence of complexity, are managed using this paradigm.

When we say complex projects (or programs) and management at the same time, there is a specific set of meanings to these words. These words are based on Systems Engineering paradigms and the complexities of systems. System is defined in the context of a product or service provided to the people whose money is being spent. Of course this system has boundaries, relationships between its components and of course the relationships between the people working to produce the system or working in the system to produce something.

And also of course the system includes the people building the product or service. But it is the product or service that comes first. Otherwise why are we spending other people's money. Certainty not to increase the self actualization of the people working on the system. That may be a by-product, but rarely do strangers pay us to increase self actualization of our staff. You had pretty much better come fully funtional on the self-actualization front, before starting work on our programs.

All systems - at least all non-trivial systems - have complexities. They may even be complex. There is a science context for these words and a business context as well. In the domain we work, disorganized complexity is rare, for a simple reason. The firms we work for would have been eliminated from the gene pool if they could get the disorganized complexity under control. The systems we work are complex and have complexities.

Now We Get to the Hard Part - and there is Always a Hard Part

In the domain we work, we calculate things all the time. That's what we do, we calculate. We calculate Cost, Schedule, Technical Performance, Labor utilization, investment return, effectiveness of a process, effectiveness of people in their roles, effectiveness of the organizational structure and its behavior.

We calculate suggested ideas for improvement. We ask how would we know? How would we know the suggestion will actually going to work? How would know that the person making the suggestion actually has had success outside of personal experience? Is there are any tangible evidence that the suggestion is actually applicable to the problem we are facing?

So what happens when those making those suggestion don't have this evidence? Do we proceed? Maybe, maybe not. Remember it's other peoples money. We usually start by asking annoying questions - questions that we hope will produce answers in some unit of measure meaningful for our decision making processes

In the absence of these answers that have measures in them - numbers - we tend to lose interest quickly. This was the original problem with Agile. Just Try It works great when it's your money. When it's someone else's money, it's a bit more difficult to proceed with an experiment, without the full acknowledgement that it's an experiment.

When the problem to be solved is a people and organizational problem, the path forward in the absence of some unit of measure is more difficult. We need something that provides increased confidence that is we proceed it'll turn out all right. This can be case studies, reference processes, working prototypes. This is how Agile got going. Small examples of success, that started to scale. But Just Try It is probably not the basis of the decision.

So Here's The Suggestion

When you hear, read, or see a new and exciting approach to an existing problem, first buy and read Beyond The Hype. Then and only then, come back to the suggestion to see if those making the suggestion fall into the category of reprocessing ideas in a new language and passing it off as new.

Now there is great value in repackaging ideas. It may make the ideas clearer, more understandable. But usually anything that has a common name with a 2.0 or 3.0 behind the name should be suspect. Of course all thoughtful managers (or anyone for that matter) should be eager for and open to new ideas. They should also be just as skeptical that the latest sure-fire solution to what they realize are eternal problems that must be constantly managed, is just possible an old idea in new cloths.

They learn, either by instruction or by hard knocks that all suggestions must be actionable, measurable, and connected to tangible outcomes from the suggestions. It's that annoying measurement part.

So proceed with care. Beware of the Hype. Be-aware that problems are constant and pretty much unchanging. The same problems. There are rarely new problems, just old ones that have come back. New and innovative approaches to these old problems need to be tested. But while listening to the 3.0 version of the solution to the 1.0 version of the problem, ask some hard questions:

• Has the suggested approach worked outside of personal anecdotal experience?
• Has it worked in my domain? With the size of the problem I have?
• Have the benefits be verified? Independently verified?
• Has the return on investment been verified? Independently?

And don't listen to that Einstein quote about “You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew.” That was about general relativity and the missing math (Rieman spaces).

Remember - everyone lives by selling something (Robert Lewis Stevenson). Find what they're selling before you buy. Ask those pesky annoying questions about how can I measure what you're selling in units meaningful to me. Don't buy the Hype, buy the outcome.

Agile Project Management

Kelly's Contemplation has a nice post on The 3 Phases of an Agile Project. He starts the example with receiving a project that has few actual requirements. The notion of a traditional - or better yet conventional - approach to project management starts looking for requirements. The agile approach is presented in a way that is typical of COTS based deployment through progressive development of the capabilities of the tool set tailored to the needs of the client.

Here's where traditional, er., conventional, project management fails to deal with the current approach to complex project, program, and product development.

I our Defense and Space program, there is a critical first step, that is baked into the procurement process.

CAPABILITIES BASED PLANNING

What capabilities does the customer want to posses when this project is over? These capabilities are the prerequisites to defining the requirements. Here's an end-to-end process for developing the capabilities description. This looks very non-agile, but these are the principles, put these into practice in a way that best suites your need. But check to see if you've covered off all the steps, because is something is missing, you may think you're being agile, but in fact you're missing a critical piece of data.

The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”

Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.

The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission.

The process flow above is the starting point for Identifying the Needed Capabilities and determining their priorities.

Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program.

In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means.

The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.

Here are the details of how to capture the capabilties needed by the customer. Again do these any the way the best suites your need. But do check that you've got - or are going to get - all the information. Otherwise you get to do the work twice.

Notice that most everything talked about in the post is here, plus some other stuff. Trade offs between capabilities is critical. Assessing the costs and the risks. It doesn't do anny good to charge ahead with everything the customer wants to do if you have no idea of the REAL costs and the REAL risk that is being created by your agile approach.

But defined capabilities through Use Cases and Scenarios is the standard approach in large defense and space programs. There is even a language for doing that - SysML is a systems engineering modeling language for Use Cases and Scenarios. I know that doesn't sound very agile, but on a multi-billion weapons systems (mostly software these days) scenarios are the starting point for identifying the actual requirements.

This is the core concept missing from the PMI approach, the dreaded waterfall approach, the conventional approach. And of course these approaches are no longer allowed in the procurement of system for the Defense and Space industry. Those places procure systems using Capabilities Based Planning.

The picure above is one of 5 processes we use in our Performance Based Management activities in our domain. Next comex the requirements, since we're spending the governments money, they want to know those sorts of things.

 

Quote of the Day

"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." - Socrates

But rememeber, you've got to provide attribution, otherwise they'll think you're a poser. Taking credit for others ideas as your own, or even embellishing them and calling it new is bad form these days.

The 5 Whys and Good Project Management

The notion of asking 5 Whys is part of Six Sigma processes in a variety of domains. Seeking the Root Cause, in a Root Cause Analysis, to standard practice in manufacturing and business processes.

In the Project Management domain, this concept is not so common. I've come to the conclusion that we're mission out on a critical success factor for increasing the probability of success from our efforts.

While participating in an Initial Visit between our client and the DCMA, the Six Sigma processes were described by the DCMA staff, which included DCAA for several parts of the 32 Criteria of ANSI-748-B and the 6 Business Systems needed for program success.

Here's an example of who to use the 5 Whys on your Project

We just got an invoice from Bob's House of Power Supplies, that we don't have a purchase order for. Bob claims he had verbal approval to build the power supplies on short notice and ship them Fed-X to the integrator.

1. Why didn't we have the PO in place before Bob started work? - I needed then real fast and the PO process took too long
2. Why didn't you come to purchasing and get a fast track PO? - I didn't know we had such a thing.
3. Why didn't you make the call to find out options? - I didn't really know who to call at the time.
4. Why didn't our purchasing process handbook inform you of these options? - I don't have a copy.
5. Why are our engineering managers not trained on how to order material? - Where is the training and process surveillance processes needed to provide emergency procurements as well as standard procurements?

In the end the process failed all around. The typical response is I went around the process because the process didn't provide me with the needed capabilities. But in the end emergency procurements are common, and there is a process, just not known.

 

Planning

This is my favorite quote around planning. Mike is an email colleague. We've never met in person, we've talked on the phone and extensively through email. This quote has been the basis of our extension of Capabilities Based Planning for the Program Planning and Controls practice. I use it every chance I get. It sums up the critical success factor for program improvement as well as the critical missing piece for most project failures.

Without a plan that looks into the future for emerging solutions, you'll simply be one of the bad project management examples the agile folks love to quote.

This in no way means you don't follow the plan, but the plan itself has to adapt to the emerging situation. The very notion that you would not respond to change and update the plan is simply nonsense.

Have a Plan, confirm it's the right plan at periodic points, follow that plan. When there is a change of plans, assess the impact of those changes, and make a new plan.

• Frontier pilots file a flight plan before they leave for Seattle with me on board
• The Broncos have a plan for winning the Super Bowl
• Andy Schleck has a plan for winning the Pro Tour Challenge in 2012
• I have a plan to loose 15 pounds before the end of the summer
• Our children have plans for graduate school
• Our clients have plans for completing on or before a date and at or below a cost for their programs, while provided technically compliant products.

Plans are mandatory. Make one, follow it.

Adapt the Plan to the emerging situation.

Without a Plan you'll never know what DONE looks like.

Ignore that silly advice of respond to change over following the Plan

If you respond without a change in plans you're lost and will not recognize DONE when it arrives.

Quote of the Day

What phyiscs tells us about the universe is it's big, rare events happen all the time including life, and that doesn't mean it's special.

- Lawerence Krauss's letcure on Dark Matter and the reason for the universe

Has Your Theory Been Battle Tested?

I'm working on proposal for deploying agile in a federal agency. They have a need to integrate Agile on the development of standard business systems. The first steps are to determine what existing software development processes are in place, what processes can be introduced, and what processes are imposed by the Federal Acquisition Regulation on their set of programs.

So now the real issue. This is not an environment where we can experiment with other peoples money, since that money belongs to the United States of America.

By Battle Tested, I mean a method that has survived the engagements of actual battle in developing software in the current paradigm - federal acquisition. There are many proponents of agile out there who have all kinds of suggestions. A classic suggestion is celebrate learning, not success or failure.

In this celebration approach, who pays for those learning processes? The citizens of the United States of America? Probably not. This notion that we get to experiment on other peoples money, is unique in the domain I work. The domain of being the fiduciary of other peoples money.

It's fine if your spending your own money, or you have written permission to experiment with other peoples money. No problem. Do it. Write up the results, so the analysis of how your experiment might be extended to other domains and contexts in those domain.

But there is this really annoying little problem with spending other peoples money and then trying our new ides.

Do you have any evidence what so ever - beyond personal anecdotes - that your idea will actually work in the current situation?

No? Then maybe you should try it out on your own money, do some peer reviews, have someone elses try it out on there money, do some more peer reviews, then get someone to fund the experiment to see if this wonderful idea actually does work outside your own personal experience.

I know is an annoying, very annoying approach. But when we're assigned to help out and the money needed to do that work comes from a sovereign or a board of directors, it's just that we have an obligation to actually improve the situation, not just use that money to celebrate our learnings.

Unless we got paid to learn something, we probably should show up with a solution in hand. A solution that has worked in several, if not many, similar domains and contexts. Annoying I know.

Planning, Plans, and Execution of the Plan

An interview with Jeff Sutherland and Hank de Velde brings up some important notions in program and project management.

1. The planning horizon is short
2. Plans must adapt to emerging situations
3. Goals are maintained

But there are some critically important aspects here that if ignored will lead to utter failure.

Both Jeff and Hank

1. Are highly experienced, very seasoned, experts in their fields. Both sailing the open ocean, flying the F-4, managing Scrum projects.
2. Have past performance to draw on when the plan encounters a change.
3. Have alternatives in mind at all times. A Plan B, a Plan C, and maybe even a Plan D.
4. Can call on external help when needed.

During a short email conversation with Jeff to determine if we were in country at the same time in the late 60's and early 70's in Vietnam - we weren't - we confirmed that our training, supervision, experiences, and learning opportunities have informed our seperate paths. Jeff's with Scrum, mine less famous with our Integrated Master Planning and Performance Based Management, share one critical thing...

Management in the presence of uncertainty - a matter the domain - requires past experience to avoid failure.

This concept is many times lost in the zeel of deploying agile develoipment or any version of lite.

There is a saying in the military flying business

There are bold pilots and old pilots, but there are rarely old bold pilots

Past performance informs future behavior. Jeff didn't drive around the skies of Vietnam without first having extensive training, the inherent skills to put that training to work, and the seat of the pants experience in the log book to know when to take risks and when to play it safe, or when to stick to the plan and when to come up with a new plan real quick, because an unplanned event just appear in the windshield.

While there are many quotes about planning and plans not surviving the first encounter with the enemy, never is that planning process abandoned in the presence of a disruptive event. It goes like this from actual cockpit experience.

 

• The morning brief (0500) has us departing Phu Bai 0600 to get fuel and pick up the first of the many loads for the day to carry from the ammunition dump to Fire Support Base Bastogne.
• Everyone is briefed, read and understood is the response to the Operations chief, when the plan of the day is pocketed, KY28, codes set and the cheat sheet put in your left arm pocket. All crew on board - let's go flying.
• Fuel on board, load picked up, headed to Bastogne. Radio traffic shows clear LZ for the morning. 40 minutes, the situation starts to turn south, small arms fire being taken from the perimeter of the Fire Base. No problem, everything under control.
• 15 minutes out all clear, proceed is the called from the pathfinders on the ground (Air Traffic Control).
• 3 minutes out hot LZ is the call from the Path Finders. So much for the Plan of the Day.

The Agile Mainfesto and Planning in the presence of reality

• Individuals and interactions over processes and tools
  • Process drives everything. Rouge individuals doing their own thing usually don't get to far.
  • Scrum is a highly disciplined process, with clear and concise step-by-step activities to reach success.
• Work software over comprehensive documentation
  • Working products are what the customer bought.
  • Document may be part of that - the Dash-1 says how to flight the aircraft. It's just as important as a working aircraft.
• Customer collaboration over contract negotiation
  • The contract read and understood in the morning brief is the mutual agreement between the planners of the mission, the receivers of the mission, and the deliverers of the mission.
  • When we don't follow those agreed mission goals, there will be disappointment all around
• Responding to change over following the plan
  • This is the biggest red herring in agile.
  • The Plan is the strategy for increasing the probability of success for the mission.
  • Accomplishing the mission will require changes in plan.
  • Abandoning the mission requires higher level authority and a new plan.

What This Means in the End

• The mission is the starting point for the Plan - be that a resupply mission, sailing around the world mission, or delivering the software system.
• The mission is a contract between the development or delivery team and the receiver of the outcomes of that effort.
• Chnaging that mission requires a change in the contract.
• Without the contract there is no mechanism for implementing the team - a group of individuals who hold each other accountable for a shared outcome
• Customers are always in the loop, they have to be, only they have the real understanding of the mission.
• Change happens. Managing in the presence of change is mandatory.
• The Plan is a strategy for success.
• The Plan can change, but only inside the bounds of the mission, without permission to abandon the mission.

Word Map for Recent Blogs

Definitions, Yes They Are Important

Just finished reviewing my notes from a DAU course on Earned Value and the validation of Earned Value Management Systems (EVMS). In the first hours of the first day, there is a slide that admonishes the students to:

• Use precise terminology
• Use the correct terms

This is because many times terms are used interchangeably and many times incorrectly

For programs applying Earned Value Management

• Earned Value Management Systems (EVMS) - a company's management system and related sub-systems that establishes the relationship between the cost, schedule, and technical aspects of the work. Measures progress objectively with earned value metrics; accumulates actual costs; allows for analysis of deviations from plans; allows for forecasting achievement of milestones and contract events; allows for forecasting estimates costs; and provides for discipline in incorporating changes to the baseline in a timely manner.
• Earned Value Management - a program management tool that integrates work scope, schedule, and cost parameters of a program, in a manner providing objective performance measurement and management.
• Earned Value - the valie of completed work. The same as Budgeted Cost for Work Performed (BCWP).

Who Cares?

Here's why. There are many voices out there how misuse these words. Some are well placed voices, working for brand name computer firms, with platforms that people listen to.

The classic is the complaint that EVM can;t be used on IT projects because it does not measure business value produce by the project. This of course is not only wrong - see the third bullet - it is uninformed. Because of this misinformation, there is now a group of software developers that have come to believe that EVM is not the right tool, simply because of this serious mistake in understanding.

So Here's The Replacement

Earned Value Management is a close fit with the development of software in the agile paradigm. Planning the outcomes in a planning session, assigning costs to the development of the outcomes with the Budgeted Cost of Work Schedule (BCWS) is simple - how may people do you have on this iteration? How much do this cost your firm? How many hours for the iteration x (Salary + Overhead + G&A + Fringe + Cost of Money)? This is your budget for the work that is to be performed.

Someone has to pay. Your firm pays if it is an internal project. Your customer pays if it is external.

What's the schedule - the period of performance for this work? In agile (Scrum) it is the duration of your iteration, the release cycle, the epic, or what ever you want to call the longest period of performance for your work efforts.

Now the reason for Earned Value Management

When the number of story points is defined in the planning session, these might be considered the measure of physical progress to plan, so let's consider them so for the moment. As the iteration progresses, these story points are earned when they result in 100% Physical Percent Complete - the perfect agile term - Working Software (according to the definition and units of measure of working).

The formula (the simplest one) for Earned Value is EV = BCWS x Physical Percent Complete.

In the agile world the Physical Percent Complete is either 0% or 100% for each story and its assigned Story Points. This notion of defining the value the Earned Value up front and then earning it is both an Agile notion and an Earned Value Management notion. What is missing from the Agile notion is the Budget for earning that value. But not problem, almost all Scrum teams have fixed resources assigned during the iteration, so the budget is the number people times their burdened cost.

In the End

Ignoring for the moment the notion of AgileEVM, EVM Lite, and any other made up term - there is ONLY EVM RIGHT - the principles of Earned Value Management are universally applicable to all projects, for the simple reason that project management performance measurement is about:

• Defining what done looks like
• Build a plan to get to done
• Allocating resources to produce th work that delivers the product or service
• Handling the risk encountered along the way
• Using tangible evidence of progress to plan from the work performed to deliver the products or services.

Earned Value Management is about measuring physical progress to plan. It is a natural process of iterative and incremental development. Don't let those supposed experts tell you otherwise. EVM is not about measuring business value. That's another measurement - usually a Capabilities Based Planning, some form of business modeling, or even a monetized Balanced Scorecard approach.

Earned Value Management is about measuring the performance of your development work in units that are meaningful to the decision makers. Story Points have no unit of measure meaningful to the decision makers. Consumption of money is meaningful, Story Points are just an ersatz representation for money.

Content of any credible project performance measurement system

Any system that claims to measure perform of a project needs to provide:

• Planning of all work scope for the project to completion
  • For traditional projects this means a master plan and master schedule for the planned work, the sequence of that work, the dependencies between the sequenced work.
  • For an Agile project this means some way of knowing what done looks like in terms of User Stories or Use Cases bounded by a period of time. The planning of an Epic or a Release can be that bound.
• Breaking down program work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives.
  • For traditional projects this means a Work Breakdown Structure (WBS) for the elements in the final deliverables.
  • For Agile projects this means some decomposition during the planning session of higher level customer needs into Stories or Use Cases.
• Integrating work scope, schedule, and cost objectives into a performance measurement baseline plan against which accomplishments may be measured
  • For Traditional projects, this means a resource loaded schedule, with milestones or Program Events, the needed accomplishments, and the exit criteria for each Work Package in the schedule.
  • For Agile projects, this means a stable development team, some means for forecasting the Story Points that can be produced each iteration.
• Controlling changes to the baseline
  • For traditional projects, this means some form of change control where cost, schedule, and technical performance are assessed on the baseline budget and schedule.
  • For Agile projects, this means some for of customer communication on the productivity of the Agile team as a result of the change request.
• Using actual costs incurred and recorded in accomplishing the work performed
  • For a traditional project, this means capturing costs for labor and materials and measuring these cost against the budgeted cost for the work.
  • For an Agile project, this means knowing the cost of the Agile team over it's period of performance, and collecting the for non-labor activities to confirm the project is meeting the owners budget expectations.
• Objectively assessing accomplishments at the work performance level
  • For Agile projects, there is a built in advantage - working software
  • For traditional projects, defining the tangible evidence of completion is necessary for success.
• Analyzing significant variances from the plan, forecasting impacts, and preparing an estimate at completion based on performance to date and work to be performed.
  • When we create a credible plan, with tangible evidence of progress to plan, the measures of variance are always in the same units as the plan.
  • With this variance information, the project team can now take actions to get back to GREEN.
• Using this information in the company’s management processes.
  • In order to manage anything we need variances.
  • Management now needs to take action and correct the work processes that have created the variances.

Doctor, Doctor it hurts when I do this

The jawbone of an ass is just as dangerous a weapon today as in Sampson's time.
--- Richard Nixon

When we encounter bad management and then construct an alternative to correct, without first assessing how to stop the bad management so we can find the real problem preventing a good outcome, it's called  argument by false analogy.

I've seen bad management produce bad outcomes, so my approach to that bad management will produce good results.

This is a common approach in the replacement of bad project management by alternative management processes.

The managers of our firm so badly apply the PMI principles to our projects, that we need to switch to agile software development to fix our projects.

A similar approach is:

Our managers have applied management practices so poorly, we need to abandon the known principles and replace them with new and likely untested outside of personal anecdotal experience.

In the debate and forensics domain, this is called false analogy. This is seen many times, when the basis of the argument starts with anecdotal experience - it worked for me and a few of my friends, so it'll work for you.

What is Earned Value?

Earned Value Management is a method of measuring the performance of work efforts that have been budgeted and the work planned in a time phased manner.

Earned Value should be named Eraned Budget - you earn your budget for the work.

Why is Earned Value unique in the world of project management?

• Performance is measured by tangible evidence of progress to plan
• Future performance is based on past performance, adjusted for productivity, risk, and technical complexity
• The efficiency of the work is the basis of performance measurement, rather than the passage of time and consumption of resources.

Applying Earned Value is simple

• Define the work in units of measure meaningful to the decision makers. What is the tangible evidence that the produced product or service meets the needs ot the buyer?
• Define the budget and time phasing needed to produce this outcome, or incremental versions of the outcome.
• Perform the work during the planned period.
• Measure the physical productivity from the work effort. The Physical Percent Complete.
• Compare the planned Physical Percent Complete with the actual Physical Percent Complete
• Compare the planned budget for reaching the planned Physical Percent Complete with the actual cost of reaching the actual Physical Percent Complete.

With these numbers calculate the Earned Value for the work performed to date:

With this result - the cost variance and the schedule variance - you can now forecast the future performance of your project. This means that when someone asks how are we doing? Or asks, when will we be done? Or even better, how much will this cost when we're done? You can answer with a definitive set of numbers in units meaningful to the decison maker.

Numbers like:

• If we keep going like we're going, we'll be 87 days late
• If we keep going like we're going, we'll be $102,000 over budget

These types of answers are not available, when you measure progress to plan with the passage of time and consumption of money. While agile suggests that it is doing Earned Value, it does not measure the cost of doing the work, nor does it measure the pre-defined phsyical percent complete in units of techncial performance.

Earned Value provides you with insight into the physical progress to plan, in units of measure you can use to make adjustments to the project to keep on schedule, stay on budget, and provide visibility to the increasing maturity of the products or services your project is delivering.

Here's the next level of understanding Earned Value in Five Easy Pieces.

Teams

Which comes first?

• The social team, or
• The outcome team?

Let's start with Jon Katzenbach's definition of a team. Katzenbach is a recognized leader in counseling high profile CEO's and their staff - the business teams that are at the heart of corporations. His book The Wisdom of Teams was a seminal work for me when I led some of the teams working a large and very complex Department of Energy program.

What struck me, and has never left, is the core confusion of how many in the agile world start with the social aspects of project teams.

First there is another core confusion revealed by Katzenbach.

If you are on a team, who is your opponent?

I played collegiate volleyball. That volleyball team had opponents. Other universities. University of California, Irvine, versus University of California, Los Angeles. Our team had a clear and concise of the outcome - beat UCLA (it rarely happened). But no member of the team was on the team for the social aspects as their first goal. We were all there to play competitive volleyball. While there are a dozen or so members of the UCI Volleyball team, teams can be smaller. The rowing teams that practice on the Boulder Reservoir in a 2 man scull are a team. They are also on the larger team of all scull's - single, 2 man, and 4 man - women as well.

So Katzenbach's definition helps clarify how teams that are formed (paraphrased)

A team is a small group of individuals who hold each other accountable for a shared outcome.

For teams to be successful, we need individuals, accountability, and a shared outcome.

The social aspects of the team may or may not result from the individuals, accountability and shared outcome. The social aspects don't have to have these attributes.

What I've observed over the years, both in my teams, and or now college age children is a migration from the outcomes first paradigm, to the friends and social aspects first. Good for them. But I'm waiting to see how well this turns out in practice.

If the first condition is to form a social unit, that is stable and has an identity, can they actually get the job done. Having a shared outcome as the starting point may allow the team to ignore the social aspects until there is evidence that the shared outcome and the mutual accountability are in place and the members actually want to participate in the social part of the team.

On the volleyball team, the mutual accountability was in place. It had to be in place, or we would not play well. But the social unit was nice, but not necessary. It was - and is - the mutual accountability that was the basis of success.

So 3 people working together for 2 months is a Team if - they have a shared outcome and hold each other mutually accountable for that outcome.We can have a team of golfers playing in a tournament on our course. We can have a spring clean up team at the park. If they are holding each other accountable for a shared outcome. Win the scrable or clean up the winter branches.

Remove the need for the social, stability, and identity as the first condition. The team is still there, it's doing its work for that period of performance, and most of all they are holding each other mutually accountable for that work.

Social, stability, and identity are all very nice outcomes. But they are not the core conditions for success of a team.

When those shared goals start appearing, and the mutual accountability is working, the social, stability, and identity come naturally as a result. The other way around may not produce the same result, simply because the shared outcome - the teams goal - is not based explicitly on mutual accountability.

Quote of the Day

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science — Lord Kelvin

When we contrast that with Einstein quote

Not everything that counts can be measured. Not everything that can be measured counts.

We need to ask what is the context and domain of the measurement. If you're accoutable to the stockholders of investors, maybe you want to consider measurement as a starting point for your success.

Sources of Variance

Cost variances on projects come from a variety of sources. Here's a picture of some of the drivers that are common in many domains.

The management of projects means you have to address these and many other activities to answer the questions posed by 5 Immutable Principles:

1. Where are we going?
2. How do we get there?
3. What resources are needed?
4. What impediments will be encountered?
5. How is progress to plan measured?

These impacts on cost variance are part of principle 1, 2, 3, 4, and 5. They are part of all the principles, because without a credible understanding what the project is going to cost in the end, the management processes of the project itself are no longer credible. You're then just spending other peoples money with no connection to producing value - yes the business value.