You are currently browsing the monthly archive for August 2009.

WWI Trench Warfare

In the Trenches

Like many IT executives, I have heard and experienced the derision from end-users and executives regarding the inefficiencies and delays in the IT department.  This can degenerate into the IT dept vs the rest-of-the-company and brings to mind the trench warfare of World War I.  This is definitely an unhappy state of affairs with IT staffers digging deeper into their bulwarks and end-users dreaming up ever more destructive ways to get attention and service.

What is the answer to this dilemma?  Certainly not more complexity and barriers of technical jargon that no one outside the dept understands.  No, the primary answer is:

PROVIDING CLEAR COMMUNICATION CHANNELS FOR THE RECEIPT AND HANDLING OF REQUESTS PLUS FURNISHING THE VITAL INFORMATION OF WHAT IS GOING ON.

Do you know every type of request coming into the dept with a clear procedure of how to handle it?  Without this analysis, the flow of requests is just one BIG flow with everything jumbled resulting in confusion and inefficiency.  Given a good analysis, clear procedures for handling and specific staff identified for such, then an orderly directing and channeling of requests can occur.

This is more than just having a ticketing system in place: it is the overall plan of handling each type of request the dept receives on a regular basis.  I would begin with flushing out a map of all IT dept requests (MindManager or XMind are good products for this).  Then, I would work with my staff to work out the exact handling of each request and document the procedures on a dept wiki (Mindtouch Deki is a good one).  Finally, I would flush out which staff would handle each type of request and create an org chart or org board map showing staff positions and the associated responsibilities of each.

Here is an example org board for the web production section showing basic responsibilities at the unit level:

IS Dept Org Board

IS Dept Org Board

Working through these organizing steps will allow the dept to inflow requests and channel them efficiently through the dept.  I have found this to be immensely effective.

Now, to furnish the vital information of what is going on requires a good ticketing system that provides excellent email communications to and from the end-users (Jira is a good solution).  Such a system can channel the requests, move them through the processes and keep everyone informed on what is really going on.

An established Service Level Agreement (SLA) is also vital as it sets the playing field rules.  The SLA needs upper management buy-in and be clearly documented on the wiki or other easily accessible platform by end-users.

The final component is keeping the senior executives well informed on the status of projects and issues.  This is covered in part 2 of this post and is, perhaps, the most vital component, at least for one’s career.

Any IT director is constantly challenged with building castles in the sky while keeping all existing systems operational.  At the chief executive level, those castles may seem little more than sand castles on the beach but more likely than not they are as formidable as a Scottish castle manned by the ladies from hell!

A recent chief executive request illustrates this point: “Every subscriber to our subscription research portal should have their own custom RSS feed which is based on their preferences; that should be easy.”  The castle looks small but dig into the sand and you encounter some rather significant infrastructure and resource barriers to overcome – thousands of custom feeds with their own unique SQL queries that are dynamically created.  Not impossible but you get the point.

Most IT departments pride themselves in being able to create or put together just about anything.  There is a joy of creating and developing that is intrinsic with software and hardware developers.  There comes a point, though, where developing and maintaining in-house does not make business sense.  Bluntly, it is just too expensive and costly in some situations.  Does the company wish to become a true software development house or concentrate on its core business strengths?

Making the leap to SaaS must solve business related IT problems and reduce costs over the long-term.  Therefore, when evaluating SaaS one needs to be somewhat detached from the “we can build anything” IT mentality and really focus on empowering the business with technology from any source.  The IT department is not there to build its own empire but to empower the business to achieve its objectives and be more profitable.

Evaluation points when considering a SaaS provider:

  • What business problem will the service solve?
  • Will it empower the business to achieve its objectives?
  • Will the service reduce costs over the long-term?
  • Is the service cheaper than building and maintaining in-house?
  • Will end-users actually use it?
  • Verify and confirm reliability and customer service (key point).
  • Will your senior IT staff get behind the project?
  • Technically, will it really do everything they say it can do?
  • What is the turn around time for bug fixes and enhancements?
  • What happens if the provider goes bankrupt?
  • Is their software kept in escrow?
  • Can you easily get your data out?

It is not crucial to get everyone in the IT department to agree and sign-off but you will need your most senior staff to sign-on.  Remember, the decision is primarily a business one.

Making the leap to SaaS may be the best move the company ever makes.  It all depends on the reasons for leaping and what you land on!

Follow

Get every new post delivered to your Inbox.