Prioritize Requests

Increasing turbulence in the business environment has resulted in endless requests for changes to existing software. IT consultants are deluged with a list of modifications required and every request is termed as extremely urgent. Prioritization is the way out when faced with a large array of competing tasks. But this is easier said than done because prioritization is based on two assumptions–(a) that there exist criteria that allow prioritization, and (b) that lower priority tasks will not be attended to currently. Also, the typical IS manager has neither the criteria to rank change requests nor the power to tell users that their requests cannot be attended to immediately. 

Urgent tasks have to be addressed immediately but may have little significance to the long-term goals. Important tasks have a bearing on the fundamental information infrastructure of the organization. For example, fixing inventory software to handle a new type of bar code scanner will rate high on urgency but low on importance while deciding to change the database engine at company depots from Access to Personal Oracle is certainly an important decision but low on urgency. Assigning priorities means being able to assess both the urgency and the importance of each request.

To put these into practice, start with a sheet of paper and divide it into four quadrants. Label these as high urgency-high importance, high urgency-low importance, low urgency-high importance and low urgency-low importance. Now put pending change requests in the relevant quadrants, the aim being to evolve a rough framework and not an exact formulation.

The problem is now simplified to some extent. All tasks falling in the high urgency- high importance framework get the highest priority, those falling in the low urgency-low importance get the lowest. One is now left with the task of assessing the contents of the high importance-low urgency and low importance-high urgency quadrants.

We are now left with the problem of prioritizing between tasks that are urgent but have little long term importance and tasks that have long term importance but little urgency. 

Let’s see what happens if we decide to tackle the high urgency tasks first. The high importance-low urgency tasks get queued and over time migrate to high urgency- high importance. This solves the current problem at the risk of having to attend to important jobs at the last minute. The other strategy, attending to high importance-low urgency tasks first is also far from optimal as the changes might be of no use by the time they are implemented. Clearly one needs other inputs when making this decision and these inputs can only come from higher management.

The final analysis is that using the framework above allows a partial simplification of scheduling decisions. It removes the really high and completely low priority tasks from the list and leaves a pruned list that can be taken to top management for a decision. This is not a complete solution but will work well in many cases.

The bottom line: Urgency and importance are separate concepts and you need to learn how to segregate the one from the other.

Gautama Ahuja  runs a turnkey software company,

AHC Infotek