Thursday, 27 March 2014

Managing Change Course

Last week I was in London on a three day managing change course.
My main reflection is thinking about the  Kubler Ross change curve: the course reminded me that different parts of the organisation / hierarchy are likely to be at different stages on the curve.
What does this mean for the day job?
When planning our process improvement training we need to think about the previous involvement in process improvement attendees have had (where are they on the curve?) and amend the training accordingly
*

Other learning points were:
1. Kotter’s Change model (this is an 8 step process for managing change, based around understanding the need for change, how to make the change happen and how to sustain the changes) and how it may inform a process improvement project team - we need to address all 8 steps;
2. considering ‘profiling’ our project teams using Belbin or other model so that we can make best use of people’s strengths and skills;
3. Reviewing the history of change in our organisation: how it was communicated and rewarded, and the consequences of the change, will affect how people respond to change in our process improvement projects.



*
This quote has stayed with me:
“If you want to build a ship, don’t drum up people together to collect the wood and don’t assign the tasks and work, but rather teach them to long for the endless immensity of the sea” Antoine de Saint-Exupery.
The work of the Process Improvement Unit (projects and training) needs to give people a vision of a better way of doing things and to demonstrate the benefits of continuous incremental change - make people yearn for change...


All in all quite varied training, with sufficient content to make the course interesting from a training perspective, yet with many practical uses for the day job. This week will be spent sharing some of these ideas with my colleagues - happy days.

Thursday, 13 March 2014

Selecting Projects for Improvement

People sometimes ask us how we select projects for improvement. Projects tend to be identified in three ways:
1. People come and talk to us about process problems, and this becomes a project initiation meeting. We then proceed to identify a project sponsor and scope the project.
2. Senior staff with responsibility for a specific area of work want to sponsor an improvement project in their area.
3. Observation - observing failure demand and errors, we chat to people and offer to work with them.
Identifying potential projects is just the start: lots of other factors are used to identify whether a project is appropriate for improvement. Firstly, it needs to be about process, so if there is a big policy change required, this needs consideration as to whether the policy change should happen before process improvement or in partnership. We also question whether the right process is in place, should we make it more effective and efficient or should it be replaced by something else eg do we look at the process for dealing with broken equipment or do we focus on a preventative maintenance system? Equally, if the project is only about systems development there are other routes people should follow.
Of equal importance is the people. Project sponsors play a key role in scoping a project and supporting the improvement activity, and it is very difficult to implement improvements without a supportive sponsor. The project team is also vital: getting the right people with appropriate end-to-end process knowledge. The team needs to be representative of the hierarchy, yet the numbers need to be manageable as a project team (otherwise the improvement event can become crowd control). Managers need to be supportive to allow people to be involved in process improvement, understanding that the team are empowered to make changes and allowing time for staff to undertake subsequent actions to improve processes (this can be time consuming, but it's the only way to reap the benefits of improvement).
Timing, sometimes it's just not the right time to improve a particular process either due to the academic cycle, external factors or likely staffing or structural changes. Sometimes, the opposite is a factor, all the stars are aligned and it's a good idea to to create space for improvement activity immediately. The likelihood of success can be critical when scheduling process improvement.
Another thing to think about is whether the improvement is strategically important to the institution. Of course if a process can easily be improved (sometimes called a 'just do it project') it's sensible to proceed, but ensuring that improvement activities support the strategy of the institution and are in line with KPIs is likely to reap greater rewards.
Once you have all of these things then the project scope is the next key factor. A clear manageable scope is essential, too big, the team will get caught up in problems and fixing everything will become impractical, too small or wrong scope risks wasting the team’s time, and missing opportunities for improvement.
In essence, it's really hard to get all the right ingredients to run a process improvement project. We're working on it, and learning all the time. It's really rewarding when we get it right, both for us, the project team and the greater benefits to the university. We would love to hear from other people about how they select and schedule improvement projects.