Melissa Swartz | April 21, 2021
I’m working on a relatively large project with a client who has migrated from a 20-year-old PBX to Microsoft Teams for telephony. Many lessons were learned, but one was unique to the pandemic work environment.
This organization, like most others, sent employees out of the office to work from home. Some essential personnel remained on site, but most worked remotely. Calls from external parties were forwarded to cell phones, and business continued.
While the employees were gone, the IT team rolled out the Microsoft Teams voice application in multiple phases. There was ample communication on the rollout’s status, and numerous opportunities for user training on the new voice capabilities added to their Teams application, but the pandemic changed the nature of the deployment. Because they weren’t on-site, it was much easier to place the new phones on desks without disrupting users. The phones, however, sat unused for months while people worked remotely, communicating through computer apps and mobile phones. Numbers were ported from the old system to Teams Direct Routing in phases, which occurred behind the scenes, and was unknown to the users.
Pre-pandemic, when there was a big event (or several phases of events) porting the numbers was the trigger for “Go Live.” The implementation project (or phase) was completed after the initial day one support, troubleshooting, and cleanup.
That has changed. With the pandemic, there was no event or reason to “Go Live.” Numbers were ported in phases, but the users were (mostly) unaware of any changes. Calls came in through the Teams app on the user’s mobile phone, rather than the phone itself. Most users didn’t understand or notice the difference.
As employees trickle back into the office, several issues have surfaced:
- A time gap existed between initial training and actual use of the phones and applications.
- Users didn’t prioritize training because they weren’t required to use the new phones right away, so attendance was low. Some users had the attitude that they didn’t need training on how to use a phone because they already knew how to pick up the receiver and say “Hello.”
All of these issues created additional Help Desk tickets and took time to resolve. Additional training classes have been held and recorded for future reference. The team has since figured out how to resolve the undocumented use cases, and users have been reminded (again) not to use the old phones.
With no “Go Live” event(s) and the usual spike in activity, the question remains: When is the project done?
My client has decided to disband the implementation project team and declare the migration “done” because they need the resources for other tasks. The finish date was essentially arbitrary, rather than driven by an event.
Their four criteria for completion included:
- All numbers ported
- New phones, headsets, and soft phone capabilities deployed
- All users offered opportunities for training
- Staff training on the new solution has been completed
They are transferring all remaining issues (including the decommissioning of the old phone system) to the existing day-to-day teams and processes. They recognize that there may be more activity than usual surrounding the phones, and have prepared internal resources to handle them.
Have you given any thought to your project’s “done” criteria? If not, it’s time.
How do you make sure that your RFP gets the responses you need? How you phrase your RFP requirements can make all the difference.
Tips for reviewing the cost structure of your next cloud communications service.
Hardware devices are difficult to source this year. But as my client migrates 10,000 users to a new cloud voice solution, we must proceed.
An RFP that is issued at the proper time in the process, is supported by a thorough needs analysis, and clearly articulates the requirements of the organization, is an effective tool.