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 beheld 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.
LSP and Complexity
There is a correlation between large projects and the complexity of a project which may serve as a criterion 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 new 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 work that has to be done in the project. It is mainly done by defining work packages. This approach neglects the influence of many other complexity triggers. The LPLM strives to define steps how to structure all possible influences to a project into a clearly arranged way of working. This ensures that any occurring complexity can be assessed and handled. 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. 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
A project is always embedded in an executing organization. Therefore, it is crucial to take this environment into account in the setup of a project management model. 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 an important factor for the setup of it. For example, a strong matrix organization groups the several level differently compared to a functional organization. All possible influences for governance and planning models are described in the respective articles.
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.