3.4 How to Determine If it is Going to Work

I deliberately focused on the pieces and parts relevant to the build-out. Exhibit 7 recounts cables, trunks, and circuits. It ignores the technologist's buzz, such as Lightweight Directory Access Protocol (LDAP), synchronizing with e-mail, and the alchemy of embedding one's mellifluous voice inside an IP packet and zipping it across a fast Ethernet wire between e- mails from the boss. Although that is fascinating to me, knowing it does not make me a better project manager.

Actually, I got the scoop on IP Telephone as shown in Exhibit 7 from the three project managers on our team who were responsible for product selection, telecom plant, and voice service rollout. Except for one glitch early on, this piece of a very complex and political project was one I felt comfortable with almost from the start. First of all, I had done a few voice and data projects before so, once I filled out the technology questionnaire for the IP Telephone, I felt I could deal with it. Far more important was the fact that these three project managers proved to me that they were up to the tasks at hand. That is a bonus of approaching the vetting process this way. It gives you the opportunity to evaluate technical people or managers while reviewing their technologies with them. It helps you determine who can be trusted and who just might require a little closer scrutiny.

It is also worth mentioning that the table holds project requirements, high-level tasks to rollout IP Telephone, a Plan B for the risk of it not working, and a postimplementation support strategy. That is not a coincidence , by the way. Requirements, tasks to accomplish them, task owners and dates, and real-time status are all you need to consider. If you decide, when the project is completed, that you want to become an IP Telephone guru, knock yourself out. But for now, stick to your job, which is making sure this thing is going to fly right side up and can land safely, too.