Large Scale Project - LSP

There are many definitions for so-called "Large Scale Project (LSP)". Generally, it does not matter how to define this kind of venture exactly. There is no clear border or threshold for a project to be named as a large one. It depends more or less on the view of the stakeholder and how they judge the respective project. For example, a very large construction work that has been done many times in similar environments may be easy to plan and manage and therefore it does not necessarily count as a LSP. Whereas a rather small software project may be seen as a very complicated task if it creates a totally new functionality in a contemporary technical environment. In this case it could be judged as a LSP.

There are some definitions that create a general frame. It is certainly helpful to have at least a general understanding of these thresholds as advice for a judgement. The blog article in [O1] aims to create a kind of features that describe a LSP more detailed. For example the author suggests to look at these topics:

  • "Longer duration" (6 months and longer).
  • "Larger teams of people" (more than 50 or 100).
  • "Greater budget.." (whatever that means).
  • "Much more task complexity, including many tasks having to be done concurrently."

Why is it so important to judge a project as a LSP? Classifying a project into this range helps the project management and all related stakeholder to understand how they can support the project and what kind of characteristics they should watched very closely. The following chapters give a guide line which topics are important to run a LSP successfully.

Level Model - LPLM

Large scale projects need a clearly defined approach that goes beyond the usual project management frameworks. There are several ways published that may help to create a suitable breakdown and governance. They often offer only partial solutions to organize and manage very complex projects environment in a LSP.

LPLM - Level Definition
Figure O2: LPLM - Level Definition

The "LargeProject-LevelModel (LPLM©)" provides a clear and consistent governance structure for all kinds of projects. Characteristic of the model is the distinction between three level that basically represent different entities in a complex project environment. There may be the need for more level in certain projects but it is recommended to keep the following three ones. Keeping this structure in mind it becomes easier to create a sophisticated structure that covers all parts of a project. The next chapters initially focus on several major topics which are most influenced by the LPLM©. Other topics will be covered in later publications.

LSP and Complexity

There is a correlation between large projects and the complexity of a project which may serve as a criteria for using the LPLM©. The publication in [O2] gives a good overview of several indicators how to judge the complexity of a project. However, having a complex project does not necessarily mean it should use the level model. It more or less depends on the executing organization and the influence of the environment on the project. On the other hand, a large project does not always require the adotption of the level model. Additional input coming taking the complexity into account may be useful anyway.

Correlation and Communication

The level model requires two ways of communication, planning and reporting: The horizontal and the vertical way. Both have their own characteristics. The horizontal way describes all relations inside a level whereas the vertical one shows all relations between the different level. Additionally, the Tactical Level must watch the vertical communication in the adjoined level.

LPLM - Communication
Figure O3: LPLM - Communication

The respective chapters Governance, Planning and Risk describe all flows inside and between the level. In both cases it shows how the relation between several cluster can be managed. Organizing this task is a crucial attribute of the level model because it clarifies the importance of it.