Governing the speed of business

Governance of IT projects ensures that they bring value to the organization, by aligning priorities and coordinating resources for the best value to the organization. They do this by enforcing a set of standard processes for each project. The standards often specify the technology to be used, the project evaluation (including cost/benefit analysis), and the reporting of project progress.

A side effect of IT governance is the slow pace at which projects can move. The governance process includes meetings and conference calls between various groups, and buy-in from the involved teams. All stakeholders are included, from users to testers and support teams. Meetings between all of these groups requires time, and frequently the governance organization schedules meetings on a regular basis (say, once a month) to review project progress and discuss new projects. Projects must live on "governance time", and fit within the schedule of the governance organization. But the benefit is that the project meets the needs of the organization.

So the IT governance process slows projects to ensure quality and coordination.

Interestingly, early steam engines (well, some steam engines) had governors. They were used to limit the speed of the engine. They slowed the engine to ensure that the engine provided the proper power. (Or, one could say "to meet the needs of the organization".)

The problem with (traditional) IT governance is that it slows the project. Any project. Every project.

Traditional IT governance is a bureaucratic process. It obtains quality, coordination, and consistency at the cost of time.

It also constrains solutions to projects of a certain size, or of a size within a certain range of sizes.

IT projects come in all sizes, from the two-person, four-hour "let's try this" to the hundred-person, multi-year global development and implementation projects for thousands of users. But IT governance often uses a standard project template for projects, specifying the general steps for a project, the reporting requirements, and the technologies involved. Any project must go through the governance process, and like Play-Doh being pushed through a mold, the project is shaped into a form selected by the governance group. Small projects are increased to include users and deployment teams. Large projects are divided into smaller ones, to allow for deliverables within the standard timeframe.

In other words, the governance process "normalizes" all projects. Small projects are made standard-size, and large projects are made standard-size too.

This normalization makes sense from the view of the governance committee (who wants to see a consistent set of projects and reports) but not from the view of the business. Let's look at a hypothetical example:

Senior Manager (to project leader): "Customers keep calling and asking for an iPhone app. Can we get something built before the end of the quarter?"

Project Leader: "Possibly. We have a few folks who have been experimenting with iPhone apps. Let me look at schedules and see what I can arrange."

:: one week later ::

PL (to SM): "I can move people from the "Huron" and "Erie" projects, and they could build the iPhone app and deliver it in two weeks. But that means delaying "Huron" and "Erie", and the PMO refused to adjust the schedule for those projects. And even if they did, the standards committee needs two months to review the new tools for iPhone apps before allowing us to use them. And then the security group rejected our proposal, since they have not tested the iPhone in our environment. They want six months (and funding) to build a lab and hire four analysts and a manager for iPhone apps. Oh, and the PMO called and wants to discuss the iPhone app at their monthly project review meetings, and they can fit us in to the schedule in three months."

An idea brought "under control" by the governance process. Standardized and approved.

But perhaps not what the organization needs.