BA Planning and Monitoring | Learning BA Planning Skills

Receive free IIBA updates and exclusive content!     Join Now!

As the Manager of Business Analysis here at IIBA, I’m responsible for organizing work for my team. With several decades of business analysis experience, I’ve learned that planning is critical for each and every project, regardless of the size. For a small initiative, it could involve a few short conversations to organize the work. For a large project, with multiple BA’s, it requires a much more involved planning effort.

I’m now managing my third BA team in my career, and when I coach team members about business analysis planning, it’s not a one-size-fits-all type of conversation. Working with junior BAs, I often find there are concepts they have never been exposed to. For senior BA’s I coach based on their years of experience and get deeper into the details based on their familiarity with tools and techniques that they need to be successful and independent in planning the business analysis work. I will cover the basics in this blog.

 

What is Business Analysis Planning?

My favourite saying about planning is “we don’t plan to fail; we fail to plan.” For every initiative, there is a need to plan before digging into the work. The key parts I focus on are:

• Stakeholder Engagement – who are the stakeholders, how will they be involved with the project, and how will you communicate with them?
• Project Approach – organizations are more frequently using multiple approaches for their projects, so you need to determine the best project approach for your initiative
• Documentation – communicating clearly and concisely is critical for any initiative. The project approach will influence how you create, share, and manage the documentation

These areas shape how your project is setup, to they’re the foundational elements you need to understand. If you’re not planning, you risk running into challenges during the project where you have to redo work, increase the project budget, or even worse, cause the project to fail.

Why is Stakeholder Engagement Important?

The purpose of a project is to introduce change and the change needs to be articulated by stakeholders. In business analysis work, this is where soft skills come into play to understand who should be engaged to articulate the needs. This is influenced by your organizational structure, culture, and your organization’s approach to projects. Selecting the stakeholders is a detailed topic, which is beyond the scope of this blog.

Once the stakeholders are identified for the project, you need to meet with them to:

• Understand and clarify the purpose of the initiative
• Obtain their buy-in to provide approvals throughout the project
• Obtain their commitment to provide subject matter experts to work with for defining the requirements and conducting user acceptance testing to prove their requirements are met

Please don’t dismiss this step as theoretical and not relevant to your project. I’ve witnessed projects that failed to do this step and they have always suffered in some way; poor stakeholder relationships, loss of reputation, increased project budgets, and in some cases failed projects. I’ll repeat one of my favourite sayings again “we don’t plan to fail; we fail to plan.”

What Project Approach?

I generally think of projects as either waterfall or agile/iterative. Regardless of the terminology used to describe these, my core thought process is how to organize the business analysis work in the context of the organization and the project.

There are many organizations who have transitioned to agile project practices, but there may still be needs to use a waterfall project methodology. I don’t see either of these going away in the future. In my previous work experience, working in an organization with high priority on cost controls, waterfall projects were dominant to clearly define all the needs up front before building a solution. In my current work, we’re using agile/iterative project practices to deliver value sooner than what can be done in waterfall projects.

There is no right or wrong answer for choosing a project approach as it depends on the work environment and the systems or processes, you’re changing. What is important is that you determine up front what approach you are using as it will impact the stakeholder communication and your documentation.

How to Document?

The third element of planning I want to cover is documentation (referred to a Business Analysis Information Management in the BABOK® Guide). I teach my team members that “our documentation is the contract with the customer that defines what success looks like.” We want to be clear on what needs to be satisfied so we are all aiming at the same target. The approach for documenting will be different depending on the project approach. It wouldn’t make sense to define 100% of the requirements up front for an agile project, just as it would be impossible to run a successful waterfall project with requirements trickling in over the life of the project. The documentation approach must align with the project approach.

Admittedly, my go-to documentation tool is Word. It’s the first thing I open to write down my thoughts. I have requirement templates in Word. But the world of technology has evolved over the past decade and there are a variety of tools available. For example, JIRA may be used to document stories for an agile project. Selecting the method and tool for documentation is key so the subject matter experts and stakeholders you’re working with understand how you will be communicating with them and aligning with them. Documentation is the communication “glue” that holds a project together and it’s critical to every project.

I hope you find this helpful as an introduction to Business Analysis Planning. If this topic interests you, I suggest seeking out a mentor who can provide some coaching. Perhaps it’s a senior resource in your team or your manager. The sooner you learn this skill, the more prepared you will be to tackle you next challenging project.

 

 

---

 

About The Author: