Having been on both sides of thie fence here I think this was a pretty “safe” article.
On the one hand being upfront and honest is key when you are acting as a vendor.
On the other hand…you do it too often, or you don’t fully explain and get buy-in from your client…they will hate you even more and think you’re a predatory vendor doing a few things:
1) Stalling: You’ll need to provide some kind of tangible update and evidence of your good faith at this “honesty” session.
2) Screwing: You’ll also need to get 100% buy-in from your client that stopping or re-scoping is the right thing to do. Otherwise, they’ll just think you’re trying to eek more money out.
Here’s why… (that other side of the fence)
1) Organizations don’t necessarily have a good grasp on what doing a fully developed web-application can involve on the part of a developer and development team.
A great example is a simple text change that my company needed to make. We specified the change in the text. That text appeared on approximately 10 pages. Only 8 were changed by the developers and they were blamed for poor execution of our change request.
I have a feeling that the developer thought they had changed everything. I think that the developer needed to ask for the specific pages where those changes were to be made.
On our end, we saw it as something simple. In reality…the developers needed more time and information that wasn’t provided. (ie. the scope for the change request wasn’t defined well)
2) Organizations aren’t as flexible as developers.
When budgets get approved. That’s typically it. In some cases it takes moving mountains to get budgets changed. If you’re dealing with a business unit inside a larger organization…you better be COMPLETELY sure that you know what you’re getting into regarding scope changes and budget adjustments for a project.
Remember…web-developers (yes even great ones) are a dime a dozen. And more often, the best developers are just consulting front-ends that have actual developers in China or elsewhere doing the actual work. So remember your competition before you start hitting that stop button!
You have every right to. And it is nearly always the right thing to do. HOWEVER, organizations don’t “get it” so don’t assume they will magically with an email. You better be 100% clear with them.
3) Organizations are notorious for business-rule changes that effect whatever you’re working on.
Don’t assume that a change request is coming out of the blue only to you! A lot of times things change in the course of a development project internally at a company. Especially one that is developing a complex site or web-application.
Expect it. Build it in if you can. And keep in close contact to help anticipate it.
Remember…only so much can go into versioning with an application. Business rules don’t get versions. They happen and that’s the end of the story on the date they go into effect.
Your clients will see your ability to keep up with them EQUALLY as important as your ability to deliver a quality project. So put on your jogging shoes and get creative with how you handle these things.
In a lot of cases you’ll be able to make a small change that won’t be a big deal. But in other cases you might need to find a way to build your current version in a way that allows the company to do what they want, but then release a more elegant interface or procedure for that in a future release.
Never say no if you don’t absolutely have to.
So in a lot of ways the relationship between the client and the develoer aren’t adversarial. But…it is EXTREMELY easy to fall into that pattern of discourse with them.
The best way I can help you think about it, and the way that I do…
Think about a magical box where you type in what you want and then reach in blind and hope to pull out exactly what you want.
In many ways that’s how businesses feel. They want a very specific thing. However, they are a bit blind in terms of thinking about all the bells and whistles it needs. And when they reach into the box they can only feel the basics of what is being built. That can cause questions, revisions, and worry on their part.
You are inside that box trying to provide them with as much feedback as possible. The more accurate, timely, and complete the feedback is that you provide the better that hand in the box will understand what it is grasping.
Ultimately you want the hand to grasp exactly what it wants, and understand how it got to that point. Problems will occur along the way. The more the hand knows…they more it understands the shape it feels. The less it knows…the more it thinks it’s being tricked.
Be honest. Be complete. Be timely. Be COMPETITIVE.