b++ The curse of estimates
I want to run faster.
Get brief. Set goals. Score. Get out.
Wet dreams.
Experts are cursed. In my experience — the more a person knows, the more she is unsure when asked for an approximation in terms of time for the task at hand.
This can be quite challenging situation, since the majority of clients/investors are not able to deliver fully developed specs. Most of the time, they just tell you what they envision in general, and you’ll have to figure it all out by yourself. If you are not reacting promptly, in many cases you loose a prospect.
In fact, prospects are right. They hire you to create magic from their random thoughts. The only problem is — you can’t charge your know-how separately. But I digress.
All professions on the web are infected by the correct estimate syndrome. Perhaps because I’m at the front-end side of things, I perceive back-end people are more into this epidemic than designers or front-end developers. I rarely ask front-end people, since I already know what can be done at what cost and in what time. So take my claims with a grain of salt.
Designers as a more irrational people are giving the estimate by their gut feeling or quite often already have established prices for various deliverables.
Programmers are rational and concrete, so they are always trying to give the exact estimate. I dare to send a message: we need such a precision only and exclusively in your work. The time programmer spends on discovering how things work, should be calculated in the estimate. I strongly believe that anything can be disassembled in matter of days, if not hours.
Features that clients request are almost always invented before. Clients are occasionally surprisingly informed and educated, but very rarely with a true authentic concept. My logic tells me — we are re-factoring what have already being adopted on the web. We should be familiar with 95% of the requested features or tasks.
Unless it’s something completely new. People are telling me The new things are fun to work with
. I hear that all the time. So I have a second-guess that the estimate in terms of billable hours is not applicable here.
As I see it — you work repetitive tasks for money, while you innovate for fun and personal growth (and so you can make more money later, when the feature becomes popular request or part of a standard package).
For any task, there is the worst case estimate, the super-optimistic case estimate and the estimate by experience. Experienced expert should know:
- what can go wrong
- how fast she can do it, if she is in the right mood
- how much time and effort some similar task(s) took her in the past
This is, of course, my point of view. What’s your approach on this?
Addenum
Snook lists the most common tasks a true web developer has to go through in A Web Developer’s Personal Projects.
001—2008.09.30.09:42
“you work repetitive tasks for money, while you innovate for fun and personal growth” - obvious, but I’ve never realized it.
“we are re-factoring what have already being adopted on the web” - the most difficult tasks in dealing with clients nowadays seems to me to persuade and explain them NOT to use this feature that what they’ve already seen elsewhere. But is a matter of fact that in web business, estimating is problem, despite in most cases designers and developers do the same thing again and again…
002—2008.09.30.10:18
The only way to accurately cost a project from a developer’s point of view is with an exact specification. Being told something like “we want an e-commerce site where customer’s can log in and view their account history” is roughly equivalent in design terms to “we want some advertising material designing”. Some clients would literally mean the most basic feature-set you can imagine that covers the above, others want you to recreate Amazon.
The only fool-proof method I’ve found is to draw up a detailed spec and put together a cost for doing it, then go back to the client and ask them if *any* feature is missing, then revise the quote.
003—2008.09.30.10:57
Excellent write-up Marko. It seems that the bigger the project is—more vague the spec becomes. :)
Recently we’re really struggling with this, and I insist on documentation or at least a solid, detailed brief with a feature list. If they don’t have it or want/know how to make it I suggest that we can make one for them. It’s not a fun part of the job, but it does keep the client who would have gone somewhere else who would take the job without the detailed spec and who knows what would happen in the course of the development.
004—2008.09.30.14:38
Programming and design related tasks are creative activities and as such come with risks. The consequence — estimation is subjective. Good estimation can therefore be based only on experience and judgment of the individual doing the estimation.
Estimation — unfortunately, once given — is perceived as an expectation in many cases. And when things go wrong (and they do), the estimator is called upon his *estimation* as if it was a signed contract with >95% certainty in whatever was being estimated.
Now combine the above with increased experience (experts) resulting in more occurrences of stuff going the wrong way. The result you get is the behavior which you observed — people tend to become cautious about giving their estimates.
The solution (as several commenters have pointed out already): having a detailed specification of whatever needs to be estimated.
Detailing out such a spec is by no means a simple task and usually involves several back-and-forths between the one needing the estimate and the one expected to give it, but it’s the best thing for all the parties involved.
005—2008.10.01.06:43
Regarding the detailed specs:
Scenario #1:
When it comes to creating feature set (and specs), developers more often then not question requests, because of their own preference. Like, “I will have to spend too much time for the feature, and I think it’s not worth it”.
On the other hand, they are not keen to participate in detailing documentation, as this is “not their job”. Not all, but many.
Scenario #2:
A client sends RFP, you need to provide her with a quote, based on the estimates of your colleagues.
A programmer needs a detailed specs, so you spend some time to write detailed specs. When finally done, the programmer says “Well, I never done that feature before. I can’t tell for sure, give me a week to Google it out.”
If you are lucky, so far you spent only two weeks to get an estimate, so you can calculate the quote and send to a prospective. At that point the contract is still not landed.
Prospective says: “This is beyond our budget. Can you provide me with another proposal?” or even worse “Thank you, but we got another agency”.
006—2008.10.01.07:07
Do what I did with my customers: Tell them to shut the frak up. Customers are dumbasses. Never forget that.
007—2008.10.04.07:27
Working as a sales person and a project manager for the last 2 years, here is my experience.
1. To be able to make a quick and a relatively precise estimate, I have to come out of a very good time tracking situation with the designer, programmer, manager and content manager for the project. We use tick for almost 2 years now and gathered a very good picture of what type of work or feature takes what amount of time. We have created an extensive list of features and estimated hours and made it easy to change the hourly rate that we raise for every new client, as we get better and more requested.
2. Adding extra hours for tweaking we base on experience with the client and the fact how “far” we are from the decision makers in the proces and how quick and pricise they are in defining the task and their expectation. If it is a client, who’s bosses’ boss is going to be making the final decision, we don’t work with that client, or we have all the bosses approve every decision and mockup, because if we don’t, we know that they will question an early decision while testing the end product.
The price is going to end up being very hign and so the client get’s a chance to scratch a lot of features they requested, but don’t need. Sometimes the project shrinks to 50%.
We are also learning that every decision and request that comes up during the process of creation has to be solved, but for it not to be solved on our expense, we need to inform the client about the cost of what they are requesting. Then get an approval.
008—2008.10.07.14:13
And still, the only real question that remains at the end of a project for me is:
“Why the hell didn’t I multiply that estimate with 4!!!”
:)
It seems to me we’re still all just little toddlers playing in the sandbox with some “web” thingy. The only people that deliver web projects in time (that I know of) are those that produce “supreme shit quality” products. :)
009—2008.10.14.03:47
Kinda… but then again. Every design have to be unique - at least the impact part. There are some patterns which vary from designer to designer, and certain “styles” - but THE JOB is to make it:
1. unique
2. pweety
3. functional
… depending on the project, not always in that order :).
Designer is also the first target mostly, in good and in bad.
You have to make it functional. That is 3:1 in programmers favor.
If the thing is logical, it can be solved on a programming side.
If the thing is logical, its hard to tell if it can be solved (and when) on a design side, because sometimes you depend on the client’s visual taste. Getting around that requires mind probing, taste-o-meters and magical mambo-jumbo, depending on the client. Oh, and you have to make their awful logo bigger.
Programmers don’t have to worry if the client suddenly “doesn’t like the green color” even if their holy&mighty “BOOK of VISUAL STANDARDS” specify that color (10 goto MR), don’t have to fight the board of 8 people where 3 of them like typeface 1, 2 typeface 2 and 3 still fighting over the colors and they didn’t even looked further from that - they will enter the fray about that typo problem after they ask the designer to change the color 9 more times… and then we have the full circle again.
But anyway, I (as Mr. designer) don’t have trouble providing them with a quote. After some time in the business you are able to estimate requests based on the required work, client profile, your experience, your usual work flow and your free time.
MR: I make sure that they got it as an estimate because I’m not a bloody Mind Reader and if they change their mind more then usual (equals there is a decision board of more then 3 people, they change the features etc. / they deviate from the normal client work flow i usually do = they hired me because I’m good at what I’m doing, so they can’t question it), they will break those borders of estimate. And it will probably cost them more.
Nothing can be 100% predicted in this line of work… but there have to be estimates - for the client and for you.
Imho, if you cant get estimates out, you are nothing more then a code-monkey who depends on other people to tell them when and what to type. And as a code-monkey, you don’t have the rights to complain, because that was your choice.
In short: programmers mostly can do whatever they like in the back-end: they can copy/paste till oblivion and google almost any problem/solution - “nobody” will care how it’s done, if the Thing works. It’s a curse and a blessing in one - depending of the programmers ego :P.
Even more shorter: You guys are having it easier (i guess you are pulling your hair out on that statement), so grow some balls and after a SHORT research - spit out ESTIMATE.
Even even more shorter: i can do it, you have to be able to do it, too.
(hey, at least there is no red lines under my words :P)