Closing the Gap between Business and IT

From almost the dawn of the age of software more than 50 years ago, there has been a communication gap between business and IT. For almost as long we have sought solutions, but they always seem to elude us.  Meanwhile, the gap has grown into a chasm that now needs a fairly substantial bridge.

From the business you may hear that ”we have no confidence in IT’s ability to deliver useful solutions”, or “we have limited visibility of progress, risks and problems”, and “we don’t know how we should measure the value of our investments in IT.”

From IT you may hear that ”they (the business) don’t fund the projects adequately”, or “they don’t know what they need”, or “they don’t know what is possible to develop”.  Each side feels the other is responsible for the problem.  And, you know, they both are right.

Over the years there have been many strategies to close the gap, sometimes going from the one extreme to the other.  Some have viewed the gap as a soft problem only:  if only business and IT could collaborate better and learn from one another the problem would be solved. Improvements in communication and sensitivity were tried, but still the gap remained.

At the other extreme people have tried to apply software technologies to describe the business process in the form of models. The result was usually a very detailed business models which could not be understood by anyone other than their creators, who were typically software people.  In reality not even these people really understood them because they usually had a flawed understanding of the business process itself.

The solution lies somewhere in between:

• We need a common, but simple, language.  Spoken languages such as English would seem simple but they are too ambiguous and nuanced to help us with what needs to be done.  Nor should we become excited about any of the many modeling languages which are understood by only a small subset of IT people.  In my experience, just 10-20% of these languages is more that enough to describe business processes.  Moreover, we should focus on describing the essentials, usually less than 10% of all the details.  The rest the IT people can take care of on their own.  This is smart!
• Of course, we need to work together but not just to learn to know one another, but to do something we can stand for together, e.g. executable code.  The era is over when one side prepares a document to an illusionary “final” status and then throws it over the wall to be implemented. We have ample proof that this does not produce good results.
• We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants.  This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.

Thus we require a strengthening of the competencies on the part of the business. The people that work with IT people need to understand how software is built in many steps based on a farsighted map.  They must be able to contribute by defining the essentials of business processes and must be able to transform these essentials into requirements in the form of use cases, etc. There is just no way around this.  It is naïve to believe that the business can avoid these capabilities.  This does not mean that they need to be experts in writing requirements, but they need to know enough to actively participate in their definition.

Of course it is equally important that the IT people understand business goals, strategies and business processes.  Software has the ability to change and improve the business processes and find more efficient ways to perform this process, but an understanding of the process is the essential starting point.