“What gets measured gets done”
Tom Peters
If we want things done, we need to measure them and …. get them organised, I would say.
Most project-based organisations have an internal system to classify, to categorise (which is not the same thing as classify, I will explain), to rank or ‘size’ their projects. This action is critical for operational, tactical and strategic reasons.
In this article I would like to cover the topic of project sizing, which has been briefly mentioned also on this blog in a previous article. I will provide my take on the subject, what project sizing is, why it is done and, more importantly, in which way it can be approached. I hope this can be of interest.
What is ‘project sizing’?
Some authors suggest that the need to classify, to label and to group things is an innate part of human nature. Think about taxonomy, as a way to formally classify things. A taxonomy groups words, labels, products, things and then arranges the groups into a hierarchy. People construct taxonomies for almost any kind of information, from biological systems (see biology classifications) to organizational structures. Organizations create taxonomies in many ways: chart of accounts taxonomies to manage accounting systems, organization charts and job classifications to manage employees, catalogues for products and also taxonomies …. for projects.
The ‘project sizing‘ comes probably from the IT sector, in which it is intended to help programmers, project managers and management to determine the size & complexity of their IT projects. In other sectors it may be termed as ‘project classification‘ or ‘project categorisation‘, both with the objective of ‘making things more manageable‘.
In the specialised literature much has been written about how the terms ‘classification’ and ‘categorization’ are used, interchangeably. Classification seems to be intended as “slotting of objects, events, or properties … into mutually exclusive classes within the hierarchical structure imposed by an arbitrary and predetermined ordering of reality” and categorization, as a “process of dividing the world of experience into groups—or categories—whose members bear some perceived relation of similarity to each other“. So these terms are different. As an example, think of a tomato. It is classified by botanists as the fruit of the edible, pulpy berry of a plant (genus Solanum) of the nightshade family, but it is categorised by the supermarkets under “vegetables”. Both approaches are forms of different taxonomies.
Why do we need project sizing?
All taxonomies are structured hierarchies of information, formal classification systems that are meant to help people handle information. It is possible that projects will be classified at the higher level, as Research or Development, Validation or Production, Testing or Deployment, Core or Non-core, etc. Each sector might have the own classification. When dealing with a more granular assessment of size & complexity, I would like here to advocate for the use of the term of sizing (rather than categorisation).
The use of a fixed categorisation may reduce flexibility, creates barriers, silos and exclusion. Continuing with the example with vegetables, I remember once a cashier at a supermarket who was struggling to find the fennel in his till system (he didn’t know the name of the vegetable and he looked under “vegetables”)- it was categorised under “exotic vegetables“!
The classification or categorisation may limit the flexibility of an organisation to respond to rapid changes in the operating or strategic environment. A project sizing tool helps in providing greater granularity in the assessment of complexity, especially when handling multiple projects or programmes in a portfolio, analysing projects and programmes in all their facets and in their relationship with the external context, but without constraints.
The PMI suggests key drivers for the project classification, which I think they are equally relevant for my take on a project sizing exercise. I integrate here the PMI drivers with others identified by other authors:
- allocation of project/programme to appropriate department, specialisation or discipline;
- strategic positioning;
- correct governance;
- resource/budget allocation;
- management of different contractual needs;
- marketing;
- reporting, including dissections for multiple purposes;
- benchmarking, performance evaluation and improvement;
- knowledge management;
- common/shared language;
- management of interfaces;
- alignment and tracking achievement of business goals;
- tactical and operational prioritization;
- “enterprise” risk management;
- resilience;
- basis for adaptation and evolution of PM processes and tools.
How is project sizing done?
A perfect sizing system is probably difficult to achieve. Many practitioners and PM standards advocate for a structured but cooperative approach between contributing agents, users and beneficiaries. The system should be able to cope with differing viewpoints, with the structure of the system maintaining scope to accommodate changes and also dissent among the communities of users.
“From the point of view of design, the creation of a perfect classification scheme ideally preserves common-sense control, enhances comparability in the right places, and makes visible what is wrongly invisible, leaving justly invisible discretionary judgment.”
Bowker G and Susan LS
An effective and useful project sizing tool should aspire to:
– provide of attributes appropriate for every project in the portfolio,
– permit a grading within each attribute,
– provide useful insight about differences between projects within one attribute, and
– be readily translatable and comprehensible across the organisation.
How does ‘project sizing’ look ?
It is generally taking the form of a matrix where the projects are graded against a list of agreed attributes. These attributes can vary, depending on sector and industry and including, for example, type of work, type of content or products, budget, geographical spread, degree of innovation etc.
In a very simplistic approach the projects can be assessed on the basis of three dimensions: technical, operational and environmental complexity. This approach may be too simplistic and not sufficient to provide the necessary granularity for ranking and for sound decision making. Another example could be by scoring against scope size, risk profile, technical difficulty and relationship complexity.
There are other approaches. One I have used is based on a set of 10 criteria. Each criteria have guiding questions that can help in the discussion with the project owners for the assignment of a score from 1 (low, in size or complexity) to 10 (high, in size or complexity). The results can be shown as a ‘heat map’ scoring, for example, from green (low range) to red (high range). The discussion with the project owners or management can help in grading appropriately the projects for each attributes.
The matrix is analysed horizontally and vertically, providing an insight into a specific project size or into a specific attributes that might carry a level of criticality across the entire project portfolio. In the example of a fictional project portfolio above, Project 2 is showing some high scores compared to the other projects. Additionally, the area of technical complexity/innovation might be seen as a challenge across the portfolio. The discussion with the key stakeholders will be around intelligent resource allocation, specific skills sought for the project management, a greater attention for risks and their mitigation etc.
I hope that this article has helped in understanding the use and place of a project sizing tool in the context of project management. I will continue to be grateful for comments, alternative views on the subject and feedback.
Marco Bottacini, Senior Portfolio Manager, GALVmed
The views and opinions expressed in this blog are those of the author and do not necessarily reflect the views and opinion of GALVmed.
Project Management Discussion Group 