Ok gang. So the last two posts have been on documenting and then improving the steps followed to undertake an activity (yes, no matter how I try to avoid saying it, that is a process). Which means that although I had been planning to next go into the intriguing world of decision tabling, I should probably hold off for one more fortnight and go into how you ‘plan the change’.
I’ve made the executive decision not to cover how you ‘make the change’ because that is just too big, especially given the range of changes that might be required. There is no easy answer to that one and I would do every reader a disservice by trying to compress it as small as I would want to. So, for the purpose of this blog – which really is focussing on documentation and analysis rather than physical implementation – it should be sufficient to say to ‘make the change’ just ‘follow the plan’. Yep, I’m satisfied with that!
But how to go about planning the change… to be quite honest, although I’m going to run through what I would suggest would be good, solid high-level phases, I’m not particularly sold on them yet. That might be partly because this is a sequence of steps I’ve only tried to universalise in the last few days. But it is also because they are so high level that they start to seem a bit useless too. There is no mention of governance here, because that will depend on the scale and formality of the project; nor is there mention of engagement with stakeholders, cost-benefit analysis, or so many other things you might want to add in. Hmm… not sure. If you have any thoughts on whether this is a useful start or not, please let me know!
Here we go…
1. Undertake gap analysis (between the As Is and To Be states)
I’m sure this is the kind of job that would either float your boat or sink it. Depending on the level of detail you have gone into in defining the current and future states for activity steps, this could involve a huge amount of detailed analysis to work out where changes and tweaks will be needed. How much detail you go into will really depend on the exact nature of your project, business area and procedural detail. How you document it will depend on these things also. My suggestion is that a visual representation of the As Is processes overlaid with the To Be with some clear indication of what the gaps are would be the clearest way of communicating this. Coding the gaps that are indicated on these representations would create a relatively easy and navigable entry point into a matrix for the following step.
2. Prioritise the gaps
How you prioritise this will be up to you. You might what to prioritise according t risk, cost, efficiency needs, dependencies, general support for the change – or whatever you want! My personal preference for undertaking the prioritisation is to use some sort of prioritisation matrix for this type of task. Generally, I think prioritisation is a useful step though, whether now, after the next step (decide strategy/ies for addressing the steps) or both! If enthusiasm, funding / resourcing or timeframes for implementing the changes are limited, it is worth knowing up front which gaps do need to be addressed for the project to be deemed a success.
3. Decide initial strategy/ies for addressing the gaps
This is the stage at which you actually work out how you are going to address the gaps. This is where you’ll be doing some serious thinking work. Do you need to create a new system to support the new / upgraded process, or certain steps within it? What policies, procedures and supporting documents need to be defined to guide staff in how they run with the upgraded processes? Do you need to run education programs for staff – or change the composition of staff altogether? Or do you need to educate / inform external stakeholders? Do you need to purchase, upgrade, alter or move around infrastructure (be that printing paper or whole factories)? Do you need to… well we could keep going with this for a while I imagine. Let’s just say that there are a whole lot of things to consider and address and leave it there. Building on the matrix that you already have going from the previous two steps could be useful.
4. Analyse strategy/ies to identify duplications, inconsistencies and best way to deliver the package/s of changes
This is another potentially detailed deep thinking phase which – to develop the best project plan possible – will require some serious analysis. This is about analysing the different strategies that have been initially determined as the best way of bridging the gap between the current and future states, subject to the findings of this stage, and working out where the anomalies, potential efficiencies and other opportunities are in the suggested package of initial strategy/ies. This is the type of step that pays dividends later when you are actually implementing the project, but it can be easily overlooked. Good examples of efficiencies and opportunities that can be realised as a result of this type of analysis are education and communication – it looks much better and is a better use of everyone’s time if stakeholders are engaged through coordinated communications and education programs, rather than on an ad hoc basis. And in terms of addressing anomalies now rather than later – who wants to get halfway through rewriting a piece of software only to be told that it needs to change again to accommodate other process changes – which could have been picked up three months ago.
5. Write project plan/s
Hopefully a lot of the thinking work has already occurred by the time you get to this point, but here’s a final stage that will help you analyse whether you have a comprehensive plan for delivering the changes, that is broken down into deliverable chunks of work and scheduled realistically. Document your consolidated package of changes (in however many project plans have been decided as appropriate, especially if the reform project you are running is large and complex) so that a clear path forward can be understood and agreed to. Then you have a thorough, accountable, transparent way of proceeding to implement the change.
So, that’s it, subject to receiving relevant approvals and funding for getting this project a-happening, you should be all ready to start actually making the changes around the organisation. I would suggest you run the project according to whatever standard project management methodology is used within your organisation – and if there is not one used within your organisation, for goodness sake think about choosing one anyway. And keep that project plan living – don’t just ditch it once you get a few weeks down the track. Update it regularly in accordance with what is agreed by the relevant part/s of the project’s governance structure, particularly keeping track of any issues and risks that arise and then planning how to address them.
My final note about implementing a change project is a no brainer for anyone who has already tried to create change which has created ripples, big or small. In undertaking change management projects, it is important to recognise that process change will generally involve some level of behavioural change which can be tied in quite intimately with personal and cultural issues. Be aware of the implications of these types of change and try to manage them sensitively. After all, unless your process is purely handled by a system, if people don’t change their behaviours, then that process will not change.
So what do you think?
Are these high level steps a useful entry point into planning a process change project? What steps do you think are missing? I tend to think that the easiest way of doing this is through some sort of spreadsheet – is there an alternative way?