One of my assignment of the last few years was to help an organisation with the delivery of a project that was having too many RED lights in its status report.

I jumped in as the new project manager with some milestones already missed and only a few weeks to recover the situation or at least to show strong improvements.

The project is a fairly short one – 6 months – and it is more or less risk free as no elements of the delivery are new to my organisation: it’s is about installing an upgrade of a product to a new set of hardware. I arrived in the middle of the customer acceptance of the test bed system – which was running late by 2-3 weeks. The project is business critical for the customer so this delay was a big issue.

The good thing about joining a project that is in trouble is that you can’t really be blamed for the problems. But as you join in a lot is expected from you and you have to strike a correct balance between ‘re-planning’ work and working on immediate fixes and this can be challenging. This is particularly true for small-medium size projects: one week, one day can make a lot of difference and so you will need to get into action very quickly. So the bad thing is that you are going to be under loads of pressure, really quickly.

Issues

Most of those issues were about lack of control on the project execution rather than a bad planning from the outset, particularly deficiencies in the day to day management of staff and lack of communication:

• the engineers doing the work were not aware of the project milestones, made it worse with engineers not communicating a lot back to the management,
• some engineers do not have the relevant experience: too junior or lack of expertise in the product being installed,
• the communications on some key product characteristics was not done upfront,
• scope: underestimate the work and importance of configurations migration from the legacy systems towards the new and no systematic approach taken to manage this migration In a sense the project was so ‘easy’ that everybody kept their eyes off the ball.

Critical Success Factors

With those issues in mind, I thought the critical success factor to binging this project back on its schedule and quality would be:
- On site engineers have the right skills and are ready to put in extra hours so that we shorten the duration of the project,
- We need to master the configuration of the systems,
- The communication within the team and towards the client needs to be direct, quick and open so that issues are rapidly shared and addressed.

Based on this here are the actions I took in the first 2-3 weeks:

• Review resource assignment to ensure the 2 most senior engineers were committed until the end of the project,
• Rework the plan bottom-up: by working closely with the engineers on the new plan, as a result, we changed the initial approach to validating the new systems and run the acceptance in parallel instead of sequentially,
• Secure week-end working for on-site engineers,
• Get active participation from the support and maintenance manager so that we could 1. facilitate the transfer to support and 2. actively manage open issues,
• Coach the engineers on the importance of communication and configuration management,
• Unfortunately: do a lot of micro-management.

Results

Those decisions paid-off. We actually delivered the project on time, arguably with one major product issue open that we agreed to fix a few weeks after the product has gone live.

Reflecting on this project I think it was not very hard to fix and most issues were around communications and those issues could be fixed relatively quickly.

This example goes to show that soft skills and communications are crucial to projects success and when you get them wrong then there is a good chance of failure, however simple the technical aspect of the project might be.