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.

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

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.

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.