How to Break Bad News About Shipping Software
Imagine you're working on a major project such as Healthcare.gov. Suddenly, you realize there's no way the software will be done on time -- or even work. What do you do? Hear how veteran testers, project managers and developers tactfully handle such situations.
Thu, January 23, 2014
CIO — With 250 project managers in the audience, Richard Sheridan asked the certified project managers to raise their hands. Those who had never had to fake project data, not once, in any way, were told to keep their hands raised.
Every single hand went down.
You'll also notice one key phrase in Sheridan's question: Had to. As in, the project managers had to fake project data.
Did they really have to fake the data? What would have happened if they hadn't? It's possible to tell the truth about a project's status and keep your job, right? If so, how?
This article will put you in the driver's seat as a project manager faced with the reality that a project won't meet expectations, along with an executive team that doesn't want to hear that the sky is falling. We'll help you deal with it while keeping your integrity.
Forget PMBOK, Look to PMI Code of Conduct Instead
Joel Bancroft-Connors is a program manager for EMC. He's also a certified project management professional, a PMP. When I ask him about this kind of issue, he doesn't point me to the Project Management Body of Knowledge (PMBOK) but, instead, to the Project Management Institute's Code of Conduct and Professional Ethics.
Bancroft-Connors tells me the questions of "Do I tell?" and even "What do I tell?" aren't as cut and dry as they might first look. What the project team tells its PM often comes with an implied confidentiality, much like a doctor/patient relationship. Revealing things told in confidence can destroy trust and morale.
Company standards represent another often-ignored issue. The company, or at least management, should provide contributors guidance on how to communicate problems when they occur. Bancroft-Connors describes one large program where the policy was only to inform the client organization when the schedule was clearly in the red. By then, though, it's too late: Finger-pointing and blamestorming displace getting real work done for some time.
Following policy, Bancroft-Connors informs his superiors each step of the way and tells the client when it wants to hear from him. Over the years, he has increasingly received project information that's visible, in the form of a burn up chart, and eventually made it continually available to the client.
With the tools in place for the client to view progress all the time, there's no expectation gap. The client can see performance, make predictions and, if things aren't going well, the client — product management, marketing, take your pick — can suggest corrective action.