It’s easy to think a project size is purely a function of its budget. After all, the difference between a small project and a mega-project has to be how expensive they each cost right? Unfortunately as with almost everything in the world of projects, the answer requires a little bit of digging deeper.
Project costs are only a by-product (a side-effect, if you will) of the true factors that drive classifications like small, medium, large, or mega-projects. In fact, how much money is spent on a project is rarely ever a clean-cut indicator.
Instead, projects are rather classified more accurately through a set of more representative indicators to project size like:
1. Project scope
A project may have a low cost associated to it but can also be riddled with complexities like multiple disciplines being involved, intricate design elements, or simply large implications on the overall business processes of the project owners. Conversely, even projects that have large budgets may be only address a certain straightforward task, in which case a “large project” designation is not correct.
2. Team size or stakeholder composition
Regardless of financials, a larger project organization is by definition a large project. This is because department being involved address the project from their own lens, every member of the project team coming from a different department may have their own targets or KPIs that they need to address.
Stakeholders bring a different dimension to project complexity, especially when they also come from different backgrounds and agendas. Managing projects like these are big not because of cost, but because of the amount of navigation is required around all the different requirements, and reconciling them when conflicting goals are present.
3. Risk profile
High-risk projects (whether technical risks, operational risks, or financial risks) require a log of effort in managing because they come with a lot mitigating actions that need to be addressed. These mitigations often come at the expense of standard or straightforward ways of working. The higher the risk, the bigger the consequences when things go uncontrolled, unexpected, or unmitigated.
Risk tolerances should be defined and agreed early on during the project planning phases to avoid losing control of the project.
At the end of the day many factors affect project complexity and size. It’s easy to focus more budgets and project costs and leaving more crucial elements in blind spots. There are also a range of other factors that define how well a project is defined that I didn’t address here; things like project schedules, technology complexities, regulatory challenges (and a lot more), also need to be studied and analyzed to define the correct resources needed at the start of the project, and can easily inflate the project requirements and scope very quickly if not taken into account early on.