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?"
Clearly you need to invent a bell curve. (Score:5, Interesting)
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 [wikipedia.org], 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.
% of list complete = % of bonus recieved (Score:5, Interesting)
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.
Screw the rankings ! (Score:5, Interesting)
Re:Get a project manager (Score:5, Interesting)
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.
Scheduling algorithm (Score:3, Interesting)
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.
One possible solution (Score:4, Interesting)
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.
Re:Hold it!!! (Score:5, Interesting)
I have done this before too. I had fun with it. I told the PMs that I would be working on the project of whichever PM was in the room looking over my shoulder. They literally had to stake out their turf if they wanted my time. This did two things... 1 if the issue was really important, they dropped their tasks also. 2) If another PM thought I should be on their tasks, they had to talk to whoever was in the room watching me. If no one was there, then I changed gears to the new request, and let my manager know that the constant shifting was slowing me down and preventing any real momentum.
Once the PMs werent able to blame me, management sorted things out and stopped giving me multiple top priorities, and most importantly, the PMs all realized that they had been sold a lie.
Re:Get a project manager. (Score:4, Interesting)
True story...
The business committed delivery of a huge pile of work in 60 days. Despite working around the clock with offshore resources, it still wasn't possible to make it.
Moral: The business needs to pay for any custom development out of their bonuses.
Right now- they pay a fixed amount ot IT and get an "all you can eat buffet" of work based on how hard and loud they scream.
Our current workload is 10 projects per person plus support work plus validation of data for deployment plus determining scope for the next release.
About 6 months ago they recognized we were grossly understaffed and just this week new resources started arriving. In 90 days, we'll have 4x the staff we do now. But that staff will be unproductive for 15 to 30 days after each one arrives.
Re:Don't let users score their own tasks (Score:5, Interesting)
This reminds me of an internal application I (re)developed for a very large shipping company. The company used conveyer belts to move most of their packages between sections of a central shipping hub. At the end of the shift the floor manager for each section would walk along to find issues with the belts in their sections, which could then be submitted with a rating of 1 (unimportant) to 5 (critical). Without fail, the floor manager would rate every problem 4 or 5. This caused issues when running reports for higher management because they would see a bunch of 4s and 5s that had been in the system for weeks. Despite instructions to stop doing this, it continued.
I took the (spaghetti code) application and rewrote it, including a large number of enhancements. One was that whenever one of the mechanics went in to check on a problem, they could assign it their own level of importance, which was usually far closer to the actual severity of the issue. Then they'd take care of what they considered 5s, then 4s, etc. In addition, the floor managers got to see what the mechanics rated an issue. While I'm sure they didn't like their problems being downgraded, it gave better feedback, and if they felt an issue was truly a 4/5 then they could take it up with someone higher; maybe they didn't explain the problem correctly. Reports also showed both ratings so there was a better understanding all around.
In short, let the users dictate their own priority, but with the understanding that it's not the ultimate priority. IT can then assign their own, and if the user feels wronged they can go higher about it. (Obnoxious users will do this anyway, but having a system that compares the two gives one more wall for them to climb.)
Re:Get a project manager. (Score:4, Interesting)
Yeah some of the worst mis-management stories I have heard came out of Texas. It is like business people over there aren't in the club unless they are abusing and overworking foreigners.
You got people who don't know how to manage, distributing far too much work to offshore resources who don't know how to develop software, for mission and business critical applications. If that is their idea of what offshoring brings to the table then they were doomed for failure even if they were appropriately staffed.
Software Development Lesson 1: NEVER assign mission critical or project critical tasks to offshore resources. NEVER. You want the ability to handle this and the knowledge for this in-house. Offshore the menial shit that doesn't matter or the bells and whistles, but NEVER offshore your bread and butter.
Re:By not having the situation in the first place (Score:2, Interesting)
I see a lot of feedback from the software developer's perspective. I was an IT Portfolio Manager at a Fortune 100 Insurance company...and here is how we did it:
When dealing with Business sponsors, it is important to have them see the workload and demand (new requests for new work or upgrades/mods). A Demand Management System that satisfies both the IT department and Business can be found in Clarity and Microsoft Project Server 2010/SharePoint 2010. A simple Excel list could also help.
IT need not be order takers (I know, easier said than done) but IT needs to start the conversation with facts in hand.
Gather the IT estimates for each demand item. We used stage gate estimates at the beginning of each project phase up through Test (Request > High Level Estimate (+100%, -50%) > Requirements Gathering > Refine Estimate As Needed > Initiate > Refine Estimate As Needed > Solution Scoping > Refine Estimate As Needed > Design > Refine Estimate As Needed > Develop > Refine Estimate As Needed > Test > Refine Estimate As Needed > Implement > Refine Estimate As Needed).
This gave us a quantifiable range of estimated effort as the project progressed. Any project or request needs an estimate. Multiply the effort estimates by a blended rate (an average of hourly costs including overhead; typically $50-$100/hr depending on the resources required). The product of the multiplication is a dollar range of the IT effort.
Using Excel or another spreadsheet tool, enter the project/request names in column 1 (A), the IT estimates in Column 2 (B, but hide this column before having the following conversation/meeting with business), and Business Value in column 3. It is easier for Business sponsors to think in terms of Business Value rather than Priorities...because if they are working on it the priority must be high! ("Everything I work on is High Priority"...no one wants to work on low priority projects...or at least no one wants to admit a project is low priority). Here is where the fine art of Portfolio Management comes in. Obviously, if left untended the Business sponsors will quibble over the business value of each project or request. Don't let them quibble...if they quibble, shelf that item until others are prioritized. Ask which project has the highest business value. Then continue going through the list. If you spend more than 1-2 minutes on an item then you have to refocus the conversation on business value. "If this is implemented, how much in revenue or profit or goodwill do you think it will create? Just a high level estimate, a ballpark. Is it Five Million? Twenty Billion? Two Thousand dollars?" Capture that number in the spreadsheet or tool. (If you are lucky enough to get Business Cases for requests/projects, then that really really really helps!)
Then sort the list by business value. Un-hide the IT estimates column. Create a simple x-y plot chart of each project/request with the x-axis being IT Cost (or estimate) and the y-axis for the Business Value. Now place bisecting lines over the chart in both directions, creating four quadrants over the plot area.
Now you can drive the conversation as follows:
1) Explain that the Top-Left Quadrant contains projects with High Business Value and Low IT Costs...these projects are "Just Do It" as they make sense (high returns with little investment).
2) Explain that the Top-Right Quadrant contains projects with High Business Value but with High IT Costs...these are Strategic Projects. A business case should be developed and the project should be scheduled with Marketing, Finance, and other considerations in mind.
3) Explain that the Bottom-Left Quadrant contains projects with Low Business Value and Low IT Costs...these are "routine demand" projects and are typically scheduled as a percent of time per week ("I can have the developers work 15% of their week on these and the projects will be finished one at a time")
4) Explain the Bottom-Right Quadrant contains projec
Do the Math (Score:4, Interesting)
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
Just charge differently (Score:2, Interesting)
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.