This diagram illustrates the stakeholder engagements involved in the development of an AI solution (note that this is essentially the same as that for creating any kind of software product).
Senior sponsors and stakeholders representing the business have the vision (and usually the funding) and are often keen to be involved in the process of setting up and defining the project. This can be great – they are engaged, keen to make
the project a success and very supportive (both in terms of time and money). However, senior stakeholders generally have an incomplete picture of the business operations and the individual roles and responsibilities on a day-to-day level. This can lead to
gaps in the understanding of what the solution is required to do, what the full extent of the tasks are that it should be able to perform, and how the solution might interact with any users when deployed.
Building relationships and consulting with those who will ultimately end up using the eventual solution is therefore vital. These individuals will likely have a more detailed understanding of the problem that the solution is being designed
to solve or address, as well as having a very clear understanding of potential pitfalls, unusual circumstances or requirements that the solution will need to successfully navigate.
It is also similarly critical to engage with those involved in the technical aspects of the business. These people, coming from an engineering perspective, will most likely add a whole additional range of potential pitfalls, unusual circumstances
and requirements that will need to be considered in the solution. Although these conversations will undoubtedly add challenges and complexities to the project, it is vital that these are uncovered as soon as possible so that they can be fed into the design
of the solution.
Having all the right stakeholders present in the initial project definition, scoping and planning is only half the battle of bridging the gap – one thing that must be remembered is a potential gap of understanding and vision. For example, as a data scientist
or other AI professional, you have been involved in previous projects, understood how they ran and what the ultimate solution looked like. Added to that, you also have an in-depth understanding of the underlying technologies – algorithmic, data and infrastructure,
as well as related areas such as UX and design. All of this together means that you are in a good place to imagine what the solution will look like and what is possible. For the stakeholders, this is unlikely to be the case, and they may well suffer from a
reduced horizon, which either means they underestimate what can be done, or overestimate the possibility of some sort of magical solution. Either is wrong and unhelpful.
As a brief aside, at this point is it worth briefly exploring in more detail our role: As the AI expert of the project, we need to act as the guide, and to get the best results for the project in these situations. When there is a reduced horizon or underestimation
of what can be done, there is a poverty of aspiration. Therefore, as the guide, you have an uphill challenge of trying to help a stakeholder imagine what the solution might look like and steer them away from something inferior which may not fully address the
business problem. Perhaps the best strategy here is to act as a facilitator, helping them to understand the impact of their decisions on the solution.
It is also important to be aware of the opposite situation found with a stakeholder, that is, the unrealistic optimism about the ‘magical powers’ of AI or Gen AI to automagically provide a solution without the problem even being verbalised (never mind systematically
documented) in the first place. This is why in the process of understanding the business problem described earlier, many steps are dedicated to teasing out information about the business problem. By gathering requirements and identifying potential issues,
it becomes easier to discuss in concrete terms what the solution might look like in these early stakeholder conversations.
However, specifically with such stakeholders, there are several recurring challenges: firstly, there are unrealistic expectations about what the finished solution might look like and what is even possible for it to do. Secondly, there may be a lack of realism
about the detail of user/solution requirements that need documenting (since it happens magically). Thirdly, and continuing with the theme of magic, there may also be a lack of understanding of how long such a solution takes to build. Taken together, this can
spell trouble for the unsuspecting data scientists or project managers. However, often the great advantage of such a stakeholder is their boundless enthusiasm. The important thing is to harness this, whilst at the same time, appropriately setting expectations
and channelling their energies in constructive ways (e.g., working with them to detail what the ideal solution would look like, how It might work, introductions to key stakeholders, etc.).
In summary, regardless of stakeholder type (and no two are the same), it is vital that they are involved in the project as it unfolds so that they can be engaged and provide ongoing feedback, ensuring that it does not stray far from what is needed by the
business.
As we have already seen, being able to clearly relate our solution – whether it is Gen AI, ‘old’ AI or anything else – to the business problem is key for the success of our project.
