Getting better at estimating is hard, but first, a word of warning.
Before the estimation can even begin you have to have at least a limited draft of a specification that both you and your customer are willing to sign off on, you because you are confident that you can build it and your customer because having that implemented will make them a happy customer. Happy customers are repeat customers, repeat customers is where you will make in time the most of your money.
Any estimate before the scope of a project has been laid out is essentially meaningless and plenty of people fall for this, answering questions on how much something will cost or how long it will take before that document has been agreed upon is going to get you in to a world of trouble.
If a customer asks more beyond the draft specification after you have agreed on it, you have to realize you are back to square #1 and that any agreement reached regarding what is going to be built, how long it will take and what it will cost is null and void.
You will have to re-estimate and work the changes in to the new estimation.
Some small requirement changes may cause big consequences.
We’re looking at this problem through the eyes of a junior project manager, someone that has been growing a business with a bunch of friends, reasonably successful so far, they’ve been referred the example customer through a previous customer that was happy - eventually - with the work the company has done.
The customer was happy, which is good, but you and your friends know that when all is said and done you probably lost money on the contract but you kept a straight face and swallowed the loss due to estimation errors in that job and you’ve vowed to do better in the future.
But how ? Hopefully that’s why you are reading this page.
So, let’s take it as read that by the time you start your estimation job you have on your desk a document that has a rough outline on it of what is going to be built, that we are going to give a ‘fixed price’ offer with a hard deadline for delivery and that the execution of the outline is within your groups’ capabilities.
The first thing to do is to break down the proposal in to a number of blocks, if I estimate a job I break it down in to foundation and ‘deliverables’, where each deliverable is a module that will perform some function, and which can be built or parceled out as a bite-sized block and checked off when it is functioning.
For an example, lets pretend we’re going to estimate the work on a website, with a web-shop, with a couple of twists to make it interesting. If you don’t build web-shops, do read on, the principles are what matters here, not the actual project, that’s just some scaffolding to hang my points from, the basic principles apply to any contract work, from Architecture, to Programming and Zebra-crossing painting. The elements will be the same, only the roles and activities will vary.
The ‘rough outline’ that you and your prospective customer have agreed on is the following:
A website will be built which will consist of the following sections:
a homepage, with basic navigation and an introductory blurb
a product portfolio with a limited CMS so that the sales people of the company can update it without supervision or assistance from more technical people (as it should be)
a contact page with information on how to reach the company by email, telephone, snail mail, and if required by transportation, both private and public
a shop module, with a back-end hook up where the orders from the store are going to be entered automatically in to an order processing system which already exists (because the web shop is only one of the ways in which the company receives their orders), and that before an order can be made there has to be a call to the inventory system to make sure the item is in stock. The ‘shopping cart’ will be tightly integrated with the portfolio pages
users should be able to register with the website to expedite ordering in the future
there is to be a limited order tracking facility that will tie in with the shipping company that you use, and an alternate shipping company in case the first one can’t be used. Say FedEx and UPS.
a customer support module is indicated which can issue tickets and which will guide the support desk of the company in their daily work
a frequently asked questions module which can be used to relieve some of the pressure of the support desk of the customer by guiding users through common scenarios.
an about page that tells a bit about the company,
a press releases page
We’d rather program this from scratch in = insert your favorite hot programming language here = but the customer has heard great things about ‘drupal’ in the press and from other companies they work with, so ‘drupal’ it is, small gotcha here, we don’t have drupal experience, but one of the backend guys in your shop has worked with PHP before and thinks he can hack it. (this site is running on Drupal, and even though I have my strong reservations about the platform, in particular with respect to their major release upgrade troubles I figured that I should use them as an example or switch the site over to something better. Drupal is touted as a ‘CMS’, but in fact it is more like a frankensteinian swiss army knife that has everything and that kitchen-sink built in or in a module somewhere, it is a very capable tool but you have to read up a bit about it before committing to it, it is not without its problems, but it is perfectly capable of fulfilling all requirements listed here).
The company is US based, and sells for the most part to US customers, however, they’ve found that they currently have a small number of customers from latin america, and their widgets could be sold in larger numbers there through the website, so they request the website to be tri-lingual, English, Spanish and Portuguese.
the job is to be delivered ‘turn-key’, in other words your company is the main ‘contractor’ on this project and you are responsible for hiring copywriters, translators, the programming and the design work.
Just a small website, right? Drupal has modules for all of the above, you’ve already checked that with a bit of googling, the designer says he’ll have something cooked up so it won’t take more than a week. Let’s build in some safety here and three weeks should be plenty, right ?
BZZZZZZZZZT. Wrong.
Now, if you’ve built 10 websites using drupal of roughly identical functionality you might get away with estimating like that.
But in this case there are a number of subtle pitfalls in the specification that will completely ruin your relationship with your customer over the course of the work if you do not slow down a bit now and estimate this properly.
The key and I should put this in bold and blinking letters but I really don’t like the ‘blink’ tag, to good estimates is to dig up each and every unknown that is hidden in a specification that seems to be 100% clear. There is no such thing as a ‘perfect’ spec, but the spec above deals with the problem almost exclusively in terms of what it looks like to the outside world. It does not go in to details about what’s going on behind the scenes and that ‘mismatch’ is where the problems will come from.
Estimating this at the back of the envelope is almost sure to get you the job, but that’s mostly because you’ll be quoting a price that is so ridiculously low that nobody will be able - or even willing - to compete with you at that price. The reason is simple, you are probably under estimating the amount of work that needs to be done here significantly because of insufficient insight, and to improve on that we need to follow a number of formal steps.
The first thing to do now is to break the problem up in to each of its component parts, figure out what the foundations are and how the ‘deliverables’ will be realized on top of those foundations.
Let’s list them one by one:
foundation components
platform
hosting
version
future upgrades
maintenance
design
template (8)
artwork
usability analysis of the design, iteration
under-water communications
protocols and standards used
shop module
CMS module
permissions structure
role definition
setting up access rights to various content modules based on those roles
initial content
- translation of the content to Spanish and Portuguese
When you write it out like that it appears immediately that there are a number of elements missing from the specification.
(1) It’s obvious that the initial content is not the content that will be present over time, so the translation of new content will have to be automated to such an extent that the people that will provide the initial content are not going to rely on you to keep the site up-to-date. By taking the job on in a turn-key fashion and by making yourself responsible for it in this way you’ve set yourself up to be the go-between for translations of text in the future, as well as a potential liability for translation errors.
So the right thing to do is to realize that translation is not quite like design and should never have been part of the work you contract for in the first place.
That part of the deliverables needs to be restructured so the company will deliver you the translations for the initial content.
(2) Another gotcha that was not visible in the original spec is that the hosting facility for the web server is not at the same location as your customers offices, system that runs their back-end and order processing system is located in their offices. So you are going to have to do communications between the web server in one location and the intranet server in another.
On top of that the intranet server seems to use an antiquated protocol for external integration (you’ve asked for the documentation on the intranet server from one of the tech people working for the customer), and it looks like there is no built-in support or even some library that you can buy in order to create records the back-end server will accept.
(3) The order tracking system will eventually give the customer a ticket when the package is shipped, there is a lack of clarity in the specification how that tracking information enters the system. Is this something that the customer will enter in a form somewhere and then the user will take that information to the website of the shipper or is it the intention that the shippers API be used to integrate the information in to the order status page? Both are valid interpretations of a ‘limited tracking facility’ and you need to get on the same page as to what is expected.
(4) Security was completely overlooked in the original specification, it looks as though everybody has access to everything, clearly, this can’t be right, help desk people shoud not be able to change prices and so on. You need a series of ‘roles’ defined and which actions each of these roles is allowed to perform.
(5) Nobody mentioned a word about how frequently the website of this customer will be visited, but fortunately the statistics of the old site are available and to your shock and surprise the company has significant traffic to the website they already have and it is your estimate that you will need at least two front end-servers and a database back-end to make this work.
(6) The programmer on your team will have to work extra hard on this job because he has no experience with the framework, so you can expect a significant amount non-billable time lost for him to get up to speed. On first job this may come to two or three times as much time as it would take on a job done with a platform your group has experience in. You can’t factor that in to the ‘billable hours’ because then someone with more experience will undercut you, but you will have to figure this in to the delivery date.
(7) Make sure that every module and the final integration have sufficient time allotted for testing.
The thing to do now is to start iterating on the specification. Go back to the customer with your notes, either in person or on the phone, and list the things that you have found that were not deliverable after all in the original spec (for instance, the translation services), work out how they are going to be part of the workflow and how the data will go from your customer to the translation services, back to their people and after verification on to you for the initial content.
Work out how you are going to get that data from the hosting facility on to your customers intranet, what kind of security issues you will encounter in order to do this (VPN? firewalls? etc) and get access to all the documentation of the intra-net system as well as a line to the vendor of the back-end system and their help desk in case you run in to trouble while doing the integration. Verify they haven’t gone out of business!
Work out what ‘limited tracking facility’ means, to the customer.
Ask which security implications there are with respect to the modification of the various pieces of data that you have identified, such as product info, pricing, order status, customer information, inventory and so on.
Figure out who will do the hosting, are you going to be responsible for that part of it, how much will it cost, what kind of SLA are you going to agree on with your customer and how will this impact your own organization because you are currently not set up to do system administration for a customer.
Rework the specification with your new found knowledge, send it back to the customer to get them to agree on the new state of affairs and then do it all again.
At some point you will find that you have a specification that is no longer changing and that both you and the customer still agree on.
Which is great, that means that you are now ready to start the actual estimation process, and that is surprisingly simple. In the past, you’ve been tracking how many hours of work have gone in to previous projects, and you have your old estimations as well.
Take those two side by side and get a worst case factor, how bad were you ‘off’ on average?
Given you new confidence level of having nailed down the customers requirements for the project, take it to the people you will be working with (they’ve supposedly been kept in the loop during the reworking of the specification), and go through the items in the specification one-by-one and work out how much time will go in to it.
If an item is an unknown generously overestimate it, you can always deliver early, but not late.
Define milestones, as the project goes forward, each and every item that needs to be done gets it’s own start time on a timeline, an alloted run-time and an end-date on the timeline when it is completed.
The roles of various people (in this case project manager, who doubles as Q&A and tester), designer and programmer are running in parallel, and sometimes there are parts that need to be done before someone else can proceed.
Now your role becomes the mirror image of what it was so far, so far you were the contractor that was building something for a customer, now you are the customer of the people that are going to do the actual work, and they take the role that you had in the story so far. Make sure that they are on the same page as you are, work out a specification of what it is that they are going to build, how long each module will take to complete and which uncertainties there are. It’s turtles all the way down.
This will take a bit of time from the various team members, but it will ensure that everybody is in the loop, and that if the job goes through there will be relatively little room for people that are suddenly confronted with stuff that was promised over their heads that they can not deliver or can not deliver in time.
Have people commit to the milestones, make it clear that they are ‘mini deadlines’ and can not be shifted, so a deliverable had better be ready by the promised date. On the sly, build in some slack here because you know something unexpected will pop up, no matter how good that spec is.
Figure 20% to 30% slack space in to your project on top of that, to cope with people falling ill, communications mishaps (oh, sorry, I didn’t realize you were waiting for my email) and so on.
The programmer has now had a long and hard look at the spec of the back-end server, he’s worked out how to get to it, so the communications problems are solved, but the shop module can only do XML and XML was science fiction when the back-end server was built, the company that built it went out of business during the .com boom. The solution seems to be to hire an external expert that has experience with this kind of system that will take your XML and make sure it gets imported and any data spit out will be converted back to XML.
He’s willing to do it as a contract job, again, you are the customer, work up a detailed specification and make sure that he indeed has the relevant experience and that the time allotted seems reasonable from your point of view, make sure he has no other work or responsibilities that will pre-empt his work for you.
Agree on a fixed price with a delivery date well in advance of the final delivery date of the project to your customer, allow for integration snafus and some delays and possible communication issues.
A third party has been found that will do the hosting and that has the relevant experience in keeping Drupal patched and secure and is willing to give the required level of service. You and the customer have agreed that the contract for the hosting will be out of the scope of the construction of the site and the customer will contact the hosting party directly to arrange for the required machines to be bought and configured, ready for your people to start the delivery, a date has been agreed on, the arrangement is pending on you being selected as the party to execute the design.
At this point in time you will have a detailed understanding of what will be built, how long it will take to build each module, which means that you have a spreadsheet or a project management tool up and running with a detailed overview of how this project will run if you get the contract.
You’ve probably done several days of really hard work that will not even get paid if the project falls through, as you do this more often this time will decrease.
But this is the interesting part. You are at this stage almost guaranteed to get the job. You’ve been in constant contact with the customer, you’ve shown in increasingly solid understanding of the problem and the solutions to those problems, probably the customer has by now learned a thing or two about their own business from you, you have given the customer confidence that you are willing to do what it takes to get this project finished on time and within the budget.
Estimating was the hard part. Once the spec is really solid the rest is ‘mere execution’.
A small note about execution:
While ‘executing’ the job make sure that people keep track of the time spent on the various sub-jobs and compare that to the time that was agreed on during the specification phase. Note any discrepancies and try to avoid slipping of the schedule. This is a lot easier now because you have a lot of ‘mini deadlines’, each of which can be marked off as time progresses. If a mini-deadline is not made in time the extra work will have to be done between the expiry of that mini deadline and the next one. Like that you keep surprises to a minimum, instead of finding out three days before launch that half the project isn’t done yet you will be able to keep track of it on an almost day-by-day basis. And while it’s possible to make up for a lost day in one day of a bit harder work, it is not possible to make up for three weeks of lost time in one.
After the project is completed you can use the creep that did occur and the overruns on sub-projects to learn how to improve the estimate the next time around by adjusting for your observations.
In a corporate setting where the ‘customer’ is the company that you all work for the process is much the same, only the billing will be different.
More about that in a follow up post, I hope this was of use to someone.