A Guide to Developing A New Practice
By Hal Macomber (1 )
Routinely, projects are late, over-budget, or fail in some way to satisfy the client. And all this in spite of the training and tools deployed on projects. However, there is a practice for increasing the reliability of completion of project tasks. This practice is the securing of reliable promises. Why do we say “to secure a promise” rather than “to make a promise”? First, it is a practical matter. There is a much better chance of training the few who manage projects than the many who perform on projects. Second, the requestor is the one more interested in having his or her request completed.
Most of us are so interested in getting our requests satisfied that we latch on to the first utterances of a would-be performer, thinking we got the promise we were looking for. All too often we receive just the opposite. The individual is trying not to promise, but doing a very bad job even of that. Learning to secure reliable promises is strictly an act of self-interest. This guide will take you through an approach for securing reliable promises on your project.(2)
Structure of a Promise
A promise is made in response to a request. In the absence of a request, a promise can also be made in the form of an offer. Either way, our everyday promises generally take the form:
I (the performer) will deliver “X” for you (the customer) by a specific time in the future.
In response to the common request, “Please do “X” for me,” we often shorten our reply to single-word responses like “Yes,” or “Sure.” Under these kind of “every day” promising circumstances, the conditions required for completing the promise are often so well understood that they slip into the background (or into the silence of assumption). For instance, you might go to your favorite coffee shop and say, “The usual.” What you get is what is usual for you – a double cappuccino with skim milk, and powdered cinnamon on top of the froth. The next person in line might order their ‘usual,’ getting (and being satisfied with) something entirely different. In fact, the “promising conversation” may have slipped so far into the silence of assumption that the performer may not even bother to speak his or her promise to you – let alone exactly what you want - instead just going directly to work preparing your coffee. In the same way, your spouse’s request, “Take out the garbage” which (at first look) appears to be missing a key part of its anatomy (the time (due date) for completion) turns out, on second inspection, to contain the time specification, now. Depending on what is usual and customary, that request may also include in its assumptive silences, “And don’t forget to empty the wastebaskets.”
On projects, however, promises take a slightly different form. First of all, work is usually referred to as “tasks.” Common practice is to 'assign' a task to a project team member, who generally 'accepts' the task. Due to the non-repetitive nature of this kind of work, conditions of satisfaction may need to be made explicit. The requestor may request that the team-member perform the task to some organizational standard for that type of task. The requestor may even go so far as to ask that a certain protocol or procedure be followed, which may also include providing documentation indicating the task has been completed to the declared standard.
Page 1 of 5
© 2001 Good2Great™ Associates
