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
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!
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
It sounds like they need more than one project manager and a number of additional worker-bees to get the jobs done.
Start by showing the problem to senior management and tell them flat-out that there is no way to get all the projects done on schedule unless they hire enough people that each project has enough people on it to get the job done. It's always incumbent on workers at each level to give their best (i.e. worst-case) estimates of how much work is required to execute a project and how much time it requires. (Some work can't be accelerated past a certain point by adding more people.)
There are three responses that might generate:
* "you'll just have to work harder" This response is not unusual but tells you you're going to fail anyway and is a signal to get out of the organization before it crashes and burns.
* they'll cancel some projects and focus their people on the remaining ones
* they'll hire some more warm bodies to get more work done.
Also, you need a way to shield the people working on each project from interruptions generated from outside the project and the project managers need to insulate their people from scope creep.
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.
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.
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.
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?"
"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!"
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
"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.
To me it smells of poor management period. The fact that they were able to get into a position where projects are slipping and it is then the worker's job to convince management that something needs to be done.
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.
"If you are going through hell, keep going." - Winston Churchill
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.
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
One of the problems w/ project management when one is bombarded w/ projects is that one has to have a continuous line of communication to the boss, which obviously means less time actually working. Oh, that, and meetings regarding the project as well. One solution is an online status tracking system that gives anybody an instant status level as to where in the project it's there. That way, one can determine where the bottleneck is, and work towards addressing it there.
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.
This.
You will be amazed how much more can get done on projects when you have dedicated Firefighers and Babysitters. Another helpful suggestion is to make sure that the Babysitters have teeth. Upper management is not going to care what IT processes are in place to keep the whole infrastructure from devolving into anarchy. They want what they want and they want it fast.
Make sure your babysitters are the best of the best, and make sure that they can affect immediate change in IT without having to go through the proper channels. If they need to open a port on the firewall then they should have the passwords and access to do so. If they need to have an account created make sure that they can log into the LDAP server and create one, etc...
So many IT people get angry about this claiming that they shouldn't get special treatment. Bullshit. They should get special treatment because they are the Upper Management, they are pretty damn special. You don't want them waiting and you don't want their IT requests to slow down the project guys at all.
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
Make sure your babysitters are the best of the best, and make sure that they can affect immediate change in IT without having to go through the proper channels. If they need to open a port on the firewall then they should have the passwords and access to do so. If they need to have an account created make sure that they can log into the LDAP server and create one, etc...
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."
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
Ye flipping gods- another one.
No. Just No.
Sarbanes-Oxley did NOT make it illegal to change production software in public companies. What it DID do was make it a requirement that the management of a company was legally responsible for the financial reporting of the company. So even if the financial reporting software had a problem, they are still on the hook for it. All the IT auditing firms got together and agreed that meant the FINANCIAL software needed to have all the changes be approved by the proper applications owners and that there needed to be an approval process, documentation, and all the other stuff that makes auditors (and no one else) happy.
Those same auditors have pushed that in order to avoid risk, EVERY software application should go through that same process even if it has nothing to do with finance. Risk-adverse management agreed. So now most public companies force Sarbanes-Oxley compliant processes on every bit of development, costing huge amounts of wasted time and money.
Skipping it doesn't mean it is illegal. It means that if your company is audited and a set of software is found to be the cause then it is possible the management might get fined. To the best of my knowledge, this has NEVER happened. And I feel comfortable saying it is unlikely to ever happen.
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.
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.
A sig is placed here
To display how futile
English Haiku is