The Danger Of Scoping After Contract Acceptance

Ideally creating a scope of works for a web project would be done before entering into a design and development contract for the work.

For many clients they want a simplified process, choosing a developer and moving forward in the project. Agencies and developers often are happy to get work in this way and take on the responsibility deliberately or accidentally of the scope.

Whether its budget driven, relationship driven or timeline driven this method is common, as are the problems that can come from it.

So what problems can it create?

The problems are similar to any project that doesn’t have a clear set of specifications, however when a contract has already been entered into for a set price, the parties are taking on some assumptions that aren’t necessarily correct.

For example, the client will be assuming that the price is all inclusive, that they have agreed on a price for the site they have in their mind. They assume that the scope is just a formality to moving through the project and often don’t realise what it entails.

A developer on the other hand has made an assumption that they understood from pre-quote meetings that they have a great handle on what the client wants and their quote covers everything they want and some contingencies so that they can make a profit on this project.

What could go wrong:

  • Assumptions invariably aren’t facts
  • Misunderstandings
  • Miscommunication
  • Budget blowouts for the client
  • Conversely losses for the developer having to build more than they quoted for
  • Timeline blow outs
  • Unhappiness

Even if each of these issues is resolved during the process you will invariably find at least one of the parties involved has a sour taste in their mouth afterwards.

No one sets out to have that as an end result.

How to fix the problem?

The easiest answer is to say, scope the project first then quote second.

And that is an ideal scenario. That process allows for time to be spent on getting a quality scope assuming the client is willing to spend time and money on the process.

However if that workflow isn’t going to work for your business then it’s important to understand what goes wrong and how you can fix it. Making one or two small adjustments to your process could save you a lot of heartache and money.

Process Change 1: Make it an Estimate not  QUOTE

If your process requires you to offer a price first then scope after project acceptance, make your quote an estimate.

Change your terms and quotes so that they provide an estimate based on the best shared knowledge provided by the client however during the scoping phase you will review and update the estimate based on their requests and requirements.

You can also note and allow for them to remove items or add more depending on the estimate.

Note. I’ve used this process in the past and we have actually reduced an estimate when a significant assumption we had made was removed from a scope. Not only did this delight the client that they wouldn’t need to spend as much on their site it also built massive trust with them about how we conduct our business.

If you lock yourself into a fixed price with no ‘out’ clauses then no matter how well you do the next steps you will always have some projects that you lose out on. If you don’t know how big something is there’s no way you can truly quote that project.

Process Change 2: It’s all about the detail

Even if you offer the scoping service at a minimal cost, your process should be to spend as much time as possible at this stage.

Why? Using the old carpenters expression, ‘measure twice, cut once.” It is the same with your web work, the actual cost of reworking code, and design can be much higher than the cost of a few more hours scoping.

It’s likely your salesperson, analyst or business manager is the person involved in the scoping. They are most likely salaried and not people who produce income for your business.

If you are a freelancer doing everything all time costs you but the principle remains true.

Getting the specifications clear, and agreed on, up front will avoid all the issues later on.

Taking three extra hours to get the client in agreement on what will be built could save you hours of frustration with them later, late nights trying to squeeze in extra fixes when the project now overlaps with others, and possibly less third-party contractor costs.

It’s worth it.

Focus on the detail, detail is what hurts all projects.

It can be tempting once the project is underway to go through the scoping step in a simplified format. Everyone is energised to get designs underway and meet deadlines. What can easily happen is that the scoping phase done during the project isn’t as thorough as something done seperately.

It can suffer from:

  1. Lost communication
  2. Lack of Understanding
  3. Lack of attention
  4. Lack of detail

[ 1 ] Lost communication

When we communicate there are lots of assumptions being made on both sides of that communication. Typically in a briefing process there are a number of meetings, calls and emails that might happen prior to the project commencement or in the early stages of the project.

How do you test your assumptions?
Do all of these get stored in a document or project tool?
Do both sides clarify them, agree on them and note any variances?


  • See the next section on Understanding to clarify assumptions.
  • Ensure all communication affecting the project are noted in the project tools or document
  • Ensure that both parties have a method to accept these changes
  • Promptly deal with each one.

[ 2 ] Understanding

Sometimes it is as simple as two people being unable to communicate on the same level. Not a technical level but in a way that is understood equally.

When we communicate we explain through the filters that our brain has, from our own experiences and understandings, and we assume that the person we are communicating with has the same filters.

Anyone that has sent a beautiful document using an unique font to someone without the same fonts will understand how both people viewing it see something completely different. This is one reason that PDFs came to be so useful to us, they enabled all parties to see the document/s as they were produced.

Web projects suffer from this problem often, either side jumps to the conclusion they understand from within their own frames of reference or experience and that then becomes how they understand the issue will be dealt with.

Seek first to understand then to be understood.

Habit 5 in Stephen Covey’s 7 Habits of highly effective people is a great method to handle this issue.

A great example is when discussing design. The client might say to your designer “I would like a modern design with lots of flat elements.

In such an example the designer can say, “Great, I get that, we can do that.” And they lock that one in the notes and move on.

A better approach is to acknowledge that and then bring up examples of that in front of the client and get them to clarify what they actually like. Working through example sites, or designs, and getting to understand what ‘their modern’ or ‘their flat’ is, instead of your understanding of the same thing, helps to alleviate you heading down the wrong path.


  • Clarify each requirement with specifics, including examples to ensure you’re hearing what the client is actually saying and not just the words they said
  • Document it, with example images if required so that there is no ambiguity for either team later in the project acceptance phase.
  • Ensure the client approves these documents and examples

[ 3 ] Lack of attention

Lack of attention is related to points 2 and 4. Attention is often in short supply these days, with everyone busy. A significant web project takes up a lot of the key stakeholders time. For the development team they already factor that in, they know they will be busy day in day out on the project.

Most clients say they understand they will be needed, however their business doesn’t stop for them just because they have taken on this new site project. They often don’t advise you of upcoming deadlines in their own work, holidays, key staff absences due to business matters.

Invariably these all impact on you the development team, but in regards to this topic, their work stresses can mean they will give you approvals or feedback which hasn’t had their fullest attention.

They’re working on an assumption that they can fix it later with you.


  • Written approvals throughout the project
  • Clear communication of the impact of approvals. E.g. An approved design can’t be changed within the scope of work, any changes after approval will incur out-of-scope costs.

[ 4 ] Lack of detail

Detail is often missed between steps. It is often left out of scoping documents or quoting documents because it simply hasn’t been raised.

It can be because the client doesn’t have time or doesn’t want to pay for the detail, but rest assured someone always pays for the detail.

Or the lack of it.

The only way to improve the detail in a project is time, time to sit and discuss each item, time to document it and make sure the other person understands it. An experienced project manager or analyst will be needed to ask the questions that draw out all the detail, but mostly it takes time. Invariably time equates to money so short budgets mean being short on details.


  • Detail as much about each page, each function as you can
  • Get everyone to sign off on the details
  • Get the client to provide the details when budgets are minimal by providing the entire scope


Overall you can ensure that most of your projects go to plan by improving a few things in your processes. The following process flow includes the resolutions listed above in a simplified way that you can use to keep your projects on track.

Process fixes:

  1. Document every discussion or request into one document set
  2. When it’s finalised walk the client through it and make sure they actually understand what the meaning is behind what you have written out.
  3. Give them enough time to review the documentation and provide feedback
  4. Repeat steps 2 and 3 once you’ve updated any documents
  5. Ensure your terms and conditions (see your legal advisor) include a term that the quote for work and the project is written there then it is not included.
  6. Have a clearly articulated process in your terms and conditions for ‘out of scope’ works and how they get handled
  7. Manage your project so that you uphold those terms.

When you take a firm and professional stance regarding scoping you set a standard that benefits both you and your clients.

If you are the client ask for a process like this and invest the time to ensure it is done this way.

Whether or not the scope is done up front or during the process, if you employ better processes you can help make sure both sides get great results.

Related News