Setting Priorities:

Just Too Much To Do

September 2000

Is your team unable to keep up with customer demands?

by Karl Wiegers
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 bug 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.
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 had to do. So I learned 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 didnt manage to finish. Any resourceconstrained software group also must devise a thoughtful way to prioritize the seemingly
infinite backlog of requests.
I helped the Internet development group at a major corporation that Ill 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
couldnt keep up with the customer demands. Naturally, each business unit was convinced that
its needs were the most pressing and should have top priority.
This group realized that it needed a structured, rational and analytical way to evaluate the
requests that competed for scarce development time. The spreadsheet tool we devised
(available from www.processimpact.com/goodies.shtml) is easily customized to help any team
choose those new development and maintenance activities that most strongly align with the
corporations 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 accompany prioritization. Such a tool
makes it more likely that deliberate and reasoned decisions are made, that the decision
making is more consistent over time, and that decisions are documented.
Constructing the Model
Our prioritization approach posits that a software group should preferentially tackle those
projects that most strongly align with its business and technical success drivers. Therefore,
the first step in building your own model is to identify your project prioritization drivers.
Begin by listing the factors that feed into your groups thought process when you decide
whether a specific project proposal makes good sense. You should identify only 10 to 15
project prioritization drivers; more will become unwieldy. Consider including key customer
representatives in this process. Their involvement as partners in understanding and
determining how resource decisions will be made is often a procedural and political plus.

Table 1 lists the factors the Contoso Internet development team considered incorporating into
their model. Some of these might not apply to your situation, and you may well have other
powerful factors that influence your decisions. Its important to balance business and technical
drivers. Always chasing the next sale (a business-driven perspective) is as dysfunctional as
always chasing the next shiny object (an engineering-driven perspective).
Table 1. Possible Process Prioritzation Drivers

Ratings Cues
Driver

What is the opportunity for generating

revenue?

minimal
(<$10K /year)

some ($10K50K /year)

strong ($50K100K /year)

exceptional
(>$100K /year)

What is the opportunity for cost savings?

minimal
(<$10K /year)

some ($10K50K /year)

strong ($50K100K /year)

exceptional
(>$100K /year)

When is the site needed?

>8 months

5-7 months

2-4 months

<1 month

How long will the site be active?

<3 months

3-6 months

6-12 months

>12 months

Can this project be completed with current

technical capabilities?

no

to some extent

mostly

completely

Will this project help us develop

significant new capabilities or reusable
components?

few or no new
capabilities or
components

some new
capabilities or
components

several new
capabilities or
components

many new
capabilities or
components

severe risk

strong risk

some risk

minimal risk

How will this project impact other Web

sites or projects?

severe
impact

strong impact

some impact

minimal impact

How complex is the user interface?

extremely
complex

quite
complex

somewhat
complex

not complex

ongoing
maintenance

frequent updates

occasional
maintenance

limited
maintenance

<10% of assets

10-40% of
assets

40-70% of assets

>70% of assets

minimal
alignment

some alignment

strong alignment

complete
alignment

no

some

many

yes

questionable

partial

most available

available

minimal

some

significant

substantial

not very
important

somewhat
important

quite
important

critically
important

How risky is the technology?

How much maintenance and support will

the site require?
Are appropriate assets
currently available?

and

content

Does the intended audience align with

current user demographics on the site?
Are necessary staff available?
Is necessary funding available?
What is the strategic value?
How important is the business or strategic
relationship with the client?

Some of these drivers probably play a greater part in your decision-making than others, so
step two in creating your prioritization model is to select weighting factors for your
prioritization drivers. Allocate 100 points among your project prioritization drivers such that
those that are most important to you receive the greatest weight. This is not a high-precision
exercise, so use multiples of five for the weights. Assigning fewer than five points to a driver
suggests that it plays an insignificant role in your thought process.
Next, to determine how each candidate project stacks up with respect to each prioritization
driver, you need to define a rating scale for each driver. After some experimentation, we
selected a four-level scale, with point values of 1, 3, 5 and 7. A scale with an even number of

choices forces the raters to make a decision, rather than assigning "medium" ratings to many
of the drivers. After all, the objective of the prioritization is to spread the candidate projects
across a spectrum so that you can identify the high-impact activities. That is the same
rationale behind using a scale from 1 to 7, rather than using the narrower range of 1 to 4.
Note that several of the priority drivers in Table 1 actually contribute in a negative way to a
projects desirability. Examples include the risk from current technologies, impact on other
Web sites, user interface complexity, and the amount of maintenance and support required.
We defined each factors rating scale so that higher scores correspond to a more favorable
indicator for undertaking a project. Using this scheme, even the negative drivers contribute
points to the total score. As an alternative approach, you could assign negative weights to
those drivers instead of reversing the rating scale. This would amplify the impact the negative
drivers have on the scores.
You also need to provide some cues to help model users interpret the scale consistently. Table
1 presents cues that define what is meant by a rating of 1, 3, 5 or 7 for each prioritization
driver. Modify these as appropriate for your situation. Quantifying the cues when possible will
reduce the subjective bias that goes into assigning ratings and help to achieve consistent use
of the scale over time and between people.
To apply the model, you rate each candidate project with respect to each prioritization driver.
Formulas in the spreadsheet will multiply each driver rating by the corresponding weighting
factor. The sum of these weighted scores for all drivers yields a priority score for each project.
The 1-to-7 rating scale yields a maximum possible priority score of 700 points. All other things
being equal, those projects that have the highest scores should most closely align with your
organizations value drivers or strategic objectives, hence they should be your top priority.
Table 2 illustrates a sample application of the prioritization model, showing the drivers the
Contoso Internet development team chose, how they allocated their 100 weighting points, and
how they rated four candidate projects. This weight allocation indicates that the opportunity
the project poses for generating revenue most strongly influences the decision to undertake a
proposed project, accounting for one-fifth of what makes a project attractive. The model
suggests that Project C should have the top priority, while Project D can wait for a future time.

Table2:AnExampleofApplyingtheProjectPrioritizationModel
Driver

Weight

Project A

Project B

Project C

Project D

20

How immediate is the need?

15

How much maintenance and support will the

Web site require?

15

What is the strategic value?

15

How long will the site be active?

10

Will this project give us new capabilities or

reusable components?

10

How risky are the necessary technologies?

How will this project impact other projects?

How complex is the user interface?

100

460

360

520

320

What is
revenue?

Totals

the

opportunity

for

generating

However, even the most compelling theoretical model is worthless unless you have confidence
that it provides some meaningful predictive capability. Therefore, the final step is to calibrate
your prioritization model.
The Contoso team calibrated its model by analyzing several recently completed projects. We
compared the model-derived scores with our subjective, after-the-fact evaluation of how smart
it really was to have undertaken each of those calibration projects. Initially, we saw some
disconnects. If the model yields approximately the same score for two projects, but you
believe that one was a great idea and that you should have avoided the other, adjust the
model. The weighting factors might not be right, the scale definitions might need tweaking,
you might have included unnecessary drivers that skew the results, or you could be missing
some important prioritization drivers.
We modified our initial weighting factors until the model scores roughly agreed with our
subjective evaluation of how favorable it really was to have undertaken each past project. In
one case, two projects had nearly identical scores that were both favorable but for different
reasons. The fact that the model yielded high scores for them both gave us confidence that
our model had a useful predictive capability.
Make sure you understand your models shortcomings, as some customers will attempt to
exploit any loopholes. For example, in the Contoso Pharmaceuticals model, tight deadlines
contributed to higher priority. We needed to insure that this characteristic was used
appropriately and not abused. We didnt want users to wait until a state of crisis erupted to
bring a project to our attention, in an attempt to gain top priority. However, we did need to
give preference to those projects that truly were an immediate need.
Using the Model
Nowat lastyoure ready to apply your prioritization model. A small group of informed
decision-makers should participate in the rating process to minimize individual biases and to
compensate for each individuals limitations of knowledge about the candidate projects. One
approach is to have the participants create the ratings by consensus in a meeting, discussing
points of disagreement to reach an equitable resolution. Alternatively, the participants could
prepare their ratings individually and then meet to review the numbers and reconcile any
conflicts. The decision-makers need not all be from the development group. Getting your
customer representatives to understand the unpleasant reality of resource limitations and the
need for prioritization might help them change from adversaries to partners.
At Contoso, we examined several dozen projects in our backlog queue, as well as those we
currently had underway. We rated each of them against all of our project prioritization drivers,
using the rating scales we had defined. Sorting the candidate project list in descending order
by the computed score yielded a first-cut prioritization sequence for these projects. Ironically,
the analysis suggested that several of our current projects didnt make the grade; we probably
should have been working on other, more pressing ventures instead.
The numbers that come out of your prioritization model shouldnt be the only consideration
when you choose the next project to launch. Political factors also have a way of slipping into
the discussion, although a model-based rational analysis might help you combat the more
irrational games.
Youll need to reevaluate your project queue periodically as new proposals come along, when
corporate directions change or when significant factors change for projects in your current
backlog. For example, perhaps Project A was originally rated low because it could not be
completed with current technical capabilities. If some other project work leads to those
capabilities now being available, Project As priority could go up.

A reliable prioritization model can help you justify why some projects simply should never be
done. Nothing helps a project queue more than eliminating the candidates that just dont cut
it, so you dont have to keep reevaluating them. Keep your project priority list current as life
goes on around you, and youll be able to devote your limited resources to those activities that
will best enable your software group to help the company achieve its business objectives.