Building a transition plan to onboard a new business analyst hire

Nothing is worse than starting a new job with a set of expectations and you don’t know what they are. When you transition from one role to another, how do you set-up the person taking on your job to be successful? It’s important to impart as much knowledge as possible, along with the context of what you do and why. But it’s just as important that the new employee is set-up do forge their own path into the role.

I’m in a position right now to fully transition my responsibilities to a new business analyst, so I’ve been giving this idea some thought. I’d like to put my ideas out there so I can also get some feedback. I’m in a lucky position where I’ll have a full month (possibly more) to transition my role. I’d like to do this right.

Impart business and system domain knowledge

As a business analyst, you need to gain an understanding of the business domain and how the software systems support the business. Consider the following aspects:

• Business Model – share an understanding of the customers, products, and how the operational processes support the products.
• Key Business Processes — share knowledge of the key processes that support the business.
• System Diagram — list of the systems the business process and what they do.
• Actors / Use Case Diagram — overview of the key roles and what they do with the systems.
• System Walk-through — functional walk-through of the key systems, including a description of how they support the business processes. Some organizations may have detailed systems documentation. Include a review of the documentation, but provide context with a walk-through.

Identify the business and IT stakeholders

Business analysts work with a variety of stakeholders. During your tenure in a position, you build knowledge of who needs to be involved with what types of questions. Consider the following elements:

• Functional Departments — a high-level organizational chart of the departments you work with and how they are related from an organizational perspective.
• Business Stakeholders List — list of individuals within each department that serve as stakeholders on projects. Include their role, their expertise, and a list of reasons they may be brought into a discussion.
• IT Stakeholders List — list of individuals on the development and IT support teams that you work with to define and implement the requirements, including their roles and expertise.
• Introduce the new business analyst to each of the stakeholders.

Share information on outstanding IT requests and projects

In most cases you are not in a position to leave everything you’ve worked on in a complete state. You’ll need to share information on active projects in development so the business analyst can serve as the new touch point for questions and concerns. Share the project vision and purpose. Explain what steps you’ve taken so far and what still needs to be completed. Conduct a walk-through of any available documentation so the new business analyst has a complete understanding of what has been done to-date.

You’ll also need to review the backlog of requests you’ve started to analyze. Consider how you’ve got your documentation organized. Will it be easy for someone else to establish the context of these new requirements or does that need to be developed? Is it clear who requested the change or enhancement so that follow-up questions can be asked and answered. This part of the transition involves leaving things as organized as possible while also conducting a walk-through of the structure so the new business analyst can pick up where you left off.

Describe the business analyst responsibilities and software development process

There is a lot of variations among IT shops in terms of how projects move from from initiation through to completion and how the business analyst supports that process. Go through the software development process in detail. Outline who does what and how everyone works together. Dive into detail about your role as the business analyst. Some aspects to include are:

• What are your inputs? How do you learn about new work?
• What are your outputs? What is your work product like? (It may be helpful to share some sample work products from past projects.)
• Are there standing meetings? What is expected of the BA in those meetings?
• What meetings do you normally schedule throughout the life cycle of a project? What is the BA role? Who gets invited? What is a typical agenda like?
• What steps do you typically take to complete your work? (Recognize that each person might have an individualized path toward completing their work.)
• What tools do you use? How do you use them?
• Where do you see opportunities for improvement?

This is my starting point for developing a transition plan. I’d welcome the opportunity to hear your ideas from the giving or the receiving end of a business analyst transition.

Related posts:

1. Building a mature business analyst practice: Interview with Mark Jenkins
2. Reverse engineering requirements: Create a Work Plan
3. Building a better business analysis practice