According to a report published in 2015 by McKinsey research, construction megaprojects have a 98% occurrence rate for time delays and cost overruns. Data indicates an average cost overrun of 80% of the original value and an average slippage of 20 months.
Effective project planning and technical documentation delivery is mission critical to support the successful execution of major construction projects.
Step #1 getting organized
Last month we covered “Metadata Based Software Improves Document Organization” the 1st step in creating successful deliveries of technical documentation in construction projects. Good planning requires an organized and structured foundation which enable you to reuse and apply common ways of planning and executing across multiple projects. Each new project should also feed back into the foundation for continuous improvement.
Step #2 planning the delivery for a specific project
In this post we cover the 2nd step – planning the delivery. These two steps appear similar however while Step #1 getting organized is about deciding on some overall information models such as coding and numbering manuals and business processes like review and approvals, Step #2 is about planning for a specific project.
For a specific project you will need to:
- define data model and business process requirements
- define documentation to be delivered and assign responsibilities
- define packages, milestones and due dates
Define data model and business process requirements
While ideally you have defined an information model and business processes that can be reused across projects (Step #1 getting organized), each project will have their unique characteristics. You either have a new client you work for, or the nature of the asset requires a different set of requirements for the project. Hopefully you can reuse a previous template directly, or just make a few smaller adjustments.
Without repeating too much of the what we described in the last blog post that focused on how to get organized, this first step is about making sure you use the right coding and numbering manuals based on the specific project’s client requirements and industry standards where applicable, review and approval processes and access control.
Define documentation to be delivered and assign responsibilities
The client will send you the overall requirements for the delivery – a Document Requirements List. Typically, you produce parts of the documentation internally, parts of the documentation will come from your suppliers or sub-contractors, and parts of the documentation will be standard documentation. The supplier documentation is usually described as a Supplier Document List(s).
A subset of the documentation will eventually be sent to the client, often called the Master Document List.
A key success factor is, as simple as it may sound, to be able to identify and group the documentation correctly – which documents are to be produced internally, by suppliers, and what is to be delivered to the client. This is the first step in being able to apply the correct processes such as review and approvals.
Another important aspect of the delivery is to define who is responsible for a specific document or class of documents. For internal documentation it is usually the person producing the document, while for supplier documentation it is usually a package responsible. This part is rather simple, but important. The complexity arises when you are to define the workflows – who performs the review and approvals. This topic will be explored in the next blog post about “Execution”.
Define packages, milestones and due dates
As mentioned above identifying and classifying document types or classes is very important and more frequently in today’s construction projects a key performance indicator used to measure compliance to contract.
This results in documentation segmented into document packages – basically groups of documents. This often correlates to an Activity (level 4) in the overall project plan, after Discipline (Level 1), Module (Level 2), and System (Level 3). Advanced planning also assigns weight (effort) to documents and document sets, and progress based on the status of the documents.
The milestones are often defined with reasons for issue codes such as Issued for Review (IFR), Issued for Construction (IFC), As Built etc., with each document package then measured to assess internal or vendor performance of achieving performance against schedule delivery deadlines that are based upon the milestones determined at the planning stage.
The challenges and success factors with planning:
In the above section we have described the key steps in planning for technical documentation deliveries and described important aspects to remember in each step. Having worked with megaprojects for over 30 years there are certain key challenges and key success factors that we have found to characterize successful projects.
Establish and use the right processes and tools to support the documentation deliveries
- Excel and a file server are just not enough. Some projects do the planning and execution of documentation deliveries in separate systems, leading to manual work and lots of time spent on following up during execution.
Planning ON the actual documents, not just FOR the documents
- There will always be a high-level project plan in systems such as Primavera, Safran or MS Projects, but there should also be planning capabilities in the documentation system itself so that it is easy to track and monitor progress.
- Intelligently handle due dates such as automatic recalculation of planned or forecasted dates based on actuals. This will ensure the plan is always up to date automatically.
Integrate planning systems with documentation systems saves time and increases quality
- Doing planning in two different systems that are dependent on each other, namely the Planning system and the Documentation system, can lead to manual work and be prone to errors.
Progress Transparency and Accuracy
- Getting an accurate picture of the progress is difficult if you are not assigning weight to each document and document set. Without this information it will become harder to spot potential delays before they happen.
Depending on the complexity of your project you might want to use advanced planning with weighting, progress definition and automatic recalculation of due dates. If the project is simpler it is normally enough to define documents to be delivered, with a responsible person assigned and a clearly defined due date on the document.
Next, we will cover step #3 execution
The key thing for successful planning is that it supports the requirements for your project and sets you up for a successful execution of the project. Look out for our next blog post on step 3 - Execution.