The key to successful communication as a business analyst

Whilst working on my use case modeling training course, I have been researching current thinking on online training. It has really opened my eyes to effective methods for engaging and communicating with others.
This article explains some best practice principles for communication.

Ok, imagine you’re a project manager and your business analyst says:

this task is really difficult. I’m not sure how long it will take but I will kick off with a workshop and decide where to go from there.

Now what would you think if they said:

I estimate this task will take ten man days. This is an estimate so I will discuss the approach with the key stakeholders on Day 1 and will give you a revised estimate at the end of the day.

The difference is clear.
In both cases, the work to be undertaken is much the same. In the second case, the business analyst is communicating from the project manager’s perspective. In essence, the project manager thinks in terms of estimates, timescales, cost and risks.
In an ideal world, all estimates are 100% accurate (in fact, they are not estimates); all risks have been eliminated or mitigated; and the project will be delivered to a timescale acceptable to all stakeholders.
The business analyst gives the project manager what is needed, anticipates objections and addresses these.

There are a couple of principles at work here:

• Understand your audience’s perspective 

 

• Speak in terms of benefits to your audience

Vague, unreliable estimates keeps project manager up at nights.
Estimates which will be improved help them sleep soundly.

These principles are even more powerful when the communication is written rather than verbal.
This time, imagine you’re providing a status update to your project manager, senior management (stakeholders) or the board.
You could produce the following:

The analysis for project XYZ is proceeding well in general. The progress has slowed slightly due to stakeholder ABC being ill all this week. The analysis is behind plan but expect to catch up this week by arranging an additional workshop this week. It is still proving difficult to understand process XYZ as there are several parties involved and it was assumed that there would be a single subject matter expert who understood the full process end to end. This will require some replanning to get a better estimate.

Alternatively, you could produce a few lines of report with the following:

Status:  AMBER 

Detail:

Progress slowed due to illness - plan in place to catch up.
Assumption of single SME for process XYZ was incorrect so falling behind. Will replan to address this and present results at next update

 

There are several additional principles in operation here:

Structure
Consider the structure. Ensure you highlight the most important information. Use font size, colours and positioning to draw the reader’s attention.

Editing
Write once and review. Consider how it can be expressed more clearly and in less words. Use enough words to communicate well but look out for unnecessary padding. Remember the audience - these sort of readers are busy and like essential, relevant information only. The higher up the organization you go, the more important this is.

Technical writers (I assume) apply these principles today instinctively. Many experienced professionals and others will also understand this.

It is always useful to have a checklist to ensure the best communication approach is being adopted:

• understand your audience

 

• communicate in terms of benefits

 

• structure the communication to highlight key information

 

• review and edit the communication to ensure it is compact but clear

 If you would like to advance notice of the use case course I am developing and a very valuable free report that will accompany the launch (est February 2010), please enter your details below:

Add your comments below with your views on the article or your experiences on principles for effective communication.