It’s About Sentiment, Sustainability & Plausibility
Let’s turn our attention to a second major area of consideration in a platform decision, which is about evaluating the viability of both the current and alternate, or switch, platforms.
This has to do with understanding current user sentiment, anticipating the sustainability of the solutions over time, and gauging the plausibility of achieving your objectives by switching.
A Leading Indicator for Change
Now, when considering platform viability, the obvious and logical place to start is by quantifying user sentiment with respect to the current solution.
This is almost always the first thing we do: we send out a survey to users and literally ask them, “how satisfied are you”?
For example, shown above is one from an actual client engagement. In this case, 8% of respondents say they are either extremely or very satisfied. However, 47% show clear dissatisfaction.
With one simple question, we get a clear indication that something might be amiss.
Two More Indicators for Change
We also quantify two other factors, namely the user’s perceived benefit vs. burden of the current solution. Once again, we ask users explicitly, with two more survey questions: “is the current solution beneficial to you?” And, “does it impose additional burden on you?”
In the case shown above, 31% of users believe the current solution is not at all helpful or beneficial to them, and more than half, or 57%, believe it’s only somewhat beneficial. Meanwhile, 69% believe the current solution imposes additional burden on them, above and beyond any benefit it provides.
With such lopsided answers, we see that the current solution is facing serious challenges. But what might explain that?
Let Users Express Themselves
To answer the question of what might explain user sentiment (and therefore to develop a case for change), we should also understand the underlying cause of sentiment. So, we typically expand our quantitative analysis with qualitative information.
And, the best way to do that than to let users express themselves, in their own voice, in interviews and open-ended questions.
This lets us hear, in vivid and colorful terms, what users find confusing, inconvenient or lacking in their day-to-day experience with the current platform.
Finding the Underlying Cause of User-Stated Issues
When we analyze all of the user-stated issues together, themes and patterns start to emerge.
For example, when we categorize issues as reported by end-users into functional buckets, we often find that most issues — 56% in the case shown above — are related to process, complexity, and lack of collaboration and visibility.
Which is good insight — but don’t stop there. We should also go a step further, and pinpoint the underlying cause of these issues.
When we do that, a very telling picture often becomes clear: in the case shown above, it turns out that 61% of the issues were directly related to platform features, idiosyncrasies or constraints.
In other words, these issues are not things we can easily improve with training, tweaks or enhancements. In this case, the issues are actually foundational in nature, which inevitably take a significant, and lasting, toll on user adoption.
Considerations to Achieve Adoption
Let’s remind ourselves one more time: ultimately, we’re striving for adoption of an operational system of record. With that in mind, how would we characterize our platform’s viability of doing so?
Well, in many cases, the main distinction between the current and switch platforms is basically this:
The reality is that with results such as we’ve seen earlier, the current platform often faces an uphill battle with respect to generating adoption:
- User sentiment is well established and gelled since the current platform has often been deployed for many years
- Credibility will need to be re-established with tangible improvements for both platform and solution (rather than simply communicating the promise/potential)
- Challenges are often foundational constraints resulting from the underlying platform itself
- Challenges are often “death by a thousand cuts” rather than attributable to just a few issues
- Pull may be elusive, meaning a top-down mandate and communication initiative may help, but not likely to generate adoption “pull”
- Result: we’ll have to “prove it” with major, tangible improvements in order restore confidence in the current solution
On the other hand, a switch-based solution often begins with enthusiasm. And, that going-in enthusiasm can make a switch attractive toward generating adoption, although there could be some caveats as well:
- Aura of fresh & new: a new platform will benefit from initial enthusiasm in the eyes of users (with little hands-on experience)
- Solution credibility likely to be assumed by end users — and even hoped for — from the start of a deployment initiative
- Catalyst for change: the potential exists for the new platform to serve as an impetus for organizational change
- However, inexperience will likely take a toll (at some point) with discovery of unexpected constraints & idiosyncrasies
- And, bumps are expected — but they will be unplanned (and possibly unpleasant) surprises
- Result: we’ll need to work quickly to deliver tangible capabilities and frequent wins in order to sustain the initial enthusiasm
In short, we encourage you to consider deeply the medium and long-term implications that each platform could have on adoption. It really goes to the heart of platform viability and long-term sustainability.
Considerations about Plausibility
Finally, when assessing platform viability, there’s always one question everyone is hoping to answer: how can we determine — preferably before we make a final decision — the likelihood of success, or plausibility, of a platform switch?
Well, there’s no magic analysis that will give us a definitive answer. But, we would recommend three general areas to probe.
Customer References
The first (and obvious) thing to do in order to gauge likelihood of success is to check customer references, especially those that may have struggled during their deployments, and understand their lessons learned.
Ask vendors to provide meaningful references, and don’t be shy about asking people you may know in user groups or discussion communities if they know of any as well.
Key Capabilities
The second is to carefully analyze the platform’s capabilities with respect to key functional needs that will be instrumental toward meeting your objectives.
For example, with respect to work management, these are typically important capabilities to validate:
- Workflow templates: understand the methodology and validate with specific examples
- Conditional branching & sub-processes: understand technical details (or workarounds)
- Online reviews & outcomes: consider review iterations, annotation and voting capabilities
- Task management: assess the end-user’s experience with prioritizing and managing their work
- Schedule & resource management: investigate the project manager’s experience in managing initiatives and assigning work
- Reporting & dashboards: look at canned and personalized views of work status & associated information
- Integration framework: analyze thoroughly, especially with respect to providing consolidated visibility (e.g. for spend)
Hands-On Feel
Third, and probably most important: try to get a hands-on feel, not only for the platform, but also for the vendor, and the vendor’s partner ecosystem. Specifically, take a good look at these areas:
- Review specific use cases (and brainstorm with platform solution experts)
- Experience platform hands-on via workshops, training and “day in the life” exposure
- Visit the platform’s offices & assess their culture
- Consider the platform’s partner ecosystem & user communities
As they say, the company you keep can make a world of difference. So, we’ll say this with special emphasis:
After all, those are the relationships that you’ll be relying on as you build your switch-based future — we would even say they’re every bit as important as the platform itself.
Next Steps
We’ve hardly scratched the surface — so much goes into a carefully considered platform decision! Don’t worry, we’ve got you covered. And, as a next step, we invite you to check out some of our other posts:
- Platform Decisions: When & How to Build a Case
- Platform Decisions: Evaluating Fit
- Platform Decisions: Assessing Viability
- Platform Decisions: Estimating Impact
- Platform Decisions: Testing Assumptions
- Platform Decisions: Differentiators & Productivity Levers
- Platform Decisions: Thoughts About Change
- Platform Decisions: Getting All The Juice
Leave a Reply