How to Build a Transition Plan: 4 Steps to Onboarding a New Business Analyst

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.

#1 – 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 pulling together the following documentation to share what you’ve learned about both:

  • Business Domain Information — 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.

#2 – 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. This technique is called stakeholder analysis, but it’s unlikely that all of your knowledge is pulled together in one easy-to-refer-back-to document.

Consider putting together a document that includes the following sets of information:

  • 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.

If time allows, it’s also a great idea to individually introduce the new business analyst to each stakeholder. Otherwise, consider an email introduction.

#3 – 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.

#4 – 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?

>> Don’t Forget About Career Planning!

While career planning may not be part of initial onboarding, as your new business analyst becomes secure with the business domain and job role, you’ll want to work with them to form a path to career development. Consider starting with our free step-by-step career planning course. Upon joining, you’ll also receive our BA career planning guide and follow-up insider tips via email.

Click here to learn more about the free course

13 thoughts on “How to Build a Transition Plan: 4 Steps to Onboarding a New Business Analyst”

  1. Hi Latonya,

    Thanks for the feedback. I can imagine that would be helpful because in a leadership role you also need to understand the business, systems, and stakeholders as well. I’m glad to hear this tip is useful beyond BA!

    Best,
    Laura

  2. I stumbled across this post while searching the web for tips on transitioning into a leadership role with a new company. Although the information presented is specific to business analysts, it was very helpful to my work as a non-profit professional; I was able to take the information and translate it into the role I currently hold. Thank you very much for posting this information!

  3. Well timed Article Laura. I was planning to write a similiar post as I am also passing on the baton to a new Business Analyst and have got couple of weeks for the transition starting Monday.
    My transition plans overlaps a lot with yours…what I will do is write a post after the transition is done and share my learnings.

    Thanks for the post!

  4. Laura, you have a very thorough plan laid out. I think that information involving how Business Analysis is viewed within the organization would help.

    1. Wayne, Congrats on your new role and good luck with the transition. I hadn’t thought of it this way, but this checklist could also provide a list of questions to ask your mentor when transitioning into a new role. Great idea!

      Mary, I like the idea of also sharing how the role is viewed. This would definitely help the new business analyst find their place more easily and avoid some pitfalls. Since the role is still different within each organization, this would really help the new BA get started. Great idea.

  5. Laura –

    I will be moving to a bus-sys analyst role at a new company early next year and this information will help me frame my transition. Thanks for the insights.

  6. Laura, if you only had a week to impart the most important information, I agree that business and system domain knowledge should come first. I would cover the business domain knowledge first if the system and project documentation was clear and well organized.

    I also especially appreciate your points about how the software development process works here. Every organization is different, so communicating the particulars about how the process works would make the new resource’s transition so much smoother.

    The tidbits about stakeholder personalities are really just the icing on the cake if you have time to share this kind of information.

  7. Thanks, Linda! Great idea about the stakeholder personalities. That is indeed key. I suppose the opposite side of this question is “how much is too much?” or “if you only had a week, what should you absolutely focus on?” From this perspective I’d say the primary area of focus would be business domain knowledge. Thoughts?

  8. Laura, any BA who received the road map to success (transition plan) that you described above should consider herself/himself most fortunate!

    The only addition I can add, which I am sure you also include, is some verbal information about the personalities of the various stakeholders:

    So and so is a very visual learner.
    So and so tends to be slow at responding to emails but don’t be afraid to drop by his desk.

    A few clues about how best to approach some people or the definite pitfalls to avoid are worth their weight in gold.

Sign up for weekly updates and access to the FREE Quick Start to Success workshop:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

Laura Brandenburg
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.

Scroll to Top