Ensure the project has sustainable business benefits and identify to which business unit(s) they accrue
That’s two steps, but the first seems too obvious to merit a blog entry of its own. But …
You have probably already had demands from your CIO for essential funding to upgrade infrastructure to prevent the world coming to an end. What has that got to do with business sustainability?
Unfortunately we live in a technology dependent world where information is vital but vulnerable. Information which is vital to your business is valuable to your competitors. And in no small measure, your business is valuable to your community’s economic well-being, as well as that of the nation as a whole. Cyber warfare is perhaps the next major threat to global security, and to the continued success of your business.
So some IT initiated projects have to be seen as contributing to business sustainability. Some, however, may not.
Techies like new toys. And we are now all techies to some degree. Why else would we trade in a year old smart phone for one with a slightly different screen? The techies in the IT department like new toys tools – let’s be generous – too, but theirs are a lot more expensive. They may also become obsolete at a faster rate than iPhones. Frequently the justification for these tools is that they will improve productivity, mitigate staff turnover, attract needed talent and eliminate the need for costly upgrades at a later date. Rarely are these assertions backed by evidence.
Conversely, we have seen examples where an IT department refused to allow a vendor to use a particular tool because it didn’t want to maintain another piece of software and train people in its use. The CIO’s intransigence almost derailed a major business relocation project which, the CEO acknowledged, would have cost him his job. The minor adjustment to the CIO’s key performance indicators achieved long-term sustainable benefits to the organization.
Hopefully, the more common case for funding of an IT project comes from, or at least with support from, one or more business units. In itself it should be gratifying to see IT and business users playing in the same sand pit. Often, however, the user has no real understanding of the implications of an obviously beneficial IT project. And if they think there are no adverse consequences they are in denial.
A Benefits Realization review is designed to qualify, quantify and attribute benefits to each and every stakeholder affected by a new system or process. It also identifies the actions, activities and responsibilities of each stakeholder to achieve the expected outcomes.
Too often, the benefits are not quantified … and the responsibilities are assumed to be incumbent on the IT department or vendor. It is this mis-attribution of responsibility which become the grounds for friction between business units and IT, or outside vendors, and which causes most distress to timelines and budgets in systems implementations. (See also Change Management)
We have witnessed a propensity to dismiss the need to quantify benefits on the basis that they are obvious. This is a massive failure of logic. If it is obvious, it should be easy to calculate. Alternatively, the outcome is described as not quantifiable but, again, obvious. This is just laziness or a failure to fully understand the processes and how benefits can be realized. Even if an outcome cannot be reasonably quantified, a value should be ascribed to it. The effort required to achieve the outcome will be real. The reward should be seen to commensurate with the effort in order to achieve the responsible stakeholder’s rational buy-in – and commitment.
A word about sustainability. The business world is changing rapidly. IT should facilitate that change, but it should also adapt itself to future changes too. Every IT project request should include a section on how it is expected to integrate itself with and/or facilitate the five-year business strategy of the organization.