One size does not fit all: Choosing the right project approach

Abstract

Within the last ten years, agile project management has gained popularity as a means of effectively dealing with today's project uncertainty. Now, agile project management is often touted as the de facto standard for executing projects. Has agile become the “one size - fits all” approach to managing projects? The nature and characteristics of the project must dictate the type of project management approach to be taken. This paper will present a project assessment that should be considered when choosing the right project management approach. The project assessment focuses on defining the project team's strategy for planning and executing the project. Choosing the right project approach involves selecting which project management practices the project management team should perform based on the specific, high-level project characteristics gathered from the project charter and other related environmental factors to adequately plan and execute the project.

One Size Does Not Fit All

Every project is unique. Some projects are relatively straightforward and predictable. Others are highly complex and risky. Each requires a different approach when it comes to how the project should be managed. Applying the same amount of project management rigor to every project is wasteful. Despite this, many organizations and project managers apply project management dogma without deviation instead of tailoring their efforts appropriately. Cobb (2011) argues that one of the risks in managing a project is if the project manager is knowledgeable in one particular project management methodology, it is difficult to step back and consider an entirely different approach. Project managers often attempt to force a project to fit a given methodology because that is what they are most familiar with. Project managers need to expand their thinking to embrace different forms of project management. The project manager along with the project management team should tailor the project management approach to fit the business environment, the risks, and the complexity of the project.

For new and experienced project managers alike, it is hard to know how to approach the project. Many project managers are strict disciplinarians when it comes to which project management methodology they apply when managing a project. Some organizations have their project management office establish the policies that standardize all projects, while other organizations allow the project team to choose and tailor the most appropriate approach for their individual project. Some project managers choose a specific project management methodology and demand compliance from beginning to end, regardless of the project's size or complexity. Others choose a less rigorous approach and hope for the best.

Forcing all projects into the same detailed framework regardless of actual need is a common problem in choosing a specific project management methodology. From a traditional project management perspective, there can be a tendency toward excessive planning, which can drive a project into the ground. At the other end of the spectrum are those who feel that any form of project management is a waste of time and can stifle a project before it begins. Somewhere between over-relying on project management and rejecting all project management is the correct approach for managing a specific project.

Project managers along with their project teams must identify among the numerous project management processes and practices those that are most appropriate for each project. Each project management process should be carefully considered to determine if it is applicable to the project. Today, a project's approach should be developed to reflect the uncertainty that many projects face. Developing a project's approach recognizes that all projects are not the same—requirements will likely change, schedules are compressed and often come with imposed deadlines, budgets are limited, and stakeholders will have varying degrees of involvement.

Project Categorization System

Today, most organizations manage a significant number of projects. Ten years ago, the consensus was that the application of project management processes and practices was the same on all types of projects. Recently, research has shown that different types of projects require different approaches and competencies for their management. Large, complex, high-risk projects need a different approach compared to smaller, simpler, low-risk projects. The purpose of a project categorization system is to aid in determining the approach used for managing the project.

The basic premise of a project categorization system is to provide comparability between projects (Crawford, Hobbs, & Turner, 2005). A project categorization system identifies significant differences that exist between projects. To accomplish this, projects need to be classified hierarchically for the purpose of determining which project management practices are best suited to the different types of projects. Comparability makes it possible for the project manager and the project management team to draw on the lessons learned from similar projects and apply the proper level of planning and control. This aids in determining the approach for completing the project.

Elements of a Project Categorization System

There is a wide variety of elements used in establishing a project categorization system. The elements should be specific to an organization, its business environment, and its history. In some industries, the business landscape changes quite often and these elements change quickly to capture new business conditions, new understandings, and new meanings. In other industries, such as construction, the elements change very slowly. Over time, a project classification system becomes “naturalized,” meaning the organization, project manager, and project management team understand and use these elements without questioning. The following are elements of a project categorization system that can be used to classify projects.

Product category – What industry does your company operate in?

Starting a project categorization system with product category may not seem obvious because it is often taken for granted, which makes it difficult to see. The product category can be associated with the industry your organization operates in. Understanding the industry and its market dynamics and emerging trends will provide a background for developing innovative end products that help your organization stay competitive in its industry. Defining a product category can be based on established industry classification systems, such as the North American Industry Classification System (NAICS). The NAICS (naics.com) is the standard in classifying business establishments for the purpose of collecting, analyzing, and publishing statistical data related to the U.S. business economy. Exhibit 1 includes examples of product categories based on industry sectors.

Exhibit 1 – Examples of industry classifications that can be used to define the product category

Each of these industry classifications can and should be subdividied for further granularity. For example, construction could be subdivided into commercial construction, industrial construction, and residential construction. Each of those subcategories could be further broken down for further granularity. No classification system is inherently better than another. The only measure of success of a classification system is its value. Different people or organizations may have different ways to label their product category, so what works for one individual may not work for another.

Product life cycle – What stage is the product?

Exhibit 2 – Comparison of the product life cycle and the project life cycle

All products have a life span, called the product life cycle. A product life cycle is a series of stages that represent the evolution of a product, from the introduction stage through the growth stage, the mature stage, and the decline stage. In reality, very few products follow such a prescriptive life cycle. The length of each stage varies, and not all products go through each stage. Each industry has its own perspective on its product's life cycle. In Exhibit 2, the addition of the ideation stage and the development stage illustrates the comparison between the product life cycle and the project life cycle. The development stage consists of the project life cycle. The scope of the project cannot be adequately defined without some understanding of how the product life cycle influences the development stage used to create the end product. A product that is in the introduction stage of the product life cycle will have different project objectives than one that is in the growth stage or mature stage.

Decisions made at the development stage have ramifications for a product's life cycle. Studies estimate that 70% of the life cycle cost of products is determined during the design phase within the development stage (Edwards, 2009). Manufacturers are becoming increasingly responsible for the life cycle of the products they produce due to legislation, customer demand, and negative publicity. By analyzing the product life cycle, project teams can “design out” hazards and “design in” features that address the environmental, economic, and human aspects of taking care of society for the long term.

Project category – What is important to the strategic goals of the organization?

A result of the strategic planning process, a list of the organization's goals and objectives, established by senior management, reflect the organization's philosophy and strategic direction. An organizational philosophy helps identify which strategic initiatives will fit within the organization's current culture. For example, an organization philosophy could be exceptional customer experience or developing innovative products. Strategic direction covers areas that senior management feels are important for continued organizational growth and development, such as quality improvement goals or expansion goals.

The value of project management is the ability to link projects that are tied to the business strategy of the organization. Initially, high-level project categories may be based on the following strategic considerations:

• Market demand: responding to customers’ demands for increased services
• Strategic opportunity: developing a new product line or services for future growth
• Organizational need: increasing organizational efficiency by undertaking a quality improvement initiative
• Social need: holding a fundraising campaign to increase public awareness regarding a social cause
• Environmental consideration: developing sustainable products
• Customer request: developing or improving an organization's current operations
• Technological advance: incorporating and improving operations due to improvements in technology
• Legal requirement: adherening to new governmental laws
• Regulatory compliance: complying with new regulations and policies

Project categories are influenced by a variety of environmental factors, organizational constraints, and the influence of stakeholders. The goal of portfolio management is to balance these factors, both short-term and long-term, while staying aligned with the organizational strategy and objectives. The different project categories should be established based on decisions in the best interest of the organizational strategy and objectives.

Project life cycle – Is the project plan-driven or change-driven?

The project life cycle identifies the beginning and the end of the project. At a high level, the project life cycle breaks down a project and identifies the logical sequence of tasks that must be completed to produce a product or service. All projects share a common life cycle by virtue of being a project, meaning that all projects have a beginning, a middle, and an end. A project life cycle can be reused with some variation for similar types of projects. Different project life cycles exist for different products and services. For example, the life cycle to construct a building is very different from the life cycle to develop a software application. There is no ideal project life cycle applicable for all projects. A project manager may have a preference for determining a project life cycle based on past experience. There should be a consensus on which project life cycle is used regarding the selection, value, and usefulness of each particular project.

Exhibit 3 – Various project life cycles based on the project's characteristics

According to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Fifth Edition (Project Management Institute, 2013), project life cycles can be structured from the following three approaches (Exhibit 3) based on the unique aspects of the industry, organization, stakeholders, and characteristics of the project.

A predictive (plan-driven) project life cycle attempts to define the total scope at the beginning of the project. This project life cycle works best in project environments where there is the need to have a high level of certainty regarding what the project is expected to deliver. It does not work well in environments with high levels of uncertainty and change. A predictive life cycle is used to satisfy a management need to provide predictability and control over the project. Changes to the project are managed by a formal review and acceptance process. A common misconception with a predictive project life cycle is that it requires a significant amount of bureaucratic controls and unnecessary documentation. That is not necessarily the case. There is no reason why the project management team cannot be empowered to make decisions to fit the needs of the project. Project documentation can also be tailored to fit the needs of the project.

An iterative project life cycle is one where the end product or service is developed through a series of repeated cycles, while an incremental project life cycle successively adds to the functionality of the end product or service. Iterative and incremental project life cycles are generally preferred when the project team needs to manage changing objectives and requirements to reduce the complexity of a project, or when the partial delivery of the project's end product provides value for one or more stakeholder groups. An incremental project life cycle is a variation of the predictive project life cycle. It is assumed that the total scope for each incremental release or phase can be completely defined prior to executing the work to build that release. An iterative project life cycle typically has smaller units of functionality than an incremental project life cycle, and the end result of each iteration may or may not be a usable end product. The planning for the next iteration is carried out as work progresses on the current iteration's scope and deliverables and allows the project team to progressively build some level of functionality that gradually builds toward the final end product.

An adaptive (change-driven) project life cycle is expected to respond to high levels of change and ongoing stakeholder involvement. Adaptive methods are similar to the iterative/incremental life cycle but differ in that the iterations are very short, usually with a duration of two to four weeks, and are fixed in scope and cost. An adaptive life cycle uncovers project requirements by executing the project in short iterations and has the flexibility to adjust to changes in project requirements. The less certain the project's end customer is of requirements, the more adaptable the project team's needs are with respect to project management processes and practices. Adaptive methods are generally preferred when dealing with a rapidly changing environment, when requirements and scope are difficult to define in advance, and when it is possible to define small incremental improvements that will deliver value to stakeholders. The sponsor and customer representatives should be continuously engaged with the project to provide feedback on deliverables as they are created and to ensure that what is being delivered reflects their current needs.

Project phases – What are the related project activities that produce project deliverables?

A project phase represents a set of product-related activities that culminates in the completion of one or more deliverables. Breaking a project into different phases helps to distinguish between the various types of work to perform when the work is unique to other portions of the project. Project phases also provide a method of monitoring and controlling the overall project's progress. Subdividing a project into phases provides an opportunity for the project team to review the deliverables and the project performance to determine if the project objectives are being met.

Project phases are product-dependent descriptions that are derived from the product life cycle. There are various phases in any product development life cycle. Each phase follows a particular sequence in the life cycle in order to produce deliverables required by the next phase in the life cycle. Exhibit 4 illustrates the product life cycles used for software development.

Exhibit 4: Example of the common phases used in a software development project

Software development life cycle phases (for illustrative purposes only) include:

• Feasibility phase: The purpose of the feasibility phase is to determine whether it would be technically and financially feasible to develop the software application by conducting a preliminary business analysis.
• Requirements phase: Information is gathered from key stakeholders and end users to determine their needs, wants, and expectations.
• Design phase: The system and software design are prepared from the requirement specifications. The system design helps in specifying hardware and system requirements and helps in defining overall system architecture. The software design is more focused on usability features, user interfaces, and outputs.
• Development phase: From the system design documents, the work is divided into modules/units and actual coding is started. This is the longest phase of the software development life cycle.
• Testing phase: After the code is developed, it is tested against the requirements to ensure that the product solves the needs gathered during the requirements phase. During this phase, unit testing, integration testing, system testing, and acceptance testing are completed.
• Deployment phase: After successful testing, the product is delivered/deployed to the customer for use.
• Maintenance phase: Once the customer starts using the software application, errors and updates can be resolved as ongoing maintenance.

Phase-to-phase relationship – How will the project phases work together?

As stated previously, a project may be broken into specific phases, with each of these phases having a set of related project activities. The end of each phase culminates with the completion of one or more phase-specific deliverables. For example, for a software development project, the requirements phase will produce the requirements document. When projects have more than one phase, the project team can choose how the project phases work together. Project phases are part of a series of related activities designed to ensure proper control of the project and attain the desired product, service, or result. There are two approaches to how these project phases relate to each other: sequential or overlapping.

In a sequential phase-to-phase relationship, when one phase is completed, the subsequent phase can begin (Exhibit 5). This approach improves management and control and reduces risk and uncertainty about the project, but it may also eliminate any options for compressing the overall project schedule or responding to changing business conditions.

Exhibit 5: Example of a software development project using a sequential phase-to-phase relationship

Today, projects require much shorter schedules. One way to reduce the project schedule is to use an overlapping relationship between the project phases (Exhibit 6). In an overlapping phase-to-phase relationship, the subsequent phase may begin before the previous phase is completely finished. Using overlapping project phases can work, but it may increase risk and result in some rework.

Exhibit 6: Example of a software development project using an overlapping phase-to-phase relationship

In practice, many organizations and project teams use a combination of sequential and overlapping approaches (Exhibit 7). Many factors can impact the decisions as to which phase-to-phase relationship to use, such as degree of risk, imposed deadlines, or demanding stakeholders. The key is to select the phase-to-phase relationship that provides the best solution by balancing the preferences of your stakeholders and the abilities of your project team with the overall project characteristics.

Exhibit 7: Example of a software development project using a combined phase-to-phase relationship

Stage-Gate^® reviews – How and when will you authorize completion ofphases?

The Stage-Gate^® review process is intended to break up a project into a series of phases that could be individually reviewed. The review points at the end of each phase require that a number of criteria be met before the project can progress to the next phase (Exhibit 8).

Exhibit 8: Example of Stage-Gate^® reviews for the software development life cycle

The “gates” or decision points are located at points in the product development process that are most beneficial for making decisions regarding continuance of product development. At the conclusion of each phase of development of a new product, it is the responsibility of senior management to make a decision as to whether or not the product should continue to be developed.

Stage-Gates^® must have clear and visible criteria so that senior managers can make “go/no go” decisions and prioritization decisions objectively. Most importantly, these criteria must be operational (easy to use), realistic (make use of available information), and discriminating (differentiate between the good projects and the mediocre ones).

The primary advantages of using a Stage-Gate^® review model for product development are its ability to identify problems and assess progress throughout the project's life cycle. Poorly performing projects can be quickly modified to meet the original project objectives. Runaway projects can be killed to prevent additional loss of capital and move organizational resources to other more valuable projects. In addition, the Stage-Gate^® review model is an opportunity for senior management to validate the business case for the project and determine if the project is still aligned to meet the project's objectives.

Project management process – Which project phases are in the five project management processes?

All of the information that the project team has gathered up to this point is used to determine what product-related activities need to be performed to complete the final end product. Now, it is time to begin thinking about project-related activities. Despite their similar names, there are big differences between product-related activities and project-related activities. For example, software programming (or coding) for a software application is a product-related activity. Developing a project schedule to know when the coding will start, its duration, and when it will be completed is a project-related activity.

The project management process uses a “systems approach” to completing projects. Projects are completed through a series of processes. The definition of a process is a set of interrelated actions and activities performed to achieve a pre-specified set of products, results, or services. The output of one process becomes the input for the next process. The outputs of the planning processes become the inputs for the executing processes. The outputs of the executing processes become the inputs for the closing processes. The project management processes ensure the effective flow of the project throughout its existence.

Exhibit 9 illustrates how the product phases fit into the project management process for a software development application. The project management process represents a set of project-related activities that culminates in the completion of one or more deliverables. Breaking a project into different processes helps to distinguish between the various types of work to perform when the work is unique to other portions of the project. This also provides a method of monitoring and controlling the overall project's progress. Subdividing a project into processes provides an opportunity for the project team to review the deliverables and the project performance to determine if the project objectives are being met. A product life cycle is broken down into distinct product-related phases. Each phase can be traced to one of the five project management processes. In Exhibit 9, the maintenance phase is outside the project management processes because it is considered part of the ongoing operations.

Exhibit 9: Comparison of product-related phases to the five project management processes

Project sizing – How big (or important) is the project?

A project sizing matrix is a good tool to use in assessing the relative magnitude of a project. For example, projects are sized in categories of small, medium, and large projects (Exhibit 10).

Exhibit 10: Possible project sizing matrix based on project metrics

A project sizing matrix can incorporate major factors affecting project size, including estimates of the project's cost and duration, degree of complexity (the estimated number of tasks), level of anticipated risk, and strategic value to the organization. Cost and duration estimates made in the justification process will be high-level estimates. After the project is authorized, the project management team will refine project objectives and requirements, cost and duration estimates will become more accurate, and the project's true size will become clearer. By the same token, project complexity estimates in the initiation process will be based on assumptions about what type and how much work the project will require. The risk assessment for the project must align with the performing organization's risk tolerance.

Projects typically cross organizational boundaries, and the associated challenges and considerations for the project sponsor, the project manager, and the project team increase proportionately. Organizational cultures, strategies, goals and objectives, and leadership styles can differ markedly from one department to another within a single organization. In these cases, the project sponsor and the project manager must spend a great deal of time working with stakeholders from each department to ensure that project deliverables meet the needs of all stakeholders. Political considerations in these cases will typically require a more conscientious and sophisticated project approach.

Various other factors can influence the size of the project. For example, a project with a long duration, a large budget, and a sizeable project team may be considered a large project. However, a project with a short duration and small budget can be a strategically high-value project and one that is highly critical to the performing organization. In this case, applying a minimal amount of project management practices may not be appropriate. It would be advisable to adapt the project's approach to include more project management processes than would ordinarily be suited for a small project.

Using a sizing tool, based on project metrics and impact, puts projects in perspective to determine the extent and degree to which project management component processes should be applied to the project. As the project manager and the project management team use the project sizing matrix for initially evaluating a new project, they can also update the project sizing matrix with relevant project attributes used in the project justification process.

Project Approach

When it comes to projects and practices, one size does not fit all. Effective project management is not a rigid set of processes to be followed on every project. A “one size fits all” approach simply does not work. The nature and characteristics of the project must dictate the type of project management approach to be taken. Principles, best practices, and methodologies of all kinds can be very valuable, but only if they are appropriate to the specific needs of the project. The project management processes, tools, and techniques described in the PMBOK^® Guide should not be used uniformly on all projects. There are some basic project management practices that should be applied, but the way they are applied must be tailored to the situation at hand. For any given project, the project manager, in collaboration with the project management team, is always responsible for determining which processes are appropriate and the correct level of rigor for each process. This approach is known as “tailoring.” Project managers and their teams should carefully consider each process and determine whether it is applicable to the project they are working on.

• Plan-driven project approach. An example would be undertaking a project where there are significant risks, such as strict government-imposed regulations, loss of business, or loss of life for the project. Therefore, a more extensive or plan-driven project management approach should be taken, which would include additional planning and monitoring and controlling activities.
• Change-drive project approach. If the primary objective of the project is an innovative, state-of-the-art product or service, developing a set of fully defined project documents is unreasonable and the only way to complete the project is a flexible or change-driven project approach. A change-driven approach is generally preferred when dealing with a rapidly changing environment, when requirements and scope are difficult to define in advance, and when it is possible to define small incremental improvements that will deliver value to stakeholders. In this case, a moderate number of component processes are needed.
• Time-driven project approach. If the project is one that is time-sensitive, a more fast-tracked or time-driven project management approach may be more suitable. A fast-tracked approach is also applicable for projects that have consistent, repeatable project management processes because they are performed on a regular basis (e.g., managing monthly program events, minor software releases, advertising campaigns, etc.). In this case, only the essential component processes are needed.

Summary

There are many types of projects in many types of environments managed and performed by people with varying degrees of knowledge and expertise in project management. Some project managers have sophisticated project management experience; others do not. Project managers who acknowledge these differences are more likely to be successful than the project managers restricting themselves to a model that does not fit the knowledge level of the people working on the project. Some organizations have established policies that standardize all projects, while others allow the project team to choose and tailor the most appropriate approach for their individual project. Taking the time to engineer a project management approach that is based on the combination of existing organizational standards, best practices, and the specific characteristics of your project will contribute to a greater probability of success.

The purpose of the project categorization system is to develop the best approach for completing the project. The project approach involves the selection of project management practices, means, and methods that the project management team should perform based on the specific, high-level project characteristics gathered from the project charter. These high-level project characteristics involve comparing the project objectives and other related information to the quality and accuracy of the information necessary to adequately plan and execute the project.

Appendix

Project Approach Survey

This survey will identify which project approach should be used to execute projects based on high-level project characteristics.

Project Type:     _________________________________________________________