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?"
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!
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.
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.
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.
This reminds me of an internal application I (re)developed for a very large shipping company. The company used conveyer belts to move most of their packages between sections of a central shipping hub. At the end of the shift the floor manager for each section would walk along to find issues with the belts in their sections, which could then be submitted with a rating of 1 (unimportant) to 5 (critical). Without fail, the floor manager would rate every problem 4 or 5. This caused issues when running reports for higher management because they would see a bunch of 4s and 5s that had been in the system for weeks. Despite instructions to stop doing this, it continued.
I took the (spaghetti code) application and rewrote it, including a large number of enhancements. One was that whenever one of the mechanics went in to check on a problem, they could assign it their own level of importance, which was usually far closer to the actual severity of the issue. Then they'd take care of what they considered 5s, then 4s, etc. In addition, the floor managers got to see what the mechanics rated an issue. While I'm sure they didn't like their problems being downgraded, it gave better feedback, and if they felt an issue was truly a 4/5 then they could take it up with someone higher; maybe they didn't explain the problem correctly. Reports also showed both ratings so there was a better understanding all around.
In short, let the users dictate their own priority, but with the understanding that it's not the ultimate priority. IT can then assign their own, and if the user feels wronged they can go higher about it. (Obnoxious users will do this anyway, but having a system that compares the two gives one more wall for them to climb.)