Inserting Architectural Governance into the IT Program Funding Cycle
People do what you pay them to do. That much is clear. In most businesses, if you pay (reward, incentive) your employees for performing a particular task, then the task will be performed. Also in most businesses, people are busy, so if you don’t pay them to perform a particular task, it largely won’t be performed.
So in organizations where there is little or no tradition of governance, and where many people openly oppose the notion of having another person or team “telling them what to do,” how do you get people to sign up, show up, and put up? You pay them.
I’m not talking about bonuses, and I’m not talking about personal rewards. When dealing with the governance of projects within a business, I’m talking about requiring them to justify hours spent against a budget, and then creating controls that create and distribute the funds for that budget.
A large number of IT shops use this mechanism for basic governance.
A primer…
Let’s say you have five project teams. They all want to perform different projects based on what the business wants (or, as is often the case in IT, based on what IT believes that the business needs). But there is no way that all of those projects can actually be completed in the coming year. You can use priority to decide what to do, or you can use teams of architects to drill in to the project teams and determine what features will be built, and by whom. But that doesn’t mean that the decisions made in advance will be followed. Just because business leaders don’t want that ESB, does that mean that the developers won’t build it?
The rigor needed is to require project managers (and in some organizations, the project team members themselves) to “book” their time against a budget that has been set aside to fund their project. So team one, that wants to build features A, B, and C, starts with an estimate the costs of that effort. The architects and planners decide that team one should only build features A and B. So they budget only enough money to build A and B. Assuming that people are actually pulled off of projects when the money runs out, then project teams will have a built-in incentive to either deliver what they promise, or inflate their estimates so that the amount requested covers all of the desired scope, regardless of the executive decisions.
Now, in this environment, how do you add architectural governance? Add architecture to the funding model, of course.
When a project is being considered for funding, take a look at specific attributes of the project. If it is important, large, risky, or likely to need oversight, then it should follow specific rules for architectural governance. (The rest of the projects, which will account for a large majority of the budget, do not require architectural governance, and can simply negotiate directly with their business stakeholders on the basis of ROI).
This subset of projects needs special governance, architectural governance. That means that specific requirements are placed on the project as it is being conceived. In fact, you may need a two-stage process just to get the project started: stage one to get the information in place to decide whether to do it, and stage two to perform the actual project, with a funding decision taking place in the middle.
The key requirements for deciding if a project should be performed will go far beyond the normal ROI calculation. Large, risky, or potentially game-changing projects need to have architects fully engaged to help set the scope of the project, decide what enterprise assets will be improved or addressed, and focus in on stability, scalability, security, agility, and performance. Information has to be collected about the components in other systems that need to be improved, so that careful dependencies can be taken. Roadmaps need to be lined up because success may depend on many projects producing changes in many systems.
The flexibility that the business will have in “compressing the scope to reduce the budget” will be severely curtailed. The ROI calculation will not be quite as flexible, as there will be a great deal of cost that the business cannot squeeze out.
A team of architects needs to oversee this information gathering process, and needs to be present to defend the costs when the business tries to compress the budget or take short-sighted cuts. The project needs to deliver value frequently, all the way to the customer, in a rhythm that increases confidence in the IT organization to succeed. Only if all of these criteria are planned in, and carefully described, can the project get through the funding process and begin effort.
All the architectural review in the world can’t begin to provide the value that architectural governance during the funding cycle provides.
Sometimes, to win the game, you have to be at the right starting line…
Comments
Anonymous
June 15, 2010
Interesting post Nick. We are doing a lot of this right now, after having some "ah ha" moments over the last year or so. As architecture director w/ "Standards and Governance" in my job description, I've been really involved in making this work at my organization. Key is ensuring your roadmap and IT funding approval policy/process are aligned so that executives are making funding decisions "peeling" initiatives off the roadmap. That ensures you are deciding to do things that have gone through the vetting, prioritization and strategic alignment that roadmapping should provide. Next is implementing an Architecture Governance process that check projects not only for technology standards conformance, but strategic conformance, using the roadmap as key governance tool.Anonymous
June 17, 2010
So where does governance really belong in an org to make it affective for the tasks that require governance. I would opine that it belongs in the business model or strategy of the org. If it is established at the top then it can easily permeate the various levels of hierarchy that some times impeded governance support. I have seen a continued push for governance from below. Seems counterintuitive and fails. At its simplest Enterprise governance comprises LOB and Operations. Once that is established then the layers can be peeled back and the key players identified for further governance activities, such as architecture.