Let’s face it, to most people in IT, “Governance” is a dirty word. That perception is not born out of an idea that IT governance is bad, but out of the reality that IT governance is badly implemented in most organizations. When an organization confuses good IT governance with overly detailed and prescriptive IT governance, it starts to constrain rather than enable its people. And when people feel constrained and not empowered to make the decisions, they work around or against the process, which then results in proliferation of shadow IT.
The reason for this phenomenon is that many organizations approach IT governance with a few very flawed assumptions around how software and technology projects work:
- Changes are bad;
- Consistent results are driven from consistent processes;
- Standardization reduces the number of decisions, which makes the process more efficient and consistent; and
- Measure of a good project is on-budget and on-time.
- Technology is about change. The whole point of implementing technology is to support and enable more rapidly changing business needs. Add that to the speed of technology changes, the default position of any good IT governance process should be to assume constant change and deal with it head on instead of trying to contain and avoid it.
- Speaking of change, there is no way for a one-size-fits-all process to anticipate all the different ways a technology project can unfold. In fact, the more prescriptive a process is, the less likely it will fit the next project. There are simply too many variables and moving targets in modern enterprise IT projects.
- You hired smart people to implement technology and guess what? Smart people like to make decisions and feel ownership of their work. By over-standardizing, talented tech resources are turned into the IT equivalent of assembly line workers. At best they become disengaged and stale in their skills. But more likely, they take matters into their own hands and create opportunities to make decisions or fight the governance process to retain some ownership of the work they’re being asked to do.
- IT initiatives exist to make your business better and the users happier. While budget, scope, and schedule are important, they’re management measures on the process rather than whether a project was truly successful.
- Reduce and align the number of gates to the number of “point-of-no-return” decisions on a project (e.g., business case, functional design, technical design, go-live).
- For each gate, focus on what kinds of decisions need to be made, guidance on people who should be involved, and some basic examples of information that should be provided as input. Let the smart people do what they’re being paid to do, which is talk it out and own the decision.
- Standardize only the mundane and highly repeatable decisions. Standards are about helping speed up the process and focusing the effort of only debating things that deserve to be debated. It’s not about compliance metrics and enforcement. If you have to put in an exception or exemption process, you’ve gone too far.
- Ensure communications on what the project will deliver in terms of functionality and value. Most stakeholders care a lot more about whether a particular feature set is being implemented for their users rather than whether a particular deliverable is green or yellow.