Skip to content
Debbie
Back to Project Delivery
Portfolio case study

ParentLink

A 30-day SaaS implementation with a data-readiness crisis.

Role
Project Manager / SaaS Implementation Manager
Duration
30 calendar days
Project context
SaaS implementation portfolio scenario

An end-to-end portfolio project developed to demonstrate project-delivery practice across planning, governance, implementation and handover. No real school, trust or parent population is represented.

At a glance

1,949
Production accounts loaded
32/32
UAT cases passed
88.15%
Early activation

Below the 90% target

£68.5k
Final project actual
01

The brief

ParentLink is a 30-day SaaS implementation portfolio scenario for a fictional multi-school trust. The objective was to configure an existing parent-engagement platform, prepare a 2,000-row parent source, train 180 relevant staff, pass critical UAT and transfer the service to BAU by Day 30.

The central delivery problem emerged in Week 1: data profiling found missing mandatory fields in 18% of rows and potential duplicates in 7%. After overlap, 452 unique records needed controlled recovery or disposition while UAT, training and the Day 25 launch remained live dependencies.

02

The starting point

The approved implementation plan assumed full data readiness by Day 9. Profiling made that assumption unsafe. I kept the miss visible, separated production-data readiness from product acceptance and built a recovery route that did not force identity-sensitive matches.

2,000
source rows

Target population

452
unique affected records
18%
rows missing mandatory fields
7%
potential duplicate rate
180
relevant staff
03

What I was responsible for

  • I owned the day-level integrated plan, governance cadence, RAID, budget control and status reporting.
  • I prepared decision papers and kept data, privacy, safeguarding, testing and business acceptance with their accountable owners.
  • I coordinated the recovery plan, maker/checker validation, controlled UAT cohort, training readiness and launch conditions.
  • I ran cutover coordination, hypercare review, residual-action transfer and formal closure.
  • Implementation planning
  • Data readiness
  • UAT
  • Training
  • Go-live
  • Hypercare
04

How I structured the project

  1. Days 1–5

    Mobilise and discover

    Baseline scope, requirements, roles and profile the 2,000-row source.

    Stage 1 of 6

  2. Days 5–13

    Recover and configure

    Control the 452-record recovery while preparing configuration and UAT entry.

    Stage 2 of 6

  3. Days 14–19

    UAT

    Run two cycles, retest defects and reach 32/32 without calling production data ready.

    Stage 3 of 6

  4. Days 20–23

    Decide

    Resolve 443 dispositions, establish nine fallbacks and secure Conditional Go.

    Stage 4 of 6

  5. Days 24–25

    Load and launch

    Reconcile the production load, validate six controls and release communications.

    Stage 5 of 6

  6. Days 25–30

    Hypercare and handover

    Support users, re-integrate six exclusions and transfer five BAU actions.

    Stage 6 of 6
05

The hard part

Data readiness missed two forecasts, but the issue did not disappear.

Full readiness missed Day 11 and Day 19. I protected valid product testing with a controlled 240-record cohort, but I did not let that cohort stand in for production readiness. The data issue stayed Red until every affected record had an accepted route.

By Day 21, 443 dispositions were accepted and nine identity-sensitive records remained unsafe to load. I kept the launch conditional, established verified fallback and retained Data Protection and Safeguarding authority over re-entry.

06

Key decisions

Decision 01

Fund a bounded recovery route

Context
The Week 1 profile identified 452 affected records and removed schedule float.
Options
Move the launch, lower the control standard, or authorise targeted recovery with explicit limits.
Decision
I proposed a £1,400 recovery ceiling, maker/checker review, quarantine and risk-based sampling.
Why
The project needed extra capacity without turning contingency into an open-ended spend route.
Consequence
Actual recovery spend closed at £1,365, leaving £35 of the authority unused.

Decision 02

Use a controlled cohort for UAT

Context
Production data was not ready, but a valid test pack could be assembled and reconciled.
Options
Delay all testing, use unsafe production data, or separate product acceptance from production readiness.
Decision
I recommended a controlled 240-record cohort for the scenarios it could validly support.
Why
It protected the test window without making a false readiness claim.
Consequence
UAT began on Day 14 and finished 32/32 on Day 19; the production-data gate remained separate and unresolved.

Decision 03

Exclude nine unsafe records at launch

Context
Nine identity-sensitive records still lacked sufficient evidence by Day 21.
Options
Force a match, delay all users, or exclude the nine with safe fallback and re-entry controls.
Decision
I recommended controlled exclusion and a Conditional Go.
Why
A fixed date did not justify unsafe linkage, and the service could support verified case-led fallback.
Consequence
All nine were excluded at load; six were safely re-integrated by Day 28 and three transferred to BAU.

Decision 04

Retry only after proving no partial commit

Context
A batch timeout interrupted the Day 24 production load.
Options
Retry immediately, abort, or pause and inspect idempotency evidence.
Decision
I paused for eight minutes and authorised one controlled retry after the evidence showed no partial commit.
Why
A retry without that check could have duplicated or corrupted the load.
Consequence
The final disposition reconciled exactly with no abort trigger.
07

Project control

  • The baseline stayed visible: Day 9 data readiness was achieved with conditions on Day 21, while the Day 25 launch remained unchanged.
  • The £68,500 final actual matched the baseline. Recovery spend moved £1,365 from contingency into data preparation; £3,135 contingency remained unused.
  • RAID retained the occurred data-readiness risk and converted it into an active issue rather than rewriting history after recovery.
  • Six timed launch conditions controlled fallback, reconciliation, access, validation, communications and support before release.
08

Testing and assurance

Assurance used reconciled cohorts, 36 historical UAT attempts across 32 unique cases, defect retest and regression, privacy/safeguarding checks, training evidence, a negative-load rehearsal and timed launch controls.

  • UAT final position: 32/32 unique cases passed with zero open UAT defect.
  • Training reached 172/180 at the launch gate and 178/180 by Day 30.
  • Day 24: 1,949 loaded + 42 duplicate-surplus rows consolidated + nine excluded = 2,000 source rows.
  • Hypercare: 41 tickets, no Severity 1/2 incident and 100% service availability in the five-day window.
09

A conditional launch, closed one control at a time

The Sponsor approved Conditional Go on Day 23. The Day 24 load balanced exactly, and production enabled at 09:00 on Day 25 only after the timed conditions passed. Validation finished at 11:18; communications released at 11:30.

I kept the nine exclusions out of the recipient list and in named fallback. Six later passed controlled re-entry. The remaining three did not become invisible simply because the project closed; they transferred into BAU with owners and evidence routes.

10

What happened

Simulated Day 24 actual · nine exclusions

1,949 accounts

Production load

Simulated closure actual · six re-integrations

1,955

Day 30 live accounts

Simulated final result

32/32

Final UAT

Simulated Day 30 actual

178/180 · 98.89%

Training

Early indicator · below 90% target

1,718/1,949 · 88.15%

Activation

Five-day early indicator · not sustained seven-day use

1,294/1,718 · 75.32%

Active usage

11 · Evidence gallery

These are readable web-native representations of the source artefacts—not fake software screenshots. Open any item for a larger view and its source reference.

12

What I learned

Early profiling, staged decisions and segregated assurance prevented a fixed date from driving unsafe account linkage.

A controlled test cohort can protect progress, but it must never be allowed to impersonate production readiness. Residual records and missed targets still need owners after the launch story ends.

Previous case CRM MigrationBack to DeliveryNext casePerah Studio Delivery System