Conduct a Thorough Analysis
I would begin analyzing site information as it came in. Sometimes we had to make a “no go” decision, at which point we’d drop the work on that site and I’d move on to another. But more often than not, we’d continue through to project completion.
The analysis is not just a cost analysis. Evaluation of each site’s wiring was also essential, as we often found Cat 3 cabling in use. A lack of Cat 5/6 cabling in some areas meant that we needed to stop and evaluate alternatives to VoIP phones when new wiring was cost prohibitive.
Our network engineer reviewed the switches and routers. Do the switches support LLDP and PoE? Are those features must-have, all the time? (Answer: Not always, but LLDP is usually a minimum requirement.)
Execute on the cutover
Execution, in my opinion, was the easiest step of the project because we had completed 90% of the work during normal business hours in the weeks leading up to the go-live date. Execution was the remaining 10% of the work on the morning of the VoIP migration. When things went smoothly, the cutover was mostly an uneventful conference call with the team while the phone company ported the numbers. The old PBX remained up. Existing TDM phones remained in use. The real event was that inbound calls that rang on the legacy PBX would now ring on the VoIP phones.
This was my favorite scenario (upgrading TDM phones to VoIP) because we placed and tested the VoIP phones well ahead of the go-live date. For about a week prior to the cutover, users had two working phones on their desks. I encouraged users to use their new phones for outbound and internal calls. I asked users to log into their Web portals and I encouraged them to install and use their mobile app. This gave the user community time to become acquainted with the new products before the go-live date and reduced stress when they forgot their voicemail or Web portal password. Inbound calls would still ring to their old phones until the port date. Taking this approach allowed us to complete most of the work ahead of the go-live date.
Some of the legwork still occurred on the morning of the cutover. For example, we had to connect analog telephone adapters to fax machines, external ringers, paging equipment, and analog phones. And, we followed a test plan, which included international and 911 calls, auto-attendant options, dial by name, etc.
Communication Is Crucial
Throughout this entire process, I can’t stress the importance of communicating with team members enough. Anybody can build a project plan, but what’s often undervalued is communications -- both verbal and written. Helping stakeholders see the big picture and understand their roles and responsibilities is one of the biggest challenges I faced. Since I couldn’t fill out a cut sheet myself; draft the script of the auto-attendants; identify network limitations; or provide a floor plan for each site, I motivated others to help with these tasks.
As much as possible, I used canned emails, or templates. I carefully drafted my messages for first contact, follow-ups, go-live expectations, training documents, and help desk process to be concise, but rich and valuable.
Weekly conference calls were equally valuable. Over time, I found, I had memorized my talking points, which helped to eliminate lulls and redundancy. Rather than just lecturing, I had best results when I peppered folks with questions every two or three minutes. Our company uses Google products, so using Google sheets allowed for everyone to be on the same page. I could easily see who was and wasn’t paying attention, and when I saw that someone wasn’t on the same tab of the workbook, I’d ask him or her a question to keep them focused.
I could have used a screen-sharing service, but these are working meetings and require participation from EVERYONE. I put ownership on the business representative to fill out the cut sheet and provide a floor plan. Field IT must provide DHCP server and switch information. Network engineering needs to request new scopes for voice VLANs and document those in the workbook. We all had our roles, and keeping everyone on task was my job.
At the start of each meeting, I’d ask each participant for a status check. If the stakeholder didn’t do his or her homework, I’d wrap up the meeting and say something like, “Well, I booked this meeting for an hour. I’ll give you 45 minutes back to work on it, and I’ll check back with you next week.” That’s it. Meeting immediately adjourned and my message was heard. If nothing was done the next week, I’d repeat the process. If this happened three times in a row, then I’d explain that I’m canceling the project because I have a couple hundred other locations that do want a system upgrade.
Usually by the end of the day I’d receive an apology, along with an email telling me that the requested work had been finished. And we'd continue on with the project.
In part two of this multipart series, I’ll share my lessons learned.
