There is a tension between the need to keep project requirements simple and concise and the need for complete and thorough definition. For smaller projects, it is best to limit the number of business requirements to five or ten if possible. This has a number of advantages. People are able to clearly remember and act upon only about ten tasks or goals from memory. More complex lists require constant reference to a written document, which makes deviation more likely.
How can larger projects, which often necessitate hundreds or even thousands of distinct and concise business requirements, be simplified without losing important information? Several approaches are available to structure projects so that the requirements remain simple, fresh, and immediate without losing vital information needed for project success.
It might be advantageous to organize a project with thirty requirements into a portfolio of three subprojects with ten requirements each. This is especially useful if the project requirements can be neatly grouped by common subtopics. Under these circumstances, all three projects may be managed by a common project manager, with separate technical team leads for each of the three subprojects.
Many organizations make use of phased project management. This strategy breaks the project into subprojects with separate requirements and measurable deliverables and then executes the projects sequentially. Ideally, the phases are organized so that the most important requirements are met in the first phase. Succeeding phases address groups of requirements in descending order of importance until the project is finished.
The advantage of phased project management is that the project team can focus on a limited number of requirements, and the stakeholders are able to evaluate preliminary results to determine whether the project is on track and the requirements are still valid. In addition, if the project must be terminated early, the most useful solutions were delivered up front, ensuring the best return for the amount of time and effort put into the project. This makes it easier for the organization to change its spending patterns quickly by canceling or delaying less vital project phases.
Iterative project approaches develop the solution while the requirements are being developed and refined. This class of methodologies includes variations known as spiral, rapid, and radical project management.
More Info
See Chapter 3, for more information on process models.
The less information gathered prior to development and the more hectic the development process, the cooler the methodology’s name. Presumably, a project methodology performed completely in ignorance, in a darkened room, without food or water, would have the coolest name of all.
Iterative project methodologies continue to gain popularity with development teams for a number of reasons. Most importantly, technology development tools increasingly use object-oriented technologies. At a very high level, object-oriented technologies allow development teams to use self-contained programs known as objects to develop solutions. Objects can be quickly assembled into unique configurations and combinations. They can also be quickly recombined and rearranged into other configurations in response to shifting requirements.
Similarly, the ability to develop user interface screens by recombining graphic elements and then linking them to underlying software objects has made it possible to quickly develop a prototype solution from even scant requirements. In an iterative context, the technical team might first create user interface screens based on the information gathered from the business stakeholders. After reviewing and refining these screens with the business stakeholders, software objects and other modular tools may be added to gradually create a solution to fulfill the business stakeholders’ requirements. In an iterative methodology, changes in scope and requirements are not treated as enemies of the project—rather, they are seen as an integral and organic part of the process.
The business stakeholders and technical team gather just enough requirements to develop the first prototype screen or function, and then more requirements are generated from discussions about this first deliverable. If this process is guided by the standards and best practices defined in a technical strategy, then the solution will integrate into the larger computing environment when it is declared complete.
Iterative methodologies also recognize that a solution is never truly finished, and the project ends when the evolving solution is declared "good enough" by both the technology and business stakeholders.
It is also possible to develop some aspects of the solution using an iterative approach, some in parallel and some in sequence. This places a much larger burden on the project manager, but it often has the best results. When fulfilling a complex system of requirements, it is often true that some groups of requirements can be met using an iterative approach, while others require a systematic and laborious effort accomplished in concert.
The ability to employ a hybrid methodology in meeting complex systems of requirements hinges on the use of a mature technology strategy. The technology strategy is necessary both in determining which methodology best fits the solution set and in making sure that the component solutions can be successfully integrated with each other and the larger computing environment.