You have just completed a series of discovery workshops with your stakeholders. You're all done with interviews, show-and-tells, and other meetings. You even went as far as compiling the outcomes - project vision and scope, the functional backlog for MVP, and candidate stories for the 1st development sprint. Great job!
Do you think you're done with Discovery now?
Photo by Canva Studio from Pexels
Well, not just yet!
Before you actually call it “done”, you need to run, perhaps, the most important meeting in the entire discovery, if not the whole project!
I’m talking about the Knowledge Transfer meeting. This is when you present and "transfer" all the discovery outcomes and results to the delivery team—the team that will actually build and deliver the product to the stakeholders. Often, this meeting is overlooked which leads to issues with the project delivery down the road.
In this article, I'll share a detailed agenda and practical tips for handling knowledge transfer sessions in discovery projects.
Free Discovery Checklist for Business Analysts
Why Bother With the Transition?
If you’re new to requirements discovery in the software development cycle - please check out my other article where I discuss this in more detail - What is Requirements Discovery?
Before we actually get to the KT sessions, let’s revisit that the Analysis & Transition phase (sometimes called "Completion") is the final logical step in requirements Discovery.
During this phase, BAs and the discovery team analyze and compile the discovery outcomes, and transition them to the delivery team. If you skip this, your team won't have anything to work with, and all the valuable knowledge will remain with you and the discovery team, instead of being passed on.
Of course, you want to make sure that what's in your head is actually transferred to the delivery team. This includes not just functional requirements but, more importantly, the context of the client's business, their pain points, the struggles of real users, and how the product, you're about to build, will solve them.
One significant difference between the Discovery and Build/Delivery phases of a software development project is the number of people involved. In the discovery phase, you're in a relatively small consulting team. During delivery though, we're talking 20, 50, and sometimes hundreds of people involved.
During the transition, we start preparing for the actual Build or Delivery phase of the project. This is where you'll start seeing more and more people joining the team who are new to the business problem we're solving.
And here’s the main point - it is your job to help your new teammates get up to speed as quickly and seamlessly as possible, to ensure the team is set for success.
How to handle a Knowledge Transfer Session?
Alright, so how do you run a knowledge transfer meeting?
During the knowledge transfer, you will present to the team the main discovery findings and all the outcome documents you've produced. This is where we will walk the team through the feature backlog that we've collected, the solution design that we came up with, user experience wireframes and UI designs that we produced, and so on.
Depending on the size of the project, you may even have a sequence of knowledge transfer sessions, where first you handle the transition for the leads and key team members, and then separate sessions for the entire team. The audience is usually your new team members - software developers, QA engineers, new BAs, and project managers.
It's very important to give the team the right context - the history of discovery, how it all started, why your company was invited to participate, and who are the people on the client side that you met. These things really help get the right context and are instrumental in helping your teammates to get up to speed.
Now, I want to share with you the agenda for a knowledge transfer meeting that you may use for custom software development and consulting projects.
Agenda for a Knowledge Transfer Session
Introductions - 5 minutes
Welcome your new team members.
Share your role on the project/discovery team.
Customer Profile - 5 minutes
Briefly describe the customer's business.
Provide a summary of their history, markets, and main locations.
Current Process and User Pain Points - 10 minutes
Explain the focus business process (e.g., order management, shipping of physical goods, insurance claim processing, etc.).
Introduce core business terms and definitions.
Discuss user pain points and refer to the discovery interviews; mention what real users say and experience today. This will add the element of empathy that we want to keep in the development process.
Problem Statement and Project Goal - 10 minutes
Clearly state the project goal and how achieving it will improve existing processes and solve the pain points.
Success Criteria - 10 minutes
Outline the benefits to the customer's business and users.
Define how success will be measured using specific metrics.
Customer Stakeholders and Org. Chart - 10 minutes
Provide details on key business and IT stakeholders on the client side.
Mention roles such as IT directors, product owners, solution architects, developers, QA lead, and UX lead.
Emphasize the importance of building relationships with counterparts on the client side.
Functional Decomposition - 20 minutes
Dive into the scope details, including epics and functional areas.
Highlight integration points with external systems, and known dependencies, including the 3rd party vendors or internal customer teams.
Share any available UX wireframes or business process diagrams.
Store artifacts in a shared space for future access. Inform the team where to find them.
Technology Landscape - 10 minutes
Present the details of the current technology landscape.
Discuss the tools the client is using, including their pros and cons.
Highlight any upcoming technology projects on the horizon.
Introduce the technology experts on our team and the client side.
Risks - 5 minutes
List out the main known risks and strategies to mitigate them.
Team Structure and Next Steps - 10 minutes
After covering the above topics, let's focus on the team structure. It's important for team members to understand their roles and responsibilities within the project structure.
Share a team org chart to visualize teams and their cross-dependencies.
Next Steps - 5 minutes
Do we have an onboarding guide for the team? It should include details on accessing development environments and where the requirements specifications are stored.
Task tracking tools we are planning to use: Jira, Azure DevOps, ServiceNow, etc.
Provide specific steps to get through the onboarding process
Q&A - 10 minutes
Lastly, allocate some time for questions and answers.
As an important follow-up to the meeting, ensure that all shared artifacts and presentation slides are stored in a common team space (Sharepoint, Confluence, MS Teams, etc.). Share the link to this space with the team after the meeting.
As far as timing, you need to plan a minimum of 2 hours for the knowledge transfer meeting. Now, you can choose to conduct it all at once or split it into two parts. For instance, you could begin with 1 hour on Monday and complete the remaining hour on Tuesday. Alternatively, you can schedule part 1 in the morning and part 2 in the afternoon. Be flexible and select the approach that suits the team best.
Get a free copy of the Discovery Checklist, which summarizes all the discovery phases, team structure, key meetings, activities, and resulting artifacts - Free Discovery Checklist!
Conclusion
I hope these tips and the proposed agenda will be helpful to you. Remember, it's not enough to just hand over a ton of documentation to the team and hope they get everything right from the start.
What may be clear to you may not be clear to others. That's why it's crucial for Business Analysts and other project leaders to actively manage knowledge transfer to the delivery team. This will ensure the team is well-prepared for successful delivery of the project.