SYSTEMS THINKING: GAINING AN UNDERSTANDING OF THE PROBLEM SITUATION
3.2 Description of Current Situation
3.2.4 The Existing Change Management Process
The company's Strategic Governance Council has prescribed the manner in which any change request will be processed. Due to the complexities involved and the possible serious impact that an ill-considered change could have on the company's operation and customers, the process has been enforced on all projects. Over the years that this process has been in operation, it has been expanded to cater for instances where there were unexpected negative consequences ofa change. Thus, at the beginning of the Work Allocation Project the template ofthe change request form that a change initiator had to complete was more than ten pages long. The template was split into different sections in
order to accommodate the type of change (e.g. functionality, cost, timeline, etc.), the possible cost of the change, the possible impact on other system(s) that may be affected, etc. Added to this and depending on the type of change request that was being submitted, additional forms had to be completed which were used as supporting documents to the main change request form. Thus the change initiator had to spend many hours trying to understand which parts of the form had to be completed prior to submission. As any person in the organisation may initiate a change, most change initiators were not familiar with the process and hence the completed forms would frequently be returned to the initiator due to the form being incorrectly completed, resulting in additional lost time and frustrations.
Since the project under discussion was already slipping behind schedule, the senior management ruled that they would have to sign all change requests in order to ensure that they were absolutely essential to meeting the scope and timelines of the project. Not only did this require more than then usual amount of signatories on a change request forms, but caused additional delays due to the managers not readily available. The initiator also had to motivate the (often very technical) change to the managers who did not have an in- depth technical background in the technology that was being used. The decision by senior management that they would have to sign all future change requests thus had an
unintended outcome of creating further delays to the project, increasing pressure on the resources and creating additional stress and demotivation in an already highly stressed environment. This is a prime example of management, through their actions, contributing to a possible project failure, as explained by Steyn (undated).
To make matters worse, the process and the change control template was itself changing at an unprecedented rate. Thus, in the past 4 months, it had changed 6 times. On many occasions, the change initiator found that by the time they had submitted a change request, the required template had changed and form was returned to the initiator to resubmit on a new template.
Once senior management approves the change request (which can take up to 2 weeks), it gets submitted to the proj ect change control board. If approved, it then gets submitted to the programme change board for approval to investigate. If approved there, it gets sent for approval to the company's change control board. Each of these change control boards
meets once a week, so should any uncertainties arise at a particular board meeting requiring that the change request be returned to the initiator or owner for clarification, further delays are encountered. Submitting a change request for the first time to the relevant council for consideration could take anywhere between 2 weeks and 6 weeks depending on the complexity of the change required and the amount ofpre-approvals that were necessary prior to submission. Appendix C provides an example of the steps to be taken for a typical change request.
A further source of frustration was the fact that the change initiators (usually technical people) do not enjoy administration and bureaucracy, wanting only to "get the job done".
They view the paperwork as an unnecessary formality and adding little if any value, especially since in most cases there is little option but to approve the change request.In fact, the situation was being viewed by the team as being a classic case of goal
displacement where the operative goals had become ends in themselves. Added to this is the fact that the technical people are generally in short supply and are thus under constant pressure, having to work a significant amount of overtime, sometimes for years on end. In fact, the onerous amount of bureaucracy within the organisation has a demotivating affect on the entire project team. Stacey (1993) indicates that bureaucratic control is neither rational nor efficient outside of certain limited conditions.Ithas a number of negative behavioural consequences that undermine its effectiveness. Two reasons that the failure of bureaucracy to achieve its purpose are:
a) The alienating impact that it has on people that leads to a sense of
powerlessness, isolation, frustration dissatisfaction and aggression and the deskilling people leading to trained incapacity (Blauner and Merton, cited by Stacey, 1993); and
b) The inability of bureaucracies to handle ambiguity and uncertainty and to cope with complex, unstable and unpredictable working conditions and
environments (Bums and Stalker, cited by Stacy, 1993).
The feelings expressed in a) above are evident within the project team. The result of the resistance to bureaucracy is the tacit agreement by the people not to abide by the rules, thereby giving an appearance of rationality and order. Stacey suggests that leaders need to adopt leadership styles and motivational factors that fit the situation appropriately. To do
this, appropriate feedback loops need to be installed in the organisation to make it operate like a cybernetic system.
Once all the necessary approvals have been obtained, the change request is allocated to an owner who will be responsible for obtaining the impact analysis (investigation) from the impacted parties. The impact must be documented on a prescribed impact template.
This impact study must then again get submitted to the various change control boards as described above in order to get approval to proceed with development. Once the approval is received, this information is communicated to all the relevant project stakeholders so that they can proceed with making the required change. The project change control board then monitors the progress of the change through its development and testing phases.
Once it is ready to be put into the main stream of the project, the project change control board must give approval so that it is properly coordinated.
All throughout this process, project logs need to be kept up to date and all the related documentation need to be saved in the project repository for audit purposes. The quality assurance representative assigned to the project to ensure conformance to the project management processes monitors the process closely. See appendix C for a detailed list of steps involved in the change management process for a typical change request.