“Wasn’t That Feature Part of the Project Scope?”

Sometimes I hear that question in my nightmares…

OK, perhaps I’m exaggerating. But it is one of the most dreaded questions a developer can hear from their client.

Why?

Because it inevitably points to impending confrontation, and it’s likely to be costly for one party or the other. In extreme cases, contracts have dissolved and projects have ground to a halt because this question arose.

So let’s talk about why it happens, and then we can discuss what to do about it.

Why the scope is in question.

If, at any point, the client asks about a feature that doesn’t exist but they thought was part of the project (or the opposite – although that’s much more rare) it points to one of two things having occurred: a simple miscommunication, or, more commonly, lack of appropriate planning, management, or oversight.

If it truly is just a simple miscommunication, it’s likely regarding a fairly minor feature or functionality, and is usually easily rectified without much of a problem.

However, most miscommunications can and should be eliminated from the equation through thorough planning and proper project management. At the very least, these factors should mitigate misunderstandings about major components of the project and the overall project scope.

Without proper planning and management, however, scope issues are almost a guarantee. It comes down to the reality of two parties with potentially conflicting goals:

• The client wants the very best end product for the very best price and they probably have a vision in their mind of what that looks like.
• The developer wants a functional product that can be created efficiently and profitably.

If these two parties don’t work hard at the very beginning of the project to agree on every detail of the project, those viewpoints are going to naturally draw them away from each other as the project progresses. The client will always be expecting the most robust rendering of their vision while the developer will always be focusing on the simplest functional product that meets the established parameters.

On the other hand, if both parties do agree on every detail of the project before development begins, both can work together harmoniously in complete agreement as to what the finished product is going to look like, act like, and accomplish. Therefore, the dreaded question should never come up.

What to do if scope is in question.

Unfortunately, if a project is already in development and a question arises around scope, someone is going to have to pay to resolve the issue. After all, adding features to a custom software project (or removing features that were not supposed to be there) requires additional resources from every member of the development team. What may seem like a minor addition from the client’s perspective can actually turn out quite costly if it takes six people an extra 2-3 hours to accomplish.

And this is where the conflict arises: who pays for the change in project scope?

If the developer requires the client to pay for every additional hour without exception, the client will tend to feel like they’re being nickled and dimed. If, however, the developer goes ahead and does extra work without charging anything, they’re going to end up losing money, which inevitably affects their attitude toward the project and can even impact the quality of the work.

So, the best result is usually somewhere in the middle with the client agreeing to pay something additional and the developer offering a lesser rate than usual for the work involved.

Still, that’s not an optimal working relationship, and both parties know it.

A far better option – and one that we constantly stress with every new client we work with – is to invest in an initial planning phase that leaves both parties with absolutely no questions about what the complete scope of the project includes. That way, the project fee and all other details can be agreed upon before work commences, and everyone involved in the project can move ahead confidently.