Using Constraint-Driven Estimation in the Early Stages of Writing a Business Case
Software project estimation predicts the duration, cost, and resource requirements for a software project, product, or feature. It is often an integral part of forming a solid business case when seeking funding. Constraint-Driven Estimation is a lightweight, rapid approach that can help you get a ballpark idea of time and costs that is good enough to feed into your business case. We’re yet to come across an organisation with no constraints, we’ll tell you more about how to explore the constraints.
What is software project estimation and why does it matter?
Estimating can be tough, especially in the early stages.
Software project estimation predicts the duration, cost, and resource requirements for a software project, product, or feature. It’s important because it can help you understand how much time and money to invest in bringing the product or feature to market. It is often an integral part of forming a solid business case when seeking funding.
A common misconception is that you first need to understand the project to get accurate estimates. What are the requirements? How much time will it take? What resources are required? Chances are, you will have to invest a lot in upfront costs and spend considerable time getting to know the details of the project. At this point, you’ve already fallen into the trap and are probably frustrated with the process!
There’s an easier way – Constraint-Driven Estimation
What is Constraint-Driven Estimation?
Constraint-Driven Estimation is a lightweight, rapid approach that can help you get a ballpark idea of time and costs that is good enough to feed into your business case. Ultimately, at this stage of formulating the business case, you want to rapidly understand if the idea is financially viable or not.
The technique uses common constraints as input to build a time and cost model:
Minimum team size – what is the smallest delivery team we could put together to start delivering this work?
Maximum team size – what is the biggest team to put on this before the team size becomes too big?
Typical time to release – how quickly can we typically get a new feature into production?
Deadlines & Timescales – are there any deadlines associated with this work? Hard or soft?
Max budget – what’s the most amount of money you’re willing to spend to solve your problem?
By exploring these constraints, you’ll often find that they’re limiting your options anyway, enabling you to quickly understand the impacts on your business case and return on investment (ROI).
We’re yet to come across an organisation with no constraints. If a business case has no constraints, don’t do it!
Exploring the Constraints
Here, we’ll tell you more about how to explore the constraints. This will give you the background knowledge needed to have better conversations when building your cost model.
Minimum & Maximum Team Size
Think about the minimum and the maximum number of people, with the right skills, needed to develop the software. You probably won’t know much about the specifics of the work, but you should be able to deduce the knowledge domains required and the high-level technical skills needed.
You likely have a finite and limited number of technology stacks across your organisation. Therefore the skills and technical capabilities required should be easily identifiable from the project brief.
The context of your business domain tends to be finite and limited. You will unlikely be asked to take on a project from an unfamiliar domain outside of your context. For example, if your business domain is a price comparison website for consumers then the new project is highly unlikely to be a request to develop an interplanetary spaceflight guidance system!
In other words, you are not working from a blank sheet of paper. You will already have insight into the types and project staffing levels you have used in the past. Ask a couple of simple questions – “what’s the smallest team we’ve ever used?”, “what’s the biggest team we’ve ever used?”
What is the maximum team size that we can get on the job without them standing on each other’s toes?
Typical time to release
Some teams can release a new feature in hours but most take days, weeks or even months. Ask your development team how quickly they typically release new features and what the lead times usually are. This will give you a rough feel for the minimum amount of time you’re going to need to invest before any value is released.
Deadlines & Timescales
“take as long as you want, no rush” – said no one ever! The expectations and deadlines associated with the work you want to do are important aspects to explore when thinking about your cost model. Make sure you fully understand the difference between a hard deadline and a soft deadline. Black Friday is an example of a hard deadline. Regulatory demands are another. The deadline is beyond your control as an organisation.
Soft deadlines are timescales that if not met will negatively impact the business case. “If we don’t release this month, we’ll lose £25k per week of lost opportunity (cost of delay)” is a good example of how to convey the potential consequence of missing out on a deadline. The important thing to understand here is the impact of not meeting the deadline and quantifying it if possible.
Max Budget
How much are you willing to spend to solve your problem? For a given investment, your stakeholder expects a certain return – but what is that return? Ask them to quantify the expected return.
Knowing the return of your investment is critical to making informed decisions. However, it can be difficult to calculate the return of an investment if you don’t know the value it will deliver.
Watch out for stakeholders who are trying to get you to write their business case for them. They may strong-arm you for a cost estimate, and then try to negotiate the price lower to make the business case look more attractive. Ultimately, they are just shooting themselves in the foot.
“doesn’t matter how much it costs, just do it!” – I’ve only heard this phrase said in a couple of scenarios. For example, a regulatory requirement may dictate that you do it otherwise you will be shut down. Or calculating an ROI may be difficult because of a lack of precedence in the market. If it’s due to a lack of precedence in the market then it’s a punt. In these circumstances only bet what you can afford to lose.
Constraint-Driven Estimation in Action
Our Software Estimation Toolkit provides an Excel spreadsheet template to help you turn constraints into an estimate. The screenshot below shows the general idea.
Input your constraints in cells B5 to B10.
Cells B11 and B12 contain the minimum and maximum cost estimates, respectively.
Always present your cost estimates as a range, instead of one specific number. This allows your stakeholders to input on the estimate and help them better determine how much to budget in the context of the expected ROI.
