Quality Assurance and Project Management

Apr 16 2011   9:22AM GMT

Most Of Software Delays Are Because Of No Proper Requirements Gathered



Posted by: Jaideep Khanduja
Tags:
development phase
implementation phase
project gap
project management
project phase
Project Risk
requirement gathering
requirement phase
Software Project
testing phase

Most of the times the software delays are because of no proper requirements are gathered. Reasons of this could be many like lack of business knowledge of Requirement Gathering Team leaders, lack of experience, inappropriate allocation of time, wrong choice of customer representatives for understanding of business process and requirements and so on. In such cases the level of documentation remains below standards howsoever good may the expertise in documentation be.

Documentation of requirements apparently may look very systematic and structured in first go but once project teams start working for development and testing etc. they start finding out so many gaps and holes in the document showcasing a bumpy road ahead calling for repeated sessions of business understanding from customer and rebuilding of documentation.

Biggest fear in such cases is that if this stage crosses development and testing phase without any hiccups, it definitely does not ensure a healthy situation ahead. Rather it ensures that a volcano or tsunami was in the making during earlier stages is definitely about to erupt or break out soon during rest of the stages. And it could happen anytime.

UAT and implementation stages are most vulnerable stages in such situations where the hidden volcano bursts out when customer business process owner shouts out a flaw in software built to address to their business requirements. Those hidden major gaps unaddressed properly during Requirement Gathering Phase now spell out wounds badly on project.

That is why most of us agree
that the most crucial phase of any project is Requirement Gathering Phase. If this phase is not addressed to in a micro level analysis manner, it may cause harm later to project, teams and managements.

Best way would be to vet and validate user requirements twice or even thrice spending a little time extra in beginning rather than asking for a higher amount of critical risks at a later stage.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: