Do you speak your stakeholder’s language?
07/05/13 07:45
It’s the most normal thing in the world – project managers hand the charter, the requirements specifications and many other documents to other stakeholders for review and for approval. And it’s also quite normal that this document handover results in rather unpleasant feedbacks like: “I don’t have time for this”, “I don’t understand what is written in there” or a more general: “If you have to write these documents, then do it, but don’t bother me with it…”
The cause for this reaction is most of the time the language in which the document is written. And language does not mean English or French. But project managers and specialists, such as IT employees, all speak their own language with a very specific terminology. When the documents, the stakeholder has to agree with, are now written in a combination of these languages, this might result in sentences like: “The UAT has the scope of the UI and will be conducted in three iterations.....” The reaction of the recipient to such sentences will be a mixture of confusion, ignorance, and anger. To make matters worse, such documents can be quite lengthy. And who ever wonders before such a document is issued or even written if the person who should read it at the end is used to or willing to read such an extensive collection of words?
A common way to deal with this issue is either to calm the stakeholders down by telling them that everything is fine and states their expectations and they should simply sign it or that the stakeholders are pressured into signing it by threatening not to proceed without a formal approval. Both approaches might lead to a signature, but in both cases the signature will be worthless, as neither the true intent of the stakeholder is clear nor does the stakeholder understand what the project team is trying to accomplish. This results in unhappy stakeholders and tons of change requests.
To effectively prevent these issues, all documents the stakeholders will have contact with, will need to be written with them in mind. The following questions should be asked:
Which amount is the stakeholder used to read?
The amount of material people feel comfortable reading depends on their functions. A scientist might be used to going through huge stacks of papers, whereas a senior manager is used to getting the key issues presented in a condensed abstract. Although the scientist might refuse the one-page document and deem it as not detailed enough to be trustworthy, the senior manager may simply not be willing to read the lengthy document. This is why it is so important to adjust the length of the document and the degree of details to the stakeholders. In cases that multiple stakeholder with different reading appetites have to review the same document, it might help to write a detailed document with an abstract at the beginning.
What “language” or terminology does the customer understand?
Put yourself in the stakeholder’s shoes. What is the terminology they are used to? What forms of communication are they normally exposed to? Try to stay as close to their “language” as you can. Do not use project management expressions if not absolutely needed, and if you have to, explain what they mean. The same goes for abbreviations. Try to write the documents in a way, that a glossary is not necessary. Still, it’s not a bad thing to add a glossary anyway, but the shorter it is, the better. A good tip is also, to place the glossary in the front of the documents and not in the back as usual. This way the stakeholder gets familiar with the terminology, before he or she reads the document.
But language goes beyond words. There are groups of professionals, who rely not so much on words, but on numbers, graphs, charts, shapes or colors. Take a scientist who might rely mostly on numbers and graphs or a marketing person who might be used to colors, shapes, and icons. Consider how to adapt the documents, that they look familiar to them too!
What really matters to the stakeholder?
Documents, which are directed to the stakeholder, should only contain information that is relevant to them. Everything else wastes the time of the stakeholder and might lead to additional questions and review rounds. A very good example is the requirements specification document. A lot of project managers are tempted to write in this document already some technical details. But this does confuse the stakeholders, as this was not their initial requirement and they don’t understand it. By keeping the requirements specification document clean and only stating in there the needs of the customers in their words, it can be ensured that the requirements are gathered correctly and hence the document fulfills its purpose.
By simply asking these three questions stated above, documents can be written in ways that make them easy to read and understand for the stakeholders. The result will be a stronger involvement of the stakeholder in the project, a better understanding of the stakeholders needs by the project team as well as a better understanding of the project teams actions by the stakeholder. Which all means that the initial deliverables will be more likely to match the stakeholders expectations and the journey up to this point will be much more pleasant and collaborative.
Tweet
The cause for this reaction is most of the time the language in which the document is written. And language does not mean English or French. But project managers and specialists, such as IT employees, all speak their own language with a very specific terminology. When the documents, the stakeholder has to agree with, are now written in a combination of these languages, this might result in sentences like: “The UAT has the scope of the UI and will be conducted in three iterations.....” The reaction of the recipient to such sentences will be a mixture of confusion, ignorance, and anger. To make matters worse, such documents can be quite lengthy. And who ever wonders before such a document is issued or even written if the person who should read it at the end is used to or willing to read such an extensive collection of words?
A common way to deal with this issue is either to calm the stakeholders down by telling them that everything is fine and states their expectations and they should simply sign it or that the stakeholders are pressured into signing it by threatening not to proceed without a formal approval. Both approaches might lead to a signature, but in both cases the signature will be worthless, as neither the true intent of the stakeholder is clear nor does the stakeholder understand what the project team is trying to accomplish. This results in unhappy stakeholders and tons of change requests.
To effectively prevent these issues, all documents the stakeholders will have contact with, will need to be written with them in mind. The following questions should be asked:
Which amount is the stakeholder used to read?
The amount of material people feel comfortable reading depends on their functions. A scientist might be used to going through huge stacks of papers, whereas a senior manager is used to getting the key issues presented in a condensed abstract. Although the scientist might refuse the one-page document and deem it as not detailed enough to be trustworthy, the senior manager may simply not be willing to read the lengthy document. This is why it is so important to adjust the length of the document and the degree of details to the stakeholders. In cases that multiple stakeholder with different reading appetites have to review the same document, it might help to write a detailed document with an abstract at the beginning.
What “language” or terminology does the customer understand?
Put yourself in the stakeholder’s shoes. What is the terminology they are used to? What forms of communication are they normally exposed to? Try to stay as close to their “language” as you can. Do not use project management expressions if not absolutely needed, and if you have to, explain what they mean. The same goes for abbreviations. Try to write the documents in a way, that a glossary is not necessary. Still, it’s not a bad thing to add a glossary anyway, but the shorter it is, the better. A good tip is also, to place the glossary in the front of the documents and not in the back as usual. This way the stakeholder gets familiar with the terminology, before he or she reads the document.
But language goes beyond words. There are groups of professionals, who rely not so much on words, but on numbers, graphs, charts, shapes or colors. Take a scientist who might rely mostly on numbers and graphs or a marketing person who might be used to colors, shapes, and icons. Consider how to adapt the documents, that they look familiar to them too!
What really matters to the stakeholder?
Documents, which are directed to the stakeholder, should only contain information that is relevant to them. Everything else wastes the time of the stakeholder and might lead to additional questions and review rounds. A very good example is the requirements specification document. A lot of project managers are tempted to write in this document already some technical details. But this does confuse the stakeholders, as this was not their initial requirement and they don’t understand it. By keeping the requirements specification document clean and only stating in there the needs of the customers in their words, it can be ensured that the requirements are gathered correctly and hence the document fulfills its purpose.
By simply asking these three questions stated above, documents can be written in ways that make them easy to read and understand for the stakeholders. The result will be a stronger involvement of the stakeholder in the project, a better understanding of the stakeholders needs by the project team as well as a better understanding of the project teams actions by the stakeholder. Which all means that the initial deliverables will be more likely to match the stakeholders expectations and the journey up to this point will be much more pleasant and collaborative.
Tweet
blog comments powered by Disqus