I've done a bit of management consulting and found that a good formula for making a system that works is this: 1) Talk to management about what their goals are

I've done a bit of management consulting and found that a good formula for making a system that works is this: 1) Talk to management about what their goals are, and what kind of resources they have to get there. 2) Talk to the people that will actually use this system, and make sure that they all get to comment and put ideas into it - even if they are minor. These are the people that will be using whatever system is being built, so they know where it hurts. 3) Come up with a rudimentary plan of the system. I normally build a a simple mock-up in HTML so that it will be understandable to everyone. 4) Talk to the people that will be using the system again, and show them what you have come up with. Inevitably they will offer changes, because you didn't understand them right the first time or because they didn't explicitly know what they wanted, only the problem they have. Keep doing this for a few iterations changing your HTML as you go. Make sure to get buy-in from management along the way. 5) Use the HTML as a template for your spec. 6) Implement and test. 7) Deploy. This step is the easiest of them all, since all the employees (or at least a good part of them) have eagerly been awaiting the fantastic new system that will take away their itches with the old system. They know because they all helped design it. And since they all helped design it they are all eager to make it work. I'm constantly amazed at how it seems that corporate systems are all designed and agreed upon by management and consultants without asking the users first. The author of the article seems to have fallen into this trap, and only just discovered this simple insight.