Our new change triangle is now a double triangle as follows:
The double change triangle™
What this means is that
- if you are considering change you need to consider all seven dimensions.
- when you look at your change management processes they need to explicitly acknowledge and deal with each of the seven dimensions
- you need to be able to assess and address each of the seven dimensions in making change.
More experienced practitioners will immediately see why their people-process-technology approach to change has left holes and not delivered the desired smooth or effective change at times.
For example, a project to realign and restructure a department can involve
- Strategy — how does this impact or is it impacted by the strategy? Is it consistent?
- People — who is impacted and by how much? Are they up to the new changes?
- Structure — what will be the new structure and specific accountabilities?
- Infrastructure — what new space, equipment, physical networks, etc will be required?
- Information — what changes to the information/reporting/measurement flows will be required?
- Processes — what processes will change, how and why? What systems changes are required?
- Culture — how will this challenge the mindsets and belief systems? How radical a change is this to the current ways of thinking?
Trying to achieve just an organizational change without all seven dimensions is a recipe for disaster.
What do you think? Do you think the P-P-T triangle meets all of your needs? Comments to the blog
© Jed Simms, Australia, 2009
No tags for this post.
I have managed by the people, process, technology triangle for some time. Although many people talk about it, there still does not seem to be enough emphasis on people and process in most software projects.
As we focus on people and process, the organizational structure and roles and responsibilities naturally come out. The culture and learning requirements also become critical. Too much emphasis is placed on fire hose training.
In change projects, executive buy in is identified as a key issue. This is simply an issue of goal or strategy and communication. If the executive has not defined and communicated the strategy, the project will encounter problems.
I like your diagram. It brings all of the elements into focus in a very simple diagram.
Thanks Marc
I agree that too often on software projects “change management” is relegated to getting people familiar with and able to use the software, full stop. Then we wonder why we don’t get the value!
My earlier worldwide research into the drivers and destroyers of project delivery success found that ‘change management’ was universally the worst performed dimension of project delivery. Now we know why
JED