When there are problems with a mission-critical application, playing the blame game can stall progress and destroy your team's morale. How do you put an end to chaos and get your team back on track?
The following is an actual incident related by one of my company's consultants. A nervous young man greeted the consultant in the lobby on the IT floor. He simply said, "Follow me." As he walked down the hall to the application team room, the sounds of a heated discussion echoed in the corridor and grew louder.
The large meeting room was divided into "camps." Employees and contractors working for the systems integration firm were gathered in one corner around tables with laptops and printouts. The IT operations team was in another corner. Other camps included database management and mainframe administrators. In the center of the room a man and a woman were squared off facing one another. "Your architecture won't work, that's obvious! This performance is completely unacceptable! How can we can do so well in QA, but as soon as we go live we choke?" said the woman. "It's not the architecture," retorted the other, his voice rising in volume. "We've gone over this a dozen times. It's got to be either the way you have configured the app servers or your mainframe application."
The consultant's host pulled him aside. "It's been like this for two months. This is destroying our team's reputation and morale, and some execs are talking about killing the whole project. Can you …