How do you get a client to understand the importance of a project lifecycle?

Question

Situation is I have a number of in-house clients who continue to have trouble grasping the concept of defining clear requirements for a project and committing to them. Unfortunately my job situation is that I can't decline such projects, and I am often forced into situations that I can tell are doomed to scope creep (or worse) from the very start. Telling them that detailed requirements are vital and why we need them (using examples of past troubled projects due to this) have not helped.

I am looking for techniques, tips, words, etc that you might use to motivate or illuminate clients in such situations to the necessity of requirements,setting milestones, etc.

I am only a developer, and not a manager.

Answer 1

Draw the Time-Quality-Cost triangle on their whiteboard:

.

Explain the trade-off: It's physically impossible to satisfy all 3 properties. They want good quality in a short time? It's going to cost them dearly. No time, no money? Then they're going to see it in the shoddy quality. High quality, low cost? That'll be ready whenever it's ready!!

This doesn't exactly address requirements and milestones, but it may plant some kind of seed that says, "Hey, if I leave stuff too late I'm going to end up paying more or get worse quality."

Answer 2

Here's a tip that usually works - if in the middle of the implementation they come up with "yet another feature", you should put on a straight face and require that contract, delivery date, payment be updated to reflect the new feature "cost of implementation". After a few of these, you should be noticing a sharp decline in a number of feature creeps.

Answer 3

Throw the entire business-buzzword-gauntlet at them. They need to see the big picture by being proactive in order to leverage inter-department synergy and improve the bottom-line. How could they not be on board?

Seriously, when they request a change, you need to mention the following:

1. In order to implement the change at the time they need it, what feature(s) should be delayed? Can they afford to delay the entire project?
2. Get them to commit to an increased testing/approval schedule. You may have to repeat the tests on completed areas of the project.

As a profession, we need to get over this. It's going to happen, be prepared. You'd be surprised at the reactions of users when you present your concerns calmly and professionally. Often times, the reaction I get is, "Oh, if it's that much of a problem, forget it." If they accept the delay and extra work on their end, so what. But if you have a reputation of whining after every request, you've lost credibility and won't be taken seriously.