Does Your WFO Provider View Implementation as a Process or a Project? The Answer Matters.
The two approaches operate under distinctly different sets of ground rules signalling a solution provider’s degree of implementation flexibility.
Is a software implementation a process or a project? What’s the difference? It’s just semantics, right?
Far from it. The lens through which one views an implementation determines methodology, the software provider’s degree of flexibility, the makeup of their implementation teams and more.
An implementation process — its inputs, outputs and every step in-between — is defined by the provider; it’s solution centric. They’ve painstakingly constructed a universal set of checklists, detailed instructions and preordained lines of communication-based on their solution’s requirements. Every detail of the process is precise, documented and fairly inflexible, and the unique character of a customer’s business tends to be treated more as an impediment to the implementation process than a reason to modify it.
A WFO solution provider that speaks of implementation as a project, though, implies a high degree of customer centricity — that each implementation project is discrete, its methodology organized around a particular customer’s business processes, regulatory requirements, size, industry and numerous other factors. The provider recognizes that every customer is different, from their IT organization to their reporting requirements to the ultimate value they expect the solution to deliver.
The distinction between a process and a project approach to implementation manifests most visibly in their methodologies, team makeup, and level of consultation.
Methodologies and a Templated Approach — Implementation templates aren’t inherently bad; in fact, provided they’re not inflexible, they’re necessary for navigating the different phases of an implementation. In the hands of a solution-centric/process-minded provider, though, templates can be blunt tools for pounding square pegs into round holes.
Does a hospital record calls for the same reasons an online retailer does? Of course not. The hospital’s primary motivation may be audit protection — proof that they’ve complied with regulatory requirements for safeguarding patient privacy. On the other hand, the online retailer may use call recordings primarily for their agents’ customer management training or sales training. In this example, a one-size-fits-all template would consider the implementation of the Call Recording module to be the end-goal itself instead of recognizing that the module is a means to an end — that end being helping each organization meet its unique call recording requirements.
Teams — A process approach also discounts the importance of team continuity, the assumption being that any individual or collection of individuals can be plugged into a well-designed process. Arguments in favor of providers dedicating the same individuals and teams to a particular customer, their implementation project and beyond are obvious: personal relationships, a shared experience/frame-of-reference over the life of the project, faster issue resolution, etc.
Ideally, the software provider would dedicate many of those same individuals (for instance, project managers, implementation engineers) to the customer, even in the post-implementation support stage and throughout the product lifecycle. After all, you may want to implement more advanced features down the road after you’ve had time to adjust to and evaluate the new WFO solution. When that time comes, wouldn’t it be great to talk to the people who initially implemented the system?
Consulting — A process-minded WFO provider may tend to treat implementations more programmatically, meaning that if a customer wants feature-A, that’s what they’ll get, regardless of how unsure they are about their requirements for feature-A. The burden of figuring out how to maximize the solution’s value post-implementation falls disproportionately to the customer.
Project-minded WFO providers tend to look at implementations more granularly, interviewing intended users, conducting ideation sessions, analyzing data and adjusting the implementation parameters accordingly. For instance, the more closely the provider can define the customer’s requirements for feature-A through collaboration, the more they can narrow the gap between what the customer envisions and what the feature ultimately delivers.
— — — — — — — — — — — — — — — — — — — — — — — — — — — —
Virtually every WFO implementation project, even in the smallest contact center, merits an individualized project plan. The plan should be fine-tuned through a collaboration between customer and provider and should define everything from the project’s scope and objectives to the required documentation, technical design and timetable.
Most importantly, an implementation should fit like a tailored suit, reflecting the customer’s business processes, regulatory requirements, size, industry — everything that makes each organization one of a kind.
