Monday 4 August 2014

Unifying Technical Project Management with Management of Change

One of the things that successful leaders of improvement initiatives understand is that at least 80% of the effort is about managing change. It is often something that their sponsors and supervisors also understand.

So, when you pick up a book about process improvement, you’ll generally find extensive information about understanding the psychology of change, managing resistance, winning hearts and minds and communication, and all the other ‘soft’ skills that will help you succeed. You probably won’t find a huge amount of information about writing a process. (If you think about any of the CMMI reference books there are very few pages about creating a process, although to be fair you won’t find many pages about managing change either, so maybe that’s a bad example!).

In PRINCE2 a project is “a temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case”. According to PRINCE2, projects are the means by which we introduce change into an organisation. But, pick up a book on PRINCE2 project management and you’ll hardly ever find anything about managing change, other than standard scope and change request management. What you’ll usually find are all the specific technical details about project planning, monitoring and control.


If you are creating a new product or even introducing a new off-the-shelf solution within an organisation there is a significant element of change. People will probably have to adapt their way of working. They will need to understand how the new solution integrates with existing systems and processes. They will have to understand the new expectations being forced on them through the change.

Yet, in my experience, this element of the work is rarely considered as anything other than an afterthought, and technical project managers who lead these projects are often lacking the skills required to successfully implement the change. They may deliver the product, sometimes within budget and time constraints, sometimes not, but they don’t deliver an integrated and working solution to the original problem.

The result is that staff now need to spend a considerable amount of their time trying to adapt to the change without the necessary understanding, guidance, processes and tools or even the context for why the change has occurred in the first place.

When organisations begin to understand that technical project management alone cannot meet the requirements of delivering a working solution to a problem, and learn that the end users who are closest to the work are the ultimate stakeholders, projects will continue to fail to deliver against the expectations initially set for them.

Businesses need to follow the patterns set up by change practitioners whereby technical project management skills and management of change skills are interwoven throughout the project management process, and not simply bolted on when it is already too late, or worse, ignored completely.



Print this post

No comments:

Post a Comment