Keeping Promises

The project, a complex healthcare facility, was in trouble. The money and time were gone, but there was plenty of distrust and mis-coordination.

Scheduling work seemed impossible; the design was filled with conflicts, and it kept changing. Supervisors were torn between finding work ready for today and trying to solve problems for tomorrow. It wasn’t much fun, and the client was very unhappy. There was so much to do—and so little time—that it was hard to know where to start.

Design issues dominated the weekly planning meeting, so I went there to listen and learn. After new issues were identified and discussed, the meeting turned to review the status of unanswered RFIs. These Requests For Information typically originate in the contractor organization and are used to define, manage, and track solutions.

Going down the list, Carl, the contractor’s project manager, spoke to Dan the architect. “Dan, we need to resolve RFI 173.” Dan shook his head in agreement, and they moved on to RFI 204. I wasn’t at all sure what had happened or how to interpret this brief interchange.

After the meeting, I caught up with Carl and asked if Dan had promised to solve the problem. Carl was convinced that he had. I was not so sure, so we caught up with Dan and I asked, “Did you promise Carl to answer 173?” Dan was surprised and confused. “How could I?” he said. “I agree we need to get it resolved, but Carl owes me some vendor data before we can decide.” Carl was taken aback; he had forgotten his promise to Dan. But after a quick discussion, both were back on track.

Walking away, I asked Carl why he had framed his request, “Dan, we need to resolve RFI 173.” He said this was a nicer, more team-friendly way of talking. He claimed, “It puts us in the problem together.” Carl and I are pretty good friends, so I took him straight on. “Teamwork isn’t about being soft and unclear,” I told him. “It requires making clear requests and securing reliable promises. Don’t be a wimp—ask for what you want. And don’t be a flake—do what you say you are going to do.”

Coordinating work in projects and keeping projects under control is a matter of people making and keeping the commitments that release work to others in the right sequence. A project can be understood as a network of commitments that links the work of the specialists to the promise of the project and coordinates their action. Carl makes a request to Dan…Dan asks for vendor data…Carl asks his assistant…somewhere a request is mistaken for an opinion, or the nod of the head is interpreted as a promise. Planning systems can provide the structure and circumstance for planning conversations, but systems don’t make work happen. People make work happen by making requests and keeping promises to one another.

There are ways to tell when you are making a
reliable promise. Ask yourself if you can say one or
more of the following:

1. I am competent enough to perform, or I have access to competence.
2. I estimated the amount of time (hands-on) required for this work.
3. I have the capacity available to do the work and have allocated it to the task.
4. I am not having a private unspoken conversation in conflict with my promise.
5. I will be responsible; I’ll clean up the mess if I can’t deliver.

Commitments are between people, not schedules. Project management as practiced today creates a “commitment-free zone,” because it assumes that people will commit to centrally managed schedules without providing a mechanism to ensure their work can be done. So they give it their best, but something always seems to come up…“I tried, but you know how it is.”

This form of project management does not provide a mechanism to ensure that what should be done, can in fact be done at the required moment. Too often, promises made in coordination meetings are conditional and unreliable. It has been my experience that at times trust can be low and hard to build in this environment. The absence of reliable promises explains why on well-run projects, people are often only completing 30–50 percent of the deliverables they’d promised for the week.

We all know what a promise is; we have plenty of experience making them and receiving them from others. So what’s the problem? The sad fact is that the project environment—like many other work environments— is often so filled with systemic dishonesty, that we don’t expect promises that are reliable. Project managers excel when they manage their projects as networks of commitments and help their people learn to elicit and make reliable promises.

About the Author

Gregory A. Howell is co-founder and managing director of the Lean Construction Institute (LCI), a non-profit organization devoted to production management research in design and construction. Howell brings 35 years of construction industry project management, consulting, and university-level teaching experience to LCI.