Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to break bad news about shipping software

Matthew Heusser | Jan. 24, 2014
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.

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

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.

 

Previous Page  1  2  3  4 

Sign up for CIO Asia eNewsletters.