Approach

A pragmatic, evidence-based approach

Enough structure to make sound decisions. Enough agility to create value early.

Complex transformations need a sound foundation, but they should not disappear into months of analysis before anything is learned. My preferred approach combines focused discovery, rapid prototyping of solution alternatives, high-level solution design and targeted proof with iterative delivery and consolidated end-to-end assurance.

It is a preferred starting point, not a methodology imposed on the client. I adapt it to the organisation’s governance, culture, delivery model, project leadership and existing partner landscape.

This approach runs across all five expertise areas, and you can see where it has been applied in selected experience.

Inspired by selected Microsoft Success by Design principles and refined through more than two decades of international Dynamics delivery experience. It is an independently evolved approach, not an official Microsoft methodology.

The differentiating idea

Evidence on both sides of the high-level design

I don’t only validate a completed design. I also use rapid prototypes to help discover the right design in the first place.

Before the HLD · explore and shape

Prototype the alternatives

Translate business strategy and requirements into several solution alternatives. Use rapid, AI-assisted prototypes and stakeholder playbacks to make those alternatives tangible. Score them against business fit, functional fit, technical feasibility, time-to-value, risk, cost and operating model. The evidence becomes direct input to the HLD.

After the HLD · prove and de-risk

Prove the critical components

Use focused PoCs and technical spikes for the solution components that carry material performance, security, integration, data, product-capability or delivery risk. The evidence confirms constraints, changes the design where needed and supports explicit go/no-go decisions.

Exploratory prototypes are not production code. They remain subject to normal engineering, security and quality standards before implementation.

The shape of it

Four macro bands, nine stages, one continuous governance layer

Select a stage to read what it involves. Everything shown here is also written out in full below — nothing depends on hovering.

Initiation Once per project · non-iterative

Project definition Mainly non-iterative · evidence can loop

Project delivery Iterative build · consolidated assurance

Project support Per release · continuous

01 Initiate Create a shared frame before architecture work fragments across domains. 02 Discover & frame Build enough shared understanding to design responsibly while creating momentum quickly. 03 Model & prototype solution alternatives Make alternative ways of meeting the requirements tangible before the programme commits to one design. ↑ Evidence into the HLD 04 Shape the high-level solution design Turn the preferred direction and early evidence into a coherent architecture that sets boundaries without pretending every detail is known. 05 Scope & phase Translate the HLD into a realistic delivery shape that recognises dependencies, value, risk and team capacity. 06 Deliver iteratively Refine detailed analysis, design and development inside clear architectural guardrails while learning from working increments. 07 Prove critical components Prevent high-impact assumptions from surviving into production merely because the HLD looked convincing. ↑ Evidence back into design 08 Consolidate, test & harden Prove that increments work together as one operational solution, not only as locally successful components. 09 Cut over, stabilise & operate Move into production responsibly and use operational evidence to guide support and future improvement.

Continuous Governance · decision records · risk & dependencies · stakeholder alignment · security, performance & data · architecture assurance

The approach runs across four macro bands. Initiation (stage 1) is non-iterative and happens once. Project definition (stages 2–5) is mainly non-iterative, but evidence from prototyping loops back into discovery and design. Project delivery (stages 6–8) is iterative for build, with consolidated assurance cycles per release; proof of critical components loops back into the design. Project support (stage 9) runs per release and continuously. A governance layer runs beneath every stage.

Initiate

Once per project — non-iterative foundation

Create a shared frame before architecture work fragments across domains.

Typical activities

Define the problem, desired outcomes and success measures
Connect the company strategy to the transformation context
Confirm initial business requirements, constraints and decision rights
Establish the budget envelope, timing assumptions and governance
Confirm high-level scope, current partners and team responsibilities
Prepare the initial environment and information required for discovery

Typical outputs

Problem statement
Success measures
Governance and decision model
Initial scope and risk map

Discover & frame

Focused discovery — not an open-ended analysis phase

Build enough shared understanding to design responsibly while creating momentum quickly.

Typical activities

Understand business outcomes, journeys and priority capabilities
Review the existing application, integration and data landscape
Identify constraints, dependencies, assumptions and stakeholder interests
Review existing blueprints, partner proposals and architectural decisions
Identify the decisions that need early evidence

Typical outputs

Guiding principles
Priority decisions
Constraints and dependencies
Discovery backlog

Model & prototype solution alternatives

Evidence before the HLD

Make alternative ways of meeting the requirements tangible before the programme commits to one design.

Typical activities

Define a small number of credible solution alternatives
Use rapid, AI-assisted prototypes to demonstrate key journeys or interactions
Play alternatives back to business, functional and technical stakeholders
Capture new requirements and operating implications revealed by the prototype
Score alternatives against strategy, business/functional fit, feasibility, time-to-value, risk, TCO and operating model

Typical outputs

Prototype alternatives
Stakeholder playback findings
Weighted scorecard
Recommended design direction

Shape the high-level solution design

One coherent direction

Turn the preferred direction and early evidence into a coherent architecture that sets boundaries without pretending every detail is known.

Typical activities

Define application responsibilities and system boundaries
Describe the end-to-end business and solution flow
Set integration, data, security and operational principles
Make key alternatives and trade-offs explicit
Capture architecture decision records and transition considerations

Typical outputs

High-level solution design
Architecture principles
System responsibility model
Decision records

Scope & phase

Prepare controlled delivery

Translate the HLD into a realistic delivery shape that recognises dependencies, value, risk and team capacity.

Typical activities

Confirm in-scope and out-of-scope capabilities
Define releases, increments and transition states
Set up the delivery team, responsibilities and specialist capacity
Plan the first sprint/release backlog and architecture runway
Confirm budget allocation and major milestones

Typical outputs

Phased roadmap
Release scope
Team model
Initial delivery and assurance plan

Deliver iteratively

Once per iteration within a release

Refine detailed analysis, design and development inside clear architectural guardrails while learning from working increments.

Typical activities

Refine detailed requirements and acceptance criteria
Complete functional and technical design for the iteration
Develop with appropriate unit and test-driven practices
Run solution playbacks and scope reviews
Update decision records, dependencies and living documentation
Keep domain specialists responsible for their areas while preserving end-to-end coherence

Typical outputs

Working increments
Updated design and decisions
Iteration evidence
Refined release forecast

Prove critical components

Evidence after the HLD — embedded where risk warrants it

Prevent high-impact assumptions from surviving into production merely because the HLD looked convincing.

Typical activities

Run technical spikes and product-capability checks
Validate APIs, events, data flows and integration ownership
Establish performance and volume baselines
Test security feasibility and identity boundaries
Confirm migration or operational constraints
Record go/no-go decisions and refine the architecture

Typical outputs

PoC evidence
Confirmed constraints
Revised design where needed
Explicit decision

Consolidate, test & harden

Multiple cycles per release — non-iterative release assurance

Prove that increments work together as one operational solution, not only as locally successful components.

Typical activities

Manage the release and resolve integrated defects
Execute process, end-to-end and regression testing
Complete user acceptance testing
Run performance and volume tests
Complete security hardening and operational monitoring
Confirm data, support and cutover readiness

Typical outputs

Integrated release candidate
Acceptance evidence
Performance/security findings
Go-live readiness decision

Cut over, stabilise & operate

Once per release, followed by continuous learning

Move into production responsibly and use operational evidence to guide support and future improvement.

Typical activities

Execute cutover and go-live controls
Run hypercare with clear ownership and escalation
Monitor performance, integration and operational health
Transfer knowledge and support responsibilities
Capture lessons and feed them into the next release or operating backlog

Typical outputs

Production release
Hypercare exit criteria
Operational ownership
Improvement backlog

Across every stage

The continuous layer

Governance and decision ownership
Architecture decision records and traceability
Risk, dependency and assumption management
Stakeholder alignment and transparent trade-offs
Security, performance, data and operational considerations
Architecture assurance across client teams and delivery partners

Next step

Need an independent view on a complex Dynamics 365 decision?

Let’s discuss the architecture, the trade-offs and the realistic options — without starting from a predefined solution or delivery model.

Start a conversation →