EVM Deployment vs. Complexity

First a word of caution: I strongly believe in the advantages of EVM. I also notice that the concept fails while it is being deployed. So I am trying to discuss why it is that EVM often proves so weak during its deployment.

Basic EVM principles are simple… but let us not kid ourselves, the implementation is not.

If EVM is not a common place practice, and it isn’t, that is not because it is not clear, or because its potential value is not understood. If it is not a successfully wide spread practice, it is because it is hard to implement.

EVM is most useful in complex projects. Most responsible companies who are interested in EVM have deployed EAC calculations, often automated in systems such as SAP or others. However this is understood to be simply scratching the surface of EVM.

Why is it so hard to go any deeper?

So let us ask a question: What changes are introduced when an EVM practice is deployed?

Well, let’s see:

At project level: imagine a PM deploying EVM, what happens. There is some form of controlling mechanism in place, and there is some sort of progress reporting in place. These, a PM will feel inclined to defend. So the fist challenge is reluctance to change. This is a very important factor and the solution is not that evident.

However: even if the PM is open to change (which is rarely the case) there are several practical obstacles that she will face.

In an ongoing project, the existing overview on the project is put in question. Often the original bud get or baseline has lost relevance due to changes that have occurred since the beginning of the project. More often than not, the project scope is not the same as when the budget had been defined.

So what is to be used as reference for the EV calculation: old outdated data? That would make the whole exercise useless. On the other hand, if the decision is to start from scratch and apply the most useful information to the model, the result is often catastrophic… it actually starts showing us the truth… The new budget requirement which has been calculated in order to have a reference baseline to start with, gets submitted to the Sales manager or the project sponsors and they hit the ceiling! “What, our margin is gone with these new requirements!” And EVM is dead before a single analysis has been performed.

However, in happier projects where the deviation is not so great, or in projects where the management is open to re-discussion of these critical elements, practical issues start taking relevance: when is a PM all owed to adjust the CBL: never, or whenever reasonable? CBL which is adjusted every time an assumption is proven wrong quickly becomes useless as does all the rest of the work done in deploying EVM. Ergo: EVM brings no value and is killed. If a CBL is so fixed that it is never adjusted, it becomes quickly outdated and useless. Ergo: EVM brings no value and is killed. Oh but the budget and the CBL are not the same!!! Sure, that’s the whole point, but where is the border? Contractual change…. Business related change…. Customer sanctioned change…. Purchase order based change….do you/don’t you adjust for currency variations? There are many guidelines and each company ends up inventing its own. But the final result is often that these guidelines, exactly because they are arbitrary, are easy to define, but seldom easy to implement. If a PM is measured via EVA results, he will have the most advantage in interpreting these guidelines in way to readjust the C
BL as often as possible, thus undermining the usefulness of EVM guidance on his own project. If the control is too strict, the CBL is quickly outdated. At least this is the case in complex projects.

However, the real value of EVM is exactly great in complex projects. Chances are that on a simple and small project, I will need no EVM anyway. So we end up in a paradox. EVM would be most valuab
le in complex projects, and this very complexity makes it so challenging to deploy. Maybe there is a solution exactly in the management of complexity, more of that later.

Program: Back to our question. What changes are introduced when EVM is deployed: at program level?

Why does a program exist?

Essentially: to capitalize on a benefit by coordinating multiple projects. So all changes, even a process related one, will be (and should be) viewed in terms of their impact on this benefit. So the enthusiasm to introduce EVM is high up front, when the idea is that finally Program managers will be able to have a clear overview on their projects, finally transparency! Which promise is maintained? In the short run… very few. The common experience is that there is a sudden increase in conflict, Sales teams are frustrated (mainly because they still price based on cost plus margin instead of understanding the real value that project management is bringing them… another interesting subject, that of PM value…for next time).
However, conflict is not the only challenge faced at Program level. Existing communication methods and monitoring methods may become obsolete, even if the program manager is comfortable with the new mechanisms introduced thanks to EVM, the customer may not be.

Customers do not give a vendor additional value simply because the vendor starts using EVM, especially not outside of the US. On the contrary, the answer is often “why are you changing your monitoring mechanism if I did not ask you to?”

If, on the other hand, the reason for existence of a program, is not a common customer but, for example, the deployment of a common technology, EVM may not be offering huge advantages to the program management. Sure, there is a better oversight on the project progress and success, but the focus is the common technology, does EVM offer a better overview on production dead lines or ready for shipment or deployment dates: certainly not. Will the program have a better overview on the value of technological receptiveness, no it will not. Therefore there is the risk that at program level, the advantages of EVM may not be valued.

So how could EVM really help at Program level. Again we are back to complexity. EVM can, if used appropriately, reduce, or at least create a better overview on the status of the program’s level of co
mplexity. Complexity: We noticed how the concept of complexity shows up all the time. It seems quite clear that the more the project is complex; the more EVM is worth the effort of implementing. So let’s have a look at complexity: A complex system’s characteristics have been defined as:

1. Involves a large number of interacting elements.
2. Non-linear interactions. Disproportion between change and its consequences.
3. Dynamic system. Whole is greater than the sum of the parts. Solutions arise from circumstances.
4. Past is integrated with present. Elements evolve. Evolution is not reversible.
5. External conditions and systems change. Therefore hindsight does not lead to foresight.
6. Agents and systems constrain each other. Forecast is not possible.
7. Realm of unknown unknowns.
8. Why things happen is clear only in retrospect.

Complexity may be due to: technology, globalization, intricate markets, cultural change… some of these elements put at least some form of EVM deployment into question straight from the start. For example:

Point 3: therefore, in a program, managing the parts (the single projects) is not sufficient. And more, opportunity arises exactly by being open to the broader view and letting the circumstances play their part. This can be done if also the operational aspects and dealt with and kept in the overall picture. Managing separately the single projects on one side and the operational content on the other is not sufficient.

Point 5: “hindsight does not lead to foresight” seems to eliminate the practical usage of calculating the new EaC simply by applying the CPI to the BaC.

Point 6: Then how can we rely on PV, what value does it maintain?

A few quick points regarding risk management in such a context:

• Risk Planning cannot be event based.
• Root Causes of complexity are the first which need to be identified (example: great cultural differences in the team, technological changes ahead, changes in customer priorities are not controllable or foreseeable).
• Actions can be planned on root causes, but not on single events.
• So we have talked about challenges in deploying EVM at different levels, how complexity is an element and how it makes most sense to deploy EVM when complexity is high, what is complexity and how risk management may change.

So let’s start building some deductions from the observations made:

1. Does this make EVM obsolete? On the contrary: these observations underline how important it is to have real and self-confident EVM in place.
2. The more complex the nature of key projects, the more extensive the EVM implementation must be. Both on Managing by Project: PMO, Program and Portfolio operations, and in managing key complex risks as a subproject.
3. Simple implementation of basic principles will risk being killed in the Hype/depression cycle.
4. EVM results must be monitored on the long run through overall KPIs as a project in it’s own rights.
5. KPIs must be also business related and not only project related.
6. EVM maturity models exist; however they monitor, and to some extent guide, in terms of level reached. A more valuable indication would come from a more holistic analysis (like OPM3?) in which to include a strong presence of EVM related best practices, including best practices related to the management of operational aspects.