The Geometry of the Corporate IT Engagement Model

Part 1 – Century-Old Wisdom

If there’s one business where they’ve got their angles set right, it’s the construction industry. I am not referring to the fact the workers all carry carpenter’s squares in their tool boxes, but to their organized management of roles, responsibilities, and accountabilities*. I came to this realization a few years ago while digging through construction contractual agreements, governmental regulations, and professional order bylaws. The structure of stakeholders in the construction industry and their relationships can be summarized and abstracted as follows:

1. The customer (C). His responsibilities are to provide the requirements, supply the funding, and approve the specifications.
2. The architect (A). Her duty is to define what has to be built, based on the customer’s requirements, in compliance with codes and regulations. The customer hires the architect.
3. The builder (B). His job is to build the conception based on the architect’s specifications, while adhering to codes and regulations. The customer hires the builder.

 

The Three Poles Dance

In general, the ABC business model works fine, despite the following natural antagonisms that exist between these polarized roles:

1. The customer often knows exactly what needs to be done, and feels he could manage without the high-priced services of an architect. He also feels that the builder, especially if the chosen one was the lowest bidder, is trying to transform any unspecified detail into a change order and will do everything to get his profit back. The customer’s objective is to maximize his return on investment, whether it be sales, rent, property value, family happiness, or social pride.
2. The architect often has the impression that the customer changes his mind too often, doesn’t have the means for his ambitions, or is inaccessible when time comes to sign-off on blueprints. She is also convinced that the builder will cut corners to raise the profit margin, or consult directly with the customer and deviate from her specifications. The architect’s objective is to maximize customer satisfaction while remaining profitable, given the time spent on the project. The architect works in a market where reputation and past experience are crucial.
3. The builder is convinced that he knows how to build with or without the architect: an extraneous player who often can’t drive a nail into a 2X4. He also believes that customers take advantage of him by constantly requesting incidental extra work while remaining resistant to official change orders. The builder’s objective is to remain profitable by maximizing effectiveness, minimizing rework, and optimizing material usage. The builder operates in a highly standardized and competitive market where price is the main differentiator.

Fences Around the Construction Playground

The polarized roles described above could lead to discord or confrontation. But the construction industry, through centuries of feuds and casualties, has developed a series of safeguards to control the behavior of the stakeholders. The main defenses against misconduct are:

• Building codes that define standards required to ensure minimum levels of quality and safety.
• Town planning departments that provide additional guidance regarding building sites, optimized use of shared infrastructures, and development expectations of community residents.
• Constituency construction inspectors who independently examine the project’s compliance with the approved plans, building codes, and local regulations.
• Trades certifications that legally enforce safe standards of practice for builders.
• Professional orders that endorse the right to practice for architects and engineers, define a code of conduct and manage alleged or confirmed misbehaviors.
• Duly voted laws and published regulations that legally enforce all of the above, from building code compliance to the letters patent of professional orders.

All of these safeguards have the obvious objective to protect the customer and the public in general.

When Things Go Awry, Roles Are Never Questioned

The construction industry has a pretty heavy legacy of issues that often finish in courts of law. These range from petty misunderstandings to serious worksite casualties and building collapses. As in any other business, when things go awry in construction, fingers point in all directions until guilt is determined and restitution is achieved.

But in such cases there is one thing that is never questioned: the engagement model and the respective duties of the three roles. The customer owns, pays, and approves. The architect understands, designs, and complies. The builder constructs and complies. Each stakeholder knows what the other has to do, and can recognize when another steps out-of-bounds. These crystal clear roles leave little space for interpretation, and are often textually described in contracts.

Century-Old Wisdom

Houses are buildings, but a software-based business application is not a building. Corporate IT is a very different business than the civil construction industry; processes, tools and, most importantly, the base matter to work from are worlds apart. I nevertheless strongly believe that corporate IT could benefit from focusing on the applicable similarities rather than technical differences with this model from another field. Centuries of trial and error have yielded highly reusable practices:

1. Clearly delineated roles that minimize misunderstandings and quickly expose conflicts.
2. Defined standards, which are understood by all.
3. Independent bodies that control compliance of the work.
4. Incentives and penalties that are directly linked to responsibilities.

In corporate IT, these four elements are either absent, neglected, or ill-defined.  In my opinion, these deficiencies can be traced to the engagement model used internally for corporate IT. And this is the subject of the second part of this article.

———————————————–

* For a deeper dive into the construction industry, its structure, and the wisdom it can impart, I invite you to read my book, Volume 1 of An Executive Guide to the New Age of Corporate IT.  This article is in fact an elevator pitch for Chapter 1.