As first published in Rail Professional Magazine, May 2021.
Projects, almost by definition need to be completed by a specified date, therefore time management through the use of a project programme is crucial. However, many will have witnessed project programmes that resemble a fairy tale…. where all the works go off without a hitch. That is, until someone realises that the completion date is not achievable, and the question “why” starts to be asked. An investigation ensues and what becomes apparent is that historic project delays have not been accounted for in the programme and now it’s too late to resolve without affecting the completion date.
COVID-19 has unexpectedly hit thousands of projects this year. Its impact on industries across the globe has been monumental. The engineering and construction sectors are no exception to this, with many projects grinding to a halt. The pandemic has placed a heavy burden on project teams who must assess both retrospective and forecast prospective delays, which have or will likely occur due to the virus. It is events like COVID-19 that bring the quality of the project programme into sharp focus and highlight whether the team have properly updated and maintained it or not.
In light of these circumstances, we have compiled a few hints and tips for structuring, integrating, and maintaining programmes so that events such as COVID-19 will be far easier to manage. Drawing on our experience, we have also identified and shared below common problems which impact a project programme and how they can be resolved. A well-structured and integrated programme will enhance a project teams’ ability to reliably monitor progress, forecast delay and proactively manage any identified issues.
What common problems impact a project programme?
Some of the most common problems which impact a programme are:
1) Level of detail within the Work Breakdown Structure (WBS);
2) Missing works scope;
3) Missing logic and dependencies;
4) High levels of float;
5) The use of ‘hard’ constraints;
6) Negative float; and
7) No clear or identifiable critical path.
The 7 problems above all interweave with one another and can have a compounding effect which can ripple throughout a project programme.
Why do the problems above impact a project programme? How can they be resolved?
(1) Without a clearly defined WBS, drawn up (or at least integrated) by a single controlling mind, programmes can often be difficult to understand, particularly when comprising of thousands of activities. These programmes resemble a list, as opposed to a well-structured plan. By incorporating a WBS into a programme, a hierarchical structure is created. This enables the relevant sequences of work to be summarised and assessed. As a result, large and complex programmes become easier to interpret, as works can be broken up into smaller sequences of work. This also applies to activities with long durations which should also be broken down to allow accurate progress updating.
(2) Missing scope is another symptom of an ambiguous WBS. Programmes without a clearly defined scope of work are more susceptible to ‘scope creep’ where changes are not recorded against the original programme. Scope that is added during the project should be incorporated into the programme and assessed. This will then determine if an adjustment to the completion date may be required, or a recovery programme needs formulated. It is imperative that project teams ensure all work scope is included in the original programme, so they have an accurate baseline against which to measure and record any changes which occur.
(3) Programmes that do not include all scope are highly likely to give rise to missing logic and dependencies. As a programme’s logic defines the relationships between activities, if a programme contains open ends (activities with neither a predecessor nor successor activity), this will inevitably result in flawed logic which may obscure the true critical path of a programme. This is best addressed by ensuring each activity and dependency is assigned with a logical predecessor or successor. This is usually done with a ‘Finish to Start’ link, to ensure that the programme reacts dynamically to any changes made.
(4) High levels of float imply an activity has a long period of time before affecting the critical path on the project. Certain activities may genuinely have that much float attributed to them. Other activities, however, contain high float because they are missing logic and the period prior to becoming critical is inaccurate. Identifying which activities are missing a dependency and assigning the correct logic will reduce high levels of float within a programme.
(5) Programmes that contain missing logic can sometimes prompt the application of ‘hard’ constraints, i.e. ‘Must Finish On’, to artificially hold activities in place. This type of constraint must be avoided as it overrides the relationship of an activity’s predecessor to drive logic when progress is updated. It is best to remove all ‘hard’ constraints and use either a ‘soft’ constraint, i.e. ‘Finish On Or After’ (which will not override the relationship of an activity’s predecessor) or the correct predecessor to drive the activity.
(6) Negative float frequently occurs in programmes which have activities with ‘hard’ constraints. Negative float can indicate a scheduling problem caused by an activity start date set earlier than the end date of its predecessor. Removing ‘hard’ constraints in the programme will ensure an activity start date cannot be set earlier than the end date and will likely remove negative float within that logical sequence.
(7) Rectifying the previous issues highlighted above will increase the likelihood of identifying the true critical path within the programme. A clear and identifiable critical path will enhance the programme’s ability to demonstrate critical and non-critical delays which occur throughout a project.
Programme integration
Having highlighted common problems which impact a programme structure, we now come to the topic of programme integration. Having a truly integrated programme means: ONE source of truth, ONE team working together to deliver ONE common objective with ONE overall delivery.
So, what does true Integration look like?
Integrated planning requires real collaboration amongst multiple planners representing different workstreams across complex capital works. Integration will ensure stakeholders are actively involved early in the production and continuous development of the programme. It promotes the project team to ‘buy in’ to the programme where issues are identified, discussed, and hopefully resolved. Creating an environment that promotes ‘collaboration and togetherness’ in delivering common goals often helps pre-empt problems that are otherwise likely to be encountered.
It is the best strategy to avoid gaps in the programme such as missing interfaces, interdependencies, an unreliable critical path. Without integration, a lot of the issues described earlier typically arise and can give rise to formal disputes between parties. The next step is to enable the full integration of the programme.
What does full integration of the programme mean?
Integrated planning ensures the project scope is defined using an iterative life cycle approach, with flexibility and agility built into the programme. This will give a greater chance for achieving the project’s objectives. We use these terms very deliberately, as follows:
- Flexibility: because change always happens, and needs to be recorded as efficiently as possible; and
- Agility, because to identify the effects of change, a dynamic and agile programme that reacts and moves according to change is paramount to a successful delivery.
Planning ‘best practice’ should be adhered to when developing, integrating and maintaining the baseline programme, as you should start as you mean to go on! The integrated baseline programme is going to be the best point of reference, so it is important that it is communicated to all parties and used as a ‘working tool’ as opposed to a mere ‘reporting tool’ of historical events!
Best practices, dependencies and interface management must be consistent throughout the project. It revolves around 4 key stages: identification, coding, integration and impact analysis, and finally impact resolution. Poor integration will not be conducive to impact analysis or scenario planning.
It is worth reiterating that collaboration is crucial to ensure all members of the team are consulted during the identification stage. This is vital as it only takes one missed dependency to introduce a delay to the project. Ensuring full Integration is no small task. It requires planning, communication, and commitment throughout the project life cycle. The benefits include:
- Improved collaboration across the project team;
- More accurate forecasts and what-if scenarios;
- Faster insights for all stakeholders to align with operational planning and strategic goals;
- Greater process visibility and transparency that strengthens risk management; and
- A single version of the truth backed by transparent methodologies and processes.
Summary
The hints and tips covered in this article provide guidance on how to structure and integrate a programme more effectively. Whilst the approach is not exhaustive, it is intended to incorporate the most common issues which can prevent a programme’s primary purpose: to provide the project team with a dynamic and reliable tool that can be used to identify issues early and plan for change events as they occur.
Whilst it is near impossible to foresee an event such as Covid-19, a well-structured programme will enable impact and scenario analysis necessary to assess the overall impact of such a significant delay event.
If you require any further information, please contact Catherine Barthélemy or Stephen Mills catherinebarthelemy@hka.com or stephenmills@hka.com
Catherine Barthélemy is an Associate Director and a project planning specialist with more than 15 years of experience in the engineering and construction industries, working for clients, contractors and consultants on the delivery of complex infrastructure, process, energy and utility projects throughout the UK and International.
Her wide range of sector experience includes rail systems (including electrification and signalling), nuclear decommissioning as well as other major International nuclear projects, heavy civils, and oil and gas. She has significant experience in the development stages of major projects and programmes, working closely with designers and contractors to ensure the delivery of value-driven programmes in accordance with scope and contract requirements.
Stephen Mills is a Managing Consultant and has over 15 years’ experience in the construction industry working as a planning engineer and site manager, for both main contractors and sub-contractors. He has been involved in a wide range of building and major infrastructure projects with sector experience within the rail sector (tunnel M&E fitout), highways, new-build construction and construction refurbishments.
Stephen specialises in alternative dispute resolution and has prepared and assessed extension of time claims for major rail and construction projects in the UK. His hands-on knowledge of the rail and construction industry heavily influences his proficiency as a delay analyst and his familiarity with various standard forms of contract.
