Ask Slashdot: How Do You Deal With Priorities Inflation In IT Projects? 304
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?"
By not having the situation in the first place (Score:4, Insightful)
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.
Get a project manager. (Score:5, Insightful)
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.
Don't let users score their own tasks (Score:5, Insightful)
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.
Re:Get a project manager. (Score:5, Insightful)
Hold it!!! (Score:4, Insightful)
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.
No one has a "low priority" project (Score:5, Insightful)
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.
The standard producer solution: (Score:3, Insightful)
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.
Ranking tasks (Score:3, Insightful)
10% (Score:5, Insightful)
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.
Do not use priority levels, use a priority list. (Score:2, Insightful)
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.
Analytic Hierarchy Process (Score:3, Insightful)
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.
Learn to say no (Score:4, Insightful)
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 [amazon.com]
Time Management for System Administrators by Thomas A. Limoncelli [amazon.com]
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (Author) [amazon.com]
The most interesting part are the case studies and how the authors manage to say "no" in a management-compatible way.
Relative priorities (Score:4, Insightful)
"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.
Re:We dont deal with it (Score:5, Insightful)
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...
Re:Get a project manager (Score:5, Insightful)
"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"
BINGO!
Don't know how many times I have to stop the project I am on because the boss's kid can't get his mac to work on the home wireless.
The IT guys wear many hats unfortunately.
A good idea is to get most projects are done after hours, work output is doubled seemingly because you are not pulled from the project every 15 minutes. Would be nice to be on the after hours team.
The problem is in no way unique to IT departments. Every department suffers from the same thing. I manage hardware engineers and we face the same issues. Everybody thinks that because a problem is his biggest priority it should be your biggest priority.
But I recognize that there's a particular problem in IT departments. They have day-to-day issues that have to be dealt with on a timely basis as well as long-term issues that absolutely must be dealt with but on a longer schedule. You have to segment the problem somehow.
Some companies have a group that only handles system-down and user complaints and other people handle the longer-term projects. Some companies have babysitters for upper management.
Re:Get a project manager (Score:5, Insightful)
I've been in the same situation. More workers were needed so that new features, rewriting of core features for stability as well as general bug fixes could be done simultaneously. That was on the company's key product that generated >50% of the entire company's revenue ($10M company). Aside from the primary product slipping the CEO was heavily invested in his pet project for a new service, siphoning off existing resources and claiming all new hires. The new service was to compliment the existing product (but could be resold to competitors as well).
After spending too much time trying to convince management of the obvious and watching all my coworkers become demotivated (hard to stay motivated when you spend all your time barely succeeding at treading water in an industry you should be swimming in) I made the obvious but difficult decision. I left. I make more money and work for a company that is focused on a single product. If you can't do a bunch of things well, then focus on one you can do well.
I've seen it a bunch of times. Egos get in the way and management is focused on doing things that make them feel like they have ownership or are in control or are doing something 'cool' to brag to their cohorts about. The difficult thing is to drop everything but what you are good at. A friend saved a failing middleware company by doing exactly that. They were in the hole working on a bunch of revenue sucking 'products' that could have been the next greatest piece of middle ware (can you say bubble mentality? Great middleware? YA). The saving grace is they had a successful support and service side of the business. He dropped everything but the service and support then focused on having that be as profitable as possible. A decade later they are still alive and the company has the best employee remuneration of their field for the market they are involved in. The company would have gone under in months without more investment money had they continued to try and make a product. Looking back it is now easy to see that their big software products plans would have never panned out.
Re:Get a project manager (Score:5, Insightful)
At my job, when us salaried programmers start averaging more than 40hr/week, they hire a new person. Once that person gets up to speed, we're working under 40hr/week, so they expand our projects.
Happy workers are good workers.
This is the whole point of kanban (Score:4, Insightful)
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.
Re:By not having the situation in the first place (Score:5, Insightful)
Big 'A' agile NEVER works, full stop. Small 'a' agile IS an iterative approach with the size of the iterations scaled to the project's needs. Pairing will happen as deemed necessary by the actual developers. Note that for small projects, the number of iterations may be 1 and the size 100%.
Like most management fads, big 'A' agile is a crude attempt to proceduralize the natural result of a group of well motivated and skilled developers with a management that knows when and how to stay out of the way such that a pack of monkeys saddled with a micro-managing idiot can supposedly produce the same result. It never works.
If you do have a pack of monkeys and/or a micro-managing idiot, they'll find a way to mess up anyway and if you don't, then slavish dedication to 'the Method' will make them act like said monkeys and idiots. At that point, success if proportional to the team's ability to game the system in order to shoehorn 'the right thing' into the provided framework. They would have done better dedicating that effort to the actual project.
Meanwhile, the true Scotsmen^wbelievers will be happy to tell you why the 99 out of 100 projects that failed miserably weren't really following the one true methodology.
Re:By not having the situation in the first place (Score:5, Insightful)
I agree that'd basically fix it, but "agile" itself isn't necessary.
Just move to a stack instead of (or in addition to) priority numbers. IMO, priority numbers are nearly worthless. Put someone in charge of the stack order, and you're done.
This will open up one new problem... you'll have to have the discussion/argument about how you operate on a stack about once every 3 months, and defend that position absolutely. You may allow priorities to be tagged on stuff for PM/reporting purposes, but make them absolutely aware that development completely ignores priority (and, if possible, remove it from display to developers).
It's a pretty simple argument: You can not have two projects that are both the top most must be done now items. One MUST be more important than the other. They (management) can yell and fuss and scream all they want but, until they commit to changing the stack order, it's just hot air and can be completely ignored.
"This other thing MUST be a TOP TOP TOP priority NOW!" - ok sir, then just drag it up to the top and make it so.
"But this other thing must ALSO be TOP TOP priority!!!" - sir, do you hear what you just said? Here, just make these a simple list in the order you want them done.
If people are doing double duty as production support and development, which will always happen to some degree, make sure to place one above the other (preferably production support - if current system isn't running and supporting your custom base, new features don't matter).
Re:By not having the situation in the first place (Score:4, Insightful)
They (management) can yell and fuss and scream all they want but, until they commit to changing the stack order, it's just hot air and can be completely ignored.
"This other thing MUST be a TOP TOP TOP priority NOW!" - ok sir, then just drag it up to the top and make it so.
"But this other thing must ALSO be TOP TOP priority!!!" - sir, do you hear what you just said? Here, just make these a simple list in the order you want them done.
If people are doing double duty as production support and development, which will always happen to some degree, make sure to place one above the other (preferably production support - if current system isn't running and supporting your custom base, new features don't matter).
This is where a change management board comes into play. If you have the management get into a room, along with key developers, and prioritize the list of projects, and most importantly get buy in from the participants this is how you get a hold of the project queue. Of course, this doesn't account for the "quickie projects" that get dropped on you, but that's where you need your manager to step in and take the arrows for you so that you don't get distracted.
Re:By not having the situation in the first place (Score:5, Insightful)
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.
Re:We dont deal with it (Score:4, Insightful)
Deal with them like my debt. If I paid all of my debt collections the "minimum", I wouldn't have any food to eat. I just figure out what I can pay and pay top X amount of debt collectors who yell the loudest.
Ask for ROI Estimates (Score:5, Insightful)
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).
Re:Get a project manager. (Score:4, Insightful)
Theme these days is, get projects at any cost, we will figure it out once the project starts moving.
Survival in the global economy demands this kind of business strategy though. It sucks I know but when you are a small company with a tight budget and you got ferociously hungry competitors in a super-saturated market then you have some tough choices to make.
I used to think this way until I saw the books and I participated in sales meetings. When the choice is to sell fiction and hope for the best, or just hope another opportunity comes around in 3 months before you run out of money for payroll... well then maybe you wouldn't be so quick to point fingers at sales.
Re:Get a project manager (Score:5, Insightful)
They also need the balls to say "NO!" when appropriate. And then suggest a working alternative.
"No, you can't install that application you downloaded from some dude in Romania. I've looked, and it is not what you think it is. But here's another way to do the thing you need to do."
"No, we won't make that Excel file editable by the entire company. It won't work like you think it will. But here's a workaround."
Re:By not having the situation in the first place (Score:2, Insightful)
Not really. First, all IT work is about Costs and business is about Profit. Some IT work actually generates revenue, and that's nice, but business is in the business of business: making money. IT needs to change from focusing on "Priorities" to focusing on "Business Value". In our organization approximately 15% of projects were support and KLO. I may have over-simplified, but our strategy was to divide IT into teams that focused one type of project (Fast, Strategic, Maintenance/KLO, Features, R&D, etc.). 15% of the IT staff supported or maintained software, 35% developed new software or features, 10% were network, etc. That's what worked for us...and it worked well for IT (I didn't hear any grumblings, instead I heard "this is the best I've felt since I started here twenty years ago." or "this is the only good change Management has done. I can breathe again.") and for Business, who now could focus on what they wanted to focus on, in the terms they want to hear ("Business Value").
Further, negative one, no threatening was ever required. Business (Director-level and above 10+ departments) was represented in our Portfolio meetings, as was IT (Resource Managers, Application Leads, Directors, PMs, etc.). Just because a Project was proposed does not mean it should be implemented...technology and needs change, some project requests needed to be questioned. In the first three months we shaved off over 90 projects (in a Portfolio of 700+) and used that budget to hire more IT staff to work on the things that actually provided High Business Value and purchase better or more efficient tools like Test suites...while still keeping the operation running with the portion of the budget that was for KLO.
I am sorry you missed the many gems in my post above. You should probably re-read it with a more open mind.
or... Cage Match! Re:We dont deal with it (Score:5, Insightful)
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.
Re:Get a project manager (Score:4, Insightful)
And this is what makes the best of the best. The ability to extract from the customer what they need and then be able to offer the best solution in the framework provided. The tech skills are only handy in the second part. The first requires great communication skills. Something that can be lacking in some IT workers.