Problem-solving vs gathering requirements: our consultancy approach

Problem-solving vs gathering requirements: our consultancy approach

23rd February 2021

By Richard George

Have you ever hired a consultant for a technology project and been disappointed by the outcome?

Driven by positive human outcomes, the focus of Connect Assists consultancy work is to deliver actionable insights, solve real-world problems and offer practical plans for how to address them.

Rather than gathering requirements from non-technical staff and building a system from those specifications, we work together to paint a broad picture, then narrow it down to the technical details.

Accountability ‘ping-pong’: gathering requirements

Over the years, I’ve seen a lot of games of what I call ‘accountability ping-pong’ being played between providers and clients.

The common departmental divide between technology and operational teams offers a real threat to producing purpose-driven solutions.

Consultants, looking for clarity open a conversation asking clients what their requirements are; often focusing on the configuration of technology rather than the human outcome.

Consequently, it’s often the technology teams who are responsible for the briefing with operational staff only being brought in later in the process – sometimes as late as the user acceptance testing phase. The chain of events runs something like this:

The provider draws up a requirements spec based on what they’ve been told and in good faith. They ask the client to sign it off – so passing accountability back to their client. The provider’s development team then faithfully follows that spec, without saying if they think it could be done better another way.

You test the solution. It meets the spec, then with a flourish of expectation and pride, the client’s operations team are lined up for a demonstration then the teams that are actually going to use the solution start asking for changes – a lot of them.

The project heads into an uncomfortable game of ‘accountability ping-pong’ where good relationships become tarnished with the commercial realities of change management. And this all before a solution has actually gone live.

That creates an uncomfortable situation where the outsourced organisation is trying to do the right thing by gathering requirements, but the client doesn’t have the skills or experience to define those requirements.


I avoid asking customers to define their requirements. Instead, I ask them to explain their operational headaches, how do they affect their business and customers? What are the implications for resourcing? Regardless of what technologies are (or are not) available, what does ‘good’ look like?

These conversations seek to help articulate what a client wants to achieve rather than how they are going to achieve it.

Arguably, answers to these more subjective questions are a nightmare for technology teams – they’re too ‘fluffy’, but in my view they represent a better starting point than requirements briefings. Surely that’s a more sensible approach to shoe-horning operational goals into a given technology solution?

If the consultant is worth their fee, then they should be able to translate the feedback into a brief that brings clarity to the project’s objectives and forms the basis of the requirements documentation and technical requirements.

It’s a human-focused, problem-solving approach – not one that’s a slave to technology.

Problem-solving in action

Say a client wants to get thousands of application forms and supporting documents into one place so that caseworkers can evaluate them. Email won’t suffice, as the documents are too large and contain sensitive data. You can’t bring staff into the office because of Covid-19.

We can build a customer portal where digitised documents can be placed, but we will also open up the opportunity to improve the overall experience for customers, as well as staff.

So, we ask: do you have bugbears around how this information is presented? Is it categorised correctly? Is it simple to action?

Take Home Office asylum visa applications, for example. These are very long, and often customers are not familiar with UK terminology so need considerable assistance.

There is some really clever tech that uses business rules to power online application forms so that they respond dynamically. So if an applicant inputs that he is a single man, the tech works in real-time to skip the questions about family.

It can also evaluate the answers and recommend an outcome that a caseworker can then check and validate. Concurrently, improvements in the reliability and accuracy of artificial intelligence is moving at pace.

We see a time coming soon where fixed business rules will interplay with AI to make customers and caseworkers lives much more straightforward when it comes to administrative processes.


We begin our consultancy projects with a vision session, typically with the CEO. Then, we ask frontline people what ‘good looks like’ for them.

You’ll generally find a disparity between the two visions which can be a slightly uncomfortable moment but if the outcome is the product of a collaborative, informed and well-managed process, then it stands a much better chance of working for everybody.

As a consultant, you have the advantage of being free of organisational politics and have the privilege of acting as a facilitator between the frontline part of an operation, the people who manage it and the technical teams that support it. It’s why I enjoy my job.

If you would like to find out more about Connect Assist’s problem-solving skills, check out our success stories and drop us a line to explore how we can help.


If you need our help in developing more effective, meaningful connections with customers, get in touch today.