Evaluation of the process of change July 16, 2007Posted by alwilliams in Production Analysis.
From the discussions and establishment of a list of variables that affect the process of change (www.cemp.ac.uk/macmp/wiki/index.php?title=Change)
it became clear that there are many forces at work that influence both the effectiveness of the change(s) made and the ease in which change could occur. Here I have pulled out the most salient variables, which I believe have the greatest impact on what can be described as “change management”.
Time is money and places a great deal of pressure on the work environment, which results in the need for prioritisation and shifting deadlines. Embarking on Action Inquiry (AI) is likely to take more time than if no data collection and data analysis stages were included in the process. These stages are crucial, but need to be accounted for in how long they are likely to take. Some students (e.g. http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335) found that they ran out of time because they were not aware of how long the change would take to make. In this particular case the project was an addition to the existing workload and the temporal demands placed on the project leader led to the project being left incomplete. Therefore when embarking on change, an analysis needs to be made to ensure there is enough room in the diary. This also ties in with priority however where a lower priority project should be fit into the diary, whereas for a more urgent project time might be shifted around to account for its priority level.
It is simply counter productive if there turns out to not be enough time to complete a project. Time would have been spent on working on an AI for the momentum to have been lost, while waiting for sufficient time is available to complete the project. Further more it takes time to pick a project back up again, which results in more lost time. It is important to get the timescale and timetable firmly defined in order to avoid this situation.
The practical problem here of course is that the complexities of a project may not be apparent until the project timeline has been scheduled. Barriers to change may present themselves and lead to a project running over time and this occurs in projects of any kind (e.g. building the Millenium Dome and Wembley). A “Buffer Zone” should be built into the timing of the project to account for such an eventuality. Additional resource should be identified and pre-arranged so that more people can get involved and help keep the project on course. Although this is extra work and time, if the AI project is of substantial size it is an investment that could save a significant amount of time in the long run.
This aspect of change became extremely evident following the execution of the AI projects. Some chose to adopt a leadership role and ‘own’ the AI, while others took a more team-based approach. It might makes sense, on face value, for the person who perceives the need for change to lead the project, since they are perhaps the most aware of the problem that needs addressing. However looking deeper this is not the case. Most of the project leaders who attempted to champion and lead the project were not in a position of power or authority to make key decisions to move the project forward past certain hurdles on the way (see; http://www.cemp.ac.uk/macmp/forum/download.php?id=238). Due to this, unanticipated outcomes resulted, which in this case was the adoption of the implemented solution outside of the project plan. This is a problem since the use of the solution was then out of the leader’s control and data could not be collected as planned. In another case it meant that the project leader did not have enough authority to push through various decision stages, where it was held up.
If the leader had sufficient authority within the organisation to make the decisions and be able to enforce the project’s structure and process there is likely to be no problem. When this is not the case however it becomes apparent that it is better to adopt a collaborative approach, to ensure that everyone buys into the aims and values of the project. This is more likely to lead to a situation where people adopt the plan and champion it themselves. This means that if the leader needs to drop out or leave the project for whatever reason then it is likely to continue anyway. This group cohesiveness is also likely to save time and organisation. Further more if this collaborative effort includes those in a position of power, then the project is likely to have the necessary team in place to effectively execute a plan of change.
There is also the question of skill. In same cases it might take an employee on the front line to identify a problem with process, resource etc. Yet they may not be the right person to lead the project and not have the necessary skill set to lead a project. This is where it is apparent that an instigator of change does not necessary have to lead, but relinquish control to someone who will be able to see it through, while being an advocate of the project. This will result in efficiencies gleaned through using the right staff for the right job and ensuring that individual strengths are played to. Again this is embracing mutual ownership and a collaborative effort that is less likely to fail.
The Scope of Change Attempted:
This factor relates to the issues of time and resource available, as well as project ambition. As identified, sufficient time and resource (physical and human) is required in order to execute a successful project of change or AI. It is therefore imperative that too great a change is not attempted to overstretch these elements. What is available to the project must influence whether certain problems are attempted and what the solution might be for this. If too greater scope is attempted then the change is likely to fail or put on hold. Certainly the chosen problem needs consideration on this basis. Unfortunately it is often difficult to know what might be required as a solution, when looking at the problem. The solution that meets the needs of the project may exceed the available time/ resource, yet only become apparent after significant work has been complete (see; http://www.cemp.ac.uk/macmp/forum/viewtopic.php?t=335). Rather than holding the project the best solution is to compromise and work on another solution that meets the needs of both the problem and resource. This might be enough to solve the problem or provide a sufficient temporary solution until the necessary resources are available to adopt the ideal solution.
It is clear that all of these factors are intertwined and vary in their impact on managing change, depending on the context in which the change is being made. The context itself is made up from all of the influential variables listed in the Wiki including those discussed here. Early consideration must be made for the above issues in order to provide a solid understanding of the microenvironment that change is being instigated within. If one of these is not planned for correctly the project will not be efficiently executed or even worse not happen at all.