No one likes surprises, least of all executives who might have given high-level commitments on project delivery to their peers in customer organizations, investors or other key stakeholders. I holdÂ Project ManagersÂ largely responsible for poor â€˜bad news managementâ€™. In most cases, there are half-baked estimates that never are a firm basis for project planning to begin with, or there are inaccurate project metrics that lead to an ambitious planning. During project execution, Murphy strikes and then the fun begins – the project manager is fighting a losing battle but is not willing to admit that (professional’s ego?), nor is he asking for help! The result is a blindly predictable situation where it is too late to do anything anymore. Could this have been avoided? Well, its possibilityÂ surely could have been lowered, even if not eliminated 100%.
My advise on how to minimize ‘bad news’ events would consist of:
Donâ€™t rely on bravados. They might be ok for a weekend to complete a build, release some critical feature or deliver some part functionality, but to rely on them for anything larger and non-trivial would be setting up for grand failure. It definitely is not sustainable in the long-run.
Remember Fred Brooks when he said â€œhow does a project gets late by a month – one day at a timeâ€. No one likes to know about a project that suddenly pops up with a one-month delay. If thatâ€™s what you report, donâ€™t expect any sympathies or support. Period.Â This typically happens when the project manager continues to have blind hope that the schedule he lost earlier would be recovered subsequently by some stroke of luck, magic or overtime, or all three. However, in reality, it just doesn’t happen. While you might be able to bring back some of the tasks on track, the time lost one day at a time just can’t be gained one month at a time without doing something radical like dropping a key feature, but not definitely by adding people (because that’s when you meet Brook’s Law).
Donâ€™t overstuff your plate. It is very tempting to fill up the plate because that showsÂ manager and team in a very good light – you know, like shining as a ‘good corporate citizen’ who understands company’s obligations to its customers and so on. However, non-essential features eventually take up lot of design, development and test effort relative to the value they provide to the customers. They also unnecessarily elongate the development cycle without creating an opportunity to get real customer feedback if those features are required at all. A project manager must do effective gatekeeping.Â
Use enough prototyping and feedback cycles (like Agile development methodologies in software development).Â Â
There are perhaps many more, but you get the idea – it is possible to reduce ‘bad news’ possibility for your project without hurting project goals.
That said, if there is a bad news, no point in covering it up, or externalizing the faults. Own it up as the Project Manager in-charge Â â€“ no one is going to hang you up for that. However, be prepared with an extremely thorough analysis of how the problem could be fixed, and the support you require from senior management to make it happen. Involve your team into a complete commitment to the revised proposal before discussing with the upper management. Also, try to explore multiple options and not a single-point solution â€“ giving multiple solutions not only shows your analytical ability and intent, it also gives flexibility to upper management to take the best possible option. Finally, donâ€™t go to your management as a postman and deliver bad news â€“ go to your management with solutions and explain your preferred solution and various pros and cons.
A few years back, while working with a group in Germany, a project manager colleague of mine overcommitted on a delivery and decided to deliver the code against recommendations of his team. It was actually â€˜codeâ€™ only â€“ as it was not even compiling. I was the Quality Manager and I was not made aware of the delivery. When my boss came to know, he was naturally furious. However, before talking to our peer in the German office, we first sat down and made a careful plan to fix the problem. We got the team involved in it, and once we had a plan, we called up our German colleague. The fact that he was upsetÂ would beÂ a gross understatement, but we worked sincerely to make up for our mistakes. In another case, during early phases in another project, the technical team delivered a high-level design that was a complete fiasco. The team in headquarters was extremely doubtful if we even understood the problem. In the morning, my boss pulled me in to that project and that evening, we were in the flight to Amsterdam. Next morning, we had transparent discussions with our peers in the Business Unit, and by afternoon, we were discussingÂ high-level project plan. In both these cases, we hadÂ serious project problems, in one case in the delivery phase and in the second one during initiation phase itself. However, in both cases, we were confronted the issues as soon as we came to know about them, and without neither defending nor externalizing our initial actions that resulted in this problem, we worked towards finding a solution to the problem.
Failing first time is not a crime and almost everyone is entitled to a second life, but donâ€™t expect a third life. That happens only in video games. In real-life, bad news will happen, but it can be managed much better if people are willing to keep project goals in the forefront and do not go about taking hardline positions. With sincerity and a willingness to fix the problem, we can improve our ‘bad news management’.
So, how good is your ‘bad news management’ ?