Tuesday, January 06, 2009

The way we screw requirements up.

My previous job was at a small software firm. They had no software development process at all. There was couple of people who mainly interacted with the customer to get the requirements. They spend few days with the customer discussing; and then sit with the developer for half an hour and ask him to write it! No documentation; no diagrams; no nothing. Write this. Once in a while they’d check what’s going on; show the customer what’s going on and change few things here and there and that’s it!...

Needless to say; we never made correct estimates; we never delivered what we initially thought the system was and very little number of customers came back. The applications were not designed at all. They were ad-hoc code with only the blessings of the skills of the developer.

That sucked… So I joined this company which has a pretty matured software development process. It defines how to capture requirements in different scenarios and conducts periodic audits to make sure that everyone is on track. Pretty neat eh? This all works well when everyone involved in it is committed and competent (almost all committed people are competent and almost all un-committed people are incompetent. Once in a while there’s a committed but incompetent person and a competent but un-committed one.)

But requirement capturing was a nightmare in the last two projects I worked in. Why? Some smart-ass thought anyone with CIMA or a MBA, who’s fluent in English, could be a BA. They simply didn’t know reasoning or probability. They just wrote what they heard. (I’m pretty sure they didn’t understand a thing what the customer wanted. But they didn’t know how to ask a question so that there won’t be ambiguity)

So what’s the end product? A big pile of documents that has no value at all and several wasted months (this is no small deal; one project had two BAs who wasted three months and the other had 5(!) BAs who wasted 10 months!!).

So; to think of it; the first company did less damage to the customer and the developers than the second.

So what really works?
A requirement capturing process practiced by professional BAs or Software Architects. That works really well - I’ve seen that. So; if you have any stake in a software project, make sure that you are talking with someone who’s capable of translating your requirements in to something that developers understand. Otherwise you’d just be wasting time and money - a lot of it (those 5 BAs wasted at least about US$1 million).