What should we resolve before implementation?

The supplier is ready to proceed, but internal sign-off keeps slipping. Different teams need different things to feel ready.

What Cohentia examines: We map acceptance criteria, unresolved issues and the decisions behind sign-off.

Cohentia examines whether acceptance criteria are unclear, or nobody has authority to accept the operational trade-offs.

What Cohentia examines: We check who can accept each trade-off and what evidence they need.

If this is happening, sign-off becomes a negotiation under deadline pressure. Unresolved issues move into live operations.

What Cohentia examines: We trace unresolved conditions into launch risk and pressure on operating teams.

Establish what remains undecided and who can decide: define acceptance conditions and resolve or escalate trade-offs.

What Cohentia examines: We define acceptance conditions and the decisions required before proceeding.

The timetable works on paper, provided the same people can run the business and deliver the change at once.

What Cohentia examines: We map delivery schedules, daily workload and demands on the same critical people.

Cohentia examines whether the same people are allocated to daily operations, testing, training and several change programmes.

What Cohentia examines: We compare available capacity with testing, training and other change commitments.

If this is happening, work is displaced rather than absorbed. Testing is compressed, increasing defects and later support demand.

What Cohentia examines: We trace displaced work into compressed testing and later support demand.

Map competing demands on critical roles: sequence work, release capacity, provide cover or change the date.

What Cohentia examines: We compare sequencing, cover, released capacity and changes to the date.

The demonstration succeeded. People who will use the system are still asking how it will handle their difficult cases.

What Cohentia examines: We map demonstration results, real exceptions and representative operating volumes.

Cohentia examines whether the solution was tested against a standard scenario, excluding difficult cases and actual operating volumes.

What Cohentia examines: We test whether difficult cases and actual constraints were excluded from the demonstration.

If this is happening, a successful demonstration creates premature confidence. Exceptions require costly workarounds after launch.

What Cohentia examines: We trace uncovered scenarios into likely workarounds and support demands.

Test representative operating scenarios: adjust the design, narrow the launch or require further evidence.

What Cohentia examines: We identify what further evidence, design changes or launch limits are needed.

Migration is waiting for clean data. The data team keeps meeting questions that only the business can answer.

What Cohentia examines: We map migration records, conflicting definitions and unresolved ownership decisions.

Cohentia examines whether business owners have not agreed definitions, authoritative records or rules for resolving conflicts.

What Cohentia examines: We separate data errors from disagreements about meaning and authoritative sources.

If this is happening, data is repeatedly cleaned and disputed. Migration carries unresolved meaning into the new system.

What Cohentia examines: We trace repeated cleaning into delay and unresolved issues carried into migration.

Separate data errors from ownership and definition gaps: assign business decisions before approving migration.

What Cohentia examines: We identify the business decisions needed before approving the data move.

One process is proposed for every business unit. Local teams say some differences are essential, but those differences have not been tested.

What Cohentia examines: We map proposed standard processes and the local variations teams say they need.

Cohentia examines whether some differences reflect genuine customer, contractual or operating requirements.

What Cohentia examines: We test differences against actual customer, contractual and operating requirements.

If this is happening, forced uniformity creates exceptions and shadow processes. Central reporting then hides material differences.

What Cohentia examines: We trace forced uniformity into exceptions, shadow work and reporting gaps.

Distinguish necessary variation from avoidable inconsistency: standardise the core and define controlled local variants.

What Cohentia examines: We define a standard core and the evidence required for controlled local variation.

Support is expected to take over after go-live. The ownership of exceptions, access and future changes remains unclear.

What Cohentia examines: We map handover plans, incident routes, access decisions and ongoing change ownership.

Cohentia examines whether no clear owner exists for incidents, exceptions, access decisions or ongoing changes.

What Cohentia examines: We check whether support responsibilities and supplier boundaries cover real operating cases.

If this is happening, problems bounce between teams and suppliers. Temporary project staff remain essential after planned handover.

What Cohentia examines: We trace unresolved dependencies into repeated referrals and reliance on project staff.

Establish the support responsibilities and unresolved dependencies: resource ownership and set practical handover conditions.

What Cohentia examines: We set practical ownership, resourcing and handover conditions.