More often than not when engaging a software developer there will be a conversation about price:
“Here is what I want. How much will it cost?”
The conversation may be more subtle, or nuanced, but the bottom line is pretty much the same no matter what: A true definition of what is actually being asked for is not very well defined at the point in time a price is being requested.
Consider the evolution of the project as a ‘cone of uncertainty’ – the farther you go developing the software the more certainty you have of the cost, time and definition of the final solution.
Image courtesy of http://www.agilenutshell.com/cone_of_uncertainty
There are a few ways of mitigating the risks associated with the cone of uncertainty:
Stage the estimation of the solution – we generally would develop a high fidelity interactive rapid-prototype of the solution to be developed as code. By doing this, we get a chance to understand the real scope of work including unhappy paths in much more depth. Then, a second phase estimation would be much more accurate
Model the estimation based on complexity – by using probabilistic models in estimation software, historic performance of the vendor and some comparative measure of the complexity of the project, it is possible to get very close to accurate pricing
But wait, what about the detailed cost and the detailed scope?
Well, this is where things get interesting: a complexity-based estimation is an estimation that works at the top of the funnel and actually breaks down as you move further down the funnel – this is where agile project management comes into its own.
The project manager will start to translate the broad brush strokes of complexity-based estimation into the granularity of detailed scope and estimated user-stories as the project progresses. Further to this, those detailed user stories will be attenuated for detail as the project progresses.
There are two great benefits to using time-boxed agile sprints to deliver working software:
1. You get to reduce the ‘scope to cost’ risk into many more discrete pieces.
If you think of the balance of risk to the vendor for assuring delivery of the scope as a seesaw, with you on one side and them on the other – if they do this once at the start and they are just compelled to deliver, it’s like having a huge seesaw: massive effort to deliver and completely imbalanced. The vendor is holding all the risk and will either charge you for it, or it will cost you that in overrun. Either way, you end up paying for that ambiguity. If you instead have small seesaws instead of one big one (think: agile sprints) then there is less work yet a balance of risk is achieved without excessive cost to cover the risk
2. You understand the implications of your disparate mental models, make better-informed decisions and get control of the project variables
A vendor will invariably have a picture in their mind as to ‘the definition of done’ which is a large determinant of time and cost in any project – yet often not well explored. By having many opportunities to align with the vendor on an agreeable ‘definition of done’ you collectively understand real delivery dates – you even get a fancy chart to help! So then you get to control the variables of the project: What needs to be controlled? Scope or Time?
Image courtesy of https://www.axisagile.com.au/blog/planning-and-metrics/scrum-metrics-and-reporting-measure-what-you-manage/
An agile burndown chart extrapolates delivery date and effort very early in the project.
It is very important for the vendor to watch out for ‘big picture’ scope changes at the start of the project and move their way down into the detail of scope as the project progresses. Expect this, and it is in your best interest to have this attention to scope creep – it is the only way to accurately estimate for and effectively manage any complex software project.