Why do technology strategies fail?

Summary:How can executives and managers ensure that everyone in their organizations is making decisions which support the same strategy but have the flexibility to innovate and adapt to local circumstances?

I have seen very good technology strategies in conception that have failed miserably in execution because they relied on overly complex frameworks that did not translate well as the strategy was disseminated down the ranks. This is especially true for global organizations.

How can executives and managers ensure that everyone in their organizations are making decisions which support the same strategy but have the flexibility to innovate and adapt to local circumstances?

The answer may be “a set of simple rules that allow employees to make decisions on the fly, act on them, and respond quickly to shifts in the environment”, according to Sull and Eisenhardt. In fact, they found that, “to shape their high-level strategies, companies like Intel and Cisco relied not on complicated frameworks but on simple rules of thumb”.

Developing simple rules requires 3 steps:

  1. Set corporate objectives – what are you trying to achieve: profitability, growth, innovation, social good? At the end of the day, you want to do more than align activities to corporate objectives;you also want to foster coordination across internal groups and create a mechanism or structure that allows them to autonomously make better decisions.
  2. Identify bottlenecks that keep you from achieving those objectives. Where do opportunities most exceed the resources (time, money and people) needed to pursue them? This is key because the rules constructed will be used to push through the bottlenecks. The key here is to stay away from 'broad aspirations' or processes that require thousands of micro decisions and activities which may be spread out across the whole of the organization.
  3. Create simple rules for managing the strategic bottlenecks – focus on the one or two critical processes with which your organization has experience. Take time to identify critical bottlenecks.

A typical approach is to rank all projects based on forecasted future cash flows, then ranking all projects based on Net Present Value. The disadvantage to this approach is it is quite complex, very data intensive, and will open you to computational errors.

For technology projects in particular, this Net Present Value approach leaves you exposed to the risk that disruptive technologies, if assumptions are incorrect, will result in a different ranking.   

Instead, the rules that managers worked from should include examples, such as:

  1. Minimize up front expenditures: Any proposal that required a massive year one expenditure would not be considered viable.
  2. Provide benefits immediately: A Cloud Initiative that allowed your organization greater agility would pass, but one that saw benefits realized in years 3-5 would not, for example.
  3. Reuse existing resources: Rather than purchasing new equipment, see if equipment which is beyond end of life may be salvaged, upgraded perhaps, or optomize workloads to accommodate new projects.

Be wary of rules that contain the buzzwords: innovative, strategic, synergy, convergence. Be wary of rules that require any new project to have a 'positive Net Present Value'. The key is to focus on key areas where this sort of rule generation will have the greatest impact.

There is a balance to creating these rules that must be maintained.

An organization has to both exploit efficiencies through the implementation of standards while ensuring that those standards do not hobble flexibility. This is because flexibility is needed to innovate and seize unexpected opportunities.

Like any other repeatable process, standards rely on checklists-type processes.

A checklist would differ from a rule in that checklists are used to drive efficiency in repeatable processes; whereas, simple rules are to be employed when the challenge is one of needing to adapt quickly to changing situations.

As the authors put it, simple rules “set the boundaries of acceptable behavior while leaving ample scope for flexibility with in those limits.”

Has your organization used rules like these to empower strategy? Let me know.

See also:

Topics: CXO

About

Gery Menegaz is a Chief Architect for IBM with more than 20 years supporting technologies in the financial, medical, pharmaceutical, insurance, legal and education sectors. My Full-Time Employer is IBM. I write as a freelancer for ZDNet.

zdnet_core.socialButton.googleLabel Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.