Chapter 3. Just Too Much to Do[3]
Note
When I began my graduate studies in chemistry many years ago I quickly realized that it was impossible to do all the work that I absolutely must do. I had to learn to prioritize the competing demands for my time, to make sure I worked on the most important tasks first. This strategy minimized the downside from those activities I just didn’t manage to finish. Any resource-constrained software organization also must devise a thoughtful way to prioritize its towering backlog of work requests.
If your software group is like most, the demands for your services far outstrip your available resources. Teams building highly innovative products are pressured to include ever-more nifty features. MIS groups that support mature systems face an avalanche of problem reports and enhancement requests. Corporate Internet development teams are deluged with requests for new Web sites and pressured to include leading-edge capabilities, along with routine maintenance demands.
Perhaps the most important thing you can do when initiating a new project is to make certain that you are working on the correct project. Therefore, I’ve included this chapter on project prioritization in this book on project initiation. Using a tool such as the one described here to help you sift through the portfolio of potential projects helps ensure that each project you initiate is worth finishing.[3]
I helped the Internet development group at a major corporation that I’ll call Contoso Pharmaceuticals develop a tool to help them manage their huge work backlog. At one point, the project queue contained some 150 requests for new "sitelets" from the corporate business units this group supported. Although the development team was growing rapidly, it still couldn’t keep up with the customer demands. Naturally, each business unit was convinced that its own needs were the most pressing and should have top priority. However, simply because a business unit had funding and waved a wad of cash at the development team didn’t mean that theirs was the most vital project from a corporate perspective. Another factor influencing decisions was that some attractive projects posed greater technical risks than did others, which had to be balanced against the potential benefits of each project.
This group realized they needed a structured, rational, and analytical way to evaluate the requests that competed for scarce development time. The spreadsheet tool we devised is easily customized to help any team choose those new development and maintenance activities that most strongly align with the company’s vision, objectives, and strategies. Outputs from this model should become just one part of your decision-making process, as there may be compelling reasons to undertake certain projects that the model does not address.
Adding an analytical tool to your priority-setting process can help you break through the political and emotional confrontations that sometimes characterize making priority choices. Such a tool makes it more likely that the right people make deliberate and reasoned decisions, that the decision making is more consistent over time, and that decisions are documented. It’s easier to argue your case and defend your decisions with the help of an analytical approach.
[3] This chapter was originally published in Software Development, 2000, 8(9): 65–68. It is reprinted here, with modifications, with permission of CMP Media Inc.