Are your change management initiatives solving the right problem?
Part 1: Why misdiagnosis derails projects
In project and change management, there’s one question that doesn’t get asked enough:
Are we solving the right problem?
It’s easy to get swept up in momentum, launching into delivery mode without fully understanding the problem we’re trying to solve. But when the diagnosis is off, even the best solution will fail – because it’s solving the wrong thing. The result? A solution that doesn’t land, outcomes that don’t materialise, and confidence in both the project and its leadership starts to erode.
Technical
solutions that don’t get used
Deliverables
that tick boxes but miss the point
"Successes"
that don’t move the needle
The real problem: Jumping to the solution too soon
Often, organisations focus on symptoms rather than the root cause of a problem. This leads to solutions that treat surface-level symptoms while the real problem remains unresolved. In many cases, multiple underlying causes contribute to the core problem. These ‘sub-problems’ need to be analysed to understand their impact and prioritised based on the value their resolution would bring. Taking this approach ensures the change initiative targets what matters most – maximising impact and effectively addressing the root problem.
Why does this happen?
Stakeholders often jump to a solution instinctively for various reasons such as cognitive biases, cultural pressures, organisational incentives, or simply a desire to realise the solution’s value as quickly as possible. Familiar symptoms may trigger pattern recognition and confirmation bias, leading to people assuming they have seen the problem before and know how to fix it. Add in the organisational pressure to act quickly, and teams are rewarded for speed over accuracy. Experienced leaders may rely too heavily on past wins, while cultures that reward action over analysis discourage deeper investigation. Misaligned Key Performance Indicators (KPIs) and limited cross-functional communication only compound the issue, making it easy to move ahead without ever fully understanding the problem that needs to be solved.
At CITI, we work alongside organisations to bring clarity, structure, and objectivity to the problem diagnosis phase. We ask the right questions to get beneath the surface, challenge internal assumptions, and uncover the core problem that needs solving. As neutral facilitators, we help align stakeholders around a shared understanding, ensuring the focus stays on the real problem, not just the most vocal or most recent symptom. This approach helps our partners avoid costly missteps, build a strong case for change, and implement the tools and mindset to tackle future challenges with confidence. Please get in touch with us if you feel we could help enhance your organisation.
The diagnosis: Requirements elicitation and capturing done right
If your requirements process is just a list of stakeholder wants, you’re already off track.
Effective requirements capturing begins with thorough requirements eliciting. This process is not about compiling a list of stakeholder wants, which are often influenced by personal or political agendas. Instead, it’s about actively uncovering the underlying business needs that drive meaningful change, even when stakeholders struggle to articulate them. By using interviews, workshops, observations, and root cause analysis techniques such as the 5 Whys and the Fishbone (Ishikawa) diagram, teams can dig beneath the surface to identify what the business truly needs, not just what people say they want. It’s a critical step in clarifying scope, challenging assumptions, and aligning priorities before any discussion of potential solutions begins. Done well, it prevents misalignment, reduces costly rework, and builds early buy-in from key stakeholders. Done poorly, it leads to missed expectations and solutions that fail to address the real problem.
Stakeholder Engagement: Staying grounded in the problem space: Effective stakeholder engagement when eliciting the requirements is not a box-ticking exercise – it’s a critical, human-centred process that keeps everyone anchored in the problem space. Humans are wired to jump to solutions, but the real value lies in slowing down and exploring the problem from all angles. This means going beyond the usual voices and engaging those closest to the problem – people who experience the pain points first-hand.
Following requirements eliciting, requirements capturing is the process of organising, refining, and translating raw stakeholder input into clear, prioritised, and validated requirements. It involves categorising inputs such as business, functional, and technical needs – clarifying vague statements, and rewriting them into specific, testable requirements. This ensures everyone understands not just what’s needed, but why. Prioritisation helps focus on what truly matters, while validation with stakeholders ensures accuracy and alignment.
Use tools that drive clarity
A disciplined diagnosis isn’t about ticking boxes, it’s about fostering shared understanding. The most effective tools in requirements capturing, such as the 5 Whys and the Fishbone (Ishikawa) diagram ensure teams slow down, question assumptions, and share a thorough picture of the problem space. They don’t just document what’s already known, they reveal what’s been overlooked.
At CITI, we work closely with our partnering organisations, using our own proven, field-tested tools to enable them to get problem diagnosis right from the start. Our tools ensure effect requirements elicitation by keeping stakeholders focussed on the problem space long enough to have the right conversations surrounding the core problem, before moving onto capturing the requirements.
These tools matter because they:
Expose gaps in understanding between teams and individuals who may each see a different slice of the problem
Challenge assumptions by surfacing deeper causes, not just symptoms
Make the invisible visible, turning fuzzy frustrations into structured insight
Create alignment, ensuring everyone is working from the same definition of the problem.
Ultimately, tools that drive clarity turn complexity into confidence – giving teams the confidence that they’re solving the right problems, not just the “loudest” or most prominent one due to a recency bias some may experience.
Define the Gap: The requirements elicitation and capturing enables us to produce a solid problem statement, which includes three elements:
Ideal
What should be happening?
Reality
What’s happening now?
Acceptance criteria
What good looks like?
Why this matters
When your problem definition is inadequate, your solution will be too. Taking time up front to capture real, structured requirements isn’t bureaucracy – it’s your best insurance against wasted investment.
In Part 2, we’ll explore what happens after the diagnosis: how to design and implement solutions that actually solve the problem and stick.
If this strikes a chord with you, or you have any comments or questions regarding your change management initiatives
solving the right problem, please feel free to get in touch to have a chat using the methods below:
Get in touch for more information
