The Importance of Classifying Projects

There are many ways to classify a project such as:

• By size (cost, duration, team, business value, number of departments affected, and so on)
• By type (new, maintenance, upgrade, strategic, tactical, operational)
• By application (software development, new product development, equipment installation, and so on)
• By complexity and uncertainty (see Chapter 2)

Projects are unique and to some extent so is the best-fit model to manage them. Part II of the book is devoted to exploring five best-fit models and when to use them. For now it is sufficient to understand that a one-size-fits-all approach to project management doesn't work and has never worked. It is far more effective to group projects based on their similarities and to use a project management approach designed specifically for each project type. That is the topic of this section.

Establishing a Rule for Classifying Projects

For the purposes of this chapter, two different rules are defined here. The first is based on the characteristics of the project, and the second is based on the type of project. Chapter 2 defines a third rule, which is based on the clarity and completeness of the goal and the solution.

Classification by Project Characteristics

Many organizations choose to define a classification of projects based on such project characteristics as the following:

• Risk — Establish levels of risk (high, medium, and low).
• Business value — Establish levels (high, medium, and low).
• Length — Establish several categories (such as 3 months, 3 to 6 months, 6 to 12 months, and so on).
• Complexity — Establish categories (high, medium, and low).
• Technology used — Establish several categories (well-established, used occasionally, used rarely, never used).
• Number of departments affected — Establish some categories (such as one, a few, several, and all).
• Cost

The project profile determines the classification of the project. The classification defines the extent to which a particular project management methodology is to be used. In Part II, you will use these and other factors to adjust the best-fit project management approach.

I strongly advocate this approach because it adapts the methodology to the project. “One size fits all” does not work in project management. In the final analysis, I defer to the judgment of the project manager. In addition to the parts required by the organization, the project manager should adopt whatever parts of the methodology he or she feels improves his or her ability to help successfully manage the project. Period.

Project characteristics can be used to build a classification rule as follows:

• Type A projects — These are high-business-value, high-complexity projects. They are the most challenging projects the organization undertakes. Type A projects use the latest technology, which, when coupled with high complexity, causes risk to be high also. To maximize the probability of success, the organization requires that these projects utilize all the methods and tools available in their project management methodology. An example of a Type A project is the introduction of a new technology into an existing product that has been very profitable for the company.
• Type B projects — These projects are shorter in length, but they are still significant projects for the organization. All of the methods and tools in the project management process are probably required. Type B projects generally have good business value and are technologically challenging. Many product development projects fall in this category.
• Type C projects — These are the projects that occur most frequently in an organization. They are short by comparison and use established technology. Many are projects that deal with the infrastructure of the organization. A typical project team consists of five people, the project lasts 6 months, and the project is based on a less-than-adequate scope statement. Many of the methods and tools are not required for these projects. The project manager uses those optional tools only if he or she sees value in their use.
• Type D projects — These just meet the definition of a project and may require only a scope statement and a few scheduling pieces of information. A typical Type D project involves making a minor change in an existing process or procedure or revising a course in the training curriculum.

Table 1-1 gives a hypothetical example of a classification rule.

Table 1-1: Example of Project Classes and Definitions

These four types of projects might use the parts of the methodology shown in Figure 1-3. The figure lists the methods and tools that are either required or optional, given the type of project.

Figure 1-3: The use of required and optional parts of the methodology by type of project

Classification by Project Application

Many situations exist in which an organization repeats projects that are of the same type. Following are some examples of project types:

• Installing software
• Recruiting and hiring
• Setting up hardware in a field office
• Soliciting, evaluating, and selecting vendors
• Updating a corporate procedure
• Developing application systems

These projects may be repeated several times each year and probably will follow a similar set of steps each time they are done.

The value of classifying projects by type is that each type of project utilizes a specific subset of the entire project management methodology. For example, projects that involve updating a corporate procedure are far less risky than application systems development projects. Therefore, the risk management aspects of each are very different. Risk management processes will be less important in the corporate procedure project; conversely, they will be very important in the applications development project.