Fewer concurrent projects mean developers can focus. It works better. That doesn't make this idea a welcome message in every executive suite. Dear Bob …We’ve had a problem for years, where the company’s executive council routinely approves too many IT projects. The result is that our ten developers are expected to work on 20 concurrent projects, and take care of the maintenance and enhancements queue.The results have never been good. Now I’ve been told I have to lay off two developers as part of an overall company downsizing. I asked which projects they plan to put on hold. The answer was, none of them — my job is to figure it out. Other than jumping off a bridge, do you see any path out of this?– At wits endDear Witty … Probably not. You appear to be working in an executive culture of “the world works however we say it works.” So the advice that follows doesn’t have a high probability of success. It’s the best I have to offer, though.The first rule of persuasion is to sell the problem. Which means you have to make this their problem in a convincing way. I’d suggest these steps:1. Clarify an assumption: Specifically, ask the members of the executive council what their expectations are for a developer work week — 45 hours? 50 hours? 60 hours? If they ask why, let them know you’re putting a realistic schedule together for getting everything done. Your own assumption is 50 hours because more than that leads to too many bugs and developer burn-out. You need to know, though, if they’re expecting more than that. Accept whatever number they give you.2. Create a plan: Hold out 32 hours a week (4 per developer) for the maintenance and enhancements queue, and allocate the 368 that remain (or whatever) developer hours per week across the 20 projects. Ask your project managers (or whoever handles project planning) to put a schedule together based on this level of developer availability.3. Create an alternative plan: In this plan you execute four concurrent, fully staffed projects at a time. This will make it clear that with a more reasonable load, the business will get more benefit, and faster, by letting developers concentrate on one job at a time. 4. Present the plans: Meet with the executive council and show them the plan. Almost certainly, they’ll try to make it personal. One or another of the executives will give you an unreachable goal and say something like, “If you can’t get the job done, we’ll find someone who can.”Keep it impersonal. Tell them they’re arguing with math, not you. Let them know there’s no padding or contingencies in the plans — just arithmetic.If you can, draw an analogy to budgeting: When they budget, if they spend a dollar on one item that dollar is no longer available to spend on another item. The same is true of developer hours. 5. Make it their decision: You’ll run the projects whichever way they want. If they think 70 hour work weeks are sustainable, you’ll inform the developers that this is the company’s expectation … and when you do, those who can find other employment will do so. If they prefer 20 concurrent projects, that’s what you’ll do.Your job is to present the alternatives and their consequences. It’s up to the executive council to make the best choice for the company.It’s thin … usually, people like the ones you described can’t stop pretending the world works the way they wished it worked … but it might be worth a shot. Good luck.– Bob Technology Industry