I used to get asked to do “change management” on projects that were not change management projects.
This is annoying if, like me, you reallylove doing change management projects, and there are so few opportunities to do really proper change management like those you read about in change management books.
The projects I was asked to work on were often the very opposite of change management projects, they were projects designed to minimise change while something disruptive happened. They were business continuity projects with the aim of avoiding the impact of changes happening elsewhere.
The most common example I was involved in was an office relocation, where you want the impact of the move to have minimal impact on the operation. You might want to take advantage of an office move to improve some things about how you work together, but the point is that they are peripheral, you are not changing how people work in order to improve your Key Performance Indicators (KPIs), and therefore, although it’s a bit change-management-y, it isn’t really driving transformation of the organisation.
If we look at an organisation’s performance over time (using the KPIs as the performance measure) then a successful organisation will probably be happily motoring around the amber/green lines most of the time.
The purpose of this type of “change management” (i.e. business continuity management) is to keep the Organisational Performance (OP) line as consistent as possible despite being buffeted about by disconnected external factors (i.e. disconnected from the KPIs, and so not central to the performance of the organisation).
How many people and organisations suffer through the process of objective setting, insisting they be SMART, and yet feel like they’re an unnecessary evil that gets in the way of the day job?
SMART is one of those cases where the acronym is so good, it takes over the whole process.
Of course objectives must be Specific and Measurable, although being measurable means that they have to be specific anyway. Objectives should ideally be Agreed, always Realistic, and adding Time-bound at the end is absolutely crucial – there has to be a deadline (I’m using the definition of SMART from MindTools).
In other words, being specific about what you want and when you want it.
The problem is that it doesn’t often work out that way.
And if we get it wrong, it can be dangerous and lead to the measure having an ineffective, or damaging, impact …
It[‘]s really easy to decide to measure something … and screw up a team beyond belief. For example, if I measure how productive individual programmers are, then it[‘]s to the advantage of individuals to focus on their own work and spend less (or no!) time helping others. Completely kills teamwork
Brian Button (Agile programmer and blogger) in “‘You get what you measure’ versus ‘what you measure you can manage'” – article no longer accessible)
So it’s worth getting it right … but it’s not so simple …
This is even more true as most things sit within complex systems and have an impact over the long-term and so can’t be easily isolated or measured within a single twelve-month performance appraisal period.