Negotiating Achievable Commitments in Software Project Management
- By Karl Wiegers
I once observed a discussion between Steve, a senior manager, and Rob, a project manager, about a new project. “How long will this project take?” Steve asked. “Two years,” replied Rob. “No,” said Steve, “that’s too long. I need it in six months.” So what did Rob say? “Okay.” Now, what changed in those few seconds? Nothing! The project didn’t shrink by a factor of four. The development team didn’t get four times larger (although this would not have solved the problem). The team didn’t become 400% as productive. The project manager simply said what he knew Steve wanted to hear. Not surprisingly, the project took more than two years to complete.
Too many software projects are launched with the hope that productivity magic will happen, despite previous experiences to the contrary. Sometimes a team does get lucky or pulls off a miracle. More often, though, miracles don’t happen, leaving managers, customers, and developers frustrated and disappointed. Successful projects are based on realistic commitments, not fantasies and empty promises. Project initiation is the right time to establish a convention for how you’re going to handle commitments on your project. This chapter presents several ways to improve your ability to make—and keep—achievable project commitments (Humphrey 1997).
Making Project Commitments
A commitment is a pact one person makes with another. Both parties expect the pact to be kept. The commitment might involve delivering a specific work product or performing a particular service by a specified time and at a certain level of quality. A software development project involves many commitments between customers, business managers, development managers, and individual team members. The project manager makes both individual commitments and commitments on behalf of the whole team. The project manager also requests commitments from team members and perhaps from external stakeholders. Some software projects have at least one formal commitment: a legally binding contract.
Effective commitments must meet two conditions:
We must make them freely. Powerful people can pressure us to say yes, but most people are unlikely to take ownership of an impossible commitment that is thrust upon them. Some people will pretend to make a commitment they don’t intend to fulfill to bring an unpleasant conversation to a close, but this undermines the commitment ethic.
They must be stated explicitly and be clearly understood by all parties involved. Ambiguity about the specifics of the commitment reduces the chance that it will be satisfied.
It’s easy to make unrealistic promises on software projects. Most developers are optimistic about their talents and overestimate their productivity. Project managers assume their staff have 40 or more hours of productive project time available each week, although the reality is considerably less. Managers and customers who don’t understand software development pressure the team to provide perfect estimates and to meet their aggressive business expectations with little regard for the uncertainties we face. Often, we get incomplete or misleading information about the problem we’re asked to solve, which limits our ability to make meaningful estimates and commitments. Requirements are volatile, changing frequently for both good and not-so-good reasons. We need the freedom to renegotiate unrealistic commitments that turn out to be based on inaccurate information or premises that have changed.