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:
- The architecture review committee does not have adequate authority
- They are more discussion forums than decision making bodies
- The process lacks metrics and accountability
- The process does not connect with other critical processes
- Pre meeting preparation is also minimal
- Note taking is minimal. Subsequent distribution is rare
- 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's 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 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 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 his consulting firm.