Change requests are inevitable in any project, but they can also create conflicts and delays if not handled properly. As a project manager, you need to balance the needs and expectations of different stakeholders, while maintaining the scope, quality, and budget of the project. How do you manage competing change requests from stakeholders? Here are some tips to help you.
Before you accept or reject any change request, you need to assess its impact on the project. This means evaluating how the change will affect the scope, schedule, cost, quality, risk, and benefits of the project. You can use tools such as a change log, a change impact analysis, or a change control board to document and analyze the change request. You should also consult with the project team, the sponsor, and other key stakeholders to get their input and feedback.
As a project manager on the contractor side, it is important to access the likely impact of the change order on the existing scope of work before proposing a price or contract extension amount for two reasons: -The rough estimate of the duration of the extension may be beyond the customers tolerance for tying up the asset. -The timing of the additional task in the Gannt chats flow of tasks may cause the change to tie up your assets, either personnel or equipment, in a way the impacts other projects and therefore adds additional hidden expense that should be considered when assembling pricing.
Change requests seldom affect a large project's committed end date but they do affect the cost. To minimize the effect, the work is reviewed for how it impacts the project flow. The impact may accelerate the flow if key resources are freed to work tasks on the longest chain of work activities. The change request may not affect the overall project flow. So when is it a big deal? There could be a negative impact by slowing the flow of tasks worked by the most needed resources. Any work that requires critical resources on the longest chain is high risk. The change can become a big deal when known work is pulled from the contract package to reduce overall. This approach seldom saves costs, so planning to complete known work is better.
Review and validate the change request if it provides a business benefit then assess its affects on any existing processes and document prior accepting it and getting sign off from if a CAB exists.
One thing I've found helpful is open communication with external and internal stakeholders. Change can be difficult, but when you communicate the change openly and honestly, you position yourself to soften the edges of change. It's not easy and takes time especially if the status quo has never changed.
Change requests are unavoidable and something that needs to accommodated based on the priority, impact on the business and the users. In the Agile world, it's easy to handle such requests as accepting changes even at the fag end of the implementation is a part of the agile approach. Also, the nature of change request should be something that is in line with the vision of the organization and the team. The development effort/complexity vs value matrix will give a good measure on the importance of that request. Whether to do it or not do it.
Communication is key to managing change requests effectively. You need to communicate the change request, its impact, and your decision to all relevant stakeholders in a timely and transparent manner. You should also explain the rationale behind your decision and how it aligns with the project objectives and priorities. You can use various communication methods, such as emails, meetings, reports, or dashboards, to keep everyone informed and engaged.
While multiple methods of communication can and should be used to enact contractual changes, especially those which are time sensitive and may fall within your critical path, all proposals and approvals should be formalized via email with a clear title. This makes them more easily searchable and the validity more easily proven should dispute arise.
Yes the PM should communicate the change requests and impacts effectively, but the CCB, Steerco, or Sponsor gets to make the decision. The PM simply highlights the risks and impacts.
There are various means to communicate changes, the important aspect of managing communication is ensuring you are communicating in a way that is received by the masses. Some perfer email, some perfer a phonecall, and some prefer visualizing change in person. It is up to the individual managing change to insure it's being received through accepted means of communication.
Sometimes, you may face conflicting or incompatible change requests from different stakeholders. In such cases, you need to negotiate and compromise to find a solution that satisfies everyone's needs and expectations. You should listen to each stakeholder's perspective and concerns, and try to understand their underlying interests and motivations. You should also emphasize the common goals and benefits of the project, and seek win-win outcomes that add value to the project.
Based on my experience, there's one strategy that stands out: "Asking Why". Here's why: 1. Empowering Reflection and Clarity: Delving into the reasons behind the change request triggers the requestor to pause, reflect, and articulate their motivations. It will not only sharpens their thoughts but also elevates the overall quality of our work. 2. Prioritizing with Purpose: Asking "Why" enables project managers to prioritize effectively. It will help understand the potential impact of implementing or not implementing the changes on the project's goals. 3. Facilitating Collaboration: Understanding the reasons behind the changes helps project managers connect the dots and facilitate discussions among stakeholders with conflicting requests.
Often times it is not the project manager who makes the decision. Identify and communicate which stakeholder(s) own the product and who has the final say. There can issues that a non-negotiable from the start.
Win-win outcomes are not always feasible, hence the importance of a clear escalation path. It should be clear to all stakeholders who the ultimate decision-maker, and risk owner is. Project Managers tempted to ‘make a call’ could find themselves in conflict with the ‘client’. It is however prudent to share one’s experience and advise on record, all risks associated with change requests that may have a negative impact on the project.
No solution will satisfy everyone, and that shouldn't be the goal of this exercise. Negotiations are encouraged, but ultimately priorities need to be set based on how each change request affects project outcomes and customer experience. Learn how to say "no" while thoroughly explaining your reasons and the common goal.
Managing change requests can be challenging and complex, but it can be easier if you follow a structured and consistent process. You should establish and follow a change management plan that defines the roles, responsibilities, procedures, and criteria for handling change requests. You should also use a change management system that tracks and records the change requests, their status, and their outcomes. By following a process, you can ensure that change requests are handled in a fair, efficient, and controlled manner.
I began my career as a configuration manager. While managing the engineering change process I realized that the most important part of the process is knowledge about your customer. During my years as a program manager, I didn't wait for my allies to submit requests for changes. I communicated with them and asked if they had any issues. I let them know that sharing any issues with me, made the product better. Making our customers feel like allies and staying ahead of the engineering process, produced win win controlled situations. BTW I was able to write the change requests which also gave our government more control and reduced the processing time.
Developing a structured process is important but users should understand fluidity amongst rigid procedures should not be over looked. As artificial intelligence enters the STEM space, rigid procedures may hinder forward momentum. Users should continuously monitor thier processes and ensure they allow for ease of success whenever possible.
Particularly in design and engineering, timing when a change is introduced into the lifecycle can make a big difference. Once it has been agreed that the change is to be implemented there often pressure to get on with it, but waiting until a ‘design freeze’ point or ‘stage gate’ in the process can help the design team be more efficient. All too often multiple changes are pushed into the iterative design process mid-cycle with the result that the time and costs predicted at impact assessment stage can’t be met. It is difficult for the design team to recover from this and often the design phase is deemed a failure because of poorly handled design change execution.
The change request process must be mapped out and available to all team members and stakeholders. Everyone should be able to easily find how to make a CR. The PM is responsible for maintaining the system and tracking progress.
As a project manager, the approach to changes in a project should be dynamic and proactive. Change requests can be seamlessly managed by fostering proactive communication, using robust tracking tools, and integrating a predefined, streamlined process to mitigate risks and disruptions.
Managing change requests is also an opportunity to learn and improve your project management skills and practices. You should review and evaluate how you managed change requests, and identify what worked well and what could be improved. You should also solicit feedback from the stakeholders, and incorporate their suggestions and recommendations. You should then apply the lessons learned and best practices to future projects, and enhance your ability to manage change requests successfully.
It's an old adage nowadays but... Celebrate failure! Reflect with your team and encourage everybody to share what didn't go so well, stick them on the wall along with your learnings. Teams that can confidently, regularly celebrate failure together grow faster and celebrate success sooner. As a project manager it is in your gift to create a culture of openness, empowerment and agility within your projects, enabling your teams to pivot, accept and implement change without hesitation or guilt.
100% for this one. Hold regular retrospectives and seek feedback to see how your processes are working, including change control.
Strive to be not just a learning person, but a learning organization. Spread the culture of open, straight, honest communication in simple and efficient ways.
Be the channel for multiple stakeholders to collaborate and help them break the silos they are working in. Transparency of the priority and cross functional impact of any task is very crucial when handling multiple stakeholders competing requests.
When you receive a change request from customer : 1. Understand that change 2. Identify the Impact v/s Urgency of the request 3. Evaluate the resources - time, budget, expertise 4. Negotiate if you see any risk during the process 5. Document each and everything properly so that there is a transparent communication.
We learn as we go forward, and prototypes and testing provide insight on the usability of product designs. Listen carefully to feedback from stakeholders. The change may be necessary for the product to succeed in the marketplace.
I've grown substantially as a project manager. Initially, balancing stakeholder needs with project objectives seemed daunting. Through transparent communication and strategic negotiation, I learned to navigate these complex dynamics. I discovered the human elements at the heart of project management, understanding that beyond technical aspects, I was managing people and their aspirations. These experiences reshaped my approach, emphasizing the importance of creating an environment where everyone feels heard and respected. It's a continuous journey of learning, adaptation, and growth.
I've found that a good process that is widely known and understood helps manage against gold-plating and changes that are self-serving. Once people understand that they need to do some work to submit and analyze the CR, they know that it will be scrutinized and the project leadership will all see what is being attempted. Sometimes a bit of red tape can help save a project.