If you’re trying to develop a classification system for your projects, you don’t have to reinvent the wheel. Other companies have built classification systems, and you can simply “copy” from existing systems and tweak it so it fits your needs.
In this article I’ll help you define your own classification for projects. What you read is practical advice from someone who has used classification systems as a project manager and implemented formal project management processes that relied on project classifications.
Why should you categorize your projects?
The main reason for introducing a project classification is to increase transparency. The more projects your organization is running in parallel, the harder it is to manage oversight and to provide support, for example as a PMO (project management office).
Project classification can help you in several other ways:
determinING how much project management will be needed IS MUCH EASIER
While smaller projects can be handled in a very lean way without much organizational overhead, larger projects should definitely follow a formal process that includes some level of oversight and control (why? to manage risk).
Formal elements can include a steering board, the use of quality gates which projects are only allowed to pass if they meet certain requirements which are usually documented in a project checklist.
With the right classification system, you can categorize projects by risk, complexity or other criteria and define the process and formal requirements that projects from a specific category have to follow.
You can better prioritize projects and decide on budget allocation
With a classification system that reflects the business value or strategic importance of projects, you have a basis upon which to decide where to focus your resources (people and money) on.
It’s easier to staff your projects
If you have an indicator for the project’s complexity, you can use it to assign project managers with the necessary amount of skills and experience. Less complex projects can be managed by less experienced project managers while more complex projects may require real project veterans with tens of thousands of project hours under their belt.
These are just some of the reasons that justify the introduction of a project classification logic. You may have other reasons for categorizing projects.
What are good classification criteria for projects?
Here are some of the most common classification criteria used by companies:
- schedule
- budget
- complexity
- business value
- service type
- framework used
schedule
The project duration is a good indicator for the size and impact. Longer duration correlates with more resources being needed, higher expenses, more room for error and consequently greater risk of failure.
Get my project templates – including schedule, budget, risk log and more!
budget
Probably the most important criterion. Usually used in combination with project duration (schedule) because a long schedule doesn’t necessarily tell you about the budget volume (although schedule and budget are correlated). Cost is what management is most concerned about after the actual project goal. For good reason because a series of unsuccessful projects can quickly drain the financial resources of a business.
complexity
I highly recommend you use some key figure for project complexity. It is the complexity of a project that determines the level of risk and greater risk requires more oversight and control.
The question you probably ask yourself is: How can you measure project complexity?
There are many ways to measure complexity. At my previous company we simply looked at the number of functions involved in the project. Was it just IT that was involved or were other departments like accounting, sales or logistics also part of the team? The longer the list of stakeholders, the higher the presumed complexity of a project.
business value
Another useful classification factor is the level a project contributes to your company’s finances or its competitive position. Some projects don’t contribute much in terms of business value and can therefore be deprioritized, for example if you need to trim the project portfolio. Other projects have a significant positive impact on the cash flow situation and thus should receive full attention.
service type
Type of service is a useful classification factor if your organization runs different kinds of projects, for example in different business units. It can also be helpful to structure the portfolio within a specific department. For IT projects, service types could be system upgrade, infrastructure, ERP, migration etc.
Framework used
Agile, waterfall or hybrid: The project management framework (or methodology) being used determines what steps and guidelines a project must follow and how it must be staffed.
Classic projects work in pre-defined phases and with fixed milestones. Agile projects work in iterative cycles and you need an experienced agile coach or Scrum master to facilitate the process. By using a classification by methodology, you can easily see what projects fall into which delivery framework.
Don’t make the classification too complicated and define clear thresholds where everybody understands what category their project falls into and which sub categories apply for them.
Got your classification system ready? Here’s what you should do next
Once you have defined a suitable classification logic for your projects, the next step would be to update your project documentation and templates accordingly. If you are using a dedicated project management software, you may also want to track classifications there too. This may require some custom development by your software vendor.
Finally, don’t forget to communicate the project classification system among your organization. In particular, your PMs and project support staff needs to understand how to use the new classification logic.
