In a CRM project, how to prevent scope creep comes down to four lists agreed in writing before the build starts: what is in scope, what is out of scope, what each side must deliver, and where new ideas go. The people who will build the system should write those lists, not the people who sold the project. It is worth the effort: in PMI’s 2018 Pulse of the Profession, 52% of projects had scope creep, up from 43% five years earlier.
In CRM work, scope creep rarely starts with a big change request. It starts on a call. Someone mentions a newsletter, an outbound idea or one more report, and someone on the partner’s side says yes, no problem. By the next meeting, the client expects it to be done. The advice below comes from a recorded conversation between Vladislav German, founder of Deeps Solutions, Benjamin Wallmann, partner at Deeps Solutions, and Richie Dharma, head of HubSpot at Red Pandas Digital in Australia. It covers both sides of the table: what the buyer should insist on, and what a good partner does.
Key takeaways
- Scope creep is work that nobody priced or approved. An approved change is not scope creep.
- Every CRM proposal needs an out-of-scope list that names the ideas from the sales call that this project does not include.
- Dependencies belong in the scope: what the client and other vendors must deliver, and by when.
- New ideas during the project go on a list for later or through a change request, never into a quick yes on a call.
- The people who will deliver the project should write the scope, and the buyer should ask who did.
What is scope creep in a CRM project?
Scope creep is work added to a project without a decision on what it does to the time, the cost and the people. PMI’s PMBOK Guide (fourth edition) describes it as adding features and functionality “without addressing the effects on time, costs, and resources”, or without customer approval, as quoted in a PMI paper by Richard and Elizabeth Larson. The same paper makes a point that is easy to miss: if an expansion of scope is approved, it is not scope creep.
Change itself is not the problem. CRM projects change all the time, because the team learns how it really sells while the system is built.
In a HubSpot project, or any other CRM project, scope creep usually looks like this:
- A newsletter or an outbound sequence that came up on the sales call.
- One more pipeline for a team that was not part of the plan.
- An integration that turns out to need custom work.
- A feature from a higher subscription tier, rebuilt as a workaround.
Why does scope creep start on the sales call?
Scope creep starts on the sales call because the client remembers everything that was said there, and the proposal covers only part of it. Ben sees this from the implementation side. A proposal that only promises to set up HubSpot is not enough, because the client expects everything they talked about on the call. If the proposal does not say what is excluded, the client fills the gap with what they heard.
The Larson paper names five common causes of scope creep: an unclear scope, no formal scope management, an inconsistent way of collecting requirements, weak sponsor involvement, and project length. It also notes that teams add work nobody asked for because they want to exceed expectations.
Partners will recognize that last point. In CRM projects, three causes come up again and again:
- A yes in a meeting. The partner wants to help and agrees to small extras on calls. Each one is small. Together they use up the budget.
- Missing inputs. The data export, system access or a decision from the client arrives late, and the deadline does not move.
- Workarounds. The client does not want a higher subscription tier but wants its features, so the partner builds something in their place.
Instead of saying ‘let’s bank this for later’, you’ll say ‘we can take care of this’. And then by the next meeting, they expect it to be done.
Benjamin Wallmann, partner at Deeps Solutions
How to prevent scope creep: the four parts of a good scope
A good scope has four parts: what is in scope, what is out of scope, what the work depends on, and a list of ideas parked for later. The first part is in every proposal. The other three are often missing, and that is where scope creep comes in.
In scope
Name the deliverables, not the activity. “Set up HubSpot” is not a scope. “Two pipelines with exit criteria, a lead routing workflow, four dashboards and training for 12 users” is. A specific list is easy to check at the end of the project, and it becomes the base of your CRM project plan.
Out of scope
Write down what was discussed but is not part of this project. Vlad’s rule is to move every side idea from the sales call into its own block.
The best way to scope, what I found, is to include a block for out of scope. You talk about a lot of stuff on the call: a newsletter, an idea for the outbound and everything. You’ve got to make sure you cut all of those bits and pieces and put them in out of scope.
Vladislav German, founder of Deeps Solutions
The list protects both sides. When the topic comes back mid-project, the partner can say it is part of a later project, and the client sees that it was not forgotten. In Ben’s experience, most clients are fine with that answer. An IBM project leader gave the same advice in PMI’s PM Network: identify what is outside the scope during planning, and agree on both sides of the boundary with the sponsor.
Dependencies
List what the client, and any other vendor, must deliver before a task can start. In a CRM project that is often a data export from the old system, admin access, a decision on pipeline stages or an API key from another tool. Richie recommends putting dependencies inside the scope of work: if the client does not deliver the input, that part is not delivered. This matters most when other vendors are involved. The partner should not carry the cost when another vendor did not do its job.
A dependency only helps if you use it. Ben says the clause is always in Deeps’ scopes: the timeline depends on the client providing the information. In practice, he admits, he has been too nice. With the finish set for Saturday and Tuesday already here, he chased the missing inputs through about ten meetings in three days, then spent the weekend finishing. Sometimes even big decisions were missing. Tie the dates to the inputs and say so early: if the data export arrives a week late, go-live moves a week.
Parked for later
Keep a list of ideas that come up during the project, and review it at the end. It is often the start of the next project, and the client sees that their ideas were heard. Richie’s team uses a simple line on calls: they say they are just thinking out loud, that the idea is possible later, and that right now they stay focused on what was agreed.
Who should write the scope?
The people who will deliver the project should write the scope. A salesperson wants to close the deal and often does not know how long a pipeline rebuild or a data migration takes. Richie is direct about it.
The one thing I’ve learned is that salespeople cannot scope. No way. The implementation specialists need to scope.
Richie Dharma, head of HubSpot at Red Pandas Digital
He adds that both sides must agree on exactly what will be delivered. Sometimes he scopes ten items and, as the project goes on, delivers seven. With real buy-in, the client often agrees at the end that ten was too many and seven was fine. His advice is to do less and roll it out well, because a few things that work have more impact than many that do not.
Scoping also takes time that a sales process does not pay for. Ben’s rule is to know exactly what you need for the proposal and to get it in one call, or two if the project is complex. Deeper discovery belongs in the paid project, not in unpaid sales calls.
What should the buyer insist on?
A buyer should insist on a written scope that answers six questions before signing. The answers also help the internal champion, who has to defend the budget and the date to finance and leadership.
- What exactly is in scope, listed as deliverables?
- What did we discuss that is out of scope?
- What do we have to deliver, and by when? What happens to the date if we are late?
- Who on our side approves changes?
- How is a change request priced and approved?
- Who wrote the scope: the salesperson, or the people who will build it?
Ask one more question when a feature depends on your subscription: does it need a higher tier? Vlad learned this the hard way. A client wanted features from a higher HubSpot tier without upgrading. He built workarounds and spent far more time than planned, and some of them did not work.
The client blamed me, that I was a bad guy, that I didn’t make it work. And I realized the problem was actually that I did not communicate to her clearly that you need to upgrade.
Vladislav German, founder of Deeps Solutions
His rule now: if a feature is part of an upgrade, you either upgrade or you do not have it. He does not build workarounds, because in most cases they fail. For a buyer, the lesson is to get a plain answer on licences before the project starts. Which HubSpot plan do we need? helps with that choice.
How do you handle a new request during the project?
Handle every new request the same way: check it against the written scope, then park it or price it. Do not agree to it on the call. Ben’s point is that this is easy when expectations were set early. You do not feel bad telling the client that something is for later, because you never promised it. The trouble starts when someone says it is no problem right away.
A change request can be short: the change, the hours, the price and the effect on the go-live date. One named person on the client side approves it, and the change goes into the scope and the plan.
How Deeps scopes a HubSpot project
Every Deeps project starts with an analysis of how the team sells. You get a quote after an intro call. For complex projects, the first step is a paid discovery that ends with your HubSpot architecture and a project plan, and the price of the build is based on that plan. How much a HubSpot implementation costs explains what changes the price, and How involved does our team need to be? lists the inputs your team provides. For the steps after the scope is signed, read our CRM implementation plan, or see what a HubSpot implementation includes.
Frequently asked questions
What are two common causes of scope creep?
Two common causes are an unclear scope and no process for handling changes. Both are on the list of the five most common causes in a PMI paper by Larson and Larson. In CRM projects, a third cause is common: ideas from the sales call that the proposal never mentions, so the client assumes they are included.
Which action is most important to avoid scope creep?
Agree on a written scope that lists what is in scope and what is out of scope before work starts. Then send every new request through one person who approves changes. Most scope creep starts with an unwritten assumption or a quick yes in a meeting.
How do you handle scope creep in Agile?
In agile projects, new requests go to the backlog instead of into the current sprint. The Scrum Guide (2020 version) makes the Product Owner accountable for ordering the Product Backlog and says no changes are made during a sprint that would put the Sprint Goal at risk. For a CRM project run in sprints, the backlog is your list for later.
Is every change in a project scope creep?
No. A change that is described, priced, planned and approved is a scope change, not scope creep. CRM projects should change when the team learns something new about how it sells. Scope creep is only the work that slips in without that decision.
