Mark McDonald

Requirements are the basis for the business and IT conversation.  Requirements form the foundation of developing IT solutions and assessing the value and contribution of IT.  So how can this be something that separates business and IT?

Simple, focusing on requirements puts two things between the business and IT.  First, it puts a language between the two – the language of requirements used to specify software specification and model solutions.  The second is that it takes responsibility for software engineering out of the hands of IT.

However, this language requires the business to translate the problems and opportunities that it sees into terms IT can understand.  What gets lost in translation separates the business from IT, particularly when the business says the system is inadequate and IT responds that it was built to requirements.

The misunderstanding and separation between what the business wants and IT provides has been the butt of many jokes – most often expressed as the different designs for tree swings shown in the figure below which was used to discuss the state of software engineering.

Communicating and understanding requirements are at the heart of this issue because the separate business from IT.  The figure below illustrates the first tow points made at the top of this post.

Requirements put a language between the business and IT that creates misunderstanding rather than brings the two together.  The misunderstanding starts with IT asking the ‘second most dangerous question” in software – what do you want the solution to do.

Seems like an innocent question, but it is asking the business to state their requirements for the solution.  Unfortunately business users are NOT trained software engenderers and this conversation shifts software engineering responsibility from IT to the business!

Now business users are smart and they will try to answer your question by translating their problems and opportunities into requirements.  Often these requirements are poorly formed, counter intuitive, in conflict with each other or technically or financially impossible.

The business thinks it is done a good job and tried to be as clear as possible, but find it hard to ask for exactly what they want.  The IT professional walks away with an idea, but there is so much the business left out.  In any case the barrier is set – IT asked a legitimate question, got a lower quality answer from the business and we are off to the races.

Requirements form a barrier because it’s a different language spoken at different levels by each player in the relationship.  If you have ever been in a country where you speak a little of their language, but not enough you understand the situation.  The business tries to speak tech, it takes business words and tries to say them with a different accent – but there is little communication and less understanding.

Iterative development approaches, like agile development, seek to address these points by increasing the frequency of the dialogue between the business and IT to get to a common understanding through rapid development cycles.  These techniques work, however they can be still based on requirements.

A better solution if for IT to retain its responsibility for solution engineering and ask the business a question in a language that everyone can understand – the language of business issues and needs.  The figure below shows this change.

Replacing that first question, with “What is the business issue we are trying to solve?” brings the two parties together and focuses them on the common issue and its solution.  The business knows its issues and can speak eloquently about them.

Business professionals can tell you how often the issue happens, its business impact, the conditions that it creates, the value in resolving them – all critical elements of a strong solution and business case.

IT professionals get the opportunity to exercise their software engineering skills and propose how to use IT to address the issue.  Once the design the concept, solution etc, they can ask, “Does this create value?”  in terms of addressing the issue.

Business professionals can then judge if the solution will address the issue.  If it does great, if not then the business can discuss the specific issues they see remaining open, including issues that they no recognize will never be addressed by IT.

The business issue is a language that both the business and IT understand and there is no reason why it cannot be the foundation of the relationship between the two parties.  Requirements remain important, but they an engineering language that often separates rather than unites business and IT.  Requirements can easily create the tree swing dilemma.  Communicating and solving business issues with technology creates business value.

This post is part of a series on the ways in which IT separates itself from the rest of the enterprise.  The first/keystone post can be found at this link

6 Comments »

Category: CIO Personal Observation Strategy     Tags: Business Management, IT and Business, IT management, IT strategy

Share

Tweet