AML/CFT remediation, regulatory change, technology implementation, digital transformation, AI projects... the subject may change, but many of the project management challenges remain surprisingly similar.
External expertise can accelerate delivery and bring valuable capabilities. But successful execution still depends on what happens internally: how the project is defined, owned, governed, measured, challenged and communicated.
Before focusing on the solution, the technology or the provider, a few simple project governance questions are worth asking.
1. Start with the project, not the provider
Before launching an RFP or approaching external providers, the first step is to understand and document the problem to be solved.
What triggered the project? A regulatory finding? An internal or external audit recommendation? A compliance monitoring finding? A regulatory change? A control deficiency? A technology limitation? Or simply a business decision to improve an existing process?
The trigger matters. It helps determine the urgency of the project, the expected outcome, the level of governance required and, ultimately, what should be asked of the provider.
Once the problem is understood, the project should be framed internally: its scope, objectives, expected deliverables, timeline, resources and success criteria. Dependencies and constraints should also be identified early, including the availability of internal teams, data, systems and subject-matter experts.
This exercise should take place before the RFP. Otherwise, there is a risk of asking providers to define both the problem and the solution, making it much harder to compare proposals, challenge assumptions and remain in control of the project.
A simple question should therefore come first:
What exactly are we trying to fix, change or achieve and how will we know when we have succeeded?
2. Keep ownership where it belongs
Appointing an external provider does not transfer ownership of the project.
Clear internal ownership starts with an identified project owner, with sufficient authority, knowledge and access to the relevant stakeholders. Who owns the project internally? Who validates key decisions? Who challenges the provider? Who approves significant changes to the scope or timeline? Who handles escalations? And who ultimately accounts for the project?
The project owner provides the link between execution and the organisation. This does not mean managing every operational detail, but maintaining visibility over the project, facilitating decisions and ensuring that issues reach the right people when needed.
This becomes particularly important when several internal teams or external providers are involved. Individual workstreams may progress as expected while dependencies, competing priorities or unresolved decisions affect the project as a whole.
External expertise strengthens execution; it does not dilute accountability. Someone within the organisation still needs to retain the overall picture and remain accountable for where the project is going.
3. Fit and proper: the right expertise for the project
Selecting a provider also means looking at the resources assigned to the project.
Does the team have the right knowledge, skills and experience for the work to be performed? Do they understand the relevant regulatory, operational or technical environment? Is the level of expertise aligned with the complexity and risk of the project?
Fit and proper, in this context, is about matching capabilities to the specific tasks, risks and expected outcomes of the project.
This assessment does not necessarily stop at onboarding. Team changes, evolving project complexity or an expansion of scope may require another look at whether the resources remain appropriate throughout the project lifecycle.
Ultimately, the question is simple:
Do we have the right expertise, in the right place, for the work that needs to be done?
4. Prepare the organisation before execution starts
A project can be well designed and properly resourced, yet still lose time if the organisation itself is not ready for execution.
Before the project starts, the relevant internal stakeholders need visibility on what is coming. IT, Operations, Compliance, Risk, HR, Information Security or other functions may all have a role to play depending on the project. Bringing them into the discussion early helps identify practical dependencies before they become blockers.
The questions are often very concrete. Where will external resources work? What equipment do they need? Which systems, data and folders require access? Which internal policies and procedures apply? Is specific training required before access is granted? Who approves access and who removes it when the project ends?
Internal onboarding also matters. External teams need to understand the organisation’s processes, tools, terminology, escalation channels and ways of working before they can execute effectively.
But preparation is not only logistical. People contribute better when they understand why the project is happening, what it is trying to achieve and how their role contributes to the outcome. Early communication helps create that shared understanding, gives teams the opportunity to raise practical concerns and provides them with the information and tools they need to contribute effectively.
Good project mobilisation is therefore not only about getting the provider ready.
It is about getting the organisation ready, informed and engaged.
5. Define the framework and measure what matters
Once the project is mobilised, the execution framework needs to be clear and measurable.
The scope translates into concrete work instructions, methodology, allocation of tasks, deliverables and expected quality standards. A RACI* can help clarify who performs, reviews, approves or needs to be informed. Documentation requirements, escalation channels and change management also provide a framework for dealing with issues or changes as the project evolves.
Measurement is equally important. What does progress actually mean? How is quality measured? Which milestones indicate that the project is on track? What constitutes an exception? When does a delay require escalation? And how do we determine whether the expected outcome has actually been achieved?
This is where the distinction between activity and progress becomes important. A high number of files reviewed, tasks completed or system features implemented may demonstrate activity, but not necessarily quality or effectiveness.
A meaningful set of indicators combines quantitative and qualitative measures: completion rates, milestones, quality or error rates, exceptions, delays and, where relevant, effectiveness.
The objective is not to multiply KPIs, but to select those that provide a reliable view of where the project stands, how it is performing and whether it remains aligned with its expected outcome.
RACI: Responsible, Accountable, Consulted and Informed — a responsibility matrix used to clarify roles within a project.
6. Oversight means challenge, not just monitoring
Oversight is not limited to receiving progress reports or checking whether milestones have been met. It is also about understanding how the work is being performed and identifying issues early enough to act on them.
Sampling, quality controls and second-level reviews can reveal recurring errors, inconsistencies or misunderstandings. The value of these controls lies in what happens next: analysing the root cause, clarifying instructions, providing additional training where needed, adjusting the methodology or correcting a process that is not working as expected.
This creates a continuous feedback loop between execution and oversight. Findings are not simply recorded for later remediation; they are used to improve the project while it is still running.
The same applies to the provider relationship. Regular exchanges create opportunities to challenge results, discuss difficulties, clarify expectations and adapt where necessary.
Effective oversight is therefore not only about detecting what went wrong.
It is about using that information to keep the project on track and avoiding the need to remediate the remediation.
7. Keep the Board informed and be able to account for the project
Project governance does not stop at the operational level. The Board needs sufficient visibility to understand how the project is progressing and where attention or decisions may be required.
Reporting goes beyond a completion percentage. Where are we? Are we on track? What issues have emerged? What remains at risk? What corrective actions have been taken? Are additional resources or decisions needed?
The level and frequency of reporting will naturally depend on the nature, scale and risk of the project. What matters is that the information provides a meaningful view of progress, quality, key issues and deviations from the original plan.
This also creates accountability. Management remains able to explain the status of the project, the challenges encountered, the decisions taken and the rationale behind them.
Good governance is not about reporting everything. It is about providing the right information at the right level, allowing the Board to understand, challenge and, where necessary, decide.
8. Close the project and prepare what comes next
The provider’s final delivery does not necessarily mark the end of the project.
Closing a project also means confirming that the expected outcomes have been achieved, understanding and documenting any deviations, resolving outstanding exceptions and ensuring that decisions and key evidence are properly recorded.
It is also the right time to look back. What worked well? What could have been done differently? What recurring issues did the provider observe? Are there processes, controls or ways of working that could be improved?
External providers can bring a useful perspective from their experience with similar projects and market practices. A closing discussion creates an opportunity to capture that feedback and identify relevant best practices or improvements for the organisation.
Finally, attention turns to what comes next: transferring knowledge, defining any ongoing monitoring, integrating changes into business-as-usual activities and ensuring that internal teams are comfortable taking over.
A successful project closure is therefore not only about demonstrating what has been delivered. It is also about learning from the project and creating the conditions to move forward with confidence.
Conclusion
Successful project delivery is ultimately about more than scope, timelines and deliverables. It relies on clear governance, effective communication and teams that understand the objective and are empowered to contribute to it.
External expertise can strengthen execution, but the organisation remains at the centre: maintaining ownership, connecting the different parties, challenging where necessary and keeping management and the Board informed.
At SableRock, we can coordinate AML/CFT, regulatory and technology/AI projects from initial scoping through to delivery and closure. We can also support projects already underway by bringing an additional layer of governance, coordination and oversight: connecting internal teams, external providers and management, structuring reporting and helping maintain momentum.
Because a successful project is not only one that delivers.
It is one where governance provides direction, communication creates alignment, and people move forward together.