Herding Cats

Business Value and Earned Value are NOT the same

No matter how often it is said, Business Value and Earned Value are not the same value. Earned Value's value is the Budgeted Cost for Work Performed (BCWP). The value is earned by completing the measured percentage - preferrably 100% - of the value of the work budgeted - the Budget Cost of Work Scheduled (BCWS).

BCWP = BCWS x Percent Complete (or some other form of tangible evidence of progress)

The value of business value of a strategic and operational assignment of value to the business. When there two terms are confused, mixed, or just complained about, both sides of the equation loose.

Here's how to connect them from the top donw, using Vision, Mission, Strategic Objectives, Performance Goals, Critical Success Factors, and Key Performance Indicators. It's the KPI's where the EV metrics live. The other metrics are business centric and have units of measures that are business focused. These are called Measures of Effectiveness in the Systems Engineering world. The KPI's have Measures of Performance along with the EV metrics.

Use this approach and ignore the voices that claim EV value is not Business value and the comments that EV of no interest to IT projects. It turns out EV is directly connected to methods like Scrum, where measures of physical percent complete are embedded in the process. These voices are unlikely speaking from hands on experience connecting business value with Earned Value on actual projects.

This approach of connecting busines value with Earned Value works, it is currentlyworking, and will work once you get past the rhetoric.

Black Swans and Intentional Ignorance

The notion of a Black Swan as a low probability event with high unfavorable impact is a common example of the "long tailed" probability distribution found in many domains from finance to manned space flight.

The Black Swan as a excuse of not doing your home and seeking all the possible sources of disruption is common in some domains. The notion of Unknown Unknowns has been presented before. Unknown Unknowns is a start. Managing Projects in the Presence of Unknowns. And Colossus is the last. This discussion of course went off track when there was major push back on the "knowability" of these unknowns.

No magic here, just plain out Bayesian statistics and it's application to the population of possible outcomes. But not necessarily observable at the needed time by an individual or worse an individual inexperienced or not trainied to look for those pesky black swans. Without the math, experience or processes, it does look like magic. But sadly for many of our 401(k)'s, the facts are becoming clear (Too Big to Fail, The BIg Short, and All The Devils Are Here, there were no Black Swans in the sense of Unknown Unknowns in domains where we would actually discover the processes if we simply wanted to. Instead it seems to be a case of simple ignorance, likely intentional, to transfer risk to fulfill a political agenda or fulfill the quest from greed. So let's move off the opinion puff pieces based on populist literature and back the actual mathematical basis for the Black Swan.

Here's a news article from our local paper that demonstrates the basis of the "knowability" of risks and the intentional ignorance of this knowledge. And more importantly the notion of only looking in the obvious places for potential risks is the source of these Swans.

Certainty the Black Swan definition of a low probability high impact event is applicable to Fukushima. But everyone knows there is an island facing slip fault not far off shore in Japan and that fault is active. Simple geology can predict the outcome that happened. To conjecture, as TEPCO did, that this is not a problem is the same as Donald Rumsfeld's conjecture that the tribes of Iraq will willing accept democracy after the removal of the dictator, or Taleb's "we just didn't understand the complexity of the financial markets," or software project managers saying "we just didn't have enough information about the complexities of the process to see that the cost and schedule would overrun by 200%." 

Are you out of your frick'in mind?

When we talk about risk, the only risk that can not be considered is one that is unknowable. We may not be able to afford the cost of seekiing all the risks. That's OK sort'a if we acknowledge we can't afford to look. But the lame excuse of it was an "unknown unknown," is just that, lame. Maybe an unafforable unknown. But if the risk is knowable, then there is no Black Swan as an excuse for the project going in the ditch - or worse for the foreign policy going in the ditch.

Memorial Day

Least We Forget

 C/159 ASHB, Phu Bai, I-Corp, Republic of Vietnam, 1970 - 1971

Agile and Earned Value Slide Share

I really don't like self promotion for the simple reason that it diminishes the credibility of the promoter. But our inside sales suggested I do this.

The presentation Successfully Integrating Agile and Earned Value got recognized this week as being talked about on LinkedIn more than anything else on SlideShare right now.

So What? Who Cares?

There is still a huge way to go to "connect the dots" between Agile and Earned Value. From the NDAA Section 804 efforts to correcting the mis-informed messages about how Earned Value works in software development.

This includes:

• Connecting iterations with Work Packages on monthly or bi-monthly boundaries
• Using physical percent complete in agile as the same physical percent complete in EV
• Using Planning Packages as future iteration place holders

The reason for this is simple and complex at the same time. In the government procurement domain, Earned Value is mandated by FAR 34.2, FAR 52.234-4,  and DFAR 252.234-7002. Those in the commercial world could care less. But in fact as citizens they should. The IT budget for the US DoD is something like $87B. The NDAA Section 804 initiative is attempting to introduce concepts like Making Acquisition Measurable.

When there is discussion of "scaling" agile beyond the small to medium projects, here's an opportunity to actually do it, in a highly visible and controlled manner.

Another example is "in the news" CIOs Site Trouble With Agile Development. And Improving the Initiation of Acquisition Activites for Automated Information Systems.

It Takes All The Challange Out When You Read The Directions

I had a conversation of sorts with a blogger that stated essentially "EV is bunk," (this is false) "Value and Cost are not the same thing," (this is true).

I had another conversation where the statement "the WBS is not needed in agile when you're doing EV." (Where do we collect costs) Or "EV is not going to be needed on large DoD IT programs when we get agile installed and running." (Let me introduced you to the DCMA and DCAA).

This is like the conjectures about Complex Adaptive Systems that are completely devoid of mathematics. Or persona anecdotal experiences that get scaled to global levels?

So what am I missing?

When we come to technical processes, EV, CMMI, CAS, ITIL, and maybe even well defined instances of Scrum, there should be little confusion about the definition of the process, it's application, and most of all it's benefits. The unassailable beneficial outcome as we say in our proposal writing classes.

So why can't those with opinions start by reading the manual?

When it comes to EV, there are public domain sources for "the manual." ANSI-748B itself is not free, but the NDIA Earned Value Management Intent Guide is. At the Defense Acquisition University (DAU) site there are tons of resources. PMI has an EV Practice Guide (which is not free). There are books, articles. Google is our friend here.

When opinions start flying around about EV or CMMI there seems to be two camps. Those that practice the principles and find issues and discuss these issues, seeking improvements. Those who have not practiced the principles, may not even know the principles, and want to tell others that the principles and the practices are somehow wrong.

The classic is "The Value in Earned Value is not Business Value, and that makes EV useless for IT in the agile setting." Well Dah. The "value" in EV is NOT business value, and if you'd take even this minutest amount of time to read any EV book, you'd know that.

This would be all irrelevant is it were not for the esteem of some of these voices. Voices with major fimrs behind them. Voices with major credentials (PhD's) behind them.

So here's my test questions:

1. Have you practiced the principles you are saying can't work?
2. Have you asked those who have made it work in similar domains and contexts how they did it and if they have any advice for you?
3. Have you sought out solutions from sources like articles, conferences, professional organizations? And at the same time sought connections with the people participating in those organizations?

No, then you're probably not having much success are you?

And by the way, those suggesting Earnend Value can be done outside of the 748B 32 criteria, you may have a point. But before getting too excited, ask how the "alternative approach addresses these 11 needed process areas, the colored ones?"

Project Success

Attending the EFCOG (Energy Facilities Contractors Group) Project Management Working Group. One discussion was around the success factors for projects. There were two obvious assessments:

1. Accountability and rigor in the management of the baseline and the process for executing the baseline.
2. Experience of project management

The accountability and rigor is the source of visibility to the performance of the project and the capturing of feedback for corrective actions.

The "baseline" is a concept missing in some domains.  The baseline is the metric benchmark against which project performance in terms of time, cost and technical performance is measured. Without the baseline, there is no description of what "done" looks like. Without some description at a level sufficient to control the outcome means that the only measure of progress is the passage of time and the consumption of money.

This is the case no matter what the project domain or context of that project. Controlling the baseline does NOT mean no changes. It means knowing what happens when a change is requested to the cost, schedule, and technical performance

Experience is obvious. But the right kind of experience is critical. The notion that a PM can manage any project is nonsense. The PM's in the DOE work in three major areas: Science, Environmental Management (EM), and National Nuclear Security Administration (NNSA). Performance varies between these groups and projects within the individual groups.

In the end, success starts with "past performance." This means I've made it work before, in some way close to what the problem is today. There is rarely a project that is complete "green field," - something that has NEVER been done before.

One recurring theme for projects is the phrase more planning up front. This doesn't mean Big Planning Up Front, just better planning up front. The credibility of the plan when the project starts has to be just that CREDIBLE. The nonsensical notion that we'll figure out how much this project will cost and when it will be done as we go along, is just that nonsensical. This only works if you're spending your own money and you don't care if you overrun. When you're spending someone eles's money, you'd better can some notion of cost and schedule near the start of the project.

You wouldn't hire a lawn mowing service if they couldn't give you some estimate of the cost per month of their work. Why would you engage in an IT project without some upper bound on the cost and duration?

Managing Projects with Earned Value

There are two books that describe how to manage projects with Earned Value. You can read about EV in a variety of places, but the principles are many time missing from these sources. Here are three books that not only provide the principles, they also define the practices.

Mario Vanhoucke provides detailed insight into managing projects with Earned Value. The key understanding for all successful Earned Value implementations is time is not money. The units of measure in Earned Value is money. Only money. OK, maybe some other simple unit like hours. But both time and money are not used together in Earned Value. This is both a problem and not a problem. It is not a problem, because the role of Earned Value to to show progress to plan in a stable unit of measures. It is a problem, because it is hard to speak about performance of the schedule, when we say we're $129,000 behind schedule. What is a dollar worth in time? It depends of course on the labor rate.

The main purpose of Earned Value Management, or any performance management system, is to provide actionable information to the decision makers early enough to actually take action to avoid unpleasant outcomes.

This is where Walter's book comes in. Dr. Vanhoucke provides insight into Earned Schedule as well, but Walter's book is the companion to Mario's. Earned Schedule is an approach to Earned Value - using the same data developed for Earned Value - to forecast the schedule performance of the project.

Both are needed, one is official in the US Government, guided by ANSI-748B.

The Earned Schedule metrics are time based they augment the Earned Value metrics (which are also time based in proper implementations). The detailed schedule analysis is the result. With the Earned Schedule Analysis, improvements in the fidelity of the performance forecast is possible in ways not found in Earned Value alone.

Why is it Important to Read Books Like This?

There are many opinions about the application of Earned Value and its cousin Earned Schedule. Most good, some just OK, some simply misinformed. Earned Value management is both simple and complex. Simple in that the measures of performance are just that simple:

• What did I budget for this work?
• What percent complete did I achieve at the time I planned to achieve it?
• What did I actually spend to achieve the work I actually achieved at the time I planned to achieve it?

That's it in a nutshell. Plan the work and the budget for that work. Execute to plan. Measure the percent complete with some tangible evidence, record how much it costs to produce that percentage of the work at the time I measured the performance.

The hard part comes from controlled the baseline for the work. It does no good to change the baseline for the budget, since that allows the percent complete measure to be stretched. Rubber Banding the Baseline is the term we use. The next hard thing is to define the budget for the planned work. If you don't what work you will be performing in the future, than you can't know the budget for the work.

But if you don't know the work you will be performing in the future, you've got a bigger problem. You don't know what DONE looks like. And if you don't know what done looks like, than you can't manage the project in any meaningful way. The only way you can management it is with the passage of time and the consumption of money. That means when you run out of time and or run out of money, the project is complete. That definition of DONE doesn't sound very pleasant when you spending someone eles money.

 

Be Careful to Check Your Sources

Jurgen has an interesting post about the Illusion of Control, where he bases the principles of his thesis on what appears to be his favorite "journal," (non-peer reviewed) The New Scientist.

Jurgen nicely references a previous post of mine about the Unknown Unknowns, but he missed to origin of this concept. The famous Rumsfeld quote that we're in the pickle we've got ourselves in, in Iraq is because there were unknown, unknowns. Iraq by the way is Arabic for Vietnam.

These are actually ignoramus et ignorabimus - we do not know and will not know.

Much like Rumsfield's hubris, we cannot fall into the same trap (of believing there are UnkUnk's in the absence of actually seraching for them).

The counter to this "we can't possibly know" is David Hilbert's pronouncement:

We must not believe those, who today, with philosophical bearing and deliberative tone, prophesy the fall of culture and accept the ignorabimus. For us there is noignorabimus, and in my opinion none whatever in natural science. In opposition to the foolish ignorabimus our slogan shall be:

We must know — we will know!

Each of our "world views" are formed from experiences, education, training, and of course mentors and leaders. At this point in my career I can look back as a few seminal formation events. The latest is my experience as a Program Manager at Rocky Flats Environmental Technology Site (RFETS). The slight irony of the site name masks the fact that Rocky Flats was in the top 10 toxic sites on the planet. A nice overview of this project can be found at Rocky Flats Legacy Closure Report and Making Impossible Possible: Leading Extraordinary Performance: The Rocky Flats Story.

As a framework for discussion, Jurgen's post is interesting in that he actually defines the three levels along logical partitions. It's the notion that project managers are so naive to believe that charts are the source of information that make me smile.

His 3 levels of technical complexity - independent of the non-peer reviewed opinion pieces in New Scientist - have a good match with reality in their first sentence.

• Level 1 - technologies performing particular functions
• Level 2 - technology as part of a bigger system. The complexity assessment is a separate issue, first comes the system. This is the system of system paradigm common in most non-trivial projects today.
• Level 3 - complexity as a pervasive paradigm. This is called "mega-projects" in the project management world.

Now comes the notional connection with how people implement the approaches to these levels. I saw notional becasue there of course is not backup data, just personal opinion from the domain of agile software development. Good stuff, but a bit lmited in the broader domain of software intensive systems.

• Project and Program managers work on all three levels, not just Level 1. There can be a simple project with a manager and some technical staff. There can be a program manager, with 10's of 1000's or even 100's of 1,000's of staff. A read the The Manhattan Project: The Birth of the Atomic Bomb in the Words of Its Creators provides insight into how a complex program can be "managed," even to the point of "engineering" the solution with a defined goal set out on day one. You'll see there that the simple minded partitioning between the three Levels is just that "simple minded."
• The System of Systems paradigm (in Level 2) has program managers, managing the projects that are the systems in the System of Systems. Future Combat Systems is a recent example I've worked on. Ricky Flats was one. Each building on the site had a project manager. The Program Office held the contract, which flowed down to the Project Managers. Each building manager had accountability for D&D'ing (Deactivation and Decommissioning) the building on schedule, on budget, and according to the regulatory compliance's. Those build project managers had their schedules. Those pesky little Gantt charts Jurgen loves to hate.
• In "mega-projects" complexity is the norm (in Level 3). The Manhattan Project is one. But there are modern Manhattan projects. Y-12 is one. Joint Strike Fighter is another. There are others in the construction business, even in the IT business in government and large industry. The conversion of Washington Mutual's system to Chase was a recent one.

So What Can We Learn Here?

The classification of complexity is one of many approaches. A good approach, but just one of many. Capers Jones' book is a good start at partitioning software intensive systems. SEI has a long lost taxonomy of software development as well. Maybe Bill Nichols can dig it up. A former superviors from TRW and others have a Taxononmy-Based Risk Management, which has some of the same flavor. Maybe this is a useful approach - the taxonomy of complexity in projects - but that's for another time.

• The levels of complexity are important. Without the recognition of what level we are working at, it is hard to have a conversation about what to do next.
• The notion that project manager prefer to "engineer" the future is a bit silly. Project Managers would certainly like to know something about the future, at least to the planning horizon. "Engineering" the future is the role of the technical staff. The future needs to have a time frame. Project managers that attempt to control the future will be disappointed if they are not established the processes to actual perform that control. A plan and schedule is just a map. The work processes are work produces the future. See the RFETS Case Study mentioned above for a simple, clear, and documented example of how to "make the impossible possible," by controlling the future.
• Project Manager "prefer" to use Gantt and PERT charts. This is even more silly. The "plan and schedule," for the project is represented in the network of activities showing how we're spending the customers money to deliver the needed capabilities, fulfill the requirements that implement those capabilities, plan and monitor the expenditure of money and consumption of resources along the way, defined and address the impediments to progress, and of course perform our continuous risk management for every step. A Gantt chart is one of a dozen "notations" used by project managers.
• All good project managers are "systems thinkers." Project and Program Management is a systems engineering discipline, at least in the domain I work. Other domains may not have come to this understanding yet.
• Complexity thinkers can invite the future in all they want. But when your spending someone eles's money, you probably have an obligation to stay close to the budget and schedule. That is one of the roles of "project management." No Surprises, or at least no REAL surprises. Ones that you should have thought of. Ones that you could have thought of if youhad invested more time and money looking for the sources of the surprise.

In the End

• Project management is a process. Sometimes poorly applied, many times successfully applied. My Rocky Flats experience for example. But the use or not use of something like a chart format is not the souce of success or failure on projects. It's the competency of the project manager. The single factor in success is the experience of the Project Manager, was a quote in this weeks program management meeting at a DOE PM conference.
• Accountability and rigor is the next factor for success of a Program and Process process.
• The complexity of the project is a major driver of course, but dealing with this complexity - that is managing in the presence of complexity - is the role of project management.

A commentor on Jurgen's original post says most of it:

One point I'd make is that the curiousness of humans is to try and move things downward in the levels from Complexity to Systems Thinking to "Managed". From a simplistic level, it's moving things from unknown through scientific discovery to used in engineering. Some things are more easily discovered and understood, while others take a lot of effort.

This is the systems engineering paradigm, that appears to be missing from many IT programs. Systems Engineering is defined as (from www.incose.org, the systems engineering professional society)

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.

So the Illusion of control is in fact a false illusion, it is simply the lack is visibility and understanding to the underlying processes. It is the uncertainty - the lack of certainty that creates the problem.

Remember Asimov's quote.

“Any sufficiently advanced technology is indistinguishable from magic.” – Arthur C. Clarke

The points made by Jurgen are a nice distinction (as Boos suggests). It's the processes and solutions to these distinctive partitions that are the problem. With all those non-peer reviewed articles and populist books, maybe a survey of NASA, DOE, DoD, and other enterprise class case studies of how complexity has been addressed, might provide insight to how the problem can be addressed. This is not to say the problems are less in our domain, but the root cause is not the presence of chaos and uncertainty as evidenced by the case studies. It the lack of rigor, discipline, and competency of those those executing the process.

One Final Thought

The successful application of agile software development process to the development of software is well established in some domains. The generalization of those processes outside of specific domains has yet to be established.

Past Performance is a fundamental assessment factor in our domain. Show me what you've done in the past is applicable to my problem as well as your ability to actully perform that work in my domain.

This prevents the confusion between theory and practice.

Quote of the Day

Numerous studies, cited in this book, demonstrate that application of most enlightened environmental management increases profits (since pollution is equivalent to wasted resources) and thus fiscal conservatism and emphasis on private property rights also mean increased environmental protection. Only in an unenlightened society are environmental safeguards mistakenly considered as opposed to business interests and free markets.

From Fundamentals of Risk Analysis and Risk Management, editor Vlasta Molak, CRC Press.

The same could be said of project activities, IT projects, space projects, construction projects. Not managing risk is wasting resources.

More Confusion About Earned Value Management

There is another post about the confusion between the term "value" in Earned Value and "value" in Business Value.

The latest is on Vin D'Amico's BrainsLink site, where he states Earned Value is a Fallacy. Let's start with some history. Popular history has EV starting - in its present form - in mid 1960's. There are other histories going further back. There's a short survey starting then "How Earned Value Got to Primetime," Wayne Abba. Wayne is a member of the PMI Earned Value Management Community of Practice, like I am, who just held it's 27th annual Earned Value Management conference in Naples Florida. This principles of Earned Value go back further than 1964 of course. A quick survey can be found at DoD Financial Management Orders.

That history aside, what does EV measures?

Earned Value measures the "earning" of budget planned for the work. I planned something to cost $100, at the completion of the period of performance I need to look at what was "earned" in terms of that budget. I do this by measuring the "physical percent complete" achieved at that end period. Here's a simple lawn mowing and yard work example.

Our son got paid $20 to mow, edge, and trim the lawn while he was in high school. My budget for this work was $20. BCWS = $20. The period of performance for this work effort was Saturday, sun up to sun down. All that had to be done was "green and clean" between sun up and sun down.

At the end of the day (sun down), I'd step outside and see if the lawn was "green and clean." If it was he was paid $20. That $20 payment is the Actual Cost for Work Performed, ACWP = $20. If I was 100% satisfied (within an error band) with the work - Physical Percent Complete - than I "earned" (BCWP), $20 worth of VALUE. I earned my budget.

That's EV. Well that's the simple minded formula part. The ANSI-748B criteria are on the other end of the spectrum of EV.

Now the personal value for having him mow is much more than $20. If I assume my hourly rate - even on a Saturday - is larger than $20 for work effort, which take more than one hour. So my "business value" is not part of the discussion.

Mr. Amico changes the definition of Earned Value, than argues that EV does not produce that value. Scott Ambler does the same. When Mr. Amico says...

 I think earned value management (EVM) is bunk.

We have to read this carefully and notice the word "think."

EVM’s focus is budget not time or quality so you’ll need to determine schedule and quality status using other metrics.

Yes, the units of measure are "dollars," but schedule performance is part of EV. Earned Schedule, using the same measures is another view of schedule performance. The technical performance of the project is not measured by Earned Value, but it is measured by Measures of Effectiveness, Measures of Performance, KPP, and TPMs. The PMI EV CoP training titled Implementing Technical Performance Measures, is a good start. This issue of integrating Cost, Schedule, and Performance (C,S,P) is actively discussed in nearly every community practicing EV.

But Mr. Amico appears to be further confused when he says.

You can see why the EVM concept appeals to consulting firms. They want credit for the work completed, that is, value delivered, so they can send invoices and receive payments.

There is a fundamental error - made by many - that cost (ACWP) is core to the measurement of project performance. Cost is fundamental to the measurement of budget performance, not schedule performance. The schedule performance index does not contain "cost," the amount of money spent to produce the deliverable. The schedule performance is in units of dollars, that's an issue in principle, but not in practice. This is why Earned Schedule is appealing.

But in the end these type of approaches can be ignored if it weren't for the "thought leadership" of some of the voices. The application of Earned Value provides actionable information to the decision makers in ways not found by simply measuring the consumption of money and time.

So take with a grain of salt, those claiming EV is not the way to go, if those saying so have not actually worked EV programs. This is similar to early XP critics, claiming it can't work. Ask for experience, past performance, examples of the critic they state.

Degrees of Control

In Jurgen Appelo's Management 3.0 there is a conjecture about complex systems, chaos, and managing or not managing this chaos. This weeks edition of Nature, (12 May 2011) has two articles that are important to the discussion:

• In the News and Views "Degrees of control," Magnus Egerstedt, pp. 158-159
• An article, "Controllability of complex networks," Lui, Slotine, and Barbasi, pp. 167-173.

First, these are not anecdotal opinions, but research on complex networks and their control. Second, they are applicable to a wide variety of domains from biology to social networks. Since Nature is a subscription only, copyrighted journal, I'll provide a summary of the News and Views.

One might expect that social networks would generally be harder to control than naturally occurring systems such as biological networks. But this is not so...

(Network are constructed of) nodes of individual decision makers, for instance people in a social network, ..., or DNA segments in a cell. The edges are the means by which information flows and is shared between the nodes.

The flow of information in the  network is what enables the nodes to make decisions or update internal states or beliefs ... The result is a dynamic network, in whcih the node states evolve over time.

Central to the question of how information, injected at certain key locations, can be used to steer the overall system towards and desired performance is the notion of controllablity - a measure of what states can be achieved from a given set of initial states.

Liu and colleagues (the article) found, for several types of network, controllability is connected to a networks underlying structure. ... The surprising result is that driver node tend to avoid network hubs.

The result of this type of analysis is that it is possible to determine how many driver node are needed for complete control of a network.

Let me stop here and restate this idea. COMPLETE CONTROL OVER A NETWORK. The notion proffered in Management 3.0 of self organization and emergent control appears to be flawed in the absence of a domain and context.

One implication of the study is that both social networks and naturally occurring networks , such as those involving gene regulation are surprisingly hard to control.

By contrast, engineered networks are generally more easier to control, which may or may not be a good thing, depending on who is trying to control the network.

So here's the Point

Engineered systems are both robust and controllable. Let's the system emerge in the absence of a controlling paradigm, is likely a bad idea. The Management 3.0 paradigm is devoid of any real assessment of how these networks of people actually interaction, outside of anecdotal and "populist" descriptions of emergent network. This set of articles starts - or restarts - the conversation around how to organize a group of people around creating a solution to a complex problem.

When we encounter a collection of "notions" based on a loose set of ideas and anecdotes, take some time and possibly some non-trivial effort to look into the basis of these notional ideas.

Making Progess to Plan

How can we tell we are making progress to plan? By measuring the tangible evidence that we said was going to be produced from our work efforts.

But the tangible evidence must be produced on the day (or statistically close to the day) we said it was going to be produced, for the cost (or statistically close) to the cost we said is was going to cost, and have the performance needed to be the technical or operational parameters.

Agile and EVM?

There is an initiative to connect Agile Software Development with Earned Value Management. I've talked a couple of times on this topic. While here at the PMI College of Performance Management - the Earned Value Community of Practice - conference I was approach about contributing to PMI's effort to integrate EV with Agile in the new PMI Agile Certification.

My first response is - In what domain? Then the next response - do you have a mandate for EV? And finally - what are you trying improve?

The critical issue is what is wrong with the agile software development process you are using now? Is Scrum working to deliver products on time, on budget, and meeting customer needs?

If so, then what can EV add to the mix? Not much would be my contribution, on programs that do not have an EV mandate?

So let's invert the question. If you have an EV program - mandated by FAR/DFAR clauses, or internal company governance - how can Agile software development add value to the project? The answer is of course yes.

• Agile measures physical percent complete, so does EV through Earned Value Techniques (EVT) measures of progress to plan.
• Agile has bounded scope during the iteration, so does EV through Work Packages and Planning Packages on baseline.
• Agile postpones the details of work that is in the future, so does EV through Planning Packages.
• Agile manages risk through frequent delivery of working products, so does EV, when using a credible IMS and Integrated Master Plan with Accomplishments and Criteria for each Program Event.
• Agile provides for teams to manage themselves, so does EV with Control Account and Work Package managers.
• Agile focuses on deliverables, so does EV through the Work Breakdown Structure terminal nodes.

So what's the issue?

• EV is defined by ANSI-748B. All 32 criteria don't need to be in place, but 11 of the 32 do need to be there. Anyone making up their own version of EV should look to AACEI (International in I), UK MoD, Australia MoD, and most large construction firms use 748B as a starting point before defining the processes necessary for EV's application to projects.
• Agile and EV have much in common once you get above the noise of compliance and the theology of agile.
• Measurements of physical percent complete are needed in both domains. These should be the same in both domains - at least for software. The measurement is "working software."
• The architectural issues need to be worked out in agile. Coupling and Cohesion are critical concepts in all software and more importance in EV + Agile software for a simple reason. The forecast of future performance depends on credible estimates of the work to be done. Re-architecting, untangling poor architecture, refactoring the code to make it better costs time and money. That time and money has to come from somewhere. That somewhere has to be the Budgeted Cost for Work Scheduled (BCWS). That number is on baseline and not easily changed.

So in the end Agile and EV are buddies. But EV starts first, than Agile. The other way around is suggested to be possible. "EV Light," "AgileEV," what ever you call it. Call it anything, but if it's not traceable to the 748B criteria, I'd suggest it's not EV.

 

Deterministic Versus Probabilistic

The world is probabilistic. The world is driven by statistical - stochastic - processes. That does not mean the world is chaotic, uncontrolled, or even uncontrollable.

I drive my car on I-25 to Denver office when I'm in town. Out in the country side, the speed limit is 75MPH. No one of course is going 75. Here in Colorado, open road driving is 80 to 85. My car - a Fire  Engine Red Honda SI - moves right along at 85. I stay in the lane, but the steering inputs are small random movements. At the lowest level the inputs are stochastic. A random, non deterministic behavior. But I stay in the lane.

When we think of  a project's's cost and schedule, those are stochastic processes as well. They are random non-deterministic processes. By deterministic we mean "knowing the EXACT outcome. The underlying numbers are probabilistic, they are not deterministic. But that's doesn't mean they are chaotic. They are random wihtin the probability distribution driving their behaviour. The stochastic process driving their behaviour. This is lost many times in the conversation about "big anything up front." No credible project manager believes that the numbers - cost, schedule, and technical performance - are deteministic. To do so is basic nonsense. I know it happens, but that doesn't not make it nonsense.

So let's look at some definitions here.

Let's put this to work on a "notional" schedule." If we look at a schedule we SHOULD look at the probabilistic aspects not the deterministic aspects.

Each task durations are defined as "most likley" but have probabilitic durations as well. The shape of the probability distribution curve may vary for each "class" work, risk level, and other drivers of variance. The actual schedule looks like this.

If you consider your world deterministic without variance then you're late, over budget, and the thing you're building probably doesn't work - and most of all you probably don't even know it.

Quote of the Day

[W]hen you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it. — Donald Knuth

Quote of the Day - Guessing

Thanks to Bill Nichols for this.

Never make a calculation until you know the answer. Make an estimate before every calculation, try simple physical argument, (symmetry!, invariance!, conservation!) before every derivation, guess the answer to every puzzle.

Courage: no one else needs to know what the guess is. Therefore make it quickly, by instinct. a right guess reinforces this instinct. A wrong guess brings the refreshment of surprise. In either case life as a speculative expert, however long, is more fun.

From Taylor and Wheeler, Spacetime Physics, page 60.

The notion that "guesses" are somehow bad is of course wrong. We guess at this all the time. The confidence in our guessing is what the problem is. A "best guess" is qualified with the variance and confidence of the guess.

Without an understanding of the underlying statistics of the domain, it will be difficult to quantify the guess. The credibility of the guesser and the guess will be suspect.

Quote of the Day - Self Organization

When I mentioned there is discussion on "self organization" in software teams and that some authors use biological processes as example, our biology child sent me this.

Care is needed when making connections between one domain and the other, for those making the connections may not realize what they are stepping in. Notice the last sentence. Fundamental structural organization is one source of self organization, not the popularized "chaos," used in some of my favorite or least favorite agile books.

Complexity versus Simplicity

John Goodpastuer speaks about the difference between Simplicity versus Complexity. "Making things easier requires complexity." While the terms "Easy," "Simple,", and "Complex" all have dictionary definitions, none really have much use in the discussion of "systems."

For example Simple (\ˈsim-pəl\)

• lacking knowledge,
• free from secondary complications,
• a basic element.

But what do we mean actually when we say "simple." There needs be a unit of measure associated with the definition, for the "simple" reason that one man's simple is another man's complex. So how about (\ˈkäm-ˌpleks\) -

• A whole made up of complicated or interrelated parts (noun)
• Hard to separate (adjective)
• Comprise (a multitude of objects)

These definitions don't leave us with an units of measure either.

Let's Look At Complexity First

Complex systems is a field of study that is rife with “overloaded” vocabulary. Words like Enterprise and Architecture are given new meanings [Bredemeyer 2006] as understanding and technology evolve, and each new meaning develops a following. Eventually the followers collide in an interdisciplinary task or meeting. Those who hear other people using the same words tend to assume everyone means the same thing, but in this case, since it isn’t true, each group ends up thinking the other side is being stupid (or has a hidden agenda). It is unfortunately rare that such problems are headed off by a close examination of vocabulary and meanings.

As an example, let us look at a use of the term “complex systems”:

All systems that systems engineers work on are complex. If they weren’t, they wouldn’t need to be systems engineered. Why are you making such a big deal out of complexity when we all have worked with it forever? You must be trying to make money. 

The answer is to use a very specific meaning. A meaning developed by scientists doing research in the area of complexity theory and its follow-ons. Not a meaning essentially "made up" to fit the needs of an author in a book of ancedotal experiences. One of my educational degrees is in Systems Engineering, so I'm biased here.

This domain (systems engineering) uses the word “complex systems” as follows:

Complex systems are systems that do not have a centralizing authority and are not designed from a known specification, but instead involve disparate stakeholders creating systems that are functional for other purposes and are only brought together in the complex system because the individual “agents” of the system see such cooperation as being beneficial for them.

A reasonable and short background in chaos and complexity theory for the systems engineer can be found in [Sheard 2005]. Other material from the INCOSE Systems Science Enabler Group, such as [Sheard 2006], is also supportive of any discussion around complex systems.

Here's a current (2011) definition of complexity in the systems engineering domain - the domain common to the development of software intensive systems:

Complexity is defined as the measure of the difficulty, effort, and/or resources required for one system to effectively observe, communicate, and/or interoperate with another system
[Simpson and Simpson, 2009b: 2].

So here's little story to show that one man's complexity might be another's

When the Hubble Space Telescope (HST) was stranded by the failure of the Columbia Space Shuttle, it needed some way to get fixed. The Wide Field Camera had failed and the NiH batteries were having problems, like all NiH batteries used in your phone and laptop. Frank Cepollina (Ceppie) "owns" the Hubble at Goddard Space Flight Center. The "in orbit servicing" of HST took place with a hands on process. Without the Shuttle, a robot was needed to perform the servicing. There was lots of discussion pro and con for this approach.

Ceppie had three "simple" requirements (mission statements):

1. Do no harm to the telescope
2. Change the WFC
3. Connect an umbilical cord from a external battery pack to the internal DC bus of the telescope

That's essentially what was stated at the Broad Area Announcement during the Industry Days.

The answer - the winning answer - was a robotic servicing mission HRSDM.

Starting with those 3 "simple" requirements (mission concept of operations statement), a "complex" systems was propose, awarded, designed, and started to be developed. Many NASA programs get canceled at PDR (Preliminary Design Review).

Here's the Point

When there are no units of measure of "simple" and "complex," it's difficult to explore the meaning of those terms. What can be used as a starting point are some boundaries for these measures

• Coupling
• Cohesion
• Robustness
• Resilience
• Fault Tolerance

These definitions are of course Domain and Context sensitive. In the Low Earth Orbit business "complex" and "simple" mean something different than "complex" and "simple" in the e-commerce server platform business.

And this is the core problem in discussing nearly anything around these words. Without a Domain and a Context inside that domain, the use of overly-generalized language - language found in recent Agile Management books - is essentially meaningless.

At the risk of being blunt, without an established domain and context for the terms "complex" and "simple," their units of measure, and system architectural examples of these systems, it is pretty much a waste of time to have a meanigful discussion.

As an aside, tools like Lattix and Design Structure Matrix "measure" coupling, cohesion, and other "system" attributes around the complexity discussion.

Is your problem domain the HST and the HRSDM? Probably not. But there are many system exactly like HRSDM or very near, many times more complex. So try to establish the domain, context, measures of complexity in units meaningful to the decision maker, and avoid the simple - and many times simple minded - discussions like "simplicity requires complexity."

References

• [Sheard 2005] Sheard, Sarah. “Practical Applications of Complexity Theory for Systems Engineers”. Proceedings of the Fifteenth Annual International Council on Systems Engineering. (cd).  International Council on Systems Engineering, 2005.
• [Sheard 2006] Sheard, Sarah. “Definition of the Sciences of Complex Systems.” INSIGHT (volume 9 #1). Seattle, Washington: International Council on Systems Engineering, October 2006, p. 25.
• The Growth of Complexity
• J.J. Simpson and M.J. Simpson, "System of systems complexity identification and control," Proceedings IEEE 4th Syst Syst Eng Conf, Albuquerque, June 2009b.

Earned Value and Sofwtare Develop? "Yes We Can"

Can we integrate Earned Value Management with Software?

Yes We Can.

It's always been possible. It's been done. It's being done. Better yet, we can integrate Earned Value Management with Agile Software Development, like Scrum.

Earned Value + Agile = Success is a recent briefing at the National Defense Industry Association Information Systems Summit. This briefing speaks to the issues of DoD acquisition on the application of Agile Software Development methods through the National Defense Authorization Act, Section 804.

Prior to this briefing, the NDIA Program Management Steering Committee meeting in Fort Worth discussed how to successfully integrate Earned Value with Agile Software Development.

There are strong voices asserting this can't be done, this shouldn't be done, it adds no value, haven't seen it done, is a questionable practice. All those approaches seem to be based on "I haven't seen it work, so it can't work."

This is a throw back the the early days of eXtreme Program, where some voices - and I was one of them -  claimed "I can't see how this can work in my domain, so it can't work in my domain."

Here's a recent briefing moving the discussion forward.

Pitt spin-sept-10-ev-in-sw-projects-psp

View more presentations from Glen Alleman

This briefing doesn't tell us how to do it. That's domain specific. But it speaks to what to do and guidance on what steps are needed for success. These are straight forward:

1. Define what done looks like in terms of capabilities for the software. This is the vision and mission statements from the sponsors and funders of the project. We want to process transactions at $0.07 per transaction rather than the $0.11 per transactions we are doing today.
2. Define a release cycles. This is a Rolling Wave and the Planning Packages for the software solution. Define the sequence of working software needed to deliver the capabilities. Each cycle provides working capabilities, just like in agile. Formal process like DoD 5000.02 have this on the SDD (Milestone C) phase. Other development processes do as well as large construction or deconstruction (D&D is one area we work).
3. Define the tangible outcomes for each iteration. This is a natural approach for all successful projects. Measure these outcomes in physical evidence of compliance with Key Performance Parameters, Measures of Performance, and Technical Performance Measures.
4. Define tangible evidence of physical progress to plan on fine grained boundaries. Answer the question "how long am I willing to wait before I find out I'm late?" Measure physical percent complete at some finer grained boundary to allow enough time to take correction action to actually avoid being late.
5. Measure the performance of development in tangible units meaningful to decision makers. The best measure of money. "Story points" might be OK for developers, but "story points" don't show up on the balance sheet, and aren't in the Control Account Plan (CAP), and EV is not measured in Story Points. The core reason is Story Points are a relative estimate of effort, and not a quantified measure of something tangible, like money or time. Do something about this for agile projects to be considered part of the business.
6. Identify impediments to progress and have a mitigation plan. Risk is how adults manage projects. Don't use the unit less blather that "agile reduces risk." Measure the risk reduction in cost, schedule, and technical performance improvements.

There is a lot more here of course, but don't believe Earned Value and software development can't be integrated, even agile software development. The excuses used by those saying it can't are just that excuses.

• Managers using EV to appear to make progress? I'm calling BS on this. EV measures tangible evidence of progress. Not measuring tangible evidence of progress to plan (agreed deliverables at the end of the iteration), then you're not doing EV. You're lying to others and your self. That's EV that's bad management.
• Not reporting actual deliverables? That's actually a violation of the Federal Acquisition Regulation in our domain. You're a felon. You're also a bad project manager.
• Listening to horror stories of how it can't work? Stop listening, go find stories of how it does work. Any fool (a lazy one at that) can find examples of stuff that doesn't work. Go look for how others made it work and learn from them. Stop listening to people who have never made it work, tell you it can't work.
• Can't tell the difference between ANSI-748B Earned Value and Business Value? Get a grip, read the guidance, do you're home work, grow up and be a real business and project manager.

There are many voices around this topic, but please focus on "solutions" not whining "I can't make this work."

Clarity of Purpose

When the word Earned Value is used in the same sentence as Software Development, it appears to trigger a visceral response in some. There many definition of Earned Value on the web. Most a flawed in some way. Some are seriously flawed, some are wrong. Along with this are many mis-understandings of what Earned Value is, what it's purpose is, and how it is applied to project. Some of this mis-understandings are just that. Some are mis-informed, so appear to intentionally be mis-informed. Meaning "I don't want to know how it actually works, I want to use my definition because it supports my agenda."

So let's start at the top. Applying EV to software projects works, has worked and is working as we speak. Not observing EV working on software projcts, doesn't mean it doesn't work.

Now if you can't make it work, haven't ever seen it work, or don't know how to make it work, or don't know anyone that can help you make it work, or aren't convinced you're even interested in making it work, then don't try EV on your software project. Stop reading right now, go back to what you were using.

It may well be your project is not ready for EV. It may be you're not ready for EV. It may be you and your project are not right for EV. You may never be right for EV.

But don't assume that EV doesn't work for software.

What Should Management Know About Earned Value?

First the "value" in Earned Value is not the same as the "value" in business value. The "value" in Earned Value is not the same as "story points," Use Cases, the value discussion between the agile development teams and the customer or any notion like that.

The Value in Earned Value (BCWP) is how efficient are we spending the Budget (BCWS). Earned Value make no judgement of the "value" to the customer. This "value" (the business value) is very subjective. Very much at the whim of the market, the financial decision makers, the politics of the organization, and all sorts of other "human" foibles.

So What Does Earned Provide Us?

1. Visibility to the budget efficiency - If I spend a dollar, do I get a dollars worth in return?
2. What work is on the critical path and how is the budget efficiency for that work?
3. Where is the budget assigned and how is it being spent?
4. What corrective actions are needed to put the budget efficiency back on track?

Staining the Deck EV Example

Earned Value measures are the measures of "earned" a value compared to the "budgeted" value.Here's how that works in a real live example at our house in Colorado.

If I budgeted $1,200 for the staining of our deck. And this job was to be performed in 3 weeks, starting April 25th and end May 13th, how can I tell if the deck staining project is on budget and on time. The actual deck is about 900 square feet, so let's look at an Earned Value paradigm of this project.

If I naively assume the staining job is linear in both cost and work effort, than at the end of the first week, there should be 300 sf of staining complete and the contractor should have consumed $400 of labor and materials (we didn't separate labor from materials, since this is a naive example).

I'll add one more twist to this deck straining from real life here in Colorado. I want to use the deck while it is being stained. So when the first third of the deck is stained (assuming is dries really fast) I want to sit on it over the week end. I don't want the deck un usable for three weeks. We've got a Kentucky Derby Party, Saturday May 7th and a few neighbors coming over.

So I come home from the office on that first Friday May 6th (assuming he started on Monday) to see the following:

• 250 sf was stained
• $400 of labor and materials was accured. (EV needs accrual accounting)

As an EV Program Controls Manager, what can I learn?

• We're right on budget (planned $400, spent $400)
  
• We're behind on the work by 50sf (planned 300 sf, did 250 sf)
  

But actually we are over budget, because the square footage planned to be complete is 300 sf for a cost of $400. Unless the contractor is going to do the remaining 50 sf for free, it will cost more, So I'm both over budget and behind schedule.

He's behind schedule, because the remaining 50 sf needs to be done sometime and over budget because to do that remaining 50 sf, someone has to pay and it ain't me. The Kentucky Derby Party members are going to be short 50 sf of party space. Since neighbors on both side are Program Managers and work EV projects, they're going to ask "what's your get to green plan, you're behind schedule and over budget, pass the Pinot Noir, and what horse did you pick?

So what does this mean to an IT project?

Let's not assume we care about the software development method. OK, we like Scrum, let's use Scrum. I like Scrum and use it where ever possible.

But let's put on our business management hat. I have a budget of $120,000 for developing an application and budgeted 3 months for the work. This application has planned for 90 features - all relatively the same effort. That pencils out to be something like 60 work days (assuming 20 per month which is not always the case and why MSFT Project males a crappy EV engine), and that pencils outs for two people to be 960 works hours (assumes 8 hours days) and $125/hour per person per day. These are well paid developers, cause we're in Boulder and they are retired IBM'ers and expect to be paid what they are worth. (I can see IBM Global Services from this deck).

So now I come home from my office to have a look at the application (with all the naive assumptions of linear work effort and linear work productivity). And I've assumed that what is produced at the end of the first month I can actually put to work in my day job (not the Derby Party).

But what do I find?

• The code that was developed is missing some features that I was told were going to be there after the first month. Let's say there 1,200 features for the whole system, and using our naive assumption 30 of those would be in place, 100% usable at the end of the first month. Just like those agile developers assured my they would be. Remember I have $120,000 for this little application and 3 months to get it done.
• Well the status review and demonstration shows me I have 25 features. I got to pick which ones didn't make it into the release, just like a good Scrum product owner would.
• My retired IBM'ers spent the planned number of hours and didn't raise their rates, so there is an invoice sitting on the table on my newly stained deck for $40,000.

But now I do the math.

• Budget looks like what I was told. $40,000 per month for 3 months (20 days per month) for $120,00 Budget at Completion (BAC).
• But where's my 30 features. I know I agreed they could drop 5 of the them when they did their weekly reviews. But how are those missing 5 going to get done? The developers are working at their planned pace, not to fast, not too slow, but just as planned. And not they're 5 features behind schedule, and on budget for the 30 features, but not for the 25 features.
• Each feature is now diluted (reverse dilution actually). If I pencil out the cost per feature of the planned features it comes to $1,333.33 per feature. But with only 25 features delivered they actually cost $1,411 oer feature at the end of the first month.
• Well that's a problem. They've spent what they planned to spend, but under delivere by 5 features. So to supply the 5 features, which I agreed to postpone but drop, they'll have to spend more money.

Now at the 2nd week we have similar results:

• First instead of the planned 30 features (again assuming niavely they are all equal, with equal work effort), they need to produce 35 features.
• But since the budget for the last week was spent as planned, they'll have to do those 35 features for the planned budget of $40,000 which means they will get paid only $1,142 per feature instead of the expected 1,333 per feature. This is called "margin erosion" in all the businesses I've worked.
• Those great developer caught up and did those 35 features and kept on budget - they only spent $40,000 in the month as planned, so now we're back even on time and on cost.

But since we're doing accural accounting in the best GAP manner, they have "under absorbed" on cost to the tune of $190 per feature to date after the 2nd accounting period.

At the end of the 3rd month, there is another situation.

• All the planned 30 features for the 3rd month are done on time and for the agreed on cost of $120,000.
• But when we pull together all the features\, there is one of those pesky "system integration" problems, that requires for more work. Of course this work takes money.
• We now have over spent, we're late - not by much - but a few days, and finally I get all the features I wanted for a little bit more than I planned and a little bit late.

That's how we use Earned Value. But who cares, you say? You could use Story Points in the same way. You could monetize the story points you say. yea you could do that, but here's the rub. There are other aspects of Earned Value missing from the simple Story Point measures.

• Earned Value provides forecasting calculations like the To Complete Performance Index TCPI), that tells you how much you need to improve your efficiency to keep the schedule.
• The Estimate At Completion (EAC) calculation that will forecast what this is going to cost if you keep going the way your going.

Yes, you could do the same with Story Points. And that's the Point. The units of measure of Earned Value are Dollars (currency). If and only If (IFF) you use the Earned Value formulas, the agile development processes of Scrum, with Story Points, charts (burn down, burn up doesn't matter) with the proper scales looks just like those sen in Earned Value.

Here's the Punch Line

Once the development team doesn't deliver the planned outcomes for the planned cost at the planned time, something has to give. Either we're late against the plan, or we're unfavorable to the budget, or both. Now that we know this some corrective action can take place. But the critical piece here is we know it.

Unlike the "burn down" charts found in some agile team which tracks features and not money, EV tracks both schedule variance and the cost variance. Project Managers and those providing the funding are interested in both.

Earned Value and Agile Software Development - at the work management level - are a match made in heaven. Look here for examples of how to do this Successfully Integrating Agile with Earned Value Management and Earned Value + Agile = Success.

Don't buy the mis-informed notion that EV can't be used on IT projects. It's not true. I say that with the conviction of an EV practitioner on software intensive programs using agile methods for development.

But unlike those little dead red herrings tossed out there to argue with, EV projects and for that matter any project that would be considered credible must have - and I emphasize MUST - answer the following 5 Immutable questions:

It's number 5 that agile can measures in "story points," but that is just part of the measurement.

• What is the impact of the "missed" work? Work that was planned but not delivered at the planned time?
• What is the cost of this "missed" work. If the work is going to be done, but the budget was spent on the previous work and the "missed" work didn't show up, who's going to pay? How much over budget are we?
• How much will is cost to get caught up with the work we missed?
• Add to that "rework," how much will it cost in total?

One straight forward way to do this is to apply the 11 criteria (out of the 32 found in ANSI-748B) to your project.

The Final Piece of Advice

• Don't apply Earned Value and Earned Value Management if you don't know what you're doing. You'll fail. You'll then enter that realm of bitching about how EV can't be applied to IT projects and join the ranks of those failing to ask favorite Talking Heads line from Once in  Life Time (1984)  "how do I work this?" (along with "that's not my beautiful wife!")
• Don'y apply Earned Value is you don't have a credible understanding of what "done" looks like, have some kind of budget for done, know what your productivity for getting to done is, can measures progress toward done in some units meaningful to the decisions makers, and have some sense of what the hell is happening on the project on a short term basis to answer the question how long am I willing to wait before I find out I'm late?
• And for God's sake don't even let anyone talk you into proceeding with a naive/fictitious schedule and estimate committed to far too early in the project, and then blame EV for problems.
• Get real, grow a pair, and be a credible project manager and look around to see how Earned Value is being applied on software intensive projects with success. Ask question, explore a little, seek advice from practitioners of this craft and stop listening to the un-informed.

And as we say here in the space and defense business.

OK we're done for now, everyone back to work.

I know this has been a long post. EV is simple, but mis-understood, mis-applied, and many times simply used to counter what ever arguement someone is makig for their tool or process in the absence of understanding that EV has tangible benefits when applied correctly.

Here some more background

• The Simple Problem of Schedule Performance
• A Gentle Introduction to Earned Value Management
• Techncial Performance Measures