With agile projects not only mobile apps or application software are developed—agile projects are more and more used in larger and complex development projects and programs in the industry where software is embedded in large technical systems. This article gives you an overview of how Earned Value Management (EVM) can be applied to complex projects with agile developed software components and shows you that EVM and Agile are not mutually exclusive and even complement each other well. Read on an learn more.
The Combination of Agile and EVM in Large and Complex Projects
To deliver software intensive systems more quickly and affordably is constantly growing—not only in the private industry but also in the defense industry. This led to an increased focus on capability-based planning and iterative product development with the goal to deliver the highest priority system features to the stakeholders as quickly as possible.
Agile has emerged as the leading industry software development methodology and has also seen growing adoption across the Department of Defence (DoD) and other federal agencies. Agile implements the needed method by focusing on small, frequent capability releases. It delivers working software while responding rapidly to changes in operations, technology, and budgets, and actively involving users throughout the development to ensure high operational value.
Why EVM for Agile Software Projects?
Many prominent representatives of agile software development believe that EVM has no place in software projects. Useless key figures that generate no value for the customer and only bureaucratic effort that Agile actually wants to avoid! Agile proponents assume these prerequisites:
“In Agile, we start from the assumption that we cannot predict the future. While we know generally how much time scope and budget we have, we know that it is waste to spend large amounts of time and resources building predictive plans. We always flex on scope, and we inspect and adapt to the learning of the team, customer, and business environment.”
“We find out what the user needs while we develop the software.” That is a nice concept, but what do you say to your customer when they ask in a serious voice?
- How much will it cost?
- When will the project be completed?
- What features will I get until when?
- How confident are you with your answers?
Whether agile project or waterfall project, the customer does not have unlimited budget, time and patience. Therefore, you need an instrument with which you can give reliable answers.
Earned Value Management is already a critical success factor in many IT areas, e.g. ERP or system integration projects. By this I mean that you will have problems if you as a contractor cannot give a forecast with 80% certainty for projects over 1 million dollars. SOX or CobiT 4.0 also define “Program Performance Measurements” as necessary for IT areas.
Agile Projects for the U.S. Government
IT projects of the American government often take several years and consume billions of dollars. In December 2010, the Office Management and Budget (OMB) published a 25-point plan to reform the government’s information technology management.
Regarding IT programs, the following point is relevant: Government IT programs must be structured to deliver functionality in release cycles not longer than 12 months, ideally less than 6 months. The first usable functionality should be delivered no later than 18 months after program start. This means delivering results faster and reducing costs and technology risks.
Agile EVM Delivers the Required Transparency
You often hear that it is too difficult and complex to apply EVM methods in agile projects or large and complex IT programs, and that EVM cannot deal so easily with changing requirements in agile projects. Many agile projects that have implemented a simple, customized EVM have already confirmed that this is not the case.
The central question in project monitoring is: “How do we measure our project progress in relation to the plan and what have we spent on the work done?” When monitoring agile projects, the burn down or burn up chart plays a central role. However, these only monitor created features and/or user stories, i.e. technical progress. Agile metrics do not provide information about “Estimate at Completion” of a release or cost metrics that support the business when it comes to making decisions, such as when requirements in a release change. EVM, on the other hand, monitors costs, schedule, and technical performance in larger projects—normally not on the agile level but on Epic/capability (Control Account) level.
Agile EVM requires only a few input parameters:
- A release plan with the number of sprints
- An estimated product backlog
- The actual costs of work perfomed
- The estimated development velocity
For all estimates at sprint level we use user story points as a measure of story size and velocity.
“How do we measure our project progress in relation to the plan and what have we spent on the work done?”
How to Implement Earned Value Management and Agile in Large Projects
Aligning Agile and EVM on Project Planning and Reporting Levels
In this section I show you in a short overview the principle how to implement Earned Value Management and Agile in large projects. The following figure shows you this in the overall context.
As you can see in the figure, a large project or program is planned as usual. On the top level with the Integrated Master Plan (IMP), milestones and releases. On the next lower level you create the Performance Measurement Baseline (PMB) . This is the level of the Integrated Master Schedule (IMS), where Earned Value Management plays a crucial role. Here you plan Control Accounts, Planning Packages and Work Packages as usual. At this level you include agile elements in the planning process for the first time. Control Accounts normalay correspond to Epics/Capabilities and Features correspond to Work Packages and Planning Packages.
At the lowest level, agile development takes place with Scrum, for example, as described in the Scrum Guide.
Aligning Agile Progress Metrics with Earned Value Reporting Levels
In the next figure, the completion of Agile Stories, with attributed Story Points proportional to the effort, determines the completion status (Percent Complete (PC)) for a Feature, which is the lowest EVM reporting level. The Story Points assigned therefore create a weighted Story Value for product completion status calculations. Now the Feature PC is used in roll-up reporting to the higher level item. One or more features are contained in a Work Package; therefore, the Epics/Capabilities, comprising Features, would logically align to CAs.
This was only a short introduction on how to implement Earned Value Management and Agile in large projects and programs. Get This 22 page White Paper: How to Implement Earned Value Management and Agile in Large Projects which goes much deeper into detail of this topic.
Here You Can Find Even More Knowledge
Would you like to learn more about how to make your projects more successful with Project Control and Earned Value Management? My book “Earned Value Management – Fast Start Guide” takes you an important step further!
Do you know somebody who might be interested in this article? Then simply forward it or share it. Thank you!
