Abstract
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.
Introduction
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
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
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
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.
Requirements Analysis
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
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.
Collect Requirements—A New Project Management Process in PMBOK® Guide, Fourth Edition
Collect requirements is a new project management process in the PMBOK® Guide, Fourth Edition. Collect requirements, defined in the PMBOK® Guide, Fourth Edition as the process of defining and documenting stakeholders’ needs to meet the project objectives, embodies the seven requirements management processes previously discussed. Inputs, tools and techniques, and outputs for the collect requirements process are shown in Exhibit 2.
Exhibit 2: Inputs, Tools and Techniques, and Outputs for the Collect Requirements Process
Formal Project Management Methodology
Formal methodology and standardized tools/infrastructure are two additional top reasons for project success. However, even though a formal project management methodology is well-described in the PMBOK® Guide, developing one that serves the needs of all projects in an organization is not a simple matter. Although all the nine project management knowledge areas described in the PMBOK® Guide should be utilized in a formal project management methodology, it should also allow for some flexibility for smaller projects that need less rigorous application of the project management methodology.
For example, a minimum project management methodology may include the processes shown in Exhibit 3.
Exhibit 3: Minimum Project Management Methodology
Project reporting methodology should also be tailored to allow flexibility for smaller projects. Exhibit 4 shows an example of how frequency of regular project status reporting can be tailored for smaller, less risky projects.
Exhibit 4: Flexible Project Reporting Methodology
Standardized Tools and Infrastructure
Although developing a formal project management methodology can be a tremendous challenge, implementing and standardizing the methodology can be a bigger challenge. Yet, a formal methodology that is not fully utilized throughout the entire organization is not very effective. A standardized set of tools and infrastructure will help a long way in implementing and standardizing the project management methodology—a great leap toward an organization-wide project methodology.
This is where the concept of the PMO comes into the picture. The PMO concept has become a very popular project management practice. Organizations of varying sizes, from midsize to multibillion-dollar businesses, utilize a PMO in various aspects of project management. The PMO can effectively serve as the center of excellence for best practices in project management—providing training, mentoring, and coaching in project management, as well as project/program/portfolio management methodologies. The PMO has become the choice for the centralized organization to provide and implement project management tool suites.
Organizations that utilize the PMO as the standard infrastructure to implement projects and programs benefit by having the PMO perform the strategic role in driving predictable project execution by embedding project management best practices, including requirements management processes and formal project management methodology and tools, in delivering successful projects consistently.
Executive Management Support
Executive management support is a critical success factor. In some cases, it can make or break a project. Executive management support definitely improves an organization’s project success rates.
However, for many reasons, it is not easy to gain executive support, let alone sustain executive commitment. Many projects/programs compete for executive management’s attention, involvement, and support. Although the project management team focuses on the project contributions to organizational success, executive perspective is much broader than the project management team’s perspective. Sometimes executives are not even accessible to the project management team.
The project management team should treat executives as “special” stakeholders, get the executive management involved in project activities as much as possible, and sell their project to executive management.
Project sponsors in executive management position are special stakeholders. The project management team should:
- Understand and document the executive management’s definition of project success and delivery priorities
- Get the senior and executive management involved in requirements management
- Understand requirements and expectations of senior and executive management
- Get executive project sponsors to participate in risk analysis and risk mitigation planning sessions
- Develop a project communication plan that focuses on specific communications requirements of senior and executive management.
Selling projects to executives can be very difficult but can be the most effective way to get executive management support. Some selling techniques may include:
- Understanding how the project fits the organization in terms of operational and strategic goals
- Explaining how the project contributes toward achieving long-term operational and strategic goals
- Emphasizing business results and organizational value, relating project results to organization’s key business priorities.
The following familiar project management tools can be very effective selling tools:
- Business case, including a cost-benefit analysis
- Project charter
- Project kick-off meeting agenda
- Project risk management plan
- Project scope management plan
- Roles and responsibilities matrix, including executive sponsor responsibilities.
Conclusion
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.