Sorry, couldn't resist.

A well known and very vocal Project Management instructor made a statement about Government Projects always being late and over budget. Then making a not so subtle suggestion that his competency based assessment approach, versus the PMI approach to certification, is solution to better project management.

Man, do I wish that was the case. Here's my hands on experience in the government (DoD, DOE, DHS) experience on the program controls side.

• Requirements changes impact programs in ways that are not desernable when first suggested. We see this all the time. "Let's make this change from one real-time control data bus to another real-time control bus for all the right reasons" - faster, better, cheaper. But then the second and third order impacts start showing up months later.
• Techncial architecture impacts are many times unknown. "Let's scale up the number of processing units from 20 to 100. It's only a 5 times increase, so let's up the cost and other impacts by 7 to account for unknowns. Turns out the real impact was not 7 but 14, twice what was estimated. Materials impacts, process flow impacts, the overall thermal impacts were huge impacts on the program.

The  processes used to manage a program are absolutely necessary for success. Earned Value Management, prorgammatic and techncial risk management, Systems Engineering, Measures of Effectiveness and Measures of Performance driving the Techncial Perfomance Measures.

But necessary of OK, what about the sufficient conditions?

• Senior management must behave in rational ways.
• Change control is mandatory, not as a "constraint," but as a process to reveal impacts
• All parts are connected, no matter what the suppliers say. A Systems Engineering paradigm is mandator for all things other then simple projects.

These, and many others, are not directly related to project management processes, even the general purpose ones found in PMBOK®.

At the bottom of this discussion the "necessary AND sufficient" conditions starts and ends with:

• Past performance,
• Extensive experience,
• Processes and tools, and
• The necessary leadership to put all this together.

Now how can we increase the probability of project success? This is the 64 thousand, 64 Million, and maybe 64 Billion dollar question.

Simple, and many times simpilistic soultions are just that simple and many times simplisitic.

We have to remember ...

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

There are no soltions to complex problems. Complexs are part of our current life paradigm. All the easy problems have been solved. So rarely will there be a problem that can be solved with a simple solution.

Project Management means different things to different people. From the social and humanistic aspects of managing the people working on and around projects, to the gritty details of a Performance Measurement Baseline, with in integrated cost, schedule, risk, and technical performance measures.

One advantage of working the in Space and Defense business is the social and personality aspects are minimized. Not gone all together, but certainly much less than commercial domains, where egos get in the way many times of getting things done. In A&D "done" is clear and concise - the machine flys away, the product does it's job as defined in the SOW, with measurable outcomes, soldiers are using the product, things like that. Black and White, either it flys or it doesn't fly. Of course it's not that simple, it never is.

But one thing that is different in A&D is the focus on the processes and tools. I'm working a moderate ($300M) Army program through January when we get to the Integrated Baseline Review (IBR). While poking around looking for some ideas for training our customer, I came across PM Lotus's "Setting Baselines in Microsoft Project."

The Baseline is just what it says it is, the "baseline" of the cost, schedule, and technical performance. Now MSFT Project is not the best at managing baselines. In fact it's pretty poor at managing baselines. No change control, no traceability, not much in the way of mandated documentation. But it's popular and most of our programs use MSFT Project.

Drill down into this site, there are some very good articles for those interested in the programmatic aspects of project management. Like Checklists.

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.