by Mark Patterson - Prioritizing IT projects is really more of a financial decision than an IT decision. IT's job is to support the company by increasing revenue and reducing costs and all IT projects should do one or both of these. Therefore, IT projects should be prioritized by determining their true ROI and then ranking them against the budget (and whatever more $ you can extract).
Even internal IT projects, such as replacing a network backbone switch, has ROI. If the switch is underpowered or is reaching end-of-support with its vendor, the ROI is in terms of disaster avoidance or reduced productivity. What happens if the switch fails? Calamity. How much calamity?
If you get push-back on replacing it, calculate it out: If it is a primary switch between users and the ERP system, the users will either lose connection to ERP or could have degraded access. If they are unable to process, for example, 1000 orders per day because the switch failed, and it would take 2 days to repair, the risk is the lost revenue of those 2000 orders. What is the true risk of switch failure? Maybe 5% that it would fail in the next 5 years? Therefore, you could cost the risk at 5% of 2000 orders, or 100 orders. If each order is worth $1000, the risk is $100,000. In this example, buying a new switch avoids a calculated $100,000 in costs. A $30,000 backbone switch is a good investment in this scenario - especially if the actual risk is considered, which could be $2 Million in lost revenue if the switch fails at the wrong time.
In addition, Finance will look at projects over time, where an investment of X returns Y over a period of months or years. Three things to consider are:
- How does the project compare against just investing the money in a T-Bill or other investment?
- How long before the hard-dollar investment is paid back?
- What is the interest rate of the investment over the period?
In the example above, where a $30,000 investment returns $100,000 in avoided risk over a five year period, if Finance buys the $100,000 estimate, they will tell you that this project has a rate of return of 60%, a payback time of 1.5 years, and that the investment is worth $46,000 more than if they had just dropped the $30,000 into a 10% bond. Pretty good.
You can (and should) run the numbers yourself, but Finance will run the numbers anyway, so it makes sense to work with them for any project that needs budget approval.
Once you have established a realistic ROI by working with other departments and Finance, then prioritizing the project is just a matter of ranking them against the budget. (By the way, a good CFO will give you money over your budget, if available, for a very compelling ROI. After all, he is buying money.)
Of course, when prioritizing projects, you will also need to look at timing and resource availability. This is taken into account in ROI calculations, but when you have three or four compelling projects, you need to look at sequencing and concurrency of projects.
I put in place an "IT Steering Committee" at my company consisting of key leaders from each department to ensure that each project was sanity checked and coordinated. Departments have their own activities and projects, and IT projects need to fit into this mix, and they need buy-in and support from the business. Conflicts of scheduling are addressed and corrected, and projects are submitted and rationalized. This has been successful for us.