Causal Wizard is designed to help people apply Causal Machine Learning to real world problems

These articles about AI and ML project design are intended to address the real difficulties people experience when trying to define and scope their projects.

Project design issues are widely regarded as a key cause of project failure. So to have the best chance of success, read our tips before you start, and review them regularly during your project.

These articles are organised as a set of questions you should ask yourself about each aspect of your project. Most importantly, you do not need to be an AI or ML expert to answer the questions.

We also provide a free tool - a kind of Business Model Canvas for AI and ML projects:
Project designer
Using the tool, you can record your answers to these questions.

Problem definition Value proposition Build a team Data Solution design Evaluation Adoption

How to turn a problem into a Machine Learning solution

Anwer the questions below to define the problem you will solve, and the impact of solving it.

Q1.1 Background

Briefly describe the need, problem or opportunity - from a business perspective, not a technical one.

Additional context & tips

The objective here is to define what you want to achieve, in terms which avoid narrowing how you will do it.

You might have a business problem - something that is costing money or time (and time is money!) Or perhaps a new need, which must be met; or maybe you have spotted an opportunity to be seized.

Ensure you capture the heart of the idea. Try to avoid creating a tautology - for example, don't say "we need a machine which picks fruit, so this project is to develop a fruit-picking machine". Instead, focus on the real problem - "picking fruit by hand costs $XYZ per hectare and we believe there's an opportunity to reduce this cost using robotics". Avoid declaring the problem statement as a desired capability e.g. "this project will develop software to detect malware". Instead, re-focus on the problem "malware infections are costing the business $XYZ in lost productivity per person per month".

To help you, ask stakeholders what their needs are, especially non-technical stakeholders. Try to define the problem or opportunity in their business language, not technical terms. The next question will also help you identify those stakeholders. If necessary, go and talk to them and come back to enhance your answer to this question.

Q1.2 Stakeholders and impact

Which teams, business functions or people are likely to be impacted or benefit from the project?

Additional context & tips

The aim here is to start to understand who or what would potentially be affected by the project. This will help you build support and essential input for the project, and defuse any potential issues further down the track.

To identify relevant entities, consider the project from several different perspectives.

Which teams or individual people are potentially affected by the problem, or any future solution? Perhaps people are responsible for elements touched by the project, or even that entire business area. Or maybe the solution aims to change the workflow of these people, potentially making it easier or harder. Does it have implications for team size and jobs?
Which business processes are potentially involved - either because they provide data or other input, or because they consume outputs of the project - or systems the project will replace?
Finally, are there specific systems, equipment, apps, machines or devices which are affected, perhaps because the solution implies changes to their software environment. For example, if your solution will use a shared business app, you'll need to think about how that deployment and functionality would affect other users of the app and IT workloads.

Q1.3 Key domain knowledge

Briefly name & describe key concepts, processes, risks and constraints which are relevant to the project and might not be understood by all readers of this document.

Additional context & tips

This question aims to develop some key background knowledge to help your colleagues understand how your project fits into the bigger picture. This is the place to describe how your opportunity or problem fits into the business or system you're going to be changing. It's also the place to add key terminology or concepts which might not be familiar to everyone in your organisation. By providing this reference, you make it easier for them to understand everything else in this document.

So what should you include?

We suggest you start by thinking of the major concepts which relate to your solution - perhaps, the actions or entities in relevant workflows.

Next, consider enumerating key steps or a diagram of the workflow or process flow involved. Consider listing essential inputs and dependencies.

Another important consideration is risks - what are key business risks involved in the business function you're seeking to modify. Are these reputational? Financial? Legal?

Finally, consider things which are constraining or limiting the existing process, and presumably impact any future solution as well.

Don't make this section too long; the aim is to explain the high level picture.