A big number of changes and corrections in requirements regarding the scope of the project vastly impacts the date of the project’s delivery. Extending the time limit is just one of the negative effects of the modification. It happens that additional requirements lead to a situation in which the project is not delivered at all. Such cases take place when many of the following requirements are dropped into the project: ad-hoc, urgent, emergency, out of scope.
The above factors often need to be addressed and managed immediately, as not only do they affect the duration of the project, but also distract the project team and divert the attention from the project’s main goal.
How to refuse in a professional way without offending the client, at the same time keeping the project’s well-being in view?
Consent to the additional requirements and its influence on the project
When you say YES, it predominantly has influence on 3 main aspects of the project: cost, time and quality. Growing of the solution’s scope may significantly increase the costs, leading to a budget overrun. It results from the extending of works’ duration, which may ultimately affect the final product’s quality. This is key information for stakeholders, as it allows them to make the right decision regarding further tasks in the project.
Alternative
„Expect the unexpected.” The project’s only constant is the change, which is worth emphasizing during the talks with stakeholders as regards requirement extension. It is always smart to have several alternative solutions up your sleeve. Additionally, for each of them it is advisable to present the pros and cons, as well as explain their impact on the project. One might as well suggest delivering the solutions in the project’s next phase in case it is currently impossible or may significantly affect the deadline, cost or quality.
Such an approach does not guarantee success in each case, but telling someone “NOT NOW” instead of “NO” is certainly better seen, as it gives the conviction that the needs will be implemented at a later date and not rejected entirely.
Priorities
Once we have found ourselves in the situation where too many requirements of Ad-hoc, Urgent, Emergency, or Out of scope type have been requested for the project, one might ask the stakeholder to give priorities to the requested changes, and subsequently confront the expectations with current workload and deadlines. The stakeholder should individually decide what we should focus on in the first place and define the scope of requirements which “drop out” from the project plan. The upside of this technique is chiefly the transparency. The contractor can quickly see which additional tasks “entered” the project, assign them priorities and partake in the responsibility for the project team’s task execution.
Data and statistics
Presenting data and statistics often allows stakeholders to understand the impact of additional changes. Analysis results allow to make the right decision regarding requirement implementation. Hard data may also be the justification for the decisions made by ourselves.
Out of scope
This element is often overlooked while collecting requirements and keeps coming back in the project’s lifecycle’s further phases. The more assumptions that something is not a part of current project (goes beyond the scope) we make, the more often we will be able to refer to them. It allows us to avoid many unnecessary and inconvenient discussions. Besides, we can plan the implementation of additional changes for a further phase or the next release, which – as we all know – is inextricably related to additional cost.
It is worth keeping in mind that out of scope changes should be formally notified from the very beginning and priced each time. There are many factors which may affect the quality and timely delivery of our work in the project. These factors very often crop up in completely unexpected moments and usually not only do they affect the project but also cause much stress. This is why the ability to manage additional requirements and analyze their impact on our work or the final product constitutes skills of great importance which every good analyst shall possess. Thanks to an assertive attitude and thorough requirement analysis we may avoid many unpleasant situations.
I hope that you will find the examples presented above helpful and useful in your work. Good luck!
