Posts Tagged ‘Project Management’

Multi-criteria Project Selection Model

Thursday, June 11, 2009 posted by Taz Lake
I promised I would write about multi-criteria project (or product) selection in my last post.  We will be discussing this in my IT Project Management class tonight so now would be a good time for a quick overview.  

You probably use multi-criteria project selection every day, but you probably don’t call it that on the consumer side of your life.  Whenever you make a purchasing or investment decision you are using some variant of the tool.  Whether you are purchasing a new TV or deciding which route to take to work, you are thinking about many variables which inform your decision.  You break the decision into categories and then might have specific criteria under those categories.  Then you compare and score and make a decision.  By the way, making a decision not to purchase or proceed is also a decision.  All of these actions tend to be intuitive for many and everyone approaches it differently and may emphasize certain criteria more than others.

This happens in business too, but the hope is that the selection process is rigorous and justifiable.  One mechanism to help with this is a multi-criteria model.  The multi-criteria model I use below is adapted from Information Systems Project Management: A Process and Team Approach by Mark Fuller, Joe Valacich, and Joey George.  This multi-criteria analysis can be used to weigh project alternatives and provide a mathematical model for selection of projects or products.  The number of requirements and constraints is not important, but it is important to keep the decision factors narrowed to those the organization views as most important. 

Rules:

  • The total weight for requirements and constraints should equal 100. 
  • You may bias the model toward one or another of the items, but for in general start by balancing the requirements and constraints with an equal weight at 50 points total. 
  • The authors of the textbook use a 1,2,3,4,5 scoring model.  I prefer a 1,3,9 scoring model because it forces tough decisions and creates separation in the model. 
  •  The individual weights assigned to individual requirements and constraints are a matter of negotiation among the project selection team.  In this model, larger numbers indicate the project is better along that line item.
  • The scoring and summary columns are calculated fields and should not be modified.

Example:

The organization has determined that X system is needed.  We have been asked to evaluate three platforms using the organization’s multi-criteria analysis.  Step 1, requirements and constraints have been set based on negotiation and review of the organization’s needs.  Step 2, weights for the criteria are applied based on negotiated values.  Step 3, alternatives are selected from a “consideration set” and ratings are applied, giving us a final total.  The larger number wins.

Step 1: Multi-Criteria Analysis
Step 1: Multi-Criteria Analysis
Step 2: Multi-Criteria Analysis
Step 2: Multi-Criteria Analysis
Step 3: Multi-Criteria Analysis

Step 3: Multi-Criteria Analysis

Note: This example is not prescriptive… criteria, weights and ratings are unique to each selection process, as well as each organization.

Using VRIO analysis for IT Project Selection

Thursday, May 14, 2009 posted by Taz Lake

The fact that information technology departments are swamped by requests for services on a daily basis is well known.   Many of these requests are for projects.  These requests are often not put through a filter to determine the relative value of one project over the next.   The larger your projects, the more time and effort should be put into the selection of the projects.  Oftentimes the tool sets for selection are lacking.  Some organizations use SWOT analysis to select projects or an SCP model.  There may also be a generic multi-criteria model utilized.  I will talk about product selection using such a model in a later post.  One analysis that is oftentimes overlooked is VRIO (aka “VIRO” for easier pronunciation).  All of the previous serve as good starting points for filtering projects.  However, VRIO can assist further.  VRIO stands for the following:

Valuable – Is the project valuable to the organization?  Can the value be quantified in any way?  For example, you might identify projects tied to the balanced scorecard metrics, or they may be tied to a particular department or sales region success metric.  If the project helps move that metric in a positive manner it is valuable.  This may also be tied to process improvement and/or automation.  Of course, to determine this value, the organization has to know which metrics are important and has to be able to measure them with some level of accuracy.  If your company has the ability to do this, then definitely focus on aligning your IT projects with improving those metrics!

Rare – Rarity has to do with whether or not the competition has a similar resource.  Rarity might be tied (probably briefly) to a unique software or technology stack, particular experts within the organization, contractual arrangements with suppliers, etc.  In the context of project selection, is it something everyone else is doing or has done, or will this lead to an outcome that provides a unique capability.

Imitable (or “Inimitable” depending on context) – This deals with resources that are difficult or impossible to imitate or substitute.  A concept known as “path dependence” sometimes plays a role here because even a direct duplicate of processes and resources may not produce similar effects across companies.  This is the most difficult in IT project selection because almost any IT technology stack can be reproduced by a competitor.  Installing the latest OS or the most popular DMS does not make you competitive.  It may be a baseline for competition, but it is easily imitable.  Full systems, people, processes, software, hardware and data, are harder to copy completely.  For this case, it might be helpful to attach a time component.  For example, can it be imitable within a year or two?  If not, then by all practical assessments, it is inimitable because of the technology product lifecycles and the unique processes and people put in place during the development of the system.

Organization Ready – Is the organization ready to capitalize on the project?  Projects can be suggested for a variety of reasons, but the organization has to be ready to grasp the opportunity if it meets the three previous requirements.

So, for the purpose of IT project selection, consider filtering projects first by whether they are valuable and rare, then by whether they are inimitable within the context of the time horizon selected.  If the answer to these three is yes, it is obvious the organization should be ready to sign off on such a project.