In my previous blog post I asked is the functional specification dead? My conclusion was that it unfortunately was not. It is an necessary evil which is required to gain new business.
If our clients will not join us in the agile dream of working without functional specs in short defined sprints and paying for each time box as they go, how can we delivery projects on time and on budget given the unknowns of software? Simple, we do the only thing we can; under promise and over deliver. However I propose a twist with what I call the buffering method.
A functional specification locks you into a guesswork plan. 37 Signals advice a functional story instead:
So what do we do in place of a functional spec? We write a one page story about what the app should do. If it takes more than a page to explain it, then it’s too complex. If it’s simple and it takes more than a page to write it then we’re not writing clearly enough
The functional story maps out what a client wants to achieve but leaves scope for the way and quality to which it is implemented. As an example I could tell a story about a user being able to go onto a website and book some tickets. There is a base level of design and coding required to make this happen, but after this I can implement the web form to a varying degree of quality. This quality element is important as we will see in a moment.
After deciding with the client what we want to achieve, we calculate the build time.
Time predictions are by nature estimates. It is simply not possible to envisage everything that will consume time, and place an accurate time upon it. So we break down the work into the key areas such as design, backend build, frontend xhtml/css build, payment system integration, system admin, testing, project management etc. We place a time on each of these areas, based upon how long it would take if everything went perfectly to plan. We then add in a healthy margin for error. When deciding on the percentage it is always worth keeping Hofstadter‘s witty Law in mind:
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
Depending on the nature of the project this figure seems to be between 15% and 50%.
Once we have a time scale we can cost the project. We multiply the total number of development days by our daily rate to produce our project price.
The buffering method requires that we know how long the team spends on our project. From the moment we kick off work everyone in the team, including the project manager, records their hours. I personally hate time sheets, but see their value in running a client orientated business. For them to be effective all working hours need to be recorded. If a designer takes 15 minutes sending an email to the client in the morning and 10 minutes on the phone later that day, 25 minutes needs to be logged. Time in meetings also need to be noted. It is normal to think that worked hours only include those when photoshop or a text editor are open, but everything we do on a project uses time and so needs to go into the time sheets.
So at this point, the process might look fairly normal. However there are a few things to note. We have used a functional story instead of a functional specification which leaves the quality of work open and we have overestimated the time scale, and therefore in turn the budget. We have crucially given ourselves a buffer. Given that we are keeping accurate time sheets, upon project completion we will know whether we have gone over or under our build time allowance.
Hopefully given our margin for error we will not go over our project time allowance. If we do we have to bite the bullet and take a hit. We investigate what took the extra time and use this extra information to budget according next time.
However the method gets interesting if we have finished the project with time to spare. Firstly we can deliver early, which will please our client. Secondly we have ‘extra’ time in house which we can use to improve the project. We can go back to our client and say ‘We have some time left in the kitty’ and ask them “how would you like to use it to improve the website?”. Alternatively we could spend some time making improvements on our own terms.
As a team we all want to feel we have produced something we are proud of, and there is often a feeling that if we had a few more days we could neatly tidy the project up. What a great thing it would be if a project manager could tell the team “You each have a day to do what you want to improve the project”. A designer might tackle that UI which has been bugging him, a developer might re-factor some code to make life easier in the future. This would build a sense of personal satisfaction right across the team. Alternatively the team could take a day out to do something fun but beneficial to the project such as a viral campaign.
This may just look like giving away your profit margin but I don’t think business is so clear cut. Profits flow from having a happy, motivated, and inspired team who are doing really great work.
As a web development shop we always want to produce the best solutions possible, but we also need to do this within the confines of running a profitable business. The buffering method places an interesting twist on the classic technique of under promising and over delivering. Given that we have built in a healthy margin for error our projects should not be late and if we deliver early we can go that extra distance and create something really great for our client that the whole team is proud of.
