Herding Cats

The Grammar of "Done"

Geoff Crane posted a piece about "Achievements for Projects." Setting aside for the moment all the Face Book stuff, Geoff has discovered what the Defense industry and those following that guidance have been using for some time now.

The Integrated Master Plan. Let me start with a previous post Milestones, Resist Milestones. The structure of the Integrated Master Plan has three layers.

 

• Events - these are maturity assessment Events. Reviews of work in preparation for moving on to the next set of work. These Events have predefined levels of maturity for the deliverables that will be assessed. This means we have a description of what "done" looks like at any particular Event. Preliminary Design Review (PDR) has a predefined set of maturity assessment criteria. These state what it means of have a "preliminary" design.
• Accomplishments - these state the significant accomplishments needed to enter the assessment that takes place at the Event. For example (using an IT project), if we're going to have an Pilot Rollout of the transaction processing system, the Event would state PILOT TRANSACTION PROCESS SYSTEM COMPLETE. Then the Accomplishments would state what are the entry condition for this to be successful.
• Criteria - are the exit criteria for the Work Packages that create the content for the Accomplishments.

These are the elements of the Integrated Master Plan (IMP). In MSFT Project, these are zero-duration activities (not marked as milestones), that describe the increasing maturity of the products and services.

So Why This Approach?

This seems like a lot of work for a project, why not just have a schedule of the work and everyone start working?

• What done looks like is rarely connected with the passage of time and consumption of resources. That's what a schedule describes.
• The Integrated Master Plan has no dates. It's the Map of the flow of value for the deliverables.
• It states the needed maturity of these products or service in order to make physical progress.

Now The Grammar of the IMP

In Geoff's post shows an Instant Message. 

Ignoring for the moment the questions of how did the IM author know that the approval of the detailed design of the spacecraft prototype was planned to be started, the accomplishments needed to start, and the criteria for the work performed to start are not mentioned. 

Grammar of Done

One of the common errors made in project management planning processes is to not speak in clear and concise units of measure. You assume people have an understanding, when in fact they don't. The IM example above is an example.

• What are the conditions for the approval?
• What is the prototype "really?"
• What will be constructed?

Here's a Grammar framework used in the IMP paradigm

We always speak in the past tense about the product and its maturity. Preliminary Design Complete for example.

Social Media On Projects

So Geoff has it right. Social media can be used to communicate information (limited of course) to the project. But the actual achievement is defined, measured, and verified in the Integrated Master Plan and the Integrated Master Schedule for the Work Packages that perform the work needed to achieve the outcome.

The IM channel is just an announcement of the arrival at DONE for a particular Event, Accomplishment, or Criteria

Probability v. Statistics in Cost and Schedule

There's a popular myth that says project process can't forecast the future. This is literally not a correct statement, since this phrase leaves out the confidence with which the future is being forecast.

Add to the counter arguments used many times about Black Swans (a book of the same name is either loathed or loved depending on you point of view). But Black Swans are not usually in the vocabulary of project management. We as project managers aren't managing portfolios of investment funds, forecasting earth quakes, or making other decisions in that.

We're taking Statements of Work, Requirements, Concepts of Operations, and turning them into plans and cost models. Emphasis here on "model." 

So the real question is

• How confident are we that our model is credible?
• Do we know anything about the underlying statistical behavior of this model?
• Can we ask probabilistic questions of the model?

By credible I mean, there is a confidence level that the model can be used to guide the work efforts. The answer to knowing the level of confidence starts with knowing something about the variance in the underlying random variables that make up the model. Pat Weaver talks about Dancing with Chance. Like all of Pat's posts, there is an associated paper with more details. Pat's site is a "Must Subscribe" in Google Reader.

But here's an issue with the word "Chance." Change is a probability term. The local weather forecaster uses the phrase "there is a 30% chance of snow tomorrow on the Front Range." This means there is a 30% probability to snow will occur over the forecast area. This does not mean there is a 30% chance it will snow at our house, since local weather conditions drive storms coming from the north (Wyoming) to dump huge amounts of snow here before reaching other parts of the Front Range. 

To know if it is going to snow heavily in Niwot, Colorado, we need to know both the probabilities and the underlying statistics of the behavior of the storm. In the same way we need to know the underlying statistics of the cost and schedule processes to know the probabilities of completing "on or before" for a "cost or less."

Probability Versus Statistics

In scheduling or cost when we speak of probabilistic outcomes - what's the probability of being on time and on budget - we also need to speak of the statistical nature of the activity network that models the durations and associated costs.

When we speak of a probabilistic activity network (a Bayesian network) we also need to speak in terms of probability.

A question that can be asked of the network is – “ what is the probability of completing this task by a certain date?”

But first we must asked – “what are the underlying statistics of the activities of the network?” Without this knowledge we cannot build a model (or at least a credible model) of the project's cost and schedule.

A final question that needs to be asked is “what is the inherent uncertainty in these estimates?” In other words – how good is our ability to guess in the presence of a statistical process? 

So to have a useful model of the schedule and cost and to avoid falling into the trap Pat suggests - having the illusion of control versus "managing in the presence of uncertainty."

What Does it Mean to Manage in the Presence of Uncertainty

Uncertainty in plain English is about the “lack of certainty.”

• Uncertainty is about the “variability” in the performance measures like cost, duration, or quality.
• Uncertainty is about the “ambiguity” associated with a lack of this clarity

Discovering the known and unknown sources of bias and ignorance helps define much effort it is worth to clarify the uncertainty. This is the underlying process driving uncertainty. As well, uncertainty arises from the basic processes of work.

• This is Deming uncertainty.
• It is the statistical “noise” built into the work process

Both of these sources of uncertainty impact cost and schedule.

• Trying to control the “noise” adds little value.
• Trying to control the “lack of certainty” arising from ambiguity and lack of clarity does have value.

We cannot "Manage in the Presence of Uncertainty" until we know about the statistics. What is the statistical population of allowable values of the random variables of duration and cost for a specific activity? If we don't know these from past performance, we can make inferences to get close.

Once we know about the statistics, we can ask Probability questions.

• What is the probability of completing on or before a specific date?
• What is the probability of this project costing a specific amount or less?

These are the questions that are asked an answered to move beyond falling into the trap suggested by Pat Weaver.

Basic Rules of Managing Projects and PM 2.0

There are 1000's of rules for managing projects. I've collected many over the past 3 decades of managing projects. I came across a web site that has important things to say about project and program management.

Altis is the site of Jerry Maden, Associate Flight Director, Goddard Space Flight Center. Jerry has his 100 Rules for NASA Project Mangers.

But there is a critical important rule his states regarding PM 2.0 type processes. I'll paraphrase

Spitzer's Advice for Business Leaders: Never write when you can talk. Never talk when you can nod. And never put anything in an e-mail.

This is expandable every aspect of managing a project.

Garbage In Garbage Out

Mathematics may be compared to a mill of exquisite workmanship, which grinds you stuff of any degree of fineness; but nevertheless, what you get out depends on what you put in; and as the grandest mill in the world will not extract wheat-flour prom peascods, so pages of formula will not get a definite result out of loose data.

in Quarterly Journal of the Geological Society of London, Volume 25, 1869, Lord Kelvin, when speaking of the calculations of the age of the earth, in Fourier Analysis, "The Age of Earth I, II, and III," T. W. Korner, Cambridge University Press, 1988.

Quote of the Day

Competing pressures tempt one to believe that an issue deferred is a problem avoided, more often it is a crisis invented - Henry Kissinger

Remember risk management has five easy pieces

1. Hope is not a strategy
2. No single point estimate of cost or schedule can be correct without knowing the variance
3. Cost, Schedule, and Technical Performance are inseparable (this is the REAL Iron Triangle)
4. Risk management requires adherence to a well defined process
5. Communication is the Number One success factor in Risk Management

Using Social Media to Help Manage Projects?

Ryan Enders has a post about using Social Media to help manage projects. Notice "help."

Ryan mentions what social media is being used in an article in PMI's PM Magazine. The referenced McKinsey study claims:

• 69% of respondents reported "gains in measurable business benefits."
• 10% improvement in operational costs
• 30% increase in the speed with which employees connect with outside experts.

The PMI article states

Depending on how they're used, social networking sites, blogs, and wikis can be powerful tools for intra-team collaboration.

All this collaboration stuff is critical to project success. But is collaboration using the latest social media tools "project management."

Let's quickly review the knowledge groups of Project Management.

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management

Now social media as a communication enabler can add value to the communication needs of these process groups. This is not new news. Even in our defense and space practice, we live on IM and SharePoint. Both might be categorized as Social Media. Team Sites, chats with people at multiple locations, document control, dashboards, WebEx, and other "connection tools."

But are these tools Project Management?

They support the management of the project, no doubt. But so did the HP9000 based electronic contract management and program management tools used at Hughes Aircraft for the AH-64 in late 1970's, described in Project Management Lessons Learned.

Was this called PM 2.0? Was it social media? There was chat across the terminals with remote vendors. There was collaborative development of documents and databases between multiple sites using the tools of the HP9000 (a wonderful machine with a very fast processor).

Project Status Updates using Twitter

As a emeritus program was fond of saying,

"Are you out of your ever lov'in mind."
You might as well scratch your project status on the wall of the men's stall.

First project status is ALWAYS a report of physical percent complete against the planned percent complete. This is a number, some percentage, which can certainty be sent bu email, IM, twitter, and even scratched on the stall.

But that's not the "status" of the project. That the physical percent complete at the end of the reporting period - weekly in our domain.

The status of the project is the face to face, or video face-to-face conversation between live people about how you got to that physical percent complete, what prevented you from reaching the planned physical percent complete, and what you're going to do to get back to GREEN for the next assessment of your physical percent complete.

The Core Paradigm Gap

Reporting a numeric value is not "Project Management." No matter how you restate the hype, chatting, twittering, posting docs in MOSS, looking at pictures on WebEx is not "managing the project."

It's exchanging information about the project - possibly. Exchanging information through a very narrow bandwidth channel. And since the channel is narrow, communication errors are mandatory.

Those suggesting PM2.0 of the next big thing have failed to understand that a successful PM relies heavily on face-to-face communication. The agilest know this and state this in their Agile Manifesto.

So how is it we've moved away from this fundamental understanding? I have some conjectures:

• Those conjecturing PM 2.0 don't actually manage projects, they develop software. And since PM 2.0 is a project tool, they assume those of us who manage projects will really like their tool.
• That the core understanding of the process areas and knowledge groups of PMBOK and similar items in other PM framework are either not understood, nor practiced, and both in the world the PM 2.0.

Show Me the Money - Ron Tindell to Jerry McGuire

Please show me in units of measure meaningful to our clients (Enterprise IT, US DoD, DOE) for "managing" projects with tools like twitter, IM, and other "social media."

Seven Deadly Sins of Project Scheduling

Kiron D. Bondale posted about the Seven Deadly Sins of project scheduling. After you read this very useful post here's my experience of putting this advice to work in ways you'd see if you were on the site of one of our defense programs.

1. Scheduling Tools are necessary but not sufficient - we use MindJet to capture the Work Breakdown Structure (WBS), the Integrated Master Plan (IMP), and the Work Packages under the IMP's Accomplishment Criteria. The structure of the IMP/IMS can be seen here. The WBS is similar. The great thing about MindManager, is the "export to Project" button. Once you get close to what you want, just export the map to Project and continue working. When the WPs are sequenced, this is called the Integrated Master Schedule (IMS). The details inside the WPs are supplemental schedules held by the WP Manager. In other domains there are Tasks under the Accomplishment Criteria.
2. Scheduling constraints are forbidden in any credible schedule. Just don't use them, period. The only constraint should be Must Start On (MSO) for the milestone titled "Authorization to Proceed" (ATP). All other constraints are As Soon As Possible. You should avoid like the plague leads and lags. In some of our defense domains (NAVAIR, the Navy's aviation division) not leads or lags are allowed longer than 5 days. On a large program 5 days is the same as zero days. If you need leads or lags, make a "holding task," label it as a "holding task," and put it between the two tasks you want to lead or lag.
3. Automated resource leveling is an oxymoron, used by morons. Do not let a machine do your work for you. Touch every resource issue. Confirm the resources are what you need, their availability and what they are capable of doing. In some organizations there is a separate "resource management planning tool. Use it. NEVER let MSFT Project do this, it simply screws uop the entire IMS. This is a transition to the topic of Work Packages (WP). WP's are resource loaded but resource leveled. The WP manager figures out how many people she needs over what period of time. Then looks after assigning them work inside that period of performance.
4. Too Many Tasks - use Work Packages to collect detailed work. In formal scheduling domains, changes to the schedule go through change control. There is no way anyone can know what work is going to be done at the detailed level in 6 months. Or even in 2 months, let alone 18 months. Work Packages collect these tasks and the assigned staff and define a period of performance, the tangible outcomes of the work effort. the WP manager looks after the details. Put the WP in the schedule as a "task." For future work create a Planning Package (PP), with a period of performance, forecast resource loads. This WP and PP is the standard in the US DoD Earned Value Management approach. Don't let anyone talk you out of this. Make thew WP manager accountable. The PM can then see physical progress without all the gory details of tasks. Push responsibility down. Make the PM accountable. 
5. Out of Date Schedules - if you don't status your schedules every week, you should look for a new job. On large - I mean billions of $'s manned spaceflight programs - we status the schedule every Thursday afternoon in preparation for the "stand up" meeting on Monday to answer the question "what have you done for me lately?"
6. Outline Levels - match the structure of the Work Packages that sit at the bottom of the Integrated Master Schedule (IMS), shown in the notional picture here. The construction of the IMP/IMS is more subtle that a narrow bandwidth blog can deal with. But, the indent structure of the IMS should only go to level 5 - Program Event or Major Milestone, Significant Accomplishment, Accomplishment Criteria, Work Package or Planning Package, and maybe a sub-WP. Details are in the Work Package. The WP can be no longer than 60 calendar days for big projects.
7. Starting Over - once the Performance Measurement Baseline is "set," making changes means a change control process. The way out of a continuous change process is to use Rolling Waves. Planning Packages are in the the "out years," Work Packages in the current (active) Rolling Wave. Future Rolling Waves contain the remaining budget, define the future deliverables at a macro level and always have a critical path through them to the end of the project. But the details are defined yet. So as the requirements emerge (become definitized as we say), then the actual contents of the Planning Packages in the future Rolling Waves also becomes definitized. What this avoids is having to replan the work that never should have been planned in detail in the first place

Quote of the Day

"The system is finite, therefore trivial"

What Can Be Automated, Bruce W, Arden, Cambridge, MA, 1980

Critical Path Obsolete? Probably Not

Josh Nankivel has a post on his PMStudent site about the Critical Path. This presentation is one of those "let  me re-examine the obvious." This worth the time to watch, but it brings out several issues in the domain of project and program management.

Some of the questions asked by the author include:

• Where does the CP begin and end?
• CP start and end on date constraints? 
• Fixed completion of intermediate milestone impact the CP?

But first you must watch the presentation to connect with the comments below.

But first a pre-apology. This topic is wickedly obtuse for all the right reasons. So this very narrow bandwidth blog channel is replaced in practice with a 3 day workshop, and continuous hands on mentoring, coaching, and keyboarding for the programs we work  using Monte Carlo Simulation.

If you'll go to the Lijit search box on the right panel of this blog and enter "monte carlo" you'll see the tip of the ice berg of this topic.

This discussion starts with a primary problem

When you put hard constraints in the middle of the schedule, you have essentially "broken" the schedule. In Murry Wolf's presentation, complexity is created by this approach.

In our defense domain, hard constraints such as Must Finish On (MFO), Finish Now Later Than (FNLT) are strong discourages in principle and in practice ruin the use of Monte Carlo Simulation, since the probabilistic finish date are now anchored in the schedule and cannot move.

Here's the Real Problem

In our domain, the notion of the Critical Path as an "entity" that exists in the schedule, is replaced by a probabilistic assessment of the confidence of completing on or before a planned date. This is the role of the Monte Carlo Simulation of the schedule.

This approach removes all the hand waving, re-definition of terms, and arguing what is meant by Critical and Path.

The identification of the paths the impact the confidence of a deliverable is called the cruliality of the schedule. Using Wolf's classification are useful however:

• Acute Path - this is a path through the schedule that has negative slack that will substantially impact a deliverable
• Watch Path - this is a path through the schedule that needs to be corrected so the deliverable can be made as promised
• Free Paths - are paths that have positive float

This is an interesting view from Construction

At one time I was a member of the College of Scheduling. But the construction paradigm did not sit well with me for a few reasons:

• The litigation support issues dominate the style of scheduling. In the defense world, the Integrated Master Plan is "on contract." The Integrated Master Schedule (IMS) is subject to change of course - through a change control process - but the contributes to the IMS - the Integrated Product Teams (IPT) have similarly "promised" to deliver on time, on schedule.
• Litigation is rare and usually takes place after some complete disaster occurs.
• The use of constraints is common and remove the ability of Monte Carlo Simulation.

It's the Monte Carlo Simulation that got me hooked on the method of doing the IMP/IMS. The IMS in the defense world MUST have minimum constraints. The DCMA 14-Point Assessment sets the upper limit of constraints.

To answer Mr. Wolf's pressing question - "which paths should we be looking at," means answering the cruciality question with a Monte Carlo model.

Cruciality is the combination of criticality and sensitivity of the drivers of the deliverables. That is what activities drive the "lateness" of the deliverable, how sensitive is this lateness and how critical are they?

That's how you answer all confusion created by constraints, multiple critical paths - which are always there in any real schedule, since the durations are random numbers - and the identification where to look for the next "emerging" problem with staying on schedule.

PM 2.0 ≠ Agile, But What Is PM 2.0?

I never thought I would be saying this. Ron Jeffries, would be flipping in his grave if he were not so alive, well, and definitely kicking. So here goes.

The Agile Manifesto has come to my rescue

The proponents of PM2.0 and those repeating the statements of PM2.0 tools vendors and self proclaimed project management 1.0 replacement sages, have utterly failed to understand that communication is not about communication tools, it's about communicating between people, by people, for people.

Communication - at least as it occurs on projects - is about the personal, one-on-one, or many one-on-a-small-few exchange of ideas in a multidimensional context sensitive manner.

You know, hand waving, grabbing the marker, talking over people, digging out working examples of code, hardware, firmware, drawings. Grabbing the marker back. Going outside and pointing to the things you want people to connect with. Like the flying machine sitting on the ramp ready to go and exclaiming "see that, that's what I mean by integrated product team work."

I've been sucked into a conversation - of sorts, my own fault - about PM 2.0. Again. I knew I shouldn't follow that rabbit down the hole. But I did.

What brought me back to the surface was Ron's comment at an Agile Development Conference many years ago in Salt Lake City, when he was enjoying his Coke and I my beer in the lobby of the hotel, when he said...

"It'll come clear to you one of these days grasshopper (naw grasshopper is my addition, but it now feels right). It'll come clear someday when the world starts misinterpreting our ideas and fails to understand the core elements of the manifesto."

That day has come. For the proponents of PM 2.0

It's processes and tools over individuals and interactions

Communicating about the activities on projects through a soda straw of twitter. What a concept.

If this were not the case, no one would be talking about tools, except tools vendors. But it does seem to be the case. Unless I missed read the rabbit's title as project manager, when he is really a tools salesman - again.

The 15 Second Elevator Pitch

I cam across the 15 Second Pitch site. I've built  "elevator" pitches for marketing literature. But this was cleaver.

Here's my effort...

I am a Program Planning and Controls specialist in aerospace, defense, government, and enterprise IT domains. I create credible performance measurement baselines and manage the execution of those baselines. I have deep and broad capabilities to create processes and guide others to apply those processes to increase the probability of the program's success. When a program is in trouble, I get them back to green. When the program is working, I keep them green.

Yep, that sounds like me in the elevator.

Quote of the Day

Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him saying, "This fellow began to build and was not able to finish." - Luke 14:28-30

So why then do some projects, their sponsors, they managers and the developers of those projects utterly fail to comprehend the fact that planning is a critical success factor for a project's success?

We do they delve feet first into development, code writing, and releasing products when they have not the slightest notion of what done looks like, how long it will take to get to done, and how much done costs?

3 Point Estimates Part 2

The use of 3 point estimates is fraught with statistical integrity problems. Don't elicit estimates in this way.

While many will have anecdotal evidence of this working for them personally on small self contained projects, the issue of estimating impacts enterprise, multiple supplier, and integrated project teams (IPTs).

Summary of the Three Point Estimate Approach to Cost and Schedule

• The estimates are biased values
• The estimates are not anchored to the underlying probability distributes
• The estimates are not correlated with the other estimates in the project network or cost structure model

The Details

This approach starts with two primary sources. Effective Risk Management, Dr. Edmund Conrow, AIAA, 2003 and "Judgment Under Uncertainty: heuristics and Biases," Tversky and Kahnemanm Science, Volume 185, 27 September 1974.

People often rely on a limited number of heuristic principles that reduce complex tasks of assessing probabilities and predicting values to simpler judgmental operations. These heuristics can lead to biased assessments of probability. Three such heuristics, first discussed by Yversky and Kahneman, include adjustment and anchoring, availability, and representativeness.

The broader discussion of these biases can be found in the full length discussion in Judgment Under Uncertainty: Heuristics and Biases, Cambridge University Press 1982. This is a primary source work. Conrow and others have derived the impacts from this material. Primary impacts can be found in Complex estimating problems in software development, large construction, oil & gas capacity estimating (field production capacities), and economics.

As stated by Tversky and Kaheman: "In many situation people make estimates by starting from the initial value that is adjusted to yield the final answer." The judgment heuristic is called "adjustments. Adjustments are typically insufficient - different starting points yield different estimates which are biases toward the initial values (hence the term anchoring).

The consequences of adjustment and anchoring lead to an underestimation bias of potential minimum and maximum values associated with the likelihood of an event, a duration, or the probability distribution representing these activities.

So Now the 3 Point Estimate Problem - Part 2

Many of the probabilistic questions (what is the likely duration of the task?) with which people are concerned belong to one of the following types:

• What is the probability of an object A belonging to a class B?
  
• What is the probability that process B will generate event A? 

In these cases, people often rely on representativeness in which the probabilities are evaluated by the degrees to which A is representative of B, that is, by the degree to which A resembles B.

This is what happens when you ask a developer or planned to define the Most Likely duration for work and then ask what is the upper and lower limits of that duration. A Naval Research study and studies in the oil & gas field production estimating domain  have clearly shown that the order in which you ask those question results in statistically significant difference in the estimated values.

But There is More

The heuristic above is called representativeness and it affects risk related decisions (duration estimates are actually risk estimates - the risk of completing on or before a specific date). This risks include:

1. Insensitivity to prior probability - the Bayesian statistical impacts spoken about by K in Bayes Theorem for Project Managers.
2. Insensitivity to sample size - this is the classic anecdotal evidence of "it works for me on my sample projects, so it must work in general."
3. Misconceptions of change - the drawing of a triangle or any arbitrary curve, placing to end points and marking the peak of the curve and drawing conclusions in the absence of any confirm that this pseudo-probability distribution has any connection what so ever with reality. Or worse, reverse engineering a probability distribution curve to fit the data for one project and then generalizing that process to all projects in the universe. This latter is how the Beta curve, with fixed symmetric standard deviations resulted in the PERT formula. PERT can have up to 27% unfavorable bias in the presence of coupling between tasks.
4. Insensitivity to predictability - again a Bayesian problem.
5. The illusion of validity - no calibrated variances.
6. Misconceptions of regression.

It's the first of these heuristics that is the source of the exclusion of the 3-point process as practiced by many - asking the subject matter expert for the three values.

When faced by ambiguity or uncertain information, people have a tendency to interpret information that confirms their beliefs; with new data they tend to accept information that confirms their beliefs but to question new information that conflicts with them.

Improving Risk Communication, National Research Council, National Academy Press, Washington DC, 1989.

Conclusion

Making the 3 point estimate process the basis of project cost and schedule estimating is very sporty business. For personal projects, projects where you are the personal lead, have a small group of friends working the project, or the project is essentially self contained with your small group of friends, the risk is lower.

If your project is being implemented in a larger context, by essentially strangers - contractors, teams beyond your direct experience and control (other staff teams, development teams from other locations, subcontractors, 3rd parties, COTS providers) - you're taking on risk and may not know it, be able to quantify it, or even characterize this risk profile.

This is a primary source of project failure - there is no credible source of cost and schedule estimates when you simply ask some "what is the most likely, upper, and lower limits of cost or duration." You've planted the seeds of late and over budget and may not even know it.

Why 3 Point Estimates Create False Optimism

A recent post at PM Hut describes the process of capturing 3-Point estimates for schedule. This is an example of Yogi's quote in action

In theory there is no difference between theory and practice. In practice there is. - Yogi Berra

While it may be appropriate in the classroom to teach about the 3 point estimate process - minimum, most likely, and maximum - it is not appropriate in practice. This does not mean there are not gobs of people out there doing this. It doesn't matter how many people teach this, how often it is said, it's simply not good practice.

Here's why:

• If you ask someone to estimate how long something will take by having them think about the Most Likely duration, they will for the most part actually think about the "average" duration. The most likely duration is the value that appears most often if you were to ask a group of people the same question. The Most Likely is the Mode of the samples of that question. It is the value that occurs most often.
• Now when you ask someone the estimate what the least value the duration might be. Or ask them what the most value the duration might be, you'll get statistically significant different values, depending on the order you ask that question. This understanding has been developed by many organizations ranging from the US Navy to petroleum engineers estimating the contents of gas reserves.

Here's a reminder of how to talk about the three values in our probability distribution.

So What's the Point Here?

Do not, I repeat Do Not ask for 3 point estimates of duration and cost. Instead as for "variances" of the probability distribution around the Most Likely number. Worse case ask for variances around the Mean (the average). But care must be taken for the measure of the Mean. Since the mean is a value formed by adding all the possible measures, it itself is subject to variance. Most Likely - the Mode - is a simple counting of the most recurring observed value - it is ordinal.

Why Is This Important?

When you ask for the Most Likely, High and Low, you can get up to 27% estimating bias on the estimates. This bias can be favorable or unfavorable. No matter, it is a bias.

The way to do this for duration and cost is to construct a variance ranking processes. Here's a sample table.

Now there are several important things about this table:

• The risk level classification is not a number, it is a letter. This avoids the natural tendency to do arithmetic on the risk ranking. This is a common failure mode for anyone using the PMI style risk management. Take the probability of occurrence and multiply it by the consequential outcome to get a risk rank. NOT.

Both the probability of occurrence and the consequential outcomes are probability distributions, represented by integral equations. Multiplication is not an operator on integral equations - except in their Laplace Transform representations.

• The descriptions of the risk classification represent the operational aspects of the project for a specific technology or process. This means that the words in the classification column can change depending on the problem domain. For manned space flight a Risk Classification D, may have different words, and certai9ntly have different variance ranges than a risk variance D for an Oracle ERP system roll out.

What we need is a table like this for every major risk category.

A similar table can be built for the consequential outcomes. Then and ONLY then can the risk matrix be constructed.

The final advise is risk ranking in terms of variance should be geometric.

The reason you want to do this is that the separation of differences is not linear, it needs to be geometric. The scale 1, 2, 3, 4, 5 means that the difference between 1 and 2 is 100%. The difference between 4 and 5, is 20%.

Here's a Live Example

Connecting the dots - from NOT doing three point estimates - to doing probabilist impacts for the probability of occurrence and the consequential outcomes is shown in the picture below.

So:

• No three point measures asked to the engineers - only variance estimates for each class of risk
• No arithmetic between occurrence and impact
• Narratives of the measures (in the NASA example above they use numbers - not good - use letters)

Chartering the Project

Building the charter for the project does more than just gather everyone in the room for the "kick off" meeting. The charter starts with the definition of a team

A team is a group of people who hold each other mutually accountable for a common purpose to produce a specific outcome.

This is paraphrased from Katzenbach's The Wisdom of Teams: Creating the High-performance Organization. Harvard Business School, 1993. Each word is critical here.

• A group of people - these people may or may not be self selected. You might be "assigned" to a team, you might select the team members your self, you might not be able to make any of these choices.
• Mutually Accountable - is the critical success factor. No matter how the team was assembled, they - the team members - must come to agreement that they will hold each other mutually accountable for their actions and outcomes.
• Common Purpose - this is where the hard part starts. If you start the chartering process with the search for the needed "Capabilities," then the team is likely to come to concurrence on this common purpose.
• Specific Outcome - this is the deliverables from the common purpose. What does "done" look like for this team and the project (in this context) they are working on?

So here's a presentation that can start the chartering process. This is from a magazine article that I found useful, but it needed to have more details to be "actionable."

10 tips for chartering a project (v2)

View more presentations from Glen Alleman.

Imagine

Reading Jesse Fewell's description of a Scrum Gathering, I was stuck be a few things.

• The notion that Project Managers are "commanders." Too bad those using this concept haven't worked project were a "Real" PM was present.
• I'd be interested to hear how Tom Mellor - Project Leader at State Farm Insurance - connects the governance process of a regulated business with the "self organizing" processes of Scrum in the absence of some level of "Management."

Risk Management Maturity

 Dr. Mike Clayton asks an important question "What is your appetite for risk?" His approach is different than we find in our domain. The inverse question needs to be asked

What is your appetite for delay, cost overrun or possible project failure?

Asking and answering this question is a measure of the organization maturity in the realm of risk management. Our risk management guidance starts with the DoD Model. At first glaince this appears to be overkill. It is not. The principles of risk management are independent of a domain. That's why they're called principles.

The implementation of these principles can be adjusted for the domain but if you skip one or more of the principles, you creating risk again.

In a report sponsored by INCOSE Risk Management Working Group; Project Management Institute Risk Management Specific Interest Group; UK Association for Project Management Risk Specific Interest Group, there are four (4) maturity levels for Risk Management (from Risk Management Maturity Model, April, 2002)

• Level 1 - Ad Hoc - Worship the Hero
• Level 2 - Initial - Try it out an see what happens
• Level 3 - Repeatable - Plan the Work, Work the Plan
• Level 4 - Managed - Measure the Work, Work The Measures

There are many definitions of Risk Management, one comes from PMBOK which defines Project Risk Management as

“the systematic process of identifying, analyzing, and responding to project risk.”

Successful projects have dealt effectively with all types of risk , maximizing benefits while minimizing uncertainty. Which brings up another quote from the "Universal Risk Management Final Report,"

If you can't afford to mitigate the risk now, be absolutely sure you can afford to resolve the problem later when it happens.

Instead of answering Mike's question "What's your appetite for risk?" ask "what's your appetite for paying the price for not dealing with risk now?"

From a Dr. David Hilson newsletter titled "Universal Laws of Risk Management,"

• Risk is uncertain
• Risk Matters
• Managing Risk is a Process
• Risk is Managed by People

So ask how you are "managing risk," in the context of these Universal Laws?

Status Reports

Brad Egeland has a post about status reports. This is a topic near and dear to my heart, along with many others. Brad has a nice list of items that should be in a status report.

• Project title
• Project description
• Contact information for key project personnel
• Quick view high-level status on project, budget, and schedule
• Recent tasks completed
• Tasks in progress
• Upcoming tasks
• Status of all change requests
• Detailed budget status
• Issues status
• Risks status

Here's my experience in a variety of project domains, ranging from Enterprise IT, heavy construction, defense and space, industrial projects, and other domains.

Fundamental Reason for a Status Report

A status report should do just what it says - report the status of the project. So what are the primary elements of the project status?

• Are we on schedule?
• Are we on budget?
• Are the deliverables we said we would deliver compliant with their technical performance measures?
• Do we have all we need to stay on budget, on schedule, and meet the technical performance requirements?
• Do we know the risks and do we have a plan to mitigate or retire them?

This is the status of the project.

Here's the real problem with Status Reports

Status reports should report progress to plan. Tasks and the execution of tasks are not measures of progress. The production of deliverables are the measure of progress. So Brad's list of tasks in progress, upcoming tasks, and completed tasks are no measures of progress.

This is a common mistake of confusing effort with results. "We're completing all these tasks, so we must be making progress."

It's results that measure progress, not the effort.

So the status report must state in clear and concise terms, what results were accomplished during the period of measurement. But not just any results, but the Planned Results. So this means we must know what results were planned. This means we must have a Plan. A Plan that says what is "planned" to be accomplished.

Communicating with a Tuna Fish Cans and String

Geoff Crane of Paper Cut Project Monitoring described his TwitterView with Jhaymee Wilson. I had not heard of a "TwitterView" before this. It seems to be an interview over Twitter.

I've been interviewed twice this year (2010), once by PMI for an upcoming article and other time for a commercial Blog. Both times were around an hour on the phone and an editorial session after to do the "fact check" and final edits of the interviews.

What came to mind with Geoff's post is doing an interview with two tuna fish cans and a string.

We did this as kids. It's half duplex, low fidelity, highly distorted. Fun but not very effective.

Endless studies have shown that communication between people is largely through body language and expressions. Then comes tonality, and finally the words themselves.

Now I enjoy Geoff's Blog very much and the people he points us too as well.

But I still have not gotten my mind around the notion of Twitter as a communication channel for anything other than exchanging short - almost context free - messages. 

I live on IM with our field staff. It's a way to see who's in, a quick check up on something that can be resolved in a very few sentences - like ONE. For example - "who's using the WebEx account?" "Hey Matt, I'm headed to 59th facility, you gonna be there for lunch?" "Hannah, you coming to Breck this weekend with your roommates?" "Honey, stop by Safeway and get two bunches of green onions." Stuff like that.

Serious adult communication seems to require a wider channel.

Managing projects requires an even wider channel. In narrow channels we have, no hand waving, no doodling on the reports, no looking at multiple pieces of paper at the same time, no sensing of the facial expressions to see if we're actually exchanging information rather than just textual characters.

Someone please tell me what am I missing here, where the PM2.0 advocates claim this is the "next big thing," in the domain of Project Management?

Quote of the Day

If a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related – Martin Shub

Why is it those starting with theory have a difficult time moving the practice. Book authors with notional diagrams, descriptions of suggested actions in the absence of real examples?

Why is it those starting with practice fail to understand their experiences may in fact be just personal anecdotes, not transferable to other domains or even contexts inside their own domain?