Practical Progress Reporting

Here in the real world of Contract Employees it is very common to arrive on a project when it is part-way through.  For those with experience in Planning and Scheduling, you’ll identify with my statement that getting the best out of your software is part art, part science.  It sucks to pick up on someone else’s planning work and try to figure out their mental processes to fully understand how their schedule operates.  But that’s a discussion for another time.

For today, I have a story…

There I was, new on the project, still feeling my way around the schedules and the people, and one of our main contractors presented me with an MS Project schedule that was worth less than toilet paper.  I’d had no time to familiarise myself with the history of the project, no real chance to understand the personalities I was dealing with, but enough time to know that my predecessor had left a mess and it was now MY job to clean it up and make it work.

There was just not enough time available for me to ease into the system, and the shutdown was fast approaching, so I had to wade into the team members with my steel-toe boots and hope for the best.  I called a meeting to lay out my expectations, needs and boundaries regarding the planning and scheduling for the rest of the project.  The people I brought into this meeting were:

  1. Our construction manager
  2. Our 2 lead superintendants
  3. The construction managers of our main contractors
  4. The planners of our main contractors
  5. Our Client’s construction manager
  6. Our Client’s project manager
  7. Our Client’s planner

Before calling the meeting, I briefly discussed my intention with my construction manager (CM).  All I really told him was that the construction schedule was in bad shape and our contractor’s planning & scheduling skills were badly lacking.  I told him I needed to get all the parties around one table so that I could lay out my requirements.  I did not tell him what I was going to do and say, although I did tell him that I would be embarrassing some people by showing up their shortcomings in public. All credit to my CM – He and I had never worked together before, and this was the longest work conversation we’d had up til then; he did not ask for details, he just nodded and said “Do it.”

11h00 the next day I put on my virtual armour and proceeded to shred the schedules with no attempt to lighten the blows as I destroyed the work done by our client, my predecessor and the contractors.  It could have been my last day on the job (In fact, embarrassing the wrong people has lost me jobs in the past), but life is just too short to have to work with rubbish every day.  I pointed out where the various schedules were impossible, illogical, Construction Project Softwareunrealistic, stupid, insane, ridiculous, and the occasional section that actually made sense.  I explained certain practices that would absolutely be rejected and showed examples of them in the schedules.  I also made it crystal clear that I would help all who needed guidance on how things SHOULD be done.

I remember seeing our Client Project manager’s face at one point – He was aghast, incredulous, even shocked.  I had just made sweeping statement along the lines of “I don’t care if you report an activity 40% or 60% complete, it’s not important”.  He relaxed a little when I followed that statement with “what is MOST important is a reliable forecast date particularly when it affects other parties.”

So how can I say % complete is not important – I didn’t.
I said % complete on each activity is not important, but that is subject to certain conditions being met.  A loose rule of thumb that I work on, is that activity durations should generally be no longer than 2 reporting periods.  So if the schedule is updated and reported on monthly, activity durations should not be longer than 2 months.  If the schedule is updated and reported on weekly, activity durations should not be longer than 2 weeks.  This effectively creates a situation where an activity’s status during an update will be

a.)    Not Started

b.)    In Progress (a maximum of twice only, but generally only once)

c.)     Completed

The vast majority of the activities in the schedule don’t change status during an update while some change from Not Started to Completed.  During every schedule update there is only a small portion of the overall schedule’s activities that are actually IN PROGRESS at the time.
For example – IF 15% of the schedule’s activities are in progress at the time of update (very unlikely), and IF I over report them by 20% each (also very unlikely), then in simplistic terms, the project overall percentage could be wrong by about 3%.

It is WAAAAaaayyy more important to spend time establishing accurate date forecasts that getting individual percentage figures more accurate than 20% or so.  It all comes down to this – Progress updates are 30% about identifying where we are, and 70% about establishing where we are going.  All things considered, how much can we affect what has already happened?  Let’s not get anal about the small details of last week.  Let’s rather spend useful time identifying what’s coming towards us and attempt to intelligently prepare the team for tomorrow, next week and next month.

I am definitely in favour of accuracy in all that I do, but often “accurate enough” is worth more in practical terms than “absolutely accurate”.  Think of it as a tolerance in engineering design – Structural steelwork is generally accurate enough if it is within +- 1 or 2 mm.  It would cost too much time and money to ask for steel to be accurate within 0.5 mm.

Well, I stayed on that project until the end, and the client even asked me to help them on other projects, so you judge for yourself – do you want to be right or effective?


Share this post