Changing priorities too much

Question

We are small growing company with demanding IT needs. As the company grows, new business logic needs to implemented to accommodate the growth and the existing system needs to be fixed which has a lot of shortcomings. In short there are a lot of things to be done.

The prob that I face now is there are too many priority changes every day. We have 2 to 3 top priority items on certain days. On most day I have at least one or 2. With so much priorities changes I am in the middle of priority and another priority comes, forcing me to leave the current one as it is. Further the operation are not fully aware of how complex some reports are which can easily take months if not week. I completed one within a week with all these priority changes everyday and got hit on because I was two days late.

The IT department is sort of under attack. There is an impression that things are not getting done in time and that even the quality of work is low. I am the only developer with an IT manager (new)? I am responsible for all IT works. That means any issue with our software (as we grow we have increasing issues), all reports, analysis, new functionality. There are literally 10 projects in pipeline all priority one. But I cannot work on any of those item but new priority 1 items come every day. As a developer what can I do to improve my image as well as my department. Lately what happened is that the operation is not willing to test anything on time while they blame IT for the problem. They even stopped respond go my email even though I have been extremely helpful to them. I am concerned that being too nice is actually too bad? What can I do elevate IT image as well as mine in front of operations. Note that operation is the key role in our company. And yes we are hiring new developers. But it might be a couple of weeks.

What can I do to deal with too many changing priorities where I can't get one thing completed and another one comes in?

Answer 1

First off this is a very common problem in smaller organizations and even larger ones if the culture of walking up to a developer with an issue/request was fostered from the beginning. The accessibility of the IT department is great but there comes a point in time when that behavior is bad for the developer and the business as a whole; it looks like you've reached that pain point.

The first step in educating your manager and the business on the issue is providing solid metrics on the number of requests, priorities, man hours to resolve and so on. Ideally you'd have a ticket system in place already, but considering the point you're at now I'm betting that you don't.

So start a log (spreadsheet) of all requests with the pertinent information. For example include:

• The date/time of the request
• Who made the request
• Priority of the request as determined by the person making the request
• Description of the request
• Your estimate of the man hours required to resolve the issue
• Notes about the time you spend on the issue
• Notes about interruptions of your work on the issue.

Once you have accumulated a history you'll have empirical data to communicate your concerns and the problem to your manager. I'd even go so far as to speak with your manager before you start this process; if he's worth his salary he should already have identified the issue and be working on a way to resolve it.

In an ideal world:

• All requests are submitted to a ticket or request system
• The IT manager or designated person(s) will work with the business owners to determine a realistic priority and scheduling of the work
• Work will be scheduled and priorities set that take in to account your existing load and nature of the request
• The business owners/department heads will work in conjunction with your manager to set company goals and priorities.

Obviously this is very simplified, there are whole disciplines and methodologies defined for this process and there's no way to address the full scope in an answer here.

The bottom line is that:

• The IT manager is your boss, NOT the other department heads.
• As a developer you should NOT be juggling priorities for the business. That's up to your manager and the other unit managers to determine.
• You should NOT be interrupted several times during the day with business owners demanding your attention and diverting your time to their problem(s).
• At minimum they should be going to your manager so that he can decide how to allocate your time.
• You can and should direct all such requests to your manager or at the very least require an email form of the request with a CC to your manager.

Obviously if someone walks up and tells you the system is down you need to react. But you should also ask for the email so the issue is documented.

Answer 2

Our team found it helpful to produce a publicly-viewable dashboard indicating all the projects our team was working on and the status thereof. That way, if something new comes in and bumps us off something old, it has a big yellow or red dot saying this isn't being worked on, and people are encouraged to view the current task load before insisting we drop something to handle their "high priority" request. Making them aware of what exactly will be interrupted makes people less likely to interrupt because, odds are, they want that other thing too.

Answer 3

It sounds like you need a project manager. It is their job to prioritize projects and plan the development time to ensure that there is time dedicated to accomplishing tasks. They can create a plan that will explain to the stakeholders what will be worked on when and establish a timeline for deliverables. Generally if you can show management a timeline they will either back off or rearrange priorities themselves. If they will not give you one you can take on the task yourself. Look into creating a project plan it is not terribly difficult and it will help you to deal with demands from management.

It is possible you actually have the need for more development resources. If you have a project plan you can document those needs and bring in either temporary resources or permanent resources based on real demands. But unless you can show how the work is being completed and what it is going to take to meet demands it is more difficult to show that you need more help.

Answer 4

What you need to do (or your boss needs to do) is start to manage expectations. I never take a new Number 1 priority without pointing out what will be delayed because of it and and how long the delay will be. I never accept more than 1 number 1 priority. We had a client one time who liked to make everything Number 1. At one point they had 32 number 1 priorities on the list. The new project Manager (the old one got fired because he couldn't manage the priorities) stopped this on her first day by sitting with the list and the client and forcing them to actually prioritize. She also took the time to explain to them that this continual priority switching was causing delays in all the projects and was causing overruns of the estimated time becaseu of the time needed to switch context. The clients (whether internal or external) have to understand that their requests have consequences.

Until they are willing to actually set priorities, the existance of a new number 1 priority should not take precedence over one that is currently being worked that is also a number 1 priority.

You don't say if you have a formal ticketing system for all requests. If you do not, then you need to have one and you need to sit down daily with your boss and discuss priorities for that day. Never under any circumstances work on an issue that is not in the ticketing system. If they can't take time to enter in a request, then it is clearly not important. Until you can present a formal list of what is being asked and a list of what you have accomplished from the ticketing system, you can't defend yourself nor can you show that there is too much work for one person. There are free systems available, there is no reason not to have one.

Answer 5

This is one thing that Agile was intended to solve; preventing the development team from having to chase changing priorities and put out fires. All the turbulence of those changes happens on the backlog items the team has not taken up yet. Once it's out for development, de-prioritizing it has major consequences for the development team and so such actions should be prevented except in extraordinary circumstances.

This is one Agile practice that's relatively straightforward to implement all by itself, if maybe not "easy". Speaking to you as if you are the IT manager:

• Collect a list of all the items that the development team has been given but has not yet completed. This is your "backlog".
• Sit down with the "product owners" (ideally there should be only one, but obviously you have several department managers clamoring for the dev team's attention and that won't change overnight), show them the backlog, and ask them to rank all the items in priority order.
  • By "rank", I mean there should be a #1, a #2, a #3, etc, in order of importance, and there should be one and only one item with a particular ranking number. A "tiered" priority system of "A"/"B"/"C" priorities is useless; everything becomes an "A" priority, which is the problem you have now.
  • This process will get political, and ugly, and you will take some heat for forcing them to do this. Stick to your guns; make them make the hard decisions amongst themselves.
• Once you have the ordered backlog, show it to your dev team. Ask them how much, starting from the top down, that they can get done in two weeks.
  • This "two week" window is up for negotiation; the basic idea is to shorten the window for which they're expected to make concrete plans. Most humans can plan ahead enough to schedule the next two to three weeks of their life and be able to stick to it.
  • Encourage them to be realistic; they'll be expected to chew what they bit off. On the other hand, extremely pessimistic estimates are unproductive as well.
  • If the number 1 priority (or anything else near the top of the list) is a months-long project, break it down into smaller bite-size pieces that can be accomplished in two weeks or less, ordered based on the "critical path" and/or their relative importance within the main project. This will necessarily expand the backlog, pushing down all items beneath the broken-down project.
• Once the devs have decided on their work for the next two weeks, you go back to the "product owners", show them what the dev team has taken on and committed to having done, and tell them that those items are no longer up for discussion. Anything else the team haven't picked up can be re-prioritized daily, or hourly, as the managers please, but the team will do what they have committed to do, and it's unfair to them and unproductive for everyone to change that agenda while they're working.
• The dev team then spends the next two weeks accomplishing what they committed to. If they have problems they can't solve, they come to you. If they mis-estimated, they come to you as soon as they're confident they can't do what they promised, or that they'll need more work to fill the two weeks, and the schedule can be adjusted (with the understanding that the team must learn from these mistakes quickly).
• At the end of two weeks, you line up what they said they'd do against what they did, praise them for what they got done, ask them what went wrong or what became a problem that should be fixed, and make plans to fix those things. This may include getting better conceptual designs for new features, adjusting estimates, changing the environment or organization of the dev team to improve teamwork, improving technology, etc.
• This process repeats itself in two-week chunks (or one week, or three weeks, or a month, whatever the team feels comfortable estimating, but not too long or too short). Take the current backlog, with any changes made to underlying items by the product owners in the last two weeks, and the dev team commits to their next two weeks from the top down.

The result of this process is that the dev team knows exactly what they will be working on in two week (and thus hopefully easy-to-estimate) "sprints", having made the decision and the commitment to do these things themselves, and knows that this will not change barring some earth-shattering event. The department managers submitting the work also know this, and should also find out very quickly that you will not accept any attempts to end-run around this process. If properly enforced and followed, your team will be more productive, the people who need things done will be happier because they'll know when it will be done, and overall efficiency of the whole process will improve.

Answer 6

Like many IT departments, it sounds like you are critically under resourced.

At this point in time it sounds like you are are trapped in a highly reactive fire-fighting loop that you can't find enough time to break out of; this is not uncommon in "support" roles of all types, especially where you have a skills set that others do not have.

It's hard to find the time to "break out" of this loop, because you need to get a some kind of system set up in order to do so, and of course that means more work that your "internal clients" will not see as productive.

I'd suggest that your main goal needs should be to start working with your manager to build a business case for more staff resources.

This can be very hard for a IT department if they are considered as an "internal overhead" (essentially a free service) - in order to build the case you will need to be able to effectively estimate the total workload you have, day-in and day-out.

Asking "internal" clients for prioities always seems to fail; we used to spend hours setting priorities from 1-4 in meetings, only to have to action all the "priotity zero" stuff that came up....

I'd suggest :

• stop asking for priorities from people, and start asking for delivery dates
• read up on "agile estimation", and estimate a rough size for each incoming project
• you'll probably need to use hours not "story points", but its an estimate
• record these as tickets or backlog tasks somehow
• a simple whiteboard is a good start (name, project, requested on, due date, estimated size, estimated remaining)
• assuming a 6-7 hour productive day, calculate how many days in the backlog

This should be enough basic information to allow your manager to start providing effective feedback to the organisation. I'd suggest this needs to include :

• asking senior management with full business oversight to set priorities
• circulating the "backlog" to all management staff on a monthly basis
• identifying in this e-mail wether the backlog is increasing or decreasing

All of this will hugely increase the transparency of your department and team; if, as I suspect, you simply need more resources, then senior management will be able to see this, and the other departmental managers will have a clear view of the cost-benefit that can be obtained.

It will also help to highlight if your pressure is caused by other oganisational issues outside of your department - as the saying goes "I fail to see how a lack of planning on your part, should constitute an emergency on mine"