November 17th, 2009
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.
This is smart! However, it is just the beginning, please read my
next blog.