Cheers,
Laura

I have to politely agree with you (with a somewhat red face). What I meant, but did not write, was that any attempt to define the requirements precisely & completely up front (ie define and freeze) is guaranteed to kill the quality. I agree there has to be a first pass for planning. That’s the trouble with blog comments. One just dashed down one’s thoughts without checking that the words reflect one’s thoughts. Mea culpa.

@DougGtheBA I agree, getting the implementation team involved early is a great way to encourage collaboration!

@Alex Papworth I sympathize with the inability to change your situation and applaud how you are approaching things to improve them. I love the statement about “bringing the requirements alive” and that is a main driver behind my passion for UI prototypes.

@James Christie Thanks, thanks, thanks! I agree that as you define and build (and define and build) changes unfold. Flexibility can lead to increased creativity and better solutions. But I have to politely disagree that “ANY” attempt to define requirements upfront is going to freeze the wrong set of requirements. I am all for defining features/scope/etc upfront at a certain level to support planning. It’s the freezing and the sense of a contract that creates negative behaviors, such as the steamrolling you mention.

@Joseph Butson Thank you. I do agree that stories are mini-contracts and that some of the behaviors can surface at a micro-level within an agile environment…no less maddening and possibly worse because you must deal with them every day.

@Jonathan Babcock I have used the baseline concept. I think it is a good one. I can also remember (to my personal regret) wasting a good week or two facilitating a baselining process when we could have been digging deeper into the most risky unknowns. Was the trade off in time spent baselining (and aligning the multiple development groups involved) worth the delay in getting into the gnarly details? Probably, given how the organization approached projects at the time. However, in more recent projects I’ve focused on baselining at a higher level of granularity, giving the team more wiggle room in the details as we learn more. I’ve actually found it to be faster.

@Paul Thomas I vote cynical AND realistic, unfortunately. I am just not willing to accept that we should knowingly sacrifice quality by engaging in a process in which we know it will be sacrificed. I think you bring to light the fact that this problem is really one to be addressed at the executive level. It’s difficult for an exec to sign-off on big investments with relative uncertainty as to what they will get for the money. In reality, they might be doing it anyway. But it sure is compelling to have a defensible contract to fall back on.

Big waterfall projects are fixed up front so that a goal can be met, and that goal is cost, not quality, no matter what any high-falutin’ supplier CEO might try to tell you. Once the client fixes the price they’re willing to offer, the supplier fixes the services they’re going to supply for that price. The more ambiguity they think they’re taking out of the scope up front, the better. (We, of course, know that cheap requirements are ambiguous requirements.)

Once price is fixed, the PM is measured on his ability to hit that price, with sometimes the deadline being the second most important measurement, sometimes the first. Quality is expendable. The requirements contract is a round-about attempt to fix quality, but not the obvious way it seems – no, the point of a requirements contract is to force the client to accept both changes and the cost of those changes in order to receive a working product. The changes to the requirements bring the project back on track and realise the potential for profit to the supplier.

Cynical or Realistic? You decide. Anyway, cost-based measurement is the issue which has to be relieved, if not entirely solved, before the up-front scope setting contracts can be released from duty. In brief, you’re talking Agile!

By the way, (if you didn’t notice) I really dislike the requirements contract, and tend to set high estimates for my time if asked to work within that framework. At least then I, with as much of the team as I can muster, can give it the best shot I can at being right first (and only) time.

Paul