Poor Requirements Portend Project Failure.

You need not been so technically skilled to be able to see how many project fail due to requirements.  We provide a brief list of the failings below:

    • Requirements control
    • Insufficient time
    • Did not include the sponsor or customer
    • Late delivery of requirements
    • Requirements traceability

We will not write any more on requirements control that is addressed in our other blog posts.  

Insufficient time spent on the requirements gathering is another area of failure.  In our haste to deliver the product we may perform little exploration of the use of the product.  We may have an over reliance upon standards. We cannot build a suitable product if the standards do not address the real world complexities of our application, and many do not. The scope of real world is beyond what can be boiled down to standards in many cases. Standards should be used with a jaundiced eye recognizing these limitations.  Standards help us reduce the time to develop the standards but are double edged sword that can cut us.

We do our sponsor and customer a disservice when we do not include them in the specification work. These people may not be able to speak the technical jargon; however, they are the people who will be the end user of the product.  Learning as much as you can about the application is essentially THE requirements.  Additionally, we will no doubt be contractually bound to meet the sponsors desired end result.

We have been in many projects where the requirements phase consumed so much of the time that the remaining product development time meant certain failure.  This often follows hard with we have no time to document the requirements now – we must work word of mouth.  This is a spiral to a very bad place.  The prioritization of the requirements we have discussed previously can help here.

Requirements traceability is coupled arm-in-arm with our configuration management. When we are unable to trace the requirements back to the scope of the project we are unable to efficiently close any project contract, as by definition closing the project is closing contract (meaning make sure all contractual obligations are accounted).

Post by admin