Requirements gathering the first big mistake.

Previous installments:
IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Many seasoned project managers will start off a project by sending out his business analysis team to carry out requirement gathering.
Sometimes this is the right thing to do, in particular you should do this when you have a successful proven process that you want to automate using IT.  Requirement gathering then educates the IT people responsible for system design (the features) on what they need to achieve.
This is a different scenario, just think about it for a minute.  If we had the business case open and we had a succinct explanation of our goals and how success will be measured, would it not say things “like failing processes”, “lack of experience and knowhow” and would there not be talk of providing a new and better way and retraining people?

Here’s what actually happened. 
A Business analyst was hired to gather requirements and she went about learning how the business works and mapping all the tasks that people do every day. She was very thorough and presented it all back in neat UML diagrams with notes and she created a data catalogue to back this up.  An up and coming manager from the business then was appointed to find a supplier and deliver a system. He was instructed to report with final costs from shortlisted suppliers.

Off he went and began to invite various CRM vendors over to give presentations and answer questions.   They were given copies of the Business analysis in advance which some read and few paid much attention to.  Fairly quickly it became evident that this was a bit technical and he would have to rely on the vendors to keep him out of trouble and he quickly got it down to two people that he felt he could work with and asked them for quotes.  He had by now built relationships with these guys and they were advising him. The IT manager was also sitting on occasional meetings to make sure things were to his satisfaction.

He ruled out several vendors early on because their technology was not compatible.  He was a bit miffed that he was not in charge of this instead of someone who knew nothing about technology. It never crossed his mind that he knew nothing about business. He insisted on writing a features grid based on the business analysis and asking the suppliers to state whether they met all the requirements.

Eventually they chose a vendor that the project manager felt comfortable working with and that answered all the questions for the IT manager.

Perhaps this is a good place to finish this instalment and focus the attention on where we have got to from where we started.
We began with well defined business problems that required to be addressed urgently and which included lack of experience and know-how in the sales and marketing teams.  We ended up with a supplier chosen on the basis of the IT managers priorities and the Project managers relationship with the sales-rep.
Par for the course.
At this point the budget has a debit side exceeding £30k and that takes no account of internal staff spending considerable time away from the day job.

Next week we will look at the contracts negotiation stage
 About the author

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.