There are many examples of projects that have overrun budgets and timeframes, and quite often this is because of a lack of, or at least understanding of, requirements.
The choice of an agile delivery method over a waterfall approach is sometimes driven by the fact that it is difficult for customers to know what they want until they see it. However, even with an agile project, we need to help stakeholders articulate their requirements in a way that can be well understood and agreed upon.
The first step in this process is to simply listen to what is being asked. It is very easy for an architect who already has an intimate knowledge of a particular domain to think of the solution before they fully understand what is required. For example, if we know the project is to build a data-driven application, we may start from the assumption that this means an n-tier solution built from web apps and API apps.
This is a dangerous supposition; the business parlance may not align with our own understanding of the terminology. However, by ensuring we talk through the entire end-to-end requirements we can build a much better picture, and we may find that what we assumed was needed was not in fact correct.
Agreeing on the language used can be quite an important step, and in fact, part of the job of an architect may be to translate business talk into techie jargon and vice versa as we are often the go-between for different teams.
Even when we are speaking the same language, it can be difficult to articulate what we desire. Or, to put it another way, what the customer asks for is not always what they want.
A common problem is that a simple misunderstanding, or incorrect presumption, can lead to project delays or even failure as depicted here:
Figure 18.1 – What the customer asks for versus what is understood
However, there are ways around this problem. First, we should ask open-ended questions that cannot be answered with simple yes or no answers. We should also ask questions in business terms rather than technical terms.
For example, the question does the solution need to be resilient? can be interpreted in many ways, and what you consider resilient may not be what the stakeholder considers resilient.
Instead, we should ask what resiliency does the solution require? This will incite a far more detailed response and offer the business a better opportunity to explain what their view is.
Another method of ensuring we have understood a requirement is to repeat it back to the customer in your own words. Repeating what you understand in your own words helps you both see the problem from different points of view. Often this can create further dialog as you explore the problem and any potential solution.
Always keep in mind that your stakeholder may or may not understand the available technologies. As part of the conversation, we should explore the different options and explain the art of the possible. Your stakeholder may now know that a particular technology exists that could make a particular process possible, especially with the growing tools around AI and big data analytics.
It is easy for stakeholders to fall into old ways of working and simply believe that moving to the cloud means using the same tools in a different place. For example, traditional data analysis tools involved filesystems, SQL databases, and spreadsheets. When moving to the cloud, you must opt to simply lift and shift but to truly leverage the power available to us we need to explore new ways of working using tooling such as Cosmos DB, Data Lake Storage, Azure Databricks, and Azure Data Factory.
With this in mind, we need to be careful that stakeholders provide requirements, and not attempt to dictate the solution. Again, in the previous data analytics example, a stakeholder may state their requirements as a SQL Server instance and a VM running Excel. We need to tease out what they are trying to achieve and suggest alternative, more modern approaches.
We often need to capture information around common areas, which we will look at next.
Leave a Reply