s

Create an IT infrastructure that pays for itself

Being clear about how the IT infrastructure pays for itself.  the most horrifying task an IT professional must do.   

Name the main reason to develop something or buy and put something new in place.  That is easy.  The main reason, as well as the whys and benefits, is obvious (at least to the IT professional).  How to pay for it . . . well, that requires some thought.

The most frequent reason that a technology caught our eye?  It is cool.   IT professionals would NEVER say that out loud, except, perhaps, to each other.  Mature IT people will deny this, but that feeling still gently nudges them. 

Our eyes go out of focus when we talk about it.  We talk about how it would take care of ‘X’ – ‘X’ being the frustrating problem of the moment.  We scour the internet and forums for more information about it.  We watch YouTube demonstrations of it, some of which aren’t even in a language we speak. 

We might even sense that using it will help make the world a better place.  And bring about world peace.  It will definitely bring about world peace.

Thinking about how to pay for this game changing technology is so much buzz kill.  It’s a splash of cold water.  We question our reasons for being in IT when we hear the words ‘they’ll never go for it”.  We chose technology as a career because we wanted to use technology to make things better.  And play with technology that – ah – moves us closer to world peace, right?

But there you are:  the money has to come from somewhere.  The most common triggers for funding are:

  1. It replaces something broken or near the end of its service life.
  2. It replaces something that exists and does it cheaper
  3. It enables a valuable human resource to do something faster so they can do more
  4. It enables a valuable human resource to do something new.  This increases what the organization is doing, which usually means more money.
  5. It reduces the probability of something bad happening.  It’s insurance.

Sometimes you have a purchase authority level and are the decision maker (lucky you!).   You still need to determine how the new technology will pay.  Having that authority reflects the anticipation that you’ll make good judgments.  That is, good judgments as determined by the person who gave you the authority.

Some definitions:

  • IT infrastructure:  the IT staff, hardware, software and all the connections.  Everything technical needed to provide the services and information used by the organization
  • Total Cost of Ownership (TCO):   the total costs over the projected technology lifetime.   TCO includes:
    • purchase costs,
    • implementation costs,
    • service contracts,
    • replacement costs for disposable parts,
    • maintenance costs and
    • disposal costs, to name a few.  
  • Pays for itself:  the Total Cost of Ownership (TCO) of adding the service to the organization is less than the what the cost would be if nothing changed.
  1. Handling Change Aversion
  2. Calculating Total Cost of Ownership (TCO)
    1. Replacing Something Broken or Near the End of its Service Life
    2. Replacing Something that Exists with a Technology that Does What It Does Cheaper
      1. Case Study:  Purchasing Long Distance Telephony Service
      2. More Service, Same Price
    3. Enabling a Valuable Human Resource to do Something Faster So They Can Do More
    4. Reducing the Probability of Something Bad Happening
  3. One Decision at a Time

Handling Change Aversion

 

“That is a good idea. It is also a new idea. Therefore we must fear it.”
Lothar of the Hill People

When you hear the words ‘they’ll never go for it’, the reason is usually fear of change more than the cost.  There is truth supporting the fear.  Change, particularly infrastructure change, is a source of disruption.  Disruption means people cannot do their normal work, if they are able to work at all.  The reduced productivity comes with loud complaining. 

Decision makers outside IT usually don’t remember why a failure occurred.  They remember that a change was behind the disruption.  Hence, the fear of all change kicks in when considering a new technology proposal.  

Every IT group inherits the legacy of changes gone bad.  The missteps of their predecessors live on in the decision makers’ minds.   Perhaps its past failures in your organization.  Maybe a decision maker has memories of failed IT changes from a previous organization.  The inherited legacy means that cost is usually a handy justification for avoiding change. 

Fear of change is often the real issue.  Decision makers dismiss cost numbers until you handle the change fear.  This reality demands preparation to call out the fear of change.  You must address the change aversion as well as speaking to the cost.

Addressing change aversion requires sharing the steps taken to avoid and recover from disruption.  The explanation must be in layman’s terms.  You must be ready to speak to these points before a cost discussion will have any effect.

  • What is the testing and simulation done before implementation?
  • How many users are at risk from a change failure?
  • Can the implementation progress from a smaller to larger group?
  • When would the cut over happen? 
  • How would an implementation disruption affect users and for how long?
  • What is the rollback criteria and plan?  How long would a rollback take?

A track record of careful and successful changes lowers change aversion. An automated and established change process reduces the change aversion barrier.  It opens the discussion for decision maker to consider cost.  

A group might not have a record of successful changes.  Successful implementations are invisible ones. Getting credit for succeeding with minimal pain is difficult.  Decision makers remember failures.    You must be ready to address those memories.

What if an organization is globally change adverse?  

Some organizations oppose all change, whether it is IT related or not.  ‘It’s been that way for years’ may be what you hear.  This spans everything from broken sinks and stuck doors to stacks of broken equipment.  If you suspect this is your situation, read my post on globally change adverse organizations.

Calculating Total Cost of Ownership (TCO)

Total Cost of Ownership (TCO) is the total costs over the projected technology lifetime.  This includes:

  • purchase costs.  How much it costs to get the technology. 
  • service contracts.  Maintenance and extended warranty costs.
  • implementation / conversion costs.  The projected cost to have someone install the technology. This may be the time an external, third party hired to on board the technology.  Internal resource costs include:
    • the estimated internal time to manage/perform the technology integration into the current infrastructure. 
    • Training time for internal staff.
  • Ongoing care and maintenance.  Estimated internal time to groom the technology over its lifetime.
  • disposable parts replacement costs.  Hardware may have disposable parts.  Toner for laser printers are normal disposable parts.  Disposable parts cost includes anticipated cost for failed parts outside a maintenance contract.
  • disposal amounts.  This is an estimate of the amount expected to recovered or paid at disposal.

Purchase and service contract costs are usually the easiest to determine and least disputable.  The remaining items need estimates.  Estimates may be vendor provided or your own experience, if you’ve done something similar.  Calling someone, like another customer of the vendor, may be a good estimate source. 

You need a TCO all the solution options.  That accounts for the amounts for the various options considered.   Time to turn to determine the TCO for the current technology in place. 

Replacing Something Broken or Near the End of its Service Life

Let’s say the  purchase purpose is replacing something broken or near the end of its service life.  If that’s the case you can skip the cost comparison for the currently used technology.  You may need to justify that the current technology needs replacement. 

If the item isn’t broken but is dying, you may need to provide the evidence that the point of failure is soon at hand.  A history of increased attention to keeping the item working is good.  A chronology of a string of recovered failures works, too.  You may need to account for the extra attention and failures cost.

Replacing Something that Exists with a Technology that Does What It Does Cheaper

Services or assets with ongoing costs are good targets for replacement.  This happens often in technology, especially with services.  An example was the drop in long distance rates in the 1990’s. 

Case Study:  Purchasing Long Distance Telephony Service

Organizations purchased long distance service in arrangements comparable to mobile phone contracts today.  Long distance rates were 12 to 18 cents a minute. They fell to 9 cents a minute.  A few months later the rates descended to a per minute rate of 5.5 cents.  In less than a year rates fell to half or a third of what they had been for years. Organizations who could change carriers saved thousands, if not tens of thousands.  The reduction was in  phone service monthly cost.  The TCO on switching was large, clear cut and immediate.

Changing carriers had no purchase costs or ongoing service contract amounts.  There was no ongoing maintenance costs or disposable parts to purchase and replace. The long distance carrier paid for the implementation cost.  The carrier provided the equipment and connections for a new point of presence (POP). An employee often completed the internal phone switch connection to the POP in under an hour.  This approval for this service change would be a strong and immediate ‘Yes’.

Here’s where disposal costs become a factor.  The expense was not the cost of disposing of the new service at some future date.  It was the disposal of the service for the outgoing carrier. 

The expensive rates were usually bound with a long term contract.  The contract stipulated a minimum purchase minutes each month.  The contract had penalties for falling below the total minutes commitment.  The customer had committed to purchase for several years.  Just like mobile phone contracts today, there were penalties for early termination.

For many organizations, the rates decrease savings exceed the penalties cost.  They paid the penalties and switched.  

More Service, Same Price

There is a variant on replacing services or assets with something cheaper.   Replace services and assets with something that does the same thing and more for the same price. 

You aren’t reducing cost.  You are providing new service that can claim benefits.  The most common benefits are productivity increase and reduced risk.   The organization already has accepted the amount for the replaced service.  The organization claims the new benefits for a comparable amount.

The tricky bit in this is the implementation cost. At a minimum there is:

  1. time to purchase and configure
  2. deployment time and effort
  3. time needed to remove the outgoing asset or service
  4. training time

The benefits need to be valuable enough to cover the implementation costs.  The new asset or service need to be cheaper by the amount to cover the costs over the lifetime (TCO again).  Combined with the benefits value, this may warrant the change.  

A word of caution – being a change, there is risk of disruption.  You must include a risk analysis.

Enabling a Valuable Human Resource to do Something Faster So They Can Do More

Corollary:  Enabling a valuable human resource to do something new so you can increase what the organization is doing (which usually means more money)

This was the classic justification for IT, back when IT was Data Processing.  Hard to imagine a time when rows of desks filled offices.  The people sitting at the desks had ten key adding machines.  They added up receipts and amounts on order forms.  The workers copied the amounts to forms.  Supervisors received the forms and wrote the amounts to paper spreadsheets.  The supervisors and workers used their adding machines to total the amounts.  The workers reconciled the forms and filed the reports.  The army of clerks to do this was data processing for the organization. The clerks were the the computers.

Computerized data processing took out the cost.  The first reduction was the number of people needed to do all that tabulating.  With a computer now adding up and consolidating, a few clerks to did the work of the full room of clerks.  The retained clerks used the computer to do what what the full room of clerks did. 

The clerks and supervisors let go paid for the data processing equipment.  It was a case of upgrading the computing resource.  The process of determining the justification was clear cut.  Data processing equipment cost.  Pay eliminated cost reduction.  

The days of wholesale elimination of clerical staff had passed by the 1990’s.  Online ordering provided a resurgence in eliminating order takers.  Automation may still produce staffing reductions.  The focus is now on how current resources can do more.  A human resource who can do more avoids costs and produces benefits.  This is especially true for a valuable and/or expensive worker.

An employee may be valuable because of how much the company pays them.  Their pay may reflect what they know that can’t be readily learned.  It may be the relationships they have with customers.   

What would the time and financial cost be to replace the person if he/she were no longer there?’  The answer to the question is their organizational value.  

They may leave.  They may have a long term health issue.  This question is always valid.  Everyone leaves.  This question points to risk reduction and the amount needed to mitigate a change.  That’s the amount justified for increasing their productivity and backfilling their work.

The more important question looks at the benefits of what a person does.  It asks ‘what if they could do more of what they do?’

Doing more is incremental improvement, usually done in small ways that add up.  The challenge is that doing more is tough to quantify.  

Two typical objections to a ‘doing more’ justification are:

  1. We aren’t doing more business.  There isn’t ‘more’ to do.
  2. The person is on salary.  The number of hours they work doesn’t matter.

We aren’t doing more business.  There isn’t ‘more’ to do.

Achieved the nirvana of the right workers and processes servicing the right customers?  Congratulations!  Hopefully nothing changes.  Customers and employees don’t leave.  The volume of business doesn’t change.  There aren’t competitors.  While you may have periods where all this is true, it’s tough to maintain. 

You can prepare to handle these changes which you don’t control. Increase what the current workers can do.  Doing this creates capacity to handle unrealized and unknown risks.  If workers are 100% utilized now, there is no time available to prepare for changes.  To prepare, workers need slack.

IT management author Tom DeMarco defines slack in his book by that name.  Slack is ‘a prescription for building a capacity to change into the modern enterprise’.  Slack addresses what he calls the efficiency-flexibility quandary.  When a worker (or business) is working all the time, there is no time to react to changes you don’t control.  The question:  how much slack time does the person have as they are doing the job now? 

Using technology to enable doing a task quicker can create slack.  The technology and process changes from ‘how we’re doing it now’ and creates space to do more.  Slack enables making changes that leading to quantitative and qualitative improvements. 

Quantitative improvements put hours back into the day.  it’s the ‘making space’ process that comes from doing work in a new, quicker way.  Sometimes it enables doing the current work the way you really want to do it.  The improvement creates qualitative improvements.

Qualitative improvements examples: 

  1. more information from each transaction, which can lead to better decisions. 
  2. process changes that increase customer satisfaction.  

Here’s where change aversion arrives.  The person who is doing the job is generally comfortable with how it’s done and how long it takes.  There is job security in it.  The person resists creating more time through improvements because it is different.  For success, you need to provide what will take the space in the time created.  What activity fills the space created with the change is the pay-off and justification.

The person is on salary.  The number of hours they work doesn’t matter.

So what if Jane is working 50 hours a week?  It doesn’t cost the business anything to notch that total up to 55 hours a week.  But doing/buying something to enable Jane to put in less hours – now that would cost money.  

Some problems with this financial rationale are:

  1. physical limitations.  You can only ratchet up the sustained working hours so many times.  There is a hard limit of 168 hours in every week for everyone.  Most of us want to eat, sleep and visit the place where we sleep   That takes at least 70 hours a week.  That leaves 98 hours a week, right?  That’s the hard limit.  Physically, though, the number is a lot lower.  Burn-out awaits those with eternally escalated hours.
  2. knowledge starvation.  Some people have difficult to replicate knowledge.  Having more time to apply it can make a difference. There is a risk in having no time available for the worker to replace or grow their knowledge.  That situation starves the worker and organization of knowledge needed in the future.
  3. no room to react to external changes.  The salaried person is subject to the same external changes listed in ‘We aren’t doing more business’.

A word of caution:  beware of organizations where busyness is their culture.  Yes, I mean ‘busy-ness’ – maintaining an appearance of perpetual overwork.  Even if it is only an appearance, most workers won’t accept challenges to the illusion.  They support illusion maintenance with dogged determination.  To do otherwise would put their worth to the business in question.  A business-threatening situation is even tougher to handle in this environment.  

Every business experiences those business-threatening events that demand attention now and were not intended.  Call these events ‘fires’.  Organizations without slack will have to stop other activities to attend to the fire.  Stopping like that provokes more fires. 

Beware when the ongoing operating mode requires overtime to complete every worker’s ongoing responsibilities. In those situation you cannot count on overtime to address fires.  There aren’t any hours left for overtime.

The dominance of ‘the person is on salary’ rationale  as a management tenant is a caution.  That environment holds that the salary makes the worker’s time an all-you-can-eat buffet.  Every meal should be as large as it can be.  You will probably not get traction for any changes. 

You also may be forfeiting a good part of your waking hours on an ongoing basis as well.  Use care in being part of a pay-for-unlimited-time environment.

Reducing the Probability of Something Bad Happening

Enabling a valuable human resource to do something faster so they can do more is risk management.  Creating slack increases the flexibility to react to changes.  Beyond creating slack, reducing risk helps pay for the IT infrastructure.

The ITIL change enablement practice assesses the risk of disruption from an IT change. Apply the same practices to determine the  ‘something bad’ risk impact of not doing an IT change.  

An example is the vulnerability of a 15 year old switch.  Calculate the cost of downtime from the switch failure.  You can multiply this amount by the probability that the switch will fail.  The result may go a long way to justify a new switch.  

Most risk avoidance amounts are not easy to estimate.  It ends up  in the realm of actuaries.  Few ‘something bad’ events bet the existence of the business on a negative outcome.  Think ‘offsite backups’ as mitigation for a ‘bet the business’ risk.  You can tie some IT infrastructure to reducing risks and claim the savings.  

One Decision at a Time 

The focus has been on determining how a single proposed IT change pays for itself.  The underlying assumption is that if you consistently implement changes that pay for themselves, you’ll have an IT infrastructure that pays for itself.

There is a matter of inheritance.  Setting up an IT infrastructure from scratch is a fairly uncommon event.  You usually come into an existing environment.  You will want to improve the total cost of ownership for elements in the environment.  Determining the original justification, however, can be a fool’s quest.

Businesses need a certain amount of infrastructure to operate.  The organization does not need justification for the base level.  A business without it would be difficult to conceive let alone operate. Examples are:

  1. Network connectivity, including end points
  2. Accounting systems for order taking, paying suppliers and performing reporting
  3. General office applications (word processing, spreadsheets)
  4. Telephony and communication

Over a century ago businesses worked and flourished without IT services.  Applying the IT functions of today to the business of 100 years ago would reduce expense.  Reduce it, that is, compared to the time-honored means used.  The job of IT is to consistently provide and improve the current alternatives

Maintain a Stable and Secure IT Infrastructure

 

 

Build Using What Others Have Done