It’s natural that when a software project approaches completion and is more “real” to the stakeholders, those stakeholders will give it closer scrutiny. After all, this piece of software is very shortly going to become something they need to use every day, whereas earlier in the life of the project it was comfortably abstract and lived somewhere in the future. In addition, most organisations are pretty risk-averse. On the risk radar the imminent arrival of new software has a nice, fat cross-section.
The result of this increased scrutiny and risk aversion is generally: (a) a series of change requests, and (b) a go-slow approach to making the software live. Unfortunately, change requests in the latter stages of a project have the potential to compound the length of time required to complete the project. When the code base is small, changes are trivial. When the code base (and the test code base) is large, small changes can require a large amount of code to be added, removed or refactored.
One can very easily get caught in a never-ending cycle of testing, requesting changes, updating, testing and requesting more changes. I’ve observed this process occurring irrespective of the development methodology chosen. True, the effect of last minute changes is far worse with an old-school waterfall process than with a more contemporary agile process, but no methodology can completely obviate the need to simply touch more of the code the later the project runs.
This is how large development houses and management consultants make their money. They will frequently come in with a low initial quote and then happily walk up the overall cost with change request authorisations. This is why the budget overruns for very large enterprise software projects (hello, NHS) can be so staggering. The consultants will be watching the specifications like a hawk, and raising authorisations (i.e. requests for more money) for every last change, however minor.
For smaller outfits like mine, we just want to get the project finished so we can move onto the next thing. Being outcome-oriented, we’re also in the client’s corner when it comes to delivering what they need. The later the delivery, the worse off for everyone concerned.
I was lamenting this situation to Long-Suffering Wife. She came up with something simple, yet brilliant:
Why not charge more per hour the later the project gets?
Picture it. For the original project duration, and perhaps the first round of testing, changes are billed at the standard rate. For each subsequent round, the cost of changes goes up by 50%. The more rounds of testing there are, the more expensive changes will become. Of course I’m not talking about charging for fixing defects. Those would be – at least within the warranty period – free. The charges would only be for changes to the design or functionality.
I believe this would have two significant effects. It would increase the levels of stakeholder scrutiny earlier in the project (when it is cheaper to change things) and it would incentivise clients to weigh carefully the benefits of including changes in the current build versus deferring them until the next upgrade. Both of these effects would gear everyone towards go-live and have the potential to break the cycle of never-ending testing.
I’d love to hear what others think of this idea. Let us know on Twitter @LimeboySoftware.