Is there an optimal project size?

It is difficult to find a general rule for what is an optimal project size. A project that is too small delivers nothing of sufficient value and a project that is too large can suffocate itself. Somewhere in between is the optimal project size. Exactly where it is found varies, but it is possible to systematically approach the issue.

WBS - a good start

A common way to attack projects is to work with a so-called WBS - Work Breakdown Structure. First, expected deliveries from the project are identified. The tasks / activities required for each delivery are then analyzed. Finally, the project plan is created by placing the activities in the calendar, taking into account the dependencies between the activities.

Many projects are often content with doing a WBS. But the risk is that the result will be complex and difficult to understand and thus difficult to control and follow up. This often leads to delays and increases in cost. Then chaos often occurs and the project manager loses his grip on end time and budget. In addition, the employees' expected efforts are postponed in time, which probably does not fit in at all with their own and the organization's other plans.

Is it recognizable? Some form of additional structuring is required to gain control.

Don boilt boil the ocean - divide the project into smaller parts

There is a well-known management concept called Don't boil the ocean, something that in this context could be freely translated as "focus on a small part at a time instead of everything at once".

With the WBS as a starting point, the work is structured into smaller parts that can be carried out independently of each other. The result is a number of different components / parts that are produced and delivered independently. Finally, they are put together into an end product. The advantage is that development becomes more focused, that the components can be replaced more easily and that they can at best be reused in other contexts.

However, the question remains whether the parts should be sub-projects that are subordinate to a main project, or whether the parts should be independent projects with their own project plan, management and staffing?

In general, subprojects are preferable if the parts are to be delivered as a whole. Likewise, subprojects are often good if there is the same steering group, project manager and resources for the different parts.

Independent projects are interesting if the parts can be delivered and used separately and thus have an intrinsic value for the customer. In those cases, it is advantageous to divide the project into stages.

The concept project program is also worth mentioning in this context. What is meant by that term varies greatly. This usually means that a number of sub-projects, or independent projects, have some form of joint control in the form of, for example, a program management. The program management's task can, for example, be to coordinate the parts, prioritize and ensure that duplication of work does not take place between the various projects.

Easier to prioritize and previous deliveries

An advantage of dividing the project and deliveries into smaller parts is that prioritization often becomes easier. If time and or money runs out, you can see what can be deleted or postponed. Another advantage of breaking down into subprojects or independent projects is that deliveries come earlier and more gradually, instead of a large delivery at the end. This approach is something that is becoming more and more common and is an example of agile development.

Below are general benefits from the client's and the project group's point of view:

Benefits for the customer