Prioritization can be defined as ‘a system to determine the right to have or do something before others’ or ‘a state of the level of importance or urgency in rank’. Prioritization of Projects is a time-tested methodology that is based on several approaches, the most common of which use: (a) heuristics (e.g. customer perception) of a single individual or a few senior individuals within an organization, (b) single dominant qualitative (e.g. customer satisfaction) or quantitative (e.g. ROI) criterion, and (c) weighted aggregate of multiple quantitative and/or qualitative criteria.
At first blush, Project prioritization seems a terribly trivial exercise – rank order Projects and ‘draw the line’ when you run out of budget and/or human resources. But, what should the rank ordering of Projects be based on? A single quantitative criterion? If not, why not? Further, shouldn’t the criterion or criteria in use be decision-relevant? By definition, all Projects that appear on a priority list have some sort of priority but do some of them even deserve to be on such a list?
I have not yet met an organization that boasts a dissatisfactory Project prioritization process and methodology. Yet, the many concerns raised by organizations relating to poor resource allocation is directly related to one or more of the following issues: (a) insufficient clarity regarding why some Projects are ranked higher than others, (b) what constitutes a ‘Must Do’ Project, (c) legacy Projects that continue to consume constrained resources, and (d) how to deal with Projects that end up ‘below the line’ especially when Projects ‘above the line’ are dependent on one or more of these ‘below the line’ Projects. Given that most Governance bodies do not make Project prioritization decisions on the basis of a single criterion, a multiple objective methodology that employs utility theory is highly recommended. An example of a model derived from such a methodology for the IT industry is depicted (Figure 1). As Projects mature and/or information changes, the model is easily updated to reflect the rank order of Projects within a Portfolio. However, it is important to stress that organizations have a remarkable tendency to re-prioritize Projects at general gate reviews; this should be avoided as Projects that are ‘in flight’ do not deserve to be re-prioritized until their next decision point or specific gate review. An organization that utilizes Project prioritization methodologies with the appropriate discipline does so in a manner that acknowledges Projects that are already ongoing while prioritizing new Projects that are about to enter the Portfolio, perhaps as others are about to exit.
I do not believe that mandated Projects warrant being on a Project prioritization list; they should simply be allocated the resources they require to be done where the only discretionary decision necessary relates to when they get done as opposed to whether they get done. To be sure, I have met with initial resistance from some organizations when advocating this approach but they eventually come to terms with the fact that the approach simply clarifies which Project decisions are discretionary and which ones are not. Lastly, and for the record, the terms Project prioritization and Portfolio prioritization tend to be used interchangeably; in reality, Portfolios are seldom prioritized whereas Projects undergo some form of prioritization at least once in their life cycle.
Figure 1 – Example of a multiple objective prioritization model for the IT industry