Forgot your password?
typodupeerror
IT

Ask Slashdot: How Do You Deal With Priorities Inflation In IT Projects? 304

Posted by samzenpus
from the raise-the-bar dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Do You Deal With Priorities Inflation In IT Projects?

Comments Filter:
  • by Anonymous Coward on Monday February 20, 2012 @12:17PM (#39100007)

    we just all stress out and have 10000 tonnes of pressure 24/7/365

    • by Anonymous Coward on Monday February 20, 2012 @12:19PM (#39100037)
      We typically fire the entire IT staff every couple of years and try to hire replacements at 70% salary under threat of outsourcing.
      • by telekon (185072)

        We're co-workers? Wow!

        It's a small internet after all.

        • by Anonymous Coward on Monday February 20, 2012 @12:51PM (#39100425)

          Yes, I'm not familiar with the terminology in TFA, but I suspect it's the same situation where we're up against the wall with multiple systems down and a Sales laptop infected with a Croatian automailer and the VP comes and says:
          "Stop. Just stop. I know you think you know where your priorities lie, but you're having difficulty seeing the big picture and you have a bad attitude from your inability to prioritize. So all of you come over here - I can't get this funny cat video to play on my iPad and it's crucial for this Sales presentation."

      • by Anonymous Coward

        ...then the policy is "The beatings will continue until productivity improves!"

      • Re: (Score:3, Funny)

        by dem0n1 (1170795)
        Declare all but government mandated holidays to be crunch time. Encourage all salaried employees to work those holidays and any other time they are not unconscious in microsleep shutdown with false intimation of bonus perqs tied to an impossible to achieve success bar. Include necessarily vague (to keep legal) statements at team and all-hands meetings acknowledging that those that don't live up to the highest work ethic standards of their peers will be not be moved onto teams that are "pushing the envelope
    • by houstonbofh (602064) on Monday February 20, 2012 @12:49PM (#39100413)

      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...

      • by Fubari (196373) on Monday February 20, 2012 @05:04PM (#39103321)
        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.
    • by Bengie (1121981) on Monday February 20, 2012 @01:32PM (#39100879)

      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.

  • by Anonymous Coward on Monday February 20, 2012 @12:19PM (#39100027)

    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.

    • by Colin Smith (2679) on Monday February 20, 2012 @01:07PM (#39100589)

      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.

    • by unrtst (777550) on Monday February 20, 2012 @01:16PM (#39100699)

      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).

      • by husker_man (473297) on Monday February 20, 2012 @01:27PM (#39100825)

        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.

  • by khasim (1285) <brandioch.conner@gmail.com> on Monday February 20, 2012 @12:19PM (#39100039)

    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.

    • by rubycodez (864176) on Monday February 20, 2012 @12:22PM (#39100065)
      and if they don't get it, the company will fail or be acquired. the executives will go on to get high paying jobs elsewhere, their failures spun into tremendous success stories. haha, seen that time and again.
    • Yeah, there's some bad math going on here somewhere. He either has enough requests to justify more resources at least until the backlog is cleared, or he's got users who are sending in too many requests and some should be denied.

    • I've never done project management before, but I have worked on many projects and reported to the person responsible for its resource allocation. In such a scenario outlined by the submission where you don't have a project manager, is there any software in which developers or technicians can help budget time against tasks and create a visual representation? Basically, something simple enough for staff to use and meaningful enough for management to use. The whole point is putting the final choice in manageme

      • In such a scenario outlined by the submission where you don't have a project manager, is there any software in which developers or technicians can help budget time against tasks and create a visual representation?

        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 th

    • by blue_teeth (83171) on Monday February 20, 2012 @12:40PM (#39100315)
      Companies underbid projects with aggressive timelines and less resources.  Theme these days is, get projects at any cost, we will figure it out once the project starts moving.

      Who/what is responsible for this?

      1.  Sales teams who put pressure on project architects for low costing.
      2.  Solution Architects who think each of their project member is Linus Torvalds.
      3.  Existence of bench resources.  Idea is to underbid and deploy bench resources (unbilled) as anyway they are idle.
      4.  Unbilled bench resources suddenly getting deployed in new projects.

      • by maple_shaft (1046302) on Monday February 20, 2012 @01:47PM (#39101019)

        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.

    • +1 to this. I hate project management, but it has a very clear purpose and a well thought out project plan with a strong project manager can simplify your life.
    • The important thing is not to get a project manager, but to give the project manager the power to actually do things like manage priorities. I worked at a software start-up in 1999. At the first company meeting after I got there, I tried to get an idea of what were the highest priorities among the tasks facing the company at that point, not necessarily in order, but just putting a priority from "1" to "3" (I had originally suggested 1 to 5) on each item. Out of 20-odd items, one got a "2" and the rest we

  • Staff (Score:4, Informative)

    by MBGMorden (803437) on Monday February 20, 2012 @12:20PM (#39100047)

    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.

    • Or, if there is no budget for that, refuse more projects. Give a real timeline of when the "High Priority" projects will be done, and drop everything else, and tell management that there are no new projects until May 2013. When they crap, you can start the discussion of "Wants vs Needs" and if they really need everything on the list.
    • by nahdude812 (88157) *

      Although additional staffing will probably help with the backlog, it might not be the right solution. For one thing, depending on the complexity of the systems involved, new hires may for a while reduce the efficiency of the existing staff. Sometimes new hires cause dates to slip which would have been met without the hire.

      Also, just because your business units are requesting work be done doesn't mean that work is necessarily worth the investment. The individual business unit can't provide a good ROI eval

  • by LostCluster (625375) * on Monday February 20, 2012 @12:20PM (#39100053)

    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.

    • by Orne (144925)

      If there was only some system where all of the users could post comments on the changes they wanted, and then the users themselves could rate the requests up or down, and the highest modded comments could get the most visibility.

      Nah, a system like that could never work...

    • by RyoShin (610051) <tukaroNO@SPAMgmail.com> on Monday February 20, 2012 @01:30PM (#39100863) Homepage Journal

      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.)

    • by King_TJ (85913)

      Exactly!

      But where I've seen this fall apart is when management lacks the backbone to manage properly.

      EG. My wife works in I.T. for an area hospital, and their department is insanely stressed out and disorganized. They have a system in place, at least on paper, for assigning priority level to trouble tickets. (It's based on pretty clear criteria, such as only getting the highest level if it's a piece of computer equipment required by doctors in the process of doing medical procedures.) The problem is, any o

  • by Samantha Wright (1324923) on Monday February 20, 2012 @12:21PM (#39100057) Homepage Journal

    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.

  • 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.
    • by AlXtreme (223728)

      This is probably the best way, avoid/ignore any priorities that don't come in from up top.

      Even better is not using priorities at all: simply set milestones and allocate people to meet those milestones. If during the weekly meeting one of the dept heads wants something done quick let them fight it out with the dept heads whose pet project is currently underway and will be delayed due to "reduced resources". The impact of "pet project will be delayed by 4 weeks" is much more concrete than "pet project is now

  • by Chemisor (97276) on Monday February 20, 2012 @12:23PM (#39100089)

    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".

    • by berashith (222128)

      this will at least guarantee that less than 10% of projects will be marked as high priority. mission accomplished!

    • I've adopted the Scoville [wikipedia.org] scale to help prioritization. "Yes. I know your project is 'hot', but is it Peperoncini hot? Or Scotch-Bonnet hot?"
  • Hold it!!! (Score:4, Insightful)

    by Anon-Admin (443764) on Monday February 20, 2012 @12:24PM (#39100105) Homepage Journal

    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.

    • Re:Hold it!!! (Score:5, Interesting)

      by berashith (222128) on Monday February 20, 2012 @12:47PM (#39100377)

      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.

  • by Anonymous Coward on Monday February 20, 2012 @12:24PM (#39100107)

    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.

  • by omgwtfroflbbqwasd (916042) on Monday February 20, 2012 @12:24PM (#39100109)

    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.

    • by SQLGuru (980662)

      I agree. Make the priority based on a metric instead of customer driven. Return on investment is one that most business people understand ($$$ returned for $ spent). Exceptions being legal obligations such as law changes (it's not like businesses WANTED to implement SOX compliance or tax law changes or....etc.).

      Sure, you'll get people that game the system in terms of how they evaluate the return and the cost, but it should be a lot harder than the old "mine is top priority because it's mine" that goes on

  • by ACK!! (10229) on Monday February 20, 2012 @12:25PM (#39100127) Journal
    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.
  • by robthebloke (1308483) on Monday February 20, 2012 @12:27PM (#39100149)
    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.
  • Ranking tasks (Score:3, Insightful)

    by Anonymous Coward on Monday February 20, 2012 @12:29PM (#39100171)
    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.
  • Scheduling algorithm (Score:3, Interesting)

    by Anonymous Coward on Monday February 20, 2012 @12:30PM (#39100179)

    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.

  • 10% (Score:5, Insightful)

    by BasilBrush (643681) on Monday February 20, 2012 @12:31PM (#39100183)

    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.

    • by praxis (19962)

      Just look out for those that will automate generation of junk low-priority issues to get that percent of high-priority issues down to 10% so they can file their high-priority issue.

      • by praxis (19962)

        I overlooked in my preview that Slashdot ate the less-than sign before the '10%'. I meant of course 'down to < 10%'.

  • by Anonymous Coward

    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

  • 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.
  • 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.

    • by Dastardly (4204)

      That is because percent complete is a lie to make burn down charts look good. In addition, the pain of telling the truth that at 20% complete you have discovered that whatever you are working on will take twice as long is greater over a greater period of time than pretending you can complete on time until you are "95%" done, at which point, you then deal with the pain of saying you need the extra time. That way you have avoided several weeks of annoyance and negative attention from management.

      This is direc

  • by Vo1t (1079521) on Monday February 20, 2012 @12:37PM (#39100255)
    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.
  • by johnlcallaway (165670) on Monday February 20, 2012 @12:38PM (#39100277)
    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.

    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 ... you.
  • by svendsen (1029716) on Monday February 20, 2012 @12:38PM (#39100279)
    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.
  • Learn to say no (Score:4, Insightful)

    by cccc828 (740705) on Monday February 20, 2012 @12:38PM (#39100281)
    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 [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.
  • by Kenja (541830) on Monday February 20, 2012 @12:38PM (#39100283)
    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.
  • 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

  • by Hatta (162192) on Monday February 20, 2012 @12:40PM (#39100309) Journal

    "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.

  • by ath1901 (1570281) on Monday February 20, 2012 @12:41PM (#39100321)

    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.

  • by dkleinsc (563838) on Monday February 20, 2012 @12:42PM (#39100333) Homepage

    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.

  • 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.
  • by jimmerz28 (1928616) on Monday February 20, 2012 @12:46PM (#39100365)

    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.

  • by aero2600-5 (797736) on Monday February 20, 2012 @12:46PM (#39100369)

    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.

  • by morningstar8 (234758) * on Monday February 20, 2012 @12:50PM (#39100421)
    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.
  • 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.

  • 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.

  • by CanHasDIY (1672858) on Monday February 20, 2012 @12:59PM (#39100505) Homepage Journal
    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.
  • by leonbev (111395) on Monday February 20, 2012 @01:08PM (#39100605) Journal

    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.

  • by DarkOx (621550) on Monday February 20, 2012 @01:39PM (#39100933) Journal

    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.

  • by Bob9113 (14996) on Monday February 20, 2012 @01:42PM (#39100975) Homepage

    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).

  • Do the Math (Score:4, Interesting)

    by geohump (782273) <geohump@gmail . c om> on Monday February 20, 2012 @03:01PM (#39101759) Journal
    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
  • by SmallFurryCreature (593017) on Monday February 20, 2012 @03:02PM (#39101761) Journal

    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.

  • by __Paul__ (1570) on Monday February 20, 2012 @05:28PM (#39103623) Homepage

    ...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.

  • by lanner (107308) on Monday February 20, 2012 @05:29PM (#39103645)

    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.

  • by jon3k (691256) on Monday February 20, 2012 @06:08PM (#39104091)
    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.
  • by tchdab1 (164848) on Tuesday February 21, 2012 @02:02AM (#39107301) Homepage

    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.

"Pok pok pok, P'kok!" -- Superchicken

Working...