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.