2.10 Turning Issues into Assumptions

< Day Day Up >

Your next step is getting assigned parties to turn their issues into assumptions. Instead of asking "How do we know how many arrival-departure gates should be built at the airport?" we say, "Let us assume a reasonable number of gates and see where it goes." The reason you do this is to curtail the endless churning of issues without resolution. Your project documentation would reflect that particular decision in the following manner:

It is assumed that each of the 20 airlines will require 15 gates apiece, for a total of 300 arrival-departure gates at the airport. Fred Smith will validate this with the Airline Task Force by March 1.

We may not be too sure about this, but we do it anyway. Once statements are made and circulated properly, people will react. Obviously, you would like to make any such "stakes in the ground" reasonable and rational, so research may be in order. Look for design documents, white papers, or other work that was done when the project was in its "preapproved" state. They might provide some decent baselines. Alternatively, look for similar projects. For instance, if it appears that the airports in Tampa or St. Louis have demographics similar to yours, check out their gate infrastructures.

What you are looking to accomplish is to drive the process off dead center and facilitate timely resolution. Unmanaged issues can take up far too many cycles while remaining open, so that in the end, you are forced to accept anything because you have allowed this part of the project to enter crisis mode. Allowing this to happen, as a project manager, is called procrastination.

< Day Day Up >