Data worse than expected
Early profiling before any timeline is set, and agreed decision rules for records that fall below the threshold.
Methodology
A delivery method with stage gates — so problems don't surface when they're expensive to fix.
Eight phases, each with a goal, deliverables and an explicit exit condition. The method scales to the engagement, but no phase is silently skipped.
Enterprise Delivery System
From discovery to stabilization — with a gate between every phase
Gates are what turn a methodology from a list of phases into a control system. Every gate requires explicit business approval, not just technical sign-off.
Enterprise Delivery System
- 01
Discovery & process understanding
Understand what has to change in daily work, and who is affected.
Interviews with process owners and users, current-state mapping, identifying data sources and connected systems, defining measurable goals.
Stage gate: An approved discovery document with goals, users and in-scope processes.
- 02
Architecture & data model
Lock down the layers that are expensive to change later.
Entity model, sources of truth, permissions and sharing model, integration boundaries, org strategy and platform decisions.
Stage gate: A data and permissions model approved in writing by process owners and IT.
- 03
Solution design & scope
Translate discovery into an agreed backlog with acceptance criteria.
Capability breakdown, user stories, MVP definition, prioritization, risk and dependency identification.
Stage gate: Approved scope with acceptance criteria and a change-control mechanism.
- 04
Build in cycles
Build and show working software, not slides.
Configuration, Flow or Apex by a reasoned decision, user interfaces, a demo at the end of every cycle.
Stage gate: An approved demo per cycle, with the gap list closed.
- 05
Data & migration
Move data people can rely on.
Profiling, cleansing rules, mapping, identity keys, trial load and reconciliation.
Stage gate: A trial load that passed full comparison against the source, with approved gaps.
- 06
Acceptance testing
Verify the process works in the hands of the people who will run it.
Process-based UAT scripts, permission testing, integration testing and load testing where required.
Stage gate: UAT signed off by process owners, with defects classified and blockers fixed.
- 07
Training & readiness
Bring the organization to a state where it can work on day one.
Role-based training, short reference materials, a Champions network, internal communication and a support plan.
Stage gate: A readiness check: users, data, permissions, support and a rollback plan.
- 08
Go-live & hypercare
Stabilize and hand over to ongoing operations.
A planned cutover window, close support in the first weeks, adoption measurement and rapid fixes.
Stage gate: Exit from hypercare against agreed stability and adoption metrics.
Roles
Who is responsible for what
| Role | Core responsibility | Side |
|---|---|---|
| Business process owner | Defines what has to happen and signs off acceptance | Client |
| Authorized decision-maker | Settles disputes and approves scope changes | Client |
| Solution architect | Data model, permissions and platform decisions | HPI Pro |
| Delivery manager | Planning, prioritization, risk and communication | HPI Pro |
| Developer & admin | Build, automation, development and testing | HPI Pro |
| Data specialist | Profiling, migration, quality and reconciliation | HPI Pro |
| IT & security representative | Infrastructure, identity, permissions and regulation | Client |
| User testing group | UAT and usability feedback | Client |
Business process owner
- Core responsibility
- Defines what has to happen and signs off acceptance
- Side
- Client
Authorized decision-maker
- Core responsibility
- Settles disputes and approves scope changes
- Side
- Client
Solution architect
- Core responsibility
- Data model, permissions and platform decisions
- Side
- HPI Pro
Delivery manager
- Core responsibility
- Planning, prioritization, risk and communication
- Side
- HPI Pro
Developer & admin
- Core responsibility
- Build, automation, development and testing
- Side
- HPI Pro
Data specialist
- Core responsibility
- Profiling, migration, quality and reconciliation
- Side
- HPI Pro
IT & security representative
- Core responsibility
- Infrastructure, identity, permissions and regulation
- Side
- Client
User testing group
- Core responsibility
- UAT and usability feedback
- Side
- Client
Risk management
Four risks handled up front
Scope creep
Every request gets an impact assessment and an explicit decision. An approved change also changes the time and the budget.
User resistance
Early involvement of key users, real acceptance testing and training by role rather than by screen.
Single-person dependency
Decision documentation and continuous knowledge transfer, so the project does not stall on a vacation or a departure.
FAQ
Methodology — questions we hear often
How long does a typical Salesforce project take?
Duration comes from the scope of the processes, the state of the data and the number of integrations — not from the size of the organization. One sales process with a clean migration looks nothing like three cross-department processes wired into an ERP. We give a time range only after discovery, because before that it is guesswork.
What is a stage gate and why is it required?
A stage gate is an explicit condition that must be met before moving to the next phase — approval of the data model, for example, or a successful reconciliation of a trial load. Gates prevent the common pattern where a project keeps running forward on an unapproved foundation and discovers it only during acceptance testing.
Do you work in Agile or Waterfall?
In a controlled combination. Architecture, the data model and data migration require up-front planning, because changing them mid-flight is very expensive. Build, enhancements and prioritization run in short cycles with a regular demo. The approach is chosen per component, not by ideology.
Who from the organization needs to be involved?
A business process owner per domain, an IT or data representative, a decision-maker who can settle disputes, and a user group that participates in acceptance testing. The absence of an authorized decision-maker is one of the most common causes of delay.
What happens when requirements change mid-project?
Change is a natural part of a project. What is not acceptable is undocumented change. Every request is assessed against the approved scope, receives an impact estimate on time and budget, and is accepted or declined by an explicit decision. That is how silent scope creep is avoided.
What does the organization keep at the end?
Architecture and data-model documentation, an integration map, a decision log, test scripts, role-based training material and operating procedures. The goal is that the organization can maintain and evolve the system without us.
Next step
We'll fit the method to your scope
Not every project needs every phase at the same depth — but every project should know which gates it passes.