Drum into the head of every developer, user and executive that every added feature costs time, and the later it's added, the more time it costs. And that removing features late in the game doesn't save time; it costs time to cut that code and retest.

Ask users what their plans are for the new system -- how they'll use it, when they expect it. Then concentrate on what will be important to them. Users aren't stupid, and most of them don't have it in for IT. They won't crucify you for bugs as long as there are work-arounds, or for missing features as long as first-draft software does the core of what they need.

Expect to be blindsided by something. And when you hit a hard bump that delays you, tell users and management. They'll be unhappy, but not being warned would make them even unhappier.

Keep reminding everyone that hard work later is no substitute for good design earlier, and that, as Brooks' Law says, adding more developers makes a late project later. Encourage brilliant solutions, but don't count on them. Reward real results, not paper promises. Trust working code, not good intentions.

And remember: Delivering IT systems is still at best two parts engineering to one part black art. Slips happen; you can't avoid them. But promise nothing, communicate reality and stick to the plan, and you have a much better chance of avoiding your own private Vista.