A Fortune 500 company recently learned, within the course of eight weeks, that six major projects were in trouble. In each case, the traffic light went directly from green to red, skipping a yellow warning. The CIO felt blindsided. Executive management wanted someone to blame. Project teams felt the pressure, and the project management office was asked to explain how this could have happened.
The problems didn't come out of nowhere, of course. But IT leadership can fix problems only if they're known. And problems that fester are more difficult to fix. Unfortunately, project staff can feel strong but subtle pressure to keep problems to themselves. They worry that they won't be perceived as team players if they report any concerns. Less experienced staff can feel an unfounded optimism that convinces them that the project team will be able to recover from missed deadlines by working harder. In the case of the Fortune 500 company cited above, all six failing projects had executive sponsors who were politically powerful and known to attack bearers of bad news. Nobody wanted to raise a red flag and admit that their project was in trouble.
Here are some things that IT management can do to identify problems in a timely manner:
• Require realistic project plans. And be prepared to defend them. Not always easy, but crucial. Teams at another Fortune 500 company came under intense pressure to cut project costs, so they reduced the time and budget allocated to training, testing and change management. Those cuts resulted in poor quality and low user acceptance. Project plans without adequate time and resources are doomed from the start. Agreeing to them dooms you to paying a price later.
• Use agile project management. The agile approach breaks projects into small pieces and requires tight collaboration between business and IT staffs, so problems are easier to spot. In addition, agile projects produce frequent, visible deliverables, which can keep a small problem from turning into a huge problem.
• Listen to the messenger; don't shoot him. The tendency to punish the bearer of bad news was a phenomenon recognized by Shakespeare and Sophocles. As far back as the fifth century B.C., the chivalric code in China prevented the executions of messengers sent by an enemy. Sadly, many of today's executives have still not learned this principle, or don't practice it. Make sure employees know they will not be punished for raising concerns, even when other project members deny problems exist. An angry reception stops the flow of useful information. If you have traditionally been a messenger shooter, take steps to reform, and get the word out that you're ready to listen.
Sign up for Computerworld eNewsletters.