Partner-Led Delivery Playbook

This guide is for organizations engaging a System Integrator (SI) partner for their first Unqork application build where the partner leads the development. Its purpose is to allow you to establish a strong foundational understanding of the Unqork platform while ensuring strict Delivery Oversight. This playbook ensures that even without building personally, your team gains the necessary knowledge to guarantee the partner builds a performant, scalable application that your organization can eventually maintain or expand upon.

I. Team Structure for Partner-Led Builds

In a partner-led model, your team’s role shifts from "active builder" to "informed evaluator." You are mirroring the Partner's team structure to maximize observation and oversight. This structure allows you to learn the "how" and "why" behind Unqork delivery with a lower time and resource commitment before transitioning to a co-build or DIY (do it yourself) model in the future.

Role	Responsibility
Business Lead or Project Manager	Manage the Learning Plan. Ensure the partner is effectively explaining their process. This person guarantees that the project meets business goals while the internal team absorbs platform fundamentals.
Technical Lead or Solution Architect	Review and Validate. You must understand the "why" behind the partner's architecture choices. You are responsible for reviewing and signing off on all technical designs, security architecture, and integration methods to ensure they meet your organization's standards.
Application Engineers	Shadow and Learn. While not building yet, these individuals must shadow the partner’s configuration sessions. Focus on understanding decisions made, reusability, scalability, and best practices for future maintenance.
Business Analysts	Own Requirements and Logic. Ensure user stories are translated correctly into the platform. Focus on how the partner maps business processes to Unqork workflows.
QA Analyst	Own Validation. Define the UAT plan. Focus on learning how the partner structures tests in Unqork and identifying how to validate that the build meets all original requirements. Additional focus should be put on edge case testing to ensure partner build meets all requirements.

II. Oversight & Meeting Cadence

This cadence ensures your team is not a passive bystander. Rigor and accountability from your SI Partner are required to catch issues early and build your team's platform literacy. All team members should simultaneously pursue Unqork Academy certifications to better understand the partner's technical language.

Meeting	Cadence	Attendees	Purpose
Stand-up	Daily	Business Lead, Technical Lead, Observers	Observational Planning. Listen to progress and identify any blockers the partner is facing to understand the development lifecycle.
Sprint Planning	Weekly	Application Engineers, Business Analyst	Requirement Breakdown. Learn how the partner translates requirements into specific Unqork tasks and tickets.
Knowledge Transfer Sync	Weekly	All Team Members	Platform Fundamentals. A dedicated session where the partner explains a specific component or logic they built that week and why they chose that approach.
Architecture Review	Bi-Weekly	Technical Lead, Solution Architect	Technical Sign-off. Review the evolving design. Focus on scalability and how the application interacts with your existing tech stack.
Bi-Weekly Sprint Demo	Bi-Weekly	Technical Lead, Business Analyst	Feature Validation. Formally accept or reject features. Ensure the delivered work aligns with the original vision and is "user-friendly".
Executive Steering	Monthly	Sponsor, Business Lead, Technical Lead	Risk & Strategic Alignment. High-level review of ROI, timeline risks, and partner performance.

III. Responsibility by Delivery Phase

Your primary role is to evolve from a platform novice to an informed owner, ensuring the application is built to a standard you can support long-term.

Phase 1: Discovery & Foundation Setting

Your primary goals during this phase are to:

Learn the partner’s scoping methodology and technical documentation standards and make sure they align with your own/Unqork’s recommendations
Understand how requirements become technical reality and ensure all foundational artifacts are created.
Gather artifacts that should be authored by the Partner but formally owned and signed-off by you.
Oversee the partners work and question decisions to use as a learning opportunity

Domain	Core Action	Sample Questions
Architecture	Developing and reviewing artifacts.	"Can you explain how you are going to handle high traffic during peak hours?" "What happens to the data if an external system we integrate with goes down?"
Requirements	Translating business needs to configuration.	"How does this user story translate into a workflow in Unqork?" "Why is this requirement considered 'low/medium/high complexity'?"
Security and RBAC	Understanding data protection.	"How is our data secured within this submission?” "Can you show us the proposed Role-Based Access Control (RBAC) mapping for different user types?"
Configuration	Learning optimization patterns and configuration standards.	“How did you plan configuration for this module?” “How do you determine work breakdown between team members” ”What does your configuration oversight and review process look like?”

Phase 2: Partner-Led Build & Shadowing

Your primary goals during this phase are to:

Learn how the partner approaches configuration decisions, documenting best practices along the way.
Make sure requirements are being built to your standards.
Watch the build process closely, ask "why" constantly, and ensure the configuration remains clean and modular.
Ask questions, think through edge cases, demand transparency.

Domain	Core Action	Sample Questions
Configuration	Shadowing configuration sessions.	"Why did you use a Plug-in here instead of a Data Workflow?" "How does this module stay reusable if we want to build a second application later?"
Design Review	Monthly application assessments.	"Show us how the error handling is configured for this API. What does the end-user see when a service fails?"
UDLC Process	Understanding the promotion lifecycle.	"What is the process for moving this from the development environment to QA? What automated checks are run?"
Testing	Observing QA and preparing for UAT.	"How are you documenting edge cases?" "Can we review the current defect tracker and your process to triage?”

Phase 3: Go-Live & Operational Handoff

Your primary goals during this phase are to:

Ensure 100% operational readiness for Production Support teams.
Validate that all Non-Functional Requirements (NFRs) are met under production-like conditions.
Formalize the hand-off of all technical and security documentation.

Domain	Core Action	Sample Questions
Maintenance	Validating the Runbook.	"If a user reports a bug on Monday after go-live, what are the first three places our support team should check in Unqork? Can you write step-by-step instructions for our team?"
Monitoring	Setup and understand alerts.	"Show us the dashboard where we can see real-time application health and API success rates."
Final Sign-off	Walk through every item in the "Client-Owned Governance Artifacts"	“Can you demonstrate how this requirement, including edge cases, is met?”

IV. Client-Owned Governance Artifacts Review

In a partner-led build, these documents are essential. They represent the "knowledge" a partner is handing off to you. You must review them for clarity so a person who didn't build the app (your team) can understand them. Many of these documents need to be initially generated by you and delivered to the partner, but a formal sign off from the partner is needed for each to ensure what you have provided is feasible and within the scope of phase 1 of the application.

Before signing off on these documents, please make sure you are confident in the depth and completeness of each. Asking clarifying questions before acceptance should be the norm. Here are a few sample questions to ask yourself to ensure you are prepared to take over the application:

Is the language in this document too technical, or can our Business Lead understand it?
If the partner team left tomorrow, could we use this Runbook to fix a minor issue?
Does the Data Dictionary clearly define what every field does?
Are the API response times documented so we know what "normal" performance looks like?

Received?	Artifact	Purpose or Description	Phase
	Project Plan	Detailed schedule including tasks, resource assignments, and overall timeline management.	Kickoff
	Stakeholder Interview Questions	The guide used by the Partner to capture key perspectives and alignment from leadership and process owners.	Kickoff
	Non-Functional Requirements	Defines technical criteria for system operation, including performance, security, and compliance requirements (NFRs).	Kickoff
	User Persona	Defines the goals, needs, and pain points of the different end-user types (e.g., Submitter, Approver).	Kickoff
	Environment Setup Tracker	Tracks the status, access keys, and configuration details of all development and testing environments.	Kickoff
	Functional Requirements	Defines what the application must do, detailing specific application behavior and features.	Discovery and Requirements Gathering
	Business Process Architecture	Documents a high-level view of the entire application flow end-to-end, including roles and integration points.	Discovery and Requirements Gathering
	Solutions Architecture (System Context)	High-level technical overview of the application's place in the broader system landscape and core technical strategy.	Discovery and Requirements Gathering
	API Specification	Details all external API calls, including resilience strategy, authentication scheme, and request/response schemas.	Discovery and Requirements Gathering
	Integrations Summary Deck	High-level summary of all systems to be integrated, including status and data flow.	Discovery and Requirements Gathering
	Data Model	Illustrates how data entities (people, objects, concepts) relate to each other, often including schemas and an Entity Relationship Diagram (ERD).	Discovery and Requirements Gathering
	Data Dictionary	Collects descriptions of all data objects, fields, and items used in the data model.	Discovery and Requirements Gathering
	Data Architecture Components	Documents data sources, acquisition, transformation, storage, retention, and exit strategy.	Discovery and Requirements Gathering
	RBAC Diagram	Documents the application's roles, groups, and the approach to restricting module and submission access.	Discovery and Requirements Gathering
	QA Test Strategy	Defines the methodology, tools, and overall approach for quality assurance and testing efforts.	Discovery and Requirements Gathering
	Test Scenario and Test Case	Detailed list of scenarios and specific steps for formal testing and validation.	Discovery and Requirements Gathering
	Artifact Process Flow (UI Example)	Documents the application flow and provides visual user interface examples (wireframes/mockups).	Discovery and Requirements Gathering
	Release Roadmap	High-level plan showing architecture, configuration, and final release milestones.	Go Live and Handoff
	Runbook / Production Readiness Guide	Step-by-step guide for monitoring, troubleshooting, and resolving common incidents after go-live (L1/L2 support).	Go Live and Handoff
	Configuration Documentation	Explains complex module configurations, custom settings, and rationale for using specific components for future maintenance.	Go Live and Handoff
	NFR Validation Report	Formal report proving the application meets all agreed-upon Non-Functional Requirements (e.g., latency, peak load, security checks).	Go Live and Handoff