Emerging Tech

Changes abound: What's happening in my small IT shop?

Scott Lowe talks about some of the new tech challenges his small IT department is facing and how they're handling them.

We all know that the only constant in IT is change. However, for quite some time, that change has been technology-driven. Virtualization forced IT to rethink how it hosts services. The cloud does the same thing, but in a much bigger way. As CIOs, we've also had to consider how our internally provided services could be best leveraged for maximum business benefit.

However, a paradigm shift in how we manage IT is under way. At Westminster College, I manage a small staff of eight extremely talented IT professionals, and we're at the beginning of a change in the way we do business.

To lay the groundwork: When I arrived at Westminster in 2006, there was a ton of low-hanging fruit to work with:

  • The network was in shambles
  • There was no plan for any ongoing server replacement and systems were aging
  • IT was the "department of no"
  • The help desk was referred to as the "helpless desk"
  • There was very little wireless, but there was a plan to deploy it across campus; the challenge: students wanted it now and it was becoming a significant competitive weakness
  • The Internet connection speed was much too low
  • Many, many other deficiencies

We've spent a whole lot of time correcting many of these issues, in particular the most egregious infrastructure and service issues. Are we perfect? No; just about every IT department has its own "dirty little secrets" -- weaknesses that need to be addressed but that aren't killing the institution. The challenge is knowing where you're weak. Because, once you know, you can correct. On that front, we're doing OK.

But, with massive infrastructure issues corrected and a number of data quality and business process improvement projects either completed or under way, we've begun to have new challenges.

  • The intersection of routine operational work and project work is a constantly changing location. Some weeks, staff can spent 80% of their time working on nothing but projects, but other weeks, operational support requirements might leave only 10% of staff time for project work. This makes it incredibly difficult to plan project schedules.
  • More "visible" projects. As we corrected major infrastructure flaws, people cared about what we did, but it wasn't always as visible as the work we're doing now and the mere fact that the deficiencies were being addressed was good enough. With a long current project's list, new project requests hitting us all the time, and the shifting nature of the projects, we have an increasing need to improve the transparency of the request and prioritization process and make sure that the ongoing project status is always visible.
  • Fully loaded staff. My current staff has sufficiently full plates to keep them busy all the time. New projects require careful prioritization so that we don't constantly disrupt workloads.
  • Lack of certain skills. Let's face it. With only eight people on the team, we can't be experts in everything, although many people on campus have that very expectation. We're often asked why everyone in IT, for example, isn't an expert on the database system we use. My response is usually something along the lines of "for the same reason that you don't send an English professor to teach physics." People have different specializations.

With these challenges, what are we doing to mitigate?

  • Attempting to better quantify operational support time needs. The less time that staff can spend on operational needs, the more time there is for project work. As such, I'm working with my staff to gain a better understanding for just how much "interrupt driven" activity they're undertaking each week.
  • Shifting workloads to different people. My more junior database administrator is definitely a rising star but does not yet have the skill set of the person that's been doing DBA work for a decade. I am in serious need of the skills that my senior DBA has in pocket. So, we're working on shifting some operational support responsibilities to the more junior person in order to free up the senior person's time. This helps us to build the junior DBA's skill set at the same time.
  • Analyzing our own "routine" processes. Internally, we have some of our own inefficient processes that reduce the amount of time we can spend on institutional project work. At the same time, some of these inefficient processes have an impact on other people in the organization. As such, we've undertaken a process analysis effort internally in IT to identify those processes that would have a return on investment if they were improved. Again, the goal is to reduce operational support time so that project time can be increased.
  • Instituting PPM/Project Management methodologies. Whereas our projects could be more loosely managed before, now that we've really hit a resource wall from a staffing and skills perspective, I have to pay much more attention to the project process than I used to. We've deployed the SharePoint 2010-based Project Web App to help with this effort. This tool also helps me to better understand the true cost of the projects we undertake from both a staff time and direct financial perspective.
  • Making sure status is transparent. IT projects are really organizational efforts, so everyone needs to know where we stand and if we're on target. Some projects will be behind schedule and others may be ahead of schedule. Using the aforementioned Project Web App, stakeholders will be able to gain real-time intelligence regarding project status.
  • Outsourcing when necessary. No longer can we just build or buy everything people need, particularly when the time frame is short and there are new skill sets involved. As such, we've begun to outsource some projects for which there is a defined scope and a short turnaround necessary. This is particularly true when there is a lack of internal skill in the IT department as it allows us to get the skills we need on demand without hiring new people.

These are just some of the things we're doing. There are other paradigm shifts coming as a result of cloud-based services that I will discuss in a future blog.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

4 comments
blakelyjf
blakelyjf

Address interrupt driven operational needs with a dedicated weekly rotating shift. Basically each of your staff rotate through this position. The person on-duty for that week is responsible for handling ticket type work and escalation from the helpdesk. Others are left alone to work on project based work unless their specific skillset is needed. Bring up junior people by having well-documented systems, processes, and self-training to bring their skills up-to-speed. Shifting the operational workload to juniors is a good idea that will give them in the trenches experience with the senior only an email/phone call away.

jimd
jimd

It's great to use tools to monitor projects but tracking changes and problems after implementation isn't as closely watched. This is where time is wasted when a problem occurs and everyone begins to ask "what was changed". The IT staff is burdened without a Change Log methodology to identify changes quickly. This is where the SAAS tool at "itchangelog.com" comes in handy. It also handles problems similar to Spiceworks. The bottom line is; your IT staff can identify and manage new problems more efficiently and less costly.

SvenVdS
SvenVdS

Could you shed more light on how exactly you do that? I always find it hard to keep the customer (aka end-user) up to date on project- or even incident status without going technical. How do you communicate with them in layman's terms how far along you are in resolving his or her problem/request, and how can you stamp a progress percentage (for example) on it at all?

pivert
pivert

Don't communicate in layman's terms but don't try to impress with over-use of 3-letter acronyms. The first will make your work look simple (so why do we need someone so expensive if it's that simple?), the second makes you look stupid. We are working with Spiceworks which creates a case as soon as someone sends an e-mail to the helpdesk. The general rule is that at the end of the day there are no un-assigned tickets (which is not the same as all problems solved!). Users can follow on-line what's happening and they also receive an e-mail with every update. And you can pull reports for management.