Avoiding project change analysis denial of service!

Wikipedia defines a denial-of-service attack as “a cyber-attack where the perpetrator seeks to make a machine or network resource unavailable to its intended users, such as to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet. Denial of service is typically accomplished by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled.”

Have you ever worked on one of those projects where it felt like the team was responding to change requests almost every day?

At some point, the time spent clarifying, analyzing and responding to these requests can seem greater than the effort required to complete the original scope of the project.

Stakeholders might not intend to impact a project in this manner but good intentions won’t matter if the team is unable to deliver approved scope within cost and schedule baselines because of time lost in processing change requests.

Don’t feel smug because your project delivery is done using agile approaches!

Even for those companies which have embraced agile, changes which will exceed approved funding or the approved number of sprints will still need the team to perform some analysis to be able to secure approvals to proceed.

So how can we avoid this threat?

1. Pay me now, or pay me later. Sometimes the cause for frequent changes is insufficient time spent before a project starts in defining and clarifying the desired outcomes. This leads to direction dissent which can spawn change requests. While I don’t advocate ideation analysis-paralysis, it’s a good idea to get alignment on key project objectives before the team gets started.
2. Define thresholds. If the team automatically starts analyzing requests as soon as they are received, they are sending a clear message that there is unlimited capacity to do so. While planning the project, establish a simple process for determining if a given change request will require a meaningful amount of effort prior to its review by governance bodies. If so, the analysis effort itself should be approved, and the governance bodies should be apprised of the potential impacts of the analysis effort on remaining cost and schedule budgets.
3. Remain vigilant. Monitor the volume of change requests and the effort spent in their analysis and have the courage to escalate concerns proactively to your sponsor and other governance bodies. An increasing number of change requests could be an early warning sign that the original business case is no longer valid or that there is the need for active engagement by your sponsor to manage stakeholder expectations.

Change might be a constant, but a project team constantly managing change will never deliver expected business value.