Revision as of 11:23, 28 September 2015

Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited.

Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.

An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.

This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:

Cost of changes

Figure 1.Traditional cost of change

To avoid increased cost it is important to analyze and deal with possible project changes ^[1]. If the project team doesn't have a clear plan for how project changes are handled, the changes could be implemented to late or not being implemented at all.

In figure 1 it is shown how cost of change grows over time ^[1]. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.

In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief.

Division of the project in well-defined phases The project should be divided into various phases. For each of the phases the deliverables should be clearly agreed and documented. A project phase should not be started before the previous phase has been completed and signed off. Typically the phase’s conceptual design, preliminary design and detailed design should be used. If these phases are used the project organisation will agree the project design in a three step approach. This will ensure that all project parties agree to the project design step by step allowing sufficient time to agree the solution design and thus ensuring that changes to the design will be done as early as possible.

Control of the project basis The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.

Project reviews Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.

Process of project changes

Figure 2. Process of project changes

As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.

Below is an illustration of a generic project change management process ^[2] that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.

The model is divided into two key phases:

• Initiation and planning
• Implementation

The initiation phase should begin prior to the start of the project to ensure that the expectations to the project deliverables and the approach to handling project changes are aligned between the customer and supplier. The initiation phase has two overall activities that are marked by a red circle and the numbers 1 and 2.

1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.

2) The second activity will take place after the expectations to the deliverables and the project change management process is aligned between the customer and the supplier. The supplier project team will have a meeting ^[3] lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.

The implementation phase will begin when the project starts and in this phase potential project changes will be identified and the customer will decide if the project change should be initiated. Finally, there will be continuous follow ^[3] up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.

3) In the third activity the ongoing potential project changes will be identified and collected during the monthly meetings in the project team. As the project goes ahead there will continuously be identified potential project changes and these will be discussed in the project teams. To have an overview of all the possible project changes a change register will be used as seen on figure 2.

All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a Gantt Chart can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.

4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.

As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a "Project change decision process" is inserted. The process in described in more detail below.

5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.

Project change decision process

Figure 3. Project change decision process

As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders^[3]. A model to handle the project change decision making process can be seen in figure 5^[2].

A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view.

The best position to be in is when the project change is placed in the green box in the upper left corner where the value will be increased and the cost will be decreased. In this situation the decision to implement the change should be a no brainer. The project change should be implemented unless there is a time issue.

The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.

Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?

Below are examples of different types of project objectives and stakeholders^[4] that a project change can affect.

Effect (e.g.): Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.

Stakeholders (e.g.): The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.

Negotiation of project changes

When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process ^[2] that consists of 6 phases:

• 1) What is the project change?
• 2) What are the suppliers and the customers alternatives?
• 3) What are the suppliers and the customers interests?
• 4) Negotiation variables
• 5) Prioritisation of each negotiation variable
• 6) Plan dialogue and negotiate

1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do Stakeholder Analysis to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders.

2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.

3) In this phase it must be clarified what interests that the customer and the supplier have. Interests must be understood as what the underlying causes of the positions are. Then it will be possible for the customer to find underlying and hidden interests which will make it easier to understand the customer and thereby create a better negotiation. It is important to remember that not all interests are specifically expressed in the contract. Further, some interests are rational and some are emotional.

4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.

5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.

6) In this phase the final dialogue and negotiation with the supplier will be planned before the final negotiation. Here it is very important that all the information and decisions from the five earlier phases are finished and ready for the future negotiation. Furthermore, it will be a good idea to define a starting point, target and pain threshold for each negotiation variable. Finally the supplier must consider the situation from the customer’s point of view. As a minimum the supplier must consider the reaction of the supplier and what types of scenarios that may arise when the negotiations have begun.

Limitations

Conclusion

Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.

References

1. ↑ ^{1.0 1.1} Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. "Examining the Agile Cost of Change Curve"
2. ↑ ^{2.0 2.1 2.2} Søren Vestergaard Andersen, Director of Business Process Management, Sveko
3. ↑ ^{3.0 3.1 3.2} Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013
4. ↑ Guidance on project management. 1.th edition, Danish Standards 2012

http://www.agilemodeling.com/essays/costOfChange.htm http://www.wisegeek.com/what-is-product-change-management.htm http://www.computerweekly.com/opinion/Five-tips-for-managing-project-change-requests http://www.dummies.com/how-to/content/how-to-manage-project-change-requests.html http://cobaltpm.com/effective-project-change-management http://4pm.com/change-requests-4pm-com