In It is often said that 80% of all enterprise projects that fail, do so because of basic flaws that occur at the time of defining project requirements. Numerous instances can be cited when the project, on completion, turned out to be fairly different from what was desired. The reasons, more often than not, lie in the ambiguous and unclear project requirements formulated by the team.
Here is a compilation of the most common errors while creating a project requirement document, and the best way to avoid them.
Inefficient communication
Misinterpretation is, by far, the biggest culprit behind the creation of wrong project requirements. It can start from the top, says Surendra Kapur, a senior business IT analyst with a leading financial services companys India unit. The CTO or the CIO knows what he wants out of the IT project. But he does not have the time to spend with the delivery team and work out details. So he assigns a senior IT manager to look after the project and conveys his vision to him, Kapur explains.
The senior IT manager then tries to make sense of the vision to define what is required from the project. This is often not congruent with what the CIO has in mind. If the CIO is involved in intermediate discussions, then the gaps can be sealed early enough. However, if the top stakeholders come in at a later stage a lot of effort may have been made on the basis of the senior IT managers briefing.
Sometimes, a customer may not even have complete vision of what is required. He may have ideas that could evolve as the business analyst probes about the business and its various processes. The analyst will have to be skilful enough to not just balance technology with solid business sense, but also be extremely good at eliciting information from various stakeholders. If this does not happen the IT project can land in a mess where must-have features turn into optional ones, and a debate starts on change requests.
Generally, there is an attempt to obtain requirements by asking customers or users what they want. Naturally what is actually provided is a list of wants instead of needs, says Shivshankar Singh, DGM (Operations & Trading) at BSE India.
He reiterates that there is no actual process for requirement gathering in majority of Indian organisations, or it is limited due to time constraints, forcing the analyst to accelerate interviews and information-gathering sessions to capture the bare minimum information and then attempt to interpret what the user needs.
The result, he adds, is incorrectly stated requirements, missing requirements, unnecessary requirements, too many requirements and unclear requirements.
Agrees Mohan Verma, Executive Director at PricewaterhouseCoopers when he says many times the definition of certain terms is not clear, and hence there could be a difference in their interpretation by the user groups.
For example, when one talks about customisation in ERP projects the definition is not clear. Both sides could be responsible for confusion. While the solution-provider, in his enthusiasm to push the sale, may keep some aspects of the scope blurred, the client, in his bid, to contain the cost may do the same, he explains.
Inadequate scoping
More often than not, during a pre-sales cycle while doing a scoping study, there is only so much one can do. It is only when you actually get into delivery and start getting into the details that you realise that many aspects of the scope have not been covered.
Add new comment