I have a conflict at the heart of my business.
I believe strongly that agility is required to deliver successful software projects. As each project I work on is unique it is high-uncertainty work. We are designing and learning as we go to understand the best way to solve the problems the users face.
However as an external service provider to these companies the business side strives to eliminate uncertainty. I strongly understand the desire to fix budgets for outcomes and it is something that I want to do. I hate the uncertainly of hiring companies by the hour, not knowing what the bill will be at the end.
In my early days, I did bill by the hour and it could be made to work. But in reality it was never truly flexible – if I come back with a bill that is 2x the original budget – am I likely to get paid?
I work with an iterative approach and price each iteration based on the outcomes we have defined. That way we can go to purchasing for a fixed purchase order for a fixed outcome. Then at any point between iterations we can stop work and the invoices stop coming.
By focusing on outcomes rather than software specifications, we can adapt as required within an iteration when we learn something new.
If the work is still looking very risky then I might run a design session or experiment instead. This allows us to understand the risk rather than having to give an enormous price to manage the uncertainty.
Of course, this doesn’t help with broader budget planning. The best I can offer in this case is guidance based on similar projects
The best way to understand why some of these practices work is to see what happens when I don’t follow them. I have a habit of breaking my own rules on occasion!
On a recent project, a customer asked me to deliver a solution similar to a previous project. This was a tester, not part of their main business and really, they wanted an off-the-shelf experience. Purchasing were pushing to pay per tester in a single purchase order.
Seeing as this felt like well trodden territory, I agreed to work in this way instead.
Roughly halfway through the project, it was clear that we were trying to fit a square peg in a round hole. The products that my customers wanted to test were still in development. Rather than having a well defined set of tests, they needed more and more flexibility to get the most from the system. Our original approach of fixed test profiles was going to hold both of us back.
In this case, we got lucky. The point at which we realised this didn’t fit, we re-assessed moving to a flexible tester based on were we had got to. I could reuse most of the existing code and my estimate suggested the effort was similar. Because I scope outcomes rather than software specifications we were able to agree a change without having to revisit purchasing.
In other cases I may not have been so lucky. If the solutions had been more varied in effort or risk then we would have a problem. Either the customer may have paid more than they needed, or we would have to go back to purchasing. Something that would have delayed the project.
I hope this goes some way to understanding my approach. It is a constant balance between best supporting my customers business and technical needs. I’m constantly adapting as I learn more.
There are still unanswered questions in my mind and I’m happy to work with each customer to address these balances to suit them.
Why Software Development is Hard to Estimate
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.