Classic IT Challenges – Prioritizing Work

This is the second post in a series of writings to discuss issues facing Information Technology (IT) departments. IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. In my own experience, I have seen these challenges in multiple business environments. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group.  My thoughts are more around framing the problem than presenting solutions.

Challenge #2 – Prioritizing Work
The second challenge is how to prioritize work and to maintain priorities. Several years ago I wrote about different approaches to creating priority for work projects in an eCommerce Release Management post. Priorities for project work are most commonly determined by financial measures while priorities for operational support are often determined by a service level classification. Creating the initial priority for work and inserting work into an existing backlog is a difficult puzzle, but it’s one that often has a prescribed formula and in most cases is pretty straight-forward.

The more common challenge with prioritizing work is maintaining priorities so that work can be completed without creating an environment of chaos due to context switching. The implications of stopping something that is active to start something new are high. This type of work increases work-in-progress and ultimately requires longer to complete tasks since stopping and restarting activities takes time to reacclimate to the task.
Priorities are often stressed and challenged when business requests outpace the rate of work closure. So to keep active work in an active state, the IT group must often say “no” or ask to delay the start on a request.

Example 1
The IT development group has three active programming projects. They are 20%, 40%, and 60% complete. Two new requests come in the system and the stakeholders request they start immediately so they can be completed by a specific date. Some members of the steering committee favor stopping the project that is 60% complete to start one of the new projects.

Example 2
It’s Friday and a desktop engineer has four tickets to close by the end of the day to meet a service level agreement for new desktop setups. Two new tickets are entered for two employees who start work on Monday. They need computers and a phone connection by Monday at 8am. The typical SLA for a new employee setup is one week, but the hiring manager forgot to put the request in until Friday morning.

The Challenge
The obvious challenge is to how to properly sequence and complete this work. What gets priority and how does management protect resources against context switching? Often times there is a single person or single development group to complete the requests coming from different stakeholders. Neither stakeholder is happy with a delay. So it requires a balancing act and careful communication to explain the situation.

Next week
Challenge #3 – Operations vs Innovation