I think it’s safe to say that nobody really enjoys hearing bad news. It’s especially hard if you’re the person who has to deliver the bad news, particularly to a superior. How will your boss react? Will you be the one held responsible (unfairly) for the project failure? These are all reasons for keeping the ‘bad news’ to yourself and letting those in charge find out on their own.
I’ll share a story about one of the first jobs I ever held, as an assistant manager at a summer swimming pool. My supervisor had a very hands-off approach to management and would often rely on me and the other assistant managers to handle the day-to-day operations of the pool. Whenever I would deliver less-than-favorable news to him, such as our pool vacuum breaking, or a health inspector dropping by to schedule a visit, my supervisor would literally stick his fingers in his ears and say “La la la la la, I can’t hear you. Taylor, you know how I feel about bad news. Fix the problem.” This put me in a very awkward situation, because as a high school student, I didn’t necessarily have the training or the authority to fix every problem myself, in order to shield him from the ‘bad news.’
Unfortunately, this type of management exists beyond the pool house and can frequently be found in the corporate world as well. In an environment where your reputation can mean everything, stakeholders can be very reluctant to receive bad news about the status of their project. The silver lining in this is that receiving ‘bad news’ isn’t necessarily always a bad thing. Allow me to explain.
Suppose a stakeholder is interested in delivering a software application with a lot of requirements and an overly aggressive schedule. As the project manager on the team, you start to realize that this initiative appears to be well beyond the scope of what has been done in the past. Perhaps if none of your team members take any vacation during the holidays and work 25 hours a day, you’ll be able to meet that schedule. Not only is that impossible, but it is extremely unreasonable to expect such miracles for a software development project when the proposal so drastically differs from the historical performance of past projects.
In such situations, a feasibility estimate can allow you to use ‘bad news’ to help establish realistic expectations for your project. This can be accomplished in SLIM-Estimate by simply entering a size, a productivity index, and a start date. You may also enter the number of available staff which will determine the rate at which the functionality can be built.
Below is a diagram showing the project lifecycle of a software application. At a size of 219,000 source lines of code, it would take 11 people about 15 months to deliver based on historical performance. It would cost about $2 million and the Mean Time to Defect (MTTD) would be 0.702 days.
But the stakeholder wants the application delivered in a year and there are no additional people to add to the team. As a project manager, you know that is unreasonable. Sure enough, when you enter those constraints into SLIM you get an error message saying that those parameters put the project in the impossible zone. It auto-generates several solutions that will try to satisfy as many of the constraints as possible, which you can present as alternatives.
The optimal solution that was generated by SLIM shows that the 219,000 SLOC project can be accomplished during a 12 month schedule, but at a cost. This project would require 108 people and would cost over $14 million, much more than the previous solution. Additionally, the MTTD would decrease to 0.182 days.
If you were to share these estimates with a stakeholder, it would definitely be eye-opening. By extending the schedule three months, the system will cost about $12 million less, would be more reliable, and you wouldn’t need to hire or contract out 97 additional FTE’s.
Delivering the bad news before committing to the work can facilitate establishing realistic project expectations. By determining what is and is not possible early on in the project lifecycle, negotiations can be made to help establish a plan for moving forward. Engaging in these discussions can make the difference between committing to a reasonable project scope and schedule versus committing to a death march.