2.12 Analyze and Incorporate Feedback

< Day Day Up >

Our terminal gate assumption stipulated 20 airlines needing 15 gates apiece, for a total of 300. Your feedback will range from "How do you know how many airlines will use the airport?" to "PuddleJumper Airways could not possibly need more than five gates." Stay with the process. Your goal is to come up with as many "hard" assumptions as possible. Once you have established a ballpark number, the right stakeholders will more or less be forced to take ownership for telling you the right number. You have made the number of gates negotiable and opened the door for practical forces to come into play, instead of being driven by opinions that might be uninformed, if not worse. In this case, that process will begin after the architects complete a draft design and cost estimate. That will show that each gate costs, for instance, $1 million to build and $25,000 an hour to operate.

This is really where you want to steer the debate because that is where it is going anyway. People float off into the ether with so many issues that, experience should tell you, will eventually be solved by practical matters like dollars and sense. As project manager, your goal should be to get there sooner than later.

We are going to leave the airport now to look at another example from one of my previous projects. In this one, I watched for weeks as the engineering group agonized over which of two servers to specify for a thin client application servicing several thousand users. We were fast approaching the "must order by date," and I still had no specs from these guys. Finally, frustrated, I sat down with the team lead to understand what their problem was. He was a good guy and all that, but he lacked management experience, so I walked him through the decision points gently.

In short, as he saw it, the only differences between servers were physical size and user capacity. One server was three times the size of the other, but could support twice the number of users as the smaller one. Physical size was not a factor because while we needed dozens of either type, there was adequate rack space in the data center. Both servers appeared to offer the same throughput per user even though the number of users per box was significantly different, as noted earlier.

Finally, I asked one simple question: "How do the two servers compare on a cost-per-user basis?" The engineers had not taken this into account, so we did the math on the spot. We were immediately able to conclude that on a cost-per-user basis, the larger, higher-capacity server was 15 percent cheaper per user than the smaller alternative. Because the design scaled to thousands of users, this delta was significant, and made the choice rather simple, all other things being equal. When you drill down with the right attitude and approach, it is amazing how frequently you can squeeze decisions out of folks who have been wringing their hands over something for weeks, if not longer. This story provides insight on the value you can provide as project manager. Let the experts be expert. Stick to your role as facilitator and provide closure to the open issues swirling around you. In other words, keep everything, and everybody moving.

< Day Day Up >