How to justify IT projects to your CFO

How to justify IT projects to your CFO

This article is based on a series of three blog posts I wrote entitled “How to justify Application Modernization to your CFO.” Very similar cost/benefit justification principles apply to other IT projects, such as supporting users with mobile technology, extending your system to the Web, process automation and so on. But you could of course argue these are all variations of modernization projects, so the original blog title covers it all.

Step 1. Find the Right Initiative

Become proactive and set up regular brainstorming meetings with business users. Brainstorm from several perspectives. Focus on inputs and outputs rather than how things are done today. Ask ‘What if’ questions and picture yourself there. How would operations look? Would you drive more revenue? Reduce costs? Be more responsive?

Step 2. Start Planting Seeds Early

No CFO will approve a significant project the first time they hear of it, or if it comes from only one source. Gain preliminary support from business users and be ready to make some reasonable adjustments in that process. Inform the CFO of your initiative, what you have done so far, that it looks promising but requires more work. Offer a milestone date by which you expect to be able to present it.

Step 3. Do Homework to Justify a Project Scope

Interview business users to gain support for the vision and to garner willingness to assist in subsequent project stages. You want to be able to show the CFO that Bill in Manufacturing and Jill in Marketing support the project. Build a preliminary business case, but keep it simple and back it up with figures.

Step 4. Gain CFO Support for a Deeper Project Scope

With the sponsor(s), co-present the business vision and business case. Size the project’s estimated effort/costs and benefits. Explain work done to date, what is still needed, identify the project scope and lists its deliverables. End by highlighting the desirable future-state and how it supports the organization’s mission. Ask for the green light to proceed with the study and book the first executive update meeting.

Step 5. Conducting a Project Scope

To summarize very briefly, the output from this step includes: Business vision statement, Non-functional & functional requirements, Design (which may include a data model, User interface, workflow, and more), Report of project risks and how they will be addressed, Prototypes to address identified risk areas and draw out early feedback, Project plan with all known tasks, resources and dependencies and the Project management methodology to be used. Step 5 is a blog article by itself.

Step 6. ROI Calculations

Return on Investment, or ROI, is the ratio of money gained or lost on an investment relative to the amount invested. There are various formulas to calculate the returns. The one below is practical and realistic for most projects.

Return on Investment, or ROI, is the ratio of money gained or lost on an investment relative to the amount invested.
Return on Investment, or ROI, is the ratio of money gained or lost on an investment relative to the amount invested.

Predict Measurable Impacts

Although the Project Scope forced a deep dive into the requirements, design and planning, don’t forget it’s really all about creating business value! Here you list all the business impacts that you expect your project to deliver. Make them measurable where possible, ideally as dollar figures.

The numbers should come from business users and they should be realistic and complete. For example, the introduction of new sales channels may attract new customers, but may also reduce revenue from traditional orders.

LANSA case studies are full of measurable impacts. For example, Kawasaki’s project to introduce mobile apps for its assembly staff started with a ROI analysis. Kawasaki calculated that it used 4,500 kanban cards per day and that each card is handled by 8 to 10 people, for about 10 seconds. Based on average wages being $30 per hour, Kawasaki estimated it would save $3,000 per day, or $747,000 per year in labor costs directly related to staff using mobile apps for eKanban instead of handling the physical kanban cards.

Calculate Gains in Present Value

Gains resulting from a project implementation are expected to be realized in future months and years. However, capital costs for the project itself will be spent far sooner. To answer your CFO’s question ‘What is it worth today?’ you might want to express numbers in Present Value (PV).

To calculate PV, you need to set a discount or interest rate (a.k.a rate of return). For argument’s sake, let’s assume 5%. The formula to take compounded interest into account would then be PV = FV/1.05n, where “FV” is Future Value and “n” is the number of years into the future. So 2015, being two years into future PV=FV/1.052 and so on. This will reduce your predicted gains, as gains achieved in the future are worth less than gains achieved today.

Calculate Expected Risks

Just as your predicted gains are based on expected values, you need to calculate the expected negative impacts for each risk as identified in your Project Scope. Putting aside that you plan to bring risks forward through prototyping and model offices, let’s keep things simple. For each identified risk, you need to approximate:

  • The % likelihood of the risk being realized.
  • The cost to the business should the risk be realized.

Then, you multiply them to get the expected loss for that risk factor. For example, if the risk of users rejecting the system during initial training is estimated to be 20% and the cost of system modifications and additional training is estimated to be $250,000, then the expected value of that risk is $50,000.

If the risk of downtime in the first quarter is estimated to be 15% and the estimated costs $450,000, then the expected value of that risk would be $67,500. You may have several downtime calculations, as the risk might be higher at the beginning, but possibly with a lower associated cost if the company can revert to its old system. Downtime costs then need to be annualized.

Although we could predict risks for five years, for simplicity, let’s assume for this exercise the expected value of all the risks is $1,144,500 and that the risks are not applicable after year one.

Expected Gain > Expected Cost?

As part of the Project Scope, the Project Plan should list all the project costs, such as costs for analysis, design, construction, testing, training, implementation, and ongoing maintenance & operational costs. Let’s assume the total project cost is $1,500,000 and the ongoing maintenance/operational costs is $100,000 per year, starting in year two, adjusted for PV.

After all your hard work, this step should be simple, and hopefully satisfying:

  • ROI = PV of Expected Gain – PV of Expected Cost – PV of Expected Value of Risk.

So, in the simplified example of this exercise, ROI = $10,169,037 – $1,854,595 – $1,144,500. That is, the expected ROI of the modernized system in Present Value is $7,169,942. Any expected ROI above zero is worth the consideration of your CFO, but this one should be a no-brainer.

Expected ROI

Monitor Actual ROI, Compare

As a LANSA Professional Services Consultant, I like to stand up in the Project Scope presentation meetings and tell the executive team that they must hold me and themselves accountable to meet again 12 months after go-live to measure the actual ROI. Most organization’s executives seem surprised how quickly time goes by when I call a year later to schedule that follow up meeting.

Measuring the actual ROI and comparing it to the predictions will bolster your credibility and help your cause the next time you want money for a project. So, track all the actual project costs, related changes in revenue, related changes in operational costs, risk factors and related losses suffered.

Survey the system users, their managers and other stakeholders for their general impressions of the project, the new/modernized system, how it has impacted their roles and how they believe it has impacted their business. Ideally, run the survey twice, maybe five months after go-live, and again at 10 months. Use different but equivalent question sets, and consider keeping the first survey anonymous to coax out the truth from those that may feel a conflict of interest.

I like to build the skeleton presentation before any of the business impacts can even be measured, and show it to managers and key users. I include their names in the presentation to highlight the fact that they will be highly visible to the executives, and that their role matters. Then I show the skeleton presentation to the CFO to get feedback on what I plan to measure and report on:

  • Original vision and key business objectives.
  • Status update – what was achieved, when.
  • Impact Assessment – business benefits realized, losses suffered, survey results, ROI achieved.
  • Call to action – what changes are recommended, how the executive team can assist, and so on.

Ideally, your presentation will include charts. Also collect user quotes, including quotes for benefits that cannot be easily quantified. Make sure to include the name and job title of the person who provided the quote For example:

  • “Customer Service has much improved due to easy accessibility to client data.”
  • “Having complete visibility of how documents progress through the system helps us to spot the bottlenecks and manage the process with precision.”

Of course, after legs grow weary of standing ovations and all backs have been thoroughly patted, it might be an opportune time to let the audience know that you have more cool new initiatives in mind!

Having been through this entire process more than once, I can tell you that there’s nothing more rewarding for a solution provider than presenting arm in arm with IT and business users, following through on our commitment to the executives, and especially to the all-important CFO.

Steve Collins

Author: Steve Collins

Steve is a Director of Professional Services for LANSA in the Americas. With a solid academic background in mathematics and software engineering, Steve began his career as an application programmer using many different languages and platforms. In his 18 years with LANSA, Steve has played roles of architect, designer, project manager and quality manager on many large and innovative projects and actually prototyped LANSA’s very first Web application. Steve is a regular speaker at LANSA user conferences, has presented at various seminars and has written technology and project management articles for industry publications.

Leave a Reply

Your email address will not be published. Required fields are marked *