The Myth of Right First Time

The major difference between working in a public institution and working for a private company is a perception that delivery dates are not important. Or rather, that delivery dates are not as important as getting it "right first time". I saw a presentation by Ken Schwaber a few years ago where he started by asking, "When you start a project, what is the first thing you know about it?". The answer of course, is "the date". This has certainly been true of every private company I have ever worked for.
I now work for a major National library and this is definitely not true. The date is hardly ever known. People still talk about time pressure, and there is this vague sense that we are too slow, but nothing compared to what I have experienced elsewhere.
What many people say however, is that it is important, nay vital, to get it 'right first time'.
This manifests itself in a couple of ways: First, most projects start with a huge, costly and lengthy requirements gathering exercise where everyone is invited to give their input and their opinions are collected in the greatest detail. Secondly, there is an emphasis on defining the data that must be collected (the metadata) and the form that it is saved in (usually some flavour of xml).
I have a number of problems with this:

• For any non-trivial system, it is not even theoretically possible to completely specify the requirements.
• Even if it were, by the time you had implemented a system based on these perfect requirements, time would have moved on and some of the requirements would be obsolete
• A lot of the requirements are speculative, based on what we might want to do in the future, rather than what we know we need to do now
  
• No company I have worked at has ever had the money or the time to implement all the requirements of any system. I suspect that not even Google has enough money or people to implement all the things people want them to do.

So what is the solution? Well, we need to set people's expectations right from the start. Go to the customer and say, "We can't possibly afford to build a system that does everything that you might to do, but what we can do is build a system that supports what you need to do. Want we want to do is to get you up and running as quickly as possible. What we'll do is work together to define the simplest thing that can possibly work, we'll implement that and you can start using it. When you've had it for a while you'll know the bits that need improving and we can work together to fix those bits. We'll keep going, improving things bit by bit, until the system is good enough or the business has something more important that it needs us to do."

Do you think it might work?