Here’s a little story of a project I was recently involved in. I always enjoy the chance to watch and learn from other people’s work, so with an external Project Manager I was looking forward to this one.

Things started well with all parties coming together to form the project plan. One thing that stood out on the plan was that it didn’t include any testing to show that the implementation had been successful. Whilst this concern was raised, nothing changed. Otherwise, the plan looked reasonable with various check points and milestones along the way.

Everyone signed up and off we went, full of optimism and ready for the challenge.

Pretty soon we hit problems, certain tasks were delayed and unexpected items cropped up that needed to be dealt with. Nothing too unusual there, however, instead of re-planning or executing contingency plans we simply proceeded as if nothing had changed and pushed on as best we could.

I was amazed that the original plan still stood, but even more amazed that the go-live date of the project was still achieved. Was the PM a genius for getting it this far or was he stupid to ignore the warnings along the way? I’d have been pushing hard to act upon the various setbacks we’d had on the project. Questions such as “Can we have more time?” and “What items can we cut from the first phase?” would have been asked. My approach would have been to get the bad news out early and reset expectations – better to give all the stakeholders as much warning as possible and opportunity to adjust their own plans. But maybe that wouldn’t have been right, after all this project still achieved its go-live date without having to change plans or cut items.

Well, having spent the past few weeks living through the consequences of this false go-live, I’m pretty sure the PM was not a genius!

All sorts of senior people got dragged into a project that they didn’t need to be involved in. If the original plan had considered how the end results would be tested and assessed the risks of needing some time to adjust the solution then additional time for user acceptance testing and rework would have been added and the eventual timescales would have been about the same. However, instead of creating the extra stress and bad feelings, everyone would be pleased to see the project on plan!

Here’s where I think the project went wrong, and I think this is a common mistake. A project plan is your best estimate towards reality. It is there to help you make sensible decisions that you otherwise couldn’t make unless you knew the future. A project will always take as long as it takes. Always. That’s worth repeating, a project will take as long as it takes. You might not like that fact, but it is a fact nonetheless. Your plan has little influence on the time a project takes, so you are best getting the plan as accurate as possible instead of as short as possible. Of course you can change the parameters of a project; deliver less, lower quality, assign more people, but these are so much harder to do once you have published the plan and formed a commitment to the stake holders. Your skills as a PM are often judged on how close you can make reality fit your plan, but really all you’re actually judging is how well you produced the plan in the first place!

The warning signs were there throughout the project – tasks were 90% done, but not complete. Everyone reported only what they thought the PM wanted to hear, not the truth. Once the project became live, there was nowhere left to hide and so it wasn’t pleasant viewing.

So here are the lessons learned:

1. When starting a project consider the end goals and how you will check if they have been achieved or not.

2. Look at the risks to achieving those goals and make contingency plans. In this case running a backup system whilst the new one was being tested and reworked would have been a good plan. Alternatively, scheduling representative groups of users to trial the system in phases would have been a better alternative to a big bang where the whole project was either a total success or total failure.

3. Seek the truth on a project no matter how unpalatable that might seem. Request honesty when dealing with progress and risks, and reward that honesty instead of instilling a fear of failure.