Herding Cats

Capabilities Explained

Brad Egeland has a nice post on Project Definition. Brad speaks about project objectives, assumptions, and associated attributes.

While these approaches serve the project well, an "offical" approach used in our defense domain is a Capabilities Statement. Here's our overview on this topic.

And the explaination of this chart that is on the left facing page

If you start with a Capabilities description, you can add Brad's attributes to the pile.

Managing Projects in the Presence of Unknown Unknowns

The term Unknown Unknowns (UnkUnks) is used in risk management and politics to define an event that no one anticipated. A "low probability event" or a "Long Tail" in probability distribution terms is refered to as a "Black Swan."These are sometimes mixed together, confused between each other, or used in exchange of each other.

The most famous recent quote is Rumsfeld's UnkUnk appearing during the Iraq War.

"There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns; there are things we do not know we don’t know." — United States Secretary of Defense Donald Rumsfeld

Nassim Taleb famously uses Unknown Unknowns for his Black Swan analogies. These two authors are sometimes connected in a group of those reminding us that the future cannot be forecast. While Rumsfeld is not in the same class as Taleb when it comes to anti-method language, Taleb does fit into the class of intellectual nihilists . Taleb thinks all quantitative analysis of finance is nonsense. Much in the same way some agilest think software development is not engineering discipline but a "emergent" process pf personal revelations of the needs of the users. This is harsh I realize, but it makes the point that forecasting the future is done every day and deailing with UnkUnks is part of that forecasting.

But let's look at one definition of Unknown Unknowns.

In epistemology and decision theory, the term unknown unknown refers to circumstances or outcomes that were not conceived of by an observer at a given point in time.

There is a critical concept here - conceived of by the observe at a given point in time. This means that in some domains an UnkUnk is a very short sighted and "small world" view of the categories of risk. This categories are well defined by De Meyer, Loch, and Pich's in "Uncertainty and Project Management: Beyond the Critical Path mentality" as:

1. Variation - in activity durations, costs and the exact performance level delivered by resources is a common source of project uncertainty.
2. Foreseen risks - are identified but uncertain influences in a project
3. Unforeseen risk - are not formally identified in the project planning stage, that is, they
   are not anticipated, and a “Plan B” has not been formulated.
4. Chaos - refers to the fundamental uncertainty about the basic structure of the project
   plan itself.

The question is Could these supposed UnkUnks have be revealed? How much would it cost in time and money to discover the outcomes at a given point in time?

Or another question might be, are there UnkUnk's that are simply not "knowable." In the physics world (my area of education and first practice) there are many things that are not known, but that does not mean they are un-knowable. There is a difference between Unknown and Unknowable. This is sometimes not well understood in the project management world. There and in the software development domain, not much is unknowable, with the right amount of money and / or time.

Those speaking about UnkUnks often do so in situations guided by the Dunning-Kruger effect

When people are incompetent in the strategies they adopt to achieve success and satisfaction, they suffer a dual burden: Not only do they reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the ability to realize it.

Rumsfeld's comment is classic. In the Vietnam era, the same approach was taken. Francis Fitzgerald's book Fire on the Lake: The Vietnamese and the Americans in Vietnam. We entered Vietnam with very little understanding of the culture and consequences. There were UnkUnk's but they were of the Dunning-Kruger type.

So Now How Can This Be Applied to the Project Management and Software Systems Domain?

 Let's start with another definition from the Business Dictionary:

Future circumstances, events, or outcomes that are impossible to predict, plan for, or even to know where or when to look for them.

While not the OED, it is indicative of the problem in this domain. This definition does not say the unknowns are UNKNOWABLE.

So why would you - as a project manager - embark on a project, that has Unknown Unknowns? Only to then encounter them and claim "well we came across an UnkUnk that killed our project."

Why would you as a manager of a software development project, embark on a mission critical, possibly life threatening (physical or financial) endeavor, and abandon good engineering practices - and worse claim that the development of a product that is somehow "critical" to the success of the firm or mission without a process framework that guides the development of the outcome?

If we move back from the epistemological aspects here and talk about Project Management and product development, the use of UnkUnk's may be seen as a excuse for not "doing your homework." Looks pretty lame to me.

Even more lame when you are spending someone else's money. Or even more than that when you're spending other peoples money for you to have a high probability of success.

Quote of the Day

Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about.

Marcus Tullius Cicero (196BC - 16BC), De Officiis, Book 1, Moral Goodness

What is a Plan?

Brad Egeland has a nice post about planning. He mentions three benefits of Planning:

1. Reduces uncertainty
2. Increases understanding
3. Improves efficiency

This is a good starting point, Planning is Good. But why is Planning good? First what is a Plan?

A Plan is a strategy for the successful completion of the project

The plan describes the "path" to the end. The Plan describes what "done" looks like. Not only at the end, but along the way to "done." The Plan describes the increasing maturity of the deliverables of the project. The units of measure for the maturity and when a specific value for this unit of measure should be present. This means the plan has a sequence of increasing maturity.

The Plan is NOT a Schedule, which is time based. The Plan is seqeunce based, relationship based, and maturity based. The Schedule tells us "when" this maturity should appear.

Here's an example of a "Plan"

The Plan shows the increasing maturity of the deliverables, moving from left to right. How at each point along the path to "done," the dependencies are related, and how they support the final deliverable.

At the points of assessment, there needs to be a set of assesment criteria to assure that the planned maturity has been reached. These measures of progress to plan can be Technical Performance Measures, quantities of material, or some other type of measure.

Turning the Plan into a Schedule

With the Plan established, at least in the first version - since Plans do change, we need to Schedule the work to cause the deliverables (intermediate and final) to appear.

In this diagram the "Plan" part is represented in the Program Events - the capabilties that are "planned" to be present at each assessment point in the project. The "Accomplishments" needed to provide these capabilities are defined in the "Plan." The "Criteria" for each of these Accomplishments - the measure of compliance with the planned maturity - are also part of the "Plan."

With these elements - arranged in a hierarchical structure, the "Work Packages," that perform the work are developed. The sequence of the Work Packages are the top level of the Schedule. The work inside the Work Package can be sequenced as well. But the starting point for the schedule is the sequence of the "Work Packages"

Once the "Work Packages" are sequenced, a Program Master Schedule is the result.

This is the master level sequence of work that is not Time Phased - a schedule. Below the Program  Master Schedule are Intermediate and Detailed schedule. Each defining increasing details of the work, down to the Work Packages and the Tasks or activities within the Work Packages.

An Intermediate Level schedule might look like this.

At the Intermediate Level, the dependencies that connect the major deliverables - the increasing maturity deliverables - are show. Below this are more levels of detail. The Master, Intermediate, and Detailed schedules are actually ONE file (.mpp in MSFT Project).

There are tools like, Chronicle Graphics and Kidasa Milestones that can be used to make nice Program Master Schedules from the detailed and intermediate MSFT Project schedules.

But in the end all this startes with a PLAN - a Strategy for success and the measurement points along the road to that success.

Risk Management Guidance

Risk Management on projects is well understood in some domains and poorly understood in other.

It is remarkable that a science which began with the consideration of games of chance should become the most important object of human knowledge - Pierre Simon, Marquis de Laplace (1749-1827), in his book “Analytic Theory of Probabilities”

First let's establish a definition of risk.

The DOD D5000.2 defines risk as “a measure of the inability to achieve program objectives with defined cost and schedule constraints.”

I say "a"definition, because there are several definitions. It's critical to establish the definition of risk before starting down the path of managing risks.

Then let's establish some "rules" for risk management. These come from Risk Management Process
& Implementation Practice Book Number One: Overview and Guidance Little Aqua Book, Prepared by
American Systems Corporation, 13990 Parkeast Circle, Chantilly, VA 20151-2272.

• RULE 1: Projects that don't manage risk are at risk.
• RULE 2: Risk management is not free; prepare to commit resources, define a risk management process, and make a risk reserve available.
• RULE 3: Centralize risk management responsibility; distributed responsibility must be coordinated.
• RULE 4: Prioritize risks and only deal with the most critical. All non-negligible risks must have mitigation strategies.
• RULE 5: Program managers are responsible for action; risk managers are responsible for risk identification and follow-up.
• RULE 6: The risk management process must be defined and consistently implemented throughout an organization. Activities must tree up to the organization’s risk management policy.

Here are some sources of Risk Management that can guide you through the mase (listed in order of importance)

• Effective Risk Management: Some Keys to Success, 2^nd Edition, Edmund H. Conrow, AIAA 2003.
• Managing Risk: Methods for Software System Development, Elaine M. Hall, Addison Wesley, SEI SEries on Software Engineering, 1998.
• How to Lie with Statistics, Darrell Huff, W. W. Norton, 1954.
• Development of Risk Management Extensions to the PMI Project Management Body of Knowledge, Dr. Edmund Conrow, Acquisition Quarterly Review, Spring 2003.
• RISK MANAGEMENT GUIDE FOR DOD ACQUISITION Sixth Edition (Version 1.0).
• The Death of Risk Management, 2008 NDIA Systems Engineering Conference.

Thanksgiving 2010

Be not forgetful to entertain strangers. For thereby some have entertained angels.

Hebrews 3:12

Quote of the Day - Risk

One should expect that the expected can be prevented, but the unexpected should have been expected. - Augustine Law XLV, Norm Augustine

The notion of Unknown Unknowns is simply an excuse for not looking further into the pool of risk and for not designing a "system" that is Fault Tolerant, when the pool of risk contains a risk that was missed. Any other approach is a failure to properly manage the risks. This approach comes from manned space flight, nuclear power and other domains where people die, either by accident or on purpose.

Failure to learn how to identify and handle risk is a common cause for most IT project failures. The risks to the IT project include all the common mistakes of poor risk management starting with communication failures and all the softer side of management. Moving to the technical risks, and on to requirements, development, training and deployment.

In an IT project there is no such thing as a Unknown Unknown. IT projects are not inventing new physics, flying to distant planets, or pioneering new drugs. They're simply capturing requirements, writing code, testing this code and deploying the system. No one dies, no one is "lost in space." There is no excuse for not having a credible risk management process in IT.

Techncial Performance Measures - Update

The use of Earned Value to measure program performance is well established. The "earning" of value for the work takes place when physical progress to plan is done. The simple formula for Earned Value (Budgeted Cost for Work Performed) is

BCWP = BCWS x Physical Percent Complete

The budgeted cost for that work BCWS (Budgeted Cost of Work Scheduled) times the Physical Percent complete is the "earned value." This measurement takes place at the time we planned to have a physical percent complete. 

That is, were are in terms of physical percent complete NOW compared to where we planned to be in terms of physical percent complete NOW. This measure is not the same as how much money did we spend compared to how much money we planned to spend.

While this process is powerful, there are some missing elements. What is the quality of the product produced at this point in time compared to the planned quality at this point in time. Quality is one measure, but there many others. A more general purpose term is Technical Performance Measure. These are all the measures of the performance - quality, all the "ilities," anything that is NOT cost and schedule.

Here's the current training session from PMI College of Performance Management (the EV college).

This briefing is one part of a large set of training materials given at two conferences a year. One in the DC area and one in Florida. You can find all the presentations at  the College of Performance Management site.

Cpm500 d _alleman__tpm jun 2010 lesson 3 (v2)

View more presentations from Glen Alleman.

There are several critical learning's here:

• Knowing what done looks like means knowing what technical performance measures must be met at what points in the schedule.
• Adjusting performance measures and forecasts of future performance depends on knowing how well you are meeting the Technical Performance goals and how correctly any deficiencies will impact cost and schedule.

Connecting Projects With Strategy

Ron Rosenhead posted a comment titled "Prove the Benefits of Your Project - Or Lose The Money." This is a constant discussion in the IT world, where the mission and vision of the project has not been established.

Balanced Scorecard has served me well over the years in "connecting the dots" between the Strategy of an organization and the projects that are supposed to support that strategy.

Connecting Strategy with Tactics provides "Line of Sight" for both sides of the equation. Here's how to do it.

In the upper left of the Balanced Scorecard Strategy Map. In the lower right is the traceability between the strategies and the performance measures for the projects implementing the strategies.

Competency Based Management

There are suggestions that competency based project management. Boston University has a model. Ruth Murray-Webster and David Hilson's paper, "Scaling the PEAKS of Project Management Competency."

Here's a quick summary of what it means to be competent for our Control Account Managers.

Now the challange is "how to measure these."

Project Management as College Football

   

There are many analogies for project and program management. Orchestras, jazz groups.

My favorite is college football, for many reasons.

• We live in a college town, with a Big 12 going to Pac 10 football team
• One of our children goes to CU (University of Colorado, Boulder)
• The Buffs have a long history, some times good some times bad.
• The Buffs have the best mascot every - a live Buffalo. Ralphie - pictured above gets to run around the field before kick off and before the 2nd half.

But project management is like football because:

• Football has multiple layers of management.
• Football has highly organized playbooks.
• Football has specialist and generalist all on the field at the same time.
• Football is chaos on the field, when the play is broken.
• Each has a specific job, but that job is expanded to "any" job needed to stop an offensive play, or defend against a play.
• Football is a team sport and at the same time success depends on the performance of individuals doing their job and maybe the job of others.
• Football requires discipline, strength and most important AGILITY. A 275lb middle linebacker is VERY agile on his feet.

Some Details

• There is a play book. The summary pages of the play book is on the arm of the quarterback. The quarterback calls the plays to the team. These plays are developed and organized by the coaches and many times called in from the sidelines by the coaches (command and control). The plays are detailed to the point of how many foot steps are to be taken before a player takes the next action:
  • Run down the field 13 steps, turn to the left, receive the pass sent your way.
  • Block the opponent by starting on your left foot and hitting him "on the numbers" to push him to the right so the running back on your left can come through the hole in the line you just created.
• The plays NEVER go according the plan
  • The play emerges as the players engage each other
  • But without a detailed PLAN and the practice of that plan, your team would be literally "run over" by the opponent.
• The head coach and the other coaches "train" the players to follow the game plan.
  • Detailed execution drills are done every day during the season. "two a days" before the season.
  • Players "learn" their plays by repeated exercise. They know what to do in each situation by repeated practice. They can execute their plays when called on by the quarter.
  • They can figure what to do beyond those plays in a split second, when the game is in motion - thinking literally "on their" feet as the action emerges in front of them in split second decisions.
• The athelitic Director "guides" the mission of the football team, with funding, recuriting, hiring and firing.
• The Head Coach "manages" the team from start to end. In the locker room, in the office, on the road, on the side lines. The coach is the "leader" of the team when the play is not running. The quarterback is the "leader" of the team when the play is running. The Captain(s) are the leaders of the team.
• The other coaches "manage" their speciality disciplines
  • Offense
  • Defense
  • Special teams

In the End

• Deatiled plans are made before every game
• Plans are executed according to the stratgey
• This strategy "emerges" as the game proceeds
• Once a plan is called, the execution "emerges" as the opponent reacts to the plan.
• Defense has plays as well that react to the offense's play
• Individual contribute to success
• The team as a whole must play as a single unit
• The "command and control" from the quarterback, the sidelines, and the observes from above must all interact in seamless harmony for the next play to  be success
• Sometimes, pure chaos reigns and sometimes that chaos is the key to wining
• But most of the time disciplined execution of the plan is required just to survive.

Go Buffs

More Agile Claims

Dennis Stevens provides a presentation on Agile Foundation, Promises, and Myths. Dennis almost always has good things to say about agile and its application to business environments. But this time his post misses the mark and starts down the slippery slope of unsubstantiated claims right out of the gate.

He begins with the classic comparison between agile and something else, he's compelled to title it "predictive," not realizing that ALL good project management methods are based on the underlying probabilistic nature of project work.Managing in the presence of uncertainty actually requires predictive skills. Dennis uses the term predictive against a method rather than for it.

Even our beloved DoD 5000.02 (The DoD procurement standard) mandates statistical risk analysis of cost and schedule, and the System Engineering standards do the same.

I'll got through a couple of the slides to make the point in the "predictive versus agile" argument.

The Predictive Approach to  Software Development

To improve software delivery we need to:

• Standardize processes
• Optimize resource utilization
• Perform rigorous upfront design
• Produce comprehensive documentation
• Get commitment for definitive Scope, Cost, and Schedule
• Enforce strict adherence to the detailed plan

Let's look at some details

• If we don't have a standardized process, it is a challenge to syndicate the work effort beyond the current group
  • What happens when a new project comes in the door and the current team is occupied?
  • Wat happens when the current team moves on a a new team starts a project?
• Direct labor is usually a major portion of any software project. Fingers on keyboards costy money.
  
  • Optimizing the absorption of direct labor costs (plus G&A, Fringe, ODC to run up the actual cash flow to 25% to 35% of salary) is a concern for any business
  • Optimizing this cost is simply good business
  • Even the Federal Government - strange at it may seem - is critically concerned about "run rates" on programs
• The myth that rigorous design up front is done these days seems uninforme, and a bit long in the tooth. 
  • Iterative and incremental design is part  of any large project management governance process
  • This is one of those "red herrings" that agilest love to use.
  • It's actually prevented in DoD 5000.02 procurements. Rolling waves, incremental milestones are mandated.
  • Anyone doing rigorous design up front beyond the ability of the project to verify and validate that design is of course wasting time and money.
  • Stop doing stupid things on purpose. This is not the unique venue of Agile, NASA, DoD, and DOE do all have incremental and iterative design process.
• Producing the documentation requested by the customer is usually a good management choice.
  • Classical red herring
• Getting commitment for Scope, Cost, and Schedule is usually a good thing to do  when you're spending other peoples money.
  • Spending your own money, who cares, it's your money
  • Spending the share holders money, they may like to know what you're going to do with their money.

Predictive Approach Underlying Assumptions

Scope and Variation

• All Requirements are knowable initially
  • This is simply nonsense.
  • We work multi billion dollar programs (software intensive) that have emergent requirements at all levels of the program
  • Our manned space flight program has changed its mission 3 times in the last 4 years. Major and I mean major impacts on software, hardware, firmware.
• Requirements can be documented completely up front to guide development
  • I'm calling BS on this notion.
  • Even the formal Systems Engineering guidelines applicable to our program for NASA know better.
• Tasks required to deliver requirements can be precisely known and estimated
  • BS again, this is simply bad systems engineering.
  • Only the currently active work packages have "definitized" work scope and durations.

The Presentation goes on to say

• Software engineering  is linear in nature - really where does it say that. I was a contributing author to the Software Engineering Body of Knowledge and I sure don't remember writing someting like that.
• Manufacturing-centric practices apply directly to software engineering. "Got any references?" Maybe a look at CMMI-DEV 1.3 would inform the conversation a bit more.

The Dennis moves into the Apples and Oranges Comparison Mode

• In the predictive approach - the best way to finish projects faster is to dictate that all tasks finish on time.
  • Hate to say this Dennis, but if task don't start on time, they aren't going to finish on time.
  • That's a fundamental law of physics for projects.
  • If you can find a way to start late and finish on time, you've got one of two things.
    • A magic wand
    • Sand bagged estimates to complete
• The flaw, Dennis suggests is there is natural variation in estimates
  • Yes, read DID 81650, all the Monte Carlo estimating processes used for cost and schedule estimating in CMMI and the GAO, NASA, Air Force, ITIL, NAVAIR and everyone else's estimating guidance.
• The highest ROI depends on maximum resource utilization
  • Uh, That's be a NO.
  • Show me the math and stop BS'ing us.
• Planning every detail up front results in stable projects
  • Ever hear of "rolling waves," "progressive development," Milestone Decision Authorities?
  • These are mandated in complex project domains.
  • The frequent delivery notion is NOT, I repeat NOT unique to agile. In fact agile did not even discover this, they just revealed it to those working outside the defense and space business.
• Study the problem till you everything
  • Now I'm understanding Dennis is making this stuff up...
  • That is also mandated to NOT happen in any credible procurement process.
  • Even our simple Deliverables Based Planning® method is incremental and iterative Project Management

I stopped reading after that

Why do these types of presentation make it to the light of day. No credible program manager in space and defense would do these things. If an uninformed IT manager does, then she gets what's  coming to her - a failed project.

Don't do Stupid Things On Purpose

Was a Poster hanging in the lobby of a nuclear weapons reclamation project, Golden Colorado.

Please do not buy into the notion that project management processes not labeled as agile are somehow flawed. That is a false argument at best and at worse deceptive. Seek out how to apply the 5 immutable principles of project management to your project - be it a traditional project or an agile project.

Then maybe you can recognize "smoke and mirrors" when it arrives in your in box.

 

When Agile Says "Value" What Do They Mean?

A paper in the current edition of Systems Engineering, Vol 13, No, 4, 2010, has a paper titled "Value Creation in Program and System Engineering Processes." The abstract reads.

Almost every large system is initiated with an intention of building something, which has new value to its stakeholders. Yet, turning this simple statement into reality is often problematic since the concept of value is not always explicitly defined or structurally incorporated in the formal frameworks of program planning and systems engineering. Quite often, beyond traditional financial measures or technical and operational requirements, there is little agreement of what program value really means, and there are limited theoretical models that could help conceptualize and focus its essence. In this exploratory study, we investigated the components of program value in several major defense programs that were nominated for Aviation Week’s Program Excellence Award. Among other things, these programs had to declare what value their product created. Our findings resulted in an initial framework, which identifies program value according to three major groups: value to the customer, value to the performing organization, and value to the team. The specific value components identified in our data suggest that program value could be formally and explicitly integrated into program planning and systems engineering processes. It can also lead to further research and new applications that will be focused on value creation, rather than just meeting performance and technical specifications. © 2009 Wiley Periodicals, Inc. Syst Eng 13: 340–352, 2010.

For any nontrivial project, the identification, management and production of "value" in projects is the domain of Systems Engineering and the programmatic controls groups, along with the engineers.

The measure of value must be in units meaningful to the decision maker. In most cases this means measuring value in dollars (or some currency).

The Poverty of Project Management Role Definition

Recently the bulk voices in the project management literature are talking about conversations, people skills, tools (PM2.0 tools), and a variety of other 2nd and 3rd order things. While these may be necessary for success, they are far from sufficient.

Some of my favorites come from PMI and voices at PMI.ORG and those firms "selling" project training services based  on "human skills," personnel development and all the stuff around things that have little or nothing to do with actually delivering outcomes. "Bending metal into money," is one phrase we use.

What Does Done Look Like for Being a Credible Project Manager?

To be not only necessary but also sufficient we need 5 pieces of information:

1. Do we know where we are going?
   • Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now.
2. How are we going to get there?
   • Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.
3. Do we have enough time, resources, and money to reach the end?
   • Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.
4. What is going to prevent us from getting there?
   • Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Do we have some way of measuring physical percent complete?
   • Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

If we don't have credible answers  to these 5 questions, all the people skills, tools, touchy feely courses, facilitator consultants in the world are going to save you from failure.

This approach, while annoying to many, is the core bottom line for our value as project managers. Without credible skills to answer these 5 questions, we have no value to the project.

One Approach To Project Management

When I hear about a tool, a proposed method, some clever new approach, I always think about the words I hear every week on the programs we work.

Be eternally suspicious, take nothing for granted, investigate everything. Program success is obtained only by enormous attention to detail everywhere.

Challenge every proposed item to produce tangible evidentiary material to demonstrate effectiveness and performance. Measures of Effectiveness (MoE) and Measures of Performance (MoP) are core concepts in Systems Engineering. These need to applied to project  management. 

In the End

The success of a project depends on showing up near the planned completion date, near the planned budget, with enough of the needed features to put the outcome of the project to work. Each of these elements are subject to change (through the change control process).

But no matter the mechanics, the management of the work effort must answer the five questions posed at the top of the post.

Without answers, the project manager and the techncial staff as simply spending the customers money with little hope of success. In fact "hope is the only strategy" at that point.

Quote of the Day

Successful people are always looking for opportunities to help others. Unsuccessful people are always asking, "What's in it for me? ~ Brian Tracy, American business author

Domain Dependent Concepts

I'm surprised some times by the differences in domains and contexts in domains and some general notions of project management.My suprise is how simple concepts in one domain fail to make into other domains.

One is Mosaic Project's White on Duration Estimating.

Apart from very small short term projects (3 to 6 months and under $200,000) attempting to directly integrate the cost estimating process with the scheduling process in fraught with difficulty. Even on these smaller projects, direct linking is not really feasible unless the primary source of all costs is staff directly employed on the work.

This type of planning and controls is simply not allowed in programs subject to Earned Value for governments, including the Australian government.

Without connecting cost and schedule as well a technical performance measures, probabilistic risk and cost and scheduled margins you cannot build a credible Performance Measurement Baseline( PMB).

The concept in the last sentence cannot be true as well. The PMB includes Labor and Non labor Cost Element Relationships (CER).

See the current GAO Cost Estimating and Assessment Guide for how to integrate cost and schedule.

Without the integration of cost and schedule, the program cannot be managed to success.

Here's why:

• Cost drives schedule
• Schedule drives cost
• Subcontractors on FFP (Firm Fixed Prices) still have cost and schedule spreads inside their FFP subcontract. They have cost and schedule coupling.

It's this coupling between cost and schedule, along with the compliance with Technical Performance Measures (TPMS), that is both the source of problems and the source of transparency in program controls.

Here's the Pictures

The Peformance Measurement Baseline (PMB) is composed of the following elements:

• IMP/IMS - Integrated Master Plan / Integrated Master Schedule
• Cost baseline
• Statement of Work (numbers tracing the deliverables to the work delivering the work)
• Technical Perfomance Measures
• Work Breakdown Structure (the products and process structure that produce the products)

The connections between Cost, Schedule, and Techncial Performance drive the needs for "margins."

 

So the Mosaic paper is a good starting point if yuo ignore the conjecture that connecting cost and schedule is fraught with difficulty. Yes it is difficult. It is also mandatory for success. In the absence of these connections, including the TPM's you don't have visibility into the risks that drive the project.

If you don't have visibility into these "drivers" you're likely late and over budget before you start and you probably don't knwo it. No wonder many projects are in trouble.

Yes it is hard, that's what we get paid for.

More Long Tails

Our book club is reading Colossus, Michael Hiltzil. There is great quote early in the book, when the Imperial Valley in California was being developed by private interests.

There's a great quote from an effort in 1922 to dam and divert the Colorado River using a simple method of blasting canyon walls to form a dam.

A rock filled structure might be cheaper, [but] we can not be sure that this will be the case. If some unforeseen difficulties .. should be encountered, its expense might be greater than that of a concrete structure.

What finally tipped the scale against the rock dam was...

We can not be sure it would entirely safe.

When there is a discussion about "long tails," and the lack of knowledge and its impact on a project, there must be clarity around the very notion of Unknown Unknowns.

Unknown Unknowns must be isolated from the process. Put outside the "project," to have minimal or no impact on the outcomes. Since by their definition that are "unknown," if you let them on to the project, you'll be assuming risk that has Unknown Unknown probabilities of occurrence and Unknown Unknown consequences.

Why would anyone do this on purpose?

If you don't ask what don't we know about, and what are we going to do about these unknowns, when they become known. The simple answer - and the best answer - is to bound the project to operate within the Knows. That is isolate the boundaries of the project to the known probabilistic risk.

Then have the project adopt a behaviour in the presence of risk outside the Known - Unknown Unknowns, that is "fail safe." That is, the project must operate in such a way that it "fails to safety."

 

CMMI-DEV 1.3 Released

CMMI-DEV 1.3 is released. While those in the agile commmunity may not see this as important, for those of us managing or participating in the development of enterprise and government software intensive programs looked forward to the upgrading of several Process Areas.

You may ask "how cares" about CMMI-DEV outside of government? Good question. Here's the inverse question.

• Using the field data from SEI that connects process maturity with increases in success of software projects, how does a proposed development process fit into the Process Areas (PA) of CMMI?

In other words how does any proposed software development method show it can increase the Probability of Progam Success (PoPS)?

 

 

 

 

 

Managing in the Presence of Uncertainty

Pat Weaver and Lynda Bourne of Mosaicprojects have both made thoughtful arguments about dealing with the unexpected and how some may operate under the illusion that controlling the future is possible. In this discussion there seems to be a mixture between what is possible and external observations of "rare" events in the presence of expectations and intentions of those who build systems that are designed to fail safe.

These failures can be technical, operational, and even programmatic. A blog page is a very narrow channel to discuss the complexities of nuclear power plan failure modes, high voltage substations powering large particle physics experiments, or any other "complex system."

What has helped me comes to an understanding of how the "management in the presence of uncertainty," is the writings of several authors. Here's a short list of papers and books that can shed light on this complex and sometimes confusing topic of "managing risk." The first list can be located at the INSEAD site or with a little effort through Google. INSEAD provides a free membership for its research. So I won't provide the link, since you have to log in to retrieve the documents.

• "Adjusting project management techniques to uncertainty," Christoph Loch, Michael Plch and Arnoud De Meyer, INSEAD.
• "Diagnosing and Managing Unforeseeable Uncertainty to Improve Venture Capital Returns," C. Loch M. Solt and E. Bailey 2004/101/TOM, Working Paper Series, INSEAD.
• "Decisions Under Preliminary Information: Rush and be Wrong or Wait and be Late?", C. Loch and C. Terwiesch, 2000/83/TM
• "Managing Projects Uncertainty: From Variation to Chaos," Arnoud De Meyer, Christoph H. Loch and Michael T. Pich, MIT Sloan Management Review, Winter 2002.
• "Risky Choices and Correlated Background Risk," I. Tsetlin and R. Winkler 2005/25/DS
• "On Uncertainty, Ambiguity, and Complexity in Project Management," Michael T. Pich, Christoph H. Loch, Arnoud De Meyer, Management Science, 2002 INFORMS, Vol. 48, No. 8, August 2002 pp. 1008–1023.

There are other paradigms for technical and programmatic risk management

• NASA Risk Management

Theory X, Y, Z and W

Craig Brown has a post about Theory X or Theory Y and why Project Managers should be Theory Y.

In fact we as Project Managers, members of projects should be Theory W. The orgial paper, Theory-W Software Project Management: Principles and Examples, Barry Boehm, IEEE Transactions on Software Engineering, Vol. 15, No. 7, July 1989.