
At the outset, I did not have any good news for my project manager. Also, holding on to my bad news would not make it better or make it go away. So, in my most gentlemanly way, I told her exactly how matters were.
“Based on these ridiculous estimates, it’s impossible to complete the development in time” … “We are all behind the curve and nothing has changed since last meeting. The team will not meet the deadline.”
Now some managers would appreciate the direct approach but that would depend on how they were associated with the work and also with the language used.
A non-technical project manager cannot relate to that sort of language. They must be addressed in terms that are understandable and on which they can act.
We often take for granted that people understand us all of the time. We believe they understand our colloquial language and are just as comfortable with the vernacular as we are.
Communication is vitally important, and we must concentrate to ensure that the receiver hears what we want them to hear and does not cloud the communication with doubt and ambiguity.
Initially, the problem should be stated in very clear language.
This is often assisted by stating the root cause of the problem.
Don’t detail the symptom only.
Indicate the various impacts that may be found in the chain from root cause to the symptom.
If desirable and opportune, present a solution to the problem.
That’s not too difficult …. or is it?
Unfortunately, it’s not that simple.
Software developers have a particular way of communicating, and using verbal shorthand is one of them.
As an example: if a developer says, “I can’t work like this, SQL is eating up server RAM and the SP executes are too long,” his compatriots will immediately know what he is saying.
The developer is saying:
Structured Query Language is a software tool used to communicate with databases.
Where there are many records, SQL uses a lot of Random Access Memory.
The problem could be too little RAM, or it could be too many records.
Whatever the cause it’s taking too long to get results, and I am spending a lot of time waiting.
So right now, we are not concerned with the technicalities, only that the language is difficult to understand. By using my developer shorthand, I can convey a lot of information in a very short sentence. I don’t address the root cause of the problem because I assume that my colleague knows about these things, and I don’t want to insult him.
It is for this very reason that we tend not to explain all the detail to our managers – it is respect for their intelligence and perhaps an expectation that they should actually know what we are talking about.
The problem is that most managers don’t have a clue and the problem is seldom any closer to being solved.
Bad
“I can’t work like this, SQL is eating up server RAM, and the SP executes are too long,”
Complaining that SQL is eating up server RAM is not going to advance my cause, because the project manager has no understanding of what that means. She will be asking herself:
What is SQL?
What is it used for?
What is a RAM?
How is it “eating up server RAM” and what does that mean?
A manager cannot act on this.
Better
“I can’t work like this. My computer is unable to run the applications, such as SQL, that I need in order to develop our software. The reason for this issue is I do not have enough RAM.”
This statement is easier for the manager to act on.
There is an indication of the impact of the problem,
There is an explanation of why it is important to the project.
There is also a statement of a possible solution.
Best
“I can’t work like this. My computer is unable to run the applications, such as SQL, that I need in order to develop our software. The reason for this issue is I do not have enough RAM. To resolve this issue, I need more RAM or a new computer. I have consulted with IT and if you sign this purchase order, they will upgrade my computer and budget for a new machine in the next financial cycle.”
This makes everything very clear to the project manager.
The example above is very simplistic.
It does however indicate one thing – we need to speak in terms that people understand.
Whenever you speak or write, remember who your audience is.
Configuration Management is covered extensively in our Configuration Management Module.