Herding Cats

Project Management Manifesto for America

The Project Management Manifesto for America is the starting point for improving the project management of the American Recovery and Reinvestment Act.

Simple, Isn’t Really Simple

During a discussion – of sorts – with Mary Poppendieck about Chapter 2 of her upcoming book, I suggested several ideas needed clarification regarding the use of "Waterfall" in modern project management. Mary forwarded a paper – an opinion piece actually – from Denning, Gunderson and Hayes-Roth titled "The Profession of IT: Evolutionary System Development," Communications of the ACM, Vol 51, No 12, December 2008.

Mary's book by the way looks like good reading – as usual. It is completely my issue, when I get wrapped around the axle about the details of how information is being presented. The perfunctory simplification of a topic for editorial reasons, or simply because of one's point of view. The use or mis use of Earned Value and the understanding or misunderstanding of such a topic is typical of the exchange between agilest and traditionalist. Dave Nicolette has suggested a discussion of the irreducible principles of project management to turn the light on the differences between principles and practices and that agile and conventional practice have much in common.

In this article they suggest that the failure of large systems is caused by inability to rapidly adapt to the changing environments. They provide an example of a system built within the U.S. Department of Defense using an agile approach:

The W2COG is a self-selecting collaborative community of experts formed among federal agencies, DoD, and commercial firms to enable agility, aka "netcentricity," via adaptive, open, SOA by removing the traditional barriers to cross-stovepipe collaboration.

W2COG projects …"include netcentric studies, demonstrations, and prototypes of bundled off-the-shelf capabilities validated against operational use cases. These are essentially "reference designs" if you were in the hardware/firmware platform business.

One of the backgrounders states …

Joint Interoperability Test Command (JITC) employs the W2COG Institute (WI), a government and industry expert body established by OSD, to serve as a computer network-enabling "Capability Broker." Accordingly, the WI has designed a "Mission Thread Market" (MTM) process to incentivize sustained COTS software competition around government use case requirements in 90 day production cycles. In particular, Government seeks to incentivize industry to bind innovative SOA solutions to government-furnished high assurance services, e.g. for authentication and authorization.

The ACM paper goes on to state several things that need some examination:

• Dependable large system can only be attained through rigorous application of software engineering design process (requirements, specifications, prototypes, testing, and acceptance).
• The key design objective is an architecture that meets specifications derived from knowledgeable and collectable requirements.
• Individual of sufficient talent and experience can achieve an intellectual grasp of the system.
• The implementation can be completed before the environment changes very much.

So like many topics in our domain, simple answers usually come from simple understandings. When in fact the actual understanding is much more complex. So I decided to do a little weekend research.

The authors provide no references for these assumptions. So it must be assumed these are their personal assumptions. They then proceed to use these assumptions with the anecdotal examples of failed systems. Several examples of failed large systems include:

• FBI Virtual Case File – a project that violated every single principle of project management on the planet.
• NMCI – a project that "failed to meet its two strategy goals," according to the GAO Report titled:"TECHNOLOGY: DOD Needs to Ensure That Navy Marine Corps Intranet Program Is Meeting Goals and Satisfying Customers," http://www.gao.gov/new.items/d0751.pdf

Examples of successful projects using evolutionary design include the World Wide Web and Linux.

Comparing Apples to German Sheppard's

While there are well document failures in the large complex systems development business, providing a counter example of the WWW and Linux seems curious. The web is certainly evolutionary as is Linux. But these were projects whose market was evolutionary and emergent as well. The FBI Virtual Case File systems and the NMCI system had specific operational needs, with measurable business and mission benefits. Not the same as a solution looking for the problem. As a very early user of DRAPA – Net at Wright Patterson Air Force Base, we had "interest" in communicating over a network that was not dial up. But I doubt anyone who was a user at our level – FORTRAN signal processing programs using DEC-10 running BBN's Tenex. There were visionaries for sure. It wasn't us though.

But the FBI VCF and to some part NMCI were purpose built systems, with the "capabilities" predefined – solve this problem in this manner.

This by the way is one of those diversionary approaches by some in the agile community. Use an example of poor or even downright bad management as the counter example for some agile techniques.

The FBI Virtual Case File

The VCF failures are well documented:

• Lack of a strong blue print from the outset led to poor architecture decisions – what does "done" look like?
• Repeated changes in specification
• Repeated turnover of management
• Micromanagement of the developers
• Use personnel with little or no domain experience for software development
• Scope creep – continuous adding requirements while at the same time experiencing schedule delays and cost overruns
• Code bloat due changing specifications
• Adding more people as the project fell behind. An explicit violation of Brooks' Law.
• Planning to use a hard cut over, removing any chance to "try before buy"

NMCI

GAO reports states … "analysis of available performance data, however, showed that the Navy had met only 3 of 20 performance targets (15 percent) associated with the program's goals and nine related performance categories. By not implementing its performance plan, the Navy has invested, and risks continuing to invest heavily, in a program that is not subject to effective performance management and has yet to produce expected results."

... "analysis also showed that the contractor's satisfaction of NMCI service level agreements (contractually specified performance expectations) has been mixed."

… "analysis further showed that NMCI's three customer groups (end users, commanders, and network operators) vary in their satisfaction with the program."

Sounds like your typical commercial enterprise project doesn't it? One telling statement in the introduction of the GAO report states …

A plan that the Navy developed in 2000 to measure various aspects of the program, and thereby gauge program goal attainment, has not been implemented, and associated performance reports have not been issued. According to Navy officials, implementing this plan has not been as high a priority as, for example, deploying NMCI and measuring contractor performance. While program officials told us that NMCI has achieved much, they were unable to provide performance data to demonstrate these achievements relative to either the program's strategic goals or the nine performance categories that its 2000 performance measurement plan and other initiatives defined for these goals.

Gee no plan to measure the performance of the various aspects of the program? Sound familiar.

Why And How Can Evolutionary Approaches Correct Poor Management?

The authors don't actually say how. They do reference the W2COG project. Remember this is an integration process of openly available COTS products of a communications system. Now there is a poster child for failure in that area as well. The World Wide Military Command and Control Information System (WWMCCIS), http://archive.gao.gov/d47t13/116661.pdf.

There are some interesting causal issues here:

• the operational concepts were stated too broadly
• the plan prematurely focuses on system architecture
• centralized program management of the current system (WIS) is necessary but unattainable
• modernization efforts were unlikely to resolve the problems with the existing system (WIS)
• an approved concept of operations is needed before proceeding
• detailed information requirements is inadequate
• reliance on technological advances is unwise

In the end the killer statement from this 1980 report is …

Without first identifying the critical data elements needed to carry out assigned missions, the usual result is a system design that does not completely or efficiently meet the needs of all its users. Identifying these data elements before system design and acquisition is essential to ensure proper system sizing and capacity, and hence responsiveness, as well as providing clear guidance to software developers. For these reasons, identification of detailed information requirements--the essential data elements and their associated qualities of timeliness, accuracy, and currency-is incorporated in both DOD and the Office of Management and Budget directives on developing automated systems.

So Why Would Evolutionary Systems Alone Help?

Several fundamental axioms of system development include:

• We need to know what "done" looks like in some way. Without knowing this, time and effort may be applied to work that does not proceed toward "done."
• We need to know at some level of confidence what this will cost in the end.
• Same for duration – some level of confidence how long it will take.

The WWW did not need to operate under these constraints.

So How Can the Best of Both Worlds Be Combined?

This is an ongoing question. No doubt agile has much to offer for the development of software. But for large, complex, mission critical, enterprise systems, can agile alone provide all that is needed for success. The ACM article makes that case, in the absence of evidence though.

Using the NMCI example (an integrated internet solution for the Navy and Marines). How would an evolutionary system development work in the field? In the field of combat Marines with Navy support? Would the Marines get partial capabilities, then upgrade to more capabilities over time? How those upgrades would be managed. Would everyone have to have the same version of the system in order to communicate? Good questions? NMCI is probably not performing as planned. "Users find it does not meet requirements, is inflexible, and has long waits for trouble assistance" [Marine Corp Gazette, Dec 2008]. OK, and evolutionary deployment will fix this?

Maybe. Maybe not. The first problem seems to be no one wants to admit there is a problem. How exactly would evolutionary development make the problems visible in ways not currently being done.

And The Answer Is?

Establish an irreducible set of project management principles. If these principles cannot be found in the programmatic aspects of the project, the project will likely be headed for failure. What are these irreducible set of principles?

Rapid adaptation is nice. But within what principled boundaries. Do the Marines get to choose what machines they use, what networks they communicate over, what software gets loaded on those machines? Probably not.

Did the FBI VCF project come unglued because it was not adaptive to change? That's not what the report says. Only mention of the poor project management processes, manipulative vendors, simply bad leadership.

In The End

When the discussion continues to mix software development methods with project management, we will continue to get sideways with overlapping methods. I'm not hopeful this will be resolved. PMI is starting to use the term "agile." At one time I was adamant that process and product was the same thing in the project management space.

I no longer believe this is a good idea – project management processes (project controls) and product development (software development) are separate - both needed, but not interchangeable.

Bill Duncan is currently spewing out his breakfast coffee at the sound of this admission.

The Core Elements of Program Planning and Controls - Project Accounting

Project accounting is many times confused with project management.The Project Manager is most interested in Schedule. Project accounting is interested in Cost. The critical success factor here is the derive the project costs from the project schedule. Most often we speak about "cost and schedule," it should actually be "schedule and cost." This is subtle but important:

• The "control accounts" are the intersection between the Galvanization Breakdown Structure (OBS) and the Work Breakdown Structure (WBS). The Who and the What.
• Each "control account" must have a Control Account Manager (CAM). This is not just an aerospace and defense notion. If there is not a simple person looking after the cost AND schedule, then they will be disconnected from day one.
• Budgets for these Control Accounts are derived from the cost spreads in the schedule.  This may seem counter intuitive, since in most immature organizations, budgets are handed down from on high. This of course is the "kiss of death" for the project. The budget is build up from the planned work. If the resulting budget does not have sufficient funding sources, these budgets must be changed. This is an iterative and incremental process - in the best tradition of "agile." Once the Planned Budget - the Budgeted Work for Work Schedule (BCWS in EV terms) matches the Available Funding , the cost and schedule baseline can be established.
• The resulting budget must be time phased and expressed in terms of direct costs and the resources funded by those direct costs. Having a lump sum budget for the project, in the absence of a time spread for that budget hides the cost performance numbers from everyone.
• Tracking budget performance is important. But equally important is tracking schedule and product delivery performance against this budget. "How much physical progress shoudl have been made at a point in time compared against the planned cost of that same physical progress?" Periodically answering this question provides insight into how both cost and schedule are proceeding. This is the role of Earned Value.

The Core Elements of Program Planning and Controls - Program Planning

Here's the essential elements of Program Planning:

1. The Work Breakdown Structure (WBS) and Organizational Breakdown Structure (OBS) are integrated to show who is accountable for what deliverables.
2. Schedule and Cost are integrated for the same periods of performance. It's not "cost and schedule," it's "schedule and cost." Make every effort to derive costs from the schedule. Either a resource loaded schedule, or a schedule that drives cost through a spread sheet.
3. There is a Master Schedule showing when the deliverables will be delivered, what work is needed to produce the deliverables, in what order they will be produce, and who is doing the producing. Build this schedule through the deliverables, not through the functions. Try as hard as you can to NOT have a schedule showing Requirements, Design, Develop, Test, Deploy. But a schedule that shows those functions for each deliverable. Same is true for the WBS. Product focused WBS's are the only way to build a credible description of the project, no matter what anyone says, even those claiming to be authors of PM Bodies of Knowledge. It's simply not allowed in the federal government PM space. So why do it anywhere else.
4. Work is performed in an authorized sequence. No skipping ahead. It ruins the fun to skip ahead.
5. Physical evidence of progress is the only measure of progress. This physical evidence needs to be defined ahead so you can recognize it when it comes. No hand waving. No soft assessment of "also most done." You're either done or not done.
6. Changes to ANYTHING only happen after they are authorized. No making it up as you go. No cowboys, no "making it better," without approval to make it better.

Waterfall? Not Allowed!

    The Red herring of Waterfall has risen again as the favorite stalking horse for agilest when trying to find some way to sell their approach. There are several issues with this tactic, not the least of which is Waterfall as described by an agilest is actually prohibited in the government sector. The second issue comes from the favorite reference to the Royce's paper on Waterfall (father and son). Ignore the details of the paper and use it as an example of how Waterfall was pulmigated and still in use.  But you need to read the fine print in this paper to discover iterations, customer involvement, "do it twice," feedback up and down the line, etc. etc. For 1970 this was far out stuff.

How It's Done on a Larger Scale Today
    The actual top level procurement process for government (DoD) acquisition is an incremental and iterative approach described in the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System. Notice all the loops in the "W" style systems engineering process down in the Technical Section. Of course this approach should NEVER EVER be considered outside projects larger than $20M. Of course $20M is chump change in the DoD world. But the point is NEVER NEVER speak of this process in any form when discussing procurement or development process in the commerical world.
    But at the same time the Waterfall Red Herring is not allowed even in this world. So why on God's green earth do agile thought leaders speak of Waterfall as the process they are trying to replace. It's simple marketing really. Find the ugliest, least successful, worst track record approach to developing software and use that as your comparison. Never mind that all the "evil" outcomes of the described process are actually BAD Project Management Practices.
    In the end ANY project management method - from "magic beans" to DoD IMP/IMS using ANSI-748 Earned Value needs to have an irreducible set of PRINCIPLES on which to base their PRACTICES. Principles and Practices are different. I already spoken to the irreducible principles that can be found in PMBOK
    So the question can be asked again. What principles of project management would NOT be found in any credible project management practice? I might suggest Procurement would be one. But I'm stumped to think of any others.

Separating Principles from Practices
    So when the latest critique of "waterfall" starts out the discussion rarely if ever is about Principles. It's almost always about practices - and bad practices at that. It's like complaining you can't loose weight while eating Big Macs morning, noon, and night. That !@#$'ing MacDonald's diet just doesn't work. Really? You Think?
    Look at the Principles here and ask which ones you would not want in your favorite project management practice. Now the practices can range from back of a napkin, white board or some other favorite media - to a full blown SAP (heavens no, please) based program management process framework.
    I might conjecture if you ask and answer the project management process questions in this manner all the "us versus them," the "they were really not very smart in the past," and other opening apporoaches to project management replacements go away. And what you're left with is an assessment of th type of Practices best suited for your domain and context.

Agile Status v. Deliverables Based Status

Jason Yip has a nice post describing the status expected from an Agile project. From the point of view of an agile iteration these are:

1. Is the project going to succeed in terms of achieving scope goals within time goals?
2. Where is the project trending in terms of velocity (i.e., rate of completing work)?  Does it require intervention?
3. Where is the project trending in terms of scope increases?  Does it require intervention?
4. How far have we used up overall project buffer in terms of cost?  Does it require intervention?
5. Are there any other issues that require intervention?
6. What was committed to and completed?  What was committed to and not completed?  Why?

From a Deliverables Based Planning^sm approach these are:

1. What is the physical percent progress for the defined deliverables? Each deliverable is implemented in a Work Package. What is the earned value (or some other measure of physical percent complete)?
2. What is the To Complete Performance Index (TCPI) for the collection of Work Packages and the Project?
3. What are the approved changes and what impacts have resulted to the Work Packages in terms of budget, schedule, sequence, and outcomes?
4. How is the project margin erosion trending compared to the planned margin erosion?
5. What is the content of the Risk Registry, the mitigation or retirement plans for each risk, and the allocated budget for these efforts?
6. Are the planned deliverables being actually delivered according to plan? If not, what is the "get to green" plan for the remaining work.

It's not Waterfall versus Agile, It's sample time

The "red herring" of waterfall is rising again. The proponents of agile use waterfall as the whipping boy (or girl) for what's wrong with software development processes. What is completely lost here is:

It's not the serial process that is the problem, it is the improper sample time between process steps before corrective action is taken.

All processes are serial in the end. Steps are taken one at a time, in some order. The old saw:

What is the purpose of "time,?" To keep everything from happening at once

In the control systems world - and one of the anti-serial process authors claims to have been a control systems engineer - the sampling time in the control loop determines how responsive the loop is to change.

• Sample slow, respond slow
• Sample fast, respond fast

Of course it's not quite that simple, but that's the rudimentary principle. You're house thermostat has a few minute sample time, plus a delay for restart, plus a dwell time for shut down. Same for the air conditioner compressor. Your cruise control has a difference sample-compute-response behavior. Our crappy 1997 Suburban cruise control used to hunt when climbing I-70 west of Denver. It was not tuned to the engine, the load, or the grade, but taken from the Chevy Impala - like the A/C compressor. The flight controls for a 777 have difference response times than the controls for Joint Strike Fighter.
   
A "design, code, test" cycle in months has a different response time than one that samples the resulting output in a month, two weeks, or even a day.

    All processes are serial in some form. Parallel activities can take place, but the value stream is usually serial. If it were parallel there are concurrency issues, integration stabilization point issues and a hoard of other artifacts caused by parallel developments.

• Serial is good
• Serial means least rework
• Sample times MUST be tuned for the context and domain

Any control system engineer knows this. You can learn more starting here.

The Core Elements of Program Planning and Controls - Organizing

    Here's the essential elements of the organizing processes for a project:

1. Are all the authorized work elements of the project defined? Who gets to say what the project is doing? This is sorted out in the project chartering session. Chartering defines the "rules of engagement" for the project.
2. Is there a credible Work Breakdown Structure? By credible I mean one that describes the deliverables? A WBS should NEVER describe the functions of the organization. The customer bought a product or a service, not the functional organization that produces it. If you succumb the notional that there are alternative WBS, including ones describing functions, your project is Level of Effort and has no tangible measures of progress.
3. What is the project's organizational structure? Build a RAM (Responsibility Assignment Matrix) and define the Accountable people first. Then stop. Have those Accountable define the Responsible people. Ignore the Informed and Consulted useless you really think this will add value. Hold those Accountable for being Accountable, everything else will flow form there.
4. Integrate the planning, costing, WBS, OBS (Organizational Breakdown Structure) and risk management into some sort of "seamless" system. 
5. Make sure Cost and Schedule are inseparable. By inseparable I mean they are one and the same. No disconnects between cost and schedule.
6. Define the deliverables, what the measures of "done" look like, what the incremental measures of "done" look like, in units of measure meaningful to the stakeholders.

The Core Elements of Program Planning and Controls - Introduction

    There are several posts out in the last week describing planning and scheduling methods. Some are useful, some are repeats of the obvious, a couple are simply wrong and one is nonsense. Some are based on PMI's PMBOK (which by the way is not really organized around a method, but is a collection of processes and knowledge areas that can or shoudl be found in a credible method).
    I'll do this in a series of posts, describing the core elements of any planning and controls method. My motivation here is Paul Ritchie's "check list" post. The notion of a check list is obvious, but overlooked. The elements in my "check list" are guided by the Earned Value Management framework:

1. Organizing the project
2. Planning, scheduling, and budgeting the project's work
3. Project accounting processes
4. Analyzing the project's performance and producing management reports
5. Revising the project's plans and maintaining the integrity of the baselines

No matter what project management method is used, these 5 elements need to be present in some form. These are not the technical aspects of the project, but are the programmatic elements. Whether you're using full DoD IMP/IMS, some agile method of development, or so ad hoc made up "magic beans" these needs to be there.
    Why? Good question. There is not simple answer of course, but here are some starting answers. The stakeholder needs know at least four things at all times:

1. When will the project be done?
2. How much will it cost when it is done?
3. What are the impediments to progress and how will they be removed?
4. How are you measuring real, physical, quantifiable progress to the plan?

Simple Never Is

    The notion that there are simple project management processes is just that "notional." There are straight forward processes. There are important and less important processes. There are processes more complex than others. But "simple" usually means simple results, simple understanding, simple results.
    I've talked about the Irreducible Program Controls elements in the past. Here's my current thoughts on the Irreducible Program and Project Management Principles:

• Capabilities Drive Requirements - capabilities are what business people measure success with. The underlying technology is interesting to technology people.
• Requirements are fulfilled by Work Packages - detailed schedules (or the lack of detailed schedules) are interesting to schedulers, planners, developers and engineers. But deliverables are interesting to business users.
• Work Packages Define Deliverables - without a clear and concise of what "done" looks like, all the detailed planning is worthless. Define "done" at the Work Package level. This could be a Scrum iteration if you are so inclined. But keep the planning details to the Work Package and deliverables level until forced to go deeper.
• The Performance Measurement Baseline (PMB) describes the sequence of work - putting the deliverables in the order of production is a good first step for planning and scheduling. Remember "the reason for 'time' is to keep everything from happening at once."
• Measure Physical Percent Complete First - effort and duration are not measures of progress.
• Perform only authorized work - doing work out of sequence simply creates more confusion.
• Use Earned Value (or some equivalent) to define progress - it doesn't have to be full blown 748 EV. But answering the question - "what did I get for the money I spent?" "How much money did we plan to spend to get this deliverable?" and "do I have enough time and money to complete this job?" are discussions around Earned Value.
• Adjust the estimates of future performance from past performance - Earned Value can tell you this. Velocity in agile does not. It is yesterday's weather, using level of effort labor spreads. Agile does speak to deliverables, but that's it only connection to Earned Value.
• Use Technical Performance Measures to pre-define "done" - TPMs are measures of product or service performance defined before the work starts, so you can recognize "done" when it arrives. These are NOT tests, they are capabilities and the fulfilled requirements that enable them.

These are principles, so remember ...

Principles that are established should be viewed as flexible, capable of adaptation to every need. It is the manager's job to know how to make use of them, which is a difficult art requiring intelligence, experience, decisiveness, and most important, a sense of proportion
- Henri Fayol, General & Industrial Management

Science and Pseudo-Science

    The urban myth going around the office is that an egg can be stood on its end two times a year, at the equinox. The equinox of course is when there is equal light and dark and as nothing to do with gravity and egg standing tricks.
    While looking on the web for "myth buster" articles for my colleagues, I was reminded of some long ago experiences. While a graduate study I was privileged to be in the presence of two icons of the physics world. Our principle investigator Fred Reines and a frequent visitor Richard Feynman.
    Here's some videos of Feynman, that provide insight into one of the 20^th century's best thinkers. Listen to the thought processes and the development of understanding in the presence of mystery.

Some Serious Misunderstandings About Earned Value (update)

The Department of Defense Earned Value Management Implementation Guide, October 2006 says:

1.1 Concepts of Earned Value Management. Earned Value Management (EVM) is a program management tools that integrates the technical, cost, and schedule parameters of a contract. During the planning phase, an integrated baseline is developed by time phasing budget resources for defined work. As work is performed and measured against the baseline, the corresponding budget value is "earned." From this earned value metric, cost and schedule variances can be determined and analyzed. From these basic variance measurements, the program manager (PM) can identify significant drivers, forecast future cost and schedule performance, and and construct corrective action plans to get the program back on track. EVM therefore encompasses both performance measurement (i.e. what is the program status) and performance management (i.e. what can we do about it). EVM is program management that provides significant benefits to both the Government and the contractor.

1.2 EVM and Management Needs. A fundamental requirements for managing any major acquisition system is insight into the contracts' performance specifically the program management and control. Proper EVM implementation ensures that the PM is provided contractor performance data that:

• relates time-phased budgets to specific contract tasks and/or statements of work (SOW)
• objectively measures work progress
• properly relates cost, schedule, and technical accomplishment
• allows for informed decision making and corrective action
• is valid, timely, and able to be audited
• allows for statistical estimation of future costs
• supplies managers at all levels with status information at the appropriate level, and
• is derived from the same EVM system used by the contractor to manage the contract

That's it, other than the other 96 pages of detail in the document.
    But notice there is no "business value" phrase in this statement. The production of Business Value is a separate issue. An important issue, but completely separate topic. Earned Value Management (EVM) is NOT about business value creation and management. No matter how much the agile thought leaders would like it to be. It is about knowing the performance efficiency of the planned budget (BCWS) in terms of Percent Complete within the planned period of performance to produce the "Earned Value," BCWP.

When it is stated

The ... claim is that EVM enables you to objectively measure the value being produced by project teams. Their inherent assumption is that these project teams are actually earning value for your organization, yet in practice we know that this couldn't possibly be true.

    This is simply wrong. The value of Earned Value is not business value, it is the "earned" dollars (BCWP)(EV) from the "planned" dollars (BCWS)(PV).

    All the proposed enhancements with burn down, burn up, business value are outside the scope of earned value as it is practiced by the earned value professionals.

Simple Training Example

Here's a Gentle Introduction to Earned Value Management, that may help clarify the concept of "earning value," while NOT speaking about the business side - that is the cost of the cokkies. Beacuse of course the cookies are not sold, they are Christmas Cookies.

Earned Value and IT Incompatible?

I was poking around for an EV document I had misplaced and came across a 2008 article by Scott Abler in Doctor Dobb's Journal. Scott is a thought leader in many areas of software development. I used his "process" books for many years when I was managing development organizations. I was troubled though by the misunderstanding of a core concept in Earned Value.

The premise that the "value" in Earned Value, is monetary value to the firm is not the case. The "V" in EV, is the measure of physical percent complete in units of measure of money. The money of the budgeted cost of work scheduled (BCWS). That is how much of the BCWS was converted into tangible items – physical percent complete. Whether the functional specification has are "balanced sheet" value to anyone is a local issue. If may be invaluable to NASA for the design of a manned vehicle. It may be worthless to the CIO who is on the line for making a service work.

The Value in Earned Value is not business value

For the government, it's an indication of how much "physical percent complete" has been accomplished to the "planned percent complete." Our firm manages software development projects in aerospace and defense and large IT (enterprise ERP) were EV provides measures of progress in ways not available in the absence of EV. These developments – even in A&D – make use of many of the principles of agile development, along with CMMI process areas.

In a later paragraph you mention EV effective if you have an effective plan. The opposite is actually true – if your plan is not effective you don't need project performance measures, because your project won't last long. Changes to the Performance Measurement Baseline (PMB, the source of BCWS) occur all the time. The need for a PMB, to show where we have come from and where we are going is the key to success of EV. Without some form of "baselining" the team is simply spending some else's money without accountability – this is a common failure mode for IT projects. In the EV world, this is called Level of Effort (LOE) – or "train watching" – actually "watching the train wreck." In LOE, the consumption of funds = progress.

BRUF, BDUF, big anything up front is not a prerequisite for EV. This is a popular myth of those unfamiliar with applying EV. Just the opposite in fact. Rolling Wave Planning Packages are part of DOD 5000.02. Only the open active work packages are used to perform measurements for management decisions.

If you invert your last paragraph of Scotts article and remove a few NOT's you've got how EV is done in A&D software development and Enterprise ERP.

• Define work packages that produce tangibly measureable outcomes. Be they complete and ready to ship, or measurably valuable intermediate deliverables need to produce the actual deliverables. It's the focus on deliverables and the planned value – earned value- for these. Predefining the Earned Value target, and measuring physical progress – physical percent complete – in a standard unit of measure, is what allows EV to be a stable estimator of progress to plan.
• Define what "physical percent complete" means for each work package. We typically (of IT) use an apportioned milestone method within the work package. Define this upfront, measure to the agreed outcomes (deliverables) and record this progress for forecasting future progress. NEVER CONFUSE EFFORT WITH RESULTS. Only measure tangible deliverables. Typically the tasks within a work package have 0/100 measures. Either you're done or you're not done. No partial credit.
• In the worlds we work, Scrum and EV, along with Integrated Master Plan / Integrated Master Schedule are all cousins. IMP/IMS requires you measure progress by the increasing maturity of the product or service being built. Assessment points (Events), are "assessed" with Significant Accomplishment (what is the evidence that you are at a level of maturity you say you are), and Accomplishment Criteria (what is the exit criteria for the Work Package)?
• The notion that partial maturity and 100% completion are strategies for performance is lost on most people outside of defense. For example:
  • I need a database to be stood up for a customer order tracking system
  • What are the incremental measures of maturity for this database? This could be the "walking skeleton" as someone called incremental parts.
  • But what are the actual units of measure for this incremental piece? Critical tables defined, critical PL/SQL tested, etc.
  • Define all this before starting work so you can do one critically important thing that the majority of IT projects we rescue don't – WHAT DOES DONE LOOK LIKE? And how would we recognize we're moving toward DONE, along the way?

Answering the question – What Does Done Look Like – means defining done in some unit of measure meaningful to both the customer and the project team. Physical Percent Complete of a tangible deliverable is a good place to start. Testable Requirements is the formal approach to this outside the agile world. No matter the approach the legal definition is "evidentiary materials." Show me something that you said you were going to show me, and show that it is "done." Not almost done, not "I'm gonna fix the bugs over the weekend," not "well I worked on my machine." No Done, means you won't have to touch this again unless the requirements change. We can ship it. to the customer or the SCC system.

Now how much did we plan to spend for this "done-ness?" If it is completely done, then you get 100% credit for being 100% physically percent complete. BCWP = BCWS X Physical Percent Complete. The actual cost to do the work is a cost management issue, not a schedule management issue.

If you spend the planned budget but were not 100% done, then several things result.

• You're over budget
• You're behind schedule
• You've had to remove features
• You've got rework to do
• You'll have to rob future Work Packages of their budget and schedule to get this Work Package "done"

These are all correct responses. Making them visible is the role of Earned Value.