As a WordPress developer, managing scope creep can be a tricky task.

This article presents tips and methodology I’ve developed while working as an in-house support team member at Codeable.io since 2019. During this time I have helped numerous contractors progress and resolve scope creep issues.

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 and often is assisted by the use of redundancies 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 request an additional feature be added to their website, which was not included in the original scope of the project. Jane can respond by “bricking the wall” by saying no, and explaining that the feature is outside of the original scope of the project, but also “framing the door” by offering to add the feature for an additional cost, or suggesting a different solution that will still achieve John’s desired outcome within the same budget.

Addressing accountability for scope creep

New learnings can increase the cost of the project and it can be subjective who should bear the blame when this happens.

At Codeable, we tend to place more of an onus on the expert to set and define expectations properly, but we also know there is a balance of responsibility where the client must also be responsible for the lack of definition in a contract.

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.

6 additional tips for preventing/managing scope creep

Finally, here are 6 additional tips for avoiding scope creep as a developer:

1. Stop writing, and start calling immediately. Oftentimes written correspondence fails in tone and intention whereas an in-person call humanizes both parties. It is my experience that a quick call to your client will end up solving most light-scoping issues.
2. Clearly define the scope of the project in a PDF document. This document should include details about what is and is not included in the project, and should be shared with the client for their review and approval.
3. Set expectations for unknown areas. If there are areas of the project that are not fully defined or understood, it’s important to make this clear to the client and set expectations for how these areas will be handled.
4. Add a financial padding to the estimate to account for the unknown. This can help to mitigate the impact of any unforeseen issues or changes that may arise during the project.
5. Communicate regularly with the client. By keeping the client informed about the progress of the project and any issues that may arise, a developer can help to prevent misunderstandings and scope creep.
6. Be flexible and open to changes. Sometimes the client may have a valid reason for requesting additional work or changes to the project. A developer who is open to discussing these requests and finding a solution that works for both parties can help to prevent scope creep.

Remember, also to always frame your door when bricking your wall, even if that means offering your client a handoff package/document to assist with onboarding a different developer.