1

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.

Improve this question

3 Answers 3

Reset to default
7

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

Time-Quality-Cost Triangle.

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."

Improve this answer
1
  • I didn't think about this one yet, nice idea. Its a project management standard and something they may have seen in their travels as well. Commented Nov 4, 2010 at 4:28
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.

Improve this answer
2
  • haha, the infamous staring contest. it would work great if payment was involved, cept its in-house and payment doesn't work that way - we are sort of "always on-call" developers. Commented Nov 4, 2010 at 4:26
  • @jellyfishtree: same method just different words: "we're gonna have to rebuild widget x to accomodate the new features. It was never designed to work that way." Commented Nov 4, 2010 at 5:02
1

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.