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.
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, and planning on increasing labor expenses by $100k to reward our (now fewer) employees for increased productivity.
Now, we have several things:
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 depends on pulling 25% more boxes. Plus it's more than one department - and that takes leadership from the CFO side.
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 language approach from both IT and the Business side.
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, they're not even speaking the same language to begin with.
You can reach Gene Hammons, MBA at firstname.lastname@example.org.
To forward or share this blog post use: http://bit.ly/YyD9Kx
Trends Fads Bubbles and Bashing. Take a couple hundred Geeks and give them typewriters, you'll never get Shakespeare, but what you will get is the Technology Press - here's where we sort it all out to see if there's any 'there' there.