Management of Project Change

From apppm
(Difference between revisions)
Jump to: navigation, search
 
(126 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Management of project change is to handle changes in a company´s projects and is a very difficult thing to handle. The changes may occur because of new changes in the organization or maybe the customers has requested a change in the product or a new service. This article will address product change and new services. An example of a project change could be a company that are building an administration building and six months in the process the customers suddenly also want a underground parking. Now the company has to change the project so the additional cost can be minimized and the project still can be built on time. To handle such changes require experience and planning.
+
''Developed by Andreas Vestergaard Andersen''
  
−
In this article, the following topics will described to give the reader a better understanding how project changes can handled in the following order:
 
−
* Cost of project changes
 
−
* Process of project changes
 
−
* Project change decision process
 
−
* Discussion
 
−
* Conclusion
 
  
 +
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 experience handling project changes are limited.
 +
 +
Project changes may occur due to various reasons. Introduction of new authority requirements, new or changed needs and 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 is building an administration building for a customer and six months into the process the customer suddenly also wants an underground parking facility. 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 an 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 box below:
  
 
= Cost of changes =
 
= Cost of changes =
−
[[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 2.Traditional cost of change]]
+
[[File:Traditional cost of change curve 2.gif|500px|thumb|right|Model 1.Traditional cost of change]]
 +
To avoid increased cost it is important to analyze and deal with possible project changes <ref name="Article">'' Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. [http://www.agilemodeling.com/essays/costOfChange.htm"''Examining the Agile Cost of Change Curve''"]''</ref>. 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 Model 1 it is shown how cost of change grows over time <ref name="Article">'' Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. [http://www.agilemodeling.com/essays/costOfChange.htm"''Examining the Agile Cost of Change Curve''"]''</ref>. 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 <ref name="Article 5">Wallace, Simon. Scope & Change Control, The ePM book''. [http://www.epmbook.com/scope.htm"'' Scope & Change Control''"]''</ref>. At an early stage a project change has limited consequences 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 been produced or delivered a project change will lead to costly rework.
 +
 
 +
In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most efficient and often used 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 and only within the individual phases.
 +
 
 +
'''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 customers 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 allows the project team to design an efficient project review structure <ref name="Article 4">Tom Mochal. Use gate reviews to validate that you´are ready for the next phase of your project. Tech Decision Maker, 2008''. [http://www.techrepublic.com/blog/tech-decision-maker/use-gate-reviews-to-validate-that-youre-ready-for-the-next-phase-of-your-project/"'' Use Gate Reviews''"]''</ref>. 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 reduction or early identification of project changes.
  
 
= Process of project changes =
 
= Process of project changes =
−
[[File:Process of the project changes.png|500px|thumb|right|Figure 1. Process of project changes]]
+
[[File:Process of the project changes new.png|550px|thumb|right|Model 2. Process of project changes]]
−
As mentioned earlier, there are many different ways to handle project changes. Each company has their own model for project change and to illustrate how project changes can be handled, a model from a company will be used to describe how the project change can be made. In this case the model from the company Sveko will be used, which is a consultative construction company. The model can be seen at figure 1.
+
  
−
The model is divided into two big phases that are:
+
As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project have a model for how the project changes should be handled. In worst case no model is in place and the project change management process is not clear to the parties involved. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.
−
* Initiation and planning
+
−
* Implementation.
+
  
−
'''The initiation phase''' will begin before the start of project to ensure that the expectations of potential project changes are aligned with the customer and supplier. The initation phase has two overall activities there are marked in the two red circles with a 1 and 2.
+
Below is an illustration of a generic project change management process <ref name="Person">''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''</ref> 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.  
  
−
1) In the first activity there will be a meeting with the customer and the supplier. In this activity it is very important that the benefits and process of change management will be determined. One of the biggest mistakes in projects is when expectations are not attuned to possible future changes in a project. When there is consensus and clarity of the possible future project change, the project group meeting will find place in the second activity.
 
  
−
2) In the second activity the supplier has now determined the benefits and process of change management with the client. Therefore the company will have a meeting with the project team to clarify services, delivery process and possible project changest that adresses the customers need that was determined in activity one.
+
The model is divided into two key phases:
  
−
When activity one and two are completed, then phase two can be startet.
+
* Initiation and planning
 +
* Implementation
  
−
'''The implementation phase''' will begin when the project starts and in this phase potential project changes will be identify and afterwards the customer will make the final desicion on the change to be made. Finally, there will be continuous follow up on the project. The initation phase has three overall activities there are marked in the three red circles with a 3, 4 and 5.
+
'''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.
  
−
3) In the third activity the ongoing potential project changes will be identified and there will be monhtly meetings in the project teams. As the project goes ahead there will continually be possible project changes and these will be discused in the project teams. To have an overview of all the posible project changes a change register will be used as seen on figure 1. All the information about the different types of changes will be listed in the change register and be used on the meetings and for the customer.
+
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 to project deliverables and handling of project change are not aligned. 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.
  
−
4) In the four activity there will be a meeting between the customer and the supplier where the potential project changes will be showed to the client. Here it will be assessed if the project changes has to be implemented or not. It can be very diffucult to choose between the different types of potential project changes and therefore the desicion making about a project change will be detailed described in the section xxx.
+
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 <ref name="Book">''Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''</ref> 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 customer are understood. Finally, the project team members jointly identify the possible areas for project change in order to have a common understanding of these. This will ensure greater project change awareness during the project execution both on a conceptual and a detailed level.
  
−
5) In the five the activity there will be follow up on the execution of the project changes and its economics and estimation of time. Furtheremore there will be monitoring and monthly budget updates thus that the estimated time and cost will be met.
+
'''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-up <ref name="Book">''Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''</ref> of 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 <ref name="Blog">Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log "'' More on Change Management – The Change Log ''"]''</ref> will be used as seen on model 2.
  
−
= Project change decision process =
+
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. The project changes should be reflected in the project plan which normally is done as a [[Gantt Chart]]. 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 customer and in the project teams.
−
[[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]
+
  
−
As mentioned earlier, it can difficult to choose between which project changes that should be made. Often is there a tight deadline and therefore it is not necessarily all project changest that can be performed. Therefore it is important to choose the most important project changes. The model to handle the decision proces can be seen at picture 2.
+
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 it will 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.
  
−
The model is divided into three phases that are:
+
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 is limited. Consequently, a decision model can support the decision making process. In model 3 a "Project change decision process" is inserted. The process is described in more detail below.
−
* Project changes
+
−
* Value for money (value and cost)
+
−
* Effect
+
  
−
'''The Project changes phase'''
+
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 that the time and cost estimates are met.
−
In the first phase it must be assessed what the possible project change we should consider to implement is and why we should implement it.
+
  
−
'''The value for money (value and cost) phase'''
 
−
In the second phase it must be assessed what value the change will bring and what it will cost and how the focus should be to ensure maximum value for money for the change. Figure 2 shows a matrix where the value can be seen at the y-axis and the cost 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 place to be in the matrix is in the green box in the upper left corner where the value will be increased and the cost will be decreased. The place we not would be is in the red box in the lower right corner where the value will be decreased and the cost will be increased.
 
  
−
'''The effect phase'''
+
= Project change decision process =
−
In the third phase it must be assesed what the effect of the change is and if it does deliver added value in relation to the project objectives for the stakeholders. The effects has to create value for the project and therefore it is positive thing if the project change contains most multiple effects as possible. The project change should result in an effect that benefits the project. Furthermore it is positive if the project change are affecting more stakeholders in a good way than before the change of the project.
+
[[File:Project change decision process.png|550px|thumb|right|Model 3. Project change decision process]]
  
−
Different types of effect and stakeholders that a project change can effect can be seen below.
+
As mentioned earlier, it can be difficult to choose between the project changes that potentially 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<ref name="Book">''Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''</ref>. A model to handle the project change decision making process can be seen in model 3<ref name="Person">''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''</ref>.
  
−
'''Effect (e.g.)'''
+
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 cost and value (cost benefit) point of view.
  
−
• Time
+
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.
  
−
• Quality
+
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 requires a project change. Then this change can’t be deselected and the strategy is then to minimize the cost and the value decrease.
  
−
• Future proofing
+
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 matter of the customers perception based on various rational and emotional parameters that can differ a lot.
  
−
• Sustainability
+
To come closer to deciding on the value of the change there are some fundamental questions that should be raised. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach a conclusion to these questions and to balance the two-dimensional answer it is important to have a clear objective and understand the stakeholder’s value perspective <ref name="Article 3">Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ "'' How to manage change order requests ''"]''</ref>. That is why project objective management and stakeholder management are very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you then decide when to accept a project change?
  
−
• Brand and image
+
Below are examples of different types of project objectives and stakeholders<ref name="Booklet">'' Guidance on project management. 1.th edition, Danish Standards 2012''</ref> that a project change can affect.
  
−
• Health and Safety
+
'''Effect:''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.
  
−
• Etc.
+
'''Stakeholders:''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.
  
−
'''Stakeholders (e.g.)'''
+
=Negotiation of project changes=
 +
When the proposed project changes are completed, they have to be disclosed to the customer 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 <ref name="Person">''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''</ref> that consists of 6 phases:
  
−
• The Client
+
* 1) What is the project change?
 +
* 2) What are the supplier’s and the customer’s alternatives?
 +
* 3) What are the suppliers and the customer’s interests?
 +
* 4) Negotiation variables
 +
* 5) Prioritisation of each negotiation variable
 +
* 6) Plan dialogue and negotiate
  
−
• The Clients’ clients
+
1) In this phase the type of the project change must be identified and it must be investigated what the contract states. This makes it easier for the supplier and customer to negotiate the project change. 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.
  
−
• Users
+
2) In this phase it is important to be clear about what alternatives the supplier has and what alternatives the customer has. If the customer has few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer have many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.
  
−
• Authorities
+
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.
  
−
• Suppliers
+
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 financial elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation it will be possibly to end up with a better outcome for all parties involved.
  
−
• Society
+
5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and which should not. What is important and what isn’t? These considerations should be done both from a supplier and a customer perspective.
  
−
• Shareholder and investors
+
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 =
 +
Limitations in use of the above models can be that the contract between the customer and supplier is structured in a way that the models can’t be used. Other project change management processes can also be dictated by the contract. Furthermore, successful project change management requires supplier access to customer information and employees. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require that the meetings needed to discuss and clarify must be changed or it can be difficult for the project team to handle. Also lack of access to the supplier and customer employees with authority to agree and negotiate project changes is a problem when using the above models. The models are somewhat complex and often only applied to large projects. For smaller projects the models are also powerful but should be scaled down. But it is import to stress that the models are scalable.
  
−
• Etc.
+
= Annotated bibliography =
 +
'''For further reading is it recommended to read the material below:'''
  
−
= Discussion =
+
* Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.
 +
A very good article that describes some of the elements from the book "The Object Primer, Agile Model-Driver Development with UML 2.0". It gives a good understand of how cost changes over time and shows the different between traditional cost over time and for example cost over time for software development. Furthermore, the article describes why it is important to work closely with the stakeholders and gives a good insight in the feedback cycles that are the most effective and financially best.
 +
 
 +
* Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.
 +
This is an excellent book to understand the different elements in project management that in several areas also can be used in management of project change. The book describes all the different types of stakeholders, how to create a project team, how to prepare a work schedule for a project etc. The book also reviews the different aspects of communication in a project group and why communication is a very important factor in group teams. Furthermore, the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. In general this a very good book that also is used in one of the courses at DTU.
 +
 
 +
* Wallace, Simon. Scope & Change Control. The ePM book.
 +
An article that very detailed describes Scope and Change Control. There is a lot of definitions of different types of project change related keywords like Scope change, change control, change programme etc. Furthermore, it describes very well different forms of change drivers for a customer such as business needs, new business partners and channels, globalisation, standards etc. Finally, the article gives a good understanding of a project change from start to finish and also illustrates theory and methodology.
  
 
= Conclusion =
 
= 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 not only improve the project results but also the competitiveness and financial performance of a company.
  
 
= References =
 
= References =
  
−
http://www.agilemodeling.com/essays/costOfChange.htm
+
<references />
−
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
+
−
 
+
  
−
----
+
[[Category:Uncertaity]][[Category:Change Management]][[Category:Project Management]]

Latest revision as of 17:38, 18 December 2018

Developed by Andreas Vestergaard Andersen


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 experience handling project changes are limited.

Project changes may occur due to various reasons. Introduction of new authority requirements, new or changed needs and 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 is building an administration building for a customer and six months into the process the customer suddenly also wants an underground parking facility. 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 an 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 box below:

Contents

[edit] Cost of changes

Model 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 Model 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 [2]. At an early stage a project change has limited consequences 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 been produced or delivered a project change will lead to costly rework.

In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most efficient and often used 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 and only within the individual phases.

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 customers 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 allows the project team to design an efficient project review structure [3]. 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 reduction or early identification of project changes.

[edit] Process of project changes

Model 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 have a model for how the project changes should be handled. In worst case no model is in place and the project change management process is not clear to the parties involved. 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 [4] 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.


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 to project deliverables and handling of project change are not aligned. 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 [5] 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 customer are understood. Finally, the project team members jointly identify the possible areas for project change in order to have a common understanding of these. This will ensure greater project change awareness during the project execution both on a conceptual and a detailed level.

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-up [5] of 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 [6] will be used as seen on model 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. The project changes should be reflected in the project plan which normally is done as a Gantt Chart. 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 customer and in the project teams.

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 it will 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 is limited. Consequently, a decision model can support the decision making process. In model 3 a "Project change decision process" is inserted. The process is 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 that the time and cost estimates are met.


[edit] Project change decision process

Model 3. Project change decision process

As mentioned earlier, it can be difficult to choose between the project changes that potentially 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[5]. A model to handle the project change decision making process can be seen in model 3[4].

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 cost and value (cost benefit) 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 requires a project change. Then this change can’t be deselected and the strategy is then to minimize the cost and the 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 matter of the customers perception based on various rational and emotional parameters that can differ a lot.

To come closer to deciding on the value of the change there are some fundamental questions that should be raised. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach a conclusion to these questions and to balance the two-dimensional answer it is important to have a clear objective and understand the stakeholder’s value perspective [7]. That is why project objective management and stakeholder management are very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you then decide when to accept a project change?

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

Effect: Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.

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

[edit] Negotiation of project changes

When the proposed project changes are completed, they have to be disclosed to the customer 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 [4] that consists of 6 phases:

  • 1) What is the project change?
  • 2) What are the supplier’s and the customer’s alternatives?
  • 3) What are the suppliers and the customer’s 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 investigated what the contract states. This makes it easier for the supplier and customer to negotiate the project change. 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 has and what alternatives the customer has. If the customer has few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer have 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 financial elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation it will be possibly to 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 which should not. What is important and 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.

[edit] Limitations

Limitations in use of the above models can be that the contract between the customer and supplier is structured in a way that the models can’t be used. Other project change management processes can also be dictated by the contract. Furthermore, successful project change management requires supplier access to customer information and employees. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require that the meetings needed to discuss and clarify must be changed or it can be difficult for the project team to handle. Also lack of access to the supplier and customer employees with authority to agree and negotiate project changes is a problem when using the above models. The models are somewhat complex and often only applied to large projects. For smaller projects the models are also powerful but should be scaled down. But it is import to stress that the models are scalable.

[edit] Annotated bibliography

For further reading is it recommended to read the material below:

  • Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.

A very good article that describes some of the elements from the book "The Object Primer, Agile Model-Driver Development with UML 2.0". It gives a good understand of how cost changes over time and shows the different between traditional cost over time and for example cost over time for software development. Furthermore, the article describes why it is important to work closely with the stakeholders and gives a good insight in the feedback cycles that are the most effective and financially best.

  • Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.

This is an excellent book to understand the different elements in project management that in several areas also can be used in management of project change. The book describes all the different types of stakeholders, how to create a project team, how to prepare a work schedule for a project etc. The book also reviews the different aspects of communication in a project group and why communication is a very important factor in group teams. Furthermore, the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. In general this a very good book that also is used in one of the courses at DTU.

  • Wallace, Simon. Scope & Change Control. The ePM book.

An article that very detailed describes Scope and Change Control. There is a lot of definitions of different types of project change related keywords like Scope change, change control, change programme etc. Furthermore, it describes very well different forms of change drivers for a customer such as business needs, new business partners and channels, globalisation, standards etc. Finally, the article gives a good understanding of a project change from start to finish and also illustrates theory and methodology.

[edit] 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 not only improve the project results but also the competitiveness and financial performance of a company.

[edit] 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. ↑ Wallace, Simon. Scope & Change Control, The ePM book. " Scope & Change Control"
  3. ↑ Tom Mochal. Use gate reviews to validate that you´are ready for the next phase of your project. Tech Decision Maker, 2008. " Use Gate Reviews"
  4. ↑ 4.0 4.1 4.2 Søren Vestergaard Andersen, Director of Business Process Management, Sweco
  5. ↑ 5.0 5.1 5.2 Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013
  6. ↑ Egelend, Brad. More on Change Management – The Change Log, 2011. " More on Change Management – The Change Log "
  7. ↑ Billiows, Dick. How to manage change order requests, 2015. " How to manage change order requests "
  8. ↑ Guidance on project management. 1.th edition, Danish Standards 2012
Retrieved from "http://wiki.doing-projects.org/index.php?title=Management_of_Project_Change&oldid=60535"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox