The Air Force’s recent decision to scrap the Expeditionary Combat Support System (ECSS) had wide-ranging impact that extends beyond technology. Projects that go awry have a financial impact, and financial impacts often ripple into layoffs and spending cut-backs. While cancelling the project rather than wasting another billion dollars on it may have been the wise thing to do, there was real life impact to the employees on the project.
So how do you incur a $1 billion price tag without getting to a final result? Let’s not get distracted by the dollar amount – for small companies or projects with limited funding, $10,000 can have the same impact as $1,000,000,000. It’s really about managing your budget in accordance with your project, and managing the project in accordance with your budget. In today’s Agile development environments, managers often struggle to define annual budgets when the project documentation and planning is purposely lightweight and iterative. So, let’s talk about strategies for managing a budget in a modern software environment so you don’t face the same difficult decision the Air Force just faced.
It’s a misconception that Agile development efforts conflict with product roadmaps. If you are going to compete in today’s market where building the right thing and building it fast is your key to success, you need to have both. The difference is in the level of detail. Traditional product roadmaps are detailed documents that dive into the specific details around the feature set and lay out a full-blown interface design and architecture for the upcoming year. And worse, a project like ECSS probably had a one-year roadmap that fit into a five-year roadmap, all bloated and weighed down with detailed documentation that made it difficult for the project teams to be nimble and responsive to changing requirements and technologies.
A more effective roadmap in today’s world really acts as a set of guideposts to set direction and key items that must be delivered. They are the high-level statements for which all the user stories can be written, but they are not as granular as a user story. Knowing your Product Roadmap is the first foundation for figuring out how many sprints you will need in order to accomplish the product goals that have been defined.
Know Your Velocity
Velocity simply translates to how much work the project team can deliver within a given sprint. Often the velocity is expressed in points rather than days, which takes away the calendar restraint (in case your team likes to work 16-hour days or over the weekend). Each feature in the sprint is given a point value based on how much work it will actually take – I usually equate one point to six hours. Any manager will tell you that estimating the amount of work a team can do is not an exact science – you can make an assumption initially but you need to adjust that assumption to reality as you get to know your team and what they can deliver. If the team delivers more than expected on a regular basis, you can increase the number of points you include in a sprint, aka “velocity.” Knowing your velocity is essential for estimating how much work you can do in a sprint.
Give Your Sprints a Dollar Value
When you have stabilized the project team members, the length of the sprint, and your velocity, you have the foundation for being able to assign a dollar value to your average sprint. If your team consists of four developers, three QA, and a product manager, you can use the average hourly rate for each of those positions to estimate the cost of a sprint. In general, your company should have hourly rates they use for headcount estimations. Let’s use these rates for the purposes of this example:
- Developer = $100/hr
- QA = $75/hr
- Product Manager = $80/hr
Using an average 40-hour workweek for all of them, your cost per sprint will be approximately $84,600 ($48,000 for the developers, $27,000 for QA, $9,600 for PM). Now you have the basic calculation to determine your project costs. This will also give you real data to use when you have to make product decisions and trade-offs.
Put it All Together
So now you know what you’re going to build, how many sprints it will take you to build it and approximately what each sprint will cost. Based on this, you can project:
- The target completion date for the product roadmap
- The approximate cost to deliver the items on the roadmap
In my experience, making the product owner responsible for both of those items helps control feature creep and ill-conceived change of direction. At the end of each sprint, the product owner can analyze the actual rate of completion and expenditure to the target, which gives a constant gut check on how the project overall is doing with those two goals. You never incur unexpected overruns of more than three weeks or $85,000 without having the opportunity to make a course correction.
Sometimes it’s not that simple…
I know that the Air Force faced far more complex issues than the tips above can easily solve. I also don’t have visibility into all of the strategies they used or tried to use, which may have included the ones mentioned in this blog series. But I do know that the problems the Air Force faced and their ultimate decision to abandon their original plan happens on a smaller scale every day in software companies around the world. Often it’s simply because they have not built the right process or infrastructure to do frequent and expected course corrections during the course of a project. So… sometimes it’s not that simple… but sometimes it is. Happy coding!
- The Air Force’s $1 Billion Software Flop [Part 1]
- Take Small Bites and Chew Well [Air Force Software Blunder Part 2]
- Are Google and Facebook Too Big to Fail?