News & Views

October 2009 from IBM via ProjectTimes – These are the traps with descriptions and how to avoid them in the linked article:

1. Scope creep
2. Asking customers what they want
3. Inability to adapt to change
4. Failure to communicate effectively
5. Failure to communicate frequently
6. Unwieldy documents and too much information
7. Hidden project artifacts
8. Ambiguous requirements
9. Failure to measure and assess requirements processes
10. Isolating your requirements

180 View – Although the article was written for getting requirements for software development, it also applies to getting requirements for a software selection project. The key difference between requirements definition in software development and software selection is in the level of detail.

One would not expect “asking customers what they want” to be a trap. The article claims that “customers tend to talk about features, not what they truly need. The truth is that people often don’t know what they want.” The article says the solution lies in asking customers why they need a particular solution. I agree with the problem but not the solution. It would be better to ask the customer to describe their existing business process and its problems. In this way, the customer exposes the strengths and weaknesses of the existing system, and the business analyst can suggest alternative ways to solve the problems. The business analyst should know what is possible in software development and what is possible in existing systems but also needs to understand the business impact of a particular problem. There is no point in creating or implementing an expensive solution to a problem that causes a few minutes to be wasted a week for one person even though the customer finds it annoying.