This post kicks off my long overdue series on estimation techniques for developers. Each week I’ll be sharing something I’ve learnt over the last 12 years of estimation in small-medium private sector web development teams. Some will be longer than others but hopefully you’ll find a few useful at least.
I’ll be touching on topics like:
- scope of an estimate
- risk assessment: AKA “how to help your project not fail”
- approaching the estimate document: how to describe the work
- understanding price, effort, elapsed time and velocity
- strategies for lack of time or info: using assumptions, questions and exclusions
- coming up with the numbers
- cost: strategies for communicating cost with vague requirements
- applying the DRY principle to estimation in the SDLC
- the argument for technical estimation: convincing your boss and your clients
- resources for further learning
Let’s get into it!
It’s About Needs
When your boss or project manager taps you on the shoulder and asks you how long a project might take to build, what does he actually need? Whether he says it or not, he needs you to supply:
- a solution
- for a price
- at acceptable risk to your employer and your client
and he wants this all provided:
- within a timeframe
- with a certain amount of accuracy.
What he has for you is input information from:
- the client – requirements, ideas, maybe a budget limit or delivery date requirement
- him (the boss) – his ideas on a possible solution
- third parties – references to sites or documents for any third party products to be used
All of this is communicated by “Hey, how long do you think it would take to build this site? It’s like eBay.” You need to understand what’s needed and endeavour to fulfil those needs.
Let’s take a closer look at these terms now. I’ll be expanding on these in later posts.
This is our technical architecture, defining what we’re talking about. Is this project to build a new website or an improvement to an old one? Is graphic design part of the project or not? Will you be loading content or is that the client’s responsibility? Can you log into the new site with Facebook or not? Will it need to work on an iPhone? The amount of detail you go into will be dictated by the required accuracy – this section could be anything from a few dot points for a rough ballpark, to a few hours of detailed reading for a formal quote.
This section is important for a variety of reasons. It’s likely to be the first sizeable written communication between your company and your client. It doesn’t mean you have to make it overly formal, but it will set up an opinion of your team and the way you work. Make it neat. Use correct spelling and grammar, even if it’s just a few lines. Now’s not the time to be shy! Harness the power of first impressions and make the most of it.
Make sure the document helps your client too – they may be comparing your response with estimates from other providers and it’s important to list what you have or haven’t included in scope so they can compare apples and apples and know you’re the best fit.
Most importantly, the solution architecture establishes expectations of functionality and defines scope of the project. The clearer you are in describing your solution, the easier it will be to detect scope creep and avoid (and at its worst) the decay of the business relationship and other horrible events later in the project.
If you’re smart about it, the solution architecture becomes your project specification when you get the ball rolling. But more on that later!
Price (or Price Range)
Depending on the accuracy required, you may need to produce a single number for a fixed quote, or a ballpark. The sorts of things you’ll cover are hours of work required by different experts in your team (or by contractors if needed), the cost of any graphics, licences, services or products needed for the project and depending on how your company works, overhead costs.
Most of us have the good fortune of not having to worry so much about the cost of a team member’s time, and can deal instead with simply giving our boss an estimate of hours required for each expert.
The most important point here (and one that many non-techs in our industry inexplicably seem to have trouble grasping) is:
You don’t know how long it’s going to take until you know what “it” is, so defining the solution must come first.
Generally speaking, if your solution is a few vague dot points, then your numbers should be few and vague (if supplied at all).
I use the word ‘acceptable’ instead of ‘low’ because at the end of the day, it’s up to your boss and your client to each decide whether they’re prepared to take the risk or not. All you can do is help them make informed decisions by identifying risks and their impacts and (if you can) make recommendations for avoidance or impact reduction.
Time Frame, Accuracy and Input Information
This isn’t the time frame for the project, it’s the amount of time you have to respond to your boss with your estimate and it is critical that you know how much time you have before you start. Timeframe and accuracy are opposite ends of a slider: less time usually means low detail and low accuracy (or not being able to confirm that something is possible at all!). High accuracy requires more time. Both of these are also affected by the amount of info provided: too little info could mean that either you need more time to research, or the accuracy of your estimate is low in the face of unknowns. On the flip side, too much information could mean you need a lot more time to digest it all and may not necessarily help you increase the accuracy of your price estimate or solution architecture.
You Have Super Powers
In my experience a non-technical project manager can rarely do all of the things listed above with sufficient accuracy or consistency. They may have worked with a similar style project before but even a seemingly minor difference in interaction, or browser compatibility, or content structure, or expected site load will need approach and estimation changes (and new risk assessments) that our non-tech team members may not be able to identify or estimate.
As we all know, uninformed project planning leads to easily avoided disaster.
Enter you, the technical specialist. You’re probably a developer. You may or may not have a cape (you should though, right?). You could be an old hand, nailing all of this every time, in which case I hope you can provide some feedback and suggestions! Or you may be starting out in a role where you’re called upon to estimate (we all were fresh faces at some point).
Regardless of where you are in your career, your technical knowledge and skills are invaluable here. In some ways, you could even be more valuable as a technical estimator or technical project manager than a programmer! A well estimated and planned project can completely avoid many of the problems and emergencies that a talented person like you is often called upon to resolve re-actively. You know what I’m talking about.
This is your chance. Get excited about your opportunity to help craft a project that will run smoothly and be a pleasure for all involved.
Are you excited? Good. Now hold on to that until next week’s post :-P