Skip the navigation

How to Manage by Promises

By Kathleen Melymuka
April 2, 2007 12:00 PM ET
You note that negotiation can sometimes degrade into rebuttals and gotchas. How can I avoid or change that dynamic? People like to debate about the state of the world. The underlying notion seems to be that if we talk until we have a shared understanding of reality, it will be obvious to everybody what to do. So they talk around and around. Instead of seeking the absolute truth about the world, we need to say, “Here’s a request. Can you do it or not?” Then you go to offers and counteroffers. It eliminates a lot of that other discussion.

You write that good promises are voluntary. I suspect that a lot of our IT readers are smiling at that concept. By voluntary, we mean the provider has options other than yes. A more powerful member of the organization goes to a less powerful one and says, “You will do this project by May 13 with these resources, and it will have this functionality.” There are a couple [of] problems with this. Psychologists tell us that if people are coerced into a promise, they don’t feel they own it, and keeping promises isn’t ingrained in the organization. At the margins, that matters in terms of quality and delivery. Also, if people aren’t allowed to say things other than yes, critical information — such as other commitments that could get in the way of execution — is lost.

Good promises are explicit and yet constantly renegotiable. How do I strike that balance without chaos? If two parties are committed to make a promise work, it’s not that hard. Typically, you want to have the notion of minimum specification: What’s the minimum that we agree is critical? You specify the “what” rather than the “how.” One of the most interesting aspects of agile development is that the development team is basically having a renegotiation each time it goes back to the users.

You say that good promises are mission-based. Why is it so important for both sides to discuss not only what will be done but why it matters? If a customer makes a request and doesn’t bother to tell you why, you typically conclude, “They think I’m too stupid to understand the why,” or “They don’t know why themselves,” or “They don’t think I’m important enough to bother telling.” But if people agree that something matters, they’re more likely to nudge it up their internal priority list. And if you understand what the military calls the commander’s intent, you can often figure out a better way to do it than you initially agreed to. CIOs do this all the time.

Our Commenting Policies