I’ve attached a link to an excellent blog by Jeremy Lewis…he puts a good case to the often false distinction between change and project management. Worth a read.
- People in project management – the ultimate elastic band in terms of productivity!
- Losing knowledge, insight and trust when you need it most…leveraging the value of an exiting CEO in a deal
Jeremy Lewis makes an important distinction between Project and Change Management. My only contention is that (business) initiatives should combine elements of both Project and Change Management.
The ultimate goal of a project can be distilled down to one or both of: reduce cost or increase revenue. Compliance or regulatory changes can be categorized under the former while service or product improvements the latter. To do this requires altering the status quo, which in many industries including Financial Services, requires technology changes in complex environments.
At one extreme there are projects that become mired in administration and bureaucracy. While a Project Manager can take comfort in that they have completed all the requisite deliverables and artefacts, without a (tangible) business benefit it is most likely a waste of time and money. A tongue in cheek example of this is a Yes Minister episode where changes were made to the public health system resulting in one hospital receiving outstanding performance metrics. Never mind that this was because there were no doctors and hence no patients due to “government cut-backs”!
The other extreme is where line people are asked to implement complex changes without any formal guidance, structure or planning. This approach is unlikely to succeed because of a lack of awareness or communication of “risks… assumptions… and dependencies”. They may also have conflicting priorities and are “double hatting” so they do not have the time and/or expertise to provide suitable status updates. As someone once told me, once an issue has been escalated you no longer own this issue.
So Project Management is about the technical aspects or ‘hardware’ while Change Management is about the ‘software’ or people. Providing clarity and support as well as ensuring there is appropriate accountability are essential for end-user uptake. As Rosabeth Moss Kanter stated in her seminal book on change, The Change Masters published in 1983, there are a number of reasons why people resist change (eg loss of face). Understanding and addressing these reasons is just as important as making the technical changes.
So it is not about being on one side of the fence or the other, so much as combining the best elements of both Project and Change Management. Delivering a project that the business users do not want or accept is just as indefensible as asking people to implement complex changes without the necessary tools and expertise.
Great comment John. I agree with almost all that you’ve written, the only challenge I have is the distinction you draw between the hardware and software as you describe it! Anyone who has spent any time with me on a project knows that the thing I struggle with most is a ‘deconstructionist’ view of change management…in reality, just as the culture and behaviours of a corporate are influenced and indeed influence every aspect of the business, from systems, business processes, strategy and direction to org structure, communication channels, leadership styles etc, so good change management impacts on all the different aspects of a corporate. To achieve any sort of meaningful change, you need to find a lever (s) which may exist in wide range of activities and which may indeed be a ‘taboo’ areea…only then can you be sure that the change has the potential to stay the course.