|
Home Our Company Public Workshop Schedule In-house Delivery and Consulting Workshop Descriptions Site Map Articles |
Getting the Sponsor You Need
Rule 7 - Show them the money
Another great Rule for getting great sponsors is to watch your language. Too many project managers and project reporting systems over communicate with executives and, worse, over communicate in the wrong language.
We observed a perfect example of this problem when we were advising a client regarding a project that was in serious trouble. The project involved upgrading operating systems on the corporate PCs. The client company was an early-adopter of a new operating system release and the project was over 6 months behind schedule. A significant factor in the delays was the operating systems vendor's inability to solve the technical problems without shifting the blame to other impacted vendors such as the network supplier.
By the time we became involved, the project was considered such an issue that the C.E.O. has requested a briefing for himself and the entire executive team. This sent the team into a panic and fearing a "Spanish Inquisition", they assembled a complete record of all the technical problems, how the vendor has responded and so on. They then spend hours preparing full briefing documents (in full color) and actually rehearsed the presentation.
We were invited to attend the C.E.O. briefing and watched as the project manager began to present a very complex and technical presentation along the lines of:
"Now if you'll turn to page 26 you will see that we raised the problem of the recursive articulator bug with Vendor A who then replied that it wasn't a recursive articulator bug but in fact a circular articulator bug caused by Vendor B's network concrosinator!"
The C.E.O., who happens to be one of the highest paid people in Australia, became increasingly restless as he flicked through the report in front of him. He raised his hand, which stopped the project manager in mid-sentence, and said gently:
"Look, tell me how the organisation will be better off when the project is over".
The project manager and the team members were simply lost for words. They ((and the project} were saved by another executive whose group had been a test-site for the new operating system. This executive explained that her people had found the new operating system more stable and this had lead to significant productivity gains. The C.E.O. was satisfied and simply said to the project manager "Continue the project".
While we have focussed on cost-benefit in this paper, there may be other issues or "hot buttons" that you can use.
For example, in your company, the executive "hot button" may be customer service. So the trick is to convert the problem you are facing in your project into how it impacts customer service.
The use of the relevant "hot button" is a powerful communication tool to draw your sponsor's attention to the impact of their decision-making in terms that they can relate to.
You can usually uncover your organisation's "hot buttons" from your company's mission or vision statements.
The Rule here is simple but powerful. As the wonderful scene from the movie Gerry McGuire puts it "Show me the money". In the case of your sponsor "Show him or her the money". You should avoid technical jargon (Rob here - sorry to be so obvious and traditional), you should put everything - not in English - but in money terms.
For example, you might have some trouble getting your information to the executive that needs to make the decision (see Rule 3). You have a team of 5 people at an average cost of $1,200 per day. So instead of saying:
"Look each day we lose means that we could miss the deadline"
try this:
"Each day there is a delay in this decision being made means we are losing $6,000."
better still, try this:
"Each day there is a delay means that we are losing $6,000 and placing at risk the benefits realisation of $x million".
That should get some action.
The key point of this Rule is to keep your communication short and focussed on the business and financial impact. In effect, this is a variation on a standard risk management concept known as Consequence-based Reporting. This techniques focuses on the consequence of not acting rather than simply reporting the action required.
Also, there are a couple of associated sub-Rules, which deal with the broader issue of why people change.
The first is that people won't change unless there is either a big advantage to them for changing or a big disadvantage for them if they don't change. The use of these Rules and, in particular, this Rule should help you here.
The second is that people are often unaware of how their behaviour affects other people. By simply explaining (in a factual and non-emotional manner) of how their action (or lack of) affects the project, you'll often find the person simply saying "Of! I didn't know that was the situation. I'll deal with it straight away".