Business and IT, a LAT-relationship

In my professional career, I have been involved a lot in redesigning business process and reorganizing support functions with the main focus on the finance function. IT was then and still is the enabler to realize efficiency gains by automating processes and by providing information to the business that could be used to realize their strategy.

When we see how many intermediate persons got eliminated in the supply chain, how fast orders can be fulfilled, how quick books can be closed, that information is made available at any time and at any place, that the self-service degree for reporting increased significantly and hence the dependency on IT to build reports reduced, etc…, you might believe that business and IT make a happy couple. Reality seems, however, to be different. Talking to business and to IT, the relationship seems to be more of the living apart together kind than of the living together kind.

Searching the internet on this relationship problem, I came across a lot of articles about business/IT alignment. Some of them are of a recent date but others date back to 10 years ago. This is therefore not something new and I do not believe that the solution will be easy, but also that doing nothing is not an option. I therefore like to share my view on what my experience is on this topic at the business side and at the IT side

A common statement from the business is that developments take too long. A Gartner report of a couple of years ago stated that the average throughput time for building a report, between the gathering of a requirement and the delivery of a report, lasted 28 days. According to the same report, the actual average development time was however only 8 days. So what are the other 20 days for?

Part of the time is spend on compliance processes and the administration around these processes. Amongst the reasons for compliance are to ensure proper authorization, proper segregation of duties and ensuring that the data that is reported to the outside world reflects the truth. A number of these compliance rules are the result of accounting scandals and find their origin in SOX rules. Another reason is the fact that you cannot do developments directly in a production system as it can damage the existing applications and even result in a stop of the production system. Therefore there is a need to work in a 2 or 3 tier landscape consisting out of development/quality environment and a production environment, there is a need for unit, integration and acceptance testing and there is a need to have a controlled release via a release calendar. Last but not least, as an organization, you do not want to be dependent on a single person. Therefore there is time needed for knowledge transfer to a support organization to ensure the ongoing of the operations.

So there are valid reasons for the development time but it does not always help the business. What are the issues in the above development processes? In my view the main ones are the lack of common understanding of the requirements between business and IT and working in test environments that do not have recognizable data or do not always cover all scenarios. This then results in disappointments when the solution is delivered.

Business gets frustrated and tired of waiting and then there are inventive and creative people who create shadow solutions which on its turn creates frustrations on the IT side. The issue with these shadow solutions are that they can lead to the leakage of critical information, that they can become a critical production solution without a fallback scenario or whereby the knowledge is in the head of one person and that it gets in the way of standardization

I do not think that it needs to be this way. Automation of processes, creation of new processes and better information are the common responsibility of business and of IT. The relationship between business and IT, does not need to be complicated. Like in any type of relationship, key to the success of the relation good communication, mutual understanding and acceptance of each others roles and responsibilities.

Communication starts with a good definition and understanding of the requirements. Before a requirement is raised, the first question that should be raised is what value you will get when this solution gets built. When there is no answer, the request should not be raised because too often it starts with an idea and then IT has to come up with a cost and the business case needs then to be made. At the end, the cost needs to get reduced and finally something is delivered that does not satisfy the needs. But when the answer is there, there is already a value proposal and IT will be more considered as an income generator than as a cost.

At the development side, developers often hear the requirement but have not carefully listened and believe that they understand the requirement. You may now argue that there are the user requirements documents and they are signed off by the user. That is true but in a lot of cases, those documents are written under time pressure and are written to comply with the formal process of project management rather than for what their real purpose should be. Most of the time, they are written by IT as well and that is the wrong function for the user requirement document. The result is that the document is not detailed enough and open for interpretation, with both sides having their own interpretation. To avoid this, the user should explain the requirements to IT and IT should re-explain the requirements to the user and already highlight technical complications. Verbal communication leaves less room for interpretation than written communication and correction and adaption to what is technically possible, can happen directly and with mutual understanding. When both functions feel comfortable that they have the same understanding, the user starts to write the user requirement and IT starts to write the functional/technical documentation in parallel. The next phase is that both parties validate each others' document and align on items that are not clear or seem to be missing. This clear communication and definition of each role will lay a proper foundation for the development.

Communication between business and IT should also be about challenging and simplifying current processes. Systems also evolve and get new functionalities. Too often the full potential of a system is not being used, just because users are not aware of them. Or when new processes are defined, it starts from an incomplete knowledge of the available functionalities and hence processes are set up more complex than what they should be. Therefore this is a role for IT to make sure that the functionalities of a system are clear within the whole organisation and a role for business to challenge current processes and check with IT if the full capability of a system is used.

Another example about roles and responsibilities has to do with the upcoming of self-service tools. They make the business becoming less and less dependent on IT to build reports. In building the reports, the business does not want to follow the 3-tier landscape because that takes too much time for an ad-hoc analysis. Therefore the business needs to be able to access the productivity data directly. IT however argues that there is then a risk for the single source of truth. This is therefore a question on who owns the data and it is not IT who does. Ownership of the data and therefore defining what the single source of truth is lays with the business. IT owns the system and is responsible for making sure that a controlled environment in which the business can access production data is available, that the data is stored correctly and timely, that it is safeguarded, that there is no duplication, that the data can be accessed by authorized people only and that it is available on multiple devices. However, this direct access to production data should only be to a limited number of people and the ad-hoc analysis report should also only be temporarily available on the system. Otherwise the system gets overcrowded by unused reports. When from the ad-hoc analysis appears that there is a need for a standardised report, it is the role of IT to develop this report and the ad-hoc analysis report will serve as documentation of the user requirements. IT can then judge if there is already a similar existing report and challenge the need for the new one and hence ensures that there is no duplication.

I am convinced that business and IT can make a great team together and that simplification, better communication and better understanding of the roles are steps in the right direction. McCoy & Partners strives for simplification and our consultants always act on the cutting edge between business & IT. Feel free to contact us in case you like to receive more information.