On 11/28/2013 1:46 AM, Stephen Cameron wrote:
> My theory is that the idea of issuing tenders, which is based on
> defining requirements up front, is just plain wrong for complex software
> systems, that are essentially part of the culture of an organisation.
The problem of writing requirements up front is that one often can't
know all the important aspects of the problem until one gets well into
trying to solve it. Same with quoting a project - early on, you can't
quote with precision unless the job is very similar to others you have
done. But a contractor has to know what it's bidding on in good detail,
so you can't just leave lots of details until later.
> The only solution is to get people with the expertise to do ALL the
> work, including writing a specification if necessary, and to take ALL
> the risk.
And right here is a good example of the confusion many people and
agencies have, one that often causes no end of difficulties. There are
requirements, and there are specifications. And they are not the same.
Requirements are what the end user/agency needs to accomplish,
specifications are testable statements of behavior that, if passed, help
to show that the system will accomplish the requirements.
They are not the same. The builder can only design and build a system
to meet a set of specifications - because they are what can be tested.
The requirements - needs of the customer - ideally will mesh with the
specifications (or the other way around).
Let's say, for example, that you are the buyer of a car to be developed,
and one of your requirements is that the car has to be able to transport
a family of four at least 400 miles between refueling stops. Fine. The
vendor will have to say "well, a family of four, we will take that to
mean two adults weighing an average of 160 lb apiece, and two teenage
children, height 5 ft 6 inches, weight 130 lb (sorry, metric users!).
"transport" we will take to mean drive at an average speed of 55.
Good. Off we go to design and prototype. We estimate the weight of the
vehicle, then we can estimate the amount of fuel, and by iteration we
converge on a workable design.
But now the customer comes back and says that the adult weights must be
170 lb, the teens will need more room, and oh, yes, the customer forgot
about baggage.
OK, fine, maybe the changes can be accommodated, maybe they can't. But
the vendor can't now accept all the risk for failure. The vendor quoted
the job, but now the basis for the original quoted design has been
changed. Maybe the changes make for an overall system that's no longer
feasible. Maybe a complete redesign is called for. Now there are lots
of risks, and the vendor can't know how much to charge to account for them.
Though this is a very simplified example, it's realistic in the sense
that this kind of change goes on all the time, and ordinary contracting
practices just aren't up to handling it. "The" government (whichever
one you want to talk about) can be pretty bad about it, but not just
government buyers.
