05-ph1-business_case.Rmd

# Phase 1: The business case
## Find the business case
You may find that your client already has a clear idea of possible projects. If that’s the case, then we encourage you to go through each and view them through the lens of the contextual understandings identified above. If your client does not have preconceived ideas about possible projects, then you might want to view this conversation as a brainstorming session. In our experience, the following questions can help to drive the conversation:

*  Do you have any ideas that you would like to consider?
*  If you could improve three aspects of your business, what would they be?
*  Do you have a concrete objective or are you trying to implement a more general innovation in your business?

As you drill down into specific project ideas, you should consider the practical aspects of delivering the project. For example, we often ask our clients to describe to us what a successful outcome would be, what would be acceptable and what would be outstanding. These questions can be in terms of concrete modelling metrics (such as accuracy, precision, recall, etc) or terms of business value (for instance, to save at least £10,000 in lost annual revenue from customer churn). Asking for concrete examples of outcomes can help you to get a sense of your client’s expectations and will allow you to manage these in advance. 

You will also want to understand what your client will need in terms of deliverables, by which we mean the tangible *thing* that is delivered at the end of the project. This could include items such as reports, presentations or a code-base, but often also includes more production-ready solutions such as a fully-functional software package or a deployed model or API.

Similarly, it can be useful to assess your client’s appetite for risk by asking questions such as, “If our best model is only correct half the time, would that be acceptable?”

## Define the business case
As with any scientific experiment, a critical first step in designing a data science project is to define the question and to formulate a hypothesis. To put it in slightly different terms, it is vital that all parties -- including the data scientists and the stakeholders -- agree on the project’s scope and goals. While a project brief can help identify important aspects of the work, in our experience the best results come from face-to-face conversations with everyone involved. In other words, do not restrict this conversation to a single person, but rather try to get input from every stakeholder who may be involved in the project. 

\newpage

:::{.infobox}
**A story about stakeholders**

With a client Neri once worked with, the main stakeholder turned out to be the CFO (Chief Financial Officer). Although he was in no way involved in the project, he was the one who created the budget required for the work. When asking the other stakeholders about the budget and requirements his name came up repeatedly, so we decided to include him in the next meeting. In that meeting, we discussed the scope and even expanded the scope and budget as we were finally talking to the main stakeholder. If however this interaction had not occurred, the project would have taken a completely different direction.

:::

When talking to the the different stakeholders, ask yourself whether a clear vision forms from these conversations and, more importantly, whether the different visions from the different stakeholders are aligned. When they are not aligned, it is your responsibility to align them. Find the middle ground and make compromises between the different parties. There is never going to be an infinite budget so you will always need to compromise somewhere.

In a related way, it is important to recognise that different stakeholders will almost always come from different backgrounds and have different preconceptions that can influence the way they perceive business problems and potential solutions. As a consultant, you want to take these different points of view into account, and you may even find that you have to defend your point of view as well. When talking to your stakeholders, do not be shy: understanding what the different stakeholders know and value is essential to forming a plan and ensuring that everyone is “on the same page.” In the end, clients or stakeholders will probably respect you more for insisting on going through the rigours of ensuring alignment of their visions for the project plan.

A part of your role may also be to help your client understand the principles of data science. To many non-specialists, the field may seem opaque and mysterious. While you should not view your role as that of a teacher (unless that is a specific ask of the client), it can help to give your counterparts a basic understanding of the principles driving machine learning and data science. 

In this phase, you should be focusing on the contextual and business levels. As a data scientist, it is your responsibility to make sure you and your teammates have thought carefully about what will bring value to the business and whether or not the candidate project aligns with the business strategy long-term. Fully consider how the business will change over time and what will be needed to keep this new part of the system up to date so that it can remain relevant.

Systems are in development constantly, the more you learn about the overall product and future of the product through the roadmap, the more you can use this knowledge to make your part of the system more robust. Is one of the data sources being replaced by a richer data source in future? If so how can you build your system so that this can be easily incorporated in your model when this data arrives and how will your models deal with the inconsistency in your old and new data? Writing a recommendation engine for an e-commerce site can be straightforward but how can your model use the clickstream data that will be collected in the future if you do not have this data now? These scenarios, as well as many others, can lead to technical debt in a data science pipeline. While a comprehensive review of how to minimise technical debt is beyond the scope of this article, we recommend [Managing Technical Debt](https://www.amazon.co.uk/Managing-Technical-Debt-Development-Engineering/dp/013564593X/ref=sr_1_1?dchild=1&keywords=managing+technical+debt&qid=1595912830&sr=8-1){target="_blank"}.