Setting Priorities on Projects (part 2 of 2), by Peter Symons, Managing Partner, OARBIC

(Part 1 of Setting Priorities on Projects)

Last week we looked at how to set priorities on the multitude of projects that you get presented to you every year, based on the Strategic Objectives of your company,

We first determined the relative importance of each Strategic Objective against the other Strategic Objectives and then mapped the list of projects (and sub-projects) against each the Strategic Objectives. This allowed us to see which project best supports the most important Strategic Objective, which project next best supports the most important Strategic Objective and so on.

In the perfect world that has no dependencies and / or constraints, we�d just start at the top of the prioritized list of projects and work our way to the bottom, congratulating ourselves at the end on a job well done.

Unfortunately, not many of us live in that perfect world and we do have dependencies and constraints placed upon us, so we will need to take those into consideration before we finally arrive at the appropriate list of projects prioritized in such a way that they provide most value to the corporation�s Strategic Objectives, yet still have the reality of our world�s constraints and dependencies.

You may remember our �Raw� list of projects was:

Project 1 with 36 points is the most important
Project 6 with 33 points is the next most important
Project 5 with 32 points is the next most important
Project 3 with 27 points is the next most important
Project 2 with 23 points is the next most important
Project 4 with 17 points is the next most important

The first thing to do is to look for and apply Dependencies. A Dependency is the requirement of one project to have another project completed first. A simple example of this would be a data mining project and a create data warehouse project, you would have to execute the create data warehouse project before you develop the data mining project as there�d be nothing to mine otherwise.

To apply Dependencies to our list of projects, one project (Project 3 in our example, the �Dependent� project) is dependent on another project (Project 4 in our example, the �Dependency� project). Even though Project 4 has been ranked less important in its own right (as it is in our example with a Raw score of 17 vs. 27 for Project 3); you will still have to do Project 4 first.

To change the �raw� sequence to be Dependency Considerate, change the final score of the dependency project (Project 4) so that it is 1 point higher than the higher ranked but dependent project (Project 3). This way the Dependency project will be immediately ahead of the Dependent project but will not �bump� or affect the relative importance of any other project.

To continue the example, if Project 3 is dependent on Project 4, and Project 3 has 27 points, allocate 28 points to Project 4. After taking Dependencies into consideration, the sequence in our example will look like this:

Project 1 with 36 points is the most important
Project 6 with 33 points is the next most important
Project 5 with 32 points is the next most important
Project 4 with 28 points is the next most important
Project 3 with 27 points is the next most important
Project 2 with 23 points is the next most important

Once you have the appropriate sequence for each project, you now know in which sequence you will tackle the projects. Now you can apply constraints to the projects.

Typically there are three major Constraints that projects have to deal with. They are:

  • Business Resources

  • IT Resources

  • Budget

There may well be others but at the least there will be those three

Applying constraints, in theory, is relatively straight forward. Simply allocate your resources; financial and human from the top down. In other words, deploy your IT staff, business resources and dollars to the first project first, the second project second and so on. In practice, of course, it gets a little trickier as there are often projects that demand the same smaller subset of resources (your experts) and there are times, particularly with business resources, over which you probably have less control, when people are just not available. However the basic theory is sound and will probably need to go through several iterations to make it fit.

The reason you apply the resources from the top down is to make sure the most important project gets the �first crack� at the resources. The projects near the bottom of the list are probably the ones that will be resource starved.

When you run out of any one resource, generally speaking, unless you receive additional resources of that type, you have reached the maximum number of projects that you can execute this year, regardless of the fact you may have other (different type) resources available.

In the example that follows you can see that Constraints start to �hit� around Project 2 with the constraint being the available Business Resources. Whether the �hit� is fatal for the project or not will vary for each project, but by using this process at the very least, you know the constraint is there.

One critical thing to bear in mind is if the impact of the business resource constraint on project 2 is severe enough that you cannot execute the project, you will have freed up both the IT resources and the budget from that project. Now, of course you will need to re-deploy those resources or get more business resources.

The end result of all this planning is you know exactly which projects should be executed first and you know how many projects from your total portfolio of projects that you can execute. There is no question that �the devil is in the details� in this process, however the advantage of knowing the relative sequence and the resourcing constraints make the effort well worth while.

Peter Symons
Managing Partner, OARBIC.


OARBIC Inc. is a specialized IT consulting firm helping the property and casualty insurance industry make older systems behave like new ones – and new ones behave the way they should.

We offer an array of consulting services, plus our OSEA software solution is specifically designed to extend the life of legacy applications to allow them to keep pace with change.

Our in-depth knowledge of the property and casualty insurance industry and our access to a global network of talented, specialized IT professionals, sets us apart from other consulting companies. More information at