Herding Cats

An Inconvenient Truth

There are many discussions around what works and what doesn't work in the management of projects. Words like:

• Earned Value can't work for our problem. I've seen it fail, so it can't work.
• Agile is nonsense, it's not right for our domain.
• Requirements must emerge from the development of software, you can't possibly define what the system will do up front.
• I've taught 100's of project managers how to implement PMBOK^® so I must be capable of managing real projects, no matter the domain.
• And endless other anecdotal examples of how a person with an opinion generalizes that opinion to the universe of problems.

Here's a suggestion. One that I've observed over the years. Those years having started in the late 70's when managing software development was an engineering role and having landed in the defense system program management world these days with formal probabilistic models of performance for billion $ programs.

Here's my suggestion. There are 5 IMMUTABLE principles of Project Management. These immutable principles keep coming up every time I hear someone speak about the problems they are having with a concept. The previous post was a trigger to restate these principles.

Five Immutable Principles

If you're going to successfully manage a project you must ask and answer these five questions. If you don't have credible answers for these five questions, do not proceed as a project manager. Stop, get the answers. Insist the stakeholder provide answers. Without credible answers, the project's probability of success is lowered. Possibly lowered to the point of assured failure.

The five immutable principles of project management are:

1. 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. 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. 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. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

In the absence of credible answers to these principles, you can come up with all kinds of reasons why things (methods, tools, processes) won't work. In fact you can come up with almost any reasons as to why projects fail.

Answering this principles in some credible manner doesn't assure success. But it goes a long way to improving the probability of success.

 

"Don't Do Stupid Things On Purpose"

I came across (actually Pat Richards alerted me) to an article about how Earned Value is not applicable for Software Development project. This article was in a PMI IS SIG news letter. See Pat's post. You can retrieve the article by following the link on Pat's Blog.

Here's the core of the concept proffered by a PMI Special Interest Group on Information Systems.

It is very difficult to accurately and objectively measure the progress in designing and developing software.

My first response was "really?" The very essence of project management is to apply some measure of progress to plan. Simply showing up and putting in 40 hours a week is a measure of progress to plan for a Level of Effort task like watching the trains pass the crossing. (They used to have a job like that in the old Federal Republic of Germany when I was there in the mid 70's detoxing from a tour in Vietnam).

Also the very essence of Scrum - or most agile development processes - is to produce planned measurable outcomes from the work effort. All agile methods MANDATE the production of working software. How to define what software to "get working" varies by method, but Scrum connects the work efforts with the "requirements" through a Feature and Story list developed by the stakeholder.

Software projects also have the problem of iterative development approaches in which certain activities often must be revisited a number of times before they can even be considered completed.

Yes this is true. This is true of every project on the planet. It's part of life cycle of projects. From the extreme approaches of XP to DoD 5000.02's procurement cycle, incremental and iterative approaches are used.

This is not a "problem," it is a fact. Apply the appropriate method to deal with this.

And then the final stroke is "really bad project management"

Many of the activities in software development projects more difficult to measure accurately and objectively in order to compute the actual earned value of the work accomplishments. It is very difficult to accurately and objectively measure the progress in designing and developing software. Often the project manager must simply accept the developer’s word for how they are progressing rather than use an objective measurement. For example, when is developing a computer program 25% or 50% or 90% complete? We can measure the cost of the developer’s efforts but not the needed corresponding progress toward completion.

Please tell me this is not the approach being blamed for software project failures. Better yet please tell me that Earned Value cannot be applied to software development because of these types of projects.

Earned Value is successfully used in a variety of software domains - Enterprise ERP, defense and space system, which are all software intensive, embedded control systems.

Core Success Critieria for Earned Value and Software Development

• Define the outcomes of the work effort in some tangible way. Physical evidence is best. 100% working code (at least for the planned deliverable) is best of software. Tangible evidence for other things is just that - evidence that work produced the "thing" that was planned to be produced on or near the day (or week or month) it was planned to be produced for something close to the cost that was planned.
• Define the way progress is going to be measured. 0/100% of the work. Either it's do or it's not done. Other measures of progress can be 50/50 (half when you start, half when you show up with completed product), apportioned milestones. But NEVER EVER is progress measured by asking someone "how far along are you  on the software module you are working on?" The answer can NEVER EVER be "well, I've been working real hard and I think I'm making progress, so let's say I'm about half way there with half to go."
• Define the tangible evidence, the date the tangible evidence is expected, and the associated costs.
• With this you've got all you need to do EV on Software Projects. Ignore completely the suggestion in the IS-SIG article, that EV and SW Dev don't mix. It's done every day on billions of dollars of software development.

Quote of the Day

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

- Introduction to Universal Risk Report, The Risk Management Research and Development Program, INCOSE Risk Management Working Group.

Teams

The Design, Development, and Support of High Performance Teams

from The Hunter and the Hunted, James B. Swartz

When you study companies that have bee very successful in the development of teams and compare them to companies that have floundered, you will find that the successful companies share four characteristics:

• Missioning and Contracting
• Structure
• Leadership
• Team Development

Missioning and Contracting

First and foremost the team must have measurable goals that are relevant to the strategy of the business. For example, in Motorola's case the teams were assigned goals such as reducing cycle times, reducing defects, and reducing costs - goals that are a subset of Motorola's overall mission.

There should be a clear understanding of the responsibilities and authority (what the team will do and what they won't do) on the part of management and the team.

Structure

The elements of structure are process, organization, and technology.

• Organization: team members should be located as close together as possible, considering the situation. They should have a clear reporting relationship with the business.
• Process: The team would be provided with training in decision making and problem solving.
• Technology: they should have the best tools available for the job.

Task Leadership

Good team leadership requires a broad range of leadership capabilities, including the ability to both direct and facilitate activities. The most effective leaders focus the team on the mission, while at the same time developing the team's ability to manage itself.

Team Development

Teams do not start as the self-managed level regardless of the experience of the members. Their development can be compared to the processes of parenting. In the early stages both teams and children need structure and direction. As they mature (Hersey and Blanchard define maturity as a combination of willingness and ability, or "will" and "skill"), teams can manage first to be able to assess maturity level. Depending on the maturity of the team, the flexible leader us able to provide direction and coaching in early stages of team development and provide participative and facilitative leadership in the later stages. The effective leader empowers a team in proportion to its maturity.

Motorola has defined development levels that establish the level of empowerment a team should heave as iot graduates through tje stages of development

- Julie Thrope

Quote of the Day

Nowadays, I make it a practice to call them into consultation on any new work ... I observe that they are more willing to set about a piece of work on which their opinions have been asked and their advice followed. - Columellama, Roma Landlord, 100 A.D.

Quote of the Day

While not a fan of the "popular speakers," this quote struck close to home...

Success is the result of good judgment; good judgment is a result of experience; experience is often the result of bad judgment. - Tony Robbins

So Why Aren't We Paying Attention?

Ranging from posting like "math is too hard," to "let's let the requirements emerge," I always troubled by the lack of attention to the underlying - many times the deep underlying - principles of managing software development projects.

Back in March, Guerrilla Project Management had a wonderful post about the Standish Choas report. But more imporantly are the papers referenced in the post. Rarely and I mean rarely do I encounter commerical IT projects that have discussions around these topics.

Quote of the Day

Everything important has been said before, by someone who did not discover it.

- Alfred North Whitehead, 1916 address to the British Association for the Advancement of Science

Agile and DoD Software Development

We're working a paper on the integration of Agile software development process and ANSI/EAI-748-B Earned Value Management.

Came across Considerations for Using Agile in DoD Acquisition. Worth a read.

The Work Breakdown Structure

While doing some research for a new engagement on a DoD program, I came across a paper on the Work Breakdown Structure from a PMI Global conference. Applying the Work Breakdown Structure to the Project Lifecycle. The paper provides a good overview of the WBS and its important to project success.

What was curious though was the complete lack of reference to MIL-HNDBK-881-A. This is THE reference for constructing a WBS.

First let's Look at a Bad WBS Example

PMI has a practice guide for building the WBS. Here's a clip from the guide.

This is why most software projects FAIL.

There is no description of what done looks like. Only the work activities - the functional areas of the project. This WBS lays the ground for "confusing effort with results." The is a really BAD example of a WBS for software development.

We see this all the time. It's the concrete and pipe view of a WBS. The Pharma example in the PMI guidance have the same feel. The WBS describes the "functions" and "roles" but never the outcomes or the deliverables, let alone the final Product or Service. Read MIL-HDBK-881A, learn that deliverables that compose the Products are the outcome of project. The structure of the WBS around the deliverables is the Product Breakdown Structure and the Services needed to produce those products. By services, 881 means the manufactuturing services.

Back to our Regularly Scheduled Program

The paper describes how PMBOK^® suggests the development of the schedule from the WBS and the WBS Dictionary to Activities and Milestones. No mention of Project Deliverables, although the WBS is a Deliverables Based description fo the project's outcomes. Not just Milestones. Outcomes. Tangible, physical products. We all know the story of the milestone as a rock on the side of the road with the whooshing sound as we pass by.

The paper skips right to the activities and their sequencing. DO NOT do this, you'll create a schedule that describes the "effort" executed by the functional members of the project and not the "outcomes."

The picture belong is the structure that must be in place for the schedule to have any credibility.

This of course is the Integrated Master Plan / Integrated Master Schedule. It speaks about Accomplishments and the Criteria - the exit criteria - for the work performed to produce those Accomplishments. Then assess the maturity of the product - the planned maturity against the actual maturity - at planned points in time. This is the way you can tell if you're "on schedule."

The WBS Describes the Product Structure and the Associated Costs

The WBS is the Product Breakdown and the supporting Processes that produce the Product. Not the project management processes, but the fabrication processes. Machines needed, buildings required etc. But the Product Breakdown Structure is the heart of the Work Breakdown Structure.

Here's what 881 says:

The WBS is defined, developed, and maintained throughout the system life cycle based on disciplined application of the systems engineering process. Other attributes include:

• A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item.
• A WBS displays and defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product.

Design, Code, Test is NOT a WBS. It's roles and functions. No product description, no project success.

When we speak about the "work activities" for the Work Package in the Schedule, we must speak in a grammar that conveys "done."

This grammar is the language of "systems engineering." PMI fails to adopt this paradigm. This is the source of most program failures. They don't have a grammar and a document that descries DONE. Just the work efforts, the roles performing those work efforts, and a structure showing those work effort. No one knows what DONE looks like from those work efforts.

It's ONLY About Defining What Done Looks Like

Near the end of the paper, the notion of the WBS drives straight into the ditch. The example of construction of a house illustrates where most of the problems come from in projects:

• The WBS is NOT the schedule - the suggestion that the WBS elements and their dependencies are to be represented in the schedule - along with the dependencies - is seriously flawed. At this ppint of the project planning the WBS must be a Product decomposition and a Cost Structure. Not the basis of scheduling.
• The basis of scheduling is the Product Deliverables, and the Work Packages needed to produce those Product Deliverables as shown in the second picture of this post. That picture at the top of the page is NOT the WBS. It is the project architecture that produces the increasing maturity of the products.
• It is the case that the WBS describes the scope of the project. No work should be done that is not in the WBS. This is the "all in" notion. But the sequence in Exhibit is NOT a schedule.

The examples of a House are much to simple for practical use in IT, heavy construction, weapons systems, aircraft or any "system" based project. Move to "system of systems" and the WBS developed in this manner rapidly falls apart and actually creates confusion.

In our work-a-day world, we spend much of our time "undoing" WBS's built in the manner suggested in the paper and the PMI suggestions. Don't have a project where we come to do "triage." Build a credible WBS. Read 881-A to see how. Don't convert the WBS into a schedule, define the Work Packages at the end of the WBS tree and then sequence those Work Packages.

Here are the steps needed to Build a Credible Performance Measuement Baseline. Apply them to you project and use the WBS as intended - as one of many representations of the project.

What Does Done Look Like?

I've participated in two session at Carnegie Mellon Silcon Valley's Masters Program, as a speaker. And one of our staff is completing his Masters Program there. he sent me this picture.

The inside joke, besides the graduates completing the work, is that "what does done look like," is the phrase used on most of our aerospace and defense programs.

This question and the answer, goes like this:

• When will this thing fly? On or before mid November 2014, with an 85% confidence.
• When can we install the next version of the Command and Data Handling firmware? On or before November 19th, 2010, with 90% confidence.
  
• When can the C-130 (tail number 56-0478) be ready for Ops? Next Wednesday sir, 100% guaranteed.

You get the idea. It serves no purpose to have a plan or a schedule if you don't know what "done" looks like. "Done" is defined in units of measure meaningful to the buyer, user, owner. It serves no purpose to state a date or a time unless you know the confidence level and the error on that confidence level.

If anyone speaks to you about "point" values, ask them what's the confidence level, and what's the error on that confidence. If they don't know, or don't know how to get these values, or don't care to get them - this point value can't be right. And most importantly, the point value can't be credible.

Quote of the Day

The most difficult subjects can be explained to the most slow-witted man if he has not formed any idea of them already; but the simplest thing cannot be made clear to the most intelligent man if he is firmly persuaded that he knows already; without a shadow of doubt, what is laid before him.

- Leo Tolstoy, 1897

The Problem With Deadlines

Ron Rosenhead has a great post about Bring Back The Meaning of Deadlines. The use of deadlines is common in project management. It's part of the culture of projects to speak about Milestones, Deadlines, and single items like that.

But here's the rub. Let's start with the Douglas Adams quote.

I love the sound deadlines make as they whoosh past

For the majority of deadlines and milestones, there is no entry or exit criteria for these "single point" items. By single point in mean a deadline or a milestone.

So here's the problem. When the project has milestones or deadlines, there is no explicit statements about what it means to arrive at the milestone or deadline, pass the deadline, be far away from the deadline or milestone. Or really anything about this "thing" that is in the schedule.

It's just a date or a rock on the side of the road, that you see as you go Whooshing by.

Now MSFT Project has this nice feature around Deadlines. They can be set for a date. We use this all the time in the IMP/IMS world for the Program Events. The PDR (Preliminary Design Review) for example has a planned date. The government usually sets this date and we put it in the IMS as a deadline. The Significant Accomplishments and Accomplishment Criteria, and the Work Packages and Planning Packages hang from this Program Event to the left, with the Deadline set.

In an assessment of the IMS the planned finish of the Program Event, say PDR, MUST be on or before the Deadline date, other we're late. But better the planned finish must be on or before the scheduled finish + the schedule margin for the Program Event.

With this condition we now have a credible IMS, with margin, a planned finish and a known "deadline" that has a credible probability of being met. 80% confidence level is typcially what we shot for with the applied schedule margin.

So use deadlines, use milestones. Just don't treat them as fixed rocks on the side of the road. Treat as warning indicators that your plan and master schedule is no longer credible, if you start to push the schedule margin below the allocated margin at a specific point in time.

Mathematics is our Friend

Over the past months, there has been several posts about the mathematics of project management. Cost estimating, schedule estimating, programmatic and technical risks.

I was cleaning up my server, looking for materials to aide a client for "getting back to green," on several programs. I came across Earned Value Management for Cost Estimators.

Download this material and pay special attention to the statistical information starting around page 109. The naive approach of Gaussian sums, where the Most Likely values of estimates are summed to produce a "normal" distribution, depends on independence between all probability distributions. Then move on to page 162 to see how correlations are critical to estimating cost and schedule impacts.

It turns out of course there are rarely if ever real projects that have no correlations between work activities. With this knowledge, it is now clear, that the simple approaches to estimating - 3 points, or single points, PERT, and all the other non-statistically developed estimates are simply too simple for use on any non-trivial project.

Watching Dogs Eat Spaghetti

That's a good description of what schedules look like when they are assembled in the absence of any program architecture. This architecture is of course best built using the Integrated Master Plan (IMP) paradigm.

Without going into the details of the IMP, let's look at the step-by-step approach to turning the needs of the customer into credible project architecture:

• Determine what "done" looks like in terms of the customer needs.
  
  • What capabilities does the customer need at what time during the life of the project?
  • What are the Measures of Effectiveness (MoE) of these capabilities.
  • The MoE's are operational measures of success that are related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
  • These capabilities and their measures are independent of any technical implementation
• Determine what must accomplished into order to produce the "capability."
  • These accomplishments are the "entry" criteria to the presence of the Capability.
  • The accomplishments are stated in the past tense. For example for an insurance claims processing system, such an accomplishment would be to capture all the existing policy holders in a single integrated database in preparation for migration to the next system.
  • The Capability for the system is "collect all policy holders"
• Determine the Criteria, the "exit Criteria" for the work packages that perform the work to produce the Accomplishment
  • This is where the scheduling processes start.
  • The work is produced through Work Packages.
  • Each Work Package produces an outcome, preferably a single outcome.
  • This outcome is described in Measures of Performance (MoP)
• Assemble the Work Packages in a logical order that produces the outcomes in the best order for the project.
  • The assembly of Work Packages is the "schedule" for the project.
  • This sequence is for the Work Packages, the Tasks inside the Work Packages are sequenced by the Work Package Manager.
  • The task sequence is called the "supplemental schedule," and is able to adapt to the emerging needs of the development process.
• This is where "agile" enters the picture.
  
  • At the boundary of the Work Package sequencing and the Task arrangements within the Work Package.
  • Since each Work Package has an "outcome" that contributes to the increasing maturity of the business capabilities.
  • This is where the connection between "business value" and the project performance measures takes place.
• With this connection - between business value and project performance - project management and business management are joined

With this joining the "dog's breakfast" is avoided, replaced by a logical project architecture, describing the tangible evidence of progress to plan measured in units meaningful to both project management and the customer.

The relationships between these measures is

These measures are the "glue" for the architecture of the project's schedule. Without the "glue" the schedule is just a list of work, hooked together in any olde arbitrary way - like watching dogs eat spaghetti.

Earned Value v. Earned Schedule

Andrew Makar posted a comment about Earned Schedule and if I had read Ray Stratton's papers on Earned Schedule. It has awhile since I looked at www.earnedschedule.com. So please go there, read the papers, look at the pictures on the first page of the site. There you'll understand that Earned Schedule does for Schedule Variance what Earned Value does for Cost Variance.

Earned Value provides Schedule Variance in units of "money." "You're $12,750 behind schedule," is not only strange sounds, it says nothing about what that means it units of time. Does a dollar = a minute, an hour, a day, a week, a month. EV does say. There is no way to find out without knowing the labor rate for the work effort being performed. For a collection of Work Package, with various rates, this would be near impossible.

Enter Earned Schedule. Using Budgeted Cost for Work Performed (BCWP)(Earned Value) and the Budget Cost for Work Scheduled (BCWS)(Planned Value), the schedule variance in the traditional Earned Value view looks like this.

Schedule Variance = BCWP - BCWS. Both these variances have units of "money," the "budgeted cost. Now you can use hours, but then you've got no way of calculating Cost Variance = BCWS - ACWP.

For Earned Schedule, the visualization of Schedule Variance answers the question, "on what day should we be earning the planned value for the work being performed.

If you "take" Earned Value "today," that is calculate BCWP using Physical Percent Complete or some other credible assessment of progress and determine the day that value was planned to be acheived, then you can tell if you are ahead or behind schedule. If the currently measured BCWP is achieved on the same day your had planned to achieve that value - the BCWS for today, then you're on schedule.

If BCWP≠BCWS today (the measurement day), then you're off.

Looking backward (or foreword) for the day BCWP = BCWS for today, tells you the day you should have achieved the planned BCWP. This backward duration is how late you are in DAYS, not "money."

This is the essence of Earned Schedule. Read all the papers at the ES site. While ES is not a government standard, like 748-B is, it should be and is used to great advantage on many programs.

The Three Deadly Sins of EVM?

Mark Mullaly has a nice post at Gantt Head where he speaks about the three dealy sins of EVM. While I enjoy Mark's posts, and he does bring up good points, I'm not a fan of this approach for some simple reasons:

• EVM is our livelihood on DoD and DOE programs. As program planning and controls we work EV every day. The conjectures made in the post represent very low maturity on the EV maturity scale. See Ray Stratton's The Earned Value Management Maturity Model.
• EV is really a straight foreword process. The minimum concepts of EV are actually that minimal. Read these is see if Mark's post makes sense. When I hear descriptions about the complexities of EV, that are not based on implementations, and miss the foundational aspects, I cringe.

I am always compelled to respond to this type of approach, since the post contains some good ideas, but seems to wrap them in concept that would bring a chuckle on our DCMA validated programs. So here goes a reponse from the field experiences of applying EV on DoD and DOE programs and critically important, surviving DCMA validation and surveillance.

The sins of omission...

...are (relatively) straightforward, in that even the proponents of earned value are (usually) quite up front about what EVM can and can’t do. EVM measures performance against the agreed-upon schedule, budget and particularly scope. It has nothing to do with measuring the quality of what is delivered, and very little to do with ensuring business value.

This is the role of Techncial Performance Measures. See the PMI-College of Performance Management's CPM-500F Techncial Performance Measures. While EV does not address product quality - actually quality is but one Technical Performance Measure - this is far from new news. As far back as 1984 TPMs were part of the performance measurement of a program. In 1995, then SecDef Perry stated

… the basic tenets of the process are the need for seamless management tools, that support an integrated approach … and “proactive identification and management of risk” for critical cost, schedule, and technical performance parameters. ― Secretary of Defense, Perry memo, May 1995

We just haven't been paying attention

The sins of commission...

...are a little more complex ... they largely relate to how earned value is implemented. ... One of the fundamental dimensions of earned value is to understand “work accomplishment”--what is actually done and complete. For anything completely finished or anything remaining, this is pretty straightforward: You get 100 percent credit for what you’ve completed, and 0 percent for what you haven’t started.

It’s when something is in progress that things get a little messy. Projects are famous for hitting 90 percent complete and stopping, and frankly so are activities. What underlies this behavior is the complete imprecision by which many projects get to “90 percent”. We need to understand how this is calculated and what it actually means--and the degree to which it is in any way reflective of reality.

This last paragraph is actually BAD EV. Measures of Physical Percent Complete, Apportioned Milestones, fine-grained (no Work Package crossing more than one accounting period), measures of 0/100, 50/50 and the like at the Task level inside a Work Package are described in the Earned Value Management System Description (EVMSD).

"Completely imprecise" is simply BAD EV. Don't do that. Define what done looks like in units of Physical Percent Complete at the Task level, within a Work Package.

Most egregious of the earned value sins...

...however, must be the sin of deception. Theoretically, earned value is a transparent and open means of tracking project costs. Let’s go back to the fundamental principles of earned value, however, and our identification of what it explicitly addresses and implicitly includes. While cost, schedule and cash flow are explicitly articulated, within the world of earned value, scope and defined work are assumed implicitly to be stable for earned value to work. Here is where the use of earned value goes beyond sin and can get downright immoral. All of the relevance of earned value is predicated on having a stable baseline. However, if you change the baseline, you change the basis of managing the earned value of the project. This is where the deception occurs.

What Mark describes here violates the core principles of EV. You can certainly change the Baseline. It's called re-baselining. The permissions needed to re-baseline only come from one of several conditions - Over Target Baseline (OTD) or a Nunn-McCurdy breach. This is a major event on EV managed system. If you treat re-baselining as a deception, then you get everything coming to you in terms of violating EV principles. It's that simple. This is not a egregious sin, this is a violation of 748-B and the very principles of managing projects with EV.

This approach would be laughable on a DCMA validated program. It would the source of a CAR (Corrective Action Request) - a "ticket" in the speed limit paradigm. Frankly this is simply nonsense. Don't do it. Don't allow anyone to do it. Don't tolerate doing this. Don't believe for a minute this is a sin. It is simply not allowed. If you are compelled to re-baseline, do the simplest thing possible, stop using EV and look for work elsewhere - management is cooking the books.

So In The End

When I read...

A quote that is widely attributed to former British prime minister Benjamin Disraeli is the statement, “There are three kinds of lies: lies, damned lies and statistics.” To this we clearly might also arguably add a fourth: earned value.

I have to ask the question I am always compelled to ask of Mark, of proclaimed PM experts, or anyone making statement like this.

Have you worked a DCMA or credibly managed EV based program?

Because if you have, you'd certainly not be making statement like this. Please read about EV in locations that practice Earned Value. There is new Defense Acquisition Portal. Go there, enroll, install all the Certifications needed to have the site stop asking you to verify, and read about how EV is practiced. Read the articles, download the materials, subscribe the Blog feeds, subscribe to the Journals, Defense Acquisition, Technology and Logistics, Defense Acquisition Review Journal, and most of all join the Earned Value Management Community of Practice and then you can possess the information needed to sort out fact from fiction in the Earned Value Management world.

One Last Suggestion

Take a look at a project that applied EV succesfully. Here's a Case Study from CERN.

Anchoring and Adjustment - Part Deux

Dan Ward posted about Gray's Paradox. When Dan describes his experience at the Baltimore Aquarium:

The truth is, the animals have it right and we've got it wrong. When our math indicates one thing and observation reveals something else, um, that means our math is wrong. Rather than saying things like "Bumblebees shouldn't be able to fly" or "dolphins shouldn't be able to swim that fast," we should go with something like "Our understanding of physics is wrong / incomplete / etc." But let's not blame the animals when their behavior doesn't comply with our "laws."

Dan demonstrates classic "anchoring and adjustment." What was missing from Gray's assessment of the Dolphin's swimming speed was the understanding of how much force the Dolphin could actually produce while swimming. Gray "assumed" the Dolphin had some special "anti-drag" property. This was needed to explain why the Dolphin could swim at the observed speed, using only the hypothesized force.

Of course the hypothesis was wrong, and Gray failed to completely question his hypothesis in the presence of the "facts" of the Dolphin swimming at the observed speed. Gray was "anchored" in the perception that the Dolphin did not have enough muscle force to swim at the observed speed.

This "anchoring and adjustment" process (first developed by Tversky and Kahneman) is persistent in everything we do. It is part of how our brains work. Anyone claiming not to be subject to "anchoring and adjustment" in any process involving making decisions in the presence of uncertainty - project estimating, gas field capacity estimates, or financial performance estimates for example - is fooling themselves and those around them.

This is the reason that 3 point estimates collected from subject matter experts (the most likely, optimistic, pessimistic) are seriously flawed, not matter who says they are not. Examples are all around us:

• The original estimate for the cost of Joint Strike Fighter are now know to be off by a factor of two, even though those with calibrated Rayleigh distribution models showed this would be the case. Anchored by past performance and un-adjusted by the complexities of the software systems.
• The risk associated with drilling in the Gulf was known to be many times higher than the "subject matter experts" stated. Anchored by the past performance in near-shore experience and un-adjusted by numbers for the North Sea.

So NO 3 point estimates gathered by asking people Low, Most Likely, High. Bounds for the variance are ONLY gathered using calibrated ordinal values derived from models that connect the non-linear drivers of cost and schedule in a network assessed through Monte Carlo. Consider your project schedule a Bayesian Stochastic network and treat it accordingly. As well these models can be "tuned" to match the emerging relaity of performance. Individual P-ML-O data is a one shot deal, lost to analysis once gathered. And if that's not enough to discourage you, when you come back to collect the personal opinion data again, the author will have moved from the past anchoring to an adjustment phase with no way to connect to correlation of past performance to future forecast.

Just Say NO to personally gathered 3 point estimates

Then start reading John Good Pasture's series of Thomas Bayes. Then go to Kailash Awati posts on probability and statistics in project management, and then visit articles on probability theorems. I'd suggsest when you get through these sources, read the Against the Gods book and google the Tversky and Kahneman papers, you'll have a different view of the 3 point problem and thoses suggesting "it's good enough or it works for me."

A Credible Resource of PM Materials

There are many resources on the web for Project Management. Some from offical organizations. PMI's Project Management Journal is one. Some from government organizaitons, The Defense Acquisition University's site is a wealth of materials. PMI's College of Performance Management. Cross Talk is a journal of the Software Technology Support Center. Of course there is PM Forum, where guest authors provide materials of interest. Max Wideman's site is always there for credible informaiton.

With all this though, I still find myself draw to Pat Weaver and Lynda Bourne's Mosaic site. They have written and collected a wealth of PM materials. I'm not always in agreement with their approaches. That's because I have a built in bias from my aerospace and defense point of view. But that is irrelavent, their materials are MUST READ for anyone claiming to be a project manager.

Why amy I writing about this. It's simple, there is a trend in the PM world these days to claim all kinds of simple and simple minded solutions to complex problems. Solutions that have not stood the test of time. not been applied to hard problems, solutions that rely on some "magic beans" to providethe desired outcome.

We're in the throws of "resetting" a Performance Measurement Baselime for a moderate sized program ($80M, is moderate in our domain). The root casue analayis of the "over targer baselime" situation, is simple. The team was searching for simple solutions to complex problems.

Such solutions are simply not there. Anyone telling you they have a simple solution is either confused, in experienced, and or simply unqualified to speak about the topic. When such a solution is presented, ask a simple question:

Can you show me where you suggested approach has been successful in the past, on programs or projects similar to the one I'm working, and with tangible evidence that the problem was corrected or at least the situation improved?

No, thanks for the free advice. If you paid for the advice, ask for you money back.

Earned Value and Agile "Connecting the Dots"

There is lots of discussion about applying agile development in an Earned Value project domain. The inverse is discussed as well but not with the same intensity - applying Earned Value in the agile domain.

Here is small sample of how Earned Value and agile can be connected.

Earned Value	Agile
Progress measured as physical percent complete	100% working software at the end of each iteration
Planned deliverables define what DONE looks like	Iteration's deliverables are agreed to before starting
Past performance forecasts future performance	Burndown charts used to forecast future performance

 

Some on our team are developing the notion that Agile software development techniques can be applied on Earned Value projects. The abstract of the paper is due late August, more to come.