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.
Explain what you want to achieve, and how this provides value to the business.
In the previous section, you outlined the problem or opportunity. Now it's time to think about what you could do to solve the problem, or grasp the opportunity.
Don't stress about explaining the details of how you'll go about it. Focus on the outcomes or changes you want to make happen.
Explain how the project will tackle the issues or opportunities described in the Problem Statement.
In this section, write a sentence or two explaining how achieving the changes or objectives outlined above will address the Problem Statement (the previous section of the project design).
Describe how the value provided by the project can be demonstrated and measured objectively. Try to quantify this value.
A key weakness of many projects is the lack of a clear value proposition. This section is really important. How will the business generate a benefit or value from the project?
This shouldn't be left to be self evident - "the value is we reduce network outages". The more explicit and specific you can be, the less the chance the value proposition will be forgotten, or never met.
Look past the immediate objectives and talk to the original problem statement - for example, "network outages cause loss of vital data, which can't be recovered, and reduce productivity. By reducing the frequency of outages we can prevent data loss".
By being specific, it's now easier to try to make the value proposition quantifiable and objectively measurable:
"network outages typically occur every 200 hours, causing loss of vital data, which can't be recovered, and reduce productivity ( 15 staff spent an estimated XYZ hours last month repeating lost work at a cost of $50,000). We believe by addressing technical issues X and Y which are responsible for half the outages, we can halve the number of data-loss events and achieve labour savings of $25,000 a month. To achieve a one-year Return on Investment (ROI) just on labour savings, with a project investment of $125,000, 40% of network outages would need to be prevented."
The quantifiable value proposition is hard to deny and provides a specific performance target for the project. It also provides a framework for amending the value-proposition if the project goes over budget, or if performance is less than anticipated.
Try to avoid subjective measurements of value, such as opinions or views, or anecdotal comparative numbers. These will tend to shift around and can undermine you later. If you need to use subjective metrics (such as client satisfaction), make them more objective using surveys, ratings, or other statistical feedback.
What level of impact, performance or gain is necessary for the project to deliver a financial benefit?
This question is less about giving an answer that's set in stone, than about creating a framework to calculate the financial cost/benefit of the project given changing solution performance metrics, or external factors such as changing user-base or number of customers.
With this framework, you'll always be able to verify the financial viability of your project as it evolves. This will help to ensure your project has support within your organisation.
It might help to focus first on relating solution performance to financial outcomes, and then scale those numbers. For example, try listing costs and benefits of each use of your solution, and then multiply this by the number of times it is applied each month.
You may find that, for example, an automation project is only worthwhile if the error rate is less than 1%; or if it only defers 5% of samples for human review.
You might find performance "cliffs" - thresholds, where below the magic value, the solution is unacceptable to customers, and anything above is fine. Consider how to detect if you're close to these thresholds and measure carefully. Are there ways to mitigate these cliffs by e.g. adding manual fallbacks or checks? How does this affect cost/benefit?
Briefly identify key financial and reputational risks, business disruption, and change management issues that could arise from adoption of the solution.
Now that you've started to explore how the solution will address the problem, how it will provide value and the factors that determine whether the project will deliver an overall benefit or not, it's time to look at the risks involved. It's important to list all significant risks now - you're still in a position to do something about these risks!
Risks can be financial - the solution could reduce revenue, or increase customer churn.
Risks can also be reputational, which might be minor or potentially catastrophic.
Explore both the likelihood and consequences of each risk. Risks which have catastrophic consequences must be addressed, even if the chances are small.
Explicitly consider risks around solution performance, and what happens to the value proposition as performance declines.
Usually, projects will have several more likely, but less consequential risks, such as disruption to other business activities, re-prioritization of key resources, and difficulties managing change. It is worth acknowledging these here, as a reminder to address these risks in project planning and management.