Simon was wearing his genuine Mr Spock shirt circa 1972 that he had won during a recent Star Trek Convention. His ears were perfect replicas and his hair cut and combed to exactly recreate the manifestation of his hero. As the high ball approached, his arms were outstretched creating the perfect basket for the muddy ball. To Simon’s amazement he took the ball perfectly, a feeling of satisfaction was soon short lived as the approaching players stampeded across the pitch toward him. Even his replica phasor set to “kill” could not help him now…

Different groups of people reinforce their sense of belonging by having their own language, demeanour and often dress code, expressed or otherwise. These reinforcements create a barrier to entry and make it tough for members from each group to mix well in each other’s environments.

The IT Team and the Business Team are very different groups of people. Although they work for the same organisation they tend to have a very different way of working and rarely mix. The only common point of contact is the “Helpdesk”. They are often lampooned which demonstrates well the failure of these two groups to communicate effectively; one group not understanding the other’s problem whilst the other, equally, does not understand the solution.

Helpdesks are an interesting point to start any improvement programme as they are a good place to find a lot of waste activity, not the helpdesk itself, but the reasons for the calls in the first place. That point is for another time. The deeper issue is when these groups are forced together – A new IT system implementation.

IT implementations are not an “IT Project”. They are far more than that. The entire organisation may be affected either directly or indirectly. IT Teams do tend to take the ownership for the project; an admirable commitment. But one point is often forgotten, the client is not the IT Team themselves, it is the business processes, owned and operated but the Business Team. The very same team with which they rarely mix.

There is a role called Business Analyst. It is often a relatively junior role whose position it is to find out how the business works. This is an enormous task to understand the flow of materials and data, the IT interactions, the reporting, the interfaces, the risks, etc. It is even more difficult as a reasonably junior person with little gravitas operating in a group that is possibly speaking a quite different language. But this role is pivotal to the success of the implementation which in turn is pivotal to the success of the business.

The activity of Process Analysis must no longer be left to the IT Business Analyst. It requires gravitas, process understanding, unparalleled communication skills and tenacity. Further, if the team filling this role can see the future of how a process could be better, what would that mean for the future?

It would be unfair to compare the Trekkies and Rugby Teams to your business. But leaving Trekkies to ponder the space time continuum and the Rugby Team to their scrum might be a good plan. Is it time to fill the space between with a specialist team?