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”, “implement” 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 of 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

a. It will not make decisions in the business context

b. 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:

a. Impact on business (Money) – get the business sponsor to attend

b. Architecture & Standards – including future technology trends. Impact on existing architecture

c. HR – impact on skills planning

d. 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 there architects are “purists” devoid of any sense for the “ground realities.” Right or wrong, under the circumstances, they are expectedly reluctant to cede authority to the committee. Hence, they attend meeting and then go about their way irrespective of the decisions made in 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 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 amongst 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 connect is not established. For example, having a technology standard is a critical ingredient to 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 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 understanding of new participants and reduce unnecessary debate on 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 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 comes 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!

About the Author:

Sourabh Hajela is a management consultant and trainer with over 20 years of experience creating shareholder value for his Fortune 50 clients. His consulting practice is focused on IT strategy, alignment and ROI. For more information, please visit http://www.startsmarts.com/. Or feel free to contact Sourabh at [email protected].


Related Categories




Related Topics




Related Articles


A Framework for SOA Governance

This paper presents a business driven framework for SOA governance that addresses the six challenges of effective service oriented architecture implementation.

A Perspective on SOA Governance

This paper attempts to look at well - established concepts of governance in public and corporate life that can be applied for SOA governance. The authors also propose the use of Montesquieu’s power sharing formula that can help constitute the SOA go...

An Overview of SC7 Standards

This presentation provides an overview of SC7 and its standards - a brief history of ISO/IEC 15504, Automotive SPICE; current developments in systems and software engineering standards.

Architecting the Enterprise for Business Value

This paper uses a case study to demonstrate the practical application of enterprise architecture to create business value. 

Assessing Project Compliance with Enterprise Architecture

This article focuses on how to assess projects implementing business processes and IT systems on compliance with an Enterprise Architecture that provides constraints and high-level solutions.

Balanced Scorecard: Enterprise Architecture Business Case

A very interesting paper on using the balanced scorecard (BSC) to measure the value of enterprise architecture.

BPMN and Business Process Management

This paper provides an in-depth introduction to the new BPMN - Business Process Modeling Notation -  standard, illustrating how it is used to model business processes and web services.

Creating Business Value through Enterprise Architecture

This is a global study on the business value of enterprise architecture - do business executives consider EA critical to business value? Does EA maturity level vary by organization? Is business value related to EA maturity level? How can companies i...

Enterprise Architecture Steps

 Step by step guide to enterprise architecture planning using Methodology for Business Transformation (MBT)

How to Govern a Service Oriented Architecture

This whitepaper describes what’s required to govern and manage a service oriented architecture.

Identity Driven SOA Governance

 This presentation defines Service Oriented Architecture (SOA) governance and describes its benefits. It also discusses architecting and implementing identity enabled SOA Governance.

Maximizing Your SOA Investment

This paper discusses the business case for the service oriented architecture (SOA) investment - "it provides the dynamic capability to create innovation for managing change and empowering competitive advantage."

Service Oriented Architecture (SOA) Governance

This paper lists the top 10 challenges facing organizations adopting Service Oriented Architecture (SOA) and discusses SOA governance as a solution to them.

Service Oriented Architecture Governance

This presentation discusses Service Oriented Architecture (SOA) Governance.

Should Enterprise Architecture Break Out of IT?

The author argues that enterprise architecture's immense potential cannot be realized within the four walls of the IT organization - is it time for enterprise architecture to break away from IT?

SOA Governance – An Industry Analyst’s View

This presentation provides an overview of Service Oriented Architecture (SOA) Governance from an industry analyst's perspective

SOA Governance Case Study (Euroclear)

This case study discusses the four aspects of service oriented architecture (SOA) governance at Euroclear namely, Service Governance, Service Ownership, Service Development, Service Management.

SOA governance: Creating a Culture of Service Re-Use

This case study argues for creating a culture of service re-use using a "hub centric" SOA architecture.

The Four Domain Architecture

In this paper, we present the Four-Domain Architecture (FDA), which integrates business process, information, knowledge, and elements pertaining to infrastructure and organization. The FDA approach can help guide the development of both the conceptu...

The SOA Governance Framework

In previous reports we have introduced the concept of an SOA Governance Framework - a structured approach to ensuring the architecture delivers the required levels of adaptability and integrity. In this report we detail each of the layers in terms o...

Using Enterprise Architecture to Quantify the Benefits of Information Technology Projects

 This paper presents a "structured" framework to quantify the "overall financial impact of an IT project," based upon enterprise architecture planning.

What is Enterprise Architecture?

"Enterprise Architecture (EA) is about creating and using a shared “language” (of words, graphics, and other depictions) to discuss and document every important aspect of the enterprise."

Why Enterprise Architecture is Mission Impossible

“The business” does not exist, proclaims the author, and then goes on to show that this represents the major obstacle for successful enterprise architecture and mature IT.

You Can’t Buy Governance

This presentation discusses the importance of governance in delivering the results promised by service oriented architecture (SOA).




Posted on 05/27/2009 by


Giving “teeth” to the Building Permit Process author sourabhhajela

sourabhhajela




Signup For ThoughtLeader









Subscribe


CIO Index

Our Focus is On Your Agenda

CIO Index is the world's largest professional network for CIOs - of the CIO, for the CIO, by the CIO. 

Over 70,000 CIOs and other IT Executives use CIO Index to Learn, Network and Share.

 

Cioindex, Inc.

  • (+1) 800-309-3550
  • Mon - Fri 9:00am - 5:00 pm
  • 115 Franklin Tpke, Mahwah, NJ 07430