What we do

An independent assurance partner for complex SAP delivery.

Waypoint can be engaged in two ways. Some clients bring us in for a focused review at a specific point, such as a scope decision, phase gate, delivery health check, recovery point or go live readiness review. Others keep us close across the life of the program as an independent assurance partner, providing a senior view at the points that matter without becoming part of the delivery team. In both cases, the role is the same: to give leaders a clear, independent view of what is really happening, what needs attention, and what should happen next.

Focused review

Brought in at a specific point. A scope decision, phase gate, delivery health check, recovery point, or go live readiness review. Clear findings and practical recommendations within a defined timeframe.

Independent assurance partner

A senior independent view across the life of the program, at the points that matter, without becoming part of the delivery team.

The situations we are most often brought into.

The status is amber. The program is still moving, and nothing has happened yet that clearly justifies escalation. But your confidence has shifted.

You cannot point to one issue that demands immediate action, and that is often the challenge. It is the pattern in the conversations, the pace of decisions, the quality of answers, and the way the same risks keep returning.

At this stage, you do not need a large intervention. You need an independent view before the concern becomes harder to ignore. We test the reality behind the reporting and tell you whether the program is as steady as it looks, or whether something is starting to build beneath the surface.

A scope or statement of work is being drafted, reviewed, or is ready to be signed, and you need confidence that it is detailed enough to support successful delivery.

The risk in these documents is rarely obvious. It sits in what is assumed, left open, not clearly defined, excluded, or written in a way that creates gaps once the work begins.

We review scopes and statements of work through the lens of delivery risk, testing whether deliverables, acceptance criteria, responsibilities, dependencies, and performance measures are clearly defined. Clearer documentation creates clearer expectations, better accountability, and fewer surprises once delivery is underway.

A phase gate. A delivery health check. A major design decision. A readiness point. A go live call.

These are the moments where an independent view earns its place. We look at the evidence, the risks, the dependencies, the quality of decisions and the delivery rhythm underneath the reporting.

The aim is not to create another review cycle. It is to help leaders understand whether the program is ready to move, what conditions should be attached, and what needs to be dealt with first.

The program has slipped, and not for the first time. The reviews keep circling the same issues without ever landing them. Dates move, actions repeat, explanations sound familiar, and the real cause still has not been dealt with.

You do not need another review that restates the problem. You need someone to find what is actually holding it back, and help you get it moving again.

You are at the start of something large, and the early decisions will shape everything that follows. The delivery method, standards, review points, roles, decision paths, planning rhythm, and ways of working need to be clear before the pressure arrives.

We help set the program up so it can hold, with the practical structure needed to move from intent to delivery without inventing the basics under pressure.

The work in practice

The judgement behind the work.

These are drawn from real programs. Three times the obvious explanation was wrong, and what it took to see it.

01

When the people were not the problem

The offshore team was not delivering enough throughput. That much was true. The conclusion everyone jumped to was that the team itself was the problem. More capability was needed. More oversight. More pressure.

Before accepting that, I went and spent time with the team. What I found was more interesting than the numbers being reported. The people were capable. They were working hard. But they had become disconnected from the outcome. They were completing tasks without understanding the value of what they were contributing to.

So instead of treating it as a performance problem, I treated it as an engagement problem. I spent time helping the team understand the purpose of the work, creating ownership, recognising achievements, and building a sense of pride in delivery. A little healthy competition between teams helped as well. As engagement improved, throughput improved.

The metric mattered. Understanding what sat behind the metric mattered more.

02

When the System Integration Testing delay was only the symptom

The System Integration Testing cycles kept slipping. The immediate response was predictable: testing needed to move faster. But when the same problem appears repeatedly, it is usually worth asking whether you are looking at the symptom rather than the cause.

When I dug into the detail, testing itself was not the issue. The real constraint sat elsewhere. Defects were not being resolved quickly enough. Throughput across the delivery process was too low. Teams were working hard, but there was no consistent cadence driving issues through to closure. The slipping test cycles were simply where the problem became visible.

So we stopped focusing on the dates and focused on the flow of work. Once the underlying bottlenecks were addressed, the testing cycles stabilised.

In delivery, the visible problem is not always the real problem.

03

When the foundations were built first

A PMO is only effective when the foundations underneath it are already clear. Too many programs establish a PMO and then spend valuable time deciding how it should operate. Templates are created. Governance is defined. Delivery methods are debated. Reporting structures evolve as the program progresses. On a large program, that uncertainty creates unnecessary drag.

My approach was to put the foundation in place before the pressure arrived. The delivery method was defined. The templates were ready. Governance expectations were clear. Planning, reporting and decision making were already in place.

When the program accelerated, the PMO did not need to work out how to function. It already had the structure, rhythm and standards to support the work, so the team could focus on delivery rather than inventing the basics under pressure.

The work that makes a program move with confidence is often done before the pressure arrives.

Start a confidential conversation