Dear Bob ... I enjoyed your columns about "doing even more with even less" this week. But, how about the backlog? You wrote: The only two outcomes for any request should be no and on the schedule. 1) Given the nature of business and IT requests, I find that the business can think up valid/justified requests faster than IT can work them. 2) With mix of resources, constantly changing priorities, etc., I also like Dear Bob …I enjoyed your columns about “doing even more with even less” this week.But, how about the backlog? You wrote: The only two outcomes for any request should be no and on the schedule. 1) Given the nature of business and IT requests, I find that the business can think up valid/justified requests faster than IT can work them.2) With mix of resources, constantly changing priorities, etc., I also like to not assign resources to project “out in the future”. For example, maybe keeping people loaded up for 6 to 8 weeks (we’re talking small enhancements here). 3) If it’s not assigned to a resource, I also don’t promise a date. All that said, it means that I have a backlog. We haven’t gotten it totally figured out yet, but are looking at some kind of “portfolio management” approach and trying to group small enhancements into small projects (to improve overall throughput of requests). What do you think? – InundatedDear Inundated …Just my opinion: The backlog shouldn’t exist. You’re right that there will generally be more good ideas than there will be people to execute them. The problem is that if there isn’t enough staff to schedule the effort now, there never will be. Depending, of course, on how far into the future you schedule. As a rule of thumb I figure you should schedule requests for small enhancements using a five-quarter rolling forecase. That doesn’t mean saturating the schedule for the next 15 months, but it does mean keeping the calendar that far. Large initiatives should be put on a three-year calendar, recognizing that initiatives don’t have fixed scope, so they require more flexibility.So you evaluate an enhancement request. If you can’t find a place for it on the five-quarter schedule, what’s the point of putting it on a list of good ideas that aren’t quite good enough now? In my experience, these things continue to be not quite good enough for years.Two other thoughts, that might help this and another point your raised: * Since enhancements are almost always departmental in scope or smaller, manage them through a budgeting process in which you allocate a pool of enhancement hours to each department which then takes responsibility for deciding how to use them. IT still have to be responsible for the actual schedule, but this takes the heat off when it comes to the backlog. A related possibility: If a department wants to spend more than its allocated hours, it can, so long as it takes budget responsibility as well. It provides the cash, IT contracts for the additional hours.* Rather than group enhancements into projects (which in my view simply increases the risk – the larger the effort, the greater the risk that it will get into trouble), group them into scheduled releases. The enhancements stay independent that way, but the change control process becomes less chaotic.– Bob ——– Technology Industry