Three Rules to Survive in an Age of Tight Budgets

We've done the obvious things to save money so now we need to find smarter ways to deliver solutions

Survive Tight Budgets

Money is tight and many industries are feeling the squeeze. Budgets are being trimmed – if not outright slashed – and we need to do more with less.

We’ve done the obvious things. We’ve eliminated waste by disposing of unused licenses and assets. We’re moving fixed costs to variable costs so that services will flex with the business.

All of these tactics are backwards-looking though. They’re one-time savings resulting from trimming the fat and tightening our belts.

The challenge is not just making our existing IT solutions a little more efficient. We need to find ways to create the new solutions that the business needs without breaking the bank. We need to find a low-cost approach to enterprise IT.

IT is no longer an engineering profession

The success of many business used to rest on the on the quality of its tools. If the tools – a business’s IT systems and processes – broke then the business would fail. We spent our time engineering capital intensive, complex IT solutions that would withstand whatever the we threw at them.

Today, though, reliable solutions can be purchased as-a-service.

The success of many businesses now rests on their ability to respond to changing market conditions. Our challenge is to furnish the business with a set of tools that it can use to quickly adapt to the ever changing market.

The old capital intensive, complex, IT solutions are the legacy that is dragging many IT departments down. Legacy thinking is our albatross.

What are the new guiding principles?

But if enterprise IT is no longer an engineering challenge, then what sort of challenge is it? What are the guiding principles we should use as we craft solutions to the problems that our business has?

We don’t need to look any further than the low cost consumer industries for our inspiration.

  1. Keep the core solution simple
  2. Provide sensible options
  3. Only pay for what you use

Rule 1: Keep the core solution simple

Reduce the complexity – and thereby the cost – of the technology you use. All those fancy options take effort to implement, and this effort must be paid for. If you can keep your core requirements simple then you can use a cheaper solution, and you can (largely) avoid the expense of customization.

Most solutions on the market today are more than capable enough for many organizations. We don’t need to spend our time trying to find the “best of breed”, knowing that the best might only just be good enough.

Apple stripped back the smartphone, simplifying how we interact with it, and created a more satisfying experience in the process. Zara develop a constant stream of fashionable but simply constructed clothes and revolutionized the fashion industry.

Basecamp, from 37signals, did something similar for project management. They realized that most projects don’t need the complexity typical project management tools brought with them.

This trend toward simplification has grown beyond small teamware tools to include tools to support managing small organization. The trend is moving upstream to larger and – traditionally – more complex solutions. First project management. Next email and desktop automation. Today CRM & ERP from SaaS vendors such as Salesforce and Workday.

It might be wise to consider which solutions deliver the outcomes that your organization needs, and then change how your organization works to match the tool. Rather than trying to (re)configure the tool to support unique processes.

Rule 2: Provide sensible options

Provide a small but logical set of options so that teams can tailor solutions to their needs by selecting the options that they find the most suitable.

Avoid the “one size fits all” problem where all stakeholders are forced to use the one, monolithic, expensive solution that tries to cater for every eventuality. This results in you needing to either overcharge the smaller users – often discouraging them from using the solution in the first place – or let them ride on the coattails of the larger users.

Building one large, complex solution was right approach when creating an enterprise application was akin to launching a rocket to the moon. You only get one chance and you need to make it all the way to your destination so you better pack everything you’ll need for the journey. Saber – one of the first, if not the first, airline reservations systems – is a case in point, with the final solution including everything from back-end mainframes and applications through networks to the terminals the staff would use to access the solution.

Unbundle your products and services – just as the low-cost airlines have – and provide a small but logical set of options that the business can use to construct their own end-to-end solutions. They might have bought the flight, but do they need the meal?

These days there’s an app for that. If we need something small to add onto our CRM or ERP then we can often buy an app or module from the marketplace provided by our platform.

You’ll need to work with your customers to understand what options they need.These options will also change over time as the business and the market around it evolves.

Rule 3: Only pay for what you use

The last and possibly the most important point as it ties the other two together. You might have provided simple base solutions with a reasonable set of options, but if the price is not connected to the choices the business makes then it’s all for naught.

Encourage consumption-based models using sensible business drivers – per seat, per … – so you only pay for what you use. This is the key to the low-cost model.

Three rules to bind them

The persistently tight margins we seem to be experiencing mean that it’s time to move beyond belt tightening.

Luckily we don’t need to look far for inspiration. The low cost consumer industries can point us to three key principles that we can use to help the business optimize.

  1. Keep the core solution simple
  2. Provide sensible options
  3. Only pay for what you use/li>

If the base solution is simple then you get a  low starting price. Providing a sensible set of options allows the business to adapt the solution to meet their changing requirements. A consumption-based model can help you ensure that you’re never paying for anything that you’re not using.

What do you think? Is the current belt tightening a passing fad? Or do we need to find new and smarter ways to procure the technology that allows the business to do more with less?

Image sourceKen Teegardin

About the Author: Peter Evans-Greenwood

Peter Evans-Greenwood is the editor of CIO of the Future. He's also a author, advises independently to CxO, is a Fellow of Deloitte's Centre of the Edge, and lectures in his spare time.
  • Paul R. Taylor

    Rule 2: Provide sensible options. Making this so depends largely on whether your core solution sits on a current-generation platform that can support an integrated, consumer-driven eco-system (such as your examples of AppStore, SalesForce and Workday), in which case you have the extensibility you describe. If the core system is on a 10 year old ERP/MRP enterprise application dinosaur, the re-engineering is a more costly proposition, often involving non-trivial middleware and integration complexity and expense.
    Can you illustrate with some stories of where people have opened up legacies or ERPs to create dynamic ecosystems which exhibit the characterisrics you describe?
    Or are we talking a platform migration here?

    • http://peter.evans-greenwood.com/ Peter Evans-Greenwood

      Hi Paul,

      I think we’re at the start of a big platform migration as I don’t see how low-cost models can be done in a sensible way with legacy ERPs. The challenge is to know when to jump. Do I go early to try and find a competitive edge? Or do I wait until competitive and/or financial pressures force me?

      Luckily the investment to turn-on these new solutions is a lot lower than was required by the last generation, though it’s still had to get past the sunk cost problem, writing of an expensive asset that the finance department are still depreciating.

      r.

      PEG

  • Todd V

    Just a few thoughts on this…

    When we talk cost drivers being sensible we must take care that their variability does not compete against business growth. What I mean by this is you must ensure that the “per” factor for licensing is not completely correlated with business growth. “# employees” works fine for a business that has sufficient capacity to grow without needing new employees after every sale / deal / etc. and conversely, “# transactions processed” is not a good license cost driver when M&A is on the horizon or volumes are expected to materially grow in the near term and continue to increase. That said, it’s not always easy to select a bullet proof licensing model, as the mainstay fixed price annual fees are still an extremely sound way to go for a business that expects to grow. Perhaps if you’re thinking too much of the past and trying to protect against future dips, you’re actually more likely to feel a larger sting in the tale of poorly chosen variable license drivers when growth is good.

    • http://peter.evans-greenwood.com/ Peter Evans-Greenwood

      Hi Todd,

      I completely agree. I think the thing here is not to get hung up on having a single, simple fee in the license. Usually it’s best – given an understanding of the business’ needs over the next license cycle – to negotiate a lump sum at a volume discount with a variable component on top to cope with planned growth as well as a contingency. If you have a mature strategy (including something like scenario planning) then you might even look at using tools like real options to quantify this contingency. This way you have the best of both worlds.

      The wealth of options we have today for how we buy IT is great as it helps us to align how we pay for IT with expected business change. It does, however, require a lot more judgement from the IT department, as building a business case or IT budget is more complicated than OPEX, CAPEX, NPV and payback.

      r.

      PEG