EVM and TPM are Project Waste

I think Earned Value Management (EVM) and Technical Performance Management (TPM) are project waste.

Investors, stakeholders and end-users want to know if their investment will:

  • be delivered as specified;
  • be delivered when requested;
  • be a contained cost of acquisition;
  • always work; and
  • generate recurring return on investment.

Not enough people ask about the cost of ownership, but since many people don't seem to grasp that low cost of acquisition pursuits often compromise long-term cost of ownership, we'll save that for another conversation. Regardless, what we can all agree upon is if we're an employee or consultant spending someone else's money, we're hired to deliver while being a good financial steward. If we spend our own money, even more so.

So why is the money being wasted in software projects calculating EVM and TPM?

Determining Value

  • Market analysis will tell you if your idea has any consumer value, whether product or feature
  • If market analysis cannot tell you this with useful clarity, then you need to test the market with a minimum viable feature (MVF) or product (MVP)
  • Neither effort is a place for EVM or TPM
  • You simply need working software and an ability to empirically understand (e.g. analytics harnesses) how the consumer does or does not interact with the test letting raw data teach you where to spend money

Specifying an MV(F/P)

  • This is a much larger conversation well covered in other treatises
  • Based upon your tests, decompose the MVP into into MVFs (aka epics) and order them according to MoSCoW or some other talisman of the trade
  • After you have a "Must" list (which is by virtue assigning value), it must be prioritized (yes, they all "must" allegedly happen, but not at the same time; so there must still exist an order to the madness)
  • We need working, tested, demonstrable software not EVM and TPM calculations

Decomposing, Sizing and Prioritizing

  • After the "must" list is prioritized, decompose the epics into deliverable, automated testable statements (stories and acceptance criteria) using role-based stakeholders
  • Size each story (or acceptance criteria therein) using your estimation model of choice
  • Re-prioritize the epics and stories within using your new information validating value and asserting cost associated to points
  • Again, this is no place for EVM or TPM

Delivering

  • In Extreme Programming, predictable, repeatable two-week iterations are preferred to retrieve feedback now, not downstream
  • However, using continuous delivery behaviours, we can know the state of the software multiple times per hour taking away any possibility of value contribution by EVM and TPM math
  • Based upon story points and capacity, each person makes a commitment and delivers on the commitment
  • Iteration planning, daily stand-ups, iteration demo (interact with the end-user, get feedback now, change now), iteration retrospective, repeat
  • Planned versus actual burns occur daily and per iteration, per epic and story, visibly and transparently and tell us about our plans and actuals

Continually Deliver while Proving Completeness and Correctness

  • During development, automate the acceptance test statements within each story which may include role-based attributes of both positive and negative statements (DO, DO NOT)
  • During development, automate the unit testable elements
  • Using continuous delivery, continuously integrate, test, inspect, deploy
  • Integrate your change management, version control and continuous deploy tools for automated traceability, auditability and reportability
  • EVM and TPM serve no valuable purpose here

Deliver to production, continually. Verify continually. Report continually. In other words, the method by which we determined what to deliver and then delivered it then became the method by which production software is maintained and evolved while in production. When we are building software, we are building the framework to manage the project, product, feature, process, teams, money and timeline.

EVM and TPM were originally created to help determine qualitative value in spending. In today's software world, they cannot be used to determine market demand, test consumer response, identify, prioritize, decompose, estimate, reprioritize or then continuously deliver software. Basically, while EVM and TPM talk about determining qualitative value in arrears, the software delivery model referenced above actually delivers it in real-time on far more dimensions than EVM and TPM math can muster.

Why spend money calculating something that doesn't actually contribute to generating revenue? I look forward to hearing an answer.