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:
- Requirements gathering methods (interviews, vendor reviews group meetings, observation, etc.)
- Format of the requirements documentation including various techniques to be used such as use cases, user stories, etc.
- Various types of requirements visualization techniques to be used (business process maps, UML diagrams, wireframes, whiteboarding, etc.)
- How the requirements will be traced and used in various project activities such as design, system testing, and user acceptance testing.
- Change control approach – how will requirements changes will be approved and communicated to the project team
- The requirements format must also be agreed to by key technical staff to ensure there is no resistance to the structure or contents later in the project.
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:
- Requirements are abstract, and it often takes a real working system for stakeholders to see and experience before they can confirm the requirements are correct.
- Requirements will get much better in subsequent releases after retrospectives are conducted and stakeholders have a better understanding of how the system and the process will function.
- Developers can start work earlier in the project lifecycle and deliver the final product earlier.
- Project management will get early feedback on the feasibility and quality of requirements from the development team.