"Governance" is a badass sounding phrase that simply means establishing policies to enable consistent management by exception. But many governance initiatives are doomed to fail.
"Governance" is a badass sounding phrase that simply means establishing policies to enable consistent management by exception. Unfortunately, many so-called governance initiatives are doomed to enter the annals of IT failure history.
In a post titled, Linear Thinking and the CIO, blogger Eric D. Brown describes a scenario of governance gone wrong:
The CIO commissions the IT group to create and implement a governance model & document to manage all IT projects. This governance document is developed as a closed system with little input from the rest of the organization. The model is put i
nto practice and is now ‘law’ within the organization.
Based on the governance model, all new projects over $25,000 must go through the governance process. Why $25K? Very few projects can be completed for less than that…and those that fall under $25K aren’t really that important right?
So…the HR team is ready to implement a new system. They come to IT and ask for some assistance and are told that the project will undoubtedly be over $25K and must go into the governance process and be subject to ‘proper’ project and portfolio management practices.
The HR team are good corporate citizens and begin the governance process. They fill out the paperwork. Determine an estimated cost for the project (and it is over $25K) and wait for the governance process to kick in. And they wait.
A month after submitting the paperwork, a meeting is held to prioritize the projects within the organization. The HR team doesn’t get to attend this meeting…they have to rely on the IT team and submitted paperwork to make their case.
The project is deemed a lower priority than others and not authorized. The HR team is furious. The implementation of this system is a part of all of their performance goals for the year and it has to get done.
So….what happens?
You know what happens! The HR Team moves forward anyway. They reach out to vendors and solicit bids for a ‘phased approach’ to the project. Perhaps they look for a SaaS model for the system to save implementation and initial upfront investment.
Jump forward six months.
The HR Team has fully implement a SaaS platform to do what they need to do. The system does not integrate with any other platform within the organization (perhaps it can, it just hasn’t been integrated). The HR Team is happy as they’ve met the need of their team and reached their goals.
The IT team is not happy. They’ve now got another system in the mix and have to decide whether they support it or not. The CIO isn’t happy because the governance model has proven ineffective. The CIO takes the issue to the CEO and is told to support the platform…the HR team is ‘getting things done’ and the IT team better get on the ball or ‘heads will roll’.
THE PROJECT FAILURES ANALYSIS
The situation described in Eric's blog demonstrates three distinct problems:
1. Creating governance without user engagement. This is the Cardinal Sin. It's completely lame to not bring users into the fold when specifying rules, regulations, policies, orders, demands, mandated-sequential-small-steps-that-are-actually-big-policy-changes, and so on. Compliance requires buy-in and that means soliciting end-user opinions.
2. Ignoring technology realities. Users are aware that software as a service (SaaS) is real and often inexpensive. In 2010, it makes no sense for IT to pretend that lines of business are unable to purchase their own systems.
3. Demonstrating poor judgment. The first two points don't really reflect bad governance so much as lousy decision making.
Governance isn't something that IT can or should dream up and implement unilaterally: it involves the senior management team, as a group, sitting around a table originally and everyone nodding their heads that they all can and will adhere to this process, in order to achieve the benefits. If you don't have that high-level buy-in, don't even bother talking about instituting governance, because it will lead to the kinds of fiasco that you describe.
The involvement of key business stakeholders in the governance body is critical. Someone not directly in IT should be fighting for that HR system, in other words, in the meeting. That doesn't mean, of course, that the answer will be yes, because the organization as a whole may indeed have higher priorities and there are limited resources as always. It should mean, though, that if the answer is no, the answer is no, and it's not a ticket to go out and build things on HR's own.
My take. As is usually the case, successful IT is not about technology, bits, or bytes. Managing and coordinating across departments and other information silos or boundaries is the key to successful IT governance. It's also the critical step in preventing IT failure.
