The five Cs for clarity of thought for business analysts

by John Barris on 09/06/2015 10:28

Equinox IT's enterprise analysis framework

As a business analyst, it’s my job to understand a business – any business – and its requirements.

Only then can I communicate what I’ve discovered to stakeholders in a way that allows them to make change decisions, or build a new system to take their business activities to the next level.

And achieving that is all about communication; clear communication and clarity of thought. ‘Achieving clarity of thought’ is a key focus of mine and is also the title of a chapter I contributed to the recently published book, Business Analysis Book of Mentors: 25 Lessons Learned from Seasoned BA Professionals.

In this post, I summarise key takeaways from that chapter, focusing on the five ‘Cs’ that enable clarity of thought from a business analysis perspective.

To help achieve clarity of thought as a business analyst you should focus on:

Context – Where are you working?

A business analyst needs to understand the world in which their client is working to fully grasp the business’ needs. The people, processes, systems and information (together a business capability) of a law enforcement organisation, such as New Zealand Police, is a vastly different context to that of a banking organisation, such as Westpac.

‘Business Architecture’ is a developing discipline that allows business analysts to create a blueprint of the business context. Frameworks, such as Equinox IT’s ‘Enterprise Analysis Framework’ (pictured), help me understand and communicate the context of a particular business and importantly any changes required to that business.

Action: Learn about business architecture and begin applying this in your organisation to gain a clear understanding of your business’ context.

Change – What change are you working on?

It’s vital to know what you need to change and what you don’t. I’ve seen projects lose the context into which they are delivering and start to redefine aspects of the business unnecessarily.

Action: Using your business architecture, get clarity and agreement on the scope of change required to deliver the success criteria (described later in this post). Keep this scope and the business context behind it central to everything you do.

Configuration – What is available and how can you use it?

When the context of a system is defined using clear business language together with business processes, data and rules (that should be managed for the business as a whole), then the process of defining solution requirements becomes more of a configuration exercise.

I prefer to turn around the traditional ‘the system shall’ approach to framing requirements, instead asking what ‘the business requires’ to perform a function or provide a service. The change is then defined in terms of:

  • what process needs to be adapted
  • what roles need to change
  • which functions require automation or system enablement
  • what information needs to be used or produced
  • what policies need to be created, adjusted, implemented.

Action: Encourage your organisation to start managing business processes, data and rules outside of projects, across the business as a whole. Then begin running your change projects as mechanisms to configure these ‘business assets’ rather than ‘reinventing the wheel’ each time on every new project.

Consensus on success criteria – What’s good enough?

An agreed set of success criteria removes ambiguity, provides a clear target for a project, and maintains its motivation and momentum, thus increasing its ability to succeed.

As a business analyst you play an important role in ensuring that the project delivers what is required by the organisation. Understanding and articulating a clear message of what is required for the project to succeed is fundamental to your role.

Action: Agree and maintain consensus on the success criteria required for your project to succeed.

Collaborating – who are you working with?

We all work better – and enjoy working more – with people we like and whose work we respect. That dynamic can be the ‘make or break’ of any project or initiative. In short, people are just as important as development methodologies. 

With that in mind, I apply the principles of ‘people over processes’ and ‘functionality over documentation’.

Action: Create your project and delivery teams using people who collaborate well, are committed to agreed criteria, who understand a business’ context and what needs to change (and what doesn’t), and who contribute to a clear focus on getting the job done.

That’s what we’re all here to do as business analysts. And we can, so long as we speak, think and act with clarity.

For more ideas on clarity as a business analyst, also see my post 3 fundamental questions for achieving clarity as a business analyst.

Recorded webinar: achieving clarity - your core business analyst competency


Get blog posts by email

New call-to-action
New call-to-action