Fri, 14 May 2010
Project Work and Crazy Expectations
I've never been a fan of detailed or formal requirements docs for software or other projects, as I've found the customer's needs always change and sticking to a pre-made list is impossible. But there has to be *something* to start with, something reasonably detailed enough to make an estimate (and I recommend doubling that before telling the customer). I got an email from a potential client recently:
"...help me in setting up an already purchased server, programming of some modules in Perl and handling in cron jobs for one of my projects. I would appreciate a quick turnaround time."
Apparently, this was enough detail to come up with a fixed-bid estimate - even after I challenged and asked for more detail.
Another example - a friend of mine wanted me to develop a web-based, database enabled app with user, admin and reporting interfaces, calendaring and email hooks. This was supposed to be an easy project I could put together one night, in my spare time.
Sometimes conveying the scope of a project is hard. Hidden from the casual user is how a software app works under the hood (all-too frequently behind a web browser). When you've been doing project work for a while, you get a sense for where the pitfalls and time-sinks lie, it's just hard getting clients to see them. I'm sure I've heard this analogy somewhere before, but projects like these are like icebergs - the part you see is just the smallest part. Unfortunately, to your clients, this part is all that exists.