Fighting the Scope Creep

Scope creep is the process of adding more and more features to a fixed-cost project at the end of the development process or during delivery.

Long story short, the client expects more features, better UI, or additional services within the agreed quote, which is not expected and hasn’t been planned by the web development agency.

We have written a long Scope creep post for the DevriX tutorials section defining the problem, how to identify it, and the possible resolutions (at least for new projects).

Project Success rate

The CHAOS report identifies the majority of the projects as projects that failed or led to additional features and budget loss.

This is an important topic for the WordPress community as well, especially given the fact that many decent project management practices cannot be implemented within the standard budgets provided by thousands of small agencies and freelancers.

Not Winning Projects

This one is painful. We know what scope creep is, we know how to avoid it, and what actions to take in order to prevent it before starting a project. However, all of the actionable items lead to communication overhead, extra costs or models too flexible for our prospects where they can’t predict the end cost.

We literally get various requests for “A small social network” or “Design and a new theme for our startup”, with expectation of a direct proposal about the price and time frame. Once we start discussing everything in order to get a clear idea of the project and the proposal, that gets too complicated for the client (being unaware of what they really want) so they bail.

We are aware that it’s impossible to give an estimate of “we want a design”, but sometimes the client’s expectations and budget are a good fit for us – but the risk of adding tons of extra features before delivering the project is pushing us back.

Examples of Scope Creep

A seemingly minor change may take weeks. This puts some pressure on the tech team whenever the scope and the budget are somewhat predefined. 

Let’s discuss two recent instances where scope creep had been a problem in our projects.

Recently, we launched the public portal for a website. The client was great and the website was quite interesting. The platform interacted with a few other applications that we had to integrate ourselves.

The retainer plan was 250 hours a month and our initial planning included some buffer for unexpected surprises.

Suddenly, it turned out that our front-end layer integrated with the other platforms caused a wide set of conflicts. There were 4 different versions of jQuery defined across different pages (including one back from 2009) – with another set of dependent libraries for each of those. We were using jQuery for some animations, interactive menu items and the like.

We ended up with a list of 100+ pages causing different problems with some of the pages, some of the time. There was a launch date planned for version 1 which we had to get sorted asap. It required rewriting a big chunk of our integration, including the SSO and some of the APIs built initially that worked on our end.

Another instance was a WordPress platform migrating from a visual builder to another dynamic solution with editable fields. There were 4 different teams involved and 3 sites updating content simultaneously. The hosting vendor was inadequate, limited technical support (no ssh), a broken migration and sync feature and the like. That brought a hundred extra hours to our previously assigned 30-hour task.

Sure, all of those could be handled earlier – but not all stakeholders are fully aware of the impact of those changes or the complexity of the different components across the technical stack.

Common Causes of Scope Creep

Most of those requests that lead to scope creep in project management are often those relating to design and functionality. 

Design Challenges

Some of our web development projects come with PSDs, so we have a clear idea of what’s going on.

However, it’s clear that some text needs to be changed here and there, and most features should be dynamic. The problem is that we can’t extract every single text field, icon or image to a customizable link – imagine the icons of the header menu, all footer links and texts, or lots of additional gradients, icons, images provided in the PSD.

Another thing is migrating existing content to the new design – even if we’ve agreed on a design spec, migrating hundreds or thousands of entries leads to edge cases that don’t fit the design (misalignments, missing blocks, long text snippets), but compliance for everything is hardcore.

Functional Gotchas

There are standard features like Google Map’s pins, the jQuery datepicker and more that come with default design. We’ve discussed those features and have a general design proposal, but later on we get specific requests for changing third-party scripts and libraries. Last week we were asked to change the Facebook share dialog and change a few bits in their own API, which was technically impossible (and I’m not talking about the general Open Graph fields, but the workflow and their panel).

Another example is migrating data – we keep receiving quizzes in Microsoft Word documents that cannot be parsed due to inconsistent formats, and we need to deal with data management and migration of thousands of entries.

How Project Managers Deal With (or Prevent) Scope Creep

A common approach in project management is adding a multiplier that is usually between 1.5x to 3x on top of the initial quote estimate proposed by the team before sending a quote to a client. 

The multiplier allows for a safety buffer that will cater to unexpected changes and surprises along the way, misses from the initial requirements, or communication overhead that needs to be accounted for.

However, even with this “safety buffer”, a huge percentage of projects still fail.

Budgeting dynamic features or general ideas is close to impossible – we are not mind readers, but preventing scope creep without adding a lot of overhead in communication and budget and losing projects accordingly is just as tough.

There are general tips and tricks to avoid scope creep, but in practice we’ve encountered issues with several projects so let’s touch on the different ways you can possibly approach projects with clients to avoid scope creep.

1. Tailor-Fit Project Costing

For smaller budgets, we try to keep our costs down in order to fit a number. This means that for some projects we don’t budget documentation, personal training, code reference, unit tests, continuous integration environment or so. Yes, we can add them, but clients don’t appreciate them as they bump up the cost and the other agencies don’t cater for them.

You will most probably get into various arguments about those, and waste time with calls, emails, or various questions for standard WordPress features while ignoring WP101 and other available resources.

Consider these as opportunities to educate them on the challenges of the fixed fee projects.

2. Embrace Scope Creep

Embrace scope creep by communicating it with your client through your proposal and contract. From day 1, discuss scope creep openly with your clients and don’t hesitate to talk about it whenever necessary. 

Write clearly on the documents relating to your project agreements that no assumptions shall be made on things not explicitly mentioned or documented. It can be very tricky as it is a sensitive topic for most people but doing features pro bono is not the way to go. You will gradually have issues with the planned architecture which may require additional time for work and less time for quality assurance among others.

Embrace scope creep by communicating it loud and clear upfront, and charge for any additional requirements on top of the initial scope. New features (when approved) will increase the profitability from your client, and extend the duration of your contract.

How Team Members Can Help Fight Scope Creep

Team members must proactively give immediate notice when an estimate is off and the project/milestone/task won’t be done on time.

If a partial assignment takes 10 days to complete and a developer spends 3, realizing it would actually require 15, the manager is still capable of negotiating extra time once new facts are introduced.

Scope creep is tough and often not intentional. There are practical ways to handle that during the negotiation phase.

Oftentimes, extending a bit due to additional challenges is possible.

Otherwise, the project manager could explain the new context and propose a compromise that is completed on time (with some caveats or edge cases in mind).

As long as developers keep an eye on possible bottlenecks and communicate on time, most problems can be resolved in a civilized manner across all parties.

Your thoughts?