The author of the following article is Michael Clark. Now retired, he is pursuing a lifelong interest in communication. This led him to language studies, to teaching language and contributed much to his work as a business analyst. He has lived and worked in multicultural and multilingual environments in different countries for most of his life – currently in California.
A business analyst occupies the “space in the middle”, like the center span of a suspension bridge. The user community considers you as an internal consultant. For the ICT side, as a user representative in the change management process, you are more a subject area expert than a systems analyst or software developer. You have to initiate and manage the ambivalence and occasionally the tension of being in that space. You are expected to know a lot both about the business area and the ICT supporting the business and both expect you to sort out problems with the other one.
However, tension can arise from competition in a project. No-one wants to be the cause of delay or non-performance. The importance of the middle space in the change management process grows with the complexity of a project. The larger the project, the more you need to ensure good communication and mediate between all parties, as well as help to overcome resistance to change.
I should like to illustrate how important that communication is. In one project, I was assigned to the finance unit of a field office far from the head office of a large international organization. I had to support and further the implementation of a new system requiring significant changes in the way users worked, including the approval of payments and other financial transactions reserved to managers. The chief of the finance unit found this task beneath his pay grade and gave his password to his assistant. When I made it clear this was not how the new setup was designed it led to the worst relationship of my career with a direct supervisor. To complicate matters, my second reporting line was to the project sponsor at Head Office, who also had a strained relationship with him but was his senior.
Retrospectively we did not do enough on the project to explain the rationale of the new procedures in place, nor sufficiently take into account the conditions in the field office. It was not until about 18 months later, back at Head Office, that the finance chief and I mended our relationship and he had come to understand the reasons for the new operating procedures.
Another project I worked for, related to the opening of new international offices, including Paris, saw a similar situation. As a business analyst I managed the participation of several ICT teams (reporting to the ICT director) and coordinated their efforts with those of the business side, in particular the director of the new office in Paris.
On one occasion the Paris director expressed concern at project progress and I suggested he could voice that discretely to my director. When I next saw my director, he wanted to know if I was aware of the Paris director’s concerns and what I had done to alleviate them. I was afraid he might see my efforts in supporting his teams as insufficient.
This situation gave me the opportunity to ensure both sides shared the same understanding of the importance of the project and of the deadlines ahead. The ICT side appreciated better the time-critical nature of their work, while the business side saw well how dedicated the ICT side was to the success of the project. Both sides were reassured that they shared the same goals and were equally motivated.
These projects, while all were by and large successful, illustrated in their differences the importance of clear communication during change management, the building of trust between project teams and user communities and the benefits of having team members dedicated to watching that center span of the bridge.