How Do I know My Project Is Really On Track?

Any PM practitioner always has one paranoia to some degree which is ensuring their project or program is on track with budget ($/people) and schedule at any point in time during the life or lifecycle of the project.   PM’s use scheduling tools to varying degrees to manage their project. I’ve seen PM’s use a simple word document or excel spreadsheet of their own design to a detailed task level resource driven project schedule and successfully managed to their expected outcomes.  I think it’s scalable to the size of the project and the experience of the PM.  However, even the most detailed schedule depends on the discipline of the team to provide accurate and timely updates estimating their progress to date.  Even though at the current point in time all looks good, it’s the forward view of the next tasks and the competency of how well they were scoped, estimated, and resourced to see the reality of predictive negative or positive consequences with the remaining work.  Any change – and change will happen, can very quickly change the dynamic of the project.  I can sum this up in a few commonly known project ‘laws’ as follows:

-       “Work expands to fill the time allotted – Parkinson’s Law”        

-       "If it can go wrong it will - Murphy's law."     

-       "If it can't possibly go wrong, it will - O'Malley's corollary (result/outcome) to Murphy's law."     

-       "It will go wrong in the worst possible way - Sod's law."            

-       "Murphy, O'Malley, Sod and Parkinson are alive and well - and working on your project."

Have you even been on a project where everything is going just, ‘too good’ and the team starts getting nervous as something unpredictable has got to happen?  We missed something… we lose a key team member… the external environment changes… there’s a ‘act of God’ (common reference) such as bad weather causing damage to the facility…or my favorite, ‘differing site conditions’.   I know this is IT project centric, but I started in the construction background and I love to read those stories describing that during an excavation for building foundations to a new building a construction worker notices some bones or items and they come to discover it’s an old burial site also potentially filled with historical artifacts.  Therefore work is stopped temporarily as now it’s an ‘historical archeological site’ and until fully investigated – no one is doing nothing and interest is building on borrowed money to finance the project along with proportional delays until the project can start generating expected benefits.

To a degree it happens in IT projects when an external vendor delays the release date of a product or software that was a dependency to the project.  As decision is made to go with existing, do a work around, put the project on hold and wait, or cancel the project and reassign the team to the next priority project.  I have to believe in the ‘butterfly effect’ or chaos theory which simply defined states those small differences in the initial condition of a dynamical system may produce large variations in the long term behavior of the system.  In other words can a minor misinterpretation of the initial scope statement cause a large impact later on during the execution phase of the project? Of course as minor mistakes always occur in a project but its how well the team reacts to the discovery and rallies to identify a solution and impact analysis to the project parameters.  It’s a continual dynamic which is why poor communication is almost always listed as a basic cause of a project failure despite the extensive use of OneNote and continuous update emails.  There’s still a gap from the time the problem is realized until the time the team is communicated about it and then can react to it.  All h time the problem is still there.

So where am I going with all this? Keep in mind that ‘blogging’ is not an article but a written conversation so it’s ok to go off into tangents.  Point is that the PM never ‘really’ knows how well the project is doing until it’s completed and the entity (customer / stakeholder) receives the benefit from its use.  The simple rule of thumb is to get as far as you can on the project at every opportunity without the customers/stakeholders thinking you padded the schedule and officially ask you to pull it in.  It’s not often that happens as usually a PM gives a near best estimate then the project team works like hell to get fairly close to the goals when in actuality in most cases they exceeded it then with little rest go onto the next project .  Ah yes – now you get where I’m coming from – been there – done that – got the T-shirt.  Perhaps now if I add another Project Law of, ’The 1st 90% of project takes 90% of the time and the last 10% of a project takes another 90%...’, you factor in that PM paranoia now knowing that despite all the metrics on linear timeline, that last part of the project integration when any/all mistakes made prior will now expose themselves and will need to be dealt with as we go into mini-crisis mode working late hours. Sometimes I think ‘Pizza Delivery’ was one of the best inventions, right after ‘beer’ which is great to celebrate with (in moderation of course and always have a designated driver) after the PIR (Post Implementation Review).  As always, I’m hoping this blog post will generate comments and I’m interested to hear what other PM’s think.  …JGH (or the PM Pied-Piper as I was recently given the moniker.)