What to Consider When Estimating Change Requests

Change Requests are estimated differently depending on when in the lifecycle they are requestedImagine this. You’re working on developing and implementing a new system. Unexpectedly, you receive a formal memorandum from the primary stakeholder. It is a long and complex document, but the gist of it is summed up in the first paragraph.

It reads: “The Board of Directors has voted to change the fundamental methodology of the eligibility requirements and benefits derived for our product offerings. Before you go any further with the project, please provide an estimate for the following …” What follows is a long summary of the changes requested for their new system. As you analyze the requested changes, you realize that they fundamentally alter the core functionality of the proposed system.

Depending on where the project is in the system development lifecycle, the Change Control process will be handled in different ways, yielding vastly different results.

Consider the following scenarios:

During Project Charter 

If the change request comes during the development of the Project Charter, or even after the Charter has been completed, there is little impact on the overall project. The project team would compare the requested changes to what had been documented in the Project Charter and make any necessary changes.

If additional explanation of the requested changes is required, they would meet with the stakeholders to understand the changes before updating the Project Charter. Any Business Case and Feasibility Study documentation should be reviewed for potential changes to the cost and schedule estimates.

At this point in the project, the delay would be minimal – a few days to a few weeks. If handled internally, there is no cost impact outside of the delayed start. If an IT provider will be contracted to develop and implement the system, there would not be a cost impact at this stage of the project.

During Procurement 

If the request comes during the development of the Request for Proposals (RFP), or even after the RFP has been completed, again there is little impact on the overall project. The project team would compare the requested changes to what had been written in the RFP and update it as necessary.

If additional explanation of the requested changes is required, they would meet with the stakeholders to understand the changes before updating the RFP. If required by organizational standards, the team would also update the Business Case and Feasibility Study documentation if warranted.

At this point in the project, the delay would be minimal – again, a few days to a few weeks. If the RFP had not yet been issued to the public, a preliminary correspondence to potential bidders advising them of the delay should be sent out. If the RFP was issued, an addendum must be sent to potential bidders with the new requirements and timeline for proposal responses. There would be no cost impact at this stage of the project (outside of internal costs associated with the delay in starting the project).

During Scope Definition/Requirements Analysis 

If the request comes during requirements gathering, or after the requirements definition has been completed, there would be an impact to both cost and schedule. The Project Manager and her functional leads would immediately scrutinize the changes and determine which sub-teams’ work is affected.

For example, in this hypothetical situation, the requested changes are to the core functionality of the system. Let’s say that a preliminary analysis indicates that the changes will not affect the reporting subsystem or much of the data gathering subsystem. Those sub-teams can carry on. However, the team developing the requirements affected by the change should stop immediately until the Change Request for the new functionality has been reviewed and approved.

The cost and schedule estimates for the CR would take the following into account:

  • redoing the functional requirements for the affected area(s),
  • re-evaluating the upcoming system design and development effort based on the anticipated changes,
  • reviewing infrastructure needs for development and implementation,
  • re-estimating the effect on System Integration Testing and User Acceptance Testing,
  • reviewing potential changes to the training documentation and process, and
  • reviewing potential effects on the system rollout.

Additionally, a cost may be added for personnel idled while the CR is being reviewed.

While the redoing of the requirements can be estimated with a high degree of accuracy, the estimates of changes to cost and schedule for upcoming project phases would be only slightly more accurate than those provided initially. Until the new requirements are fleshed out, it would be difficult to be much more accurate.

Naturally, changes to fixed-price contracts will take longer to analyze, given that the contractor will be held to the new estimate. However, even if not fixed-price, the Project Manager should provide the client a thorough analysis of the estimated impact to the entire project effort. In some cases, understanding the full impact may cause the client to rethink the requested changes or, in the worst case, terminate the project. If the stakeholders agree to proceed, they would have been alerted to the need to acquire additional funding (if necessary).

Note: in most cases, once the project becomes the responsibility of a contracted IT provider, any initiating documents created by the contracting organization typically do not need to be changed. In some government contracts, where the funding agency is not the contracting agency, the funding agency may request an update to the Business Case and Feasibility Study documentation.

During Execution 

If the request comes during any of the design, development, or testing activities, the impact to both cost and schedule is greater the further into the project lifecycle the changes are requested.

If requested during design, the requirements analysis must be redone to define the new/updated functionality. Changes to the requirements are carried forward to the design, and by extension to development and testing. Again, it may be prudent for the teams involved in the project execution of the affected area to stop their efforts until the Change Request has been reviewed and approved. Cost and schedule estimates for the CR would review and analyze the same activities that were noted above for changes requested during requirements analysis.

Again, redoing the requirements can be estimated with a high degree of accuracy. The estimates of changes to cost and schedule for design, development, and testing would typically be more accurate, given that these activities are already in progress.

Note: regardless of where in the project lifecycle the changes are requested, the team must begin with the requirements stage to analyze the changes. Any work that needs to be redone in design, development, testing, and other activities is sunk cost.

During Implementation 

If the request comes during implementation of the system, the impact must be assessed immediately to determine whether the system should continue to be rolled out. For such an event to happen, there would have to have been some serious miscues during requirements definition, and even more so during User Acceptance Testing. (Note: I have not seen this occur during my career, but I suppose it is possible with an emergency policy change or other such factor.)

Most CRs that are requested during or after system implementation fall into a release planning process to be considered for later inclusion in the system. In fact, even for changes requested during User Acceptance Testing, I recommend that they be moved into release planning as well. (An exception to this would be for errors in the approved statement of requirements that were not caught until user testing).

The same estimation activities apply for changes requested during this timeframe. Though now they would not affect the project timeline.

Estimating Change Requests is a challenging task, especially when the entire team is immersed in managing to the project schedule. For ideas on how to handle change control, and perhaps avoid some Change Requests from even occurring, refer to my previous article, “How to Make Project Change Control Work for You”.


Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.