Slashdot Mirror
Ask Slashdot: How Do You Deal With Priorities Inflation In IT Projects?
NetDanzr writes "I work for an IT company that has a steady stream of projects, new features to our existing products and technical support issues. As it is customary, though, our development resources are not sufficient to cover the amount of projects. As a result, our delivery dates are slipping, and as a result the average priority of projects is rising. Where the goal was to have only 10% of projects rated high, within a year nearly 50% of projects are rated as such. Our solution is to completely wipe out the project list once per year and start a new, properly prioritized list. How does your company deal with this inflation of priorities?"
We typically fire the entire IT staff every couple of years and try to hire replacements at 70% salary under threat of outsourcing.
Or get a manager that can get the priorities / resources changed.
Something isn't working at your company. If upper management is setting their expectations too high (or not providing the resources to meet those expectations) then someone needs to explain that to them.
Every user wants their project first and everybody else to wait. You can't let users declare their own priority unless there's a strictly followed grading system or rubric based on the priorities of the business. (Ex. Customer facing systems are more important than internal ones.) If you've got 5x of the "high" priority tasks either you;re making too many mistakes or priority inflation needs to be addressed with the users.
Replace your current priority-tracking system with a floating point number. Add buttons to the interface that increase or decrease its value by small increments. Next to that, display a z-score, ideally presented offset so that the base priority is higher than zero (to reduce the number of negative numbers shown—or perhaps don't do this if you really want to discourage people from working on low-priority items.)
Statistics: fun for the whole family.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Obviously, you need more priorities. Nobody wants to mark his pet project as "low" priority, so you need to be creative. Ask marketing for help, and you'll end up with your new priorities: "High", "Very High", "Red", "Extreme", "Platinum", "Overclocked", "Done Yesterday", "Drop Everything", and "The Boss Is Watching".
Our company makes the corporate bonus program dependent on the project list. So everyone in the company has a vested interest in the projects that were defined near the beginning of the year. That's not to say that individual projects don't have the inevitable and constant feature creep, but release dates NEVER slip, we have a solid group of PM's I like to consider as enforcers, and a corporate structure where if something turns from green to yellow the person to blame immediately gets his schedule cleared until his piece is caught up. It seems to work, but it depends on everyone being pretty good at estimating work tasks, so there's a lot of double buffering to allow time for maintenance work... even then we stay really busy.
The answer lies in quantifying the project impact, not in calling it low/medium/high (which is a subjective, relative term). Also, as business grows (or shrinks), the measurement of impact should be weighted as well. For example, a project that generates $1M/yr in revenue is a big deal when you're making $2M/yr, but not as much when you're making $20M/yr.
In the end, limited resources need to be focused on the area where it makes the most impact rather than trying to solve everyone's problems. That is exactly what IT management's job is.
The other answer is that no group/team/company does this really well, it comes down to individual manager's or IC's style and how you dismiss the trivial requests.
Someone wants a good project manager ? Good luck with that man. Either you have too few PMs and too many projects or more PMs than actual engineers. No one I mean absolutely no one at all seems to have a clue about finding a balance in terms of staffing project managers inside of a technology department. Now with that bit of fussing out of the way. What you do is you look at the list sit with your immediate manager. You both logically discuss the insanity of a full sheet of top priority 1 emergency projects and figure out which ones really need to get done and when. Remember who signs off on your yearly review and focus your priorities from what your immediate and his manager above really need for you to get done. You cannot let the bullshit of 50% of your projects being ranked as a high run you into the ground. Focus on what NEEDS to be done and then after that what your boss WANTS to get done and then on what the boss's boss would LIKE to have done.
ACK
It sounds like they need more than one project manager and a number of additional worker-bees to get the jobs done.
Start by showing the problem to senior management and tell them flat-out that there is no way to get all the projects done on schedule unless they hire enough people that each project has enough people on it to get the job done. It's always incumbent on workers at each level to give their best (i.e. worst-case) estimates of how much work is required to execute a project and how much time it requires. (Some work can't be accelerated past a certain point by adding more people.)
There are three responses that might generate:
* "you'll just have to work harder" This response is not unusual but tells you you're going to fail anyway and is a signal to get out of the organization before it crashes and burns.
* they'll cancel some projects and focus their people on the remaining ones
* they'll hire some more warm bodies to get more work done.
Also, you need a way to shield the people working on each project from interruptions generated from outside the project and the project managers need to insulate their people from scope creep.
From the sound of it, your problem is that anyone is allowed to mark an issue as high without restriction.
You say the goal is to have no more than 10% marked as high. So it seems the answer is simple. When you have 10% marked as high, you don't allow another item to be marked as high unless and until something else is removed from high.
That could be manually managed by a project manager, or it could be a business rule in your issue tracking database.
If you think something will take an hour, say it will take three. Then when it takes you two you're a genius for getting it done early. Oh... and shout "I've given 'er all she's got cap'in" every now and then.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
I have done this before too. I had fun with it. I told the PMs that I would be working on the project of whichever PM was in the room looking over my shoulder. They literally had to stake out their turf if they wanted my time. This did two things... 1 if the issue was really important, they dropped their tasks also. 2) If another PM thought I should be on their tasks, they had to talk to whoever was in the room watching me. If no one was there, then I changed gears to the new request, and let my manager know that the constant shifting was slowing me down and preventing any real momentum.
Once the PMs werent able to blame me, management sorted things out and stopped giving me multiple top priorities, and most importantly, the PMs all realized that they had been sold a lie.
we just all stress out and have 10000 tonnes of pressure 24/7/365
Typically, this is the norm. Eventually, key people get better jobs, and it all comes tumbling down. Then they outsource it all. Then it gets expensive, and does not fit well. Then they hire a new team. Lather, rinse, repeat...
Yes, I'm not familiar with the terminology in TFA, but I suspect it's the same situation where we're up against the wall with multiple systems down and a Sales laptop infected with a Croatian automailer and the VP comes and says:
"Stop. Just stop. I know you think you know where your priorities lie, but you're having difficulty seeing the big picture and you have a bad attitude from your inability to prioritize. So all of you come over here - I can't get this funny cat video to play on my iPad and it's crucial for this Sales presentation."
Not all projects are incremental in nature. You can't jump a chasm in five small steps.
There are projects where agile is a godsend, and there are projects where it will only do harm. Most are somewhere in the middle.
Simple - cage match. This is a political problem, not a technology problem.
So: Invite your stakeholders to a Priority Planning Meeting (this is the 'cage match') and tell them:
1) Here is the list of invited stakeholders (name names).
2) If your priorities aren't important enough to come to the meeting, they'll be rated unimportant.
3) Come prepared to convince your peers why your projects are more important than theirs.
4) Your choices will set the project priorities for the next month (or week, or quarter.. some multiple of your iterations).
5) List the projects that are "on the table", along with their respective stakeholder(s) and your team's "cost" estimates.
*shrug* Then let them hash it out.
Agile fans would call this a kind of planning game; you'll probably make more progress telling your stakeholders it is a Priority Planning Meeting.
The smart ones will line up political support and make deals before the meeting.
Pro-tip: if you don't know who your stakeholders are, you have bigger problems than you are aware of. Seek professional help and with a qualified consultant to help you find out who they are.
Other random bits of advice:
A) Don't try to make everybody happy.
Even if it were possible (which it isn't), that simply isn't your job.
Your job is to allocate scarce dev resources to best serve company goals.
B) Verify with your boss that your job is to Allocate scarce dev resources to best serve company goals before holding the meeting, and let your boss know what you're planning so they don't get blind sided by it (that makes bosses unhappy).
C) There is a very real chance that everyone will be unhappy. Throw the unhappy people a bone and ask them to give you additional funding options: "Ok, so if your project is so important, what budget will cover it?" Then you have more options about how to get things done.
D) Work out (in advance) how to choose the winning projects: you could hope for consensus (100% unanimous agreement) but... a more practical method might be to give everybody one vote, or N-votes based on their %ge of their operating budget. Also work out how to handle tie-breaking; perhaps recruiting an arguably neutral third party, like the "Product Visionary" or someone, so you stay out of that hot-seat.