Inheriting Projects

Working in a corporate environment we are often asked to drop tasks and projects that we are currently involved in, so that our efforts can be concentrated on other initiatives within the organization that needs our attention.

We often need to transition these tasks to other individuals in the same or similar role as our own.

“One of the hardest things for someone working in Business Analytics is letting go of a project they are working on or transferring it to another Business Analyst.”

You have already put in significant time, effort, and energy to bring the project and stakeholders together and now you are being asked to transition it to another person. The first thing that comes to mind is a younger version of myself that says “I don’t wanna share! This is my toy!”. I was an only child, so I didn’t have to share a lot when I was younger, but when I did it was an effort for my mother to get me to do so. Thank you, mom, for teaching me this important life lesson early on, so that it is easier for me to share as an adult.

“It is perfectly acceptable to share our work with others when we need assistance.”

I have been on both sides of the coin (giving and receiving). It can be strenuous for both parties for different reasons, but the analyst receiving the project from another will have to perform more work initially in order to be brought up to speed on the project. Many times, you may not even know which questions to ask or what information you need as you have not been associated with the project in any role.

“Working in the field of Business Analytics, one needs to remain flexible and open to change.”

I have devised the below checklist to assist with the transition process from one Business Analyst to another. The checklist is meant as a guide or a talking point when creating your very own Transition Checklist. The Business Analyst should be thinking about the potential answers to each of the items during the initial transition of the project. Each project is different and working in the Business Analysis field, we need to be committed to change. Therefore, each Transition Checklist may be different. The checklist below is created from the aspect of the analyst(s) receiving an active project, however, the analyst(s) transitioning the work to another should be proactive and communicate as many of the touch points listed below as applicable to the project.

---

---

Identify:

• Verify the tasks, goals, deliverables, and roles in the phase(s) owned by your team
• Identify what methodology is currently being used: Waterfall, Agile, Agile-Waterfall Hybrid
• Identify the project goals and scope
• Are the correct resources on the project or are there resources missing?
• Determine if it is possible for the previous analyst to stay on the project as a mentor for a short time period
• Conduct a meeting to introduce yourself to the new project team. Make sure to cover the following:
• Review established expectations
• Review established ground rules
• Review key decisions made prior to your assignment
• Review Stakeholder roles and responsibilities for accuracy
• Inform group of what they can expect from you moving forward
• What is the current communication style?
• Is there a communication plan?
• Where is the project documentation stored?

Analytical Services:

• Meet with the current analyst on the project and complete a knowledge transfer
• Walkthrough of the requirements and project scope
• Review the current BA Plan and complete any updates needed
• Obtain written approval of updates from key Stakeholders
• What are the deliverables (completed and outstanding)?
• Project milestones
• Change Requests
• Requirements
• What is the current phase of the project?

Project Details:

• Meet with the Project Manager to cover the project timeline
• What are the key milestones that will need to be completed and the dates?
• Record the impact/risk of the transition of Business Analysts on the project
• What is the current health check of the project: At Risk, Poor, On Schedule, Ahead of Schedule
• What are the dependencies or relationships with other projects?
• How many Project Managers are currently assigned to the project?
• How many Project Managers have been transitioned off of the project?

Solution Details:

• What are the Known Production Problems that are to be resolved as part of the project?
• What are the details of the Release Schedule?
• Who are the Third Party Vendors involved in scope, requirements, testing, or implementation?
• What are the defects associated with the project?
• What are the identified constraints?