Why Managers Admire Ambiguity

Any Architecture is based on answers to five core question: WHY, WHAT, WHO/WHOM-FOR, WHERE, and WHEN. Any architecture comprises models and structures that detail the answers. If any answer to aforementioned questions is vague it becomes apparent immediately because it brings uncertainty and can lead to multiple versions of architecture with no criteria for comparison.

Answers to architectural questions have clearly defined relationships. If the clarity is absent, the architecture becomes vague and unstable again. Do you want to live in unstable building?

As Terry Roach said, “However many managers don’t want these relationships to be explicitly identified and are horrified by the possibility that [anybody] could establish hard and fast mechanisms for measuring performance and aligning operational results with the achievement of strategic goals”. I wrote about the same factors on many occasions but here, let me comment on Terry’s statement. Particularly, “establish hard and fast mechanisms” means to me that answer to the WHY-WHEN questions about the adherence to the strategic goals should be done in three variants only: ‘in line with the goal’, ‘not in line with the goal’, and ‘partially in line with the goal’. If the answer is the latter, it means that the results delivered by the manager are partially not in line with the goal, and this manager has to explain why that has happened.

Moreover, a measurement of the results against the strategic goal has to be fast in order to catch the manager in his/her position (before his/her next career move) and make really responsible for the provided results. If the managers know that they will “wear the shoes they made”, many of them will think twice what they deliver “on time and in budget”.

At the  beginning of this year, I published an article “Purpose Case Management”. I argued there that business management must verify each step of a business process or each decision of the case against the overall business task and not only against the task set for this particular management action. Over the time, the overall task can change because of external conditions and proceeding with the goal, which was set before that change, makes no good to the company except creating new problems. But we can adjust our management decisions only if we exactly know where we are.

Ambiguity saves managers in measuring their results against their responsibilities and accountability. Yes, we all human, we can make mistakes, have to consider resources and changes we cannot control. However, what we do, not say, is very concrete: a building cannot stay on a half-complete base and philosophy of a “half-full glass of water” (vs. a half-empty) does not help the building. If we start building based on something half-complete, our next constriction will complete even less than half and, to fix it, we shortcut the architecture, design and Best Practice for the sake of delivery. But is this delivery what we need?

Corporate IT is one of the most illustrative examples of this process of degradation. Obviously, with limited resources, IT cannot deliver to all business requirements in all cases. So, IT has created a theory of agility that uses MoSCoW – a system of prioritisation of requirements and somehow adopted an approach that only “must have” requirements are realised. Thus, in each IT project, business gets a handicapped solutions and sooner or later starts suffering from it. At the same time, IT deviates from the real business needs more and more because ambiguous words replace concrete deliveries. Well, many of the business requirements may be not correct requirements for a particular project, but it is a different story.

Agility between IT and Business in the an enterprise will materialise what management ambiguity gets away. If a business does not know what it wants, it is better not to do anything. If a business requester (manager) is made financially responsible for specified requirements and received results, believe me, we will see very few but very consistent requirements as to the business teams as to IT; in this case, IT resources may appear sufficient and outsourcing and even Clouds will be not that necessary.