Change Managemt Process

Change Management and dealing with changes is a key project management function for any industry. There might be enormous variance in efforts, cost, schedule, quality of deliverables if changes are not handled effectively. Many projects are delayed and many other are closed (terminated) because project managers were not able to manage changes.

Introduction

Change management and dealing of with scope or requirements change is an importance function of project managers. However clear the requirements are, whatever the tool used for documenting requirements ( right from Rational tools to Word document ) and whatever the category of execution model ( Pure Waterfall to evolutionary prototype ) requirements are bound to change. The only difference to change is to what extent, and what is the impact on project success or failure. Having said this successful execution of any project relies on how good and effective is your change management mechanism.

This is the reason why Monitoring and Controlling Process Group ( Section 3.2.4 of PMP handbook ) is such an important section.

Why Requirements Change?

There are a number of reasons for change in requirements and these reasons depend on multiple factors like:

Industry: Is the project related to Automotive or Aerospace or Jewellery

Geography : APAC customers are precise in their requirements compared to US or European Customers ( Based on the project execution experience I have on multiple engagements )

Customers: Customers maturity

Implementers: Experience of implanters with the same customer or similar customers or projects

Execution Model: Fixed Price project executions model demands requirements to be crystal clear. So efforts taken on such projects to control scope are more compared to Time and Material or other models.

But whatever the reasons, the result is the same "Customer Dissatisfaction" or "Project Failure" in terms of:

Schedule Variance: Failed to meet committed deadlines

Cost Variance: Customer paying for changes or implementers bearing the cost impact affecting their bottom line.

Quality: Not able to meet desired quality goals or metrics

Although there can be number of other reasons this paper will limit its scope to IT projects (more inclined to product implementations to meet customer needs )

Considering this scope I will consider few major reasons of requirement changes:

Customers:

Customers new to the Digital World

Customers who are mostly moving from a manual system to a digital systems (Example: Product Life Cycle Management ( or Product Data Management ) systems like MatrixOne from Dassault Systems or TeamCenter Engineering from Siemens or PDMLink from PTC) .

These customers normally fail to understand that their entire process cannot be replicated in the new systems. If you are developing new inbuilt system for your own business transactions then you can fine tune the system as per your requirements. But if you are using some product for your business process mappings there are few critical decisions they have to take to define a solution. Customers have to

Follow process defined by basic product (Out Of the Box - OOTB features). You may need to change some of your processes.

Maybe you may have an Engineering Change Request ( ECR ) process coupled with Engineering Change Order process ( ECO ). If OOTB product is providing a separate ECR and ECO process, and it has some benefits, you should explore the option of revising your Change Management process framework.

Change OOTB process to fine tune their requirements (Configure or Customize the product).

Your ECO process may have different workflow compared to OOTB product process. This means you need to configure or customize the product.

Change product process as per your own process (Heavily customize the product. Sometimes this is over kill)

Your existing change management process does not match to OOTB process so you may have to develop a separate module to overcome this process gap.

These customers sometimes fail to map their requirements. Some customers we have seen instruct System Integrators (SI's) / development team to exactly replicate the manual system without understanding the benefits of new system. Such projects are a nightmare for project managers as requirements keep on changing slowly as they realize these issues at a later stage of execution. Issues such as:

Technical issues on implementation

Realize product features and related benefits after some time

Performance issues due to heavy customizations,

We need to be extra cautious to deal with such categories of customers and some of the steps to avoid such problems can be:

Document the manual system

Features demonstration of new system if it's a product with key end users and IT staff to get their buy in on OOTB features.

Gap Analysis ( What they want and what new system can give )

Convince them for some of the gaps where they need to fine tune their process in terms of efforts required for development and maintenance, performance, technical limitations. (with reference to best practices followed in industry)

Develop a prototype solution and get a feedback

Preferable follow an "Evolution Prototype" model for project execution where you get a set of requirements, develop, implement, test, get user feedback, refine solution and then define new sets of requirements. Avoid following RAD (Rapid Application Development) model. It's a big risk unless you know your customer well.

Matured Customers

These set of customers are those who have already gone through one cycle of digital systems and know the benefits of new systems. Also they understand possible hurdles for these projects. Few of them understand the importance of