"Hello. Is that the garage?"
"Yes, it is. Good morning. How can I help you?"
"I'd like to buy a car, please?"
"Great. We'd certainly be pleased to help you with that!"
"Oh good. Can you tell me how much it will cost?"
"Er..."
Well, OBVIOUSLY, you wouldn't go into buying a car like that (although I have in the past wished that you could!).
Of course, what you would actually do is tell the garage your requirements. Some of those might be quite specific: you might want a diesel engine or a sunroof. You might also provide a bit of background information, such as the fact that you have three children. This will give the salesperson an opportunity to add some value, as he (or she) might ask, for example, whether you want rear doors with childproof locks on them. And, of course, no sale would be complete without an attempt to sell you a few bits and pieces that aren't strictly necessary, like alloy wheels.
I'm mentioning all this because this current instalment in why IT projects fail concerns the Business Analysis stage. Now this isn't strictly sales - that's where my analogy breaks down - but a good business analyst will collect information not only about your specific requirements but also your business.
This enables the analyst to do three things: firstly to contextualise your requirements. Secondly to bring their experience of similar companies and projects to bear and thereby add value. And, thirdly, to ensure that the development fits in with your requirements strategically. After all, there's no point in buying a five-seater if your family is expecting a fourth child!
So, a business analyst needs to be a good listener. They need to ask you about your business, where it's come from, what it's doing now and where it's heading. The analyst needs to understand what systems the company uses now and whether any new software will be required to integrate with them.
Next the business analyst needs to listen to your requirements, using their experience to understand whether what you're asking for matches your stated intentions. Here their experience of other projects and companies will be of value, possibly preventing you from making mistakes and helping you to benefit from the experiences of other people.
The business analyst should also be able to make suggestions about what other options you might want to consider doing that aren't currently part of your plans. The cross-pollination of ideas across sectors is not always obvious but a good analyst will be able to spot them.
Once you have had this meeting - or possibly meetings - the business analyst should provide you with a business requirements document, which should detail the scope of the project and the requirements that you want satisfied, whilst also recording any discussions around future development. The document might include some design work but, really, it should be a summary of your business requirements.
Once you've approved this document, the company for whom the business analyst works should be able to give you a reasonably accurate estimated cost for the work. However, I wouldn't expect them to quote for the project until the more detailed analysis is complete and it wouldn't be unreasonable for their company to expect you to pay for this detailed ("systems") analysis, which will take days or even weeks. Next time I'll write about systems analysis and that stage of the project.
I think it should be fairly clear from what I've written here just what the issues are that might arise if the business analysis is not done properly; a client who ends up with a system that is not right for their business.
