Showing posts with label earned value. Show all posts
Showing posts with label earned value. Show all posts

Thursday, July 17, 2014

Agile and Earned Value Management (again)


I've been on this horse before, but it's worthy of another ride. I've just completed a new white paper on Agile and Earned Value Management that you can read/download on slideshare.net/jgoodpas





Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, February 22, 2014

Robert F. Kennedy on value...


.... It measures neither our wit nor our courage; neither our wisdom nor our learning; neither our compassion nor our devotion to our country; it measures everything, in short, except that which makes [... our project] worthwhile. And it tells us everything about [... about a project] except why we are proud that we are [...doing the project]."
Robert F. Kennedy

Senator Kennedy said this -- within the limits of my somewhat tortured paraphrase substitutions to port it to our domain -- in the midst of a political campaign; he was referring to the metrics of the Gross Domestic Product (GDP).

His point was one that is all too common in many domains of human exertion: the mix-up between that which we can objectively measure and that which we know subjectively as quality, value, and purpose achieved.

Now, one can make measurements on some subjective values, to be sure. But on many of the qualities that lend utility and excite interest, who can say why, really?

I've actually given it a go; I've written a whole book on finding/delivering project value. I'm not the first and likely not the last to address this subject.

But I've also written books on the objective means to measure projects.

Now, it's probably no surprise that "Maximizing Project Value" is not the first book a PM picks up; more likely it will be a subject as "Quantitative Methods"  and "Project Management the Agile Way"; but I actually think "Maximizing Project Value" may be the more important subject to know and internalize -- for all the reasons RFK spoke about.






Bookmark this on Delicious
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, September 1, 2013

Dr. Will on earned value

Dr. (George F.) Will mostly writes about politics and baseball -- and mostly about unwarranted constraints on freedom.  He never writes about earned value.

So, I was struck by this passage which made me think immediately of the earned value examiners that used to descend from Washington onto my projects, foretelling gloom and doom

"Studying history serves [governance] by highlighting contingencies: Things [do not] need to turn out the way they did; choices matter. Since Hegel, Marx and other 19th-century philosophers decided that history is History — a proper noun, an autonomous force unfolding an inner logic — humanity has been told that vast, impersonal forces dictate events, nullifying human agency. But they don’t. Choices matter."
Dr. George F. Will

OMG, choices matter! Said another way: History does not dictate the future when human agency (thoughtful action) is applied.

And that brings us to earned value (I'm a supporter, but only to a point), the value of which is a forecast -- which, by the way, is not a certain outcome -- of where we may go based on where we've recently been. For purposes of the forecast, efficiencies, are presumed constant (over the near-term future) and presumed to be the coefficients of the future.

Of course, efficiencies are not constant -- we just want them to be. That's the paradox of earned value. Efficiencies are influenced by the quality of requirements, the effectiveness of environment, and the competence and willingness and commitment of staff,

Consequently, the outside analysts come with their forecasts of a project in trouble (which may be true) but no solutions (except change the efficiencies). And, of course, that is exactly where human agency comes in: DO SOMETHING (FDR's words) to affect a change.

In other words, an earned value moment of analysis becomes an inflection point. The efficiencies going into the analysis are not the efficiencies coming out-- by choice and by action.

But, earned value has served its purpose: to warn of a need for change, not to forecast the eventual outcome.



Check out these books I've written in the library at Square Peg Consulting

Saturday, August 24, 2013

Earned value and technical performance


Paul Solomon, among many others, has been on a worthy campaign to closely integrate earned value accounting and technical performance -- to wit: no performance, no credit!

Some of this thinking is put down in a paper he wrote for Crosstalk -- The Journal of Defense Software Engineering, entitled: "Basing Earned Value on Technical Performance"

The essence of his idea he states this way:
1.Tie the technical baseline to the EV Performance
Measurement Baseline (PMB).
2.Tie technical progress to the Technical Performance
Measures (TPM) of the program, including progress
towards achieving planned functionality
This stuff is not without consequence. Solomon asserts:
If good TPMs are not used, programs could report 100% of earned value (or credit for work performed), even though they are behind schedule in terms of validating require ments, completing the preliminary design, meeting weight targets, or delivering software releases that meet the requirements
Solomon goes to say that he sees four opportunities (his words):
  1. Base EV on technical performance
  2. Account for deferred functionality
  3. Track tasks discreetly
  4. Plan rework and track discreetly
I've probably given away the store with this much reporting, so I'll leave it you to finish the paper, a worthy investment of your time.


Paul J. Solomon, PMP, is co-author of the
book, Performance-Based Earned Value.®
He supported the B-2, Global Hawk, and
F-35 programs at Northrop Grumman


Check out these books I've written in the library at Square Peg Consulting


Sunday, January 20, 2013

Earned value references


Are you looking for a handy reference of Earned Value articles?

I wasn't, but I fell onto this website by accident: Earned Value Bibliograpy. It's maintained by  David S. Christensen, Ph.D, CCEA, CMA who teaches in the business school at Southern Utah University.

In this bibliography you will find (at today's count) 514 articles/references, many with clickable links.
514 is a big enough number to keep anyone going....

Although I didn't know it til I looked, even one of my EV papers is among those listed.  How nice!

Monday, July 23, 2012

EVM and disjunction

The situation is disjunctive when everything must go right; nothing must fail. To say it another way: either failure or success is possible, but not at the same time. And disjunctive congnition occurs when one thing is given two distinctly different appearances or interpretations (we call it a 'success' but it's really a failure).

So much for the dictionary. Why should project managers care?

Well, for one thing, there's a cognitive bias to be concerned with that can affect many project situations:
Disjunctive bias: There is a bias towards the understating the likelihood of at least one failure and thereby overstating the likelihood of complete success

What's the usual countermeasure, the usual risk response? Make every single constituent very reliable so that nothing is allowed to fail.

Feel comfortable? Well, the problem here is that the math is against you.

The probability of at least one failure among a number of independent components (call them work packages, for convenience) is a binominal problem in probabilities, given by this messiness (click to see).

So, for example, consider this table of trouble, where
N = number of components
K = number of successes
N-K = number of failures

 N  K  N-K Prob of success  Prob failure Prob at least N-K failures
6 5 1 90% 10% 35%
4 3 1 90% 10% 29%
2 1 1 90% 10% 18%
6 5 1 99% 1% 6%
4 3 1 99% 1% 4%
2 1 1 99% 1% 2%
60 59 1 90% 10% 1%
60 59 1 99% 1% 33%
60 57 3 99% 1% 2%

The last couple of rows appear counter-intuitive. But, remember this is about a least 1 failure (or 3).
  • Third from the bottom tells us the likelihood of only one failure is not good
  • Second from the bottom tells us the likelihood of only one failure is good
  • The bottom row tells us that 3 failures is pretty improbable.

But still, with the high reliability, it's remarkably probable to get at least one failure in 60 objects, even though not three!

So, what if these objects are work packages, and the success/failure is 0/100% evaluation of the earned value?

What the table tells us is that even with hugely reliable work package managers, the likelihood of at least one failing is much higher than the individual failure rate, but the likelihood of more than one such failure is quite low. To wit: at least one failure: 33%; but three failures: only 2%

Thus, the cognitive disjunctive bias: who would have predicted 1 chance in 3 of getting a WP failure (on a WBS of 60 objects) when there is only 1 chance in 100 that a WP will fail?

If you want more about how this is calculated, visit the Khan Academy.org




Friday, April 20, 2012

Agile sailors

I recently gave a presentation to a PMI chapter on Agile project management using a sailing race analogy. I've used this analogy before, but this time there was some Q&A that was worth passing along.

 
The first thing is that audience was shocked (shocked!) to learn that agile projects have plans, and even more shocking that earned value concepts (that is: earning some value for the investment made) is also alive and well.

 
The second thing is that those from large companies lamented (I won't say complained because they didn't) that executive managers had little idea about the change in management paradigm that is the most pervasive aspect of agile. It's not the technical practices: those are largely like those in other software methodologies. But it's the change in management practices and thought that is different.

 
What's different?
  • What's different is that best value is preferred over a fixed scope specification;
  • what's different is that matrix management at the team level, sprint to sprint, must be put aside;
  • what's different is that the team, in collaboration with someone holding the customer/users proxy has to be trusted to apply the available investment is the best possible way; and
  • what's different is that the project manager manages to milestones that have user/customer/stakeholder value and not to the details of a networked CPM schedule.

 
Take a look and see if you don't agree

 

Thursday, November 24, 2011

The project sentence

Richard Feynman is a renown theoretical physicist (deceased 1988).

He once said that if he had to summarize modern science in one sentence he would choose: "The world is made of atoms".

Brian Greene, also a theoretical physicist, has written of Feynman's choice: "When we recognize that so much of our understanding of the universe relies on the properties and interactions of atoms......we can well appreciate Feynman's choice for encapsulating our scientific legacy."

And, there are other sentences. Many have said: "The business of business is business", meaning customers are swell, but shareholder value is better!

So, what about a project sentence? It would be great it would unify the three great values of project management:
  1. Customer value (value as experienced by the customer)
  2. Business value (value returned to the business as a consequence of project activity), and
  3. Earned value (a measure of the effective utilization of the business resources committed to the project)
And, it would be neutral on plan driven vs outcome driven (agile)

So, how about this?

The business of projects is to effectively invest business assets to return to stakeholders value from the affirmative vote of customers

Brian Greene: "The Fabric of the Cosmos"
Photo

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Monday, October 3, 2011

Sins of progress

Paul Solomon, an industry guru in earned value, has an article in a recent edition of the "Journal of Software Technology" (August, 2011, vol 14, number 3) that lists a number of sins that distort progress. I'm sure of none of you reading have done these things, but I repeat Paul's list so you can be aware.

Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)
Rework--in other words, error of feature, function, or performance requiring correction--is not included in the budget (though it's reasonable to expect some rework as part of the natural variation in the design and development processes). Rework is identified as a risk (on the risk register) and money to fund the risk response is included in management reserve (MR). Later, funding is transferred from the reserve to the budget when the design or test item does not meet, or no longer meets, technical requirements.

Cost drivers such as software lines of code (LOC), number of drawings, hours per drawing or per LOC, are understated (justified as aggressive interpretation of bottom up estimates) compared with empirical data and realistic estimates.  The low ball estimate is called “management challenge” and identified as a risk, not an issue. Later, funding from the management reserve is transferred to the budget to cover the risk.

The same conditions exist, as above, but no “risk” was identified. Instead, the additional iterations are called “scope growth” even though the basic tasks were planned in the budget
The number of tests (and resultant rework and problem reports) is understated based on realistic estimates and empirical data. Later, the tests and rework needed to meet technical requirements are funded from MR as “additional scope” even though the customer requirements are stable.

Work that could not be completed internally is transferred to a supplier. MR is used under the pretext that it is “additional scope” or “unplanned.”

So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.

Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"

Good grief! Is there no one on top of this?

Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, August 28, 2011

EVM standards compared

I came across a white paper the other day that compares the ANSI 748 EVM standard to its Australian counterpart, and also provides some comparisons to the PMI practice standard.  Conveniently titled "COMPARISON OF EARNED VALUE STANDARDS", and written by Paul Harris, it sums things up nicely for the non-expert in 11 pages, most of which is quite readable table of comparison.

I wasn't familiar with the Australian standard, AS4817, but I learned this:

This is a standard is a practical guide explaining:
1. The basic processes of an Earned Value Performance Measurement including the calculations.

2. The steps required to run an EVPM system and includes requirements, guidance, examples, graphs and tables.

3. Analysis and reporting techniques. It includes a number of charts and their interpretation.

This standard may be used by people who have project experience to assist in setting set up and running an EVPM system and to provide reports using the formulae and examples which assist in explaining the processes.


And, here's an interesting quote from a bookseller pushing a new PMI book on EVM, but you see it quoted elsewhere:

EVM is management with the lights on!
Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Thursday, June 2, 2011

Another business value v earned value misstep

PMI's Aerospace and Defense Community of Practice (CoP) hosted a webinar in May entitled: "Considerations for Using Agile in a Government Contract Environment", meaning for the most part a U.S. government contract, as different from state and local contracts and non U.S. contracts. If you're a PMI member, you can join the 'A&D' CoP and then click on past webinars for a recorded version.

Now, about BV vs EV: In fairness, the webinar presenter, Peter Brosella, said he knew little about earned value. He then proved his point by putting up a slide with a chart of earned value vs time and labeled it 'business value'. His description of the slide was more about business value than earned value, but he discussed both ideas without really distinguishing between them. And, none of the 100+ PMPs watching in real time took the issue on. (I tuned into the recorded version last week) What does that say?

It says there continues to be rampant confusion in the Agile community over the 'value thing'. It's really not that hard. Business value and earned value don't measure the same thing, and they don't measure in the same time-frame, but they use similar words. One more time:

  • Business value is about earning a return over time from the investment made in the project, to include the continuing post project investment to maintain and support the deliverables.  

    Business value improves the balance sheet.  Why?  Because customers add to assets by buying the product--if it's a product for sale--or employees place fewer demands (liabilities) on the business because operating efficiency is better if the deliverable improves internal operations.

  • Earned value is about getting your money's worth by transforming an investment into a deliverable that has the potential for business value attainment.  "Transforming an investment.." is what is otherwise known as the project process.  EV is the value placed by the sponsor/investor on the deliverable that has intrinsic but unproven business value. 

    Consider the timeline: At the moment a deliverable is made operational, whether at the end of a sprint or iteration or other project milestone, it's accumulated an 'earned value' but has earned nothing in business value.  So, at the moment of delivery to production: EV = some proportion of budgeted value, and: Business Value = zero.

    By some accounting measures, EV should have no effect on the balance sheet.  Money assets are transformed--by the project process--into other asset classes of equal value, thereby not affecting the balance sheet at all.  Only if the actual cost, AC, is greater than EV would the balance sheet be affected.


There have been so many posts and counter-posts (see the thread on Glen Alleman's Herding Cats) on this 'value thing' of recent that sometimes it seems like agilists are like teenagers who've just discovered sex and are sure they've done something unique that generations before somehow missed.  And, like teens, it takes years and a lot of experience before it realized that the world did not begin in 2001 in Snowbird.



Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Thursday, May 5, 2011

The marriage of Monte Carlo and Earned Value

In my risk management classes, I position EVM as a risk management tool because of its usefulness as a forecast tool. There're no facts about the future according to Dave Hulett, only estimates. And estimates are where the risks are.

I also instruct Monte Carlo simulations [MCS] as a forecast tool.

I get this question from students a lot: 'How do I integrate the forecast results from these two tools?', or 'How do I use both of these tools in my project; do I have to chose between them?'

It's a reasonable question: EVM is a system of linear deterministic equations; Monte Carlo is a simulation of a stochastic process described by random variables in functional relationships. How should analysts span the deterministic and the stochastic, and the process model and the linear equation model?

The answer lies in the fact that both systems, EVM and MCS, can be used to predict the EAC--estimate at complete. And, EVM practices do allow for re-estimation of remaining work as an alternate approach to the linear equation forecast. Running a simulation is one way to do the re-estimation.

Reconciliation of the calculated EAC from the EVM and the simulation EAC from the MCS means reverse engineering the required efficiencies for utilization of cost and schedule going forward.

The equation at work is this one:
EAC = AC + [BAC - EV] / CPI

The facts are AC (actual cost), BAC (budget at completion), and cumulative EV. The cumulative CPI is a historical fact, but it's only an estimate of future performance. That's where the MCS comes in. MCS results may shape our idea about this estimate when compared to the EVM linear equation calculations.

Of course the MCS results are not a single point number that fits conveniently into a linear equation; the results are a distribution of possibilities. How to deal with this?

There are two approaches:
First, the expected value of the MCS distribution could be used as a good estimate of the EAC. Expected value is deterministic, so it can be used in a linear equation with other deterministic values

Second, the MCS usually provides a cumulative probability curve, the so-called "S Curve", from which a single point number can be picked according to a project policy or doctrine about how to pick.

Here's how the second approach might look. The project policy about risk aversion--that translates into picking a point on the confidence curve--is usually documented in the risk management plan.  Using the policy guidance, an EAC is picked from the MCS confidence, and then compared to the EAC calculated by EVM equations.



Once the MCS value is determined, the equation above is reworked to solve for the future CPI. Now you have two CPI's: one from the EVM estimate, and one from the MCS re-engineering. What to do now?

The conservative thing is to pick the worst case. The management thing is to determine what needs to be done or changed to bring the CPI into an acceptable range, and then do it.



Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Saturday, January 15, 2011

A sailor's look at Agile, Part II

In Part I of the sailing analogy for Agile, I left it to this posting to explain estimating the cost and schedule, and by extension the earnable value.

The lay line value plan
As discussed in Part I, the lay line is the plan for delivering requirements. To be clear, a lay line is actually a course between navigation points [project periods, or multiples thereof]. To get from start to the finish, the plan may call for several lines in sequence that dodge about hazards and obstructions [project risks], and thread the way through navigable water [analogous to policies and workflow applied to the project]

From a benchmark of performance of the boat-crew-sails combination to sail a lay line [make throughput],  the captain quickly size up how many units of performance are needed to sail the lay line under ideal conditions.  Of course, the benchmark is established before the project begins.

For example, if the benchmark is 8 nautical miles in 1 hour--that is, the boat is ideally capable of 8 knots--then 8 NM is a performance unit.  [8 NM sailed is the throughput of the performance unit, aka sprint or iteration] Continuing the example, a 40 NM lay line [a NM is analogous to a story point] would ideally be planned for 5 performance units of 8 NM per unit.

And, of course, we know the $-cost of the boat and crew to execute a performance unit, so a little arithmetic will give us the planned value in cost terms; similarly, we can  schedule the lay line.  In this example, the ideal schedule would be 5 hours corresponding to 1 hour per 5 performance units.

Variance to plan
From Part I, we know it's unlikely that the captain can pilot the boat along the lay line from start to finish mark, simply because the wind [representing project energy and risks, biases, and attitudes] is unlikely to be in a favorable alignment for the whole of the sailing experience.  Some resistance to progress or inefficiency is to be expected.  Thus, we need a 3-point estimate for the sailing plan.

3-point estimate
Stuff happens!

In the sailing game, it's the wind and the effects of the wind more often than not. The wind is not only the motive energy for the boat [project], but it's the source of most of the risks and uncertainties. These various energy components interact in unpredictable ways, but their effects are estimable in many respects.

1. The most optimistic outlook is when a favorable wind enables the boat to perform each increment of the plan ideally. The efficiency of the boat's use of the wind's energy is 100%.

[For most modern boats, the wind will be coming from forward of the beam. And we'll assume the boat is sailed exclusively in displacement mode, thereby obviating the complications of extending the analogy to sailing on a plain.] 
In this example, the MOO is 5 performance units, as explained above.

2. The most pessimistic outlook is when the wind is in direct opposition to the boat [headed, in sailing terms], maximizing the effects of risk and minimizing the amount of energy the boat can draw from the wind to make value along the lay line, as shown in the illustration.  In such a situation, the captain will tack the boat back and forth across the wind as described in Part I.

Looking at the illustration, the lay line represents accumulating value, not accumulating time.  The length of the performance unit arrow represents the effort of one unit of performance, in this case: sailing 8 NM. The  projection of the arrow to the lay line is the value earned for the effort expended; the fact that the projections are shorter than the arrows means that not all requirements were earned.

For a number of reasons specific to the sailing analogy in this example, the most pessimistic outlook is with the wind heading the boat on the lay line.  This is the case illustrated. A reasonable estimate is that two increments of actual performance will yield only 1.4 increments of achievement along the planned lay line.

Thus, the efficiency of the project's use of the motive energy of the wind is:  output / input = 1.4/2 = 0.7 or 70%. 

The actual forecast is then calculated as:

Input = Output / efficiency
Input = 1.43 x Output
For this example, the MPO is 1.43 x 5 = 7.1 performance units.

Of course, the wind could slacken, or even go calm, and so the long range forecast may call for more pessimism.  However, those are circumstances that are to be addressed in the near-future time frame of the project, and thus belong on the risk register.

3. The most likely outlook is estimable once the wind direction is known; it will be bounded by the most optimistic and the most pessimistic outlook.

From the three points, Monte Carlo estimates can be made, assuming it's reasonable to apply the estimates to each performance unit [sprint, iteration]

Scale
Obviously, we have to account for sailing in a fleet, where the project manager is in overall command of the fleet, but each boat is now a team within the project.

How to maintain order and coherence?

Obviously, there are 'rules of the road' known to all that are applied by boat captains at the moment, thereby avoiding conflicts and collisions. But each captain has lattitude to maneuver for best advantage to the mark.

Boat-boat communications certainly feed 'over the horizon' information [rolling wave] from the lead boat back to the fleet. Thus, each boat is a node in a situational awareness network that circulates information more or less according to customary protocols.

From time to time, the fleet may have to 'lay up' and all captains [team leaders] assemble on the flag ship [project office] for a staff meeting and exchange of information not possible when in the team setting.

Feedback and evolution
During the course of the sail, the captain is constantly taking in data, processing it into useful information to manage the boat and its crew. No plan survives first contact with reality, so some evolution and improvisation are normal.  Additional performance units may be required.  Some performance units may have to be replanned.  Thus, in the planning of the lay line, including a buffer to absorb unplanned increments is prudent. 

It may even be necessary to get back to the admiral and rebaseline if things go really awry. 

Satisfying the sponsor
In the end, how much value is earned?   The planned value of the lay line is the earnable value.  Making the mark satisfies the sponsor and delivers the expected scope. The actual expenditure will be dependent on the wind and other events or circumstances that may arise.




Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, November 21, 2010

Earned value reform

Earned value management [EVM] reform is in the air--actually, it's been in the air for some time with effort in Congress to correct some of the problems, as reported by Glen Alleman and Paul Solomon.

In the Nov/Dec 10 online edition of the magazine Defense AT&L, Paul Solomon reports on initiatives to close three big gaps in the ANSI-EIA 748 standard on earned value in an article entitled "Earned Value Management Acquisition Reform"

[Note to reader: Paul Solomon is one of the co-authors of ANSI-EIA 748 and maintains a website on performance based earned value at pb-ev.com]

By Solomon's reckoning, the gaps to be closed are these:

Quality gap: There is no explicit provision to measure quality achievement--or short comings--in the formulation of a claim for earned value by a cost account or work package manager.

Technical performance gap: Although all technical projects have some kind of a technical performance objective and most have some sort of time-phased technical performance achievement plan, again the EVM system is not required to take achievement objectives into account explicitly. 

Solomon believes that the fact that '748 is work oriented [work: the schedule] and not also product oriented [product: the WBS] leaves both quality and TPM--these more generally associated with product than work--in the shadows.

Risk management gap: Solomon says this: "The 32 guidelines in ANSI/EIA-748 fail to address the integration of risk management with EVM".  Among others, the standard provides no guidance for risk-adjusting EVM's linear equations used to calculate forecasts.

Other EVM problems

Here's the other problems, according to information quoted by Solomon: "DoD has reported that EVM, based on the earned value management standard, no longer serves its purpose", and about that standard, Solomon says: "EVM is still recognized as an international, commercial best practice, but ANSI/EIA-748 has been largely ignored by commercial companies. When there is no government mandate to use EVM, the Project Management Institute (PMI) Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a widely used standard for project management."

PMBOK® Guide?

Well, the PMBOK® Guide may be the go-to for non-Defense projects that employ EVM, but it's been my experience of two decades using EVM in DoD programs and then more than a decade in commerical IT that few non-Defense projects use any version of EVM, especially backoffice IT projects.  And it's not because there's no government mandate. But if they want EVM, and if they went to the PMBOK® Guide, they'll find it's a subset of '748 that simply leaves out some of the process and reporting that weighs down '748. 

PMBOK® Guide has gaps

Solomon asserts that the PMBOK® Guide has started down the road to integrate risk, TPM, and quality with EVM.

I don't agree.

In spite of what Paul says in the article and on his website, neither the PMBOK® Guide or the companion PMI Practice Standard for Earned Value Management directly address the three gaps.  The fact that TPM, Risk Management, and Quality are all addressed under the same cover, and TPM appears as a practice in Quality Management and Risk Management does not integrate these practices with EVM. 

Indeed, in Chapter 7 on cost management where the PMBOK® Guide discusses EVM--an improvement over its earlier positioning as a communications tool buried in Chapter 10--the PMBOK® Guide says the measure of earned value is based on work completed.  There is not a hint that product quality and performance should be considered.  To be sure, in Chapter 8, work performance and quality are tied together, but it's a reach to then tie that connection to Chapter 7.

And, although there are dotted planning lines from 'cost' to 'quality' knowledge areas, there are no such to risk management. 

In short, the PMBOK® Guide is not currently the answer to the three big gaps.

Managers should step up:

When I do DoD programs, I set up a performance review board to evaluate and approve claims of EV from the WP and CA managers.  It's the job of the board to hold the EV claimants accountable for TPM, quality, and risk.  Done right, the standard can work.


Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, September 12, 2010

Performance measurement

Quote:
Performance measurement is an essential part of management control in that it validates whether the results anticipated from planned action are realized.

Because what gets measured gets attention, the kind of performance an organization chooses to measure will motivate actions that improve the measures
Kiran Verma, "Total Factor Productivity Management" (1992)

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Tuesday, August 3, 2010

Sausage making

It seems like the popular media and the spread of real-time networking has exposed sausage making [i.e. "the process"] to many new initiates that had no idea "that's how it's done". To many, the details of "getting there" are disconcerting, even disgusting. Unfortunately, many get caught up by the drama of the process and overlook the value of the results.

Projects are not immune: many stakeholders are exposed to project processes like never before. Dashboards, elaborate workflow engines, tweets from embedded associates, and all other manner of project detail is now 'out there'.

The key to success in the more transparent environment is the same key as before: focus on results and accomplishments. Be sure that value is only earned--and credit given--for results, not for process and effort.

In the end, the process will be forgotten; even heroic efforst will be forgotten, but results--delivered to users, customers, and stakeholders--will be a permanent memorial to the success of the project.

Photo: wickenden/flickr

Delicious
Bookmark this on Delicious

Share this article with your network by clicking on the link.

Wednesday, July 21, 2010

Time centric Earned Value

Some years ago, actually 13 years ago, Jim Sumara and myself gave a talk at the 1997 PMI Symposium in Chicago. The topic was "time-centric earned value", a practice we introduced at a commercial backoffice IT shop when we found the conditions for conventional earned value did not exist.

Jim and I both came from DoD backgrounds and had managed programs with EVM for years. But, of course, IT shops rarely embarace DoD practices. In particular, the portfolio of IT projects we were managing had a lot of participation from the functional side of the business for which there was no time accounting. People were simply assigned to projects 'for the duration'. And, the chart of accounts did not support project portfolios.

So, working with what he had, we came up with "time centric earned value". A relatively simple idea of assigning value to task starts and finishes, and then measuring the value earning of those events. The focus is on accomplishment, not effort.  The idea is to give credit only for a meaningful contribution to completing the project.  As given in the presentation, the key to success is defining the value--that is, establishing the criteria--that is the basis for sustaining a claim of accomplishment by the team.

The presentation is posted on slideshare.net.

Of course, there are other approaches to earned value that are unconventional by the ANSI definition.  Among others are 'throughput accounting' and 'work unit accounting'.  Some agile practices include a form of work unit accounting in their 'earn-burn' practice.

Delicious

Bookmark this on Delicious


Share this article with your network by clicking on the link.

Saturday, July 17, 2010

Throughput accounting

Throughput accounting is a form of earned value measurement and it is closely aligned with the Theory of Constraints [TOC]. Throughput accounting can be summarized this way
Throughput accounting measures the value added to the business, process, or entity by virtue of project accomplishments

Value added is only measurable as an accomplishment, presumably an operational difference in the business, process, or entity that makes a meaningful difference.  In effect, what is being measured is how much more valuable is the entity now than before. If expenses are lower, than the business is a more valuable transformer of revenue into profit. If a public sector mission is more effectively accomplished, then the entity is a more valuable contributor to public "welfare".

Value added is a "difference calculation"; in EVM terms, it's a variance. The absolute values of each factor in the difference are less important that the difference itself.

So, what's not accounted for in this variance calculation? Answer: operating expenses [OE] of the project...expenses traditionally called 'actual cost' [AC]. Why exclude AC? The idea is that PMO's and project shops, particularly IT shops, have more or less fixed operating costs. If not this project, then some other will absorb resources. Also, most IT projects involve contributions from non-IT sales and operations staff that are 'fixed costs'. Unless there is some direct incremental expense, like a special tool or facility, or a direct contract for services...like a consultant...then the day-to-day OE of the project is not included in the value difference. If there are such direct and incremental expenses, then they are included as part of the value variance.

The figure below gives a pictorial of this idea. "A", "B", and "C" refer to different projects


What's the tie-in with the TOC? TOC is about managing limitations to throughput, where throughput is defined as something a customer or stakeholder would find valuable. Insofar as a constraint can be minimized or mitigated, throughput increases. Thus, the need for throughput accounting.

Some AGILE practitioners have adoped this idea also. In fact, there is a pretty good book on the subject: David J. Anderson's 2004 text "Agile Management for software engineering -- apply the theory of constraints for business results"

Delicious
 Bookmark this on Delicious


Are you on LinkedIn? Share this article with your network by clicking on the link.

Sunday, April 4, 2010

Ever notice EVM is linear equations?

The earned value management system, aka EVMS, is built out of linear equations! OMG! When did this happen? One answer is more than 50 years ago, but another answer is that it happened during the same age that other models came into vogue that purport to represent reality with linear relationships.

Don't get me wrong--I am in the corner with every advocate of earned value...how else can you measure progress toward outcomes? Certainly not by measuring the consumption of input. Consumption only tells you that something is absorbing input as planned; it gives not a clue whether input is being properly transformed into value producing outcomes for the project beneficiaries. Only some form of EVMS will do that.

My rub is that project managers too often fall in the trap of believing the forecasts beget by linear equations.  They seem unaware that linearity represents only the rational part of our actions; and whereas rationality is what we all say we want because rational also implies predictablilty, in point of fact [or, at least as supported by field observation and analysis by neuroscience] humans are incapable of true rationality.  We require, or better to say our brain processes require, a dose of emotion [read: dopamine] to cause our rational brain to stop cycling through alternatives.

But, that is not to say the calculated EVMS trend lines are incorrect: to do the same and expect different is a fool's game.  Thus, this discussion arrives at the most important mission vis a vis EVMS:

"The mission of project management is to defeat an unfavorable forecast [more often than not wrought by the testy linearity of equations] and produce outcomes of reasonable value that do not exceed the expected investment."

Those with IMS/IMP experience will find these words a bit too informal, but nevertheless, they pretty well represent the bottom line.

By the way, take a look at my blog item "Beware the people model" at to get another idea about linear models and human behavior.




Are you on LinkedIn? Share this article with your network by clicking on the link.

Wednesday, February 3, 2010

That Financial Alphabet-DCF,EVA,NPV,IRR-for Program Managers

Good grief: talk about acronyms!  It's enough to keep up with the earned value system--PV, AC, EV, SPI, CPI, ETC, EAC--and now add in the accounting world.

In a whitepaper I wrote some time ago, I shed a little light on accounting for project managers.

It's entitled That Financial Alphabet�DCF, EVA, NPV: are they affecting your project?

For many in the crowd, this is pretty sleepy stuff, but wake up long enough to take notice that many projects never see the light of day because of unfavorable discounted cash flow--what's that?--and other projects get cancelled mid-stream, and still others disappoint their sponsors in ways that can rub on program managers.

So, it may be worth your while to take a few notes and be able to discuss your project with your accountant.

After all:
Cash is fact; profit is an opinion.

Is your project likely to make a profit for your enterprise, and are you being a good steward of cash?  You might be surprised--Check it out!