Fighting the Scope Creep

One of my resolutions for 2014 was to fight in any way possible the Scope creep. We had a few ups in this direction for sure, but overall I’m not satisfied and I will continue pushing in that direction in 2015.

What is 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 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.

There are general tips and tricks to avoid scope creep, but in practice we’ve encountered several major issues with several projects.

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.

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.

Additional Deliverables

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.

At the end we reach to some of those and clients expect these to be delivered. We get into various arguments about those, and they keep wasting ours and their time with calls, emails, or various questions for standard WordPress features while ignoring WP101 and other available resources.

More to come in 2015

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. We will continue tackling these issues in 2015 and keep proposing agile models for our customers, and educate them on the challenges of the fixed fee projects.

How do you deal with scope creep and WordPress project proposals?

One thought on “Fighting the Scope Creep

Your thoughts?