How not to do system development

Anyone remember the Monty Python skit "How Not to be Seen"? Where I work exemplifies "How not to do system development." We pretty much embody the "too many cooks" philosophy, and so while I am all for getting stake holder input and doing a great job of collecting requirements there are three major changes I would like to see made in our methodology:

1) Get the requirements before development begins. Or at least try. Don't just say, "Generally, we're making a system that will do X, go get started and I'll send along requirements" because what happens when you do this is you waste my time. Specifically, you waste three weeks of my time while I busily code away and get to the point where I'm about 3/4 done with my interpretation of X and then you get around to giving me requirements. Requirements for a system that does Q. Q is not X.

2) Don't involve every single person who might possibly at some point have a friend who has an uncle who's brother's best-friend's girlfriend used the system at Baskin Robbins in the requirement gathering process. Appoint representatives for the stakeholder groups, then get their input. It's kind of like Congress. The stakeholders elect a representative who then joins the requirements group and does whatever the heck they want to do regardless of what the stakeholders who elected them actually want, but there's nothing the stakeholders can do about it in this particular instance. So sure, some of the stakeholders are going to be irritated, but you'll get me requirements in less than six weeks. Oh, and btw, unless we've morphed onto Utopia instead of Earth without my knowledge, even if all of the stakeholders are involved there are going to be some who are upset, because if you're involving 35 people in a requirements definition process, you're going to get roughly 42 different versions of how the system should work. Eventually compromise (or dictatorial fiat) is going to have to come into play. Just start out that way and cut the requirements time by 90%.

3) Rolling requirements, spiral development, etc. are all valid processes. Decide you want to use them up front. Then study exactly what's involved in that. Spiral development does not entail developing a full system, deciding that you really didn't want a system that does X and then trying to modify it to do Q. If you're making that kind of a drastic change, you're really better starting over. If you decide you want X+1 or X+5 or X-3, then sure, spiral works fine, but if you're going from building a boat to repainting the Eiffel tower...that's not a spiral model. Unless of course it's the model for which your programmers' motivation spirals into despondency and despair. In which case you've hit it right on the head.

With those little tweaks, I think we could have a much more 1) productive and 2) fulfilled development shop. Of course if we did that, what would I have to blog about?