The Problem Solving Process

Let’s briefly look at the tasks, the data and the process steps of good Problem Solving in a little detail.
Click on any artefact/step to see examples and learn more:

This interactive diagram shows all the phases of a project lifecycle, and the consistent, related steps (click on any one to see examples) required to gather and use data to build and test the solution prototype, and ultimately guide the delivery team to deliver the best product (right-first-time). It reduces the unknowns, defines scope around the required value, and gives clarity and optimal lead time to the whole project team. All whilst reducing errors, cost and delivery time.

This is the pure Problem Solving process – this diagram doesn’t show the integration with the Stakeholders, nor the collaboration (in any depth) with the other project disciplines (Devs, UI designers, Systems Architects, etc). It doesn’t make it immediately obvious when and where all 3 business domains are researched and understood, but they are. It doesn’t show the associates tasks required to create and deliver the steps outlined here, not the AI tools that empower each one.

* For all that you’ll need to pre-order my upcoming book – Super Solver

This is a repeatable, consistent and scalable method for:

• Winning work
• Identifying and leveraging the relevant data and scope of a project in order that it delivers value, not just ends
• Exposing the pain points of users/customers and the business
• Collaborating with and empowering project teams early (not shown here) giving them maximum lead time and allowing them to make the most accurate resource estimates (team size, expertise, tools, time and cost)
• Communicating clearly and giving visibility to the whole project team, from senior stakeholders to engineers, ensuring we’re all on the same page
• Clarifies the opportunities for valuable new technology and innovation that improves the solution – it isn’t just shoehorned in
• Guaranteeing – no, proving – success, before (I’ll say that again ‘before‘)a line of code is written or a service is restructured
• Delivering projects that are optimal, impossible to beat and right-first-time
• Delivering solutions that your users will want to pay for and brands that your users will never want to leave

---

Business Problem Domains

If you’re going to be a good, valuable, problem solver for any organisation, it’s not enough to just know research, or service design, or Agile, or AI, or systems architecture, or revenue goals, or governance requirements or user psychology or a hundred other business, technology and user domain related factors, variables and intricacies.

If you’re going to be a good, valuable, problem solver you have to have a working knowledge of all 3 domains, because business and user problems do not live in just one domain in isolation – they are effected by and affect each other. Trying to fix a user pain point without at least conversational level of knowledge of the business, technology and user domains is like trying to fix a watch with only the knowledge of what time it is. It means you won’t understand the impact (or disaster) of your decisions – you will rely on others, who work in only one of these domains, to join some of the dots – and they won’t.

As a good problem solver, you don’t live in one of these domains, you walk confidently through all of them, connect all the dots and can learn and see the cause and effect ripples. You speak their language (business, technology, user) and mediate between them all, using data as the currency of value to all.

---

High Level Problem Solving Process

Problem solving isn’t a tick box – it’s a critical, foundational, golden thread through the business and every problem or project within it. It crystallises the data and empowers the organisation’s experts, proving the value and informing the solution, minimising the expense and time of delivery, and optimising the value of the solution and the organisation.

Good Problem Solving is the method by which:

• businesses build successful, new products and services,
• businesses achieve operational excellence, continual improvement and contingency planning.
• businesses remove pain points, maximise profits and reduce operational expenditure.
• businesses increase share price, please shareholders and customers/users, and leave their competitors in the dust.
• businesses leverage the right innovation and technology,
• development is quicker, cheaper and right-first-time.
• individual promotions happen, leaders are born, bonuses get paid and organisations own their market.

And surprisingly, it’s very simple and successful – every time

Politics, opinions, ego, personal agendas, career goals and over-promising are all huge factors in failure, leading to hasty, assumption based assurances and a focus on the wrong KPIs – the KPIs that support the initial assumptions/promises, or hide the utility failures.
Tactical project goals, in line with poorly understood assurances, come into conflict with the more important business strategic goals, but still take priority, leading to project leaders wrongly celebrating:

“We delivered (crap and mediocrity) on time and to budget!“

The very purpose of business, and the projects it carries out, are user satisfaction, reputation, savings, efficiency, revenue and profit.

Delivering crap in a 6 week window for a minimum over-spend does nothing to achieve those goals, and makes it easier for our competitors to beat us.

So over the decades, the sectors, the countries, the clients and the projects I have learned, refined, created and integrated the best methods and steps to optimally solve business problems and deliver best in class solutions, using not one partisan method, but the best from them all.
Leveraging expertise in the three domains of Business, Technology and User, this method had evolved and matured. I have used it successfully for many years and clients, including startups, public sector and FTSE 100 organisations. It works in every scenario and for every challenge – physical and/or digital.

---

How the Problem Solving Process Reflects User Needs and Informs Agile

Let’s look at a very simple conceptual example of how a real world requirement is addressed by the Problem Solving process. This shows how a user’s needs are defined using efficient Problem Solving tasks/artefacts and translated into Agile process steps and artefacts, seamlessly and clearly. This ensures no additional work, no unnecessary tasks and no changes.

We’ll use the common and simple example of “a customer needs to ‘Change Password’“. This is only one of the Use Cases in the Secure Access service.

Below you will see an overview of how the Problem Solving (PS) and Agile process tasks are used to research, architect, test and deliver this:

---