http://13.50.150.85/api.php?action=feedcontributions&feedformat=atom&user=AndreasAndersen 2026-07-14T17:33:11Z User contributions MediaWiki 1.43.3 http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16928 2015-09-28T18:18:32Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Model 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In Model 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Model 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on model 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Model 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in model 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect:''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders:''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> = Limitations =<br /> 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16927 2015-09-28T18:17:23Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Model 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In Model 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Model 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on model 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Model 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in model 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect:''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders:''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16923 2015-09-28T18:15:11Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Model 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In Model 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Model 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on model 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Model 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in model 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16910 2015-09-28T18:09:24Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16895 2015-09-28T18:02:52Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16879 2015-09-28T17:50:12Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process is described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16872 2015-09-28T17:45:26Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> 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. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> 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 &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16867 2015-09-28T17:42:56Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 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.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16853 2015-09-28T17:37:31Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16849 2015-09-28T17:36:32Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16839 2015-09-28T17:30:40Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16813 2015-09-28T17:22:23Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16791 2015-09-28T17:14:39Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> A article that very detailed describes Scope and Change Control. There are a lot of definitions of different types of change keywords like Scope change, change control, change programme etc. Furthermore it describes very well the reasons of why a company need to change such as the business needs, new business partners and channel, globalisation, standards etc. Finally the article gives a good understand of a change from start to finish and illustrates some theory and methods in figures to make the understanding better.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16790 2015-09-28T17:14:30Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> A article that very detailed describes Scope and Change Control. There are a lot of definitions of different types of change keywords like Scope change, change control, change programme etc. Furthermore it describes very well the reasons ofq why a company need to change such as the business needs, new business partners and channel, globalisation, standards etc. Finally the article gives a good understand of a change from start to finish and illustrates some theory and methods in figures to make the understanding better.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16787 2015-09-28T17:13:30Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013.<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book.<br /> A article that very detailed describes Scope and Change Control. There are a lot of definitions of different types of change keywords like Scope change, change control, change programme etc. Furthermore it describes very well the reasons to why a company need to change such as the business needs, new business partners and channel, globalisation, standards etc. Finally the article gives a good understand of a change from start to finish and illustrates some theory and methods in figures to make the understanding of the change better.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16763 2015-09-28T17:04:10Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Wallace, Simon. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> * Wallace, Simon. Scope &amp; Change Control. The ePM book<br /> <br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16755 2015-09-28T17:01:32Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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 &lt;ref name=&quot;Article 5&quot;&gt;Simon Wallace. Scope &amp; Change Control, The ePM book''. [http://www.epmbook.com/scope.htm&quot;'' Scope &amp; Change Control''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16719 2015-09-28T16:45:28Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16718 2015-09-28T16:45:07Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 3&quot;&gt;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/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16716 2015-09-28T16:43:49Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 3&quot;&gt;Tom Mochael. Use gate reviews to validate that you´are ready for the next phase of your project''. [http://www.techrepublic.com/blog/tech-decision-maker/use-gate-reviews-to-validate-that-youre-ready-for-the-next-phase-of-your-project/&quot;'' Use Gate Reviews''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16643 2015-09-28T16:00:33Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 4&quot;&gt;Method 123.Project Review Form - Initiation Phase''. [http://www.method123.com/initiation-phase-review.php&quot;'' Project Review Form''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16640 2015-09-28T16:00:01Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure &lt;ref name=&quot;Article 3&quot;&gt;Method 123.Project Review Form - Initiation Phase''. [http://www.method123.com/initiation-phase-review.php&quot;'' Project Review Form''&quot;]''&lt;/ref&gt;. 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.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16630 2015-09-28T15:50:37Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited 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.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure reduction or early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16585 2015-09-28T15:16:32Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have been produced or delivered a project change will lead to costly rework.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure reduction or early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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 &lt;ref name=&quot;Article 3&quot;&gt;Billiows, Dick. How to manage change order requests, 2015''. [http://4pm.com/change-requests-4pm-com/ &quot;'' How to manage change order requests ''&quot;]''&lt;/ref&gt;. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16558 2015-09-28T14:56:11Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have been produced or delivered a project change will lead to costly rework.<br /> <br /> 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. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced. <br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allows the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure reduction or early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> 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 in 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.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; 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. <br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project the deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project 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.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; 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.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> 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 client and in the project teams.<br /> <br /> 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.<br /> <br /> 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 figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 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.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> 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&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sweco''&lt;/ref&gt;.<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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. <br /> <br /> 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. 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?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the supplier’s and the customer’s alternatives?<br /> * 3) What are the suppliers and the customer’s interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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 at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> 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 Client information and employees. If there is limited access to for example stakeholder information decision basis is be worsened. The same applies to the meeting structure. If the company doesn´t have the meeting structure these models require 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.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> 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.<br /> <br /> = Conclusion =<br /> 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.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16457 2015-09-28T13:46:00Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 3&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16455 2015-09-28T13:45:03Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 3 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16451 2015-09-28T13:42:55Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16442 2015-09-28T13:39:12Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> '''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16438 2015-09-28T13:38:00Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|500px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16435 2015-09-28T13:37:13Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|450px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|550px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|550px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16433 2015-09-28T13:36:41Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|450px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16432 2015-09-28T13:35:07Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> '''Division of the project in well-defined phases'''<br /> <br /> 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.<br /> <br /> '''Control of the project basis'''<br /> <br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> '''Project reviews'''<br /> <br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16426 2015-09-28T13:31:07Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the box below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16422 2015-09-28T13:25:53Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Limitations of project changes can be that the contract between the customer and supplier is structured in a way so that the models cant be used. Furthermore does successful project change requires a lot of access to information systems and departments in the company. If there is limited access to for example stakeholder information can the decision making be worsened. The same applies to the meeting structure. If the company don´t have the meeting structure these models requires the meeting structure must be changing or it can be difficult for the project team to handle. The models are very complex and therefore they should be used on the projects in its normal form. For smaller projects the models should be scaled down.<br /> <br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16392 2015-09-28T13:04:10Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> Managing project changes requires a lot of experience and access to the different systems and departments in the company. <br /> Some of the limitations of handling project change may be limited acces<br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16378 2015-09-28T12:50:55Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positive feedback<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> <br /> '''Answer from AndreasAndersen''': Thank you<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> '''Answer from AndreasAndersen''': Thanks a lot<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> '''Answer from AndreasAndersen''':Thanks. This now changed.<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> '''Answer from AndreasAndersen''':I have been reading the article many times now to correct all the grammatical errors.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.<br /> '''Answer from AndreasAndersen''': I have created a Annotated Bibliography section.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16377 2015-09-28T12:50:34Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positive feedback<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> <br /> '''Answer from AndreasAndersen''':Thanks you<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> '''Answer from AndreasAndersen''':Thanks a lot<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> '''Answer from AndreasAndersen''':Thanks. This now changed.<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> '''Answer from AndreasAndersen''':I have been reading the article many times now to correct all the grammatical errors.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.<br /> '''Answer from AndreasAndersen''': I have created a Annotated Bibliography section.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16376 2015-09-28T12:49:54Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positive feedback<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> <br /> '''Answer from AndreasAndersen''':Thanks for the positive feedback<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> '''Answer from AndreasAndersen''':Thanks a lot<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> '''Answer from AndreasAndersen''':Thanks. This now changed.<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> '''Answer from AndreasAndersen''':I have been reading the article many times now to correct all the grammatical errors.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.<br /> '''Answer from AndreasAndersen''': I have created a Annotated Bibliography section.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16368 2015-09-28T12:47:52Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> A very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> An excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16366 2015-09-28T12:46:47Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004.<br /> This i a very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> This is an excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16364 2015-09-28T12:46:15Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For further reading is it recommended to read the material below:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. &quot;Examining the Agile Cost of Change Curve&quot;<br /> This i a very good article that describes some of the elements from the book &quot;The Object Primer, Agile Model-Driver Development with UML 2.0&quot;. 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. Further more does the article describe why it is important work closely with the stakeholders and gives a good insight to what different types of feedback cycles that are the most effective and the economic best.<br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> This is an excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16359 2015-09-28T12:33:35Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For futher reading is the materiale below recommended:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. &quot;Examining the Agile Cost of Change Curve&quot;<br /> <br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> This is an excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how to a create a project team, how to 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 more the book gives a good insight of the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16357 2015-09-28T12:32:01Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For futher reading is the materiale below recommended:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. &quot;Examining the Agile Cost of Change Curve&quot;<br /> <br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> This is an excellent book to understand the different elements in project management that also can be used in management of project change. The book describes all the different types of stakeholders, how the project is made, how to work schedule 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 work. Furthermore more the book gives a good insight in the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16356 2015-09-28T12:31:20Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> '''For futher reading is the materiale below recommended:'''<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. &quot;Examining the Agile Cost of Change Curve&quot;<br /> <br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> This is an excellent book to understand the different elements in project management that can be used in management of project change. The book describes all the different types of stakeholders, how the project is made, how to work schedule 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 work. Furthermore more the book gives a good insight in the different types of group meetings and how meetings can be handled in the most effective way. General a very good book that also is used in one of the courses at DTU.<br /> <br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Management_of_Project_Change&diff=16344 2015-09-28T12:22:22Z

<p>AndreasAndersen: </p> <hr /> <div>[[Category:Change Management]][[Category:Project Management]]<br /> <br /> Changes occur in almost all projects in all industries. Project changes regularly lead to cost overruns and major delays in connection with significant software and construction projects all over the world. It leads to conflicts and even to great business relationships being destroyed. The reason is often that companies have no project change management strategies and operational procedures. Further, the project management competences handling project change are limited. <br /> <br /> Project changes may occur due to various reasons. Introduction of new authority requirements, development of new or changed needs, lack of alignment of expectations are just some of the reasons to project change.<br /> <br /> An example of a project change could be a supplier that are building an administration building for a customer and six months into the process the customer suddenly also want a underground parking. Now the supplier has to change the project facing the challenge to minimize the additional cost still delivering the project on time. Handling such a challenge efficiently calls for a clear project change management strategy and agile handling of the project change.<br /> <br /> This article is a Article Type 1 and the following topics will be described to give the reader a better understanding of the impact of project change and how project changes can be handled in an efficient manner as seen in the contents below:<br /> <br /> = Cost of changes =<br /> [[File:Traditional cost of change curve 2.gif|400px|thumb|right|Figure 1.Traditional cost of change]]<br /> To avoid increased cost it is important to analyze and deal with possible project changes &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. 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. <br /> <br /> In figure 1 it is shown how cost of change grows over time &lt;ref name=&quot;Article&quot;&gt;'' 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&quot;''Examining the Agile Cost of Change Curve''&quot;]''&lt;/ref&gt;. The graph shows the cost of change on the y axis and time on the x axis. If project changes are handled in an early stage the cost and time consumption will be minimized. At an early stage a project change has limited consequence and the impact of the change is small. The change can still be handled in the project planning when the project deliverables have not been produced or delivered. At a late stage where project deliverables have not produced or delivered a project change will lead to rework which is costly.<br /> <br /> In order to avoid late or unforeseen project change different strategies can be applied. Below are three of the most often used most and efficient strategies described in brief. <br /> <br /> Division of the project in well-defined phases <br /> 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.<br /> <br /> Control of the project basis<br /> The project basis should continuously be collected, agreed and made accessible in all project phases in order to ensure that all project participants work according to the same basis and that all project requirements are known when designing the solution. This applies for client requirements, statutory requirements, user requirements, etc.. If these requirements are known and managed at the right time changes due to lack of knowledge of user requirements will be reduced.<br /> <br /> Project reviews<br /> Dividing the project into phases allow the project team to design an efficient project review structure. The structure should clearly outline who will participate in reviews, how reviews should be done and when these should take place. The review structure will ensure that changes to the design are done early and that all stakeholders have been involved. Further, it will ensure that the stakeholders input are included in the design at appropriate stages and that stakeholder engagement is high. All in all this will ensure early identification of project changes.<br /> <br /> = Process of project changes =<br /> [[File:Process of the project changes new.png|500px|thumb|right|Figure 2. Process of project changes]]<br /> <br /> As mentioned earlier, there are many different ways to handle project changes. In best case the companies involved in a project has a model for how the project change should be made. In worst case no model is in place and the project change management process in not aligned. The project change management process includes every step from agreeing the project scope and deliverables to the successful implementation of the individual change.<br /> <br /> Below is an illustration of a generic project change management process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that can be implemented in any company or applied to any project rather easily. It is important to notice that all activities in the model are linked to standard project management activities in order to ensure that these are easy to implement without adding new activities to the current project management set-up. This will ensure easy implementation.<br /> <br /> <br /> The model is divided into two key phases:<br /> <br /> * Initiation and planning<br /> * Implementation<br /> <br /> ''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.<br /> <br /> 1) The first activity should be a part of a standard project kick-off meeting between the customer and the supplier. In this meeting the expectations to deliverables should be aligned and the project change management process should be agreed. One of the biggest problems in relation to project change is that expectations are not attuned to project deliverables and handling of possible future changes in a project. When there is consensus and clarity of these topics the likelihood of project change is reduced and when project change occur there is a clear common understanding between the customer and supplier how this will be handled.<br /> <br /> 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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; lead by the Project Manager in order to ensure that the full project team understands the delivery process and the agreed project change management process. This will normally be a part of the project team kick-off meeting. This will ensure that the project team members are fully aligned and that the agreements made with the Client are understood. Finally, the project teams jointly identify the possible areas for project change in order to have a common understanding of these areas. This will ensure greater project change awareness during the project execution.<br /> <br /> '''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 &lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt; up on the project changes. The initiation phase has three overall activities there are marked by a red circle and the numbers 3, 4 and 5.<br /> <br /> 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 &lt;ref name=&quot;Blog&quot;&gt;Egelend, Brad. More on Change Management – The Change Log, 2011''. [http://pmtips.net/Blog/change-management-change-log &quot;'' More on Change Management – The Change Log ''&quot;]''&lt;/ref&gt; will be used as seen on figure 2. <br /> <br /> All potential changes will be listed in the change register. In the change register areas as change initiator, change description, change cost, agreed supplier fee, etc. will be recorded and to give a better overview a [[Gantt Chart]] can be made. The change register gives a very good overview of the status for all identified potential and agreed project changes. The change register will be used in meetings with the client and in the project teams. An example of a change register can be seen in figure 3.<br /> <br /> 4) In the fourth activity there will be a meeting between the customer and the supplier where the potential project changes will be discussed. Here will it be assessed if the project changes should be implemented or not. Further, the scope of the change, the cost of the change and the time of delivery should be discussed and agreed. The agreements should be captured in the change register in order to assure that this serves as a full overview of the project change status.<br /> <br /> As it can be very difficult to decide if project changes should be implemented especially when several project changes comes into play and the customer budget for project change could be limited. Consequently, a decision model can support the decision making process. In figure 4 a &quot;Project change decision process&quot; is inserted. The process in described in more detail below.<br /> <br /> 5) In the fifth activity there will be follow up on the execution of the project change and its cost and timely delivery. Furthermore, monthly budget updates will be provided to ensure thus that the time and cost estimates will be met.<br /> <br /> <br /> = Project change decision process =<br /> [[File:Project change decision process.png|500px|thumb|right|Figure 3. Project change decision process]]<br /> <br /> As mentioned earlier, it can be difficult to choose between the project changes that could be implemented. Often there is a tight deadline and limited budget and therefore it is not necessarily all project changes that can be implemented. Consequently, it is important to choose the project changes that offer best value for money in combination with the effect for the relevant stakeholders&lt;ref name=&quot;Book&quot;&gt;''Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013''&lt;/ref&gt;. A model to handle the project change decision making process can be seen in figure 5&lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt;.<br /> <br /> A key parameter deciding if a project change should be implemented is the value for money aspect. In the model the value can be seen at the y axis and the cost can been seen at the x axis. The purpose of the matrix is to decide what changes that are most important seen from a value and cost point of view. <br /> <br /> 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.<br /> <br /> The worst position to be in is when the project change is placed in the red box in the lower right corner where the value will be decreased and the cost will be increased. Again this should be a no brainer. The project change should not be implanted. However, there is an exception to this assumption. If for an example the government has made a new law that will require a project change. Then this change can’t be deselected and the strategy is then to minimize cost and value decrease.<br /> <br /> Very often a project change end up in the upper right corner of the model. The change delivers value but there is a cost implementing the change. Then the strategy is to maximize the value and minimize the cost. The key question is then how big the value will be. That is often a perception based on rational and emotional parameters. <br /> To come closer to deciding on the value of the change there are some fundamental questions that should be raiser. “How does the suggested change contribute to the project objectives?” and “Which stakeholders will benefit from the change?”. To reach on conclusion to these questions and to balance the two-dimensional answer it is clearly important to have a clear objective and understand the stakeholder’s value perspective. That is why project objective management and stakeholder management is very important for an efficient project change management process. If you do not know your objectives and stakeholders how will you the decide when to accept a project change?<br /> <br /> Below are examples of different types of project objectives and stakeholders&lt;ref name=&quot;Booklet&quot;&gt;'' Guidance on project management. 1.th edition, Danish Standards 2012''&lt;/ref&gt; that a project change can affect.<br /> <br /> '''Effect (e.g.):''' Time, Quality, Future proofing, Sustainability, Brand and image, Health and Safety, Etc.<br /> <br /> '''Stakeholders (e.g.):''' The Client, The Clients’ clients, Users, Authorities, Suppliers, Society, Shareholder and investors, Etc.<br /> <br /> =Negotiation of project changes=<br /> When the proposed project changes are completed, they have to be disclosed to the client and be negotiated. Early discussion and warning of project changes to customers gives a greater negotiating space and opportunities for both sides. This can for example minimize the cost as mentioned in the change and cost curve at model 1. There are different negotiation processes and below is an example of a negotiation process &lt;ref name=&quot;Person&quot;&gt;''Søren Vestergaard Andersen, Director of Business Process Management, Sveko''&lt;/ref&gt; that consists of 6 phases:<br /> <br /> * 1) What is the project change?<br /> * 2) What are the suppliers and the customers alternatives?<br /> * 3) What are the suppliers and the customers interests?<br /> * 4) Negotiation variables<br /> * 5) Prioritisation of each negotiation variable<br /> * 6) Plan dialogue and negotiate<br /> <br /> 1)In this phase the type of the project change must be identified and it must be investigate what the contract states. This makes it easier to negotiate with the customer. Furthermore, it will be a good idea to do [[Stakeholder Analysis]] to identify relevant stakeholders and how they will be affected. It will make it more attractive for the customer to implement the project change if the project change will make the final result better for the present stakeholders. <br /> <br /> 2)In this phase it is important to be clear about what alternatives the supplier have and what alternatives the customers have. If the customer has a few or no alternatives then the supplier will have the opportunity to make a better deal with the customer compared to if the customer has many alternatives. As mentioned earlier a focus on value, cost and effect on objectives and stakeholders is important.<br /> <br /> 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.<br /> <br /> 4) In this phase the supplier must identify and consider possible negotiation variables. This means everything that can be negotiated in the negotiating process. Examples of negotiation variables can be economics elements, contractual conditions, time, cost, etc. By knowing all these different variables prior to an upcoming negotiation this will possibly end up with a better outcome for all parties involved.<br /> <br /> 5) In this phase all the negotiation variables should be prioritized. Which ones should be part of the negotiation and in which should not. What is important at what isn’t? These considerations should be done both from a supplier and a customer perspective.<br /> <br /> 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.<br /> = Limitations =<br /> = Annotated bibliography =<br /> For futher reading is the materiale below recommended:<br /> <br /> * Ambler W. Scott. The Object Primer, Agile Model-Driver Development with UML 2.0. 3.th edition, Cambridge 2004. &quot;Examining the Agile Cost of Change Curve&quot;<br /> <br /> <br /> * Attrup Lindegaard, Mette &amp; Olsson Ryding, John. Power i projekter og portefølje. 2. Udgave, Jurist- og økonomforbundetsforlag 2013<br /> = Conclusion =<br /> Mastering management of project changes is very difficult as it involves several project management disciplines such as contract management, scope management, objective management and negotiation. Since project changes frequently occur and at the same time is very complex to handle it is crucial to have a strong project change management strategy and operational project change management procedures. Further, it is crucial to train project staff in this complex topic. Some of the models in this article are made based on many years of experience of handling project change in different types of project. They are not theoretical models but actual models used by companies with great experience in managing large complex projects. Professional handling of project changes will improve the competitiveness of the company and that is way project change is so important to be able to control.<br /> <br /> = References =<br /> <br /> &lt;references /&gt;</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16334 2015-09-28T12:09:25Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positiv comments<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> <br /> '''Answer from AndreasAndersen''':Thanks for the positiv comment<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> '''Answer from AndreasAndersen''':Thanks a lot<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> '''Answer from AndreasAndersen''':Thanks. This now changed.<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> '''Answer from AndreasAndersen''':I have been reading the article many times now to correct all the grammatical errors.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.<br /> '''Answer from AndreasAndersen''': I have created a Annotated Bibliography section.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16329 2015-09-28T12:05:09Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positiv comments<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> <br /> '''Answer from AndreasAndersen''':Thanks for the positiv comment<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16328 2015-09-28T12:04:41Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positiv comments<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed.<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures.<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section.<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> '''Answer from AndreasAndersen''':Thanks for the positiv comment<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.</div>

AndreasAndersen http://13.50.150.85/index.php?title=Talk:Management_of_Project_Change&diff=16325 2015-09-28T12:03:48Z

<p>AndreasAndersen: </p> <hr /> <div>Mette: I like your idea. It seems like you want to look at different theories, model and methods in your article for have to manage project changes, but maybe you should consider to just focus on one or two model/method. This way it is possible to go deeper with the chosen model(s) and to discuss the differens between the use of the models.<br /> <br /> ==s150799 reviewer nr.1==<br /> ===Overall impression:=== <br /> * The article has a good structure, correct use of the Wiki-style. There is a good balance of the different topics.<br /> * Good use of examples, it makes it easy to understand the concept. <br /> * Good explanation too graphical illustration in the text, this gives a good overall appearance and is highly effective. <br /> * “Management of Project Change” is an interesting project management tool, and the text explain it so it is easily understood.<br /> '''Answer from AndreasAndersen''': Thanks for all the positiv comments<br /> <br /> ===Improvement areas: ===<br /> * There are some grammatical errors. Mostly spelling and some sentences that are missing words like “the, are, is”. To increase the flow for the reader this should be corrected. For example :”… very difficult thing master.,” where “to” is missing to complete the sentence. <br /> '''Answer from AndreasAndersen''': I have been reading the article many times now to correct all the grammatical errors.<br /> *To me the reference list is not easy to understand, but it is most likely not completed. <br /> '''Answer from AndreasAndersen''': The reference list is now completed.<br /> *There is no annotated bibliography or description of limitation of this tool before the conclusion. <br /> '''Answer from AndreasAndersen''':I have created a annotated bibliography section and a limitation section.<br /> <br /> ===Suggestion of improvement:===<br /> *The reference list should maintain name of the author, the name of the page the article is collected and sometimes the date it is read. This is so that it is easier to quickly see where the source is from, and if it is legit. <br /> '''Answer from AndreasAndersen''': You are right. That´s now fixed<br /> *The pictures are a little small; the text can be hard to read. So adjusting them up would improve the quality.<br /> '''Answer from AndreasAndersen''':Good idea. I will try to adjust the pictures<br /> *I would suggest to make a own section about limitation of the tool, so that there is more discussion and not just explanation of theories.<br /> '''Answer from AndreasAndersen''': I have created a limitation section<br /> <br /> ==Review 2:==<br /> Nice job, it has a good structure and understandable headlines. Here is a few pointers:<br /> '''Answer from AndreasAndersen''':Thanks for the positiv comment<br /> *Where is the abstract? The first paragraph sounds like a definition of project change. An abstract should describe what the article is about and conclusions from the entire article. <br /> '''Answer from AndreasAndersen''':I have created a introduction in the beginning of the article and the conclusion is in the end of the article.<br /> *A recommendation is to delete “In this article, the following topics will be described…” and the topics, that’s what the content table is for.<br /> '''Answer from AndreasAndersen''':Thanks for the advice. I have been referring to the table instead.<br /> *The models look very nice and are well explained, good. Great job if you made them yourself but if not, remember a reference.<br /> '''Answer from AndreasAndersen''':Thanks a lot. The figures has now references.<br /> *Missing references all over the article, remember to insert references every time you write a fact. Also it's missing names ect. <br /> '''Answer from AndreasAndersen''':This is now fixed.<br /> <br /> <br /> '''s103183, Reviewer 3:'''<br /> <br /> * Overall a very nice article. It easy to understand and follow the flow of the article.<br /> * You have some nice models and you explain them well. However you might want to change ”Model 2” to ”Model 3” in the section ”The value for money (value and cost) phase).<br /> * Some places the wording is a bit weird or some words are missing like ”the changes not will result”. It is also called the fourth and fifth where you mention the activities from Model 2. I think these mistakes are a typo but try to read the article again in a day or two and pay attention as it can be disturbing when reading the article.<br /> * One of the things I feel like is missing from the article is a Limitation section where you discuss some of the limitations regarding the topic.<br /> * It seems as something went wrong with the reference list. Maybe take a look at some of the other articles and see how they have used their references. I would also like if you could put in references for the models you use.<br /> * I would recommend adding an ”Annotated Bibliography” as it is expected according to the guidelines for the articles.</div>

AndreasAndersen