Plan the Work and Work the Plan

Well, hello again everyone, hope everyone is well.  My apologies for length between columns, hopefully I can make up for the lost time here this month. 

The main purpose of a punch list is to identify project items that need to be completed or corrected right?  But we should also use those items in future applications, so we do not repeat the failures of the past.  In this industry we barely have enough time and money to do it the first time – it is imperative to do it right the first time.  And one of the things as industry professionals we can do right the first time is the project schedule. 

Henry Kissinger said, “If you do not know where you are going, every road will get you nowhere.” True statement in life, even more true in the world of project management.  An integral part of the project management process is ensuring schedules are properly developed, tracked, and reported correctly.  As stated in the current CSI PDPG – Chapter 2 – Section 2.2.8 – “A good project schedule clearly identifies the owner’s project delivery requirements and provides a tool for managing each phase.  It serves as a road map, plotting out a logical succession of steps, from which a series of smaller, more specific tasks emanates.” Sounds like a good way to figure out how to get from concept to an occupied and operational facility doesn’t it? 

Over my career I’ve spent a good amount of time working in the realm of project controls.  Specifically, the scheduling arena - developing detailed project schedules, updating, and analyzing them, and implementing best practices to ensure consistent applications within organizations so the project team has a clear vision of where it is “going” and how it is going to “get there.” 

Recently working with a wide variety construction team across several projects of varying complexity, and conducting lessons learned from those projects, a glaring trend of concern was the quality of the project schedule and its impact on a successful on schedule completion.  What did I find? A poor project schedule is a recipe for disaster.  Contract language and type can dictate what party is responsible for developing the project schedule or a particular phase of it – but a few best practices I have implemented recently and few basic truths as I like to call them have helped improve the overall delivery of recent projects. 

A few best practices I have seen implemented recently with great success are: 

1. Including a Project Schedule Development Plan as part of the Project Schedule requirement.  This document explains who will develop the project schedule, required software vehicle, various reporting levels based on stakeholder needs, schedule impact mitigation procedures, and reporting frequency.  Having this established early on the in a project and adjusted as the project moves through its phases helps identify the “who and what" for everyone involved.
2. All significant decision gates (funding approval, submit for permit, Notice to Proceed, etc.) should be included in the schedule as Milestones.  Milestones always have a 0 day duration. When the schedule float logic is computed, it will show these activities as critical path items – meaning they have do not have any ability to move beyond their completion date without impacting the overall completion of the project timeline. This will draw the focus of the team to these items and spur discussion.
3. Activities with a duration longer than 5 days should be broken down into multiple activities. For example rather than "Install Metal Framing - 25 days" - say  “Install Metal Framing PH1 – 10 days”, “Install Metal Framing PH2 – 15 days”. By breaking activities into smaller phases, it becomes easier to see schedule impacts in the event of slippage and how it will affect other portions of the work independently. 

A few of the basic truths of scheduling I have come across in recent months are: 

1. If you put garbage in a schedule, you get garbage out of it.  Logical connections between activities, proper sequencing of activities, and realistic activity durations are a must.
2. Start all activities with a verb – so direction is clear.  For example, instead of saying “Perimeter Footings Column Line A1 to B1” – say “Excavate Perimeter Footings Column Line A1 to B1”, “Pour Concrete – Perimeter Footings Column Line A1 to C1”.  Non-descript activities leave too much open to interpretation.
3. Tailor schedule reporting to the need of the stakeholder.  Not everyone needs or can understand the schedule data at deeper levels than a Level 1 or 2. For owners I have found high level milestone schedules, phase summary schedules, and “red, yellow green” status works best to communicate overall progress.  
4. The project schedule is a fluid document – it moves as the project moves and must reflect that movement, whether positive or negative, to allow the best decisions to be made in interest of the project. Don't fudge it. 

So don’t be afraid to push the envelope when it comes to project schedules - no matter your role on the team.  Remember it is usually the question that is not asked that dooms!  Hope this is of some to use to everyone and can help you in the future!

Till next time….
Mark