My colleagues often ask me why they did not achieve what they set out to do on project or how they could do better on future projects. In answering this question, it easy to spot patterns of mistakes that seem to occur and over and over. Let’s examine five common mistakes relating to the development and management of requirements.
1. Losing Sight of the Original Vision
While charging ahead with the requirements development and management activities on a long project it is easy to lose sight of the original vision and business objectives. This may occur because the goals change over the course of a project, project compromises are made or there is a change in the Project Sponsors. Because of this it is imperative that the project vision and business objectives be clearly defined and available for review by all stakeholders and project team members working on the project and integrated into review cycles thorough the life of the project.
2. Not Understanding the Business Process before defining Software Requirements
Systems projects are not intended for technology alone, they are undertaken to help automate business processes and make the business process more efficient. It is essential to gain a complete understanding of how the business process will work before starting to define software requirements that will automate the process. This complete understanding of the business process is important for both stakeholders and project team members. Often, stakeholders only understand the current process and do not understand the new process and so they provide user requirements for the current process instead of the proposed process. This results in “repaving the cow path.”
3. Not building what the stakeholders want
Too often, stakeholders are interviewed in a single session and are not kept informed on the final requirements or changes that are made to the requirements through the life of the project. It is completely unrealistic to believe that meaningful requirements can be gathered with a single one hour meeting with a key stakeholder. Requirements elicitation is an iterative and incremental activity; a single meeting with a key stakeholder will not work in terms of obtaining a true understanding of what the real user needs. It will most likely take a series of interviews from a variety of users at all levels as the requirements continue to be refined over a period of time.
4. Not Preparing a Requirement Management Plan
A Requirement Management Plan defines key activities for requirement development and management as well as roles and responsibilities. Key stakeholders, requirements analysts, development resources and project management should agree on the requirements document format and activities early in the project life cycle. The Requirement Management Plan should contain among other things:
5. Not Developing Requirements Iteratively
Most modern system development methodologies prescribe some form of iterative development. This is especially the case for Agile development methods such as Scrum or XP. Waiting until the requirements are ‘finished’ before starting development does not work for these methodologies.
Requirements should be gathered iteratively based on priorities and released to development team based on the development method used. For example, if the development team plans on delivering software in quarterly releases, then requirements should be released to the development team for each quarterly release. Releasing one comprehensive document for all requirements simply does not work for iterative development. Applying iterative methods for requirements development provides many benefits including:
