Management of Project Change
| (111 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ''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: | |
| − | + | ||
| − | + | ||
| − | '' | + | = Cost of changes = |
| + | [[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 = | |
| + | [[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. 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 <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. | |
| − | + | ||
| − | |||
| − | The model is divided into | + | The model is divided into two key phases: |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | * Initiation and planning | |
| − | + | * Implementation | |
| − | '''The | + | '''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 <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. | |
| − | ''' | + | '''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. | |
| − | + | 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. | |
| − | |||
| − | + | = Project change decision process = | |
| + | [[File:Project change decision process.png|550px|thumb|right|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<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>. |
| − | + | 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 <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? | |
| − | + | 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. | |
| − | + | '''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. | |
=Negotiation of project changes= | =Negotiation of project changes= | ||
| − | When the proposed project changes are completed, | + | 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: |
| + | |||
* 1) What is the project change? | * 1) What is the project change? | ||
| − | * 2) What are the | + | * 2) What are the supplier’s and the customer’s alternatives? |
| − | * 3) What are the suppliers and the | + | * 3) What are the suppliers and the customer’s interests? |
| − | * 4) Negotiation | + | * 4) Negotiation variables |
| − | * 5) | + | * 5) Prioritisation of each negotiation variable |
| − | * 6) Plan dialogue and | + | * 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. | |
| + | = 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. | ||
| − | + | = 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. | ||
= 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 = | ||
| Line 120: | Line 126: | ||
<references /> | <references /> | ||
| − | + | [[Category:Uncertaity]][[Category:Change Management]][[Category:Project Management]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 16: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
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
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
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.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"
- ↑ Wallace, Simon. Scope & Change Control, The ePM book. " Scope & Change Control"
- ↑ 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.0 4.1 4.2 Søren Vestergaard Andersen, Director of Business Process Management, Sweco
- ↑ 5.0 5.1 5.2 Attrup Lindegaard, Mette & Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013
- ↑ Egelend, Brad. More on Change Management – The Change Log, 2011. " More on Change Management – The Change Log "
- ↑ Billiows, Dick. How to manage change order requests, 2015. " How to manage change order requests "
- ↑ Guidance on project management. 1.th edition, Danish Standards 2012
