TrashingRequirementsEngineering

I went to a Gilb seminar about stakeholder value in IT projects where twenty of us discussed such things as contracts and project management approaches. One of the participants gave me a free copy of his third book on project requirements with a glowing inscription and a hint that a review on Amazon would not be out of place.

I read parts of his book and concluded that common practices and indeed respected best practices in Requirements Engineering accepted as the definition of a project, a list of essentially binary requirements, typically specific functions that the product of the project is intended to offer. This is misguided since it does not make explicit any quality goals or any stakeholder value as vital parts of the definition of the project. What I told him is that by his standards a project could be evaluated as a success without anyone benefitting or even using any part of the project. How foolish.

Instead we should identify and quantify and specify measurement tests for the ten or twelve, not fifty or two hundred, critical goals of the project. These are to be chosen and specified to enhance the effectiveness of the organization which is paying for them. Rather than having a list of functions, typically insufficiently specified, gathered from a number of putative stakeholders, we would then have a way to measure real progress. We would also stand a much better chance that our work would actually get used and that it would actually help.

This is the foundation of Gilb's recent book "Competitive Engineering; A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering using Planguage". His book is hard to read, but chock full of great management ideas which actually work. His book is, I think, still available as a PDF at http://Gilb.com or from in soft cover. Very practical pamphlets detailing some uses in practice are also available from http://Malotaux.NL or anywhere that Niels Malotaux gives a talk. He is often less expensive than Tom Gilb and he hasn't written any five hundred page books.

So I told the guy who gave me his book that it was all crap, indeed that the entire basis of Requirements Engineering was misdirected and should be completely replaced by more valid project definition methods as laid out by Gilb. He agreed but also suggested that my idea would go over like a lead balloon and he could not see how to approach that needed paradigm shift.

Gilb suggests that we should ask for contracts with clauses demanding that if the project does not cure the problem being addressed, we don't have to pay for it. He calls them "no cure, no pay" contracts. When that seems risky for the implementors, he suggests that each project should be delivered in so many phases that no more than two to five percent of the project resources is at risk at any point. Typically his project approaches accomplish real payoffs so early in the project that there never is a big debt for the project to start paying off after completion of the whole thing. It really means that you confront reality often.

On the other hand, only if you insist will you be able to find and implement such an incremental or evolutionary solution to the problems the project is intended to address. I have today convinced myself that ExtremeIncrementalism is wise and efficient in many things. Finding a sensible way to build a toolset to make this easy in various circumstances has captured my thoughts for an hour or two. This note is one incremental step in making the notion useful.

While I was composing this, I got MeasuringProgress in an email from the author with a note that he had heard from TomGilb that if he wanted a critical reviewer, he should send a copy to me. He did and I will serve that role. If you have comments about either this or that it might help me perform that role more effectively, so have at.

I might do it for you if that is what you want for some new manuscript of your own. I prefer to do it before publication so that my nitpicking can have maximal benefit.

Updated: Sunday, August 20, 2006