How do you control change requests in a waterfall project?

Firstly, there is no such thing as a 'Waterfall project'. Secondly, who in their right mind would believe that you can fix all three of scope, schedule and budget? Change control is an important part of any project, to the extent that it is written in to many forms of contract. It is absolutely true that you need a well defined change control process but the premise that it is somehow difficult on a 'Waterfall Project' is flawed.

Your introduction is not accurate 1) there is no waterfall project or PM method 2) plans are not fixed. Plans provide guidelines, and good plans will have flexibility 3) also, is it not the purpose of a change management process to change the plan where and when needed? Change management is needed for all projects, regardless of the development approach, whether sequential or agile. Every project must have objectives, if we change objectives, we have to change the plan and the implementation, again, even in an agile environment.

Change control is an inevitable part of Project execution. But I would also like to bring into notice that it is equally important to have the proper channels defined for each category of change. Often I see that the person in the change workflow is least associated with the project and thus may work not act as an active enabler to complete the process on priority.

Use this step to create and nurture knowledge in your organisation too. A well defined and detailed process for change control, should allow flexibility and consistency to accommodate to the project in case. Take in consideration that a change request can also come from procurement. This means that you can use your change request process to address changes from suppliers too.

In my 40-odd years of being a leader in investment delivery I have only ever once seen a project that had fixed time, scope and budget - and that ended badly. This is a flawed premise, as all investments are test and learn temporary organisations which refine their tolerances as more is learnt and progress is made. In the world of Government agencies allowing "fiscal envelopes" to divisions, it is key that a sense of reality is part of investment planning to allow for the ambiguity of investment delivery, whatever delivery method is chosen.

When reviewing change requests, it would be helpful to categorize them based on their level of risk and potential impact on the project's critical path. This will aid in determining the necessary resources and level of evaluation/testing needed to ensure that the project's goals and outcomes are not affected.

In addition to the steps mentioned, you can further enhance the assessment of change requests in a waterfall project by considering the following Priority Ranking: Assign urgency levels to prioritize changes. Stakeholder Analysis: Involve stakeholders for comprehensive insights. Feasibility Study: Evaluate technical, operational, and financial feasibility. Impact Matrix: Visualize change effects on project aspects. Risk Assessment: Identify positive and negative impacts. Change Communication: Transparently share change details with stakeholders. Change Review Meeting: Collaboratively discuss and decide on change implementation, ensuring well-informed choices.

In addition to all of the above, one needs to also asses if the change is in line with the project goal or is it introducing a new feature and thereby opening the floodgates leading into scope creep.

I agree that it's really important to check how a change request would affect a project. This means looking at things like time, money, and goals. Doing this helps make smart decisions about whether to make the change or not. It keeps the project on track and helps it succeed.

In my experience, it’s important to make this form widely available while also implementing a system whereby submissions are automatically made visible to the stakeholders/change-committee to chime in with their own insights on potential effects and outcomes, as well departmental dependencies.

Don’t forget that specific and critical projects may need input from SME that can validate or clarify to the change control board the magnitude and full impact of the requested change.

Surely, approval is the last stage before the order is confirmed for execution by the implementer. Clear communication is therefore necessary to all stakeholders.

Approval for changes is essential to successful changes in projects. Firstly, the stakeholders must agree that the change should occur and changes should not originate and stay within the group executing the changes. Also, the team executing the change must agree on the change. If the team does not agree on how the change is being performed or what it is for then you must really step back and address larger issues as to why this change is really needed and when or if it should be implemented. Finally, having the project manager or project champion sign off on important changes would go to show that both the stakeholders and the project team executing the change are in agreement and changes can proceed.

Obtaining approval for change requests is crucial. It ensures changes are well-considered, maintains project control, and involves key people in decisions. This keeps the project organized and prevents unexpected issues.

It will be important to categorize change requests into minor and major when defining a change control process as contained in step 1 above. Minor changes should be executed by the project leader without necessarily seeking approval for each change request. Changes should, however, be properly documented.

Communication remains a strong linkage in project implementation regardless of stage/phase. The clarity in communication will eliminate any misinterpretation by any stakeholder. Communication must be simplified to the dot to see its effectiveness among all involved.

Approved changes require excellent communication to ensure a successful change. If you had done a change impact analysis or otherwise noted a significant impact from a change you would want to iterate back through your project management documentation and update anything this could have effected.

Both communication and implementation are closely linked. Communicating changes ensures everyone is on the same page, while effective implementation brings those changes to life. Together, they ensure that projects adapt successfully to evolving needs.

Never, ever assume a change is approved by the client (or anyone) without clear documented instruction and authorization. It usually takes twice as long to undo a change as it does to implement.

It is essential to clearly communicate the impact of the change request in terms of cost, revised timelines, dependencies, risks etc. with the project stake holders - internal & external. Expectations need to be set right. Effective communication is the key.

In Addition to Manage Expectations and relationships in your project, Do not overpromise, be realistic and promise only what your team can deliver. Agree to only those goals which you feel your team is competent to deliver. Once you and your customer mutually agree on project goals, ensure that they are delivered on time and to exceptional standard. Set Milestones Accurately Setting the right milestones is imperative when you start working on a project. They give clarity on how a project will progress and keep things transparent between both parties. Be honest and transparent about what kind of performance you expect from your team. Manage Project Expectations & Get Ready for a Successful Take Off.

Changes need input from third parties. It is rare for the team executing a change to know all aspects of impact for their change. Despite planning and preparing for a change there could be other conflicts they are not aware of, such as changes in other areas. A common place I see this occurring is changes from one project occurring simultaneously as others. A system update to servers would prevent an application update from working on time, so it is best to review and evaluate all of your project changes with other projects and operational functions as well.

My team engages in a retro following each project to celebrate wins and discuss lessons learned from unexpected changes we encountered on each project.

Still about expectations, it's important to talk about continuous monitoring, once a change is implemented, continue to monitor its impact and see if the results match expectations. If necessary, make further adjustments to ensure that the changes produce the desired results.

This section should be threaded throughout this article not tacked on at the end. People are central to the change process. How you set up the change process is dependent on who is involved in the project, their capabilities and relationships both within the project ecosystem, back into the organisation and more broadly eg. compare a client who is technically competent and has a well established team around them to a client who has not delivered this type of project before and is outside their personal area of expertise - in the first change may be brought directly to the client whereas in the second you might build an assurance team around the client focussing on building trust with them. Process should follow people ….

One thing I found helpful is to set right expectations and proper two-way communication and engagement throughout the project lifecycle- to continuously be on the same page. Successfully managed change control systems can have a major impact on our customer expectations and their opinion. In addition, it’s important for the project team to always document the lessons learned - don’t reinvent the wheel.

Its a great effort to do a proper stakeholder analysis on a project environment. This will facilitate meeting expectations of the beneficiaries and nonbeneficiaries with minimized conflicts, but also champion a manageable co-existence. All in all; stakeholder involvement helps to create beneficial ownership at completion and most of all mutual sustainability.

Managing change requests in a waterfall project while maintaining quality, stakeholder satisfaction, and team morale requires careful planning. First, establish a well-defined change control process that includes thorough documentation, impact assessment, and approval workflows. Prioritize changes based on their impact and align them with project objectives. Communicate changes clearly to stakeholders and involve them in decision-making. Keep the team informed and ensure they understand the rationale behind changes. Regularly review and update project plans to accommodate approved changes. Balancing these factors will help you navigate change requests effectively.

I think that it's essential to correctly classify the restriction and/or area of knowledge to which the Changeis linked to, in addition to mapping the business areas involved and also the interested parties as such. The objective is to consolidate change's cause in a transparent manner and facilitate the evaluating and dealing by those responsibles. For example, a Change that directly affects a commercial area may require actions in the way this department interacts with other areas linked to the project. In this way, adjustments in the area's internal processes are demanded and, therefore, the need for the correct classification of the changing event, based on the restrictions that are affected, and the link with the affected areas.

Contingency budget is as essential to a project's health as having a Change Mgmt Plan and a Risk Mgmt Plan. Changes are going to happen; without a contingency budget, once a critical change occurs, the only option available to a Project Owner is to reduce one of the constraints (Time - Cost - Quality) in order to "pay" for the change (or to ignore it). This is true in any type of project, including Agile and Scrum projects. There's always a "cost" associated with critical changes, and you're going to pay for it one way or another.

By adopting the concept of "Change Synergy." While managing change requests in a waterfall project, explore the potential synergies between seemingly distinct changes. Sometimes, changes that might appear unrelated at first glance can create a more significant positive impact when implemented together. Encourage your team to think beyond isolated modifications and identify opportunities for integration. By doing so, you not only optimize the project's trajectory but also foster a culture of innovation where change is not just managed, but harnessed for maximum value. This approach highlights the power of seeing change requests as building blocks that can collectively enhance the project's outcomes.

You may also want to document want changes were made. Every project irrespective of the methodology should have a “version control” system to track changes made in the course of implementing the project. These will serve as valuable organizational assets and lessons to be if it future projects.