16 April 2008

BA Communications - Why its important

The purpose of calling out Communications as a BA knowledge area might seem obvious, but it hasn’t always been so, and still isn’t to everybody.

Basically the BA’s main role on projects is to manage the ‘business requirements’ through the project lifecycle. The BA acts as a, or on behalf of, a product owner. They are accountable for the articulation of the business problem or opportunity and have a strong voice in the solution strategy and design.

Business analysts also have an active interest in successful benefits extraction from the project, and are active in communicating to key stakeholders to projects, particularly subject matter experts who have a say in the product requirements & constraints, and also user groups who are the end users, or beneficiaries, of the system

The BABOK approaches BA knowledge areas and work activities with a requirements management perspective and so it labels the BA Communications Management work as Requirements Communications.

In fact BAs do involve themselves in more than just requirements. Invested in the business outcomes they are also active in change management and business process design. A tool without a context adds no value, but once you motivate people to use it, and show them how and when it’s appropriate to use it, the benefits start to flow.

So for me BA communications go beyond requirements and into process design and change management.

In fact the BABOK aims to be methodology agnostic, and so it’s framework should be appropriate for process improvement projects as well as IT systems developments. In that context the emphasis of communications sits squarely on process design and change management.

So the key areas for BA Communications are;
  1. Requirements communications
  2. Process design communications
  3. Change management communications
  4. Stakeholder management communications

I guess you could raise an argument that process design is integrated into requirements management, but my view is that it sits in the solution domain, and so is different.

Also, what’s the difference between Change Management and Stakeholder Management?
Well, stakeholders don’t necessarily need to change, but users do, and helping them through the process helps drive those benefits. Stakeholders on the other hand can cause roadblocks and barriers to benefits extraction, so you need to keep them onside, and communication seems to be the best way to facilitate this.

So, unless you care to challenge me on this I am putting these points down as the four main pillars of a BA communications framework.

Picture by Splorp at Flickr


  1. Great Post Craig, I'm actually looking to get more information about communicating requirements. I'm in the process of doing requirements gathering and communication with my team and any help to smoothen the process will be of great help to me.

  2. Chris - good luck with it. If you want to pass it over I'd be happy to have a look and offer feedback.