The software development business is all about managing risk. If we look at Scrum for example, it promotes prioritising the product backlog in descending value order so that the highest value items (based on the stakeholders own estimation of value) are at the top, and the less valuable items are down the bottom. The theory is that the project might get cancelled anytime and you want to be able to get the value out of the last potentially shippable product increment.
The true estimate of value factors in a few different things including the timeframe in which a particular feature needs to be delivered in order for that value to be realised which is why software developers so often find themselves having the conversation with the client about how long something will take to develop – which brings us back to that old chestnut of estimating the effort around a particular development task.
The ease of producing an estimate depends on how much information you have at your disposal. When I decide to drive a car from Melbourne to Sydney I have some basis for estimating how long that is going to take. The distance from GPO to GPO is about 900km, so assuming that I am travelling at 100km an hour I should be able to do that in 9 hours.
In reality it will take more than 9 hours because I know that it takes nearly that long to drive from Melbourne to Canberra including some modest rest stops and dealing with traffic on the Melbourne end of the trip. So using a fairly reliable indicator of distance and some prior experience I would take about 12 hours because. My estimate is based on prior experience and some analysis of the gap between my prior experience and the current requirement. I know that I can fairly comfortably get from Canberra to Sydney in about four hours and there is gains to be had over my previous experience because I don’t need to drive into Canberra but instead stay on the Hume highway.
It is the difficult estimates that introduce risk into a project. A difficult estimate is one where you have no basis for estimation, or your prior experience in a particular area is so light on that it may actually be misinforming your estimate.
The key to dealing with difficult estimates is spotting them in the first place and having the courage to communicate to stakeholders that you are having trouble coming up with a reliable number – after all, the reason they are asking you for a number is they couldn’t come up with one.
My advice is unless you can get comfortable with the estimate, don’t provide a low ball. Instead figure out how you could find out more. In software development this often means doing some prototyping work to explore the problem space. Prototype work in software development should be time-boxed to keep the pressure on. It isn’t a bad thing if you fail to produce a prototype within the time allocated – that fact alone tells you that there is indeed significant risk.
Who understands risk?
In my role as a consultant, one of the saddest things that I see is long chains of middle management between invested decision makers and the operational coalface of the business. What I mean by invested decision makers is those people who actually stand to loose or gain something in equal measure based on the success and failure of a project.
The reality is that most players in a business stand only to loose by the commencement of a software project because the total reward they get from success is a pat on the back, but if they fail they will likely get a sizable hit on their credibility. This in-balance drives their participation in software projects. The more removed these in-betweeners are from the actual rewards of the project – the more obvious this behaviour will become until you reach operational level of the business where day-to-day reality corrects this thinking pretty quickly.
Covering Thy Arse
I almost get physically ill when I see people blatantly arse covering. If you aren’t good enough to perform tricks without a safety net then you probably shouldn’t be performing them. Sadly, it all comes back to dealing with people who have a major imbalance between risk and reward.
As an example, in a typical external software development vendor relationship an in-betweener will most likely drive the vendor to produce a fixed price estimate. The reason for this is obvious – if it is a fixed price estimate then even if some of the project risks are realised at least their organisation won’t pay any extra money. They are simply trying to swing the risk : reward ratio closer to neutral.
Talking to the Invested Decision Makers
If you find yourself as a software vendor being pushed to provide a fixed price estimate for something that contains significant unknowns you need go back and understand what business you are in.
Software vendors aren’t in the business of accepting the risk of other companies. If you provide professional services the risk you carry is the hiring and retention of staff and their overall technical competence. If all of those things are good then you should be billing time and materials but all the time helping the customer understand the risks that are inherent in their business.
If you are hitting a wall of in-betweeners about the fixed price thing then your only option is to elevate the discussion to the invested decision makers. Sometimes an in-betweener will surrender their contact details willingly, other times they may protect them with the mistaken belief that elevating the conversation to that level will somehow make them irrelevant. You may need to have a very frank conversation about risk and reward with the in-betweener to get them to see that elevating the conversation is actually a good thing for them.
I’m not a sales person, but these are just observations that I’ve made after being around for a little while.
I’ve gas-bagged for long enough now, but I want to come back to that key point around communicating risk. There are two aspects to it. First you need to understand the risks to produce estimates – are they easy estimates or difficult estimates? Make sure you understand the difference between unknowns and things that are likely to be impossible. Once you have an understanding talk to the invested decision makers about the nature of the risks in conjunction with the estimates that you already have.
Software development; it is all about communication people!