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.
Microsoft’s overlapping endpoint management solutions (SCCM, Intune) have confused users. Microsoft itself has acknowledged this problem and resolved it by uniting its co-management services under one banner: Microsoft Endpoint Manager.
Clearlake Capital is shaking up Ivanti’s leadership. Expect greater focus on efficiency and acquisitions beyond ITSM and IT operations.
Configuration Manager (ConfigMgr) is leaving System Center and joining Intune under the Microsoft Endpoint Manager (MEM) portfolio. It’ll take years to stop writing SCCM, but co-management is an exciting feature.
VMware and Citrix are promoting their flagship digital workspaces to CIOs as a way to improve employee engagement. If you implement them without stakeholder involvement, or adequate resourcing, it will backfire.
Mobile enterprise application platform (MEAP) vendors give organizations the opportunity to enter the mobile space by providing the capabilities to develop native-like applications through a code-once-and-deploy-everywhere approach without the need for comprehensive technical expertise of the target mobile platform.
With the sale of ConnectWise to the same equity firm that owns much of its competition, is concern about a monopoly in the MSP software space warranted? We say no.
Google expanded its Android Enterprise Recommended program to include 15 managed service providers across the Americas, EMEA, and APAC. This should improve Android device traction in the enterprise.