Bricking the wall, framing the door: A method for addressing scope creep.
Managing scope creep can be tricky.
During my time with Codeable, I’ve sen many cases where the client and the contractor experience disagreement over additional work being outside or inside of the original scope.
This article highlights several techniques and methods we advise experts to consider when addressing items that are definitively out scope.
Concept: Bricking The Wall / Framing the Door
Two key techniques for managing scope creep are “bricking the wall” and “framing the door”.
“Bricking the wall” refers to setting clear boundaries and saying “no” to requests that fall outside of the original scope of the project. It involves standing your ground in a kind but firm manner. The technique gets its title “bricking the wall” due to the use of redundancy in explaining why the labor is outside of scope across a sequence of replies to the client.
“Framing the door” refers to offering alternative solutions or options that can help the client achieve their desired end goal, even if it requires additional payments.
It’s important to use these techniques in balance, as a developer who “bricks the wall” without “framing the door” may be seen as inflexible and unhelpful. This can lead to resentment from the client for the amount invested so far into your services.
Let’s give a light example of this method in motion.
Let’s say a client named John contacts a developer named Jane to improve the performance speed of their website. The client wants better scores and the contractor determines to help them to better scores starting with optimizing the images on several pages, which he charges 4 hours time. This does improve the performance on desktop significantly, but the client is disappointed with the lack of improvement on mobile.
There-in the scene is set….
Client: Thanks for the improvements. We still need the mobile GTMetrix score to be better, though.
Expert: I’d be happy to help improve this metric, but the job was for optimizing the images on the homepage only which I scheduled 4 hours time for. I apologize, but we will have to negotiate an additional task that focuses on X items that will surely improve the GTMetrix score. I’d like to point out that the work we did has improved the score already too and is a good first step in overall site optimization.
Client: My project description states that I’m looking for better GTMetrix scores and the mobile version still needs improvement.
Expert: I’m happy to focus on creating a plan to improve the mobile GTMetrix scores, but the current scope of work I was hired to perform was the optimization of images, which I’ve performed. Your site saw some improvement as well, but greater effort will need to go into improving the current mobile scores which isn’t currently included in the scope of work I’ve estimated for. I’ll make an estimate for a new round of work as soon as you close this current round of work.
Client: I’m sorry I can’t sign off on that. I clearly thought I was receiving more value for my investment. I will have to (do X) if you can’t improve the mobile scores.
Expert: Optimization projects have many variables and optimizing images are just one variable to a complicated process. I’m happy to sit with you and plan a new plan of action to improve your scores, but it will be an additional task and in order to continue with additional work, I would require that the current work be marked complete. Please do mark the current project complete so we can move forward.
Client: I’ve hired you to make my website faster! You’re the expert, you should know that is what I was looking for!
Expert: I completely understand. When you hired me I could tell your goal was to improve your scores and you pointed out that you would like to start with image optimization. As an expert, I echo the value of having optimized images and know that my assistance here on this issue will improve your scores so I contracted with you to optimize the images. Unfortunately, optimization projects still have many variables, and optimized images are just one variable of the overall process. I’m happy to sit with you and plan next steps to improve your scores, but it will have to be an additional paid task. If we can’t resolve this here we unfortunately might have to contact support to resolve the issue for us and the relationship will have to come to an end. But I am confident that we can move forward if the current project is marked complete.
Client: Okay, I’m not happy about it but I’ve marked the project complete. Please let me know what additional you have planned to improve the mobile GTMetrix scores.
Notice how each message the expert delivers to the client becomes more robust as well as redundant over time to express the expert’s resolve and leadership. This is “bricking the wall”, while always leaving a call to action for how the client should proceed as “framing the door”.
If this method succeeds, it will help foster mutual respect and will also decrease the likelihood of repeat instances of scope creep from the same client.
Addressing accountability for scope creep
New and unexpected learnings can increase the project’s cost once, and it can be subjective who should bear the blame when this happens.
Ideally, in a healthy relationship, neither client nor the developer is to blame and both sides share an understanding.
In response to scope creep, a developer might perform additional work at no additional cost if it is under a few hours, but if the increase in work is significant and not covered by the scope of work agreement, then the client theoretically should assume the financial responsibility of the additions.
A good developer will always do due diligence to avoid scope increase by advising a reliable original plan. A good client will be flexible in the instance that an unforeseen learning increases the scope of work.
Delaying contested items until the end of the project
When a disagreement arises between the two parties, it can lead to an impasse and potentially stall the progress of the project. In such instances, it is important to find a solution that can help both parties move forward and complete the project successfully.
One approach to resolving scope creep disagreements is to temporarily set aside the work in question until the end of the project. This allows both the developer and the client to focus on completing the tasks that are within the agreement, which can keep the project moving forward. This also gives both parties time to evaluate the situation, clarify the requirements, and find a mutually agreeable solution for the contested material.
In some cases, it may be necessary to refund part of the value of the contested material if a solution cannot be agreed upon. This allows the client to receive a partial refund for the work they are not satisfied with, while the developer can move on to other projects without being held up by the dispute.
Alternatively, the developer and client can work together to negotiate an MVP (Minimum Viable Product) that is in line with the client’s budget. This involves identifying the core components of the project that are essential to meeting the client’s needs and delivering a solution that provides the maximum value within the constraints of the budget. This can help both parties reach a compromise and avoid any further delays or disagreements.
In conclusion, when an impasse is experienced between the developer and client in an instance of scope creep, putting off the work in question until the end of the project can be an effective solution. Refunding part of the value or negotiating an MVP can also be viable options, depending on the specific circumstances of the project. The key is to work together to find a solution that allows both parties to move forward and complete the project successfully.
Dealing with scope creep in troubleshooting projects
Troubleshooting projects are likened to medical diagnostic processes – both require a methodical approach that often focuses on eliminating what is not causing the problem, rather than directly discovering the cause of the problem. In both fields, clients can become frustrated with the open-ended nature of the troubleshooting/diagnostics process. In both cases, clear communication and setting realistic expectations are vital to fostering a healthy relationship.
One practice that I recommend to contractors to mitigate their chances of a negative troubleshooting experience is what I call “The Sandwich Method.” It’s a simple but powerful metaphor that, if followed, will generate appreciation in your clients for the way expectations are managed.
If done well it will prevent resentment when the first round of troubleshooting does not end as optimistically expected.
Methodology: The Sandwich Method
This method begins a troubleshooting contract with a PDF proposal outlining the goal of the job, the methodology to be used, and predictions for both optimistic and pessimistic outcomes.
After this PDF is developed and sent to the client for approval, the meat of the work is then carried out.
After the booked hours are spent, a second PDF proposal is delivered, summarizing the major learnings and recommendations for further work, again with realistic projections for both optimistic and pessimistic outcomes.
The Sandwich Method helps to ensure that all parties involved have a clear understanding of the work being done, and that progress is being tracked and communicated effectively.
