Commitment of the Top Management
Every organization is driven by money. It is the money that counts. Some of the top managers/CEOs are more keen on grabbing a project and executing it without much concern for quality. This may bring in revenue in the short term, but the organization will not last long. The dotcom bubble that burst in the period of 2000-2001 can be attributed to this characteristic of money-greedy entrepreneurs who made quick buck through half-cooked project plans and exploiting the market conditions to generate revenue from the public money.
To develop and sustain a quality organization, the CEO and the top-level managers need to be committed to quality. This commitment is reflected by the following criteria:
> Impress upon each and every employee as well as the customers that quality is the
top most priority.
> Define detailed processes for the entire software development life cycle and
ensure that the processes are followed.
> Keep reviewing the processes to monitor their effectiveness and make changes as
and when necessary.
> Provide adequate resources for the process management and project management.
> Provide adequate training so that the people working on the projects are
competent to do the work.
> Take steps to continuously improve the processes and product quality.
> Introduce new technologies and new processes to meet the business objectives.
> Ensure that the customer’s expectations are met.
> Software organizations are people-driven, so take care of people.
In large organizations, the CEO or the top management cannot handle each and every aspect mentioned above. It is the project managers who need to implement the quality policies.
Types of Software Project Managers
There are varieties of software project managers. Some of them are technical, some are non-technical. The technical orientation of project manager does not really matter (though sometimes it helps). What is required is the right attitude and aptitude. In this section, we discuss various types of project managers. However, there is no fixed formula for success—success is guaranteed if the project manager can take his/her team along and is highly focused on meeting the objectives of the project.
Hands-off versus Hands-on Managers
Most of the hands-off managers are non-technical managers who took up software project management. Even the technical persons sometimes adapt the hands-off approach because of too many preoccupations. Only a handful of the managers sit with the
engineers and try to debug the software or at least suggest alternative approaches to solve a problem, particularly during the coding phase.
There are successful managers in both categories. The key to success is a good mix of process-orientation and people-orientation, not hands-off or hands-on. The important requirement is to ensure that the process is being followed and to motivate the team members and keep them in good spirits, particularly when the team is tense due to an approaching deadline.
The manager has to show professionalism in conducting the review meetings and if necessary obtain an external consultant to help him/her in technical aspects. The manager being technical helps sometimes as he/she can contribute directly, being non-technical is also not bad, as he/she can look at the software as a black box and analyze it from user’s point of view. However, a non-technical manager has to obtain the necessary technical support. When the manager does hands-off management, he/she needs to understand the process and ensure that the process is being adhered to.
Democratic versus Anarchic Managers
Some managers follow a democratic approach while handling the team members and some follow anarchic approach. To develop a congenial atmosphere in which the team members can give vent to their creative abilities, a democratic approach is the most ideal approach. However, one needs to be careful, freedom means responsibility, not carelessness. Given the freedom, some engineers mis-utilize it. A very common problem with most engineers is that they keep adding frills (unnecessary features to the software) because of the freedom given to them. This results in avoidable time delays. So, the project manager needs to give the necessary freedom, but at the same time, closely monitor the work so that time is not spent unproductively.
Proactive versus Reactive Managers
Reactive managers react to events. When an engineer comes and tells about a problem, he will try to resolve it. This approach is good when all the team members are self-driven and are highly communicative. If the manager informs at the beginning of the project that he would manage the project this way and all the engineers interact with the manager to resolve their individual or collective problems, then everything will go fine. However, every manager needs to remember that
• All the engineers are not self-driven nor they are highly communicative.
• Even if the engineers are self-driven and communicative, there is no guarantee
that everything is going fine, because inter-group problems may still remain.
Hence, it is dangerous to assume that no news is good news. Invariably, no news is bad news in software projects.
A proactive manager takes the initiative to find the status both informally and formally. Informally, during coffee breaks, lunch breaks or at social gatherings, he gets the different viewpoints of the team members on the status and uses this information to carry out formal reviews.
During formal review meetings, the manager reviews the project on all aspects, both technical and managerial. Review meetings can be conducted only to identify the problems and/or to resolve the issues. The formal review meetings have to be conducted in a professional environment—at a fixed time and with an agenda; and a record of the discussions with action points and responsibilities must be kept.
It is the proactive manager who will succeed in software projects. Software projects handled by reactive managers may succeed, but then they are miracles. We should not expect miracles to happen often.
Personnel Management
Effective management of the people is crucial for the success of the project. If the team members are committed to the project on hand and conscious of quality and time, the project would be a success. Most of the problems that arise in the software projects are because of the people.
The theories taught in personnel management do not necessarily work in software projects. Software development is a highly intellectual activity and managing the software engineers is certainly different from managing people on the shop floor of a production organization. Every individual has to be managed differently, based on his/her attitude, aptitude and cultural background. Some work under pressure, some do not. Some need constant monitoring, some do not. Some need an occasional jolt, some need an occasional reprimand. But everyone needs a few words of encouragement and an occasional pat for the good work.
Invariably, the technical people would prefer to have a technical person as a manager, not a non-technical or a business management expert. The project manager needs to have a good knowledge of the application domain which would greatly help in speedy execution of the project.
eliminate politics when a group of individuals work together as a team. The only alternative is to reduce the impact of the politics on the project. The project manager has to ensure that the progress of the project is not jeopardized due to politics. This requires knack, relations management tactics, and sometimes brute force (not physical but psychological).
What is Politics?
Politics is defined as “science and art of government”. The definition is surprising, because of the bad meaning we associate with politics—this is more due to the degraded behavior of the present day politicians.
When the project has to be governed and even if a project manager has the total responsibility and authority on all aspects of the project execution, opinions are bound to differ. Differing opinions have to be aired, discussed and the best approach is to be followed, in a democratic set up. If the project manager is anarchic, he can rule out all the possibilities and take the decision.
Even after accepting the authority of the project manager, some of the team members may not follow the instructions of the manager. This behavior may be due to many reasons—to disrespect the manager, to run a parallel government, to divide the group because of the dislike towards the project manager, to contribute to the failure of the project so that the manager can be projected in bad light… etc. That is bad politics.
The ill effects of politics may lead to differences of opinion, fights, strained relations, delays, cost overruns, and sometimes failed projects.
Why Politics?
There can be many reasons:
• The personal differences between individuals (other than technical).
• The strong opinions of the individuals which do not give scope for
arriving at a consensus resulting in rivalry (some people term it
professional rivalry).
• Due to the force from higher ups, the lower level team members are
forced to act in an abnormal way.
• Due to the inefficiency of the project manager.
• Some persons in the team, because of their personal idiosyncrasies, try
to become power centers by not sharing information and also not
cooperating with other team members (they may be good team players,
but with ulterior motives they behave differently).
Such reasons, more because of psychological problems of individuals, will have a bad impact on the smooth running of the projects. A strong manager would curb the politics
at the earliest. To identify the elements who are responsible for the politics early and to curb such behavior, or if the behavior cannot be curbed, to remove the individuals are to be done. Whatever be the strategy, curbing politics is a must.
Curbing Politics
The project manager has to curb politics to ensure that the ill effects do not affect the project at all. To turn a blind eye to the bad politics going on within the project team, would be very dangerous.
The project manager has to make it very clear at the beginning of the project itself that the team members should work in cohesion. He should clearly define the responsibilities and authorities of the individuals for technical and administrative matters. He should make it clear that playing bad politics which hampers the progress of the project would be taken seriously and the concerned individuals would be handled with a firm hand. The project manager should not hesitate to ’show the door’ to the person(s) indulging in bad politics.
Managing Inefficiency
In spite of the best efforts of the project manager, some of the team members may not perform as expected. This can be due to various reasons such as
• The manager is forced to take some persons who are not fit for the job
e.g., lack of the required skill in development tools, lack of application
domain knowledge etc. This may happen due to the obligation of the
higher management to give employment to some individuals.
• The person may be competent technically, but he/she is not a good
team player. This will be known only after the project takes off.
• Though all team members are good, they are unable to resolve issues
amicably resulting in fights and strained personal relations etc.
• Some people do unproductive work such as adding unnecessary frills
(as it happens in user interface implementations).
• Some persons give wrong projections and wrong information such as
on test results.
• Some persons do not communicate openly. Many times they know that
they will not meet the given deadline but they do not inform the
manager till the last minute.
• In spite of repeated reminders, many engineers do not maintain proper
documentation.
Perhaps the list will go on if we summarize the experiences of all the project managers. Now, can we call all these things as inefficiency? No. Then..
What is Inefficiency?
If a person is unable to do a specific job assigned to him, it cannot be termed as inefficiency. The manager has to probe as to why the job was not done. One possible reason can be that the person was not imparted the necessary training either in the application domain or in the software skills required.
Alternatively, the person is not efficient in doing a specific job because of his/her attitudinal problems such as
• Not taking initiatives.
• Lack of problem solving abilities and teamwork.
• Ego problems, which make him/her feel that what he/she is doing is
right.
• Indiscipline.
• Lack of hard work.
• Lack of time consciousness and spending time in unproductive things.
In the case where the person is not able to perform, we cannot brand it inefficiency. However, in other cases, a negative attitude towards colleagues and work can be branded as inefficiency.
Breeding inefficiency is dangerous as it affects slowly the performance of other people as well. To drive the people to perform at the top of their efficiency is the job of the manager. If inefficiency is tolerated, it is cancerous. The manager has to provide the necessary training, do periodic counseling, give warnings and if nothing works, relocate people.
Relocating People
Every person has strengths and weaknesses. An organization and the manager have to make use of the strengths and forget the weaknesses. But then, a manager can tolerate a person’s weaknesses to some extent. If these weaknesses start affecting the overall productivity of the team or set a bad example for other team members, it is high time the manager takes action to relocate the person to some other department where he/she can perform better.
Some of the programmers and engineers get into software development, by switching over from other fields. When they are tried out on their first project, they may be slow. A manager with patience may give a few more chances but if there is no improvement, it may be because the person is not suitable for software development at all. The manager has to relocate that person to another department depending on his inclination and interest or just to try out. He can be tried, for example, in software testing, or documentation, or marketing or customer support.
Well, if all that does not work out well, he has to be shown the door. Showing the Door: Right or Wrong?
Throughout the world, we hear a good number of stories of software engineers being laid down from work. The stories of software engineers being called on Monday and being told that the Friday would be their last working day are also not uncommon. And, it happens in small as well as large enterprises. Even highly profit making organizations do that. Is that right? Is that wrong? Certainly there are people who argue for and against it.
For totally business-driven organizations, retrenching people is not an emotional task. If the business does not require a certain number of people showing them the door is not a bad ‘business decision’ for them. And today, most of the organizations are business-driven.
The ‘Y2K’ is a glaring example. Organizations which were working on Y2K suddenly found that they have excessive manpower who cannot be relocated and put on other projects and very large number of people became suddenly unemployed. Is it justified? The management justifies its decision by saying that the engineers have no commitment, if they get $100 extra somewhere else, they are ready to jump out—when they are so business-minded, why not the management?
The fact remains that the people who worked for an organization with loyalty and contributed to the organization’s growth should not be left in the lurch suddenly. It is the management’s responsibility to plan ahead and ensure that the employees are relocated to other projects after necessary orientation. The People Capability Maturity Model (P-CMM) discussed later is essentially to avoid such unpleasant things, so that the management can work out a career plan for the employees and the employees can grow along with the organization.
Relations Management
Human relations are of utmost importance in the society, not the money nor the technology. Everyone has to remember that human relations are tenuous. A small unnecessary utterance can break a relation between two individuals, which took years to blossom. And relations are like a piece of glass, if it broken, it will never be the same even if it is repaired.
|
|
Relations within the Group
Software engineers have to work in a congenial atmosphere where each individual respects others’ opinions and decision-making is made either collectively or by a defined authority.
Consider a project which involves development of a web page. When the team sits for a design review, there will be many ideas as to the content and the layout of the web page. Discussions can go on for hours or days together without reaching a consensus. The team members, when they have to work against a deadline, cannot go on discussing but freeze the design (perhaps with a provision for expandability and modifications) and start the implementation. When people disagree on too many aspects, the project manager has to conclude and decide, by convincing all the people or using his/her authority. Once the decision is taken, all team members should abide by it rather than having a hard feeling that his/her excellent idea is turned down. The goal is the same but paths can differ, and everyone must have a give-and-take attitude.
The team members have to respect others’ strengths and look at the project as a team effort rather than a sum of individuals’ efforts. This approach would solve all the problems.
Human relations are complex and it is difficult to bring in harmony on all aspects but the manager has to train the team members to have a harmony at least when it comes to technical matters and to differentiate personal dislikes and technical dislikes.
Relations with Other Groups
Inter-group rivalry is not uncommon—between hardware group and software group; between development team and quality team; between test team and development team and so on. The most predominant rivalry is between hardware group and software group in projects which involve both hardware and software development. This needs to be sorted out by a process wherein the hardware testing is done separately, software testing is done separately and integration issues are sorted out by a defined testing process to isolate hardware and software problems.
To maintain cordial relations between the development group and other groups such as QA and test groups, process group, configuration management group, documentation group etc., is very important for the smooth execution of the project. Each group has to give a constructive criticism to the problems rather than a negative criticism. A test report by the test team that the user interface is ‘unfriendly’ does not serve any purpose. Instead, if the test group suggests a better navigation mechanism with a supportive argument as to why the suggested approach would be better, it will help in bringing out a better product. The project manager has to bring in this harmony between the groups using his/her interpersonal skills.
• The subcontractor selection should be done keeping in view the track
record and quality processes of the subcontractor.
• A periodic review is to be conducted to ensure that the development is
in progress as per the original plan.
• The subcontractor should have the openness to communicate in case
difficulties are encountered during project execution.
• The acceptance test procedures are made very clear during the early
stages of the project.
Communication is the most important element. If an open, frank communication path is established between the prime contractor and subcontractor, then everything will be fine and there will be no strained relations.
Expectations Management
To manage relations effectively, the expectations have to be managed effectively. The project manager has to gain expertise in the art of expectations management [B. Boehm, The Art of Expectations Management, IEEE Computer, Vol. 33, No. 1, January 2000]. Assume that the project manager is called and asked to give an estimate of time required for carrying out development of an e-commerce portal. Invariably, out of over-enthusiasm, the manager will say, “one month”. This is dangerous—estimation of time without even knowing the detailed requirements. The over-ambitious estimation is very common with most working level engineers who give unrealistic timelines for the development.
Another problem that is encountered is making a trade-off between the client’s expectations and what you perceive as a realistic target. If you feel that 4 months are required to complete a project and the client expects it in 1 month—how do you manage the expectations of the client? One possibility is to discuss with the client and promise a working prototype within one month and take another two months to refine the prototype and deliver the production model. The client feels he has won, and so do you feel! To achieve this win-win situation is the crux of expectations management. .
The problem encountered generally between the managers and the engineers is lack of open communication. The manager calls the engineer and ‘demands’ that the work should be finished in two days. The engineer, out of the fear to say no, will agree but does not meet the commitment. Invariably, most of the managers have a bad reputation for their inability to hear a ‘no’. The manager must create an atmosphere in the organization wherein the team members can openly express their fears and anticipated risks. This open communication is a must for good expectations management. More than the project managers, it is the CEOs who need to learn the art of hearing a no, and analyze the reasons for that no.
