Information and communications technology is full of complexity, and professionals often suffer from difficulties in communicating with management, especially if managers have a non-technical background. There are many reasons for this, some the fault of the expert and some the fault of the manager.
Many are beyond the control of both. However, the expert should be doing more to reduce this problem, if only for self-interest. Likewise, the manager should be seeking a solution, but more so for the benefit of the enterprise.
A major contributor to the problem is the old maxim that the customer is always right. That may be a sufficient guideline in retailing, but it is over simplistic in the design and implementation of complex systems. Consider what it can lead to when, for example, an enterprise is about to re-design its corporate network or some other major enterprise-wide system. Each business unit and each IT stakeholder-unit states its requirements. Only too willing to please, management lulls those involved into a belief that all requirements can be delivered. Then the architecture is created, a plan is developed and the system is implemented. Eventually, it ends in disappointment because the system does not meet the expectations of one or more stakeholder-units. Failures of this type are predictable and can be avoided.
Systems architecting and systems engineering are disciplines that readily accept certain limitations in a client’s ability to specify requirements and a complex system’s ability to meet those requirements. However, some of the underlying principles are not well articulated or understood within IT environments. The first principle is that the original statement of a requirement or problem is not necessarily the best one. Second is that the project definition is complete only when the project team believes the system can be implemented to the clients’ satisfaction. These principles destroy the simple belief that the clients know best. Next we have an even less known, but important, principle. No complex system can be optimized while at the same time being optimum to each of its subsystems, each of its functions or each of its stakeholders. A system design that is good for the enterprise as a whole will not be the ideal system for each client.
Armed with this knowledge, it is much easier to sell the next principle, which is rarely invoked in practice. Obviously, each solution has advantages and disadvantages, but clients must be prepared to accept the disadvantages of the selected alternative, unless of course it has been forced on them. This means that delivering those disadvantages should not be viewed as failure, but part of the price paid for some of the advantages. The final principle is that cost, schedule and performance (or quality) are related: at least one of them must depend on the others. This seems obvious, but is conveniently forgotten when things go wrong without formal recognition of such dependencies up front by the manager and the client-groups.
Recognizing these principles is the first step in reducing the gaps that exist between expert and manager, and between both of them and their client-groups. Successfully implementing complex networks and systems within the enterprise is difficult enough, without the pain arising from ignorance of the above principles. It is up to experts and managers to spread the word and hopefully reduce the extent of unrealistic expectation associated with complex IT initiatives.
