Change Requests

You may spend weeks or months painstakingly working on a website or app, covering every feature request in detail, ensuring it’s the best work your team can produce. You may be very proud of the work and eager to show the project owner. You excitedly send them an email and wait for the praise to pour in…

“Everything is great! but…”

and then more:

“maybe we could just change this one thing…”
“also I think this could do with a bit more work…”

etc. etc.

Any requested feature not clearly listed in the original scope is beyond that scope and therefore counts as a revision or change request. This must be made explicitly clear to clients and project owners. Extending the scope, also known as “scope creep”, jeopardises all other features by disrupting work schedules and putting deadlines at risk. Luckily, in your written agreement with the project owner, you have established a policy for handling these change requests… right?

There are various solutions. You may want to state a specific number of permitted revisions within the project budget and timeline, although in doing so you are essentially banking on the requests being very simple. What if it’s actually a significant amount of work? You can’t always accurately assess feature complexity before work on it has begun and the project owner perhaps isn’t going to be aware of how much work is involved for each request. Another approach is to charge a special fee or increased rate per change request. This is more reliable and may even serve to discourage the project owner from making such requests, which can only work in your favour. You may also factor several “rounds” of change requests into your agreement, allowing a fixed amount of time and budget for dealing with changes and new features. Whatever your own solution is, you should structure your agreement and your budgets to support delivery.

If of course you and a project owner are not a good fit, you may find yourself faced with multiple revision requests to the point where it is no longer worth your time. It is important to recognise when to walk away from a project.

It’s important that both sides recognise that ultimately scope is open-ended. You’ll start off with a list of things to work on, but there should be a mutual understanding that the list will change. New ideas and challenges will undoubtedly present themselves throughout the project life-cycle and you have to be prepared. Keep in mind that you must maximise your value to the project owner. That means that if something important crops up, even if it was outside of original scope, give it priority over the tasks or features that were originally agreed upon. In this circumstance, you’ll simply have to communicate to the project owner if previously agreed upon features must now fall out of scope or be postponed. This adaptability is much easier when using agile project management methodologies, and requires a certain amount of trust and empathy from both sides — the project owner’s team and your production team. With short iterations over feature sets, otherwise known as “sprints”, new priority feature requests can more easily be inserted into the timeline while other sprints are pushed back. Everyone must understand that while the eventual ship date may remain fixed, the product and deliverables remain variable. From your team’s perspective it means that they don’t have to worry about being overburdened with additional tasks. From the project owner’s perspective, they gain increased control as they are able to re-prioritise and redirect you throughout the project without having to constantly renegotiate increased budgets.