Delivery Blueprint Overview

Sign in with your Apply Digital Google account to continue.

Access restricted to @applydigital.com and @applydigital.co accounts only.
Discipline overview

Project Management

Where you sit
You're the connective tissue of every engagement. From the moment a project is sold through to the final invoice, your job is to keep delivery on time, on budget, and clear about who owns what. Project Managers (PjM) run individual projects; the PMO sets the standards across all of them.
  • +
    You own the spine of every engagement. The contract document (called the SOW), the team-roles chart (RACI), the project timeline, status reports, and the closing memo are all yours. The PMO additionally owns an internal version of the contract that translates legal language into something the delivery team can onboard against.
  • +
    Your job is to make ownership unambiguous. At kickoff, walk through every key deliverable with the team and confirm one named person is accountable for each, with a date. If no one is named, that's a delivery risk — not a detail to figure out later.
  • +
    You're the early-warning system. You're kept informed across all disciplines, so you'll see missing pieces before discipline leads do. Surface them in your RAIDD log the day you notice — not the week before launch.
  • +
    You share Status Reports and QBRs with the Client Partner. The weekly status update is jointly accountable with the Client Partner; Quarterly Business Reviews are Client Partner-led with you supporting. Align on the message before either goes out.
  • +
    Watch for: scope drift that doesn't make it into a change order, time-tracking burn that doesn't match the timeline, and retrospectives that get skipped under pressure — retros are how the next project gets better, even if they don't help this one.
See all deliverables you own
SOW Internal SOW Account Notion Page Internal & External Kickoff Decks RACI RAIDD Log Account Delivery Updates Timeline Agileday (resourcing & timesheets) Team Morale Survey Status Report Invoices Completion Memo Offboarding Checklist Retro
Discipline overview

BD & Client Partner

Where you sit
You're the commercial relationship — from first conversation to ongoing growth. Business Development (BD) wins the work; the Client Partner owns the relationship through delivery and beyond. Everything the delivery team does downstream starts with what you set up in the first weeks.
  • +
    You own the front half of every engagement. BD is accountable for the NDA, the initial estimate, the proposal, and the handover to the delivery team. The Client Partner takes accountability from the contract (SOW) onward and keeps it through quarterly reviews and invoicing.
  • +
    The BD Handover is your highest-leverage deliverable. Everyone downstream — PMs, discipline leads, the delivery team — depends on it. A weak handover makes every kickoff, RACI, and account page harder for the next six months.
  • +
    Estimates are not just sales documents. The initial estimate feeds team allocation in Agileday and pricing in the SOW. Under-scope here and you've baked margin loss into delivery before the project even starts.
  • +
    Client Partner is the ongoing commercial voice. Status Reports and QBRs are how you protect the relationship and surface growth — they're not PM admin you skim.
  • +
    Watch for: assumptions in the Proposal that didn't make it into the SOW, scope ambiguity that surfaces only at kickoff, and growth opportunities that get spotted in conversation but never written down.
See all deliverables you own
NDA BD Estimate Proposal SOW (Client Partner) BD Handover Status Report (with PjM) QBR Invoices (with PjM)
Discipline overview

Strategy

Where you sit
You frame the work before the work happens. Strategy decides what we're solving, why it matters, and how success will be measured. Everything Product, Design, Tech, and Data build later is in service of the direction you set.
  • +
    You set the goalposts. Strategy is accountable for the early opportunity work, the growth strategy, the service blueprint that connects user experience to backend systems, the value case, the executive summary, and the change management strategy. These artifacts define what "good" looks like for the rest of the project.
  • +
    Your work must feed the next stage, not sit beside it. Your roadmap and outputs should flow directly into the Product Brief and the Technical Strategy Document. If you can't trace the line from your work to what Product, Design, or Tech does next, the chain is broken.
  • +
    You collaborate with everyone on the big-picture artifacts. Opportunity identification, the digital growth strategy, and the service blueprint are joint efforts across Strategy, Product, Design, Tech, and Data. Pull them in early — late input is rework for everyone.
  • +
    The Change Management Strategy is yours alone — don't treat it as optional. It's the bridge between "we built it" and "people actually use it." Without it, adoption becomes the client's problem after we leave.
  • +
    Watch for: polished decks that don't list assumptions, value cases without numbers Data can later validate, and executive summaries that summarise the deck instead of telling the client what to do next.
See all deliverables you own
Opportunity Identification Digital Growth Strategy Strategic Initiative Roadmap Primary Research Findings Ecosystem Map Service Blueprint Value Case Executive Summary Change Management Strategy Change Management Enablement
Discipline overview

Product

Where you sit
You translate strategy into something a team can actually build. Product takes the "why" from Strategy and the "who and what" from Design and Tech, and turns it into a backlog of work with clear priorities, scope, and acceptance criteria.
  • +
    You're accountable for the contract between strategy and build. The Product Brief, the high-level story map, the product roadmap, and the Product Requirements Document are all yours. So is the detailed backlog for each release — the document engineering actually builds against.
  • +
    You sit at the centre of cross-discipline work. You're consulted on more artifacts than any other discipline — across Strategy, Design, Tech, and Build. That's not noise; it's a signal that decisions ripple through you.
  • +
    Don't open a PRD in a vacuum. It depends on Strategy's growth roadmap, Design's wireframes and production design, and Tech's architecture. If those aren't in place yet, escalate before you draft — papering over missing dependencies creates rework you'll own.
  • +
    Backlog quality is delivery quality. The detailed backlog is what Tech and Design build from. Vague stories produce vague software.
  • +
    Watch for: PRDs that lock decisions before Design or Tech have weighed in, roadmaps that don't reflect the actual technical strategy, and analytics requirements that arrive after build (they belong in the PRD, not as a follow-up ticket).
See all deliverables you own
Product Brief High Level User Story Map Measurement Plan (with Data) Product Feature Roadmap Product Requirements Document (PRD) Detailed Backlog for Release
Discipline overview

Design

Where you sit
You shape what the user actually experiences. From early concepts and journey maps through to production-ready screens and component libraries, Design touches every stage of the project. You also own brand and copywriting on Apply engagements.
  • +
    You own more deliverables than any other discipline. From early concepts and user journey maps through to wireframes, production design, the component library, the design system, the UI kit, and user testing. Design touches discovery, definition, and build.
  • +
    Your work has to be consumable by Tech. The component library, design system, and UI kit are the source of truth engineering implements against. If they're incomplete or out of date, the build slows down or drifts off-brand.
  • +
    Engage during drafting, not after sign-off. You're a Consulted role on the PRD, the content model, and others — late input here is the most common collaboration failure in the Blueprint. Get in the room while decisions are still open.
  • +
    Design owns content too. Brand strategy and copywriting are accountable to Design — they're not side artifacts, they're part of the deliverable.
  • +
    Watch for: production designs that diverge from wireframes without an updated rationale, component libraries that don't match what's actually being built, and user testing findings that never make it back into the PRD or backlog.
See all deliverables you own
Conceptual Design Content/Brand Strategy Rebrand/Stylescapes Journey Map Information Architecture Production Design Component Library Wireframes Copywriting User Testing Design Systems UI Kit
Discipline overview

Tech

Where you sit
You build it and make sure it runs. Tech owns the technical strategy, the architecture, the implementation, and what happens after launch — monitoring, support, and operations. Quality is shared with QA; everything else is yours.
  • +
    You own the architecture and the build. The technical strategy, the architecture document, the implementation, the run book (how the system is operated in production), the content model, and User Acceptance Testing are all yours. You share the testing artifacts with QA.
  • +
    Architecture is a written document, not a conversation. The architecture document needs to exist before implementation starts. Test plans, run books, content models, and monitoring all depend on it being real.
  • +
    The Run Book is not a launch-week document. It's drafted alongside implementation. Production-readiness is a discipline, not a final sprint.
  • +
    You're consulted on a lot upstream — from Product Brief through PRD. Engage early so architecture isn't a constraint that surfaces late.
  • +
    Watch for: "we'll document it later" on architecture and run book, content models that don't reflect what Design actually built, and test plans treated as QA's problem alone (you're Responsible on those too).
See all deliverables you own
Technical Strategy Technical Architecture Document Solution Implementation Test Plan (with QA) Solution Tests (with QA) Test Results (with QA) Run Book Content Model UAT
Discipline overview

QA

Where you sit
You're the quality gate before the client sees what we built. QA plans the testing, runs the tests, and produces the evidence that the team is ready for user acceptance testing. The Blueprint formally engages you late — your job is to push earlier than it asks.
  • +
    You're accountable for three artifacts: the test plan, the tests themselves, and the test results. All three depend on a real architecture document and a real PRD — if either is thin, your test coverage will be too.
  • +
    The Blueprint engages you late — push earlier yourself. Formally you're only Consulted on the PRD and the detailed backlog, but waiting for those to be finalised means joining after the decisions that affect testability are locked. Get into architecture and PRD conversations from the start.
  • +
    Your work directly enables UAT. Gaps in your test coverage become gaps the client finds. Test results are your evidence that the team is actually ready for client testing.
  • +
    Work closely with Tech. You share the work on test artifacts with Tech and depend on them for environments, entry/exit criteria, and how defects flow to resolution.
  • +
    Watch for: acceptance criteria in the PRD that aren't actually testable, test plans written after build starts, and UAT scheduled before test results are clean.
See all deliverables you own
Solution Test Plan Solution Tests Solution Test Results
Discipline overview

Data

Where you sit
You make sure we measure what matters — and we measure it from day one. Data sits across discovery (defining what success looks like), build (designing tracking before implementation), and post-launch (dashboards and monitoring). You're a first-class discipline in the Blueprint, not a post-launch add-on.
  • +
    You're embedded in the early work. You're Responsible on opportunity identification, the digital growth strategy, and the service blueprint. You're accountable for the Measurement Plan (how we track success) and the Monitoring & Performance Dashboards after launch.
  • +
    The Measurement Plan belongs before build, not after. Tracking has to be designed during definition, not bolted on after implementation. If no one owns the Measurement Plan at kickoff, raise it.
  • +
    Your work depends on Strategy and Product being specific. Value cases need numbers you can later validate; PRDs need analytics requirements written in, not appended as tickets.
  • +
    You collaborate broadly but engage discipline by discipline. Strategy for KPIs and the value case; Product for analytics in the PRD; Tech for instrumentation in the architecture; Design for what gets measured in user testing.
  • +
    Watch for: projects that "launch then measure" — by then it's too late, and dashboards end up reactive instead of strategic.
See all deliverables you own
Opportunity Identification (joint) Digital Growth Strategy (joint) Service Blueprint (joint) Measurement Plan Monitoring & Performance Dashboards
One thing to remember: the most common Blueprint failure isn't a missing deliverable — it's a Consulted discipline brought in too late. If you see your discipline listed under "C" on something someone else owns, that's an invitation to engage during drafting, not a notification that something is happening.