When specs don’t work
When estimating for a project that you’re not sure you’re going to be awarded, you don’t want to spend too much time analysing the minutiae in the spec. So what do you do when you’ve won it, you’re half way through building it, and you stumble across a small, but fundamental problem?
I recently undertook a project on a fixed cost basis that a non-tech-savvy guy had spec’d. The spec was, on the face of it, quite thorough and lengthy, approaching 100 pages, and included some wireframes. I spent a reasonable amount of time thinking about the requirements and considering the implementation to get, what I thought, was a fairly accurate estimate.
When specs don’t work
In this project, I actually encountered several small, but fundamental problems, such as subtle, contradicting relationships between data elements. So what did I do? I bent over and solved them myself, but I certainly won’t do it all the same way next time.
So, what would I do differently?
- Try and include a disclaimer that accompanies a fixed cost estimate along the lines of “The estimate is for the functionality defined in the document titled X version Y supplied on Z. Should it become apparent during the build that functionality defined in the spec is contradictory or fundamentally will not work, this will be communicated to the client as soon as possible, and if required, an alternative solution may be suggested. Estimated costs and delivery dates are subject to change should this situation arise.”
- Make sure I fully understand the whole project requirements and design the system to meet them, before starting any coding, even if the spec is 1000 pages! Then, if there is any contradictory functionality or fundamental design flaws, communicate them to the client as soon as possible.
- Encourage the client to pay for a review of the spec by a tech-savvy guy, someone who thinks through how the system will be built, who has a logical and methodical way of thinking to consider all possible scenarios, ensuring all situations are identified and their functionality is defined and possible!
- When supplying the estimate, if there are certain parts of functionality described in the spec that seem cumbersome or would be difficult to implement, consider also suggesting a simpler implementation that achieves the same thing but takes less time, and include the estimate for this as well. It may take longer to create the estimate, but the client might appreciate your honesty, ability and professionalism and award you the project for saving them money.
The only real mistake is the one from which we learn nothing.
John Powell


Leave a comment