I’ve been asked this question, and after considerable thought, I would like to tell you what I think makes a great Business Analyst.

So here goes…

There are number of skills and qualities that I believe you, the Business Analyst, must have to be competent in your role. This includes the ability to gather, analyse and model requirements using various techniques and tools, and produce documentation that clearly communicates change.

You typically like to help solve problems, you have an inquiring mind and you are comfortable asking questions. Many questions. You strive to build relationships and create alignment with your stakeholders to ensure clarity and vision of requirements.

You are an effective communicator, you listen and respond to feedback and you relate to your stakeholders on their terms. You are a good listener. You’re also a good negotiator and you manage your time and stakeholder expectations on requirements and deliverables.

Preferably, you are passionate about what you do. Passion gives you the drive to learn more, energises and fuels your success, strengthens your confidence, inspires persistence and improves your working relationships. Of course, you can’t always feel the passion – I know I don’t. But if you can identify the things that drive you, then your work will benefit.

As an effective Business Analyst, you continuously extend your skills and capabilities. Even if it is just by a little bit. You endeavour to learn more and improve your capabilities with each new project. You don’t stagnate.

You understand that even though you may often work on technology implementations, they are not really technology projects. They are business projects. Projects that impact the way people do business – hopefully for the better. Technology is a means to an end.

You know that business analysis is about facilitating change within an organisation. This change may be at the enterprise level, at the project level, or anywhere in between. Your role is important.

You create value…

Yes, you.

How you deliver that value depends on the work you’re doing and your audience. It also depends on how well you communicate that value.

You continuously ask yourself these questions:

  • What is of real value here? and Why?
  • How can I demonstrate value in this context?
  • What do I need to do that?

You know it doesn’t matter how you do it as there is no right or wrong way. Ultimately, your work must demonstrate value to be of any benefit to your stakeholders, the objectives of the project, and the organisation as a whole. Understanding this keeps you focused and aligned on the work that matters the most.

You know that success is definitely about creating value.

And this makes you a great Business Analyst.

There’s a lot written on the topic of common mistakes made by business analysts. That’s because considerable thought is given to how good business analysis practice can add value to an organisation, which is important for sustainability and growth.

Some of the bigger issues for business analysts are:

  • Failure to see the bigger picture and the problem that needs to be solved, which results in poorly aligned deliverables,
  • Being too solutions focussed, which leads to requirements written for a solution that does not satisfactorily meet the needs of the organisation,
  • Missing requirements in the specification or requirements are poorly expressed, which causes misinterpretation and wasted time in rework,
  • Poorly managed requirements due to inadequate tool support (i.e. no traceability), and
  • Inadequate stakeholder involvement, which results in signing off requirements without sufficient collaboration and verification from all user classes.

In my experience, the risk of these issues occurring can be significantly reduced with good planning. In my opinion, not planning your work is the one mistake that business analysts must avoid from the outset.

By adequately considering the goals and objectives of a project, the problem you’re solving, and the desired organisational outcomes, you will be better placed to focus your activities in the right direction. And you’ll mitigate the larger risk of some of those common business analysis mistakes occurring.

Of course there’s no guarantee, but you are putting your best foot forward by taking the time to think through your approach. And that gives you the comfort of knowing that you’ve done your best to communicate and mitigate any identifiable risks to the project at the level of your work.

As Business Analysts we must understand the importance of planning.

Without a way to describe our approach, it’s easy to get waylaid on a tangent or stuck in analysis paralysis. Often the overarching project initiation plan – typically written by the project manager – does not adequately cover the business analysis components of a project. If the BA work is not clearly defined, it can present a risk to project outcomes and stakeholder perceptions.

One way to overcome this is to develop a Business Analysis Approach document which describes the activities, deadlines and approach to delivering your work. This document can work in conjunction with a project plan or as a standalone item.

Here are 3 reasons why you should plan your next Business Analysis effort.

1. You improve your communication. A very important part of successfully completing your work is communication with your stakeholders. The BA Approach Document clearly describes what you will deliver and why. It sets expectations on how you perform your work, the resources you need and the types of activities you will engage in, e.g. workshops and interviews. So everybody is on the same page! Planning also increases the transparency of your work as the small processes of your work are better understood. This helps when expectations have to change.

2. You’re better organised. In developing the Business Analysis Approach you’ve laid out all aspects of your work in front of you. Not only does this benefit your stakeholders, but you have a clear and agreed path to follow. This prevents tangents and over analysis. Having a plan also helps when you are working on multiple projects or activities. This is because you need to consider timeframes for your activities, and any other outside work that will impact on them.

3. You’re more focussed on the goal. A project plan is not only important for communication with your stakeholders, it’s also valuable to keep you on track. It’s a way of keeping your work aligned to the finished product. With every activity you perform, you should ask yourself if it is relevant to the end product. Ask yourself, “What value am I adding here? Is this relevant to what I’m delivering? Is this in the plan?”

So if you want to be more effective on your next BA project, it’s worth investing some time in planning your activities and approach.

Recently I discussed how your documentation should clearly communicate value and that it’s important to understand whom your deliverables are intended to serve.

Whether you’re recommending a case for change to decision makers or delivering a functional specification to a technical team, your documents must contain value for your audience.

Value may come in the form of:

  • Clearly describing a problem and recommending a solution that is aligned with the organisation’s needs,
  • Assisting decision makers with the best approach moving forward by helping them understand costs and benefits,
  • Succinctly describing the characteristics of a solution (whether it be a new system, a process change or something else), or
  • Assisting an organisation with managing change or continuous improvement.

It’s my opinion that there’s no right or wrong way of communicating value as long as you know what you need to communicate and why.

Your documentation may be written according to a best practice framework and your diagrams may follow the UML specification to the letter. However, if your stakeholders cannot interpret and visualise the solution you’re describing, your documentation is ineffective. And will contain significantly less value than the document that doesn’t follow best practice but effectively expresses the intended message.

The delivery and presentation of your documentation is one opportunity to demonstrate the value of a project, and your value to a project. Your value is frequently demonstrated in how well you have understood a problem and aligned it with a solution.

Throughout the lifecycle of a project, you have the opportunity to deliver value at every step of the way. Just ask yourself “What’s of value here? What’s really important? Why is it important?” And at every point, try to express these important things as clearly as possible. Do this through all channels of communication including your documentation to make clear and powerful statements about how a problem can be solved.

Determining what documents to deliver on a project is not done in isolation. If you recall from my free eBook, The First Bite, the very first questions I ask when I commence a project include:

  • What is required of me?
  • Do you have an outcome already in mind?
  • What are the expected deliverables?
  • In what format do you expect the deliverables to be produced?

The answer to these questions not only provide you with a broad overview of the business activities to be undertaken, but also the type and format of the documents to be produced. As more is understood about the project, the more refined your understanding of those deliverables will be.

Therefore, the questions above are the starting point for understanding the objectives of project. The project objectives inform the documents and deliverables required, and the deliverables inform the type of information you need to gather.

In understanding the objectives of the project, and the things that you need to produce, it’s important to understand these three things.

  1. The intended “end game” may change as the project progresses. As new information comes to light, the objectives may change and so may the required deliverables.
  2. The project is not about producing good documents, but adding value to the organisation. The documents just help you deliver that value.
  3. Documents are not true deliverables. Nor are systems or processes. The true deliverable is the value you bring to the organisation.

Value is the key. How you deliver that value occurs through a variety of mechanisms but it includes your documentation. And your documents must communicate clearly and accurately to your intended audience.

For instance, I’ve read many business cases that lacked a suitable description of how the recommended change would provide value to the organisation. As is frequently the case, the so-called value is written from the perspective of the solution.

For example, the recommended XYZ system will:

  • Store data in a central repository
  • Provide a single source of truth
  • Eliminate duplicate records
  • Improve accessibility

These are good benefits, but what is the real value to the organisation? The decision makers need to know but it is not communicated clearly.

The same scenario applies if you were delivering a detailed functional specification. You need to provide the information in a way that the technical team (your audience) can design and implement code with as little re-work as possible. Therefore, they need a suitable description of what the solution will look like and how it will work.

So a document must accurately communicate to the intended audience. And it’s my opinion that there is no right or wrong way of doing this, as long as it communicates its value.

Yesterday morning I was walking to my office building. It was just like any other day. Bleary eyed and oblivious to my surroundings I moved through a near empty mall. It was too early for opening hour.

A man popped in to my vision just ahead of me. We were bound for a head-on collision. So I veered to my left, but he moved to his right. Noting that we were still heading for impact, I inched even further to the left. At this point I’m very close to a shop window, but I was mildly determined to stay on my course.

I had some underlying assumptions.

Firstly, in Australia we drive on the left hand side of the road, and we give way to cars on the right. So generally speaking, people walk to the left when passing, and give way to others coming from the right.

Further, men generally give first preference to women in doorways and passages. Even when I don’t want or need to go first, I’m almost always politely urged to step through. Not always, but mostly, and that’s fine with me.

So I was sticking to my guns.

And the man heading my way was finally forced to move left and around. He abruptly stopped, stomped his foot and glared straight at me.

Oh dear. It was way too early to really make sense of the situation.

Though based on my beliefs, I clearly had right of way! I responded with a somewhat bemused expression and moved on.

I thought about it afterwards.

I thought generally about how certain assumptions, beliefs, and norms may no longer serve us, or may never have served us at all.

As a business analyst you are often faced with conventions, procedures and practices that may no longer, or never did, benefit the organisation. Quite often the people in the business are not even aware that they are following outmoded norms. They are so busy doing the work, and when asked why, they respond with:

That’s the way we’ve always done it

We have to do it that way because it’s policy

I never really thought about it

It’s crucial not to be critical at this point.

As Neale Donald Walsch says, “No one does anything inappropriate, given their model of the world.”

It’s important that you determine whether those outdated practices need to be challenged. Are they worth challenging? Does it depend on the outcomes you are trying to achieve for the organisation? Maybe you could plant the seeds now, and wait for a better time.

Like difficult teenagers, pick your battles.

And when you do, you must facilitate the conversation, not dominate it. Ask your stakeholders questions that help them arrive at their own realisations about the possibility of change.

After all, they know their business better than you. Don’t they?

Don’t arrive at the meeting with exciting news of how you’ve identified the problem and know how to fix it. Even if you do know, give your stakeholders the stage to direct control over the decisions being made.

In doing this, you will earn greater stakeholder buy-in and the results are more closely aligned with the organisation’s needs. Also, the changes have a much higher chance of success.

This is the premise in which I approach my business process workshops and any other setting where change requires discussion.

Like organisations that must challenge outdated practices due to changing economic demands, it’s time that I rethink my own assumptions about people passing on the left and giving way to those on the right.

The city I grew up in is now a place of ever increasing cultural diversity. There are more and more people from different countries, cultures and backgrounds. And not everybody knows about my pass-on-the-left rule!

Before I became a business analyst, I was a spatial systems analyst. My major at university was geographic information systems and during that time I was very fortunate to win short-term contract with a research centre.

My role was to define the requirements and implement an online spatial database for a very large pastoral property in the Northern Territory. It was a pilot and, bearing in mind that this was many years ago, the technology was very new for that part of the world.

What was also very new to me was the concept of a structured approach to planning and execution. When I was asked to present my plan to the project board, I went way off the reservation. The feedback was embarrassing. I had spent a lot of time and effort in getting it all wrong.

I was no longer at university. This was real work in the real world, but I had no idea what I was doing and no idea of what questions to ask. Fortunately people who did know surrounded me, and I was put on the correct path.

So here’s the thing.

It’s vitally important to define the objectives of your business analysis project, and show how those objectives are going to be met. Upfront. This is so you are correctly aligned with the expectations and aims of the desired outcome.

Also, every organisation usually has a set of defined procedures and methodologies that informs the way you plan and carry out your business analysis effort. Using the organisation’s framework in conjunction with an understanding of the steps in the business analysis process will help you define the scope, your approach and the primary objectives of your work.

Proper planning and preparation prevents poor performance.

Planning is crucial, and so is checking with your stakeholders that the proposal is on the right path and meets their expectations. So it’s important not to skip it, or imagine that you know what you’re doing. Like I did all those years ago.

If I hadn’t been realigned with my work, I may have wasted considerable time and resources to achieve an outcome that didn’t suit the needs of my employer and their clients.

If you want to be seen as someone who gets things done and delivers results, a good set of templates in your business analysis toolkit can help.

I recommend the Business Analyst Template Toolkit as an excellent foundation for your toolkit of resources.

The Business Analyst Template Toolkit is not just a bunch of templates containing empty sub-headings. These templates will increase your effectiveness as a business analyst by helping you produce better quality and concise deliverables.

It’s a valuable resource containing 12 fully annotated templates and helpful guidance on how to use them. For each template, a corresponding work sample shows you what the template will look like when completed.

The toolkit comes with instructions on how to apply these business analysis deliverables in each of the three broad phases of a project. These phases are initiation, definition and implementation. And for each phase you – the business analyst – will provide input at varying degrees.

Whether you’re scoping the project requirements in the initiation phase, developing the functional requirements in the definition phase or revising changes during the implementation phase – the Business Analyst Template Toolkit gives you the guidance you need to produce the correct deliverables in each phase.

It won’t be the magic bullet that makes your work suddenly exceptional. Neither will you suddenly produce clear, precise and consistent requirements. That’s up to you. But it will assist you in improving the quality of your work and it will provide you with a helpful structure to follow that will save you time.

I’m often asked about business analysis documents and how these deliverables tie in with an approach such as Agile or Waterfall.

As far as documentation is concerned the approach taken influences when, and in how much detail, a document is produced. The document may also have a different name but the goals of the business analyst are the same no matter the methodology used.

The goal of the business analyst is to identify business needs and determine solutions to business problems. The solution may come in many forms but typically involve:

  • The implementation of a new system
  • Enhancements to an existing system
  • Business process improvement
  • A new information strategy
  • A new policy or strategic plan
  • An organisational restructure
  • A combination of any of the above

Most commonly, business analysts are involved in the first three.

Understanding the type of project, the problem you’re solving, or the solution you are delivering will inform the types of documentation to be produced.

If you’re procuring an off-the-shelf product, you wouldn’t write detailed descriptions of functions and features of the system. You would, on the other hand, produce business requirements with enough information about how the stakeholders need to interact with the product and for what purpose. These requirements would also include some important qualities of the system (e.g., the system must comply with the organisation’s standard operating environment). A product vendor can then provide a detailed response that aligns with the criteria of the organisation.

Where a custom solution is being implemented, highly specific descriptions of functional and non-functional qualities are necessary. In addition to the initial business requirements, the deliverables could include use cases, a user interface specification and data flow diagrams. These documents must be written with enough detail to hand over to the people who design the system’s technical architecture and write the code.

So to understand what documentation you must produce, you need to understand the type of problem you’re solving.

This is your starting point.

A few years back, I started a new role just before Christmas.

In the first week my Project Manager told me I had to start workshops immediately – that week! Two of our key decision makers were taking leave and will not be available until mid-January. Waiting more than a whole month was not an option so I had to get started.

It was the worst possible time to commence something new. People were frantically trying to meet deadlines before the Christmas shutdown, and nerves were frayed with many competing demands on time and resources.

I sat at my desk with my head between my hands. I had a headache.

I didn’t know a thing about the problem space yet. This was the real issue. I felt stuck and overwhelmed. It was a new project in a completely new domain with new stakeholders.

Will they accept me? Will they cooperate? Will I even understand them?

I reminded myself that I never ever wanted a repeat of the horror meeting of 2003.

You have to get through this, I thought, so what are you going to do?

And that’s when my thinking shifted from worry to problem solving mode. Phew!

I realised that there were things that I could do. After all, I controlled how the workshops were going to be run, and I could design them in a way that would serve my agenda too.

So I did just that, and I discovered that you can do the same for any given context.

Here are some questions that will help you jump into a new domain or project so you can start actively contributing as quickly as possible.

  • What is the problem being solved?
  • What do I already know about the problem space?
  • What don’t I know?
  • What information is available?
  • How do I get that information?
  • Can I get that information from stakeholders or other sources?
  • Who do I need to talk to?
  • What are their organisational and project roles?
  • What information do I need from them?
  • What questions do I need to ask?
  • How am I going to ask them? What format?
  • What am I going to do with the information?
  • How am I going to analyse it?
  • What other information will help the analysis?
  • What are the deliverables that I’m producing?
  • When do I need to deliver them?

The answers to these questions give you the information you need to understand the domain, plan your next steps and inform your deliverables. The more questions you ask, the better informed you are.

You can use these questions to orient yourself to an immediate problem – such as my pending workshop – or to the overall project. The sources of your answers will vary, and how you use that information is based on your knowledge and experience of the business analysis process.

This is your winch to save you from getting stuck, and keep you moving.