I've landed my first contract (hooray, self employment!) and the company is asking for time estimates.
Programmers are notoriously bad at time estimates, and I know I've been laughably wrong before. It's fixed bid, so I'm not concerned about charging. I'm just concerned about expectation management.
So far I've itemized the work I need to do, estimated the time it would take, then significantly padded that time. I'm still nervous about it, though. Is it acceptable to write in time for "unexpected delays"? I've estimated 4 weeks, and I'd like to add a 5th week for problems I haven't thought of. Is that something people do? Would you balk if someone gave you an estimate with that in it?
Best Answer
First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice.
In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the project). However, you should NOT specifically put it into the plan as it's own line item -- as then when you need it (and you most likely will), it only makes you look like a bad planner, and by definition you will be behind schedule.
There is a motto you live by: "Under-promise and Over-Deliver". Set expectations (in this case delivery time) low, but not so low that the client would be put off, and then beat the timeline (and demonstrate that you are ahead of schedule).
Instead, of one contingency block at the end of the project, you should distribute contingency planning throughout the project. Assuming you haven't already committed to delivering in your estimated 4 weeks, suggest and plan for 6, with your planned 4 weeks of effort spread out evenly over all 6 weeks. This will make you, and your client much happier, as you should generally be slightly "ahead of schedule" throughout. :)
Important: You should plan progress updates / partial demos on a frequency that: 1) mitigates the risk of building what they asked for but not what they want 2) builds customer confidence while not being overly burdensome on you. Be SURE to plan for this time working with the customer, giving demos, tweaking things, etc.
In a project of that length, that is most likely every three days or so.
Finally, when you are planning the work, front-load the most "risky" or "unknown" items first and plan the most contingency for them. Risk takes many forms -- and it's most often not the technical stuff. Generally, the biggest risk is that the customer doesn't TRULY know exactly what they want. You want to get stuff in front of them early and often to ensure you are in alignment. This means prototypes, mockups and such. If there is misalignment or misunderstanding, you want to find it as early as possible! Generally, if you find this out very early (before significant work has been done), you can renegotiate the contract to work for both parties. The biggest mistake freelancers make is delivering what the customer asked for, but not what they want. You need to understand that you are responsible for ensuring that both parties are the same page.
On riskier technical items, do enough of a proof-of-concept early so that you know you won't crash into a roadblock late in the game. Fight the tendency most people have to focus on the stuff they already know to "build momentum".
Have fun with it and I hope this helps. If you would, let us know how it went after you complete the project. Good luck!