I am writing about a topic that came up this week when working with my colleagues at the University of Alaska Office of IT. A common challenge all IT Service teams face delivering projects when there are huge operational demands. Here is the approach we took to address this critical and ongoing challenge in my Business Application Services team in IT Services, BCIT.
In Sept 2007, I took over as the Manager, Business Application Services at BCIT. For the first 4 months, I took a meet, listen and ask approach. I held one-on-one interviews with each of my team members (23 systems analysts in 3 teams). I setup regular meetings with all our key client stakeholders (Registrar’s Office, Finance, HR, Financial Aid, Student Services, Facilities, Alumni and others) around BCIT. I needed to hear from my team and our clients about the challenges they faced and their perceptions of our effectiveness in meeting commitments.
In all the meetings and interviews, I heard a common theme from…
- My team: “We have too much to do and can not keep up with the demand from our clients.”
- Our clients: “Your team is working hard but we have important projects that are not getting done on time.”
- Me: We also had a growing list of application project requests and struggled to keep our key technologies current.
What struck me was the my team was having a significant challenge separating operational work like break fix, small enhancements and regular changes related to business cycles like applying new tax rates from underway project work and deliverables. Operations always trumped project work and the result was delayed or late projects and worse unhappy clients.
We are commited to ensure our core services (operations) are delivered based on our commitments in our IT Services Core Service Catalogue. How could be ensure that we met our service levels in operations and put a focus on delivering on our project commitments??
Separate operations work from project work was the answer.
An opportunity presented itself in January 2008, a systems analyst in our developer team stepped up and took on a new role … the Duty Analyst. The role of the Duty Analyst was to handle all the operational work for a time period freeing up the rest of the developer team to focus on project work relatively uniterrupted. The introduction of the Duty Analyst has made significant improvements on the effectiveness of our developer team.
So what is the role of a Duty Analyst?
Since we have been strong adopters of the ITIL Framework and processes, we already had a process for dealing with incidents (break/fix, small enhancements and regular changes like tax updates). Incident Management is the primary duty of the Duty Analyst. This frees up the rest of the systems analysts/developers to focus solely on project work.
Here is how it works … one week before the end of the month, the developer team, their team leader and I get together. We collaboratively review what is in the Incident Management (IM) queue for our team. We start with the current Duty Analyst reporting out how the previous month went, highlighting any successes and challenges. Next we, look at what is in the IM queue and as a group assign incidents to the Duty Analyst scheduled for the next month. Typically we assign anywhere from 4 to 6 incidents. The objective is that these incidents will be resolved by the incoming Duty Analyst in the next month. We ensure that we don’t overload the Duty Analyst so that they can also deal with the phone calls and emails that come in for production problems.
From a resourcing perspective, our developer team has 7 people and we assign 1.5 FTE to the duty analyst role. The Duty Analyst is rotated through the team with the expectation that each analyst is the Duty Analyst for one month fulltime and the following month halftime. This allows the Duty Analyst to hand over to the incoming Duty Analyst and to complete any incidents they could not get done in the month.
The benefits we have seen of this approach are:
- a clear focus on ensuring that dedicated resources focus on operational work to meet our core service commitments
- more resources to be put on project work without interruptions caused by the phone ringing or emails with operational issues – projects get done!
- development of group estimation skills and clear understanding of who is working on what (gets away from the “I am working hard but they aren’t”)
- creates crosstraining opportunities resulting in multi-skilled support team
If you have staff saying they are overloaded and clients who claim IT is not delivering on projects, I suggest you consider our approach – implement a Duty Analyst role.
If you choose to separate operational work from project work, you will have happier staff and satisfied clients! If you have any questions, don’t hesitate to ask.