Telephony Upgrade: An Alternative Approach to Updating Those Old Handsets

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.

• The waterfall methodology has the advantage of a cleaner, more controlled implementation, but requires a great deal more time, work, and planning.
• The agile methodology is quicker and requires less work upfront, but will decidedly not offer perfect functionality when it’s first rolled out, and will involve continual tweaking and iterations.

There are two approaches to solving this problem, which I refer to as the “traditional approach” and the “alternative approach.”

The Traditional 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.

The Alternative Approach

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.

Recommendations

1. Engage the senior leadership team during the entire project. Do not allow the project team to work in isolation. Define a series of gates and touchpoints during the entire project. This will force the project team to engage and inform the leadership team. Also, this approach will allow validation of the expected outcome to align with their vision. A formal sign-off exercise at each stage will be a key success factor.
2. Include alternative end point capabilities. Flexibility is a significant asset to generate adoption and ease of use. Various form factors and capabilities need to be included in the scope, such as wired/wireless handsets, video capabilities, cordless units, and Bluetooth-enabled headsets and conference phones.
3. 3.Capture and organize information. All forms of documentation will be key for a successful project, including capturing various forms of requirements, cost considerations, key assumptions, and risks. Resources involved will remember many of the various conversations or discussions that occurred at a particular point in time. The potential for project failure is high if this information is not captured, maintained, and organized. As resources move into different roles or transition away, so will the undocumented knowledge that has been gathered over the life of the project.

Bottom Line

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.

---

Want to Know More?

Modernize Communications and Collaboration Infrastructure