My Methodology
“Respect the process!” We’ve all heard those three little words for many years. It was recently popularized by Marcus Lemonis from the reality TV show, “The Profit.” That simple phrase carries loads of weight when it comes to project management. Without this formula, chaos and frustration would erupt in short order. Documenting and following a process made my life easier; outlined a roadmap for the team; and made it possible to aggressively upgrade the 50 sites -- and a few extra -- in 2018.
Establish Repeatable Processes
Wash, rinse, and repeat. Ford made it possible to mass produce vehicles using a production line. Likewise, I needed a repeatable process to upgrade 50 locations in 12 months. Build a project plan. Follow it. That’s fine -- nothing new. But I wanted to take it a step further.
I built a system, and used my workbook as the framework for EVERYTHING (more on this later.) As far as I was concerned, if something important about phones wasn’t documented in this workbook, it didn’t happen. My workbook contained multiple tabs to collect various information. It allowed me to apply the same process for each project over and over and over again.
To kick off a site upgrade, I’d begin with an all-hands team call to introduce the project and let the business know that the cost is covered in my budget. Next, I hit the FAQs. Then, I moved on to roles and responsibilities, expectations, timeframes, training, technical aspects, and the logistics of porting on the go-live date. After doing a few VoIP migrations, I began to memorize and give the same speech for the kickoff call of each project.
Determine and Prioritize Locations for Deployment
Our company has more than 250 offices in the U.S. I needed to select 50 of them. To help make my selections, I first reached out to our TEM provider to gather data. My question was simple: “What portion of our circuits and landlines could we eliminate with a cloud-based solution, and how much do we pay for them?
After gathering that data, I had to identify candidate sites and prioritize them. I probably could have analyzed 10 different perspectives and played with the data in 20 different ways (just ask any statistician). Paralysis by analysis could have been an easy trap, but time was ticking, and I had a sense of urgency riding on my back. To boil it down, I simply needed to grab the low-hanging fruit.
I mined our data looking for answers to a couple of questions:
And then I broke that down to a cost per phone.
Since our voice systems were as diverse as the fish in the sea, I had no way of connecting to each system to pull quantities of stations. The next-best method was to merge an employee count from PeopleSoft, our enterprise resource planning database, with a telecom operational cost per site to arrive at an average cost per user. While each employee doesn’t necessarily equate to one phone, I concluded that this method was going to provide the best average. Perfection is the enemy of good enough. Over-analyses would drag me down, and I knew it. With few exceptions, I found that the data supported what I already suspected.
In general, small offices had a much higher operating cost (per user) and upgrading these offices would produce a quicker ROI than upgrading larger offices. Dial tone in the cloud is nothing new to small businesses. But what about medium-sized or large companies? Where is that tipping point for keeping voice on premises rather than putting it in the cloud? The results to that question are very interesting… but a discussion topic for another day.
Several other factors influenced if and when a site would be upgraded to cloud-based voice. Questions I considered included:
What costs can be eliminated after moving to the cloud?
Formalize Discovery & Data Collection
Gathering all the necessary information to make each VoIP migration a smooth transition must be done ahead of the order.
The cut sheet must be completed as thoroughly as possible. I made it clear to the business that the cut sheet is what the carrier would use to program the new system. The programmer would be someone they never met, not me. So they couldn’t make any assumptions. Every field is a required field, and if it’s not documented in the cut sheet, it won’t get programmed in the new system.
The trunks, circuits, POTS lines, DIDs, toll-free numbers, etc. all must be identified and documented.
The DHCP server, VLANs, IP scopes, network switches, cabling limitations must all be known, documented, and shared with several team members.
