In today’s race for digital innovation, enterprises are inundated with products and services offering a spectrum of capabilities to advance business objectives and fuel innovation. The IT industry spends billions of dollars advertising the benefits of such technical innovation, touting one new shiny object after another as the market’s next leading “solution.”
Commonly now, manufacturer and service provider product offerings are actually referred to as solutions themselves. For example, “We’re using a Cisco UC solution, because Microsoft’s solution wasn’t ready.” Or, “CloudGenix’s SD-WAN solution will increase performance and reduce cost.”
Unfortunately, the word solution has become overused in our industry. Frequently, providers’ so-called solutions don’t represent any value or utility for the enterprise customer at all, which isn’t much of a solution, if you ask me.
A solution is NOT a product or service. In fact, our team doesn’t even use the word solution as a noun. For us, solutioning is a process, a series of actions, a verb. It’s the discovery, analysis, evaluation and testing required to achieve the target technical end state.
When we advise enterprises regarding technology modernization and transformation, we focus on three distinct areas of the solutioning process:
- The target end state itself
- The optimal operational support model
- The financial business case and optimal commercial structure
But, before we break apart the solutioning process first we need a stated problem or opportunity – let’s call it a target outcome. The target outcome is a high-level statement that multiple stakeholders, influencers and decision-makers across the business can all agree upon, answering the question: What is the specific business problem we are working to solve? And the solution is the target end state that will ultimately solve the stated problem, achieving the target outcome.
IDENTIFYING THE TARGET END STATE
It is critical to create a specific set of technical requirements that will shape the target end state. Those requirements should include a stated preference regarding future operational support models and/or requirements in support of current operational procedures.
Too often requirements are not well defined at the beginning of a modernization or transformation program. And, even when requirements are well documented, if they have not been ratified by all appropriate stakeholders, adoption may stall or even fail. This, in turn, leads to delays and disruption for related programs and can, in the extreme, halt progress across the organization for months or even years.
In addition to establishing well-documented requirements, it’s also critical to have a carefully documented and detailed view of the current state, including a baseline inventory of the current infrastructure and services as well as current application requirements. Future application requirements must also be understood as well.
It’s tempting to ignore legacy assets – after all, they are the legacy and this is all about looking to the future. But, we can’t ignore the past. Old protocols, legacy applications, and poorly structured commercial agreements are just a few examples of legacy issues that interrupt the process of modernization and transformation. It’s critically important to identify these challenges up front.
With these insights in-hand, the next step is to identify the multiple potential approaches that might meet the formally stated technical requirements. This means including non-incumbent and even disruptive (new market entrant) service providers as well as the legacy firms that support the current infrastructure.
While you don’t want to create analysis paralysis, it’s important to review market alternatives with the clear understanding that no offering is perfect. That said, the optimal offering is most certainly the function of a broader, more comprehensive solution set that considers many different possibilities.
The last part of identifying the target end state involves identifying which technical “solution” best meets the stated requirements. And, while this step may start as a paper exercise, for large-scale modernization and transformation programs there really is no replacement for lab testing and pilot implementations that stress-test new technical solutions in a production environment.
CONFIRMING THE OPTIMAL SUPPORT MODEL
Once the target end state is better understood, the optimal support model can be identified. Often, however, this part of the solutioning process is easily overlooked. Be sure to ask questions such as:
- How will we transition to the new service platform, and how long will that take?
- What are the key implementation risks, operationally and financially?
- What is the plan to decommission legacy technology?
- And, perhaps most importantly, how will we support service on Day 2? Do we have the skills, the training, the tools, and the required operational support procedures to ensure performance once we have reached steady state for our new technology?
Since we’re talking about new technology, very often the answer to this last question is a resounding, “No.” In that case, existing operational and support limitations may very well shape the technical solution itself, especially where constrained resources or skills gaps may indicate the need for training, staff augmentation, or third-party service management.
Regardless of the circumstances, it’s clear that both the technical end state as well as the future Day 2 support model must be evaluated in parallel, as these two levers help shape the final outcome.
NAILING THE BUSINESS CASE
Once the optimal technical and operational target end state has been identified, it’s time to seek internal approval and funding to launch the transformation initiative.
Unfortunately, this is where many projects often die due to lack of funding and investment dollars. Programs may also be hindered by some other economic or commercial constraint, such as long-term financial commitments from past capital investments or a current supplier.
For whatever reason, if the numbers don’t work, the deal doesn’t get done. Although, often a “no decision” is more expensive in the long term. But that’s a story for another day.
You may still be wondering why it’s important to confirm the current state in detail, if it’s all about replacing the old technology with a new solution anyway. There are lots of reasons having a solid handle on the current baseline is critical, but one key reason is this baseline enables the identification and elimination of waste and inefficiencies in the short-term, which helps to fund modernization and transformation programs in the future. We do this work with our clients every day.
Even if you don’t lack funding or investment, you can seriously jeopardize the achievement of your business case if you don’t have a handle on legacy infrastructure and services. It seems silly to say, but companies tend to be a lot better at implementing new technology than they are at decommissioning legacy services. And, there’s no better way to break a budget or spawn unforeseen problems than running a dual infrastructure for an extended period of time!
Finally, and forgive me for stating the obvious, but please do not accept a ROI, NPV or financial business case that’s prepared by the bidding provider. The extra assistance may sound nice, but external suppliers lack the information about the customer’s environment that is required to credibly project financial impacts. Not to mention that they’re obviously incentivized to make the most attractive savings projections possible, no matter how unrealistic.
More than once, I have seen a service provider propose savings greater than the current expense. That’s a great deal, if you can get it!
HOW TO SOLUTION YOUR OWN BEST TARGET OUTCOME
So, what can enterprises do to move from product and service proposals to a truly integrated solution that will minimize risk and maximize value? Here are a few specific suggestions to start your own “solutioning”:
- Clearly define the target outcome in ways that can be measured and compared
- Clearly state requirements that must be met by any optimal technical solution, and make sure all key stakeholders contribute to and ratify the requirements statement before the sourcing and selection phase
- Make sure you are looking at the long-term support model for your target technical end state. Be honest and realistic about staffing and talent concerns, and modify the technical solution as required to ensure your firm can adequately support ongoing operations
- Make sure you include non-incumbent providers including startups and disrupters
- Work the business case creatively. There are many ways to fund transformation through short-term savings and optimization, and many ways to structure a winning commercial deal