The Conditions of Satisfaction (COS) are determined by a one-on-one, realtime, face-to-face dialogue between the requestor and the provider. Emails will never be a substitute for face-to-face dialogue. The problem with email requests and replies is that we are never really sure what the other individual is saying because we don't have the opportunity for immediate feedback or to see nonverbal reactions to the dialogue. With emails we assume we understand, but we have no way of verifying that we understand correctly.
To further press our point, here is an example from our early days of training IT professionals in project management. We would ask each student to write down his or her definition of implementation. They could do it by making a list of what was in and not in implementation. Would you be surprised to know that there wasn't much agreement from one list to another? IT professionals can hardly say a sentence without using the word implementation, and they don't really know what they are talking about. With this simple example, it is clear that the message sent is surely not the message received. How serious a communications problem might there be between a requestor (a businessperson) and the provider (a technical person)? Such communications problems can be pretty serious. They could result in the project team having one idea of what the client needed and the client having yet another understanding of what the team is going to deliver. It is so important that both the client and the team have a common understanding of what is needed and what is being delivered that to pass up the COS exercise could be fatal. The COS, which is introduced in Chapter 3 and is briefly revisited here, solves the problem once and for all.
The requestor and provider may be individuals or small groups, but they must be representative of the requestor group and the provider group and be empowered to make commitments and decisions for the groups they represent.
Let's review how the COS works. The COS consists of two conversations. The first one is driven by the requestor and the second by the provider. Figure 14.2 is a schematic of the process.
Let's look at the two types of conversation:
Requestor-driven conversation. The requestor states and describes the request using their language. The provider makes sure he or she understands the request by using questions and eventually feeding back the request in his or her own language. At some point in this conversation, you want the requestor to be able to say to the provider, "You clearly understand what I am asking you to do." The conversation now shifts to the provider-driven conversation.
Provider-driven conversation. The provider responds by stating and describing what can be done to meet the requestor's request. The requestor asks questions to frame the answer and eventually describes the response in his or her own language. At some point in this conversation, the provider is able to say to the requestor, "You clearly understand what I can provide."
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.