GXD Progress.

Keep the work connected
from requirement to acceptance.

Complex delivery involves different disciplines, decisions and dependencies. GXD Progress is our AI-supported delivery system for keeping that work connected: what was requested, how it was developed and the evidence used to check it.

01 / THE DELIVERY MODEL

01 / THE DELIVERY MODEL

The handovers matter as much as the individual tasks.

The handovers matter as much as the individual tasks.

The handovers matter as much as the individual tasks.

Research needs to inform requirements. Design needs to reflect those requirements. Implementation and testing need to refer back to what was agreed. GXD Progress structures those handovers, with review and a route back when work needs correcting.

ILLUSTRATIVE DELIVERY MODEL

PROGRAMME MANAGEMENTCoordinates delivery end to end.SECURITY & COMPLIANCEReviews risk and controls throughout.BUSINESS REQUIREMENTDomainExpertBusinesscontextBusinessAnalystRequirementsand criteriaConsultantPlatform fitEnterpriseArchitectSystemboundariesUX/UIUser journeysSalesforceArchitectSolution designBuilderImplementationTesterAcceptanceevidenceRevise and retestDEFINED OUTCOMEValidated against agreed criteria
PROGRAMME MANAGEMENTCoordinates delivery end to end.
BUSINESS REQUIREMENTThe opportunity or problem
Domain ExpertBusiness context
Business AnalystRequirements and criteria
ConsultantPlatform fit
Enterprise ArchitectSystem boundaries
UX/UIUser journeys
Salesforce ArchitectSolution design
BuilderImplementation
TesterAcceptance evidence
Tester → BuilderRevise and retest when validation identifies rework.
DEFINED OUTCOMEValidated against agreed criteria
SECURITY & COMPLIANCEReviews risk and controls throughout.

The roles represent specialist capabilities, not employee numbers. Our AI instruments support the process. People direct the work, review decisions and remain accountable for delivery.

SPECIALIST CAPABILITY

RESPONSIBILITY

OUTPUT

DOMAIN EXPERT

DOMAIN EXPERT

Understand the organisation, its industry and the context of the requirement.

Understand the organisation, its industry and the context of the requirement.

A source-backed context brief, terminology, relevant constraints and open questions.

A source-backed context brief, terminology, relevant constraints and open questions.

Verified information is distinguished from assumptions. Public research does not establish the client’s internal processes or final compliance requirements.

Verified information is distinguished from assumptions. Public research does not establish the client’s internal processes or final compliance requirements.

BUSINESS ANALYST

BUSINESS ANALYST

Turn the business request into clear requirements.

Turn the business request into clear requirements.

Process requirements, business rules, acceptance criteria and unresolved questions.

Process requirements, business rules, acceptance criteria and unresolved questions.

CONSULTANT

CONSULTANT

Assess the requirement against available Salesforce capabilities.

Assess the requirement against available Salesforce capabilities.

A functional approach, standard-capability assessment and options requiring a decision.

A functional approach, standard-capability assessment and options requiring a decision.

ENTERPRISE ARCHITECT

ENTERPRISE ARCHITECT

Check how the change fits the wider technology landscape.

Check how the change fits the wider technology landscape.

System boundaries, data ownership, integration dependencies and enterprise-level decisions.

System boundaries, data ownership, integration dependencies and enterprise-level decisions.

UX/UI

UX/UI

Examine how people will use the proposed solution.

Examine how people will use the proposed solution.

User journeys, interaction requirements and usability considerations.

User journeys, interaction requirements and usability considerations.

SALESFORCE ARCHITECT

SALESFORCE ARCHITECT

Translate the agreed requirements into a coherent Salesforce design.

Translate the agreed requirements into a coherent Salesforce design.

Data, access, automation and integration design, with recorded technical decisions.

Data, access, automation and integration design, with recorded technical decisions.

BUILDER

BUILDER

Implement against the approved design.

Implement against the approved design.

Implementation changes and the information needed to review and release them.

Implementation changes and the information needed to review and release them.

Production deployment requires the appropriate review and approval.

TESTER

TESTER

Check the implementation against the original requirement and acceptance criteria.

Check the implementation against the original requirement and acceptance criteria.

Test cases, recorded execution results where available, defects and outstanding validation.

Test cases, recorded execution results where available, defects and outstanding validation.

Planned checks and recorded execution results remain distinct.

02 / FOLLOW ONE REQUIREMENT

02 / FOLLOW ONE REQUIREMENT

Follow one requirement through the decisions it creates.

Follow one requirement through the decisions it creates.

Follow one requirement through the decisions it creates.

WORKED EXAMPLE

An illustration of the method, not a completed client engagement.

“Assign new enquiries to the appropriate admissions team and make routing exceptions visible.”

“Assign new enquiries to the appropriate admissions team and make routing exceptions visible.”

“Assign new enquiries to the appropriate admissions team and make routing exceptions visible.”

A / REQUIREMENT

A / REQUIREMENT

Starting point for design

Starting point for design

BUSINESS RULE

BUSINESS RULE

Use the enquiry’s selected school to determine the responsible admissions team.

Use the enquiry’s selected school to determine the responsible admissions team.

ACCEPTANCE CRITERION

ACCEPTANCE CRITERION

If no valid routing match exists, record an exception rather than silently assigning an unrelated team.

If no valid routing match exists, record an exception rather than silently assigning an unrelated team.

OPEN QUESTION

OPEN QUESTION

Who owns the exception queue?

Who owns the exception queue?

B / DESIGN REVIEW

B / DESIGN REVIEW

Decision open · not approved

Decision open · not approved

REVIEW CONSIDERATIONS

REVIEW CONSIDERATIONS

Where the school-to-team mapping is maintained.
Who can change that mapping.
What happens when a team is inactive.
How exceptions are recorded and reviewed.

Where the school-to-team mapping is maintained.
Who can change that mapping.
What happens when a team is inactive.
How exceptions are recorded and reviewed.

UNRESOLVED DECISION

UNRESOLVED DECISION

Exception queue ownership remains open.

Exception queue ownership remains open.

C / REVIEW AND REWORK

C / REVIEW AND REWORK

Return to design review

Return to design review

ILLUSTRATIVE FINDING

ILLUSTRATIVE FINDING

“The proposed default assignment conflicts with the agreed exception rule.”

“The proposed default assignment conflicts with the agreed exception rule.”

REQUIRED RESPONSE

REQUIRED RESPONSE

Revise the design before implementation proceeds.

Revise the design before implementation proceeds.

D / VALIDATION

D / VALIDATION

Planned. Not executed.

Planned. Not executed.

PLANNED CHECKS

PLANNED CHECKS

A valid routing match.
A missing routing match.
An inactive destination team.
A duplicate submission.
An unauthorised attempt to change routing.
Multiple enquiries processed together.

A valid routing match.
A missing routing match.
An inactive destination team.
A duplicate submission.
An unauthorised attempt to change routing.
Multiple enquiries processed together.

03 / OVERSIGHT THROUGHOUT DELIVERY

03 / OVERSIGHT THROUGHOUT DELIVERY

THE WORK MOVES.
THE CONTROLS STAY WITH IT.

THE WORK MOVES.
THE CONTROLS STAY WITH IT.

THE WORK MOVES.
THE CONTROLS STAY WITH IT.

PROGRAMME MANAGEMENT

PROGRAMME MANAGEMENT

Programme Management follows the work across stages, dependencies and decisions. Daily reporting should reflect recorded progress and unresolved issues, not an optimistic summary.

Programme Management follows the work across stages, dependencies and decisions. Daily reporting should reflect recorded progress and unresolved issues, not an optimistic summary.

REPORT CATEGORIES

REPORT CATEGORIES

What moved.
What is blocked.
Which decisions are needed.
What failed review.
What happens next.

What moved.
What is blocked.
Which decisions are needed.
What failed review.
What happens next.

SECURITY & COMPLIANCE

SECURITY & COMPLIANCE

Security & Compliance reviews requirements, designs and changes against applicable client controls. Findings remain attached to the work until they are resolved or an exception is approved.

Security & Compliance reviews requirements, designs and changes against applicable client controls. Findings remain attached to the work until they are resolved or an exception is approved.

AREAS CONSIDERED

AREAS CONSIDERED

Access.
Data handling.
Privacy.
Client standards.
Required approvals.
Recorded exceptions.

Access.
Data handling.
Privacy.
Client standards.
Required approvals.
Recorded exceptions.

04 / THE DELIVERY RECORD

04 / THE DELIVERY RECORD

Leave a record
the next person can use.

Leave a record
the next person can use.

Leave a record
the next person can use.

Requirements, design decisions, implementation changes and validation evidence remain connected, including unresolved questions and accepted exceptions. That record helps explain both what changed and why.

REQUIREMENTS

REQUIREMENTS

Original request, business rules and agreed acceptance criteria.

Original request, business rules and agreed acceptance criteria.

DESIGN

DESIGN

Reviewed approach, dependencies and decision records.

Reviewed approach, dependencies and decision records.

IMPLEMENTATION

IMPLEMENTATION

Changes made, their relationship to the design and any outstanding exceptions.

Changes made, their relationship to the design and any outstanding exceptions.

VALIDATION

VALIDATION

Tests performed, actual results, defects and remaining acceptance work.

Tests performed, actual results, defects and remaining acceptance work.

05 / CONTINUITY INTO GXD GUARDIAN

05 / CONTINUITY INTO GXD GUARDIAN

KEEP THE KNOWLEDGE USEFUL.

KEEP THE KNOWLEDGE USEFUL.

KEEP THE KNOWLEDGE USEFUL.

Requirements, decisions and validation records remain useful after delivery. They supply context to Librarian, the knowledge core within GXD Guardian, for subsequent review and change.

Capabilities and delivery arrangements are agreed for each engagement.

Before committing to delivery, establish which Salesforce changes matter and why. GXD Assess offers an optional starting point: evidence-backed priorities and an improvement roadmap to inform the outcomes you choose to pursue.

Need continuing Salesforce guidance? GXD Advance supports businesses; GXD Impact is shaped around a charity’s mission, budget and capacity. Implementation requires a separate agreement on outcomes, work and price.

06 / LET’S TALK

06 / LET’S TALK

See how the approach supports agreed corrections.

See how the approach supports agreed corrections.

See how the approach supports agreed corrections.

CLARITY. OWNERSHIP. ACCOUNTABILITY.