Who likes working on troubled projects? Fiona Charles does. In this column, find out why Fiona sometimes seeks out such projects and how she maintains the right frame of mind to allow her to solve problems creatively and devise tactical solutions to project issues. More importantly, you, too, can learn how to enjoy troubled projects and develop your project skills.
I like troubled projects. You may think that's crazy, but troubled projects offer tremendous opportunities for creativity and accelerated learning. The more problems a project has, the more opportunities for problem solving! I've worked as a test manager on several troubled project "rescue teams," and discovered a few strategies for surviving—thriving, even—while playing my part in a turnaround.
The Testing Hot Seat
Troubled projects are difficult for everyone, but present particular challenges for testers and test managers. When a project management team has skirted issues, testing often exposes the cracks. If the project has a history of missing or poorly understood requirements, cumbersome architecture, design problems, or overly-rushed coding, issues will accumulate, resulting in a system full of bugs. When the bug rate of arrival goes off the scale, testing slows down, and everyone's anxiety level goes up. Also, troubled projects are usually late; once they get into testing, the delay increases.
Just the Facts, Ma'am
When the emotional temperature is rising, only a clear and calm presentation of facts will bring it down. Testers tell you they can't test; everywhere they turn, there's a bug blocking them. All the while, everyone else says, "Why is testing taking so long? Test faster!" Your first priority is to get clear information about the quality of the system—or the current build—across as broad a range as possible. What's the smallest number of tests that will give you the most information the most quickly? Taste every significant component fast—run a simple end-to-end test through an application, such as the most vanilla sale and return through a Point Of Sale system; or, for a Web-based system, a series of quick dips into every page.
How you present the resulting information is critical. Ideally, use a format that gives a clear and comprehensive picture of system quality up front, and then keep using it to show progress and status. I use a colorful graphic table, designing it carefully to show simple categories of information across the entire application. Wherever possible, show the information in business terms, so it's meaningful to all stakeholders.
Play Nice with Others
To turn a project around, team members need to trust and be open to each other's ideas. Nothing destroys openness faster than blaming or dropping bombs on colleagues in meetings. It can be very tempting for testers to be self-righteous about poor quality. Talk to your testers about the importance of avoiding blame, and talk it through with each of them individually if it comes up. If it looks as if others are blaming you for delays when the issue is really poor software quality, you may need to prove your point. Be very careful how you do this; testing can't adequately compensate for quality problems, but it doesn't help a fraught situation to be too blunt. Stick to the facts, deliver them as unemotionally as you can, and share your report with the development lead before going public.