After all the software industry alone has been notorious for delivering half-completed products that we all use only to find out that we need to continually update and upgrade and up something. But we have been conditioned as a society of technology hungry persons to consider this type of 'delivery' to be acceptable. And for some reasons beyond this article it should be, but in general we should be striving for 100%, right!? I mean if you visit a dinner and order an omelet, you'd be pretty beside yourself if they brought you out a hard-boiled egg and some cheese on the side. But that's just silly isn't it. In IS/IT project management that is exactly what happens when a traditional methodology is used where it shouldn't be. It's not that they didn't want to make you and omelet, and it's not that they purposely thought it would be fun to watch you react to the delivering of the hard-boiled egg, it's that they thought your "omelet" was their "hard-boiled egg". And really who is to blame them? There is currently no way, nor has there ever been, nor will there ever be a machine, device or methodology that will allow one person(s) to know perfectly another person(s) thoughts and needs exactly.

Now some of you may be conjecturing that you communicate with your stakeholders and project sponsor in a way and to a degree that you DO know their thoughts and needs. Well good for you. And communication is key, yea vital to any project; however experience and time is even more stable. Who wants to decide to get married after having only met someone for 30 seconds? Who wants to purchase a house after having it described to them for only a minute? Well the same holds true in project management, and not only on the managing/controlling side, but even more so on the stakeholder side.

Realistically the stakeholders world/environment is changing in ways that a project manager can never be completely on top of. Whether market trends in Asia or the-watercooler-grapevine, stakeholders are the ones aware of what they need; and as time progresses those needs inevitably change or become more clear to them.

All this to say that a FINAL DIAGNOSIS approach to a project is illogical. Why try to be a fortune teller? Why try to be a "project prophet"? You don't know the future, but you do know that it will come. So instead of demanding strict exhaustive requirements to be completed by your stakeholders, why not go with the flow (AGILE). Have a few sessions to cover the broad and some of the specific sets of requirements, then begin coding to a specific subset of those. Building off of the code deliver tiny snippets of functionality and review it with the stakeholders. Using their feedback rebuild/recode to perfection and move to the next snippet of functionality. With an AGILE approach the client/stakeholder becomes who they truly are... the person who needs to be satisfied by the project. After all, who wants a FINAL DIAGNOSIS when they could have a perfectly made omelet?