There are many common hierarchies in software development organisations. These hierarchies can cause a dysfunctional working environment in which nobody will be able to work happily, cautions Dr R Srinivasan

While discussing the role of a project manager in a software development project, we have elaborated earlier that he should be responsible for three main areas like people, process and technology. In addition to this role in the project, he is also the main link between the project group and the senior management of the organisation.
It is possible that because of a tough hierarchical structure, the decisions are based on the preference of the senior executive, rather than on proven organisational models best suited to the size and maturity of the company. There is absolutely nothing wrong in having a hierarchical structure, it may also be a necessity, but such a structure should not impede the enthusiasm and efforts of a project manager. Will such a situation arise? The answer in the majority of cases is "definitely not!" On the other hand, if the hierarchies are based on personal relationships leading to favoured opinion, it would create an awkward situation where the need for frequent changes to the hierarchy will be warranted. Naturally this will deter the efforts of a project manager, which will have a direct impact on the productivity of the developers. In a nutshell, any organisation having a hierarchical structure that creates chaos in the management of the software development, gives rise to an antipattern called, 'Corporate Craziness'. Software guru Ed Yourdon, in his book Death March, warns that there are several common hierarchies in a software development organisation that can cause a dysfunctional work environment where nobody will be willing to work! William Brown, et al, bring out six such types of hierarchies.

A system with too many layers of hierarchy and where nothing can be decided unless we go through these layers of decision-makers is a typical Pyramid Hierarchy. Unfortunately, in a system like this, those at the lower layers will not take any decision unless approved by the one above, resulting in an inordinate and unwanted delay. This delay will definitely cut into the useful and productive time period of the developers down the line. Another case may be that there are too many managers compared to the number of developers----- a case of Inverse Pyramid Hierarchy. The confusion and the ultimate chaos that may happen in this case will be due to the point of wondering who will take the decision. It may happen that ultimately it has to go through many managers, a situation not different from the case of Pyramid Hierarchy. The third type is the one where we will see a flat management known as One-Dimensional Hierarchy. Because of the inherent informal atmosphere of shared responsibilities with no role differentiation, the decision-making is much more difficult than the other two cases. The fourth one is called Despot Hierarchy, where one person makes all the decisions. This is not only difficult but also dangerous in the area of software development that demands the attitude of balancing the tensions arising in technology, schedule slip-ups, adhering to quality aspects and above all instituting the motivation in developers.

In very rare cases, it may happen that a set of like-minded people join together in the management position for their own personal benefits and take charge of decision-making in the organisation and keep it to themselves. The classification of this type is known as Cabal Hierarchy and due to its lack of open and honest communication with others in the organisation, will be the real cause for the failure of a project. A frequent change in the management structure is also bad because each one will hesitate to take decisions because of insecurity. This is called Evolutionary Management and under this type the developers lose confidence in the management and they may decide to take decisions themselves.

To summarise in the words of William Brown: "Poorly organised management for the size and culture of the organisation is a singular cause of this antipattern". The refactored solution for this should be such that it takes care of all the bad structures that we discussed. Every organisation should have a well-planned and effective management structure with defined roles and responsibilities with respect to decision making. This is very clearly spelt under the standards like International Standard Organisation's ISO 9000 and Software Engineering Institute's Capability Maturity Model (SEI/CMM).

  ( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)