You are currently browsing the category archive for the 'CTO' category.
ROI communication & calculation can make a difference in a project getting funded or not
In today’s economic climate justifying the cost and benefits of an IT initiative has become more important than ever. Often the fate of an IT project depends on the justification of benefits and recuperation of the costs. Therefore calculating, presenting, and demonstrating the benefits of a project in an appropriate manner can make the difference between getting a green light and getting stuck in an endless review cycle.
Value-statements can help bridge the communication gap
During my interactions with various IT departments I have noticed that the IT staff values a project differently than the business sponsors or executive team. Calculating and communicating the value of an IT project puts the IT staff in an uncomfortable and unfamiliar role which requires financial, sales, and technical skills. Quite often even when the IT staff tries to focus on business benefits they fail to align the benefits of a project to the business concerns in a manner that resonates with the executive team. The use of appropriate terms and prioritization of business concerns is key to grabbing the attention of the business sponsors and the executive team. A value statement [i]can be a useful tool to summarize and contextualize benefits of a project in almost all circumstances. Sometimes there are cases when ROI is not clearly defined, is impossible to define, or simply not that important to the stakeholders. Under such circumstances a value statement can be instrumental or even a must. They help overcome resistance, bind together stakeholders, and focus the project around delivering real business value. To summarize, they help you see the forest from the trees where as ROI calculations help you count the trees.
A value statement can take many shapes and formats depending on the context of the project and audience reviewing it. However, it is always a good idea to try and tie it back to the mission or value statement of the project. For example consider the following sample value statement:
The benefits need to be tied back to the capabilities by linking them to preferably operational measures. Financial measures although are more accurate they typically lag operational measures.
Calculating ROI
When calculating direct [i]and indirect [ii]benefits of a project it is important to keep three important aspects in mind:
- The Rate of Return of the Investment
- Capital Recovery Horizon
- Variance Potential
The rate of return of the investment is not just returns exceeding the original investment plus the cost of capital but it should also include compensation for the risk of undertaking the project. For example if a project returns 20% and cost of capital is 18% then the additional 2% may not be sufficient justification even for a “sure shot” of a project. As a very rough rule of thumb ROI of less than twice the cost of capital should be considered high-risk. A ROI of 4 times or more of the cost of capital is considered ideal. Capital recovery horizon is the time that a project will need to generate enough benefits to recover the original investment. The rapid pace at which technology, business environment, trends, and preferences change (especially in the IT industry) pose a significant risk of future benefits not being realized. Changing market conditions and new competition can create new more lucrative opportunities as well diminish the value of existing ones. Therefore it is highly desirable to recoup the original investment as quickly as possible to minimize exposure to sudden changes in market conditions. The ideal recovery time can vary significantly and depends significantly on the market conditions and maturity of a given vertical. For fast moving verticals recovery time of 1 to 2 years is ideal. Variance potential portrays the risk associated with changes or variances in the calculations and estimates of the future benefits of a project. Indirect benefits are hard to calculate accurately and are most susceptible to errors and variances. If indirect benefits constitute a high percentage of the overall benefits or a project then the variance potential for the project is high and vice-versa. Indirect benefits that are less than 50% of the overall benefits are ideal whereas a number of 90% or more indicates high risk to the project.
Calculating the ROI with appropriate level of rigor can be a daunting task. Coming up with a justification for a project is not a “one size fits all” exercise and does not always have to result in punching numbers and formulas into a spreadsheet. Depending on the type of project and the company the right type of benefits calculation has to be tied to the appropriate level of rigor. Sometimes a clear and well articulated value-statement can be sufficient while at other times you have to have hard numbers to backup your claim. A simplified ROI sheet that ties the benefits to the operational levers (operational capabilities) is presented below.
[i] A value statement focus more on the qualitative aspects rather than the quantitative ones, it is simply narrates the benefits without tying it to the bottom-line.
[ii] Direct benefits are the ones that are only one step removed or are a direct consequence of the implementation of the project (e.g. hardware/software/staff consolidation, time savings, inventory reductions, increase in revenue, etc.).
[iii] Indirect benefits are the sub-consequence of the change brought about the project implementation or are the unquantifiable side-effects (e.g. improvement in morale & good will, more knowledgeable support staff, increase in revenue, etc.).
Whenever crisis strikes and people enter uncertain and frightening times they close up like a clam. They do not take on new risks like new cars or houses, instead they find comfort in life’s little pleasures. Macaroni-and-cheese, tomato soup, and meatloaf seem to sooth the troubled mind and are the perfect accompaniment to the theater of financial meltdown. IT has it’s equivalent of comfort foods, short (less than one budget cycle) projects with easily measurable gains. Projects which enhance core business functionality and projects which increase visibility are usually easy wins.
Projects like “Let’s Outsource All IT”, “Let’s Go to the Cloud”, or “Let’s Move to Open Source, Oracle, Microsoft, etc. to Save Money” are not Comfort IT and elicit the image of someone running down the hallway with their hair on fire screaming (does not look comfortable to me, let’s skip this one). These projects will have their time in the sun when the Great Wheel turns again and risk is the entree of the day. It will be fun to see how fast the major vendors morph their tune to a new reality; they are already shifting from guppy sales representives to bonafide sharks via the layoff lever (I am ever thankful for Email, Voicemail, and Spam Filter Purgatories).
If your organization is light on legacy projects and issues, now is the time to start some (ha ha ha!). All joking aside, this period is a breather in the steady march of technological leverage of the corporation. Companies can leapfrog past the painful pioneering process inherent in most technical innovation, at a bargin price. Just about every hardware, software, and services vendor will have capacity to sell. It is a buyer’s market , which gives the most comfort of all.
This is the perfect time to review projects. Determine cost-to-complete, or can it be completed. Will it enhance the business process and ultimately be welcomed by its users, or is it a statue to political personal vanity (or an ediface to technology). Sacrificing projects on the altar of the crisis is considered a statesman-like action and a career-saver for both the guilty and innocent. For the fearful, consultant priests are available to both identify and cleanse corporate IT sins for a small fee in these times (put another project on the fire!). Nothing like a second opinion to sooth the soul, a true IT comfort food.
The Holidays are a great for watching “End of the World” shows on the History Channel. They were a great comfort, actually almost encouraging, because all of the prophecies target 2012. “The Bible Code II”, “The Mayan Prophecies”, and the Big 2012 Special compendium of End of the World scenarios, covering Nostrodamus to obscure German prophets, all agree that 2012 is the big one (Dec 21 to be exact!) What a relief!, the rest of the news reports are trending to canned goods, shotguns, and gold by the end of the year. We really have almost a whole 48 months before everything goes bang (I wasn’t ready anyway, procrastination rules!).
Unfortunately, we need to do some IT planning and budgeting for the new year and probably should have some thoughts going out 36 months (after that see the first paragraph). As I discussed in a prior blog, the reporting, BI/CPM/EPM, and analytics efforts are the strongest priority; followed by rational short cost savings efforts. All organizations must see where they are heading and keep as much water bailed out of the corporate boat as possible. Easy call, job done!
Then again a horrifying thought occurred to me, what if one of these initiatives should fail? (see my nightmares in prior blog posts on Data and Analytics). I am not saying I’m the Mad Hatter and the CEO is the Red Queen, but my head is feeling a bit loosely attached at the moment. Management cannot afford a failed project in this environment and neither can the CIO in any company (remember CIO=Career Is Over).
The best way to ensure sucessful project delivery (and guarantee my ringside lawn chair and six-pack at Armageddon in 2012) lies in building on best practice and solid technical architecture. For example, the most effective architecture is to use a layer of indirection between the CPM application (like Planning & Budgeting) and the source data systems (ERP, Custom transactional). This layer of indirection would be for data staging, allowing transfer to and from fixed layouts for simplified initial installation and maintenance. In addition, this staging area would be used for data cleansing and rationalization operations to prevent polluting CPM cubes with uncontrolled errors and changes. In terms of best practice, libraries and tools should be used in all circumstances to encapsulate knowlege rather than custom procedures or manual operations. Another best practice is to get procedural control of the Excel and Access jungle of wild and wooley data which stands ready to crash any implementation and cause failure and embarassment to the IT staff (and former CIO). When systems fail, it is usually a failure of confidence in the validity or timeliness of the information whether presented by dashboard or simple report.
CPM, EPM, and Analytics comprise and convey incredibly refined information and decisions of significant consequence are being made within organizations to restructure and invest based on this information. The information and decisions are only as good as the underlying data going into them. So skimping on the proper implementation can put the CIO’s paycheck at serious risk (Ouch!).
IBM first announced a competency center in Cloud Computing, then a Certification over the past couple of weeks. Well, I guess the old Druid Priests of Mainframes should recognize the resurrection of their old God TimeSharing. Here we are, back and rested from the Breast of Gaia, Greener than 
Green (Drum Roll Please…….): Cloud Computing! (Cloud Computing quickly adjusts his costume makeover to hide Ye Olde TimeSharing’s wrinkled roots) Yes! here I am fresh, new, exciting, Web 2.0, Chrome Ready! With me are the only guys (Big Smile from IBM!) who can Certify and Consult in My Mysteries…. IBM!
The more things change the more they stay the same, but this pushes the Great Hype Engine to a new high (or low..ha ha ha). I can understand IBM wanting to jump on the Cloud Computing bandwagon, but are we really ready for a certification? No one is really sure what is in the Cloud, or how it operates, but IBM is ready to lock it and load it. Yep, they are Certifiable! (ha ha ha!). While one can admire the desire to define and take a stand on Cloud Computing; this is one topic that requires a bit more “cook time” before full scale avarice takes hold.
Cloud Computing to too “cloudy” and “amorphous” to define today. While expertise and advice is required, there needs to be more independent vetting and best-of-breed component level competitions. Full solution demo platforms need to be put together to elicit ideas and act as pilots. Case studies need to spring from these efforts as well as early adopters before an organization bets the farm on a Cloud solution. The existing ERP platforms did not come into being overnight and these solutions have an element of their interdepency and complexity (Rome was not built in a day!). All of the elements of backup, disaster recoverability, auditability, service level assurance, and security need to be in place before there can be a total buy in to the platform. The reputation of Cloud Computing does hang in the balance, all that is required is one high visibility failure to set things back for potentially years (especially given the current macro environment).
Above all at this stage, a certain level of independence is required for evaluation and construction of possible solutions. Evolution mandates independent competition (Nature Red of Tooth and Claw, Cage Fighting, Yes!). Maturity brings vendor ecosystems and the all consuming Application Stack, but not yet. More innovation is required, we may not even have heard of the start-up who could win this game.
