IT systems are usually expensive. Their implementation often costs several hundred thousand or even many millions of zlotys. When planning such an important investment, it is worth considering and planning it carefully to bring the maximum return and provide the organization with the greatest possible value.
This value can be defined very measurably, e.g., as an increase in revenue or a decrease in costs, or as something more difficult to measure, e.g., a reduction in specific risks, an improvement in the ergonomics of the working environment, or an increase in the efficiency of selected processes.
The above statement seems obvious. However, in my practice, I often see projects with an inadequately defined business objective expressed as the implementation of a specific system. Such projects are carried out from the very beginning with the assumption that the measure of their success is the implementation of a pre-selected system, regardless of what final effects this will have on the organization.
As a result, they focus only on obtaining detailed requirements, which are most often implemented only to the extent the system configuration allows.
In the article, I will show concrete examples of what to do to work more effectively.
Requirements first, solutions later
There is no point in rushing to identify the final solution. Of course, this does not mean unnecessary delay and postponing the decision-making process but preceding the choice of a solution with a reliable and correct definition of the need, requirements, and identification of available solution options. This is what properly conducted business analysis is, defined in BABOK (A Guide to the Business Analysis Body of Knowledge®):
The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.
It is also worth quoting the BABOK’s definition of need:
A problem or opportunity to be addressed.
The definition of a requirement:
A usable representation of a need.
Therefore, it is necessary to first define the need and the requirements expressing it and then, as a next step, analyze the available options and recommend solutions. It follows that the objective of an initiative should not be expressed as the implementation of the XYZ system but as a problem to be solved or an opportunity to be taken advantage of.
Why is that?
When we do not focus first on the need and requirements but go straight to specific solutions, we often lose sight of potentially better solutions that more fully meet the actual need and provide more value.
A trivial example to illustrate this phenomenon is a situation I experienced while working as an IT analyst in one of the investment banks. The team I was part of was responsible for maintaining and developing several IT systems. One day, the users of one of the systems contacted us and gave us a ‘requirement’ saying that a form containing specific fields needed to be added to the system. They also described, in detail, the place in the system where the manually entered data should go.
I purposefully put the word requirements in inverted commas in the previous sentence, as these were not requirements but a specific proposal for a solution. Following the common and well-known pattern of reasoning (no data -> entering data via a form), the system users lost sight of potentially other, better solutions. Of course, after a brief conversation, it became clear that their real need was not to have a form in the system but to be able to handle new investment products. To do this, they need specific data. Knowing this, after a short analysis, we were able to propose another, better solution involving the automatic import of the required data.
The above example is trivial, but it illustrates well the problem that can come from defining solutions too early without a solid analysis preceding them. This problem is the selection and implementation of a solution that may satisfy a real business need to some extent but is not optimal. The cited example relates to a small functionality in an existing IT system rather than the overall implementation of a new system. Still, we often fall into the same trap when implementing large and complex projects. In addition, the larger the investment, the more important it becomes to implement the best solution rather than just ‘some’ solution.
AS-IS and TO-BE
As mentioned earlier, the starting point for a specific initiative should be to define the need. This informs what we want to achieve as an organization and should be the basis for defining the business requirements.
The next step should be to analyze the current state (AS-IS), that is, the state where the organization is currently located and where the defined business need exists. Then, we move on to defining the target state (TO-BE), the state of the organization in which the business need will be fulfilled.
There are usually many possible transitions between the current state (AS-IS) and the target state (TO-BE). These may combine multiple elements and require changes to business processes, investments in staff competencies, or the implementation of appropriate IT systems. Each of the possible transitions is a potential solution option. They must be evaluated and compared, and the best one is selected.
Business Case – what is it used for?
A document that strongly supports the approach described above is the Business Case. Its development is one of the techniques described in the BABOK.
This document presents:
- the business need,
- the expected result to satisfy it,
- the comparison of the solution options that have been identified.
The solution options are rated using selected criteria. These are usually:
- costs,
- business value,
- associated risks.
The Business Case usually ends with a recommendation of one of the solutions, supported by clear and relevant arguments. Presenting and comparing the options in this form and recommending one allows stakeholders, especially the project sponsor, to make an accurate, prior-analysis decision on choosing a particular solution.
By carrying out the analysis in the manner described, defining the various options for a solution, and reliably comparing them with each other, we strongly increase the probability of selecting the optimal solution, delivering maximum value to the organization in the long term. Consequently, we ensure that our project is a success and not a costly, unnecessary, or unwanted investment that fails to deliver the expected return.
Does it work?
An argument supporting the thesis of the correctness of the described approach can be found in the example of a project carried out for one of the clients. The project concerned a pre-implementation analysis of an ERP system. It seemed difficult due to the client’s previous negative experience, who claimed that he had previously ” […] had a problem, implemented the system, spent money, and still had a problem.”
After persuasion, the client agreed that this time the project should not be strictly about analyzing the requirements for implementing a specific IT system but should be treated as an opportunity to analyze and optimize its organization. As a result, the need and the resulting high-level business requirements were defined. An AS-IS and TO-BE analysis of the selected processes followed this. This included the development of models in BPMN notation.
The final result was a list of proposed changes and optimizations for the analyzed processes and a set of requirements for IT systems that could support them. The analysis was conducted according to the ‘solution agnostic’ principle, i.e., without presupposing implementing a specific system but focusing on the organization’s requirements and expected results.
Based on the documented requirements, an RFP (request for proposal) document was created and sent to software suppliers to obtain bids. Naturally, the client received full support in analyzing the bids, selecting the contractor, and subsequently implementing the system.
The final stage of the project was to check whether the proposed changes, including process changes and the implementation of selected IT systems, had the desired effect. To this end, metrics that stemmed directly from the business requirements defined at the start of the project were developed. Based on the data collected, it became apparent that the business requirements had indeed been met and, consequently, the defined need of the organization had been satisfied.
By comparing different solution options, without an initial assumption about the choice of a particular system, it was fulfilled optimally.
***
If you are interested in the topic of Business Analytics, be sure to check out other articles by our specialists.
Leave a comment