Giving Teeth to the Building Permit Process


The building permit process is critical to the success of an Enterprise Architecture. Often, this process fails and with it the Enterprise Architecture. The article highlights the 7 common mistakes that lead to the failure of this process and suggests ways to avoid them.


Giving "teeth" to Building permits

In another article, we discussed the reasons behind the failure of Enterprise Architecture to get the executive nod. The primary reason is that often Enterprise Architectures are not implemented.

A good "building permit" process is critical to implementing an Enterprise Architecture. In fact, this process is critical to the success of IT Governance. If the organization wants to leverage its IT Strategy, Enterprise Architecture, etc. it must not only have this process but also give it "teeth". This can make all the difference between having an IT strategy and creating IT Value.

As the name suggests, the building permit process provides the authorization to implement a major IT Project. The definition of authorization, implementation, and major are critical to the success of this process.

The success of an Enterprise Architecture can be laid at the door of the "building permit" process in an organization. Often, this process fails, and with it the Enterprise Architecture.

The 7 common mistakes in the building permit process:

So why does this process fail?

I have observed the following mistakes:

  1. The architecture review committee does not have adequate authority
  2. They are more discussion forums than decision-making bodies
  3. The process lacks metrics and accountability
  4. The process does not connect with other critical processes
  5. Pre-meeting preparation is also minimal
  6. Note-taking is minimal. Subsequent distribution is rare
  7. Post-meeting follow-up and enforcement is lacking

Let us look at each of these and see how we can avoid them.

An Architecture Review Committee without "teeth"

The architecture review committee is typically the process owner for the "building permit" process. Its composition, policies, procedures, and authority are important to the success of the process it oversees.

An architecture review committee that does not provide adequate authority to the governance council overseeing it is not worth the money. For example, if you have a process that clearly determines that an IT project is not worth pursuing and it still gets done then what is the point of having this analysis done?

The composition of these committees is the root cause of the lack of authority. Typically, these committees are comprised of architects, programmers, and project managers. The premise is that this is a technical issue.

  1. This is a business, not a technical issue
  2. The knowledge of the business side of the equation is with the "business"
  3. The "real" authority also lies with the "business"
  4. Hence, the committee without business representation is one that is setting itself up for failure
    1. It will not make decisions in the business context
    2. Even if its decisions are valid, it will not have the authority to implement these decisions
      So who should attend? In the least, the following skills should be considered for representation:
    3. Impact on business (Money) get the business sponsor to attend
    4. Architecture & Standards including future technology trends. Impact on existing architecture
    5. HR's impact on skills planning
    6. Procurement impact on strategic sourcing

The focus on decisions not debate

One of the biggest digs that these committees take is that these are debating societies. This criticism does not only come from the business side but also from the implementation teams.

The latter feel that the architects do not have any "responsibility" in the process so they can debate ad nauseam. They also feel that their architects are "purists" devoid of any sense of the "ground realities." Right or wrong, under the circumstances, they are expectedly reluctant to cede authority to the committee. Hence, they attend meetings and then go about their way irrespective of the decisions made by the committee.

The business is rarely invited to these meetings. When they do attend, they are lost in all the "tech talk" or not involved in the decision-making process.

The key to such a committee is not only the participation of key representatives from "business" but also making the architecture team responsible for the success or failure of a project.

Keeping score and naming names

The argument for this process is that it makes IT Projects effective and efficient. This value delivery should be measured and tracked.

Once we have a handle on this value, the committee and all its members should take responsibility for its delivery or lack thereof. If a project is late or over budget, then the architects should share the responsibility. If it is a spectacular success, well, we know who contributed to that!

The only sure-shot way of taking responsibility is reflected in employee evaluation and compensation. Hence, this process must be linked with the employee evaluation and compensation process!

This will put an end to the debate or make them focused and meaningful. This will also alleviate a common complaint among architecture teams that they are not "appreciated."

If possible, key decisions should require key stakeholders to formally sign off on them!

No process is an island

The "building permit" process connects multiple processes. It takes input from IT Strategy and technology standards and provides input to project portfolio management, strategic sourcing, and HR processes.

Often, this connection is not established. For example, having a technology standard is a critical ingredient of this process. Then, using the position on the latest technology trends and their impact on the organization should guide the decisions of this committee.

How many meetings have you attended where the technology standards were up to date? Their business impact understood? The impact of deviation from standard articulated? The cross-organizational project plans and the impact of decisions on delivery dates understood and articulated?

Hopefully, you get the point.

A meeting starts way before the meeting

These meetings required a lot of preparation prior to them. Not only do they need up-to-date technology standards but also their impact on the project and IT capability understood and articulated.

This impact statement does not have to be volumes but it must be communicated to the participants prior to the meeting so they come prepared to discuss the implications.

This reduces "discovery" during the meeting. Reduces debate. Lowers the defense mechanism of participants and the conversation is more logical than emotional.

The impact of key IT decisions is felt by many projects. The stakeholders of these projects should be informed and where possible invited to discuss this at the meeting.

If it is not documented it did not happen
These meetings are important. The decisions made in them have a long-term impact on IT value creation. They have meaning for the entire organization.

Documenting the key decisions is critical to their implementation. Then, they should be communicated to key stakeholders. They should also be stored in a common drive or intranet for easy reference.

These notes also form the basis for discussion in subsequent meetings. They improve the understanding of new participants and reduce unnecessary debate on the ground that has already been covered.

Finally, they facilitate the tracking and monitoring of compliance. If a decision is made and communicated but not implemented then it is easy to highlight and corrective action was taken against the "offender."

Decisions are nothing without implementation
Often, meetings end with great decisions. Then project teams walk away and do what they want!

We discussed how to track compliance above. How do you enforce it?

This is where the judgment and will of the leadership come in. When, where, and how to enforce decisions is a critical responsibility of the leadership team. If they lack the will, then they might as well save everybody the trouble and shareholders their money!


Signup for Thought Leader

Get the latest IT management thought leadership delivered to your mailbox.

Mailchimp Signup (Short)

Join The Largest Global Network of CIOs!

Over 75,000 of your peers have begun their journey to CIO 3.0 Are you ready to start yours?
Mailchimp Signup (Short)