A common objection to a project plan is that it doesn't do enough--it doesn't have all the features that users will inevitably request, or it doesn't take certain situations into account.
Or as TechRepublic member biancaluna recently put it, it "does not solve world hunger nor does it wash my car or bake a pecan pie". But in my experience, those omissions argue for it rather than against it. Certainly, you don't want to preclude features that will be needed in the future, but if you try to anticipate all of those features in the initial design, you'll never complete that phase.
Rather than designing in everything from the top, start small but make your design modular and extensible.
In my response to biancaluna's comment I said: "In the future, whenever someone tries to shoot down an idea because it doesn't do enough, I'll say 'DNSWH'." Does Not Solve World Hunger. It's also a good response when someone is trying to pile on the features.
A company I used to work for had a long history of cowboy coding--that is, "we need feature X, so just go code it up." Naturally, after several years, this resulted in an unmaintainable mess; they got design religion and began requiring a lengthy design process before any code could be written.
To insure that nothing important was ever left out, they held daily design meetings involving a dozen or more people--each of whom was trying to impress everyone else with how many nits they could pick. Only a handful of projects ever emerged from this phase after months of bickering, and those projects went on to become bloated applications with so much feature noise that they were almost unusable.
What's even worse is that the projects didn't solve the original problem, which was to keep existing customers happy and to draw new customers in; instead, they focused on solving world hunger.
A number of times in my consulting career I've had clients want to ditch their product and start over from scratch. Perhaps the UI looks "old" and needs to be redone; or the code is so mangled that they think it is beyond hope; or they've hired someone who thinks that a certain language or framework is the philosopher's stone that will magically turn their applications to gold. These projects almost never succeed.
Why? Because they're too big. Yes, you can certainly recreate that application in Ruby on Rails in a fraction of the time spent on it to date, but do you realize how much time has actually gone into it? Chances are it's in the hundreds of thousands or even millions of hours. Even if you can develop ten times faster than the original, do you have several years to do this?
Sometimes it's easy to mistake how big these projects really are because their requirements aren't fully known. The projects have evolved over many years, and features are sometimes added without being documented; yet users rely on that behavior, and if you take it away, you're going to end up pasting it back in. Do that enough times, and your new, pristine version will end up being the same mix of baling wire and bubblegum that comprised the original.
It's almost always a better idea to make incremental improvements instead. That requires long-term vision of where you want to get someday, without trying to do it all at once. Lay out a general plan for the future, and then create a specific project to do just the first step. That helps to minimize the risk of failure and keep the project scope manageable.
It's easier to agree on the design for something that does only one thing well--and it's easier to tell when it doesn't. More importantly, you can get user feedback before you proceed to the next stage.
Trying to do too many things at once multiplies your chances of project failure. One company I worked for back in the 80s provided turnkey solutions--that is, they wheeled the system in, and all the user had to do was turn the key. The vendor provided the hardware, the operating system, and the software.
One bright day, the vendor decided to upgrade their database architecture. To do so, they needed a new version of the programming language and its runtime environment. That version was only supported on certain operating systems, so an OS upgrade would also be required for most users. The applications (mostly accounting) still needed regulatory changes, and they felt that they couldn't go a whole year without adding some enhancements as well.
To keep things "simple", they decided to do all this at once--to more than 1,300 supported users. It would be great--what could possibly go wrong?
The OS upgrades ran into hardware support issues. The language runtime was still pretty green on some platforms and introduced a massive number of failures--none of which showed up in QA, of course. But certainly a redesign of the database architecture should have been a simple task, right? No. Application bugs abounded due to touching just about every module.
The support lines were overwhelmed. Extra people manned the phones, including all the programmers. As a result, it took a long time to fix the issues. Meanwhile, we'd go home at night only after we attempted to call back every customer who had logged a call, but by then it was so late that they had given up on us--this added up to more than 700 users every night for months.
Did we keep all of our customers? No. Did we add any new ones? No, we tried to solve world hunger instead.
In retrospect, we should have taken on only one thing at a time. Upgrade the language runtime on one platform only where we already had users who wouldn't need an OS upgrade. Don't touch the database or the code until that's stable. Continue one platform at a time until the new runtime version is gold. Then look at changing the database--but only a portion of an application at a time.
Taking this sort of measured approach, we would have been able to slip in regulatory changes and even some small enhancements along the way, without breaking the customer's back.
For us consultants, limited scope is one of the key benefits of short-term contracts. In, done, out. But we can apply the same principle to long-term engagements as well by dividing each project into bite-sized chunks.
When a project looms massively before you, ask how you can cut it up so you won't choke on it. Identify the optional features and move those to the end, where they can be lopped off if you run short. Don't try to solve world hunger--feed one user need at a time.