Blog

From uncertain to effective: How consultants should handle ambiguity

Product & Delivery

View more blogs

In this blog, Luke Ryan, Client Relationship Director at Opencast, shares practical guidance for consultants stepping into new public sector engagements where information is incomplete, context is sparse, and objectives are still forming. From stakeholder mapping to RAID logs, Luke outlines the tools needed to reduce ambiguity, build credibility, and demonstrate value from day one.

A person stands at a clear lectern on a stage, speaking into a microphone while holding a small handheld device. A large screen to the left displays partially visible presentation text. The setting is lit with blue stage lighting, and the speaker wears a light button-up shirt and a lanyard with a name badge.

Why ambiguity happens

When joining a new public sector engagement, it’s common for consultants to step into environments where information is incomplete, historical context isn’t well documented, and objectives are still forming.

Ambiguity is not a blocker; it’s an expected part of consultancy. How you respond in the first few days to reduce ambiguity strongly influences your credibility and the client’s confidence in you.

Ambiguity in public sector projects often arises because:

  • Priorities shift quickly in response to policy, funding cycles, or ministerial direction.

  • Internal client teams may not have had time to prepare onboarding materials, especially during fast-moving delivery phases.

  • Multiple stakeholders may have nuanced or evolving views of the objectives, shaped by their own priorities and contexts.

Understanding these factors means you can stay calm, purposeful, and proactive when details are sparse.

How to respond in your first few days

It's important that you begin to gather the basics quickly; even imperfect information helps anchor your first steps.

Start by asking yourself:

  • Who is your main point of contact?

  • What outcomes is the client trying to achieve?

  • What is the problem to solve?

Then:

  • Review any documentation that exists already about the programme's goals, policy context, or project documentation (often this is available publicly, and you can review it before you join a project)

  • Create a stakeholder map and introduce yourself to these stakeholders

It's natural for clients to move quickly toward solutions. Your role is to gently draw out what the real problem is.

Consider using design thinking techniques like the ‘5 whys’, or ask questions like:

  • “What challenge are we ultimately trying to solve?”

  • “What does success look like to you?”

  • “What’s driving the urgency?”

  • “What’s blocking progress right now?”

This helps you build a shared understanding and uncover gaps.

Tools to bring clarity

When you're working with limited information, creating tangible outputs early is one of the most effective ways to build structure and demonstrate progress. Each of these outputs demonstrates structured thinking and helps you and your client get on the same page faster.

Start with these:

  • Start a knowledge base document including links to where you’ve found information.

  • Start a RAID log (a tracker for Risks, Assumptions, Issues and Dependencies).

  • Create a query log, document gaps in your knowledge or missing information.

  • Document the assumptions you're making, and try to validate or disprove these quickly.

  • Create or iterate an as-is process map and add pain points as you uncover them.

These become living artefacts that you refine as your understanding deepens. Keep these in a central location (such as SharePoint or Confluence).

You can also use different discovery techniques to gain clarity for yourself and foster consensus among stakeholders, such as:

  • Document reviews.

  • 1-to-1 interviews.

  • Shadowing.

  • Larger stakeholder workshops.

Two open laptops sit on a wooden table in a casual workspace, with a black coffee mug placed between them. One laptop shows a presentation screen, while a person nearby holds a reusable bottle. Another person is partially visible using a laptop with an illuminated logo. The background is softly blurred, suggesting a relaxed, collaborative café or meeting environment.

Who to lean on

The process of increasing clarity doesn't always happen quickly. It can be valuable to find supporters who can speed this up.

Prioritise:

  • Other consultants who work on parallel initiatives or who have done so previously (contact them before you join the project to land as well as possible).

  • Long-serving civil servants and team members who have institutional knowledge of the as-is process.

Don't be afraid to surface uncertainty directly with your client contacts. Saying something like "I haven't seen documentation on X yet, so here's the assumption I'm working with. Can you confirm or correct it?" builds trust, shows initiative, and helps close gaps quickly.

Conclusion

Ambiguity is an inevitable part of public sector consultancy, but it doesn't have to be a barrier to progress. By staying calm, asking the right questions, and using the tools and techniques outlined above, you can turn uncertainty into an opportunity to build trust, demonstrate initiative, and add real value from the outset. The consultants who thrive in ambiguous environments aren't those who wait for clarity to arrive; they're the ones who go out and create it.

Related Content

Blog post

Abstract digital network of blue and orange circuitry lines representing data flow and system connectivity.
The Future of DevOps and the Rise of Intelligent Systems

In Part One of this series, we explored how DevOps emerged as a response to the challenges of modern software delivery and why many organisations have struggled to realise its full value. In this second article, Opencast Practice Lead Scott McCarthy examines how DevOps has matured beyond its original foundations and become a set of complementary practices focused on delivering reliable, sustainable outcomes at scale. This article explores how DevOps continues to evolve and what organisations need to do to remain effective in an age of Artificial Intelligence (AI) systems.

Product & Delivery

Headshot of a person with glasses and a short beard, wearing a dark top with red detail, standing indoors against a white door.

Read more

Blog post

Abstract blue light trails converging into a single point, representing data flow and system integration.
How DevOps Evolved and Why It Became Confusing

In this blog, Opencast Practice Lead Scott McCarthy explores how DevOps has evolved from a response to the challenges of modern software delivery into a widely adopted approach. Drawing on experience working with complex delivery teams, he reflects on how the original intent of DevOps has sometimes become less clear as organisations focus on tools and structures alongside culture and outcomes. This is Part One of a two-part series, focusing on how DevOps emerged, why it can be perceived as confusing, and where organisations commonly face challenges when putting it into practice.

Product & Delivery

|

IT Architecture

Headshot of a person with glasses and a short beard, wearing a dark top with red detail, standing indoors against a white door.

Read more

Blog post

Close-up of hands reading a refreshable braille display in front of a laptop, with a coffee cup and earphones on the desk.
Accessibility in legacy services: Why waiting for the redesign is not enough

Accessibility in legacy services is often deprioritised in favour of future redesigns. In this blog, Adam Liptrot, Senior Consultant and Accessibility Specialist at Opencast, explores why that approach falls short, and why making meaningful improvements today is essential for the people who rely on these systems every day.

Product & Delivery

|

Diversity, equity and inclusion (DEI)

|

IT Architecture

A person sits at a desk in an office setting, leaning back in a chair with both hands behind their head. The desk holds a laptop, a mug, and small office items, with other desks and chairs visible in the background.

Read more

View more blogs