How to Break Bad News About Shipping Software

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.

The story that Sheridan relates in his new book, Joy Inc., seems oddly familiar - especially given the recent failed launch of healthcare.gov, thewebsite of the federal health insurance marketplace.

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-Conners 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-Conners 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-Conners 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-Conners 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.

What if your guidance is simply, "Quit worrying about it"? Or, worse, "Fix it"?

When a service provider is guilty of willful deception and had no intention to honor the contract at all, we've entered different territory. That's fraud. In that case, it may be appropriate to go entirely outside the formal chain of command, as did the anonymous employee who reported Enron to the IRS back in 1999.

In an environment where workers are willing to commit fraud, stepping out is the ultimate act of bravery. The next piece of advice involves selecting a lawyer and understanding employment law. That's outside of this conversation. Here, we'll assume an early deadline when little was known about the project or its changing needs, and it's clear the project has finally hit the point where its original goals won't be achieved.

The Test Perspective: State the Facts, Let Project Owners Make Decisions

Jane Fraser is the head of testing for robotics startup Anki. Before that, she was a director of test for Electronic Arts, which at the time released a new game every six to eight weeks. Many times, she says, she made the mistake of believing that the development and design team could meet its deadline. "Being in test," she says, "guess who gets the blame?"

To succeed as an executive in software testing, Fraser quickly learned to be the one sounding the alarm - loud and clear. That is, she made it her role; that way, when it was time to speak, no one was surprised. Then, when a project was in trouble, she began to beat the bushes," as she puts it. "Tell people clearly: There's no way. No. It's notgoing to happen."

Over time, Fraser learned to change her style depending on who she's talking to. That means telling the right story to the right people, she says.

"To a QA director and up, it's about quality, and why the quality is not there," Fraser says. "To a development director, it's about the number of bugs and the speed that those bugs have historically been fixed. Those are the kind of numbers they understand."

For marketing, of course, it's about the customer impact. "A lot of that is giving [marketing] the information so [it] can see what will happen [and] change dates," Fraser says. It also helps to propose a realistic schedule early on. Tell the powers that be that this project is similar to one that took eight weeks with eight developers, she says, and they'll see why trying to do it in seven weeks with six developers "just doesn't make sense."

[ How-to: Adjust to the Changing Face of Software Testing ]

Fraser's goal: Get ship dates changed based on actual work facts. To do that, she used the data available to her - bugs and, as noted, similar projects. Not only did she make it clear in advance that that was her role, she also learned to tell her peer managers before sounding the alarm. That heads-up to development and project managers gives them a day or two to prepare their "side of the story" - keeping them as allies instead of enemies.

Fraser's examples are factual. She left it up to the product owner to decide if the product would ship. Her job was to inform the owner of the consequences.

Compare these comments:

• "The software will cause the application to crash, on average, every 20 moves, or 40 minutes of game play. And we'll have 12 levels of content, not the planned 20."
• "There are too many bugs. We can't go."

The first statement is factual. Who can argue with it? If senior management wants to ship, then, when the house is burning down because of software crashes, the problem becomes fixing, not blaming. That changes the role of test and QA from "find bugs and protect the user" to "provide information to decision makers."

That's great if you're a tester. What if your role is line management?

The Management Perspective: Reframe Progress as Problems to Be Solved

Johanna Rothman - author of Behind Closed Doors: Secrets of Great Management and Manage Your Project Portfolio, has been managing and consulting on software projects since the 1980s. She, too, once found herself in a hole. The first thing she did? Stop to figure out what was next, Rothman says, because she didn't want to stay in that place.

Rothman was directing a team of 80, bringing in dinner for everyone five nights a week. It was obvious that the team would miss deadlines, but in the 80s, it had no tools to know just how bad things were.

"We didn't know about velocity charts then. We didn't have user stories," Rothman says. "Even today, some people don't have requirements in the form of user stories. What they can ask is, 'How can we show progress?'

[ Tips: 3 Ways to Be More Agile With Software Shipping Decisions ]

Take the requirements you have, in whatever form you have them, Rothman says, and make them features, in some sense of the word. "Customers, after all, buy features. Turn what you're doing into a feature. Then, show progress by feature." This will require working across teams, - but that's a good thing, she says: "Showing progress, and working through features, will start getting you places."

Once there was a way to measure, Rothman asked for release criteria. What really block the project from release? It might be a date. Healthcare.gov, for example, was going to ship Oct. 1, 2013, no matter what. The blocking issues might be core features, or a handful of things instrumental to the user experience. If you know the "have to's," she says, you can cut the "want tos" and refocus the team. That can change a lot about a project.

Tricia Broderick - the director of software development at Techsmith as the company planned its internal developer conference and now a coaching trainer at Santeon Group and chair of the coaching/mentoring track at target="_blank">Agile 2014 - also empathizes with those breaking bad news on software projects.

As a young manager, Broderick reacted to news that a project would be late by pounding her face on her desk. "That doesn't give the right impression," she says. "That will discourage that person. Next time, they won't tell me."

[ Related: Why You May Need an 'Agile Coach' (Whatever One Is) ]

Instead of starting a Yes/No battle over a date, a manager with responsibility needs to reframe progress as a problem to be solved. A team that's challenged to brainstorm can often figure out new and innovative alternatives that solve the core customer problem quickly, Broderick says.

That brainstorm can also include assessing the real situation - what the team can actually deliver by the deadline, for example, along with relative sizing for various chunks. The "chunking," be it story points or person-weeks, lets the customer shift the deadline to either include more or change what's cut.

Take Responsibility, Figure It Out and You Won't Lie - or Fry

We started with a problem. There's no way software will be delivered to meet expectations, and no one wants to hear it. The idea of breaking the bad news means conflict. Many people are conflict-averse. This results in hiding information or even faking project data. When I interview people who have faked project data, they always give the same answer - "I had to feed my family" - which implies that the choice is something along the lines of "lie or fry."

The experts offer a few suggestions for getting out of this bind:

• Bancroft-Conners, the PMP, suggests we find out the company standards for reporting these sorts of problems.
• Fraser, an executive in test, believes that tactfullysounding the alarm should be part of the test role.
• Rothman, the longtime manager, wants to find the real blocking conditions - ship date? core functionality? - visualize the work to be done and, finally, measure progress to drive the outcome.
• Broderick, the coach, wants to present options to the client, putting it back in the driver's seat.

That doesn't sound like lie or fry to me. It doesn't even sound like a conflict to be afraid of. Instead, it sounds like the way I've seen every successful project managed. Someone took responsibility, worked with the customer and figured it out.

The real dilemma isn't lie or fry; it's whether to take ownership. Faking the data ("Everything's fine!") and forcing an argument ("We'll never make it!") both omit a key factor in the conversation: You, and what you can do with the time remaining.

That seems like a fine way to deal with the expectations gap to me. What's yours?

You might not have to decide today, but you might be called for an answer - and soon. When you do, I hope this advice provides some comfort.

Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Read more about best practices in CIO's Best Practices Drilldown.