Conducting Successful Knowledge Transfer
Overview
Depending on who is building the application knowledge transfer is a critical handoff that occurs between you and the partner, or between teams within an organization. It is an activity that should be conducted throughout the build and go-live phases, with more robust sessions after go-live to officially transition the application.
Waiting until the application is ready to go-live, or is already live, will make this process extremely difficult; therefore, we recommend planning early and scheduling time with the proper attendees. However, sometimes proactive scheduling and knowledge transfer are not possible. If that is the case, it is even more imperative to read this article, prepare extensively for any scheduled knowledge transfer, and request the right documentation from the other party.
To ensure you are prepared to handle both scenarios, this document covers a wide range of topics you need to consider, though it is by no means an exhaustive list, as ongoing application management varies from organization to organization and team to team.
To begin, you must determine the future of your application post-go-live and answer the following question:
Are you looking to maintain the application or enhance it?
At some point, all applications fall into maintenance, and you should run through this entire document in either situation, but knowing the answer to this question can help you focus your efforts, especially if you are short on time.
Applications that fall into the "Maintain" bucket have a more straightforward knowledge transfer process, as you can focus mostly on "keeping the lights on" or understanding how to make small changes. Even if you only plan to maintain your application, please still put some thought into enhancements and knowledge transfer recommendations in the “Enhance” section. If your application falls into the "Enhance" bucket, you need to not only understand how to eventually maintain your application by using this guide, but also deeply understand the application architecture to prepare for future enhancements.
Maintain
Applications that fall into the "Maintain" bucket will keep their current or a very similar form for the foreseeable future. The future iterations of this application do not need to be identical, but changes made should be small. For example: updating a dropdown, rearranging fields, updating product prices, or changing data tables. If planned changes start to grow, or additional requirements need to be added in the near future, your team should also use the “Enhance” section to guide knowledge transfer.
To prepare to maintain an application, your primary goals should be understanding how to:
Isolate, investigate, and resolve common troubleshooting scenarios. This can include issues with APIs, user authentication, submissions, and more.
Prepare for and handle Unqork platform releases.
Make simple changes and understand the downstream effects of those changes.
Navigate your environment and identify module dependencies.
Manage and monitor Environment Settings, including secret management for API keys and integration endpoints to ensure connectivity remains stable across promotion cycles.
And more.
While you also need to make an effort to understand the configuration and architecture, it is not always something you will need to invest significant time in depending on your goals. The important thing for you and your team is to think through everything you will need to maintain the application and come prepared with a list of questions. It is also worth requesting step-by-step instructions, user guides, video overviews, and additional documentation from your partner. These resources are helpful for all applications.
Enhance
Applications that fall into the "Enhance" bucket will be measurably added to or changed in the near future. This includes making significant changes, moving the application to "Phase Two" of the build, or addressing initial requirements that were moved out of scope to keep the project on schedule.
To prepare to enhance an application, your primary goals should be understanding:
Why certain configuration choices were made.
Module and application dependencies.
Where your additional requirements or changes will fit into the existing architecture.
How to reuse existing configuration components (e.g., Snippets or Global Templates).
The data schema and integration mapping, ensuring you understand how new features will interact with existing data collections without causing regressions or performance bottlenecks.
Additional Considerations
In both cases, you should ask the partner, or other team, to explain all artifacts they have developed and provide detailed demos and explanations of all requirements and how the application solves your business needs. Hopefully, with extensive discovery, application scoping, project preparation, and the partner’s expertise in building on Unqork, this piece should be straightforward. However, here are some sample topics to discuss just in case:
Security: ensure thought was given to anonymous, authenticated, and Super User permissions, specifically regarding API access.
Role Hierarchies: have these been taken into account at each stage of the application?
Error Handling and Logging: review how the application captures and surfaces errors to the user versus how it logs them internally for administrative review.
Preparing for Your Sessions
To make the most of your knowledge transfer sessions, we recommend coming with a clear agenda and a set of questions to answer for each session. Knowledge transfer sessions are normally between 1 and 2 hours and can easily get derailed without an agenda. Providing the agenda and questions beforehand will also allow the partner, or other team, to prepare and gather relevant modules and details. Even if you do not have time to build a comprehensive agenda, having a clear goal in mind for the session will help you make the most of your time. Here are a few examples:
"Let’s use today to review the backend flow for the first two screens of a new user application. This should include how the anonymous user accesses the APIs, what happens if they already have a partially complete application, the navigation, where data is populating from, and where the forms are found. We should also review any complex logic that went into this portion of the application."
"Today’s session will focus on the APIs. We need to walk through Services Administration, the transformation logic applied to incoming data, and how the application handles external system timeouts or failures."
"We would like to review the Promotion and Deployment checklist. Please demonstrate how to promote this specific application from UAT to Production, including any manual configuration steps required in the Environment Settings or internal database collections."
Documents and Artifacts to Review
We also recommend using this time to review in detail the core artifacts that should have been reviewed and approved throughout the build or go-live phases. These documents are critical to applications that will be maintained or enhanced. Specifically, ensure you have access to and a walkthrough of:
Functional Requirements Document (FRD): To understand the 'what' and 'why' of the business logic.
Technical Design Document (TDD): To understand the 'how,' including data models, API signatures, and module naming conventions.
UAT Test Scripts and Results: To see which edge cases were tested and where known limitations may exist.
The "Handoff Checklist": A living document that tracks the transfer of administrative credentials, third-party licenses, and architectural diagrams.
Additional Handoff Documentation: Any other documents needed to ensure your application stays performant over its lifecycle, including, but not limited to, API documentation and a Data Dictionary.