How to Approximate the Cost of Internal Software Projects
There is no more controversial topic in software planning than estimation. Include the E-word in a LinkedIn post and watch the replies flow in.
Estimates are wrong by definition.
They are Waterfall.
Management needs to get out of the way and just let developers build stuff.
You should read up on #noestimates
It's the loud, defacto opinion of the internet, but it's an overly simplistic worldview.
The truth is we need estimates to build professional software. They are imperfect but crucial tools for planning and budgeting.
And if you think about it, those are two separate categories of estimate.
Estimates for planning ask the question: "How long will it take you to complete that task?"
They are personal and short-term. If it takes me about two days to build a brand-new report, I can plan to do two of those in the coming week. Short-term planning consists of estimating the length of each piece and fitting those pieces into the timebox. Days, Story Points, and T-shirt sizes are all estimates for planning.
The caveat here is that these kinds of estimates rot and should not be used for long-term planning.
Estimates for budgeting are a different beast. The question we're after here is: "How much will this project cost?"
Let's say we have a clunky web interface and want to make it more user-friendly. This can be a valuable upgrade to our system, but only if the price is right. We are after a number to calculate the Return On Investment. We want to know how much it would cost to modernize our front end so we can decide whether to proceed.
At this point, we don't care about the plan. We're not sure if we want this. We just want a ballpark figure of how much it would cost to complete this project.
So, we get our brightest developers together and ask them to estimate how long it would take to redesign the site. Since they are smart, they get very reluctant. They don't know. There is too much uncertainty to slap a number on it.
That's a healthy reaction. It would be crazy for them to blurt out "250 days!" and trust you not to abuse that number.
But we need a number to calculate the ROI, so how do we proceed?
The first idea might be to start bottom-up. Gather requirements, define the scope, create a Work Breakdown Structure, and estimate each work item in days. It's tried and tested but time-consuming. To do this in-depth, you might need weeks of work. At the end of that expensive analysis phase, you end up with a number that's not guaranteed either.
Here's a better, faster, and cheaper way to get a budget estimate:
First, create a high-level description of the work we think we need to do. The goal isn't to be exhaustive. It's to capture an idea of the size and nature of the work. We're on the right track if we hear: "Don't forget to update the mobile app as well" during this whiteboard session. The result is a mindmap of all impacted parts of the system. We're not after a spreadsheet with all the scope.
Next, we'll use this mindmap to define the ideal team needed for this project. We're looking at profiles, not people, at this point. We'll need a designer, two front-end developers, and a mobile dev. We'll need a part-time tester and a project manager too. As a rule of thumb, team members can be full-time or half-time. Don't fall into the trap of guestimating a 0.15 FTE.
That gives us a team structure like this:
Now, let's estimate the time needed to complete this project by answering the question:
"Will it take the team 1, 3 or 6 months to complete?"
If the answer is lower than 1, use 1.
If the answer is more than 6, divide it into multiple projects and estimate them separately.
We know how much the defined team costs monthly and can multiply that by the estimated months.
Et voila: a budget.
Is this exact? No, it's a ballpark figure. That's what we set out to do.
The first and most crucial step is creating a list of impacted parts of the system. Our budget is bust if we discover we also need a Kubernetes expert halfway through the project. I have found, however, that teams are very good at answering the question: "Which parts of the system would be impacted by this change?". Give a team a few hours to design high-level solutions and watch them deliver.
Defining the team means we don't ask anyone to give bottom-up estimates on a highly uncertain scope. We just look at the mindmap and say: "There's a lot of front-end work, so let's add an extra developer there."
And finally, we estimate the duration of the project in Small, Medium, and Large. Instead of summing up the work items, we ask: "Would it take more or less than three months?". This is an answer our developers feel comfortable giving.
It goes without saying that this isn't the way to go if you want to budget a fixed-price project. There are other tools for that.
However, this technique works well to approximate the cost of an internal project.
It's a crude but effective approach.