Eli Bendersky's website It's funny how coincidences go. I've just read a chapter of "The Pragmatic Programmer" called "Stone soup and boiled frogs". It's about what I call "guerilla prototypes". Here's an excerpt:
You may be in a situation where you know exactly what needs doing and how to do it; the entire system just appears before your eyes - you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."
It's time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added...", pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.
This is *exactly* what I'm now in the middle of at work. Being fed up with the managerial slowness to perceive required changes, I developed a prototype of a tool that's very much needed in our group (see my recent posts on Qt and coding frenzies). Now I'm already on the "safe" side - I've shown it to the manager and the demo was very successful - he got really excited and permitted me to keep working on it and create a full product.
I've tried this "guerilla prototyping" a few times in my career, and it almost always worked very well. When it doesn't work, you find out relatively soon and not much is lost - except a little time... At least you know you tried and won't have regrets. When it succeeds, however, the satisfaction is great and it's good for your reputation. Besides, these small "solo flights" are the more enjoyable kind of programming.
I'm glad that I'm in sync with the authors of Pragmatic Programmer on this :-)