Contribution by Ian Mackay
In response to the recently published briefing concerning the use of critical path networks in extension of time claims (Lester, 2010), I do not agree that insufficient thought is given to the drafting of programmes because they are in bar chart form. The reason that insufficient and poor programming occurs is because project teams don’t invest enough time in thinking ahead. This is either due to there not being enough detailed information to work with or by a neglect to properly think through the construction process. Project teams also fail to properly monitor progress and update the programme when required with the result that the original programme quickly become obsolete and therefore ignored.
The reason that linked bar charts are preferred over network diagrams is because they are easier to understand. They are also better at communicating the requirements of the programme if only because pictorially, long bars mean more time than short bars. Modern programming software is able to code, group and filter programmes so that they can be communicated to all parts of the project team, this is what makes the bar chart an effective project management tool.
The production of a detailed network diagram at tender stage may be desirable but is generally unrealistic due to time constraints and a lack of information, for example, subcontractor input. Further, the creation of an overly complex network of activities at tender is likely to be significantly flawed with the result that the programmer misses the main point of the tender planning exercise which is to use best judgement and experience to determine the critical time periods.
Linked bar charts produced using current programming software are extremely effective in being able to prove cause and effect in a delay claim because they are able to show a graphical representation of events which is easy to understand. Provided the computer software files are available, properly logic-linked bar chart programmes can be rigorously interrogated and challenged to determine whether the analysis provides a reasonable interpretation of the events which occurred. The attached section of a linked bar chart shows how the impact of a delay event against the baseline programme can be demonstrated (Figure 5). The critical path is clearly shown as well as activity float, slippage, future logic, as-built dates and the as-built critical path. A record of changes to the logic of the programme is provided by using the link category facility.
Judges, arbitrators and adjudicators are often sceptical of programmes when they are used to prove cause and effect in disputes. This is not due to a lack of complexity in the programmes indeed scepticism tends to increase with the volume of data which is submitted. A successful presentation of the facts depends on recognising what is important and then providing robust back-up to the durations and logic on which the analysis relies.
The most telling evidence that construction people understand bar charts rather than network diagrams is reflected in the sales of the various planning software packages.
Author's reply
I agree with Ian McKay that some planners ‘neglect to properly think through the construction process’. This is precisely why critical path networks were developed. A critical path network is not just a planning tool, but it is also a focus for discussing and evaluating options and alternative methods. Because of the involvement of the participants in the planning process, the very drafting engenders a team spirit.
I also agree that many computer-generated bar charts are not updated regularly, but while such an update will give a new end date, the computer cannot re-sequence the other activities to get back on programme. This can only be done by human intervention and the existence of a network greatly facilitates this. As an adjudicator I find that many of these, often very sophisticated, bar charts were produced either only at the initial construction stage or worse, only retrospectively for the purpose of the adjudication.
Described by the managing director of one of our major construction companies as the biggest development for planning since the pyramids, it is regrettable that with the development of computerisation this core activity has been relegated to a ‘nice to have’ option, when it should be the first task of any planning operation.
My experience as a project manager with three very large international civil and petrochemical contractors, responsible for projects, some of which had a contract value (current) of over £1 billion, convinced me that the drafting of the design and construction network [albeit activity on arrow (AoA)] at a planning meeting attended by key managers and selected members of the team, enabled the optimum solutions to be obtained. On all these contracts, which included oil terminals, power stations chemical plants and cement works, all the programmes were manually drawn AoA networks with the computers only used for the number crunching. In other words, the network was produced before computerisation.
The fact that most computer systems generate the activity on node (AoN) network after the analysis (if at all) shows just how topsy-turvy the process has become.
Most of these projects were actually completed by or before the scheduled end date (usually client imposed). This was due to most of the programming snags having been resolved at an early stage. In some cases even major late design changes were planned into the programme at similar meetings, without over-running the original time. It is when things go wrong or unforeseen problems arise that a network comes into its own.
Once a contract was under way, copies of the original and each subsequent issue of the network were retained. This enabled the changes and their effects to be easily compared and costed. This was made even simpler when the network was drawn on a grid. When combined with an earned value (EV) system, justifiable claims could be easily proven while unsubstantiated ones could be equally easily rejected.
No bar charts were produced for either the design or construction stages. Everyone on site, down to the foremen and charge hands, was familiar with networks. It is of course largely a matter of how a system is taught and explained and to what extent people are encouraged to become involved. At site level, the foremen were invariably involved in the production of the site-generated sub-nets, which were an important focal point for resolving timing and access problems.
Therefore, I cannot agree that linked bar charts are easier to understand than network diagrams. A few years ago we carried out two experiments which showed the opposite to be the case. We supplied two construction sites, (one, a civil and road contract in Surrey and the other a refinery in Pembrokeshire) with the construction programme as both a critical path network (AoA form) and the corresponding bar chart. Both programmes were pinned to the site office wall and the site management was given the option to update one or the other on a daily basis and report progress weekly. In both cases all updating was carried out on the network. The bar chart was completely ignored by the site staff.
I am fully aware that computerised planning programs are now the norm, but I wonder how many are only used as bar chart generators producing ever more sophisticated outputs. Unless the input is based on sound logic (for which a network is the best vehicle) the results do not inspire the confidence of the user. I suspect that the introduction of the AoN network is to some extent to blame, since it does not lend itself so easily to conference planning. It is for this reason that the Lester diagram was developed, since it combines the easily understood information layout of an activity on node (AoN) network with the ease and speed of drafting of an AoA diagram.
I agree that regular feedback and updating is essential. This problem was completely overcome by the introduction of EV analysis on all sites. As the ‘percentage complete’ of each activity had to be shown on the weekly time sheets, an automatic feedback for updating the network became available because every activity on the network was in the EV system. The time sheets were processed for bonuses on the Friday and by Monday morning the site manager had a complete computer-generated report showing the current progress and cost of all the work areas. This included all subcontractors, who were contractually obliged to use the same EV system. As every activity was individually analysed in terms of cost, percentage complete and efficiency, bottlenecks and overruns could be immediately targeted and resolved. The set of curves generated by the computer showed very graphically if the trends were up or down. These curves were also produced for each subcontractor, so that inefficiencies became immediately apparent and undoubtedly discouraged the development of spurious claims.
