LogiKal Projects

All posts in Software

What is Schedule Integration?

Schedule Integration can refer to:

1)    collating and consolidating multiple schedules

2)    integrating costs and resources into a schedule

3)    interfacing the schedule with other functions e.g. finance system like SAP or cost management tools

In this instance the focus of this article is on the first point, which is a common need on a mega-project.  The intention here is to look at the principles in schedule integration rather than advocating a specific tool or software.  Although it is also assumed that for schedule integration each component schedule will be generated in the same version of the specific tool.  For reference the term ‘mega-project’ alludes to a project that covers multiple areas and usually involves a high level of expenditure or a duration that extends over multiple years.

The primary question when looking at collating and consolidating multiple schedules is to understand what is intended to be achieved.  On a mega-project it is usually to provide an overall understanding of how the project is going to be delivered. In many cases it’s a mechanism to bring together all the detailed information in one place. This information can then be used to generate summary information or reports which are reviewed and presented at various forums.

In my experience on ‘mega-projects’ the purpose of having a single location for all this information is to provide senior stakeholders with confidence that the project was progressing.  Additionally it provides statistics e.g. the number of milestones achieved compared to the number that remained that can be used to demonstrate the overall status.

How to set up schedules for integration?

Fundamentally in order to successfully achieve schedule integration there needs to be the following:

1)    A structure

2)    A set of rules

3)    ‘Policing’ of the rules

So firstly, the structure should be the hierarchy of the areas, functions or work streams and based on the project delivery strategy.  Within each part of the hierarchy there needs to be a set of activities that are logically linked with checkpoints and milestones at the appropriate points.

Secondly, the rules should include:

  • An identification of which area the schedule is from i.e. a code relating to the individual schedules;
  • A data dictionary that identifies what information is required in which fields (and relevant to which scheduling tool you are using);
  • A definition of the entry / exit criteria for the milestones or deliveries so that there is consistency when marking milestones complete;
  • The limitations and boundaries of what can and can’t be changed (and who should review and approve it) which is a combination of configuration control and change control.
  • The cycle for maintenance and reporting or ‘business rhythm’.

These rules should be established as early on as possible and more importantly communicated to across the’ mega-project’ teams.  They should be easy to understand and apply.

Finally, having established the rules there needs to be a level of ‘policing’ and checking that the rules are being followed. You only need one area of the project to do something differently and the impact could be broad.

In some cases the checking can be an audit against a set of criteria which acts as a gate and defines the minimum standard that needs to be accepted before the consolidation is successful.  There are various tools that can automate this checking process to make it efficient and not too time consuming.

Benefits of schedule integration

  • The most significant benefit to an organisation for an integrated schedule is the increased visibility of the projects data.  This allows for summaries to be generated from a single location so it can be quicker to identify areas that are not aligned or builds confidence that the work is being completed as scheduled.
  • Organisations also can run audits across the schedule to identify errors or anomalies so benefit from having the data in a single location because it potentially reduces the number of times you would need to run the check.
  • Due to the discipline required for schedule integration the end result is likely to be more consistent across the different areas of the project.
  • Schedule Integration allows for interfaces and dependencies to be shown across the different components.
  • Schedule Integration provides the project with continuity when the individual team members change, which is a high probability when a project runs over multiple years.


Pitfalls of schedule integration

  • There is more preparation time required when collating the individual schedules in order to meet the required standards. This additional time should be allowed for when determining the update cycle.
  • Potentially there could be too much data to be able to identify the real issues – the focus could be more on the quantity of information i.e. milestone achieved rather than what the milestones are providing in way of progress.
  • The policing approach could be seen to drive a ‘box’ ticking mentality rather than addressing the schedule issues as the focus could be on the completion of the standards rather than what it is actually informing the teams.
  • With the details included in the integrated schedule there needs to be a simple way of summarising or filtering to show more manageable levels or else it could become unwieldy.
  • Additional information is required to be stored to ensure that when team members change the assumptions and basis of the schedule is not lost.



To conclude I think it’s fair to say that there are instances when an integrated schedule can be beneficial to an organisation because the project has resulted in a successful delivery with thousands of lines in an integrated schedule.  The key to handling large quantities of data is to ensure that you have the required skills within the team to ensure that it doesn’t become out of control.  Finally the important point is to remember that it’s best to agree from the start whether the scale of information gathered can be constructively used as this will avoid the debate of ‘quantity’ versus ‘quality’ in the schedules.

A baseline is a line that is being used as a base for future measurement, i.e. a reference. Usually known as project baseline, it is a must for anyone or a company that wishes to monitor and evaluate the success of the project. Without it there is no possibility to compare the current status of the project with the initial estimated one. Read more

In the years I have dedicated to project management of rail and airport projects, I’ve come across several type of planners, from inexperienced to seniors, and from some of them I heard the expression “my programme says we are going to finish this activity by [certain date]”, when talking with  the project manager or other stakeholders.

Read more

The pros and cons of the major Planning Tools

Read more