Home �   ITIL�  Index

Risk Management -- The Relationship Between Project & Change Management

Change and project management should be viewed through the same lens, writes ITSMWatch columnist Graham Price of Pink Elephant.
Nov 5, 2010

Graham Price

Changing business requirements necessitate changes within IT and to the products and services IT provides to the business. Many of these new requirements come under the heading of changes, some are service requests and other, larger efforts require a project plan to ensure delivery. Likewise, technology advancements themselves can trigger decisions within IT that spawn changes. And, in some cases, requirements for improving existing IT management practices and services may trigger a change. Depending on the organization and the scope of these changes, many are implemented through a project management methodology.

Most IT organizations have used or practiced project management techniques for many years and with varying degrees of discipline and success. Similarly, IT infrastructure changes have been managed within these IT organizations with the same varying degree of discipline and success; each project being executed and each technical domain tending to have its own change control procedures that did not always align with those of other projects or functional areas within IT. Both the permanent IT functional groups and the temporary project teams produce changes that represent risks to IT and to the business customer.

Traditionally, this landscape of constant change has represented major challenges for all areas of IT.

Consider the project manager’s perspective: he or she is given the task of ensuring that project outputs (the products) are delivered on time and on budget. Challenges include getting, and keeping, the resources required to actually do the work, and getting the work done according to a fixed schedule that everyone is loath to change even though that schedule is quite often a little too ambitious. The project manager is answerable to the project management board, or steering committee, and must satisfy all stakeholders by delivering a timely and beneficial product. The project manager does not typically have a view of other changes being executed every day within IT and quite often has limited views of other projects and the changes they will create.

In effect, project management, as it is practiced in many organizations, exists as another silo within the organization. How many times have project managers lamented the lack of resources or the loss of resources to other more important initiatives; how often has a project deliverable been delayed because an operational break fix was in progress at the time the project deliverable was due to be installed? And how many times is the product installed only to be backed-out because some anomaly in the live environment hadn’t been noted and thus not tested against prior to release?

Imagine the project manager’s consternation when they learn that just when the new software was to be released, on time and on budget, the servers required for the release were taken offline for changes that the project manager was not informed of or consulted about.

Now consider the IT functional areas’ perspectives. How often have you heard the cry that one or another group is installing project deliverables with little or no warning to IT operations yet operations is expected to support the changes? And if there are issues with the project deliverable, any resolution required is the responsibility of operations and not the project team (in some cases that includes the cost of repairs!)

The most graphic example of the damage this causes is at the service desk where staff are often deluged with calls about new or changed services that they know nothing about because the project deliverable was installed over the weekend with little or no training for the service desk about the changes.

All of these are examples of what transpires when a coordinated effort to manage changes is lacking. One would think that having the outputs of all projects as well as all operational changes, governed by a single change authority, would be highly beneficial and greeted with zeal and excitement by all concerned. But alas, this is not so! Every stakeholder for each project and each change quite often believes that they are and should remain the final authority for their particular initiative.

That would be fine if all that mattered was the technical expertise necessary to deliver a product. But no change or project can operate in isolation, the interdependencies and impacts of each and every change, be it project driven or operational, represent risks to the services and the customers relying on those services. These are risks that must be managed -- not just from a technical standpoint but also in terms of the impact on the business itself.

So the question is how do you stop the turf war and create a single change authority that ensures all projects and operational changes are managed and executed effectively and efficiently?

We'll answer that question next week in Part II of

Dedicated to the improvement and growth of IT professionals and organizations, Graham Price is a leading ITIL expert experienced as a consultant, change facilitator and trainer. In addition to holding the ITIL Expert Certificate, Graham possesses a wealth of knowledge and experience gained in a management career spanning over 25 years in the financial services and call center industries as well as in IT service management (ITSM). Graham’s specialized knowledge of ITSM, his experience in implementing process improvements on a global and local level, combined with strong business acumen produce qualitative and measurable results for Pink Elephant’s clients.

Project management, change management, ITIL, ITSM, Pink Elephant