Although many successful project management practitioners are “accidental project managers,” successful projects should not be “accidental.” Research studies have identified reasons for project failure, as well as the top 10 reasons for project success. By capitalizing on the major contributors to project success and avoiding the leading causes of project failure, project success should be a predictable and repeatable event, instead of a hit-and-miss occurrence.
This paper focuses on three major contributors to project success: requirements management processes, a formal project management methodology, and standardized tools and infrastructure to implement project management and executive management support—as the key ingredients to CONSISTENT delivery of successful projects.
Project management practitioners world-wide use Project Management Institute’s (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 2008), as the primary source for best practices in project management. Organizations utilize the project management framework, as well as best practices in project management to help improve their project success rates. Meanwhile, research studies continue to point to poor handling of project/product requirements as a leading cause of project failure. Furthermore, research studies (Johnson, 2006, p. 3) on project success have identified the following project success factors:
1. User involvement
2. Executive support
3. Clear business objectives
4. Scope optimization
5. Agile processes
6. Project management expertise
7. Financial management
8. Skilled resources
9. Formal methodology
10. Tools and infrastructure
Following the approach of capitalizing on the keys for project success, this paper recommends the following for consistent delivery of successful projects:
• Implement requirements management processes, in collaboration with stakeholders
• Develop/institutionalize a formal project development/management methodology
• Implement standardized tools and infrastructure through a program management office (PMO)
• Ensure executive management support for your projects.
Requirements management processes, implemented in collaboration with the users and the sponsors, will contribute to three of the top five reasons for project success, as given above (#1, #3 and #4). In addition, focus on formal project management methodology and standardized tools and infrastructure, and on executive management support will cover the majority of the top 10 project success factors that could lead to a tremendous boost to an organization’s project success rates.
Requirements Management Processes
Requirements management includes processes for planning, gathering, defining, refining, organizing, documenting, prioritizing, testing requirements, verifying that requirements are being met, and tracking and controlling requirement changes.
Requirements management involves all seven requirements processes shown in Exhibit 1: Requirements management processes—requirements planning, requirements development (which includes requirements gathering and elicitation, requirements definition, and requirements analysis), requirements verification, and requirements change management.
Exhibit 1: Requirements Management Processes
Requirements planning is the process that involves the development, review, and approval of a requirements management plan. The requirements management plan must document all requirements processes to be performed as part of project development. It must include stakeholder identification and analysis that specifies stakeholder roles and responsibilities that clearly defines how stakeholders are being involved in the project. The requirements management plan must be reviewed by all appropriate stakeholders, including customers, business users, (development/design team leads/managers), and approved by project sponsors and key stakeholders.
Requirements development consists of requirements gathering and elicitation, requirements analysis, and requirements definition.
Gathering and Elicitation
Requirements can be either known or unknown. The purpose of requirements gathering is to collect as many known requirements as possible. The process of requirements gathering is both critical and difficult (Phillips, 2000). Although it seems straightforward to gather requirements from users, record and document the information, it is often difficult to get accurate and organized information. Information may be provided in different forms (e.g., via e-mail, one-on-one interviews, telephone messages, meetings) and in different formats (e.g., in documents, in a database or spreadsheet format). Clarifying, organizing and prioritizing the information can be a very time-consuming and daunting task.
The purpose of elicitation is to identify the needs and constraints of various project stakeholders (Wiegers, 1999). The results of this process are a common understanding among the project stakeholders of the users’ expressed needs.
Requirements definition is the process of organizing, documenting, defining, and refining requirements. The requirements definition documentation (RDD), sometimes referred to as “requirements specifications,” is a documentation of the product requirements. The approved RDD (also called the requirements baseline) is a documentation of the agreed-upon product scope. It is considered a contract of the product to be developed between the business users (sometimes represented by the product sponsor) and the product developers.
In cases where development of the product is outsourced to an external group or organization, requirement definition is an integral part of the statement of work (SOW) (Kerzner, 2003). As with any contract, the RDD must be documented in great detail and must be signed by proper stakeholders. Although expected to be very detailed and well-understood by all stakeholders, requirements must define users’ needs—what is expected from the product and not how the users’ needs will be addressed in the product. Developers need to understand the requirements fully (what the users’ problem is) to be able to develop the solution (how to fix the problem). It is common practice to use an SOW template within an organization.
A standard template that defines functional and non-functional requirements, constraints and assumptions is useful tool for documenting and reporting requirements. A number of system/software tools (Visitacion, 2003) are commercially available for organizing, prioritizing, and reporting requirements. A work breakdown structure (WBS) is a common tool in identifying all product deliverables. A WBS defines the work deliverables in sufficient detail such that each deliverable component can be managed easily (in terms of cost, quality, and schedule). The IEEE Standard 803-1998 Recommended Practice for Software Requirements Specifications (IEEE, 1998) is sometimes used as a template for requirement specification in software projects. Many organizations start with a template commonly used in the industry, and tailor the template to the needs of the organization.
Closely tied to requirements gathering and elicitation is requirements analysis. The purpose of requirements analysis is to discover unknown requirements, i.e., to turn unknown requirements into known requirements. Users’ needs that were not expressed during requirements gathering and elicitation can be uncovered through requirements analysis. It is beneficial for the project if unknown or missed requirements are discovered as early as possible in the project life cycle. This will minimize the cost impact of requirement changes.
Requirements verification is the process of ensuring that all stated requirements are being satisfied. This process is performed throughout the requirement phase of the project life cycle. It includes an analysis of how the requirements are being addressed in the development plan, as well as user acceptance testing and validation.
Requirements Change Management
Requirements change management (RCM) involves the implementation of a (requirements) change control system consistent with an integrated project change control system, and managing the actual implementation of changes (approved change requests). RCM goes hand-in-hand with the requirements development and requirements verification. It is an essential component of requirements management. The requirements management plan is an input to this process, and must define the critical components of the RCM, including the change control system, the change control board as the controlling and deciding body for handling change requests, any exceptions/limitations of the process, and any permissible deviations.
Effective Requirements Management
An effective requirements management process must involve all the requirements processes previously defined. Not one of these processes is optional in ensuring that all requirements are well-understood, known early enough in the project life cycle, addressed in the development plan, and satisfied in the final product.
To utilize requirements management processes most effectively, each process must be well-defined. The deliverables of each process must be determined, as well as its inputs, tools, and techniques that will be employed to produce the process deliverables (its outputs).
There are many tools and techniques that can be used for these requirements processes, including system/software tools for organizing and documenting requirements, templates for defining and reporting requirements, gathering and elicitation techniques, testing and verification tools, and change control system tools. The most useful tools are those that encompass all the processes just mentioned, and those that are employed when the requirements processes are implemented as formal standardized processes with defined inputs, tools and techniques, and outputs.
Performing some of these processes as requirements activities, not as formal standard organizational processes, does help improve project development results but does not address all requirement issues in the project.
Project management practitioners are accustomed to following processes that have well-defined inputs and outputs. They tend to look for usable inputs before implementing the process and templates for the outputs and other tools/techniques to employ in producing the process deliverables. The project management team must provide an associated formal standard organizational implementation for each process.
Successful projects should not be “accidental.” Project success should be a predictable and repeatable event, not a hit-and-miss occurrence. To consistently deliver successful projects, the project management team needs to capitalize on major contributors to project success and avoid leading causes of project failure: utilize requirements management processes, a formal project management methodology. and standardized tools and infrastructure to implement project management and ensure executive management support and sustained executive commitment.
Although not one of these is easily done, these practices will definitely improve project success rates—a great step toward delivering successful projects…every time.
You can attend our Online Certified Associate Project Management Training facilitated by our trainers who have more than 15+ yrs. of training and industry experience.
MSys Training is the markets-leading learning services company. Our customized training solutions are efficiently tailored to meet organization and individual goals. With various training formats, technologies, and approaches, we recognize the need for custom solutions that fit your company’s systems. MSys Training is highly recognized for its global expertise on trainings to co-create significant business value.