Modern Network Architecture

Jan 16 2013   8:40PM GMT

The biggest root cause for IT failure…

James Murray James Murray Profile: James Murray

As a Seattle IT Consultant, my role is not to approach technical failures as technical failures.  I’ve noticed that technical experts tend to approach all problems as technical problems.  As a result if something fails, the technician takes on more responsibility than they should.  Management’s role is to take responsibility of the resource management of the organization.  What I keep finding as I consult, is that many IT professionals take on the role of owner, rather than technician.  The result is a technical failure that could have been resolved by the management long before the failure actually happened.

Here’s an example of what I’m talking about.

  • A server fails.
  • The network goes down for ½ a day
  • Lost workplace productivity is over $200,000

Whose fault is this?

The first reaction of course is that the problem is with the IT department.  The IT department’s job is to keep the systems running.  After all, servers don’t fail, do they?

A review of the server reveals that the server was 8 years old.  The server was also the first server built for the company.  The server was the natural repository for all company files because everyone knew where the data was.  So now whose fault was it?  Does the fault still belong to the IT Department?  After all shouldn’t the IT department have warned management that a failure could have occurred?

These are the thoughts going through the minds of most IT technicians and many IT managers.  While it could be argued that the IT department should have caught this problem, this argument is misleading.  It assumes that all departments are responsible for tracking their own capital assets.  But they aren’t so why is the IT department different?

You may be asking, “What are you talking about? That sounds like an accounting thing, not an IT thing!”  If you asked this question… you’d be exactly right.  This is also my point.  There are already non-technical business processes that should be in place to catch the failed server before it reached 8 years in age.  Very few accountants would assume a company truck would last 8 years.  A building that is 8 years old has met ¼ of its expected lifespan.  All assets expected to last over 1 year are capital assets and should be on a depreciation life cycle.  The value of the company is based on these capital assets.  As assets depreciate, the value of the organization also depreciates.  A depreciation life accounts for this loss of business value.

What’s a depreciation life cycle?

Depreciation refers to the decrease in value of an asset over time.  Since every accountant knows that every asset depreciates, the account puts the asset on a depreciation life cycle.  They do it with trucks, buildings, assembly lines and should be doing it with servers and desktops.  Yet most business leaders never do.  As a result the server runs year after year until if finally fails.  Servers are designed to last 5 years.  So after 5 years the servers should be replaced.  Part of the accounting role in the business is to put aside money for replacement of all capital assets including servers.

Therefore if the owner, the CPA and controller had put the server on a 5 year depreciation life cycle, the server would never have failed.  Because that server would have been replaced three years before it failed.  That’s the way it’s supposed to work, but most technicians know nothing about accounting or depreciation life cycles.  They quickly take on the role saying it was our fault.  The accounting department and even the CEO is willing to let the IT department take ownership of their issues.  I don’t actually think that’s fair.

So when I consult, I ask several questions.  One of the first is, are your servers on an accounting depreciation life cycle.  This is often the first time the business owner and the CPA have ever realized that servers don’t last forever.  We can laugh at management, but wasn’t it our responsibility to let them know this?  Ok… perhaps not, but we could have.  That’s what I do and as a result, I never have to take ownership of the failures that occur when server gets too old.  I just say… see… I told you.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: