There are many definitions for so-called "Large Scale Project (LSP)". It does not matter how to define this kind of venture exactly. There is no clear border or threshold to call a project a large one. It depends on the view of the stakeholder and how they judge the respective project. For example, a 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 an LSP. Whereas a small software project may have an extremely complicated task if it creates a new functionality in a contemporary technical environment.
There are some definitions that create a general frame. It is certainly helpful to have at least a mutual understanding of thresholds as advice for a judgement. The blog article in [O1] aims to create a list of features that describe an LSP more detailed. For example, the author suggests looking 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 an 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 guideline for topics that are important to run an LSP successfully.
LSP and Complexity
There is a correlation between large projects and the complexity of a project which may serve as criteria for using the LPLM©. The publication in [O2] defines several indicators how to judge the complexity of a project. Another article in [O3] shows the way of grouping complexity in different elements. These groups are the following:
- Technical - scope or innovative technology
- Functional - untried ways of working with systems
- Organizational - many people and organizations are involved
- Financial - Costs are difficult to estimate due to new functionality and technology
- Temporal - Long timeframes and many dependencies
All these complexity elements may influence a large project in many ways. Therefore, it is best practice to find several ways of breaking down the effort by defining work packages. This approach neglects the influence of many other complexity triggers.
However, having a complex project does not necessarily mean it should use a certain model. It depends on the executing organization and the influence of the environment on the project. Using the defined ways of working in the model may nevertheless help all project managers to understand how to deal with the complexity of any projects.
LSP and Organizations
The executing organization supplies the foundation for any project. Therefore, it is crucial to take this environment into account in the setup of a project management framework. This may apply to topics like governance, planning, funding, and controlling or risk management. Additionally, the structure of the executing organization in terms of projects is a key factor for the setup of it. For example, a strong matrix organization groups the several levels differently compared to a functional organization. The respective articles describe all influences for governance and planning.
Management and Delivery
All projects should distinguish between the project management and the project delivery. This enables the people who work on a project to define the appropriate way of working in every situation that occurs. It sounds like a simple rule but is often overlooked and causes unnecessary hassle in the daily work. There is a short story about the difference between both side in [O5] that shows the potential pitfalls of not understanding this concept.