Calculated surprises – change management in projects

Why change management? Targets

The change management process should ensure that changes are made in an structured way (if possible) and the impacts on the project are taken into account. Not to be mistaken with the risk management, where it is a question of identifying potential risks and taking measures to either avoid them or deal with the effects.
The tagets of the change management are thus summarized:

  • Realize changes early
  • Create transparency for all involved in the project about changes and their effects
  • Establish decision-making and approval rules
  • Genereate a climate for open handling of changes so that they are not kept secret

Causes

Why change management? If I define a process for dealing with unplanned changes, don’t I just invite for changes?
No, because often you cannot avoid changes as they are not in the area of influence of the project manager or project team:

  • Legal requirements change
  • The requirements of the customer and thus the targets and delivery objects of the project are changing
  • Price increases force a re-calculation of the project
  • Delivery problems of a subcontractor make the schedule to waste paper

The list could be continued as desired, each project manager knows enough examples from his environment.

Handling of changes

Now you can say that there is no cure for such changes anyway, and that it is only necessary to deal with them when they occur. This is right and wrong at the same time. In fact, it is sufficient to consider changes only when they occur. But the question is how to handle them. This handling can e.g. include the following steps:

  • Realize changes and their root causes
  • Analyze the effects on the project
  • Update the project plan
  • Get approval from the project sponsor and steering committee
  • Communicate changes to the project team and all stakeholders

Depending on the frequency and effect, such process steps must be aligned with the requirements of the company. According to the range of changes, different escalation or decision-making levels could be necessary.

Is there a change culture?

Certainly it would be too extensive to talk about an explicit change culture (although there may be exceptions). Better is the concept of a culture of directness. A deadline delay of a work package e.g. can be caught up in the overall project, if there is an early reaction. Here, the project manager is requested to create this directness in his team. This is particularly challenging in complex environments, e.g. with external partner companies. A culture of directness can only work out together with a “positive culture of error”. Errors are a great opportunity to learn and improve – as a person, as a team and as an organization.

Practice

After the process steps were defined in the first step, the practical implementation has to be clarified. Some companies are using a change control board where changes are presented, discussed and decided. It’s another question if such a separate board is necessary, because usually it is the same group of people that decide about project changes and new projects. In most cases, the Project Steering Board (or some differrently named board in the company) can also decide about changes.

This board should be able to decide about changed schedules or higher budget without having to call another board. The information should be provided in a structured and comprehensive manner so that decision can be taken. A formal change project seems reliable that describes cause, effects and necessary plan adjustments (deliveries, results, dates, budget etc.).

Implementation in KLUSA

You can map change management in KLUSA. For this purpose, you can enter a change request. The change request contains a description of the reasons as well as the new planning. KLUSA clearly displays the delta between the last approved plan and the new plan so that you can immediatelly see deviations from dates, costs, etc.

A workflow controls the steps of the change request in KLUSA:

  • The project manager creates and prepares a change request. KLUSA displays the delta between the last approved plan and the new plan.
  • After re-planning, the project manager requests the change request for approval
  • An authorized person can approve the change request in KLUSA. A new approved plan is saved.
  • All data of approved plans with their history are available for later evaluations (Lessons Learned).

With this easy-to-use solution, KLUSA supports any project organization without overflowing requests and inputs. We are looking forward to demonstrate this KLUSA function and answer your questions.

Share this entry on