Answering PPM's Most Fundamental Questions
Since most IT professionals seem to struggle with the same PPM concepts, I thought it would be helpful to share my most frequently asked questions with you. So, with this article, I hope to remove some of the confusion around the three most basic PPM evaluation models: alignment, risk, and value.
Question #1 - Alignment: I assume an alignment assessment model is a framework used to asses how well the proposed project aligns with the stated business aims. What form would such an assessment model typically take?
Jeffs Answer: Your assumption that an alignment assessment ensures a proposed project supports stated business goals is exactly correct.
This perspective of evaluating projects is essential in helping to identify and avoid what I call forced or pet-projects. For example, if the focus of a business strategy centers around increased market penetration and a current business goal is 15% growth of sales, then a project that enables online, real-time quoting should score higher (and get more credence) than a CRM project that is focused on customer service.
Yet, you can see where executive in charge of customer service will probably push heavily for the CRM project.
The simplest alignment model I've ever used with a client was an EXCEL spreadsheet that listed the business goals across the top (I called them strategic business themes) and listed five levels of support down the side as follows:
Evaluate the project idea against all stated themes and compute an overall score for the project. The score then allows you to compare multiple ideas in an apples-to-apples fashion.
Question #2 - Risk: I know that a projects risk needs to be estimated so a relative level of confidence can be communicated regarding the organizations ability to actually deliver the proposed project. What form would such an evaluation template take? How should it be customized?
Jeffs Answer: As with all evaluation models it is important to convert all analysis into a quantifiable score. This is important for project-to-project comparisons and graphical charting options.
A risk model, like alignment, can be kept very simple, but the resulting scores must illustrate the expected constraints inherit to the project (or, in other words, all the garbage that will make this project fail). This score is provided to decision-makers so they can test their risk tolerance.
I usually start by listing 20 common risk factors in the three categories of technology, business, and external constraints that can cause project failure.
Each question is evaluated on a 1-to-10 scale of "Probability of Occurring" and on a 1-to-10 scale of "Impact" if it were to occur.
I then multiply the two scores for each question to get a "risk score" for that question.
For example, a risk question is scored a five for its probability of occurring and a five for its impact to the project. This question would then have a risk score of 25 (five times five).
Once all questions are evaluated you then add up all 20 risk scores to get the project's overall risk score. A project's overall risk score will be between 0 and 2000.
I then ask my client to develop the point score ranges that would determine: Low Risk, Moderate Risk, and High Risk. For example, Low=0 to 600, Moderate=601 to 1200, and High=1201 to 2000.
Once this approach is consistently implemented and used for a period of time, a history is built up that executives can easily comprehend and used to make a go, no-go decisions with more confidence.
They begin to see, because of project history, that a risk score of 900 means they should expect a few bumps in the road but IT will eventually delivery the solution. While a score of 1600 means avoid this money pit.
Question #3 - Value: I understand the principle of performing a high-level cost/benefit analysis to try and represent business value vs. project costs. Does this cost/benefit model have to be customized by industry or can a common template be used for all companies?
Jeffs Answer: At minimum, a company should use "standard" cost/benefit models, such as Net Present Value (NPV) and straight Return On Investment (ROI) models.
Most finance departments have their own specific twist to these models, such as a three-year NPV or a five-year NPV.
For example, one of my clients applied a "discount factor" to stated benefits based on the method of measuring the benefits. If the benefit was supposed to eliminate five jobs then this benefit could be easily measured and the "discount factor" was set to 0%.
So a one million dollar benefit would remain as one million dollars, but if the benefit was softer, (such as reduce the time it takes to process a claim) then the "discount factor" was set to 50% because measuring the savings was expected to be very difficult.
This approach would then adjust a one million dollar benefit to $500,000 for ROI calculations.
The most difficult part of the cost/benefit equation is getting the business to define and quantify then expected business benefits.
Remember to keep the finance department happy with this part of the process. It is they and not IT that are the number experts in the company.
Allow them significant space to influence the design and execution of this evaluation model. If you keep them on the outside of the cost/benefit activities you can expect them to pick apart any ROI numbers and to quickly discredit any process. With them on your side, you get immediate credibility.
I hope this insight has provided value to you as you continue your pursuit of aligning IT with the business. Id like to hear from all of you out there with PPM questions and struggles. You can send your inquiries to me at firstname.lastname@example.org .
Jeff Monteforte is president of Exential, a Cleveland, OH.-based information strategy consulting firm, which specializes in IT governance, information security and business intelligence solutions. He can be reached at email@example.com.