How to Avoid Mistakes in Technology Evaluation

Ken Oxler, VP-IT Architecture & Chief Architect, Assurant [NYSE: AIZ]
282
461
89

Evaluating and selecting new technologies for use in the enterprise can be a risky business.  It often involves spending millions of dollars and investing critical resources for more than a year to implement the new technology.

It is not surprising that companies want to take their time and make a good decision. Unfortunately, teams will frequently fall into a few patterns of behavior that often make things more difficult over the course of the project. Let’s explore some of those scenarios and a few suggestions on how to avoid them.

Technology Looking for a Problem: This occurs when you have a great technology solution that teams are excited to implement but no one is sure of why we are doing it. In my experience this happens when the technology teams find a new or exciting technology that promises positive benefits such as shorter development or testing cycles. The cause is often a lack of a sponsor, clear business objectives we are working to achieve or any business case that will document the return on investment.

Solution: Before you begin to evaluate technologies make sure there is a designated sponsor and a rationale or documented business case. There are too many cool technologies that may help, so it is imperative as an organization to understand what benefit you expect to achieve.

Misaligned Strategy or Priorities:  Any time teams are working at cross purposes it will create conflict. Too often teams are not aligned when it comes to the objectives on the new technology evaluation. When teams are working with different goals, priorities or incentives, agreeing on a technology selection can be difficult. More importantly, implementation risks can arise very quickly. Looking across team goals can often show why team members are pushing for changes or different options.

Solution: Overall team alignment is a no-brainer, but alignment is often not considered when looking at technology solutions and evaluating products. Consider modeling your approach on the Enterprise Architecture Operating Model, based on the book “Enterprise Architecture as Strategy” by Weill, Ross and Robertson, using a unified versus a diversified technology strategy along with clear business case benefit objectives. This will help your team work together for a common goal rather than individual organizational targets or needs.

We Already Know the Answer: I have had the opportunity to work with highly-skilled professionals whose significant experience and past success automatically leads them to advocate for a particular set of tools. Who would argue with success, right?

The problem isn’t with having a preference in a technology tool, it’s around the evaluation itself. The purpose of the evaluation is to learn something new or better understand what is available in the marketplace. When using the evaluation in this manner a request for proposal can be an excellent tool. If on the other hand the intent is to validate a position or the level of superiority of a particular product then it is simply a waste of time.

Solution: Don’t waste the company’s time. In my experience the success of any new technology has less to do with the technology itself and more to do with the team’s alignment around purpose and ability to execute the implementation. Spending time evaluating tools when you already know what you want is not a valuable exercise. You would be better served spending that time negotiating a better deal or working toward implementation.

Split Decision: This is one of the most difficult situations to resolve. Often after weeks or months of capability reviews, evaluations, demos, etc. you end with the selection team divided over two options. The difficulty comes from needing someone at a higher level to step in and make a call without always knowing the details.

Solution: Do both if you can. I’m not suggesting that you fully implement both solutions, but my experience suggests that you are only scratching the surface with the evaluation and demos. You often learn so much more about a product or vendor in the first few weeks working with their solution.

Perform a Proof of Concept (POC) with both vendors to try and help shake out the better solution. Provide a reasonable use case and limit the timeframe (a few weeks or perhaps a month)for the vendors to deliver, and reevaluate at the end of the POC to determine if there is a clear leader.

Stuck in our Current Investment: Employing technology standards is a key component of any enterprise architecture function but sometimes we get stuck in a rut with a technology in our portfolio. Too many times we ask users to leverage our “enterprise standard” when it doesn’t always meet the need or objective behind the request. Maintaining and adhering to enterprise standards is essential, but it also is important to find opportunity to leverage new technology where appropriate.

Solution: As part of your standards program designate categories of technology where the organization is willing to be more flexible around experimentation or new standards, versus categories where the standard technology is more rigid. This should help your organization stay out of the rut that dictates only the standard be leveraged. Additionally, reviewing your categories regularly will also help identify when existing standards are becoming outdated and in need of something fresh.

Technology evaluations and selections are difficult but you can achieve more success if you recognize and avoid some of the common pitfalls above.

Read Also

Scrutinizing the Complexity of Technology

Ted Kieffer, Director, Enterprise Architecture, Grainger

Tales from Paradigm Purgatory

Brian Scott, CIO, Experient

Delivering Business Value through Agile EA

Kevin A. Wince, Chief Enterprise Architect, General Services Administration (GSA)