The Importance of Project Scope
By Ben Eastoe
Whether you are a project developer/owner writing full principal requirement scope documents or a construction contractor carving off a portion of your delivery scope to a subcontractor defining and writing a clear scope is essential.
Project scope normally starts with a well-written body of text, incorporates any design, drawings or models which comes together to outline the roadmap and outcome for a project, big or small. It needs to be further defined with details around, responsibilities, boundaries, milestones and set the base for the stakeholder to form an understanding, on the absolute project requirements. It protects all stakeholders so that the project doesn’t arrive at a mystery location, at some undefined point in the future, having had a million unnecessary adventures on the way.
This applies if you are the principal, main contractor, subcontractor or even a third-party stakeholder. A clear project scope will save time and money as well as usually much frustration. As we explored in our previous blog, in a sector under pressure from challenging operating environments and wafer-thin profitability, expending additional cost and effort is not affordable or sustainable.
My professional experience is in large construction delivery. The perspective that has led me to write this article has come from seeing organisations have great success from having a complete understanding of what they are delivering and seeing organisations having significant failures. The failures can typically stem from incorrect scope interpretation, incomplete scope information being provided in the first place, assumptions made from the scope provided, and external factors that impact the written scope information.
How Do We Develop A Project Scope at Lidiar Group?
When developing a project scope, I like to think of it as a satellite image. At its highest level, it provides you with an overview of the earth; at its most granular, you can count the individual leaves on a tree, determine its species, calculate the time of year, the likely ground conditions and whether it has rained recently. The zoom level required depends on the user and the level of detail or project engagement they have.
- Always begin with a nice clear introduction providing a zoomed-out picture of what the project is trying to achieve or the problem the project is trying to solve.
- From there, you can then zoom back into the specifics that this particular scope will refer to.
- At the next level, you can delve into the details: scope of work, task list, project schedule, project deliverables, commissioning requirements, handover plan, project management and reporting requirements and a definition of completion.
The next step is to ensure that the document you develop is accessible to all, clear in its language and provides a level of detail that is relevant to every stage of the project and each audience.
Key elements and concepts that we consider when developing a scope include:
- Perspective – Understanding the perspective of either the reader or the writer is very important
- Information – Provide as much information with as much specific detail as possible. If you don’t have design and engineering complete, consider that the costs will be higher due to not being able to define the scope and change management needs to be considered.
- Expertise – Engage with the right subject matter expert in your team – if you are not the right person, find somebody in your team with the technical capability to outline the project scope.
- Methodology – Specify what needs to happen at each project phase – from pre-mobilisation, mobilisation, execution, testing and completion.
- Expectation – Use a responsibility matrix to clarify who is responsible for each aspect of the project scope.
- Clarity – Clearly define the deliverables that define completion – there should be no ambiguity about when the project is considered complete.
- Documentation Deliverables- Define the format that you want to receive documentation – you may need it in native formats or PDF’s or both, define inclusions in documents and ideally, if you have an example or template, specify the template to be used.
We also ensure that the scope we develop becomes a living document until the final version is issued to all parties before commencing construction works.
In a perfect world, engineering and design would be completed and ‘issued for construction’ design documentation would be included in the scope of work. However, a project’s procurement process often runs in parallel with a design phase, so preliminary design revisions are often required to be used to stay on a defined timeline.
This means that change needs to be considered and planned for, with processes in place to manage it, both through a procurement process and if the design hasn’t been completed prior to any award. Otherwise, we run the risk of entering the world of endless variations, escalating costs, blown out time frames, and relentless rounds of litigation in the worst-case scenario. Sure there may be variations along the way, but their risks and negative outcomes are mitigated if the scope is defined early and suitable contingencies are allowed for. Developing a project scope is not an impossible task; it may be a challenging one, but like any challenge, it can be overcome by working through the process methodically and developing a proven formula or strategy that communicates clearly and is as complete as possible, removing ambiguity. With so much riding on its success, getting it right is critical; a good project scope will define your next project’s success