24 things to find out when taking over a project (BA checklist)
When you hand a project over to another BA, or when you are taking over from somebody else, it’s important to make sure that the appropriate information is transferred. This post will tell you what to look for in this situation.
There are times when you need to take over a project from somebody else, or to hand it over. In order to ensure a smooth transition and avoid unnecessary repetition of work that’s already been done, all the previously collected information needs to be transferred to your successor. It may not happen that often, which is all the more reason to have a checklist of steps that need to be carried out when the situation does arise.
First of all, you’ll need to know who you should be working with. You should find out about key stakeholders, key business function/process owner, and business end users, and how to communicate with them:
- name, contact details
- communication style
- role and attitude
- frequency of communication
- log of communications
- communication granularity level
- interests – common ground to share
You’ll need to learn the details of the project and the current activities:
- Project manager details
- Team member details
- Key milestones
- Solution(s)
- Components
- Documentation
- Business analysis plan
- Deliverables (completed and outstanding)
- Established KPIs
- Current state of affairs
- Details of the release cycle
- Third parties involved in delivering the solution
- Solution components
- Documentation (where to find it, what state it’s in etc.)
- Queue of enhancements/change requests
- Known pain points/issues and who raised them
- Known solution defects, including details of who reported them, who’s responsible for fixes and so on
- Dependencies
- Constraints
Related posts:
THANK YOU! I am just taking over a complex project from an outgoing BA. Wish I had this a few weeks ago but still will very much come in handy. You guys are awesome!
Glad it’s useful!
This is great information! I beginning my job search for a BA position and this information will be of great use! Thank you for sharing!
I see four categories into whchi various items are mentioned.
Don’t they appear in different BA documents like, RFP (from client), Response to RFP, Project Plan, Business Requirements Document, Solution Design Document (this may not be a standard name) etc?
Hi Putcha.
We did not have an intention to categorise information per BA documents. The goal was to outline all details required to get up to speed as quickly as possible when a change of BAs happens during the project lifecycle. The checklist shows sufficient information to feel comfortable when someone takes a project from the leaving BA.
Also, please note that an RFP is not normally within the BA domain, and a project plan does not contain all the required information.
This is a good reminder of the questions to ask. Unfortunately, often the reason you are taking over a project is because, for good or bad reasons, these thing were not known.
And if these things aren’t known, the checklist tells you what you need to find out on your own
On a more serious note, with the checklist you can at least be sure that whatever information *was* collected gets passed on to you.
Excellent. Thank you for sharing.
Quite Useful. Thanks for sharing.
Useful Information..