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 just all stress out and have 10000 tonnes of pressure 24/7/365
Hire a proper project manager.
Yes, it's that simple. Practice agile development and keep a prioritized backlog of work and this never happens. "50% of projects are rated [high]" basically means you have no prioritization.
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.
Sounds like you're honestly understaffed. If you guys are honestly working as hard as possible and things are still going unfinished then its not a problem of priorities - it's a manpower problem. Hire more people.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
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!
The development head should only accept dev requests coming from the heads of other departments.
A weekly meeting with those dept heads and the dev head to discuss priorities.
This way, priorities are not your problem anymore. Dept heads "fight" / discuss / negotiate to be on top of list. Dev staff / budget issues come clear on the table.
It's a win win.
Slashdot, fix the reply notifications... You won't get away with it...
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".
Wait a sec, you have projects that are not "Top Priority"?
I am currently working on 7 migration projects and every one of them is top priority. To top that off, the VP has told each and every PM that their project is top priority and I am dedicated to to getting their project done first.
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
become more agile
I'm not a massive fan of agile, but in this case re-prioritizing tickets once a year is simply not often enough. Priorities change on a weekly basis. Your process should reflect that.
Most of our projects are irrealistic, so after a roll of preventive measures we just gave up...
Measures attempted:
New priority levels - We moved from 3 priority levels to 5. Everybody kept using the highest available...
Re-Evaluation of requests by an independent team - Time lost in the team = time lost in delivery...
Mandatory rule book for project requests, namely better designed requests - Administration kept ignoring the rules and we could do nothing about it...
And the list goes on.
While I cannot speak for how my company deals with prioritization (on account of there not being a defined standard for the company) I can mention how I deal with this issue. Instead of putting every task into a category (low, medium, high, etc.), I like to rank each task relative to every other task. This means that, if one task becomes more important, other tasks must be moved down the list. Transferring this idea to a company would require that a single person (likely a manager) maintain this list.
You have a classic scheduling algorithm problem. From the sound of things, your current algorithm is such that Project A, with priority n, submitted a month ago, will never complete so long as there exists a Project B, with priority > n, submitted more recently. There are scheduling algorithms that can help to deal with this, but only if you stick to them.
Also, publish your project list, including submitted dates, priorities, and lead stakeholders. If a VIP demands a project be inserted with a higher priority, make sure that that goes up on the board so that the other VIPs know why theirs was bumped back. Let them fight it out with each other.
This is easy. All projects have value, by having a few "high" priority projects it makes clear the sense of urgency imparted on these projects. Now, if ALL projects are "high" priority then no projects have any higher priority over the others. Should half of the projects have "high" priority management is just saying "Do these first if you can". So, don't worry about it too much. Just send out a list of all the projects and their priority to your boss. If your boss already gets such a list just change the formatting so it looks original.
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.
Priority levels "low", "medium" and "high" are useless, because every user thinks their features are high priority - and there is no way to differentiate high priority and really really high priority features.
Instead of priority levels, use a priority list of features or projects. All tasks go into this list, strictly ordered by priority. *No two tasks may ever share priorities*, the users (or their managers/representatives) must choose one to be above the other.
I have used pivotaltracker.com as a tool for managing this list in the past, but I'm sure other similar tools (or just a big board of post-it notes) exist as well.
Projects should not be organized into buckets. They should be organized into One True List. Absolute priority values (High, Higher, Highest, Ludicrous Speed...) are meaningless. The only workable solution is relative priorities. One PM should have the authority to prioritize one list of projects. Dev just does whatever is at the top of the list. This is the only process that I have ever seen work effectively and painlessly.
Your project management people need to provide data to management to demonstrate the capacity of your department, then make the case for either reprioritization of existing projects, or addition of more people to do the work.
Remember that a typical IT project has used 95% of its planed resources when it reaches 95% achievement.
Then it will use 95% of its resources as well for the remaining 5%.
Have this rule in mind. Once you plan resources accordingly, your IT project management runs smoothly.
Try Analytic Hierarchy Process (AHP). It's very well described in reference to software development in "Lean Software Strategies" book (which I recommend btw).
Basically you dont rank priorities of projects/tasks not on absolute scale, but on relative scale (project A vs project B, etc.) based on gut feelings, discussions with stakeholders, CFOs, etc. You end up with a matrix you have to solve to get normalized new absolute weights of each project/task.
I had the opportunity to use it once for new project kick off, I liked it and will use this method in the future. The book presents this method in context of other case studies, and it certainly has been used in many other situations.
Keep your list of projects and tasks within projects in priority order. If management wants to increase the priority of something, they need to see that means lowering the priority of something else.
You put up way too many different issues to address. Yes, we all face all of those but if you want one answer that fits every case you won't find it.
My best recommendation to start with a meeting with upper management to get approval on this. Create a 'steering committee'. What you are striving for is to form a direction committee that includes top stake holders, the people with influence not those that wine the most. The purpose is to let them decide what the give and takes are. You job would be to provide estimates and to meet those targets that you set forth.
As for feature crawl, you repeat over and over in your meetings that 1.) Any new features must be reviewed, estimated, presented in front of the super committee for a vote. Allow your new group to decide priorities for the company. 2.) Repeat... new features require new design documents, new test plans, more work, more time, more costs. Be realistic about it but provide the numbers along with the feature for a vote. 3.) Work on what projects will slip if new features or projects are added. Let them take the responsibility for what they want to fail and succeed.
That's a quick and very rough and poorly stated objective. But good project managers can do it. And a good project manager dos not need to know programming. But good project managers are very rare.
Get used to it.
It comes down to money and profit and how much B.S. can people take before they walk out the door. A lot of companies want to make money off the project phase and by God they are going to do it.
You will never get the resources you need and you will always be playing catch up.
I don't want to quote statistics but I am willing to bet everyone who has been in your situation will say Ditto.
Work with the business to figure out the business benefit in dollars for each project.
Business benefit is a combination of:
- income (if we launch this new project we will make $x)
- risk avoidance (if we don't do this we will lose $x)
- cost avoidance (if we do this, our employees will save $x minutes/day = $y hours/year * $z/hour = $total/year).
Order your list by $benefit - $costToImplement and you have your list of priorities. Some requests will drop off as the business sponsors realize they can't make a case for them.
You really need to understand why this is happening. Are the projects you are delivering so far away from user needs that they need massive repair? Or, is it really just a case of priorities being poorly assigned?
Take one project and sit down with some product managers, salespeople, and (if you are lucky) users.
If they are bundle of frustration because the software just doesn't work they way they need it to, then yes, there are a massive number of issues that are top priority. In that case, you need to rethink your development process (including product specification).
If you hear a long wish list about a usable product, then the users need to get better at telling you what is important. And I see that there are already some comments about how to approach that problem.
I tell the powers that be what I can get done, what is slipping and let them decide. I also make it clear we don't work 60 hours weeks every week, they don't pay us enough and I'm not going to burn out. I state very clearly in projects what the EFFORT is, not the duration and only commit to timelines with the caveat that if other projects get in the way, the projects won't be done on time.
... you.
If they want us to be inefficient, that's their call, not mine. I still get a paycheck. I gave up a long time ago stressing out over the choices other people make that I have no control over. I just show up and do the job I agreed to do for the amount I agreed to get paid for it. If I don't like it, I can leave. I've had other companies call me, I know where I can go if it gets worse than the other companies already are.
If someone is working 60 hours/week every week, then they are either not good enough to get a job that doesn't require it, or don't have the cajones to tell their boss they will leave if it keeps up.
Deal with it, the only person to blame is
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Do you have one?
1. Understanding your current capacity by phase (initiation, requirements, dev, etc) by Role is critical. if you don't have this you are screwed from the start.
2. before you launch each project have you done discovery to understand business and IS hours needed to complete the project? Costs, ROI, CBA, etc. Basically do you understand the full costs (as best as you can at this point) vs. what you are getting?
3. Do you constantly go back to #2 as you complete each phase? If not you might be doing projects that no longer bring value.
4. Do you understand your strategies to help pick the projects regardless of their cost/benefits? For example if your goals are to win market share but all your projects focus on operational improvements you might have a problem?
5. Building off of #4 do you know all your strategies and what percentage you are focused on for each one? 50% operational improvement, 25% win the market, 10% shake up the market, etc.
6. Do you revisit all of the above as market changes? This should be done quarterly at least.
7. Do you understand how bringing in contractors helps your capacity model? It doesn't matter if you bring in 50 java developers but your bottle neck to testing. 8. Does leadership understand all of the above? are they educated and given data to show the above?
That would at least help your discussions.
I have no idea if you work in development or system administration, but generally improving the situation depends on two things:
1) Do what you agree to do on time and within budget
2) Say no to anything else
There are lots of books on the subject of time management, project management or the software development processes and they all boil down to these two rules. If you work in a company that does not allow you to say no, read one of those books and then explain to management why working with $method would greatly improve everything (including the coffee). As soon as you get them to agree to $method you can use $method to say no (i.e. $feature is not in our sprint, $task is on the KanBan board and blocked by $actually_important_task, etc).
If you have no support from management, consider updating you resume.
Here are three books that I found worth reading:
Kanban: Successful Evolutionary Change for Your Technology Busines by David J. Anderson
Time Management for System Administrators by Thomas A. Limoncelli
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (Author)
The most interesting part are the case studies and how the authors manage to say "no" in a management-compatible way.
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?"
It's not clear why the priorities are increasing. If management is setting high priorities on everything because they've figured out that anything lower won't get done, you have to either stop that behavior (ha!) or set up a "shadow" priority list with the real priority for each project. If priorities are rising because a project really does become more urgent as its due date approaches and passes... well, the system is working. You can't have more work than resources and expect it all to get done, so if none of it can be dropped on the floor, work is going to pile up.
"High" is not a priority. "Before this, and after this", that's a priority. List your projects in order of priority. In order to increase one's priority, you have to change it's position on the list. This means that if you increase the priority of one task, you necessarily decrease the priority of other tasks. Obviously, since your time is finite, priority is zero sum.
Give me Classic Slashdot or give me death!
...then the policy is "The beatings will continue until productivity improves!"
Set a maximum of at most N top priority projects. If someone wants to upgrade project X, another top prio project must be downgraded. That should make people think twice before suggesting a prio upgrade.
If you're in a larger organization, you need a project manager who is powerful enough to tell 14 of the 15 managers with "top priority" projects to go to hell and get away with it.
The other thing you need to do is stop looking at priorities as categories, and instead think in terms of scheduling. If somebody wants to get their project done sooner, they have to move ahead in the scheduling, and the only way to move ahead in the scheduling is to negotiate with somebody who's project is scheduled before there's. For instance, assume developer A will be working on Foo, then Bar, then Baz, and developer B will be working on Fred, Barney, then Baz. If the person pushing Baz wants to get it done sooner, he has to convince the owners of Bar and Barney to move back in the line. Make the schedule very public, along with whatever changes occurred in the last week.
The point of doing that is it makes the shouting occur somewhere else, so you can get things done.
I am officially gone from
Governance processes are really easy if you always include everything every possible user could ever want.
Somebody needs to say no. That somebody should not be in IT, but that somebody should be in the business.
developers can't solve business question
Give each Manager poker chips quarterly, and make them bid for priority. That will sort the order naturally. If people act like children, it is best to let them play with toys.
Note: set a cap limit of one year's chips at any one time, or some joker will hoard them and then spend lavishly on stupid projects.
http://www.sans.org/reading_room/whitepapers/leadership/death-leadership-management_1876
Sound like you have too much management and not enough leadership.
Get a scrum master (not a project manager, those are worthless). Train people in Agile or at least some form of iterative process if you decide against an Agile environment.
Since your delivery rates are slipping start estimating time for projects and see which give the most value; complete those first.
This whole idea that things can wait a year to be looked at was ridiculous in 1990. If you're not interative already you're decades behind.
Not that this is being perfectly implemented at the company I work at, (we're working on it) I suggest changing the rules for your prioritization.
Rule 1: Projects will be prioritized with numbers, not words. No more 'high', 'medium', 'low', 'if you have time'. Projects will be assigned a priority number. The lower the number, the higher the priority.
Rule 2: Projects cannot have the same priority number. Got five projects ranked 1? Somebody has to decide which one is really project 1, and which are really 2, 3, 4, and 5. It doesn't matter who makes the decisions, as long as someone makes them.
If you're IT department doesn't set rules for non-IT departments regarding priority, and enforce them, then you will have the standard chaos.
Please stop hurting America -- Jon Stewart
I found the secret was to tell all the other interested parties how the new project would delay their project. Let them all sort it out -- they will, one way or the other.
Its a bad culture to be in, we see this now, everything is marked high priority, and you end up prioritizing high priority items. if someone submits something marked low priority, they get an email saying "lol no" and it gets shredded.
I recommend Scrum (http://bugzilla/bugzilla-3.0.3/show_bug.cgi?id=251245). The work having already been separated into reasonable chunks, at the beginning of each three-week sprint, we again ask the decision makers, "What are the most important results that we can deliver during the next few weeks?" We effectively wipe out the project list once every three weeks! It allows us to turn very quickly to deal with new priorities.
We also have technical support issues to deal with. We attempt to manage them during sprint planning by planning time to resolve them, considering our past history. On occasion, the issues mean that some priorities can't be handled during the sprint, but we usually still get most of our important work done.
Rating each item in a long list of critical modifications is not what you really want, anyway. What you really want is a periodic answer to the question above. It is almost always easier to answer that one question than it is to prioritize a long modification list. The question naturally forces decision makers to think in well-defined, manageable chunks, and it forces teams to estimate well and to deliver results regularly. Scrum puts ceremony around the question.
Having a list of arbitrary priority levels is asking for all your tickets to end up in the highest priority; everyone thinks their own tickets are important. But the solution is simple: have a priority ORDER. Don't distinguish between high and low priority items; simply sort the tickets into priority order.
That way, if a new ticket is created it can be inserted into the priority order anywhere you like, or likewise an existing one can be moved up the list -- but doing so also implicitly lowers the priority of any items placed below it.
When they see this happening, project owners will quickly realise that not everything can be high priority. If everyone carries on putting their own tickets at the top of the tree, the tickets that were previously important will drop down the list. It's a good way to focus people's minds on what is genuinely important.
You don't rate your projects priorities to an absolute scale, that invites exactly the abuse you are seeing. Instead, you rank order them, and work on the items at the top of the list. You may need a high level decision maker to make choices in the event that there is disagreement among project owners about relative rank.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Say you've got 100 features to implement and 10 priority levels. Only permit 20% at each level. If you don't have some mechanism in place, your stakeholders are naturally going to call everything lvl 9-10.
I swear to God...I swear to God! That is NOT how you treat your human!
The way that we handle priorities is to have everything rated relative to everything else. In practice this means that all of the stakeholders have to talk to each other and agree. If Product Management wants A, B, C, D, and the team can only get 3 done, then the first priority item gets worked on first, then second, then third.
yours,
kbs
Step 1: Place the abstracts from each project in their own labeled, sealed envelope.
Step 2: Throw the stack of envelopes in the air.
Step 3: Sort priority by A) which ones landed face up, and B) the order in which they landed - i.e., topmost face up envelope is priority 1, second topmost face up is priority 2, etc.
While that method may, on the surface, seem idiotic, it's no more so than the methods employed by most companies I've worked for.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
Just take the two stake holders who are giving you grief and lock them in a room with one sandwich :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
The head of IT is not pushing back and losing focus
a) have a manager to designate which projects are the most important.
b) queue the projects to give a more realistic idea of when they will be actually completed
c) if the result is that some projects are going to be unacceptably late, you have a case for more staff, subject of course to the restriction that 9 people cannot make a baby in one month,
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
"We typically fire the entire IT staff every couple of years and try to hire replacements at 70% salary under threat of outsourcing.
Haaaaaa !
Minimise work in progress. The key is to put a limit on the things which will be actively worked on. This puts an economic value on your team's time within the company. If you don't do this, you are effectively free and why wouldn't they then just chuck more and more junk at you?
It's then up to management to actually do their jobs and decide what is important and what is wishful thinking.
Note, it's probably not your job to decide the business priorities.
Deleted
It was pretty basic, and damned effective. We had an online request system with three priority levels (Low, Medium, High), and a warning that choosing the incorrect priority level for your project would cause it to be delayed. If someone chose High priority when we knew that it wasn't (like they wanted a test server to play with), it instantly got demoted to Low and the customer had to wait an extra week for it to be done.
After seeing their co-workers low and medium priority projects being completed long before their own, most people took the hint and started categorizing their requests properly. The ones who didn't waited a lot. Sure, they occasionally bitched to management about the delay, but we usually had the work done before our management even bothered to respond to their complaint.
"I work for an IT company that has a steady stream of projects .. our development resources are not sufficient to cover the amount of projects. As a result, our delivery dates are slipping .. How does your company deal with this inflation of priorities?"
Fire whoever compiles the project list and then have the technical staff choose a single project and work on it until completion, then move onto the next one.
We were in the same situation.
We have spent over 80% of time on P1 projects, and the lower priority ones, whatever small they were, did never make it. The users realized, they have to push for P1 if they want to make it happen, making it even worse.
Then came the ROI ranking. Work on projects with highest return on investment. Just same happened! Some gigantic projects could prove a high ROI, and took all the resources. Also bigger projects are higher risk, so it happened a few times that we spent a lot on a high ROI project, and then it was cancelled for external reasons.
We now have an allocation like we spend 50% on high priority projects, and assign 50% to high ROI low priority/low risk/small projects. Like a real portfolio :-)
anon coward
In my experience, the only way to deal with this is to use a force rank priority system, meaning everything is put into a stack, and you work from the top of the stack. You only rank your requirements relative to each other and not against some sort of "high, med, low" system. If you do this, you need to expose the ranking to all the stakeholders. If they have problems with the ranking, they can negotiate with the other stakeholders. Yes, "deadlines" will absolutely slip, but you are providing value by doing the most important things first, and everyone knew what was most important. A lot of people have trouble with this, because they are used to just kicking and screaming until they get what they want, but it is better to train the stakeholders to work this way than to deal with the alternative.
Then we were acquired by a bigger company, we became a smaller sub assembly in a larger machine and I became a smaller cog in proportion. Initially all the new fangled process requirements, paperwork and bureaucracy looked like waste of time, time taken away from actually working on delivering features. But I realized what the upper management really wanted was accurate estimate of feature delivery dates, good reliable feedback etc and the paperwork was their way of asking for it. Then I learnt all the terminology. I specify my team capacity. "You can assign any priority you want for your work. I will give you the story points needed to get the work done. My team capacity is limited. You guys fight among yourselves and tell me what to schedule when. " is my position. It is actually working.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
as soon as the project manager suggestion adding a "medium high" category. IT staff flipped. We would normally have five high priority projects. All of IT said put them in the order you want done. Now they just keep changing the order.
Go get a copy of the Mythical Man Month - read.
Divide up your IT staff accordingly - especially in the area of support (level 1, 2 & 3).
Level 1 - interacts with the customer - handles 80 of the calls themselves.
Level 2 - Keeps the overall support operations intact (making sure that Level 1 is consistently working with customers) - they also meet regularly with Level 3 on what could be done to reduce calls. They need to be able to handle 90% of the remaining issues.
Level 3 support is also apart of development. They the the messily, remaining, 2% of calls. However, these are the intractable issues that require a developer's touch. Once a level 3 solution is found, level 2 can disseminate it to the Level 1's.
The point here is that you have folks that are primarily dedicated to a particular specialty. But you also have a system whereby issues get communicated back and forth. Solutions bubble down, intractable problems bubble up. Developers find what issues are costing money and have an incentive to fix them on the next go-around.
For example. 100 projects. 10 are high priority. if an 11th comes in before ANY work is done on it one of the top 10 MUST be demoted to lower priority.
It makes a bunch of the management whine like babies, but it works and keeps us at optimal.
IT requires a CTO that has a backbone though.
Do not look at laser with remaining good eye.
Everyone is telling you that you need more resources (people, project managers) to get the work done, but I think you already know this. What people aren't telling you is how to go about convincing upper management that you need more resources. So, without giving you a full college course, here's what you need to do: 1) Start recording metrics. As much as possible. How much time is being spend on which projects? How much money does that time cost? How much money is the the result of that project going to save/make the company? How much OT is your team putting in, which reduces their quality of life, which reduces their overall focus? If you don't know how to answer these, then start taking "quality questions" to your management regarding some of these concerns. 2) Once you have metrics, find which projects are marked "high" which aren't actually resulting in high-output. 3) Once you have even more metrics, prove that your team is saving the company money and you can save them even more if you have a bigger team. 4) Good luck!
You talk better than you fool!
Sure. Microsoft Project. But it won't work.
The problem is management, not software.
The developers will have to spend some of their time updating the charts .........
But the real problem will be that management can "work" the numbers so that their goals LOOK like they'll be met on the charts.
Then the developers will have to explain to management why they aren't hitting their deliverables at those milestones. The software says that they should be doing it.
So the developers will have to spend more time updating the software to show why they're behind.
And the cycle continues.
Someone at the management level needs to be able to say "No, we don't have funding" even for the "little" projects and "minor" changes. Otherwise the other projects will all slip.
But it's okay if Project X slips a week, right? As long as I get my project (which won't take any time at all I'm sure) along side it, right?
Maybe if we just change this "works 8 hours a day" to "works 8.5 hours a day". There! The software says that it can be done!
Why are all the projects slipping again?
When working for a military contractor, our client (the Army), would constantly rate every project of theirs as a 10 (on a 1-10 scale). Because we couldn't distinguish which project was more important to them, we had to create a secondary rating scale just for them. We would then ask them if the project was a 10 - A, a 10 - B, or a 10 - C... (rolleyes)
Allow every manager to escalate exactly one or two projects to "High" priority at a time. If they escalate a third project, they have to downgrade one first.
Nobody wants to hear their project is not a priority. Terms like High,Medium,Low etc are attached peoples ego. What you need to do is come up with some other system of classification. Ideally one that does not make it entirely clear what 'priority' is even attached. Use a system like "Customer facing, feature", "Customer facing cosmetic", "Internal process improvement", "Bug fix", "Regulatory Compliance", etc.
These things that have a more objective criteria, a requester project is customer facing or it is not, its cosmetic (I want this to be different font size) or its not. You get the idea. Next you get upper management to assign a "priority" to your project classification criteria, which you don't need to publish to the rest of the organization.
This way you don't Bob, feeling like he less important than Ted because his project was not classified at as high a priority. You avoid the whole power conflict aspect.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Ask for ROI estimates instead of (or as well as) priority estimates. This won't work in every environment, but where it works, it can have a lot of upside.
I put it in play at a company where the engineers worked directly with marketing. One of the marketing guys was a pure sociopath -- lied about his priorities every single time, regardless of the upside for the company, just to keep his numbers up. After one particularly expensive project that generated about enough revenue to cover the electricity for the coffeemaker, I asked him for an estimate of ROI on the next project.
As it happens, he was actually a pretty sharp analyst, and he gave me some really accurate figures. They were low, and he acknowledged that his new project wasn't really high priority compared to the other things on the plate. He didn't even seem upset about it -- once he had run the numbers, he couldn't deny reality. It was the numbers' fault, not mine.
As noted above, this obviously won't work in every situation. When it does, however, it is quite effective. It also has some significant upside for marketing the IT department internally. If you keep track of the estimated ROI figures, and follow up for actual figures, you can make a clear case that IT is a profit center, not a cost center (as it is often perceived).
Stop-Prism.org: Opt Out of Surveillance
I'm okay with infinite backlog. I simply make sure that I know at any given time what my first and second priorities are (in case I finish the first, or get stuck) and then start working. They can change priorities all the want. I told them there was one thing they had to mind, and it was that changing tasks in the middle of something was extremely stressful, and they shouldn't do that if they can help it. Since then, new priorities are always 'after you finish what you're on' and everything is fine. They change their priorities every day, so long as I can get out of what I'm doing that quickly.
That's what they pay me for, and they appreciate it.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
One of our Senior VPs was tired of similar situations at my company, so he brought in a Project Manager whose sole focus was to implement a Phase Gate methodology to all the Business projects that involve requesting resources from other departments (such as IT). Part of the process is a discovery phase so that the project can be analyzed for viability (business case, resources from other departments like IT, Finance, Engineering, etc). Large projects have a steering committee consisting of the department heads (VPs) who can say, "I have X number of people, and all are committed. If you want this project to go through, I have to pull people from one of these other projects."
The business units are then responsible for prioritizing their projects so that the resources from each group can be allocated. Occasionally, things get shifted. But not without consultation with various executives and leadership to ensure that everyone can properly adjust.
It's big. It's cumbersome. It has its politics. It's not suitable for everyone. But damn, it works pretty well.
First of all priority is not simply ranking something H/M/L it's putting them in order even if it is the result of flipping a coin. You also have to perform this activity on a fairly regular basis (at least once a quarter). Finally the governance structure you have in place for changing prioritization needs to be formal with a single point of accountability to decide prioritization disputes when needed. If you do this then a few good things will happen. 1. Individuals won't easily be able to overstate their priority as they aren't just bamboozalling the develop and PM they're having to explain it to other business folks with competing priorities. Additionally when they disagree it will get escalated and decided based on some reasonable higher level principle like financial business case or risk reduction. 2. When priorities change (due to delay and inflation or something totally different) the users have to decide among themselves rather than with IT how it change the queue. 3. When IT is short staffed and can't deliver on the priorities it will be very obvious to all involved and you'll have metrics to show it. If they choose to continue to underfund the department then at least you can project how much will get done ever year from their list and manage expectations accordingly.
Fire some of your sales staff, hire and train more employees, or start turning business away.
That's nothing. Every time the director mentions a project, the manager moves it to #1. I like going to a staff meeting first thing in the morning to find out what the project requirements are today. I remember Paul Newman in the film "Hombre". After wounding a guy he tells the guy to quit moving around so he can do better. It's hard to lead a target moving in an infinite number of dimensions.
Where the goal was to have only 10% of projects rated high, within a year nearly 50% of projects are rated as such.
You need to have definitions for terms like priority, high, and goal. If "high priority" is defined as "The most important 3 projects" then you will only have 3 projects that are high priority. If it is defined by a democratic vote of what people think sounds important, everything will be priority.
Priority is really a consequence of other factors such as deadline, cost, or opportunity. So you could define "high priority" as anything where a schedule slip of more than 10% jeopardizes the viability of the project.
Charge differently for different priorities
Higher priority = higher rates.
I'm serious. Charge 50% more for high priority tasks. In this way, the project is not strapped for funding in any way and expedite fees can be used to get outside help.
It is also important to properly estimate projects - money AND time. Explain to management that no matter how many woman you put on the "baby order", it is gonna take 9 months, but if you don't have the right women for the job, you will never get a baby.
If a project is lower priority, then it gets a discount. It will probably never be worked, since at the next funding cycle, other projects will get higher priorities again.
Prioritization is a management responsibility. Give them 5 priority levels and only 20% can be in any category. Somehow the estimated level of effort also needs to be included, since putting 20% by count could end up with 2 HUGE projects.
I've seen this model work at a company with over $500M in annual IT budget, so it scales.
OTOH, for a small company with limited budget, I doubt this will ever work and you'd be seen as an obstruction to progress.
You can't simply take 2 Generic Projects and deal with them in an intelligent way to make this problem dissappear -- you need to find convergances and synergies to make the multiple high priority problems a subset of a single issue that is tackleable quicker than had you tried to take them each on independently. And that requires domain specific understanding of each problem. Repeat for everything in your queue.
This, by the way is really hard but it is the best way of dealing with this problem and is why the best programmers justify 10,000x the pay of the average ones.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Simply put: I don't.
I set MY OWN priorities based on the technical analysis of the problems and the resources available, and publish them.
The company priorities are NOT IT priorities. They are a factor in the decision about IT priorities, but they do not SET IT's priorities unless you're fool enough to LET THEM.
Every user or department who is allowed to set IT's priorities will claim their pet project is priority one, regardless of what's good for the company. Only the people who KNOW the resources available and have to deal with ALL the customer departments can set realistic priorities for the IT department itself.
I do not fail; I succeed at finding out what does not work.
It's a matter of definition; Priority in its normal sense should be interpreted as the order of importance for /all projects/. /not/ order all projects, but instead make a very limited number of classes (low, normal, high), and allow an increasing share of the projects to "migrate" to the "high" class.
However you, as is customary (to be able to present primary-colours-only pie charts to dim-lighted management) do
That way you yourself are defeating the very concept of prioritizing.
Either prioritize each project in the full set (so for 100 projects, you have priorities 1-100), or only allow a maximum number of projects in each class.
We use a technique called “Project Management”, works wonders
Priorities are helpful, but without estimating the work effort they lead to chaos and stress.
Try this: Estimate the amount of time each project will take, then block out that time on a highly visible calendar. Then you know what project you will spend what day on, and everybody will see your estimated completion dates.
If someone reorganizes your priorities, you reorder the days on your calendar, and notify the people whose project gets screwed over. Then they will fight it out between themselves.
Welcome to resource driven project management.
Here are all of the tasks we are working on in priority.
If someone wants to bump up the priority of one task, then they will
have to duke out with the owner of the task they are bumping.
Not you.
The easiest way is to not assign priorities to projects. You do need to prioritize, but don't start with a list of priority levels and assign them to projects. Start with a list of projects, list the benefits to business if they're completed, the costs to business if they're not (including things like increased development times) and the resources needed for each one, and have business sit down with IT and sort that list into order by priority. There's no such thing as a high-priority project, only one that's higher on the priority list than another. Then, IT will work on the highest-priority projects that they've got the resources available to complete. That eliminates priority inflation, and forces business to really deal with the big picture instead of looking at each project in isolation and making it someone else's job to make it all come together.
Tools like Microsoft Project help here, if you've got the resource management tools set up properly then it just won't permit schedules that allocate more resources than are available and it won't let you reduce the fraction of a resource allocated to a project without increasing the time needed to complete that project. And you won't have to try having IT convince business that you have to follow the scheduling software's arbitrary rules, you can get outside trainers to come in and explain that as part of teaching the business people how to get the most out of the scheduling software. You just need to make sure that it's IT, not business, responsible for determining the level of effort needed on each project, and there's a fairly easy way to do that: the person responsible for determining the level of effort is also the person responsible for any schedule over-runs. It'll take a bit of politicking to do this, but in this age of increased compliance reporting it should be an easier sell.
We adopted a system where we 'friend' the critical issues. The one that gets the most 'friends' climbs up the priority list.
Everything else gets a nicetohave tag. They can just join us later for dessert.
WARNING: Smartphones have side effects--most of them undocumented.
I deal with this very simply: Each 'Project' or "work effort" has an estimated number of work (in man weeks) associated with it and each one has an estimated delivery date, a desired delivery date.
Any worker who is working on more than one thing at a time has their time multiplied by a "task switching co-efficient" which is
1.2 - ( 0.20 * number of projects they are doing simultaneously).
So a worker doing only 1 project is fully productive, 2 projects, they are only 80% productive, 3 projects, they are 60% productive, etc...
Each "customer" (manager) gets shown what their calculated delivery date is, and what it would be if their project was deferred until it could have only dedicated workers on it. They also get shown predictions of what the delivery dates are if more resources are added to the development group.
It blows the minds of the customer(Managers) when they see deliveries get later when resources are added! Each worker has a familiarity co-efficient that is calculated by multiplying the inverse of the project complexity rank by the number of weeks they have been on the project. How valid is all this stuff? per individual - not very valid, but overall it forces the other managers to understand the impacts of resources and changes on the amount of time it will take their project to get done. By making it mathematical, and more realistic than simply (Manweeks of work / # of workers) It forces them to look more realistically at the problem.
I have an internal web page that lets other customer/managers tweak the schedule to see what happens when they make changes. I encourage them to use it during meetings so each customer/manager can see what the other customer/manager thinks each others project should be delayed by. (They fight each other, not development.)
I also use Individual co-efficients for each worker: productivity, affinity, flexibility, robustness as well as each worker having a different calendar. These measures are kept private. Only I see them, but they are used to calculate the time it takes to produce each project. They are kept private for 2 reasons, #1 - the managers waiting for delivery will try to force the development department to put the engineers they perceive as best, on 'their' project. #2 - to protect the privacy of the engineers. These rankings are arbitrary and , being produced by a human, are also fallible. I refuse to let these "labels" become public, there is to much potential for harm.
Affinity- a ranking of that person's Project domain knowledge and how expert they are with the languages and tools being used on that project (and how much they like/dislike the tools or the domain). Used as part of their productivity rating, which - note this: is different for each project!
flelxibility- People multi-task differently. some folks are 140% productive when working on just 1 project and drop to 50% productive when they have to work on more than one project at a time. So each person gets their own co-efficient on this as well. Some people are best used by dedicating them to one thing at a time. Forcing the "140% on 1 and 50% on 2 " people to multi-task is incredibly stupid.
robustness: This a measure of 2 things - First - how "strong" is their code algorithmicly? eg - does their code do the work by being well thought out and therefore have a 'simple' flow? Or is it a long running chain that handles each condition as a special case instead of having the solution fall out by design.
Second, What is the defect rate in their code? (includes mechanical/transcriptional defects as well as algorithmic and domain defects)
Many people in software development are naturally "single threaded" and I laugh whenever I see the job ads that include "Must be a good multi-tasker" for software developers. Forcing developers to multi-task is always a bad idea in that it usually slows down all the work being down. In IT
If you were to suggest at say a shipping company that at the end of the year you dump all the unshipped packages in the ocean and start with a clean slate... welll, some might do that but it is not policy! Just practice.
But to be serious, the idea that you got more work then people to do it and that this is done year after year is insane. You can't have any sensible planning this way. It means projects that are not high priority have no chance of being completed, so they are elevated and this just adds to the load.
There are only two solutions, either optimize your production methods OR increase the amount of staff working on it. Yeah yeah, training new staff costs time but if that is your excuse, just resign and kill yourself. Understaffing is only fixed by the company going bust, so if you don't fix it now, you will only have even less hours to train new people in the future.
You can of course start to reduce the number of projects but they SHOULD all be mandated by business needs and anyway, changing this when you are already overloaded will just consume even more resources and telling people THEIR needs are not important... well, do you want to continue working at said company?
Any other methods are just putting your head in the sand and hoping that with continued growth of the company, customer base, feature set and code complexity, things will magically get better.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I used to work in an industry like that. So we started setting up annual Users Conferences and have them duke it out.
There can be only one... top priority. Do not multitask. You are only increasing your own pain as people attempt to make multiple top priorities upon you if they see you multitasking.
Fairly simple: create 3 categories only, with one category stratified
1: Low priority
2: normal priority
3: bonus pay approved
the department or manager wishing to have a project in the bonus pay approved category approves a %bonus to anyone while actively working the project
Highest bonus projects get highest priority.
This bonus comes from THEIR budget.
Just threaten those developers with a mandatory editor, vim, emacs, eclipse or nano, switching every week.
The productivity (measured in broken bones per week) will skyrocket without expensive goons.
If you have some sparse time (yes, this is a paradox) you might want to have a look at the book "making things happen" by author Scott Berkun (Ex Microsoft project manager).
The first edition was also featured in a slashdot post:
http://slashdot.org/story/05/11/14/236200/book-excerpt-the-art-of-project-management
Though I'm an engineer and not directly involved in project manager topics i found it highly helpful. It covers basically just the questions you're asking.
note #1: I have no relationship whatsoever with the author
note #2: Also, I'm no native english speaker. Hope this explains possible grammar and translation errors.
This is outlawed since Clinton was in office in any public company. The penalty for doing this is that it can expose senior management to personal liability.
So : good luck with that.
At my employer we deal with this by assigning all features and bugs a relative priority number. Cleverly we make 1 the highest priority and 4 the lowest priority. While counterintuitive, this means that you can't just add new features and give each one a higher priority number than all existing features by increasing the old highest priority number by one. So instead we add new features and give them a higher priority by giving them a lower priority number. The first new feature gets priority 0, and subsequent new features get negative priority numbers. We consider small projects a success if features with priority higher than -8 get implemented, and large projects a success if features with a priority higher than -32 get implemented. Occasionally original features get reassigned lower priority numbers to give them higher priority to indicate that they actually are as important as the features that were added by our management just before we would have released it.
Priorities should never "rise" since they shouldn't have a nominal priority in the first place. Instead, all projects should be sorted top to bottom. They can always be resorted as dates slip and business needs arise, but the very fact of giving someone the possibility of making something "high" priority or some such nonsense is the mistake.
This was pulled on me last week. Apparently, my email about understaffing didn't go over too well, and it was assumed that the network was incorrectly configured. The funny thing was, it had NOTHING to do with anything but normal network issues, and for the most part had more to do with getting everyone's itch scratched concerning more mundane issues like laptop battery replacements and toner.
Management simply does not grok what I do (everything from A+ level to VMware), and with a tripling of students in the last three years, things have gotten out of hand. So the 'network audit' told them nothing but that we had 'a leg up' on most schools and that I could use some help... Heh.
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
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.
Usually :
* users assign priorities, from critical to low
* you have several users comepting for IT time
* everyone marks his project as critical
I found a simple answer, which needs some balls to impose, but which works for small dev support issues
* critical priority : issues is billed @ least 1 man day and escalated to upper management
* high priority : issue is billed expensive. So I work 1 horu on it, I bill two
* normal : normal, but will be internally prioritizeded as high past a week (but bille dnormally)
* low : discount billing
This method should be applicable to any porject where yiou charge /time. If you stand still on it at the beginning, result gurantees priority control.
The issue with using a priority level is that there can be many projects with the same priority. The better way is to have an ordered list of projects where the order is the fine level of priority in the broad category. This allows a few things to happen.
1. The Dev manager can the allocate time to each project and when he runs out of dev time it becomes obvious as to what will get done and what will not.
2. It puts the onus on the project proposer to make the case as to why their project should get more resources.
3. It allows the departments to allocate some of their budget to hire contractors to fulfill their needs without impacting the Dev budget too much.
Priorities back up because you're not working efficiently and getting things done quickly enough. You also can't just arbitrarily dismiss your priorities and start over every year. That's just giving up.
I suspect you're allowing your priorities to slip because you're trying too hard to be everyones' "friend," instead of an effective IT manager.
I cut the bottom out of the totem pole every 3-6 months or so, or whenever things get too far behind, and hire more effective people. I am willing to pay for them. I can hire someone who commands 10% higher salary, but they do twice as much work as someone who sits around playing angry birds all day.
Not a single one of my staff earns less than $150K, but I have less than half as many of them as other companies would have for the same mission. When I started here, the IT budget was 50% larger than it is today under my direction, and provided fewer services.
I hate to give it to you bluntly, but if you're leading an organization that has issues, those issues start with you, because you are the leader.
...just pressure the staff to work late every night and all weekend, but keep paying them only for 40 hours per week. And cancel all leave around Christmas.
worldmobilenet.com -- World Prepaid Wireless Internet plans
I have dealt with this issue many many times in my career.
You need the discipline to know what is important, what is not, and to ignore the things which are not. That is it.
This is always a sign of management failure. Quit your job and find a new company to work for, because the managers you are working with are incompetent.
If you are managing your own workload, see my second sentence above.
Stop taking new projects until the team can catch up or hire more people. Whatever is easier to sell to upper management.... However, my personal thought is that you are experiencing the result of a business model already studied and executed by the upper management, so you are doomed.
Rather than gathering and focusing new and existing resources to actually get the project done, you focus on managing the prioritization. Then you plan in advance to do an annual chuck-it-all and re-prioritize everything that you already know has no chance of getting done from scratch, never actually getting the project done.
To hell with middle management! You've got a real future in government bureaucracy.
To answer your question; my company hires more resources to get the job done. Occasionally we'll clean house and eliminate the "dead wood" that isn't producing as well as it should or did in the past.
Establish an IT steering committee. Get all those people who have projects assigned to IT (director, executive, vp, etc) into one room and make them argue over what's most important. Use a 1-10 number system based on functional area to start with. For us (mid-sized healthcare company) it would be like: Clinical, Finance, Operations, Legal (etc).
Have this meeting every other month (at least), because priorities change. One of the main goals here is just to make sure that everyone knows what you have going on. When one random director gives you a project he doesn't realize you have 900 other projects going on, how could he? A big part is just giving everyone more visibility into IT's workload and priorities.
P1 through P6 :-)
P0
Must fix list.
Top 10 Must fix issues.
Ship blockers.
Sales blockers
Must fix in next release (really, we mean it)
Here's a tip: They'll ship it and sell it anyway whatever it is. They always do.
That's not to say you shouldn't strive for excellence, but you have to keep these kind of arbitrary list of stuff that MUST BE DONE OMG! prioritizations in perspective. Most people don't use any more than two of the 1000 features anyway. (If only they'd agree on which two).
I bought a motorcycle.
High/Medium/Low don't work as priorities when you have more projects than priority levels. Sit all stakeholders down together in a meeting with a list of all the projects to be done. Give them two rules:
Presto, an organized list.
I call it the Feature to Production ratio. That is the ratio of required production capacity to develop the stream of incoming features as compared to the actual production capacity. I am not joking when I say that I am right now at around 10-20 to 1. I can't say exactly as I don't even bother examining the incoming stream in detail; I just pick the most valuable features out of the stream and pretend the rest don't exist.
I would say the main problem is that the incoming stream sometimes contains interesting Gems that can distract from finishing an earlier, nearing completion, feature.
In a perfect world there would be a certain amount of self filtering that would polish the gems and then hold on to them until the last feature was completed and deployed.
We just hire more managers. Hasn't failed yet. (Posting anonymously, which I normally don't do, because it's actually true.)
Any change in budget requires approval. Simply require any request for change in your projects to require their supervisor's approval, which includes any changes need in your budget to handle their request without impacting the rest of your requirements. It's simple. You want more, you have to pay for it. If it's the president of the company, ask him/her what don't they want you to do. If that person can't give you an answer it's time to start looking for a new job. Until it's in your budget, it goes in the circular file.
There are numerous tasks that need to be done eventually, even if they are notionally lower priority. Either their priority rises with time, or you have a scheduling algorithm that guarantees that low priority tasks get *some* resources.
Stack the priorities up, if they must have them.
Show them what the added cost will be. If they're willing to pay for it all, its their money and their project. Just be sure they're doing with eyes open.
It is REAL simple, reprioritize. you claim the original plan was 10% priority one. STICK to that. When you get too many items in the 10% bucket, bump something out.
If someone comes up with something else that has to GET DONE RIGHT THIS VERY MINUTE. Then they need to lobby for it, and drop something else. Fairly simple.
six sigma!
1=lowest
2=medium
3=high
If there is over 20% at level 3, just add one level, so you get this:
1=lowest
2=medium
3=hich
4=top
And in some years the top priority will be at level 10 etc...
That way you will never have 50% of high, and never have to purge the list to start from scratch.
Atari rules... ermm... ruled.
So what you're saying is that we should rename our High/Medium/Low priorities as: Need/Want/Like. Its all about semantics. Oh, and about ass kissing :) Not far from the truth.
Now, to get serious, projects that are higher than the level of a "hello world" program are always political. The assigned/official priority are just for looks, the real priority is ... ethereal, being re-decided perhaps every day, for each person.
I know you all want to reach that level when you just at those lovely priority numbers and make your decision based on a simple comparison like 2 3. Trying to simplify the problem is human and somehow understandable. But its still lazy.
No, you need to handle conflicts on a case by case basis. Again. And again. Forever. There is no way out. That is your job and you have to do it.
In a previous life, when I was working in IT at a Chicago bank, we had a weekly project review meeting run by a VP. When I began attending, the project list was a printout from a spreadsheet: typically seven pages of projects rated from 0 (low) to 99 (critical). Nearly all of the projects were wish-list items -- but ranked at "99" -- that required an outside software vendor to modify their software. (IT was routinely hammered over not getting these changes made to a commercial product. Like we had a lot of clout to make that happen.) The projects that the IT folks needed to get done were all ranked at priority "1". I cannot recall a single meeting where a project was ranked anywhere between those two extremes. So we had a growing list of projects consisting of page after page of priority "99" projects that were going nowhere and important IT projects like upgrading storage, patches, etc. sitting at the bottom of the last page at priority "1". Good times.
CUR ALLOC 20195.....5804M
If you have a limited resource (such as developers) to go around, find an appropriate number (i.e. points) to represent a single developer and assign points to projects in order to determine their priority. This ensures that the overall number of points that can be assigned remains the same, thus preventing inflation. To increase the priority of one project you will have to decrease the priority elsewhere, since the points allocated will have to be taken away from another project. This is similar to how UserVoice lets people assign a fixed number of votes on suggested enhancements.
It depends on what your goal is. Do you want to stop the change requests or reduce them?
If you just want to reduce them put in a change control process and make sure everyone, including IT, follows it, no exceptions other than a true production stop situation. Half the request will go away simply because someone has to actually fill out a form and commit stuff to writing.
If you want to stop all but the most essential stuff do charge backs for everything you do. The moment the actual cost of making changes moves out of IT, requests will drop off drastically. People will ask for all kinds of stuff as long as it doesn't cost them anything. The moment they have to pay for it they pay a lot more attention to things and only pay for what they really need..
At my firm we rank-order the projects in terms of priorities. That completely simplifies the resource crunch. If we're out of resources, the last unsupported project just waits.
Just make sure to allocate 10 or 20 % time to support or that will wreck your timelines.
Just create a new level above high called "critical" and move a random 10% of the projects to it. As programmers you should have seen this completely logical solution...
You need a https://en.wikipedia.org/wiki/Project_management_office
Casteism
When I was a computer systems project manager for a large multinational corporation, we used what were called "Project Charters". These described the project, it's priority, and the criteria that determined when the project was finished. To change anything required that *all* those involved (who signed off on the project to begin with) had to meet, change the charter, and sign off just as if it were a new charter. Anyone could could come to me and ask for additions or deletions, but no matter how large or small the changes the charter had to be rewritten and again signed off. This added enough work and spreading the responsibility for lowering the priorities (few wanted to be openly responsible for changing the priority of some one else s project) on other projects that it was very rare for a charter to be changed and corporate policy was absolutely nothing could be changed without going the whole development route. Project creep, or feature creep became almost non existent after we adopted this approach. In the day-to-day stuff, if some one came in and wanted something, my usual response was, "I'd be glad to, but you pick which other project will have to wait". All of our resources are tied up so something will have to wait. I was far enough up "the food chain" that this did not create any problems for me. Also even had I not been that far up the food chain I'd have still asked them which project did they want to replace as I was already working 12 to 16 hour days and teams were already assigned on the high priority stuff and no way was I going to have a corporate team do some one's pet project. Never over extend yourself trying to please those above. You are likely to end up behind on everything and look like a poor performer in the process no matter how hard you work.
hire more programmers. duh. i'm sure your overworked and underpaid programmers will love to hear all your insightful plans about how to cram more code down their throats. meanwhile, they'll hint "hmm, well if you're understaffed, maybe hire more staff? just a thought."