Dec 142009
 

Last week, I presented the accomplishments of my applications team in 2009. I was blown away by the number and the scope of the projects my team delivered to our community. I firmly believe that the separation of our operational duties from our project work enabled us to be so productive. While most people would celebrate the project teams |(and we do!), I want to acknowledge the key enabler of this success – our Duty Analyst role.

I blogged previously about our Duty Analyst role here.

Implementing a duty analyst role minimizes the operational interruptions to our team members working on projects. Providing project members focused time to work on project challenges and meeting milestones becomes easier without operational interruptions.

I am proud to say my team delivered on our operational responsibilities and completed 43 projects in 2009.

Here is the breakdown of projects my team delivered:

  • Projects by Size : Small = 19, Medium = 14, Large = 10
  • Projects by Governance : BCIT Executive = 3, IT Governance Team = 14, Business Applications Committee = 5, Departmental = 11, Operational = 10
  • Projects by Community : Learning and Technology Services = 20, Student Services = 9, Education = 4, Finance = 3, Human Resources = 3, BCIT Executive = 3, BCIT Student Association = 1

We continue to refine the Duty Analyst role as well as our IT Governance and Project Management approaches.  I am excited to see what we can do in 2010 to continue to deliver value.  We will be upgrading our ERP this year and taking a focused approach leveraging the Duty Analyst will make all the difference.

Nov 092009
 

Last Thursday Nov 6, 2009, I spent a valuable day at the Forrester Western Canadian IT Summit.  The day began and ended with  keynotes and in between there were 3 breakout tracks – CIO, EA and IT Ops.  This post covers a keynote by Bobby Cameron on Marketing IT.  I will write a separate post on Jeff Scott’s (@logicalleap) two sessions.

Morning Keynote – Driving IT Realization: The Marketing of IT – Bobby Cameron, VP and Principal Analyst, Serving CIOs

Here is my summary of Bobby’s presentation highlighting the 3 key points:

1. What key factors improve the perception that the IT organization is aligned to the business?

Bobby provided 3 pieces of research  and a summary of key factors that keep IT a cost centre.

First, “CEOs – 75% are happy with IT overall – but they don’t expect IT to deliver much“.  IT is not seen by CIO’s as a source of innovation or a source of process improvement. We even struggle being seen as capable of managing the people and assets under our control. (Me: we do not have the reliability of a utility yet)

Second, “Business’ perception: Quality of IT’s support doesn’t match importance“.  While the business recognizes that IT is important to reduce costs, improve productivity, acquiring and retaining customers, driving innovation, managing customer relations and re-engineering core processes, their perception is that IT only delivers on these half the time. (Me: putting methodologies like Enterprise Architecture, IT Service Management and Project/Program/Portfolio Management in place helps)

Third, “A more positive view of IT begins with IT doing its job well …“.  Bobby provided a list of changes that contributed to a more positive view of IT like reliability of systems, consistency and quality of IT processes, improved execution of major enterprise projects, etc. (Me:  see my comment above as well as putting a focus on managing complexity)

Bobby’s conclusion was that “Poor communications keeps IT a cost centre“.  If we do not address the following, it is hard to become a trusted supplier or a partner player.

  • making invisible contributions
  • perceived as late and over budget
  • seen as a utility and not a partner
  • only a good as its last failure  (Me: this is really tough for us in IT because no one has created failure proof technology)

2. How can IT leadership become intentional about pursuing this improved perception?

Sep 262009
 

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.

Switch to our mobile site