Handling change in a scope
What do you do after agreeing on a scope but then realise changes are needed?
It would be easy to think that, having invested time into preparing a proper scope for your new website, that everything will run to plan and nothing will change.
That is unlikely to happen except possibly on small sites.
It’s more likely that there will be changes and that they can come from both sides of the process, Developers and Client.
Why do Client changes happen?
There are several reasons this can happen, and despite all the best intentions, some are unavoidable;
- Overlooking needs
- Rushed or incomplete process
- Other influence
- Committee based decisions
- Changing business
(1) Overlooking needs and (2) Process.
If the client prepared the scope, then it’s possible their lack of expertise in this area could create some missing needs.
The fact they prepared a scope is fantastic, and for agencies or freelancers, this is a big deal. Having a detailed brief makes your life much more comfortable. Be careful when you first receive the brief to make sure it still gets a thorough review.
You’re the person with the industry expertise, which doesn’t mean you know everything, but it does mean you should clarify it with them.
Tip:
Ensure you go through their scope with them in-depth.
The process of reviewing it with your client can often bring up forgotten items that can be added to complete the scope.
(3) Other influence.
Whenever your client mentions to people they know that they are undertaking a new site development, they will receive ‘advice’ from many different people. Not all of that advice is qualified.
The information they receive can be from online sales systems, courses, ‘helpful’ friends and colleagues or possible competitors.
Tip:
When such an issue is raised, try to understand the source of the problem. First, discuss the pros and cons to see if they do want that change or if they need a better understanding of it within the context of their new site.
(4) Committee based decisions.
Committee run projects can be a complicated issue to overcome. You’ve dealt with one person throughout the project so far, and they’ve been approving things and keeping the process moving. Then you receive a significant request that is outside the previously agreed scope.
Ideally, you’d know about a committee-based process at the beginning.
If you can’t work around the request, then you need to invoke any out of scope process you have in your contract. Handling this calmly and professionally is essential, and you should allow your client the time to discuss this with the committee that will have to accept that.
Often the additional cost implications remove the ‘need’ of the request as other committee members challenge the person requesting it.
You need clarity around what is part of the scope in the contract to handle this easily.
Tip:
Ask at the beginning of the process who will be signing off on the final project. Have clear terms and conditions for your projects. They should define what the scope is and the cost of out of scope work.
(5) Changing business
Sometimes the business needs change. The time from initial scope to commencing the project might have been long for the client, and their needs have changed since then.
Like (4) you need to have a clear definition of what is in the scope and how you handle out of scope work.
Tip:
Always discuss out of scope work as soon as it comes up. Don’t surprise the client with a bill they didn’t expect. Discuss the request with them, determine if they need an additional quote or contract for it or if it will just be added on, confirm it in writing and keep going.
Why do Developers changes happen?
If you are the client and suddenly get a call or email from your development team with a change issue, it can be concerning.
There are several reasons why this can happen and understanding them will help you in managing the way your project continues.
- Missed specifications
- Changing technology
- Team changes
- Capability
(1) Missed Specifications
While the teams working on projects aim to be as thorough as they can mistakes can happen, or misunderstandings.
It is as crucial that the client meets with the development team as is the opposite. You need to make sure what you have documented is understood the same way you wrote it.
The providers you choose might have rushed over a section of the specification and missed it as well.
Contracts are there to protect both parties. The consequence of out of scope should be clear to the client and equally the what the quote should deliver needs. If they agreed it was covered, then they need to meet that, and the onus for the mistake is theirs.
If it is ambiguous and the true meaning of the requirement only came out later during the build, then accommodation should be made by both.
Tip:
Spend time upfront on clarifying what is in the brief documents. Amend them, add extra diagrams or examples but make sure both parties can agree on what is included and how it will be delivered in plain English.
(2) Changing technology.
Web sites use a series of technologies that are continually changing — both the underlying languages as well as the content management systems. Web standards and security also influence how sites are created and managed.
In a build cycle, it is conceivable that quoted methods might become obsolete or new opportunities might appear.
The development team should be able to explain to you what is changing and the impact on you. There might be a change in how something will work, perhaps for the better, or a change in costs.
It is normal, and it shouldn’t concern you as long as the explanation is reasonable and the cost not prohibitive.
Tip:
Always ask for as many alternative options to a problem as you can. It allows your developers to think broader, and also you don’t feel railroaded into one pathway.
(3) Team Changes
If your developers’ team changes, it shouldn’t affect how your project gets built unless they lose technical skills. You should have a contract, and they should be obliged to complete it to the agreed standard.
This falls into the category of their problem, not yours.
(4) Capability
Capability refers to the ability to deliver the functionality in the method that had been agreed on. I can be technology related, and in most cases would fall into that bucket.
It could, however, be anything, e.g. legislation might preclude you from being allowed to implement a method.
Both parties should discuss this, and where they will need to make changes, the developer should be able to outline the saving from the work that will no longer be able to get done and the new costs that will be required to complete an alternative.
This should simply become a commercial negotiation about how to handle it.
Tip:
Always carry a contingency amount into a development project for unexpected events so that you have a budget to cover it.
I’ve covered several reasons why changes can occur despite creating a detailed and complete (or so it seemed at the time) website plan.
The key is that the scope that was written was ultimately a snapshot in time. Events will occur once that project commences, and while both developers and clients can cause problems (be at fault) in many cases, it can be a lack of understanding that creates conflict.
If you take time to understand the process will require small amounts of flexibility, and also you put in place sensible agreements, then your project and your website plan should be able to be completed without significant issues.
For the question “So why bother creating a plan if it’s only going to change?” my answer is, imagine how many problems you would have without a plan.
Managing small events along the way is normal, and you should expect some variance.
Understand that, and you’ll remove a lot of the stress in completing your next project.
