If at all possible, try to figure out where your day-to-day point person sits on his company's totem pole. How many layers are on top of him, or next to him, or between him and "Yes" or "No?" Make absolutely sure that a verdict from him, at any stage in any process, represents the verdict of anyone whose consensus or approval he needs. It's very easy to get burned when your point person renders a decision, then you find out two weeks later that his boss's boss's boss just got back from a two-week business trip and is looking at everything for the first time.
Agency squeeze is usually the result of internal politics at the client firm. Either someone's throwing you under the bus to cover his/her ass, or the Big Boss is putting pressure on everyone (including the agency) to deliver additional work, outside of the SOW, for the sheer sake of applying pressure.
You are getting written agreements before investing any significant number of hours, aren't you?
You're going to run into one of two scenarios. First they agree to have a person with the authority to approve, but that person has to run around and gather internal approval before they sign off, and you're now stuck in the same situation you just have a designated "approver" but without veto power.
Second scenario. They just don't approve that language in the contract. We have lots of brilliant language like this in our boilerplate contracts, but most of the time it just comes back deleted. We can haggle back and forth on it a while but eventually if its a big enough deal, we're just not going to decline a large contract because their approval process sucks.
We generally get a pretty sizable chunk of our fee up front (25-50%) and before we first hit design reviews. If crap goes sour during design review we're already holding their money. Now we can still have done more work then they've paid for but at least some of that risk is mitigated while we settle the rest in the courts.
I should note that we're kind of young, but this has never yet happened to us.
Every step has at least 2 iterations.
Sounds great but whats an "iteration"? Is a design of a whole website? What if they want a few tweaks on the about page after the second iteration because that area wasn't fully fleshed out originally?
We also explain the client that anything that does not get revisions or comments from them is automatically approved
Never, ever will this language be approved by our larger clients. We can sometimes get "deemed acceptance" language by but its never "immediate" its usually like "if no feedback is provided in 15 days". The alternative is to have a "pause clause" in (if you don't get us feedback in 15 days we have the right to put your project on "pause" until we can get back to it)
At the point where people are using "the process" and not their brains and common sense, it will cause a disaster and you have to re-invent "the process".
Outlining the working process means that I and my client have an understanding, and that they have less grounds for being surprised about getting a larger than expected bill. It forces the client to be disciplined in their own behaviour, which they wouldn't be without a process.
On the flip side, demanding clients fill out Form 27-B for Change Requests every time they want something changing is way, way over the top.
In addition, a process can help give a client some confidence that you know what you're doing. This is especially true in the technology business, where clients tend not to really understand what they're working with.
How exactly is "a process" going to change that so rapidly?
(I haven't a simple answer and I am also struggling with this problem..)
It works well when the website is an aside to their goal e.g. selling watches. The website is merely a facilitator to this. By setting a process, you can gauge your client's capacity to work with you on the project. If they don't like how you do things, you can compromise or part ways, amicably.
If you are building the product that the client will sell directly (e.g. a web service) then I believe that a process alone isn't going to overcome the fundamental difficulties of the project - namely that your client is probably selling something that they don't fully understand.
The elweb illustrated process appears to miss out a key section - functional specification. We derive our func specs from scoping meetings, navigation structure, required content etc. which is then presented to the client along with user journey flow diagrams. This is presented and discussed before the design stage - thus the functionality is agreed upon far before development happens.
With this approach we don't run into the situation where the client wants to make changes during development which could potentially greatly extend a project's timescale (cost is less of an issue as it passed onto the client anyway).
Why limit the client to an arbitrary number of changes (like 2 in this example?) The whole idea of Agile development is that we cannot know everything in the beginning, so we spec as much as we can in the beginning, and leave room to change our minds at a later stage.
Of course, we explain this way of working up front as well, and we make the benefits clear to the client. They have to buy into this before we start with anything. It works very well when they do buy in though.
Estimates in $$$ desired before start
-> Leads into defining a complete feature set
-> Desire for all estimates in time for all work (BS number, always)
Guarantees on what will be delivered
-> Getting the client on board with paying for time vs. paying for features
-> Offer minimal feature set + what we can do?
-> Dealing with scope creep
Require clients time
-> Many A) or B) given B) is 10 times more expensive
How do you deal with resource planning and also billing?
The times where the changes were big and late, it was usually down to bad communication at an earlier stage.
A really good post. I hate it when the clients ask for last minute features (for free) after not saying a thing about this during the development.