I recently had the rare opportunity to observe a development team working on a project from which all deadline pressures had been removed. However, those pressures were replaced with something else--quality pressure. The team responded in an interesting and unexpected way, which led me to some observations about how we respond to schedule pressure.

This team was not writing software for pacemakers, the space shuttle, or any domain where you might expect an extraordinary level of quality pressure. Rather, they were developing a fairly typical Web-based application. Quality issues would cost--in Allistair Cockburn's terms--discretionary money. That is, each failure in the site would cost the company a few hundred dollars, which is not enough on its own to truly jeopardize that particular company.

The company removed all schedule pressure because of past issues with the reliability of a part of their Web site. Even though this part is used by customers only during a short portion of each year, it was so buggy that the company determined they would begin losing customers if it was not dramatically improved. The developers were told to take as long as necessary to fix this part of the site with the expectation that the rewritten portion of the site should be perfect. A goal of no defects in that area was established.

I checked in with team members periodically over the next few months while they were engaged in their tasks. Every time I met with them they had established a new deadline for themselves. They'd say, "We want to be this far along by July," or "By August we need to be able to handle these types of transactions." I'd ask them how they'd established those deadlines. The answer was always the same: No businessperson had asked for a specific amount of progress by a specific date, but the team had decided how far along it needed to be at various checkpoints to feel good about the overall progress.

At first I didn't understand why this was happening and I would simply encourage team members to remove the deadline pressure. I'd remind them that the CEO had stressed to them that the goal of "no defects" outweighed any urgency in delivering the feature quickly. After a few months of this pattern, I eventually realized that the team liked schedule pressure but did not like quality pressure. Schedule pressure is comfortable to us; we are used to it, even though we often fail to meet the schedules. The pressure to do extraordinarily high-quality work is foreign to us. It also puts us in the uncomfortable position of having no excuse other than to admit our inability to do perfect work when defects creep into our work. With even the slightest bit of schedule pressure, a team can rationalize: "That bug happened only because we were hurrying." Without schedule pressure, a team has no such easy-to-reach excuse for any defects.

In another case, a project manager told me her team wasn't hearing her message about the need to focus on quality. She said that even though she'd stressed the importance of doing extremely high-quality work, team members kept falling back into old habits of rushing through their work because of a perceived need for more speed. We discussed how often she was communicating the need for high-quality work; she replied she was conveying that message a couple of times per week. We then discussed how often she talked to the team about deadlines, and she said the subject came up at least once a day during the team's morning standup meeting.

Because teams are hypersensitive to any mention of schedule pressure, this project manager and I agreed that the team needed to hear her stress quality goals a hundred times for every time she mentioned a deadline. Most teams are so attuned to schedule pressure that the mere mention of it can often be more powerful than ninety-nine mentions of quality pressure.

My third and final case shows the importance of over-communicating non-schedule goals. I spent the first day of working with this team asking why team members were initiating a project to rewrite an existing core business application. I started with the VP of the department who made it very clear that the application was being rewritten because the existing application was no longer maintainable. It had lived a long and decent life but could not be extended any further.

As I met others on the team that day--programmers, testers, and managers--they expressed different reasons for rewriting the system. They said they were rewriting the application to make it perform better, to make it more reliable, to give it a fancier user interface, and to make it easier to use.

The project had been given a fairly arbitrary deadline six months into the future because that would coincide with the release of a related product. The date was considered aggressive but achievable. I asked the team, "What if you miss the deadline by a month but create an application that is easy to maintain?" All team members thought this would be a failure--meaning, the deadline was critical.

I asked the VP project sponsor the same question, and he considered the alternative outcome to be just as successful. His major criteria for the success of the project was that the application be easily maintainable. But because the project had been given a target release date, that release date became the primary focus. This team stood mistakenly primed to sacrifice achieving the project's primary goal in order to be done on time.

If you are a manager or are in a position of authority, be very aware of the messages you send a team. If you want a team to focus on something other than the schedule, you'll need to stress that attribute many times--more often than you stress the schedule. If you are a team member, listen carefully to find out what is truly critical to the project sponsor. A little schedule pressure goes a long way.