The senior leadership team has finally decided to replace the ancient private branch exchange (PBX) platform. As you investigate and begin to plan the project, you examine the handset at your desk.
The handset is so old that its original beige color has turned to a darker shade of yellow. The two-line display doesn’t work, the buttons to the right of the dial pad stick, most of the paper labels are blank or missing, and you have no idea what features or services are configured on it.
This is a challenging project because you shouldn’t simply perform a “lift and shift” or “an in place upgrade” and deploy a newer handset. Several system limitations may hinder the business’ ability to implement a solution.
Many manufacturers of PBXs are no longer in business, or have been bought out, and their old platforms discontinued. If the manufacturer were still in business, odds are it would have long ago declared the product’s end of life, and ceased supporting it. Your infrastructure team may have already been forced to purchase spare parts off eBay, or pay a service provider to find parts and come on site and to install replacements. Asking the infrastructure team to pick up another larger scale project like replacing the PBX could push an already overwhelmed team past the breaking point. You can’t help but wonder, “Why does any of this really matter to the end user? It’s just a phone!”
Once you’ve moved from anger through to acceptance, you’ll begin considering how to tackle the project. Your first step will be to choose whether to follow a more traditional waterfall methodology, or a new-fangled “agile” approach.
There are two approaches to solving this problem, which I refer to as the “traditional approach” and the “alternative approach.”
In my experience, working within IT, I have executed several phone system replacements. My approach aligned to a more traditional methodology of documenting the current state of the solution, building out what the potential future state of the solution will be, and identifying the gaps.
This traditional approach includes activities like compiling long, detailed to-do lists, such as lists of existing services, features, phone models, phone system templates, and hardware/ software versions. Simultaneously, you would work with the various business units in an attempt to create an extensive list of traditional business requirements and document end user work flows to understand how they use the existing solution.
Executing the first phase using this approach can be very time consuming and costly. One significant issue that comes to mind is the existing IT staff may have insufficient resources to dive deep into the end user needs.
Define a minimum set of requirements based on working with an existing business unit that is “friendly” with the IT team and comfortable with change and new technologies. The business unit would need to be willing to help with developing a proof of concept (PoC) of three to five effective features and work flows that would modernize their working style and focus on “the art of the possible.”
This alternative approach ensures that the business unit isn’t stuck using an old or inefficient working style due to the limitations of the originally deployed legacy technology. Validating that the new work flow has no negative effects on the end user requires completing some simple stop watch times and comparing the number of keys or clicks from the old way to the new way.
You can improve the adoption of the new solution, as this approach allows the business to have direct input into the process and to confirm that the outcome will meet its needs. Furthermore, the IT team can now engage additional business units to spread “the good news story” that other units have successfully moved forward with a new solution.
Both traditional and alternative approaches to phone replacement projects are valid. The traditional approach is better suited when phones cannot have any downtime. The alternative approach is a more “agile” approach to phone services, and is a leaner approach — but it requires more forgiving end users.