Travails of an ‘irrational’ project manager

When a project manager lacks in-depth technical knowledge, he disregards the views of other talented team members. The project finally suffers and gets driven to irrational directions, warns Dr R Srinivasan.

The project manager should allow the problems to be resolved by others and step in only when it is necessary

The most important requirement in a software development organisation is the selection of the project manager who has the necessary skills and experience in three vital aspects, that is, management of people, process and technology. Unfortunately, in some cases, an organisation may not be able to find a person with in-depth knowledge of technology, but has good experience in the other two aspects. This is where problems arise, bringing forth another type of antipatttern, called ‘Irrational Management’. This may occur because of the manager’s skewed and self-assessed judgement on his technical competence.

The manager, under this situation, will try to impose his own priorities without taking the views of other managers or his team members, as a result of which the project suffers and gets driven to irrational directions. Under this critical situation, the decisions become more confusing and the ultimate reactions will result in more problems.

This type of antipattern will result in the manager being called an Irrational Project Manager. He will not be able to guide and direct the members of the team and hence start losing their confidence. Consequently, he exposes his inability to take care of the other important aspect mentioned earlier—people management skills. Because of his wrong vision and direction in the area of technology also, he will not be able to manage the development processes of the project either. Lack of clear vision and appropriate strategy will also lead to the antipattern discussed last week, viz., Fear of Success.

Experts in the software development advocate clear steps and guidelines to find a refactored solution for this type of antipattern.

It is absolutely essential that a manager should realise that there is a problem and recognise the key indicators. One of this is when the manager informs the problem to the team only when it reaches a critical phase, rather than bringing it out at the initial stage. The correct step for the manager would be to disclose the problem to the talented people in the organisation, or if necessary to get the help of external consultants who might be able to solve it. Furthermore, this type of manager does not recognise that there are talented and knowledgeable people in the team. It is absolutely essential for a manager to delegate some responsibilities to such members so that not only his burden will be reduced but also boost the morale of the team. As part of project execution, a vital point will be that the manager spells out the short-term and long-term objectives of the project so that he/she will be able to bring in a concentrated focus towards the objectives in the team. In many cases, either because of the urgent need of the customer or slippages in efforts and schedule, the manager resorts to skipping the processes involved in development.

A project team involved in software development should be a clear example of a democratic set up in the sense that it should be an open system with everyone having the freedom to voice their suggestions in team meetings. The manager should encourage this while he is keenly observing the proceedings. As Kenneth Blanchard says in his book, One Minute Manager with the Monkey, the project manager should allow the problems to be resolved by others and step in only when it is necessary. If this is not done, as Blanchard says, the monkey in the form of the problem will jump on to the shoulders of the manager and free everybody else from it.

Taking the proper decision in a project under crisis is a very important factor in software development. Kepner and Tregoe in their book, The New Rational Manager, illustrate two rational management techniques in software decision making. The first, known as situation analysis, aims to assist in the situation where the management gets into unstructured and chaotic environments. The second is decision analysis, which illustrates methods for making decisions objectively because, as they say, subjective biases in decision-making will lead to software disasters.

(To be continued) (The author is Chief Technology Officer, iCMG, Bangalore. He can be contacted at r.srinivasan@icmg.nu)