Establishing context is more akin to teaching.
Step One: Listen
Step Two: Reflect
Step Three: Ask questions
Step Four: Listen
Step Five: Explain
I just made step 1 - 5 up so do not take it too seriously.
Establishing context should be taken very seriously.
Establishing context is the goal.
Communication is one of many means to establish context.
Without context, the message is not understood.
Context may be considered an aspect of communication but this is a mistake. Establishing context between two domains of knowledge is the aim of communication.
For example:
We are saving 1 cent per transaction.
v
We are saving $10,000 per transaction.
Either one of these could be good or bad depending upon:
The missing context.....
1. How many transactions?
2. How much did it cost (per transaction) to make these savings?
3. Does this give the organisation competitive advantage?
4. Is this strategic?
5. Why have we done this?
6. Could we have made a larger saving elsewhere?
7. What is the expected life time of the product?
Computing literature focuses on effective communication.
Relationships are more important than communication.
Without relationships, the message will probably be ignored.
We should focus on relationships above all else.
If you do not enjoy your job, you are doing the wrong job.
We spend too long at work not to enjoy what we are doing.
You get paid once a month, but have to get out of bed every day.
If you do not enjoy it, it will feel like work. You will never have the energy to go the extra mile that differentiates between the really good and the great.
Have fun! Everything else will follow.
Escalating bad news is always hazardous and difficult for a Business Coach. The problem is particularly acute for a business coach because they represent both IT and the Business. The issue often involves either IT or the Business suffering at the expense of the other. Normally it is the business that suffers through poorly met requirements in order for IT to meet artificially imposed deadlines.
Most issues often result in a delay to the delivery of the project at the expense of the business requirements.
There are a number of approaches to escalating bad news:
1. Directly.
2. Through another IT Manager.
3. Through the business.
The business coach should only consider escalating an issue if they are 110% certain that they are correct and that the issue is significant enough to take the necessary personal risks. (See a bit of Fun, ABC Rule 3. ;-) )
1. Directly.
This is the best but often the hardest route. When escalating, tell the person that you disagree with that you are escalating the issue. Ideally take them with you to a meeting with their manager so that they can present their perspective on the issue. The manager will normally side with their own person, especially if they do not understand the details of the issue. If the Manager decides to suppress the issue, the Business Coach faces the moral dillema of whether they escalate further. (See conveying bad news).
2. Through another IT Manager.
This is a very high risk option. It should only be adopted as a last resort.
If the Business Coach has a good relationship with another manager, they may consider expressing their concerns to the other manager. This is best done informally. Once again, it is best to inform the person that you disagree with that you are seeking advice from another trusted IT Manager.
3. Through the Business.
Tell the person that you disagree with that you will be expressing the issue in business terms to the business representative on the project.
As the business are normally the party that suffers from suppressing an issue, they should be given the opportunity to challenge the decision. It then allows the business representative to escalate the issue through their management structure.
The problem is that the business representative may not understand how a "subtle" IT issue affects their business requirements. This is particularly the case where IT are arguing over "which side up eggs should be opened". The business coach has the advantage in that they understand the issue from a business perspective and can express it accordingly.
Ensuring a Decision Maker acts upon their advice is the Business Coach's hardest task.
A decision maker may ignore the advice of a Business Coach if a trusted colleague contradicts it. Even incontravertable evidence can be ignored.
The Business Coach has a number of choices at this juncture.
1. Drop the issue.
2. Build the trust of the decision maker until they trust the Business Coach more than their own staff.
3. Find a trusted intermediary to convey the message.
4. Escalate the problem.
Each of the approaches have their strengths and weaknesses.
1. Drop the issue. This is the easiest solution for the Business Coach. This is the best approach when the project has a proper issue/risk management process.
Unfortunately, when the project does not have an issue/risk management process, the issue can be easily ignored. The issue may have severe consequences for the project and as a result to the business coach. The business coach can even be blamed for not raising the issue when it become a real problem.
2. Build Trust. This is the optimal solution. When the decision maker trusts the Business Coach, they will instinctively act on the advice even if contrary to the advice of other staff that they may trust more.
David Maister's "Trusted Advisor" give an excellent approach to building trust based upon putting the needs of the other person above your own.
Trust building takes time. It may be that the issue needs to be addressed before the Business Coach can build the trust. An example would be where a Project has reached the point where they need to commit to particular course of action (e.g. Buy expensive software) and the Business Coach has identified a potential issue with the software. The problem for the decision maker is that delaying the purchase will delay the project which results in higher costs. The risk of buying the wrong software is that is may be unusable or may lock the project into paying for expensive upgrades from the vendor. The decision maker will feel safer buying the software because it will progress the project. Getting the decision maker to take a different course of action in this event will require a great deal of trust in the Business Coach, particularly when their own staff are advising them to progress.
3. Find a trusted intermediary to convey the message. Find someone that the Decision Maker trusts and get them to convey the message. This is the best option after building trust directly. The problem is finding the person and then getting them to trust you so that they will then pass the message on.
4. Escalate. This is the most difficult and dangerous option available to the Business Coach from a personal perspective. It is unlikely that they will be thanked for escalating a problem, and it is very likely they will be accused of trouble making.
Ultimately it is a moral issue whether a Business Coach escalates an issue. Their responsibility to the project is to identify issues and raise them with the project decision maker. It is the responsibility of the decision maker to resolve the issues. The question is whether a business coach has a greater responsibility to the organisation in general and the eventual business sponsors specifically to ensure the issue is resolved.
A business coach should escalate the issue. The responsibility to escalate issues should be written into the contract of employment between the Business Coach and the Employing Organisation. This will protect the business coach from the inevitable back lash from escalating issues. (See "A bit of Fun")
Business Value is the most important thing for any (IT) project.
A set of rules for the Agile Business Coach ?
1st ABC Rule: No Agile Business Coach through their action or inaction will allow the Business Value of a Project to be destroyed.
2nd ABC Rule: A Business Coach shall always obey their Project Leader unless this contravenes the 1st Rule.
3rd ABC Rule: A Business Coach shall always protect themselves unless it contravenes Rule 1 and 2. ;-)
The Zero'th ABC Rule. No Agile Business Coach through their action or inaction will allow the Business Value of a Organisation to be destroyed.
There can be only one! way to develop software. From a business value driven perspective