From business to analysis and from analysis to design: how to bridge gaps and climb up staircases.


In typical organizations involving IT (information technology) projects, we have this split between business people, dealing with the core business concepts and operations, and an IT department making the systems evolve in order to support the business needs. That's why we seen business opportunities identified, business cases drafted, and some of them end up having some IT component.
For these including an IT component, there is usually a touch point between business and "functional analysts" of IT. These functional analysts try to shape the business requirements into a formal, trackable form so that there is scope control and a somewhat doable form of estimates. In order for this to work, the business and IT "functional analysts" must develop a productive way of working, so that they can understand each other.
Unfortunately, forming a team that delivers is faster said than done. Indeed, the team must pass through the typical steps of the staircase to make a team that delivers: Forming, Storming, Norming, Performing.
In forming, you put people together and just have "a bunch of people", who start fighting with each other on what's the best way to go (Storming), devise their ways of working trough explanations, and negociation (Norming), only to be reaching the last state (Performing) after that.
This explains why you should keep a working group together if you do not want to throw you money down the drain here and there reforming performing teams every time you need something down. "Don't change a winning team."
So, let's say we now have that performing team for business and functional analysis. So far so good. Then the functional analysis needs to be gated with the technical design guys. And these have their own agendas and issues, and areas of expertise and responsibility.
Needless to say, the functional analyst is responsible for conceptual integrity. No need to have the technical design people to take the lead on that. They can be consulted on feasibility and functional analysis may have to be amended to take limitations into consideration. But all this can only occur if the touchpoint between functional analysis and design is at the performing stage.
Which it usually is not. And thus requires going though the Forming, Storming, Norming, Performing motions once more. This could lead to the functional analyst to be caught between the hammer (business) and the anvil (technical design). Enough time and management leadership must be invested to make sure we have a communication on these processes and the need to reach the Performing level in order to succeed.
So, one staircase leading to another. The story will repeat if you are implementing the design, outsourcing parts of the work, installing the solution live, providing support. Of course, there are lots of staircases all around the place.
Usually, when a staircase is not attended do, this will lead to failure work and cascading problems, ultimately making the required system to not deliver what was expected and turning into a pile of never ending headaches.
So, the question is now: where are your staircases, touch points, parties, and current performing levels?
And also: how is leadership focusing on preventing lots of failure work from happening?