How do you manage multiple clients requirments that compete for limited resources.

Question

So I manage projects for an internal development team. That is All our clients are internal to the business.

I am trying to figure out he best way to collate requests and allocate the resources that we have. (unfortunately the business dosn't have an endless budget for developers, but they still want everything done)

I would like to do some sort of backlog and feature planning but how do i do that across multiple clients and multiple products.

And last but not least the emergency requests. Someone says we need this tomorrow, how do you deal with that. I seem to have one every week, which we can do we just never eat into the feature backlog.

Answer 1

Depending on how cooperative the sub-projects are, you can either manage the features and the backlog in a single order of priority (thus, the most important task to the organization comes first - transparent, but the decision makers must be able to converge on the priorities), or splitting the time / team and then managing the priorities with each client within the time or resource slice allocated to the client. Organization-wide this is not the most efficient way, but once this hard decision is taken you are free to manage each project independently.

Exactly the same goes with the emergency requests. An enlightened organization would be able to prioritize this across different divisions - i.e. an urgent security fix ranks any feature regardless of ownership, but more likely the "emergency" stuff will either be done as a part of the "slice" allocated to the client, or according to how much pressure the "emergency requester" can produce.

It looks like you have a lot of change going on. If you are not yet using an agile process, such as XP, you should try - at least the managing requirements/features and delivering often parts. Delivering changes often can also relieve some of the pressure on you as the progress from task to task becomes more visible.

Answer 2

I agree with MaxVT that you may want to look at something like XP, as, even if you are delivering programs that have limited functionality, they are still getting something that can help.

You may also want to start setting expectations of those making the demands, based on what you already have in the backlog list.

This would mean that you should go through your backlog, with the developers, and determine what tasks need to be done, and assign time to each task. This will give a way to state that for project A there is x hours, so you can tell someone when you may be able to get to it.

By being agile you can look at what features must be implemented for the app to be useful, and then get the application to that point. You can then track features to be added, in some priority fashion, so you implement the most important features first, then as you have time you add more functionality to it.

Knowing what must be done for each feature and how much time it should take will better help you with the project management, and for you to generate your reports for those above you.

Answer 3

When you have limited resources and emergencies are eating up most of your time, one of the best things you can do (aside from dealing with the emergency), is to make the effect visible so that you have data for higher-level discussions with stakeholders (e.g., "was this really an emergency? what could have been done to keep this from having become an emergency?", etc.)

In thinking about a prioritized backlog, you're on the right track, in part because the discussion over priorities is one that you can (or might be able to) push back on your internal customers.

For emergency "skip the queue!" work, one thing I've seen work is to use "red cards", either skip those right to the head of the queue, or rate limit them to only have one in progress at at time, so that you can be making progress with non-emergency work with the rest of the team that's not working on the emergency.

A key part of whatever approach you take is to gather enough data to support having data-driven discussion with your customers. In the simplest form, have the team give rough estimates for the size of each item in the backlog, so that you can both track how much work you're getting done each week, and how much work is in the backlog. After a few weeks, you'll have supporting data to take to your boss to support a "We're spending 90% of our time dealing with emergencies. What are we going to do about that?" discussion.

Answer 4

If it was development for external clients, I would say that you need to charge a little more for "Emergency" requests. However, short of changing your organisation's internal charging model (and ticking of your F&A branch), there's not much you can do on that end.

You have a good case for bringing in one more developer, but of course $$$'s always tight.

Frankly, I love FogBUGZ (and to be fair there are other case/incident trackers out there, by FB is my favourite). I can see quickly what I have in the queue and their priority (regardless of project/client).

The other pieces of advice I'd give you are these:

1. Advertise the size of your work queue. There may be some internal secrecy required, but perhaps you can post on a wall/website all the project s you have on the go.

2. Get organizational priorities for the existing projects. Someone in your organisation must have an idea of what is needed when, and what is most important - be it the manager, CEO or BOD.
   .
   Everything else goes at the end of the queue.
   .
   If Bob has an emergency request and you are working on Jim's and Mary's requests; make Bob go through Mary and Jim first to get permission to leap frog them in the queue (or if necessary go above their heads).
   Or, Bob can choose to push one or more of his projects that are higher in the queue down and replace it with his Emergency request. Either way, it imparts an inherent extra cost on the the emergency request. Things that aren't really emergencies tend not to be called that any more. It kind of like that ER line "Mark every lab request as STAT even if you don't need it right away"

e.g.,

[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3]
[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3] <- [Bob2]
                       |-------------swap-------------|
[Jim1] <- [Mary1] <- [Bob2] <- [Jim2] <- [Jim3] <- [Bob1]

The answer for your internal (and external) clients is almost always yes (sometimes no for technical reasons). However, that "yes" is always followed by a "but".

You - Yes bob, we can work on that project for you, but we can't start until 
around X months from now.

bob - That's not good enough

You - OK, you have a couple options. If you want to shift some of your other 
requests around we can push it to the start of your queue, that would get it 
started in Y months. 

Bob - Still not good enough

You - Well, you can negotiate with Jim and Mary to leapfrog their projects.

Bob - They won't budge

You - Then go over their heads, and talk to Mr. Dithers`

[some time later]

You - Yes Mr. Dithers, we can work on Jim's requests. You are aware that will 
push back Jim and Mary's requests.

Mr. Dithers - Yup.

You - Aye-Aye Capt'n.

[some time later]

Jim - Why the $%#$%#$5 aren't you working on my request

You - Talk to Mr. Dithers

And remember, if EVERYTHING is a top priority, NOTHING is top priority.

Edit:
Further to FogBUGZ (since you asked), it's more than just issue/bug tracking. You have features requests, inquiries and schedule items too (you might have to upgrade to the latest version to take advantage of those). Use it to its fullest.

Make sure that you are including your feature requests in FB. The more you dump into FB the better the picture it will give you. Remember to use the filters and the grid views.

FB's got a wiki. Post your groups high level work list there for all to see.

Answer 5

There are two sides to this, the practical and the political. The first is straight forward, the second is a mess.

Some of this is horrible management/marketing bollocks sounding so I apologies in advance but it is good.

To sort out prioritisation on a practical level I start with a high level assessment of effort and benefit, each on a scale of 1 to 10 and then plot them on a matrix (effort on the X axis, benefit on the Y axis). The business have to assess benefit (and justify it), the IT team and the business jointly assess effort (the business team don't get to mess with IT's estimates but they may need to add in their own time).

Broadly speaking anything in the high effort low benefit quadrant (bottom right) gets killed immediately - to much for too little. Anything in the high effort, high benefit (top right) gets classed as a major project and needs to be investigated further as these are typically where you'll find one or other assessment is out. Anything high benefit low effort (top left) is a quick win and jumps to the top of the list. Finally things in the low effort low benefit (bottom left) are question marks. As with major projects these need to be examined further though in this case you're trying to turn them into either a quick win (you may be able to modify the scope to increase the benefit or decrease the effort) or to show that they're actually going to be more work than people think and should be killed.

But generally speaking the closer to the top left corner (low effort, high benefit) things are, the sooner they should get done.

One critical thing - all the information and the whole matrix is public - if there are disagreements the developer is just administering the process, not adjudicating on it. Publish the latest matrix (and resulting schedule) on a weekly basis and have regular calls between all interested parties to ensure that everyone agrees with it.

Which comes to the political side - where you know that something is a waste of time but it's being asked for by someone very important. Ideally this is where your manager earns his keep but generally if you have a transparent process (that is the benefit/effort scores and the matrix are all public), the guy pushing for something that's not worthwhile will either (a) struggle because everyone else pushes back pointing out that his change is trash and shouldn't happen at all let alone take priority, or (b) have enough clout that it doesn't matter but at least you're covered as the other people who would pressure you understand that.

And the transparent process is how you deal with the last minute requests. If everyone who has requests in knows where they are in the queue, people dropping things in at no notice becomes harder for others as they're not just messing with the developers, they're messing with their peers and pushing back their projects.

Generally speaking those who do it will either have enough clout that you couldn't stop it anyway or irritate the other people asking for changes enough that they'll be forced to minimise their bad behavior.

One interesting subset of these last minute issues is time dependent projects, that is ones where the benefit is greater if it is done this week than if it waits six months. An example might be where there's a three month window before a legislative tax change comes in and the project would allow the company to take advantage of that.

In that case the project gets assessed on it's maximum feasible benefit then reassessed when it's placed in the schedule - so if with it's maximum benefit it happens tomorrow then great, but if even with it's maximum benefit it can't happen for two months you have to drop the benefit based on what it would deliver at that point in time and reassess (normally this kills it).

So in short:

• Good benefit / effort assessment allows you to pick those which will positively impact the business most
• Transparent well defined process which the developer administers rather than adjudicates on.