
5 Things You Might Forget in an Estimation
Often times, a client will bring to me a great idea and ask for an estimation. The problem is, for me to make a good estimation, I need to imagine the product from the back: at the last day of delivery, looking back to the project start, what happened? I need to also be able to see the product on that day. "How many buttons on each page and where did they go." All of this gets put into the estimation. Of course, you can imagine that many things catch clients by surprise.
Here's 5 things that I estimate for that clients may not:
5) VISUAL DESIGN
Actually, most clients don't forget that visual design needs to be done. In fact, getting the pretty pictures is usually their favorite part of the project (BTW, everyone thinks they're a visual designer. I am, too, of course). What they forget, though, is that visual design needs to be converted into code: HTML/CSS. Throw, on top of that, the functionality (dynamic drop downs, anybody?), and you're talking about more time that you just didn't see.
4) TESTING
Some customers don't understand why testing is necessary. Why can't the developer just test as they go? The reason is that in every implementation, developers make assumptions. Having a tester validates these set of assumptions, as well as ensures that the assumptions link back to the business process. Plus, sometimes after you've drilled the 1000th nail in, it's hard to step back to see the whole wall.
3) PERFORMANCE TESTING
Not to be confused with testing above, performance testing/tuning requires a whole different skill set. It's one thing to push all the buttons in your car. It's a whole other thing to test how fast your car goes. For some reason, most customers prefer to pretend there's no such thing as performance testing. I'll concede that a "new" site might not need as much speed as a large-scale one. Nevertheless, if it's slow, the fingers point to me. So I have to factor it in.
2) TWEAKS IN FUNCTIONALITY
Every client/product manager forgets something. It might be "what happens when 'more' is clicked". Or it might be "what happens when a browser is closed in the middle of a process". Or, it might just be "oh! I forgot this!". Clients also hate to hear, "no. That's out of scope." So, there's a buffer for these tweaks. The amount can vary (but shouldn't be zero), but it should be agreed by both parties. It also reflects how flexible the project manager should be toward change requests.
1) DISCUSSION TIME (AND RAMP UP)
When an engineer makes an estimate, they're usually thinking "the customer has told me 100%. This will take exactly 4.5 hours to build". However, there's more to development than coding. (a) Customers soon figure out that they only told 80% and still need to clarify more. (b) Projects have daily scrum meetings. (c) Developers need to talk to testers need to talk to Project Managers need to talk to clients. (d) etc. I've seen projects where clients have said "I don't need discussion time in an estimation" and ended up chatting with developers 3 hours per day. The reality is, a construction worker can't build a building in a vacuum. He needs to talk to, if nothing else, other builders. The same principle applies for building websites.
Anyways, this list is by no means exhaustive, but it's just some of the things I come across. In the future, if you're asking for an estimation and you don't see these things, maybe you’re getting a “steal”, or maybe you’re talking to someone who isn’t as experienced as you need.
