The growth over the last 20 years of the use of project management software has been a success story. Many project managers and end users now routinely use and rely on software like MS Project, Power Project or Primavera P6 to schedule their projects and the days of manual bar charts in Excel are thankfully receding into the distance. However, whilst it is easy to put a basic programme together, there are some common scheduling errors and misunderstandings that I routinely come across when reviewing programmes for litigation, arbitration and claim cases.

The first common error is not linking the activities together correctly. Most people can understand the concept of durations and logic relationships, and generally they link activities with Finish-Start relationships without any issues, however once they start using Start-Start relationships for example, they often forget that the finish of an activity still needs to be linked to a successor or dependent activity. If the end is not linked, then there is nothing dependent on the finish of that activity including the project end date!

Activities that have a ‘loose end’ are called dangling and a quick check to see if all activities (other than the very first and last activities in the project) have both a predecessor and successor can avoid many later problems. If there are no suitable successor activities, then you can always create a new milestone specifically for rounding up the loose ends in a section of work, but don’t forget to then link this milestone to project completion.

I came across this exact situation of missing links in an arbitration case a couple of years ago, where the contractor’s main argument was that an employer delayed activity was driving the critical path and hence the project completion. Upon examination of the programme, I discovered that the ‘delayed critical’ activity was not actually linked to any successor activity whatsoever and hence it could not strictly have delayed the project completion. In fairness, I also took a copy of the programme and added the missing link to its correct successor and the ‘delayed critical’ activity still did not drive the delayed project completion. Needless to say the contractor’s claim did not succeed and a simple internal review of the programme in advance, could have saved them a lot of legal fees.

Other common programming errors include adding too many constraints like must ‘finish on’ or ‘must start by’ a particular date. The more constraints on a programme, the harder it is for the software to accurately schedule your programme and calculate the true critical path to achieve the quickest project completion date.

If you are delivering projects in a commercial client/contractor environment, then it is essential to update the programme regularly and keep an archived copy of each update. If a dispute arises later in the contract, then it is often the side that has the better record keeping that wins, purely because they can demonstrate the facts behind their arguments, by referring to historical contemporaneous records.

Whilst many projects are competently planned and colourful bar charts proliferate, once a project is planned, I frequently observe a huge gap in the correct use of programmes to actually manage the project.  Too many times in arbitration and project audit assignments, I come across the situation where the original baseline programme is waved around as a contractual record and only ever updated when a key date is relaxed, or an extension of time granted for a late completion date.

A project programme is a living document and one of the strongest strengths of all modern PM software is the ability to re-forecast the outstanding activities after current progress has been entered. This means that you need to regularly update the actual start and finish dates for started or completed activities and forecast what percentage or duration of the activity is still outstanding.

Modern contracts like the NEC (New Engineering Contract) proscribe not only the contents of what a programme must contain (logic linked activities, completion milestones etc.), but also mandate the regular updating and use of a programme to anticipate problems and pro-actively manage the project. In the NEC contract the programme is at the heart of actually managing the project and all variations and scope changes are measured against the latest officially agreed (in NEC parlance ‘accepted’) programme. The programme is termed the ‘beating heart’ of the project and requires to be managed on a weekly if not daily basis, so it’s important that Contractor’s allows for this when tendering. Foremost the programme under the NEC (and for that matter any contract) is there to record and navigate the project to a successful conclusion for all parties benefit and not for the benefit of one party or the other. There is even a clause under the NEC that allows retention of up to 25% of payment, until the contractor submits an initial contract compliant programme.

Most users can understand and update the actual start and/or remaining effort required for an underway activity, but once you have done this, you MUST re-schedule the programme to tell the software what date the progress is recorded to. This is known as updating the ‘data date’ or ‘timenow’ or similar terms depending on the particular software. At that point, the software can recalculate start and finish dates based on the simple premise, that ‘if you haven’t started an activity, then the earliest it can start is tomorrow’, subject to your programme’s logic of course. If you don’t reschedule after each progress update, then it can have serious implications for your understanding of where your project status really is.

For example, I did an independent review of a contractor’s programme for a utility company to verify whether a contractor was going to deliver a complicated piece of equipment in the next 3 weeks. The contractor’s young PM had correctly updated each activity with progress but either due to inexperience or lack of formal training, had not rescheduled the programme each time. On his programme, there were design activities that should have completed 6 months ago that had not yet started but his planned completion date was now only 3 weeks away. Upon updating and rescheduling the programme to the current date, I was quickly able to demonstrate to him that far from delivering in 3 weeks’ time, he was actually 9 months behind schedule. As you can imagine this came as quite a shock to everyone and unfortunately resulted in a few personnel changes by both client and contractor.