Partner Co-Build Delivery Playbook

This guide is for organizations engaging a System Integrator (SI) partner for an Unqork co-build. Its purpose is twofold: Knowledge Transfer (ensuring your team learns the partner's methods) and Delivery Oversight (guaranteeing the partner builds a performant, scalable application that meets your requirements).

I. Team Structure for Partner Co-Builds

A successful co-build requires mirroring the Partner's team structure to facilitate learning and oversight. Co-builds are a great way to expedite learning and understand Unqork delivery at a deeper level. Your core technical resources—the Business Lead (Project Manager) and the Technical Lead (Solution Architect)—are the linchpins of this delivery model.

Role	Responsibility
Business Lead or Project Manager	Manage the Knowledge Transfer Plan. This person must ensure the weekly goals align with your team's conceptual learning objectives and the overall project schedule.
Technical Lead or Solution Architect	Own the Architecture. Must review, validate, and sign-off on all technical designs, NFRs, and governance decisions. Must review and approve the RBAC structure, security architecture, and integration authentication methods.
Application Engineers	Own Configuration Quality. Actively co-build modules. Start with low complexity requirements and gradually increase in complexity over time. Must participate in all peer-reviews and begin to document best practices.
Business Analysts	Own Requirements and UAT. Must finalize all user stories, facilitate scoping using the Checklists, and manage the UAT process.
QA Analyst	Own Test Strategy. Must define and execute the UAT plan, focusing on learning the partner's automated testing structure. Additional focus should be put on edge case testing to ensure partner build meets all requirements.

II. Oversight & Meeting Cadence

The following cadence ensures active involvement, demanding rigor and accountability from your SI Partner. It is critical that your team is intimately involved in all meetings to catch issues early and keep the project on track. It is also essential that all team members are enabled and certified through Unqork Academy. This expedited the build process and ensures there is an “even playing field” when discussing choices made by the SI.

Meeting	Cadence	Attendees	Purpose
Stand-up	Daily	Business Lead, Technical Lead, Application Engineers	Daily Planning. Remove blockers and discuss work to be done for the day.
Sprint Planning	Weekly	Application Engineers	Work Allocation. Discuss tickets, prioritize requirements, and make sure work is distributed appropriately.
Co-Build Sync	Weekly	Business Lead, Technical Lead, Business Analyst	Knowledge Transfer. Review configuration progress, discuss technical challenges, and agree on who builds what next.
Architecture Review	Bi-Weekly	Business Lead, Technical Lead, Solution Architect, Lead Application Engineer	Mandatory Sign-off. Review the Partner's evolving technical design, data model, and reusable components. (Focus: Scalability, Performance, Governance)
Bi-Weekly Sprint Demo	Bi-Weekly	Technical Lead, Application Engineers	Validate Functionality. Formally accept or reject features based on finalized user stories. Ensure the work delivered aligns with the scope.
Executive Steering	Monthly	Sponsor, Business Lead, Technical Lead	Review Metrics & Risk. Present ROI status, highlight major risks, and obtain high-level approvals.

III. Responsibility by Delivery Phase

As you begin to deliver this application, you must consistently revisit your primary goals. You are not only building an application, but building resilience. Your primary role must evolve from oversight to active co-ownership to achieve independence by the end of the engagement.

Phase 1: Discovery & Requirements Gathering

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
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	Technical oversight of NFRs and architecture design.	"How will the proposed integration architecture prevent failure during peak usage?” "How long will the API retry before timeout? How did you set this up?”
Requirements translation	Finalizing user stories, scope, and planning co-build responsibilities.	"What is your process for breaking down high-level features into user stories, and how do you ensure the story is appropriately assigned?" “How do you determine the complexity of requirements?
Security and RBAC	Auditing PII encryption and RBAC design for compliance.	"How will you handle PII data encryption?” “How will our RBAC hierarchy be set up?”
Configuration	Learning optimization patterns and configuration standards.	"Why did you make the decision to set the API module up like this?” “Can you explain your thought process for this Data Workflow?”

Phase 2: Build, Co-Build, & Maturation

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.
Own an increasingly complex set of requirements over time.
Ask questions, think through edge cases, demand transparency.

Domain	Core Action	Sample Questions
Architecture	Conducting monthly application assessments and reviewing advanced architectural patterns.	"Can you advise us on the best strategy for API security?" "How are you planning to handle load times for this module?"
Configuration Management	Performing configuration reviews (peer review) and guiding team on complex configurations.	"How did you modularize this application to ensure peak performance?" “What are the exact steps and checks for using the Release Management Tool to move from QA to Staging?"
Configuration	Co-building Low-Medium Complexity requirements.	"During our peer review, why did you use a DWF instead of a simple calculation field here? What are the performance implications?"
Testing	Defining and executing UAT for all features and tracking project QA metrics.	“How are you testing for edge cases?”

Phase 3: Go-Live

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
Configuration	Lead the final promotion into Production, observing all platform security/governance gates.	"What do we do if the promotion fails?” “What steps do we take to roll back a release and how can we verify a previous version is restored?”
Application Maintenance	Operational readiness validation and monitoring setup.	"Can you provide an overview of all alerts you set up?” “How can we use service logs to isolate issues?”
Testing	Final performance and load validation.	"Can you provide the post release test plan including testing during peak load times?"
Architecture & Security	Final security and architecture gate review.	"Can you confirm that our data retention and purge requirements are working in production?"

IV. Client-Owned Governance Artifacts Review

To ensure your application is built to a high degree of quality, meets requirements, and is easily maintainable by your team moving forward, it is essential to receive the following documents and review their completeness before closing out the project. 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:

Does the architecture documentation detail all modules and APIs? Does it define user roles?
Does the architecture documentation define performance NFRs (API response times)?
Have you followed our security plan for PII data?
Does the RBAC structure scale for future user groups?
Does the documentation include steps for manually forcing a workflow state change if an error occurs?
Does it explain the "why" behind the most complex DWF logic?
Is reusable configuration documented with its purpose?

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