While many companies operate a very effective Change Board, many do not, opting for routing Change Requests around those responsible for reviewing and signing them. I am interested to know how many Project Management Professionals encounter challenges tracking Change Note Documentation. This would include ensuring that a Change Note is progressed through the sign-off loop, is properly filed, the result disseminated to stakeholders, and Project documentation is properly updated. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 24, 2022 8:43 AM
Replying to Roland Vander Straeten
...
Sorry, what is ITIL?
No, you sorry because to use it without explanation. ITIL means Information Technology Infrastructure Library. It was popular thanks the work done by Office of Government of United Kindom. While it is IT focused you can find a process that could help to implement change management at the whole organization (at least, it was my personal experience). On the other side, other thing that was very usefull for me was ANSI IEEE Std 1042. All inside those process are roles (as you know) then roles can be performed by the same person for example. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
In my experience Change Request (CR) processes/procedures need to be onerous or there are just too many of them - everyone starts second guessing and has a better way of meeting the objective. It is important to have very specific criteria that need to be met for a CR to be raised. The criteria is more important than the number of hands it needs to get through. The CR has to be preceded by a "Request for CR" and only processed when all criteria are met. In my mind only the PM can initiate the CR based on the Request for CR.
It is also important to understand who has final authority on CR approval. Regardless of how many signatures you have, if there is a cost component the person/position with financial approval authority is the one that counts.
...
1 reply by Keith Novak
Apr 25, 2022 6:04 PM
Keith Novak
...
Making the process onerous to limit change is a common approach, but it doesn't work at all points in the design process or for all delivery models.
It adds a lot of effort to the change management process with the goal of reducing the total cost through fewer changes. In projects with a high degree of uncertainty, the choice may be to accept a high volume of changes and streamline the change process to make throughput more efficient.
The process might even change at major project milestones. In the PD phase, frequent change may be more acceptable as the solution evolves but once suppliers are on contract or any fabrication begins, the cost jumps dramatically so changes get far more scrutiny before they are accepted.
In my experience Change Request (CR) processes/procedures need to be onerous or there are just too many of them - everyone starts second guessing and has a better way of meeting the objective. It is important to have very specific criteria that need to be met for a CR to be raised. The criteria is more important than the number of hands it needs to get through. The CR has to be preceded by a "Request for CR" and only processed when all criteria are met. In my mind only the PM can initiate the CR based on the Request for CR.
It is also important to understand who has final authority on CR approval. Regardless of how many signatures you have, if there is a cost component the person/position with financial approval authority is the one that counts.
Making the process onerous to limit change is a common approach, but it doesn't work at all points in the design process or for all delivery models.
It adds a lot of effort to the change management process with the goal of reducing the total cost through fewer changes. In projects with a high degree of uncertainty, the choice may be to accept a high volume of changes and streamline the change process to make throughput more efficient.
The process might even change at major project milestones. In the PD phase, frequent change may be more acceptable as the solution evolves but once suppliers are on contract or any fabrication begins, the cost jumps dramatically so changes get far more scrutiny before they are accepted.
...
1 reply by Peter Rapin
Apr 26, 2022 7:52 PM
Peter Rapin
...
I don't disagree and changes are a part of project management. Recognizing that and making necessary changes as smooth, and effective, as possible is part of our job. However we also need to recognize that changes can be, and usually are, disruptive and costly. I go out of my way to get stakeholders to recognize that at the beginning and devise ways to minimize and mitigate. One of the best ways to mitigate is to spend effort at the beginning to define the scope or deliverable. Statements like "we'll figure it out as we go" need to be challenged. Additionally, changes should only be applied to the deliverable not the process. Another consideration is to include a cost and time allowance to deal with the minor changes to be authorized by the project manager or team, say 10 or 20% depending on the nature of the project. A project with a high degree of uncertainty may even carry 50% "expansion" allowance (considered pre-approved changes).
I come from the infrastructure side of project management and it may be easier to define the end objective. But ineffective planning remains a concern and too many stakeholders have a cavalier attitude at the beginning of the project towards the possibility of changes not recognizing how impactful these can be on project delivery.
When you set up a sophisticated CR process and approval structure it can suggest that changes are not just expected but encouraged. "If you don't want changes why did you set up a process - we got a process so lets use it."
Don't get me wrong, I fully support a CR process but I also make sure the message is there. The reason for the majority of project failures is scope change with the second reason being a failure to plan for scope change.
Enough of a rant for one day! Peter
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Apr 25, 2022 6:04 PM
Replying to Keith Novak
...
Making the process onerous to limit change is a common approach, but it doesn't work at all points in the design process or for all delivery models.
It adds a lot of effort to the change management process with the goal of reducing the total cost through fewer changes. In projects with a high degree of uncertainty, the choice may be to accept a high volume of changes and streamline the change process to make throughput more efficient.
The process might even change at major project milestones. In the PD phase, frequent change may be more acceptable as the solution evolves but once suppliers are on contract or any fabrication begins, the cost jumps dramatically so changes get far more scrutiny before they are accepted.
I don't disagree and changes are a part of project management. Recognizing that and making necessary changes as smooth, and effective, as possible is part of our job. However we also need to recognize that changes can be, and usually are, disruptive and costly. I go out of my way to get stakeholders to recognize that at the beginning and devise ways to minimize and mitigate. One of the best ways to mitigate is to spend effort at the beginning to define the scope or deliverable. Statements like "we'll figure it out as we go" need to be challenged. Additionally, changes should only be applied to the deliverable not the process. Another consideration is to include a cost and time allowance to deal with the minor changes to be authorized by the project manager or team, say 10 or 20% depending on the nature of the project. A project with a high degree of uncertainty may even carry 50% "expansion" allowance (considered pre-approved changes).
I come from the infrastructure side of project management and it may be easier to define the end objective. But ineffective planning remains a concern and too many stakeholders have a cavalier attitude at the beginning of the project towards the possibility of changes not recognizing how impactful these can be on project delivery.
When you set up a sophisticated CR process and approval structure it can suggest that changes are not just expected but encouraged. "If you don't want changes why did you set up a process - we got a process so lets use it."
Don't get me wrong, I fully support a CR process but I also make sure the message is there. The reason for the majority of project failures is scope change with the second reason being a failure to plan for scope change.
Enough of a rant for one day! Peter Saving Changes...
I found that weekly CCB sessions work best, as CRs can be explained, amended and quickly brought to decision. These CCBs are documented and the status of CRs is visible in the change log. The CCB had representatives of all related functions (e.g. finance, logistics, sales), empowered to make decisions.
Used this for example with a 18 months SAP rollout project. Shorter and smaller projects might use less stringent procedures.
Hi Thomas I would agree with you. For example I am dealing with a 200+ staff company involved in on-line teaching in various countries. We do not want to increase administrative burden of the PMO but still want to put in place a process that allows to keep track of the major changes. So we would implement a simple change request form that would be handed over to the Portfolio or Program manager, the later escalating it to the PMO Head for further decision if needed. We would make this an ad-hoc process as the online training industry generally requires a fast response time (3days), although my intention was to make it weekly as well.
I would be delighted for any comment-
Thanks and regards,
Gerald Saving Changes...
