Monday Consulting Questions: Scope Creep and Getting Paid
After a 2-week break, here we are again with Monday Consulting Questions. Today I'm just going to tackle one.
Q. I need to negotiate payment on a project that went out of scope. How do I do this?
A. Trying to get paid for out-of-scope work after it's been done can often be like trying to un-ring a bell. Depending upon the circumstances, it may not even be possible. So, let's look at the circumstances.
The first thing to think about is, how do we know this project went out of scope? Do we have a measurable way to determine what features comprise the project's scope, like a functional spec? If not, you have a real problem, because without some record of what the project's expectations were at the start, anyone can interpret anything however they want. To be honest with you, if you don't have anything to prove that the project is out of scope, you're sunk. Start negotiating and be happy to get whatever you can get.
Now, if you do have a scope document, you're on more solid ground. However, you're not out of the woods just yet. Did you set the client's expectations correctly? That is, did you either a) notify the client at the outset that additional features would increase the cost or b) notify the client at the time of the change request that the change would increase the cost? Yes, I know your client is staffed by adult and that adults have no excuse for thinking that more work costs nothing extra, but to be perfectly honest, nobody cares about you or whether or not you are treated fairly. It's sad but true. You get what you negotiate. Nobody will be fair with you; you have to defend yourself at all times. So, if your client can throw up the "but you didn't TELL me this would cost extra" defense, you're in a tough position. At best, you can point to the scope doc and offer to remove the additional features if they don't want to pay for more then the original scope. But in all honesty, the moment a client plays the "but you didn't tell me" card, you're sunk.
The third scenario - the one that puts you in the best position - is that you have both a scope document and that you communicated effectively with the client. The scope documentation proves what you were setting out to build, which means that anything not in that document doesn't exist. So, changes are easy to identify. The communication ensures that at the very start of the project OR at the moment a change request came in, the client was informed that yes, when you request more work, you have to actually PAY for it. This is a one-two combo that even the most dishonest of clients will have a hard time applying twisted "you should work for free" logic to.
Here's how we manage scope around here:
- Every project has a scoping phase, even if it is lightweight. We believe that figuring out what you are building is a normal part of any project. Any client that refuses this and tries to order you to "just get started" is a client we don't want. Experience has taught me that ambiguity is frequently an ingredient in abusive client behavior.
- Clients are informed before the project even begins that changes to the project plan WILL result in a revised estimate. Sometimes, the revision means that the estimate goes down. Sometimes, the revision means it goes up. The determining factor is whether we are adding features (which is usually the case) or consolidating/eliminating features.
- Clients are also informed that some degree of scope creep is normal, because nobody can know in perfect detail what a project will consist of. There are unknowns in everything, and software development is no exception.
I don't necessarily think that scope creep must be avoided. It CAN be avoided, but I don't think it MUST be in every case; sometimes scope creep is a good thing for a project. However, there is no question that scope creep must be managed. The client must have an opportunity to think about the consequences of change in terms of additional cost, longer delivery time, additional complexity, etc. And the developer must be paid for the work provided.
So, the short answer is, you get paid for out-of-scope projects by defining a change process before the work ever begins. Barring that, it's up to you and your negotiation skills. Try to do better next time.
