Starting a new project as a business analyst can be daunting. Especially if you are transitioning to the role of BA. What to do first? Who to talk to? What to look for? In this article, I will provide a simple framework to help you start a new project.

Keep in mind that every project is different. That means not everything listed below may apply to your project. Also, you may need extra activities or techniques, but the list below should point you in the right direction.

I will split the start of the project into two phases: the ramp-up and the discovery.

The ramp-up

the ramp-up process

Image source: Pexels

You usually find out about a project a few days or weeks before you start interacting with the customer. I call this period the ramp-up period.

During the ramp-up, your goal is to obtain as much information and knowledge as possible about the domain, the customer, and the project. This will help you make a good first impression and will help you through the “drinking from the fire hydrant” phase of the project, the discovery.

Below are a few activities you can do during the ramp-up phase.

Gain domain knowledge

If you are new to the business domain, attempt to read and learn as much as possible about the domain. Learn the vernacular, if there are any regulations, and who does what.

Create a glossary of terms with the definitions and acronyms specific to the domain you’ll be operating in.

Perform a document analysis of any publicly available document on the domain. Think of laws, regulations, white papers, and anything that can give you a general understanding of the business domain.

This will help you in the first conversations. Your customer’s language will no longer seem like an alien tongue, and using their vernacular will help you gain their trust.

Perform customer discovery

Read up on your customer. Google them. Access their website and their social media. Use their existing systems. Register as a new customer, or ask the team to allow you to test existing applications, if possible.

Read any existing documentation, meeting notes, or important emails about the project. Learn the culture of your customer.

Set up templates that you can use once you get started (user stories, meeting notes, etc.).

This will help you understand how they operate and what to expect from interactions with the customer.

Identify competitors

See what other companies operate in the same sector. Learn about what they offer and how they work to be able to compare with what you’ll learn about your customer.

You can perform a competitor analysis.

First, select the biggest actors on the market. Then identify their standout features. List their weaknesses and how they approach different aspects of the business. Having a visual comparison of their products/websites is also very useful.

This will help you challenge the customer’s status quo. It will help you understand why your customer has taken a specific approach, and it will allow you to suggest ideas your customer may not have thought of.

Meet the team

If possible, introduce yourself to the project team, and find out their responsibilities. Learn about the customer through the team’s perspective but keep an open mind. You should also hear the other side’s argument before you make up your mind.

Start your stakeholder list or stakeholder map. This will help you understand who you’ll be interacting with.

The discovery

Image source: Unspalsh

Once you’ve started on the project, it’s time for the discovery phase. In this phase, your goal is to understand your customer. Understand their needs, frustrations, and objectives. And, of course, elicit as many requirements as possible.

Here are a few activities that you might perform during the discovery phase. Some of the activities below are iterative. You’ll need to complete them again as you obtain new information.

Also, while these activities are listed in a specific order, you may need to perform them in a different order. It depends on your project and customer constraints.

Identify stakeholders

Get to know the stakeholders and their power/influence structure.

What is their level of involvement, and who handles what? How do they interact with the project and each other? You can use a RACI Matrixand a Stakeholder Involvement Matrix.

During this activity, you’ll also identify potential user roles and personas.

Establish communication protocols & set expectations of the BA role

Map out the days and times for meetings with the customer taking into account time zones. Establish non-working days.

Identify the correct communication channels. Who should you or the team reach out to in different situations?

Establish the tone of voice between stakeholders. What is the rapport between stakeholders; who drives decisions? Set boundaries.

Explain roles and what the stakeholders should expect from every role. Here is an article on expectations for a BA.

Plan your business analysis approach

During the plan business analysis approach activity, you will list the activities to perform. The subtitles from this article are examples of activities. Schedule the work. Specify when you will perform the activities and when you will deliver the outputs.

Establish how you will interact with the stakeholders. What information will you provide? What information do you need? And how will everyone share the information? You might ask for access to a Confluence page, a Miro board, and other tools you may need.

Define change flow. For example, how do we handle changes in the team and changes to the project scope?

Understand the business (as-is)

Get acquainted with the customer’s business by understanding their perspectives. Understand existing solutions, and identify pain points. Get more information about the business domain, the clients, the end users, and the competition.

Understand the information architecture. Get an overview of how information is presented, transmitted, and used.

You might need to interview different stakeholders. Or observethem at work. You will analyze existing documentation, business rules, existing interfaces, and existing processes.

You can understand how the customer works by creating a business canvas model.

Your glossary of terms will grow as you get familiar with the customer’s specific vocabulary.

Elicit requirements

During the discovery phase, you will identify the business needs. You will extract the business requirements, stakeholder requirements, and solution requirements. You will identify functional and non-functional requirements.

To achieve this, you will need to rely on different requirements elicitation techniques such as:

Document and validate requirements

It is not enough to elicit the requirements. You will have to document and validate the requirements with the stakeholders.

Model the requirements and the information obtained based on the agreed approach at the project level. (Identified during the business analysis approach planning sub-phase).

Adapt to your audience. Teach/educate the stakeholders based on their needs and level of understanding. Present a high-level overview to managers and sponsors. Present detailed models and processes to the subject matter experts.

A few techniques that will help you document and validate the requirements are:

Define change management for business requirements

During the discovery phase, you will agree with the stakeholders on the process to change requirements. Who has the authority to make decisions, and what does the decision process look like? Who will be involved? What kind of information do stakeholders need to make decisions?

Use Decision Modeling and RACI Matrix to document the change management process.

List assumptions

At the beginning of the project, there will be many unknowns. That means you will make assumptions. To avoid problems later on, it is important to document the assumptions made. This will allow you to keep track of assumptions that are not validated. And it will keep all the stakeholders aligned.

Assess risks

During the discovery phase, you and the stakeholders will identify certain risks to the project. You will need to document the risks and do an initial risk assessment. Document and assess the risks regularly to avoid unpleasant surprises later on.

Manage the backlog

Together with the product owner, the business analyst manages the product backlog. You will be creating user stories and helping the team refine and estimate them. You may also create a user story map to identify the minimum viable product.

Reuse artifacts

Look at the artifacts created in the activities above. Think about what you can reuse for future initiatives. You might create templates or reuse certain formats for the artifacts. This will increase your efficiency for future projects as you won’t have to start from scratch again.

To summarize, before you start on a new project, you’ll want to learn about the business domain, competitors, team, and customer. Once you start, you will identify the stakeholders and understand the current state. You will elicit requirements for the future state. You will document and validate the requirements. Then you will create a prioritized backlog and list assumptions and risks.

What else would you add to this list? What would you do differently?

Article written by Sergiu Pocan