Friday, January 21, 2005

Requirements Management

I've been lucky enough in this role, to observe management, dealing with a 3rd party software vendor - a relationship that was in place before our IT department was even conceived of - and watch as both this vendor falls for most of Steve McConnells classic mistakes - see Rapid Development - but one, more than any other, has been their failure to document and clarify requirements before charging ahead and diving into the development cycle. What has resulted is a "code like crazy" style reactionary environment, with our users (the customer) unhappy, but not sure why.

One of the most obvious was after a recent discussion with our customers about their requirements, it was realised that that the system being developed was not really heading in the right direction.

We have just begun building a commission management system ourselves, the customers being that same group of guys involved in the frustration with the external software vendor. In an attempt to learn by their mistakes, and also introduce the business guys to my idea of project and development lifecycles, I produced one of my usual, fairly detailed but readable product requirements overview. It was written from my understanding of the requirements as gleened from general discussions and some experience in the field. As you'd expect - as an IT guy, I missed quite few points. I managed to get the message across to the business, tactfully, that I didn't want developers to start coding, until they had requirements that were signed off by the business. The GM agreed and set about reviewing the document.

After a few days, when the GM passed by my desk, I asked how he was going with the requirements document. He looked a little sheepish and admitted that "gee these things really grow once you start thinking about them don't they...". It was an innocent enough comment but I think he was realising the point of the excercise. The other project was reeling on, semi-out of control - in a cycle of code - fix - code some more - change - fix. Here, was had just saved several iterations of the out of control development they were seeing from the other guys. We'd saved money, frustration and credibility right there. Yes, we'll have our own issues, bugs, mis-communications once development begins in earnest, but at least everyone, developers, customers and management are on the "same page" and we'll already be - subconsiously even - on the "same team".