Interesting article from yesterday’s CIO Journal section in the Wall Street Journal, “Study: Most Financial Executives Unable to Evaluate IT Investments.” In a nutshell, it would seem most rate their companies either a C or D when asked about the ability to determine the success of an IT project.
Special thanks to Alix Partners and CFO Research for doing the heavy lifting of surveying 1,500 business execs to end up preaching to my choir (Survey Results Here) – I’ve been making a living for years off of crossing the divide between the CFO and CIO.
I would suppose it goes back to being fired.
In the late 90’s I was a Senior Executive at a major regional blood bank – I’d developed a national reputation for turning around these non-profit businesses and reached a pinnacle of the career. In an effort to keep replicating my 200% and 300% growth rates (trade secret: It’s not hard to deliver tremendous results when the baseline starts from a non-profit mindset), I had taken on a massive IT project to completely automate the recruitment effort. Among these efforts, was a $1.2m automated dialer – a tool to make our phone room more effective at calling blood donors when they were eligible to donate. So far so good. Having learned in an automated dialer sales demonstration that we’d be able to call 70% more donors daily, I pushed through the approval process and started the implementation. Day one of go-live, we’re calling 70% more donors!
Only one problem.
It was not lack of phone calls holding back donations, it was donor fatigue, the same donors were being called over and over again and were getting burned out, becoming reluctant to donate. So while we reached 70% more donors, we only increased donations by 11%.
I learned very quickly that what works really well in a sales demo can end up getting the project managers fired at go-live.
So, today, in my consulting practice, we don’t start with the sales demo.
We start with the business case.
We map the business model, we gather the transactional costs. We look at how it’s being done today and how we can shift costs tomorrow. We look at how we’ll gather the information, (is it easy to use) and what we’ll do with better information. We look at will technology cause change, what are the incentives for change and what are the end results of change. We develop what’s called the Cost/Revenue Model – a cross departmental goal setting for cost savings and revenue enhancement using the technology best suited to address our most pertinent areas of improvement.
And then we determine what will make the project a success. From an IT perspective, but more importantly from the CFO perspective. Will it save dollars and cents?
If the answers is yes – we take the worst case scenario.
We think we can save 25% of our labor cost in the warehouse and pay for the software system in 7 months. What if we only achieve half of that? We think we can expand the business by 40% without adding the 4 accounting positions we had budgeted for next year. What if we still need 2? We think we can cut inventory carrying costs by several million by JIT inventory and integrated purchasing and MRP. What if it’s only half of what we expect?
At this point, we’re not just purchasing software, we’re starting a project to save (very conservatively) $1.2m annually while spending $425k on our software project, budgeting $50k in internal success bonuses (or at least buy the ERP Team some Project T-Shirts), and planning on increasing hourly pay rates by $100k to reward our (now fewer) employees for increased productivity (or more T-Shirts).
Now, we have several things:
- A roadmap of what to look for on the way – especially in the sales demo.
- Benchmarks – how are we doing in each area? If our inventory savings aren’t what we thought is our labor cost dropping overtime and increasing output?
- A common evaluation process!
- Incentive Alignment
We’re speaking the same language!
While the CIO may judge the project a total success as measured by uptime, system availability, lack of major modifications or any of a number of (very important) yardsticks, the CFO has no real concept of downtime – so there’s a disconnect.
But if both the CIO and CFO are judging actual business improvement – now we’re on the same page.
BUT WAIT! Screams Bob Obvious, the CIO – “I can put in the system perfectly, have a flawless implementation, rock solid networks and hardware, but if the department managers don’t perform – that’s USER ERROR, not my fault.”
And of course he’s right, He’s Bob Obvious. Which is why we need this common language approach from the beginning. It’s more than just software and hardware. It’s Change Management, Performance Management, Business Intelligence. It’s the warehouse manager knowing he’s going to have to use this project to drive productivity by 25%. It’s the warehouse worker knowing his next bonus (or t-shirt) depends on pulling 25% more boxes. Plus it’s more than one department – and that takes leadership from the very top.
Then there’s Frank Obvious, the CFO – “They’re always promising pie in the sky financial returns – I’ve never seen any of them materialize.” Which is more likely true than not, but the question back to Frank is, “Did you have a Cost/Revenue Model in the other past projects you’ve done?” In the ERP world, it’s almost cheating. Set a goal, determine how you’re going to meet it, do a little sandbagging and you deliver every time. But Frank Obvious is right, you never reach goals you do not set – and most IT projects don’t have clearly defined goals nor breakdowns of how each dollar will be saved.
So over the years, although I’m no longer in the blood donor business, there’s been plenty of blood, sweat and tears at companies who fail to start software projects by bringing in a consultant who understands the need for a common goals approach from both IT and the Business side – but there’s also been lots of companies who meet the goals we set for the project. .
It’s always surprised me – bringing in the right consultant from the beginning is only a fraction of the cost of a successful software project – even more miniscule when measured against a failed software project – but as we learn from the Alix Partners Survey, the internal team is not even speaking the same language to begin with.
You can reach Gene Hammons, MBA at gh@genehammons.com.