Does this scenario sound familiar?
Your software project is staffed with ten software engineers, exactly the number you have budgeted for the project and the team seems to be a good match of skill levels and experience. After six months you start to realize that the schedule was somewhat aggressive and your software team is working an average of 55 hours a week, but this team has started to build a rapport with all the time they're spending together. After nine months the team is working 60 hours a week and two people have quit because they see no end to the ridiculous schedules and overtime.
You start to think about maybe doing something to help team morale, but you're too busy fighting fires and explaining schedule slips to executive management. You notice that the rapport that the team had is not quite as good as you had anticipated and everyone seems to take longer to hit their stride every day. After twelve months you realize that your team is really over-worked and could use some help, fast, so you make some calls, hold some interviews and hire five crackerjack software consultants to pick up the slack. You tell your team to put them to work.
It has now been eighteen months. You have lost three more team
members and the only people who make it to the meetings are the
consultants you hired six months ago for a three month job. You're
schedule is still slipping and you decide it's really time to
institute that bonus plan that senior management suggested you
use as a last resort to put some spark back into the software
group. It has now been twenty-four months, two years, since the
start of the project. The ship date is today. A product is being
shipped, but it's not what you would have hoped for and definitely
not what the customer expects. The software team is now five permanent
employees and three contractors. The contractors are leaving in
a week and three of the five employees have requested assignments
elsewhere. Who's going to do maintenance?
This story, which is actually a summary of the last project that
I was involved in, provides some key problems that managers have
today with hiring and keeping a good software team. The description
above highlights the following problems:
The central question in how to improve the software art centers, as it always has, on people.[6] According to the P-CMM, organizations must focus on three interrelated components-people, process, and technology. This paper will focus on the people problems described in the introduction and possible solutions for the software project manager who finds himself faced with them.
While it is necessary to hire some software experts with very specific knowledge, e.g. compiler design, real-time embedded system development, etc., it is more beneficial to the company to hire software engineers with more than just technical expertise. Valuable employees also need good communication skills, good people skills, and the ability and willingness to expand their areas of expertise.
The company should also make it an objective to provide their
people with the opportunities to expand their knowledge base and
not keep the same people doing the same things. As Maguire wisely
states in [3] "When you train your team members, maximize
their value to the company by first training them in the most
widely useful skills and save the project-specific skills for
last." If an engineer is hired for a particular project and
his skills are not in wide use elsewhere in the company, what
will happen to that employee when the project is over? It is better
to make training or on-the-job experience available to him before
the project is over so that the transition to another project
will be much easier. This training and career development is a
necessary component of all progressive companies.
Software teams are required to work excessive amounts of overtime
to complete a project
Estimating the time required to complete a software project is one of the most discussed software project management problems. More software projects have gone awry for lack of calendar time than for all other reasons combined.[7] So it would follow that when those projects start to miss deadlines, software engineers would have to work longer and longer hours to try to get back on schedule. Additionally, corporate culture often perpetuates the idea that software teams can only be truly effective once they have "paid their dues", once they have "been in the trenches" of long hours. Maguire [1] uses the analogy of a sinking ship to demonstrate how this reasoning is not only incorrect, but counter-productive. If a ship is sinking at sea and the captain relentlessly drives the sailors to bail out the water, the ultimate result is that although there is a short period of initial improvement in the sinking, the sailors will eventually become too tired to bail and the ship will go down with everyone aboard. His alternative to bailing out the water is, very simply, to look for the leaks.
Overtime is often a symptom of a larger problem, not a solution and certainly not a way to build rapport among team members. Maguire's solution is also very simple, send every one home after eight hours. An alternative approach I would suggest would be to set a very short-term goal, something that is valid and can be reached within a two-week period. When that goal has been reached, then send everyone home. The idea that overtime is an all or nothing situation is harmful to a team's morale. Sending people home, or cutting overtime without allowing the team to see some kind of progress will only cause them to think about work while they are away from the office. If they reach a goal, and then are allowed some time off, they have more of a feeling of accomplishment. It takes a while to get people to the point where they are working 80 hour weeks and it should be a gradual process of reducing that time. In the mean time, while the engineers are getting their much needed time off, it's up to the software managers to find the leaks.
Overtime is also a product of the concept of "making up time".
If a software schedule is slipping, executive management will
turn up the heat in order to get the software team to make up
in one part of the schedule for lost time in another. And one
might think that if one part of the schedule was underestimated
it might be possible that another part of the schedule was overestimated.
Since software scheduling is still more of an art than a science
there is really no way to know if or how much slack there is in
any given schedule, but it is important to attempt to err on the
conservative side.
Only the minimum number of software personnel are assigned
to a project, usually an under-estimated number
It is a risk factor to staff a software project with exactly the budgeted number of engineers. This becomes more important as software project staffing is underestimated. Compounding this problem is the fact that highly-specialized engineers, in high demand in the marketplace, can leave the project at any time. A software project manager must always be aware of the value of the skills of his people. The demand for the latest new skill is always increasing and for most software engineers a new job is not hard to find. If your people are happy with what they are doing there is less of a chance that they will be lured away. Sometimes an engineer feels that the only way for him to feel challenged or to learn a new skill is to go elsewhere.
As a contingency plan for the above problems, the company should
always have candidates ready to be interviewed to replace engineers
who are leaving. Additionally, Curtis, Hefley and Miller[4] suggest
two ways to help ensure that staffing is not a problem. The first
is that project managers must aggressively seek out talent. This
helps guarantee a readily available pool of software talent. Their
second suggestion is to involve software developers in the selection
process, since their input may be the most insightful. It is also
a good idea, because they are members of the current software
team and can be helpful in selecting a candidate who would fit
well within the current structure.
Management only works on team morale after it has reached its
lowest point
Morale is one of the most important components for the successful completion of a software project. A manager should monitor the morale of the team as thoroughly as he monitors the schedule or budget. There seems to be a point of no return for morale that no matter what the company does after that point is reached, it will not satisfy the engineer.
The problem is that this point differs from engineer to engineer. As a manager you must be sensitive to the atmosphere that the team is creating. It is important to keep your eyes open for any aspect of the project lifecycle that has demoralizing effect on your team. Work to remove that irritant before it can cause any long-term damage.[2] The best way to do this is to keep the lines of communication open with your team members.
The other issue to keep in mind is immediate response. Don't assume
that a slump among more than three or four people is going to
just go away. When one or more of your people goes off course
or does a bad job, you must let them know it and take immediate
remedial action.[8] Team morale must be dealt with as quickly
as any other potential threat to schedule.
Software consultants are used ineffectively
Software consultants, or contractors have become one of the most
popular ways to supplement a diminishing team or to help with
a project that is behind schedule. The contractor, as with any
other resource available to the project manager, must be properly
used. The contractor can be a very valuable asset, but if not
used properly he can be a tremendous morale-destroyer. The following
guidelines can help when assigning contractors to a project:
Whenever a new employee is brought in to help with a project, that worker must be given appropriate training. Contractors are hired specifically because they already have the skills necessary to "hit the ground running" and make an immediate contribution to the project. It is important to have specific duties outlined for them. These duties should match the skills that the they bring to the project. Just as you should not hire a permanent employee without a clear idea of what that person will be working on and what is expected of him, a contractor should not just be brought in to help the team "make up time".
Contractors are also expensive. Since most contractors are paid for the number of hours they work, a project manager should monitor and regulate, if necessary, the hours which the contractor is charging to the project. There is an additional side-effect of contractor overtime. Nothing can be more harmful to employee morale than to spend hour after hour of unpaid overtime with a contractor who is being paid for those hours. The problem is not the contractor himself, but the age old problem of throwing people at a program that is behind or slowly falling behind schedule.
It is important also to access the role of the contractor in the
project. Contractors are not company personnel. They either work
for themselves or for another company. This is the view that other
software engineers have about them. Therefore, it is very demoralizing
for engineers to see contractors take lead roles in their
company. For this reason, contractors should never be given authority
over a permanent employee.
After initial completion of a project team members are not
given a clear view of their future
An issue often overlooked when a project approaches completion
is providing the team members with continuity. Should the team
be kept together? Will the engineer be given a lot of input regarding
his next assignment? Part of a project conclusion is planning
for the transition of the engineers to their next assignment.
If team members feel as though they are being discarded, it can
lower morale. When engineers reach the end of a project, they
feel as though they have done a lot for the company and they need
to feel that the company appreciates them. In some cases, people
require guidance at a transition. Engineers can become so identified
with a project that they need this guidance. It is a natural reaction
for team members to want to relax after a project or project phase
is completed, especially if that project was very difficult and
many hours were demanded to complete it. However, software engineers
need goals for the project and for their long-term career. The
company should provide these.
Conclusion
A jelled team is a group of people so strongly knit that the whole is greater than the sum of its parts… [5]. In the fast-paced world of software development creating and cultivating a talented group of software people is essential. Don't look just for engineers that have specific software skills. As important as these are, there are others equally important, such as interpersonal skills and the ability of an individual to work in groups. On the other hand, an engineer must be allowed and should be encouraged to progress in their technical fields of interest. Therefore, companies should also provide opportunities for engineers to expand their knowledge with programs such as on the job training.
Once engineers are selected for a team, it is important to watch their individual work schedules. Overtime is not a solution to a poorly planned schedule. Software engineering is a demanding science which cannot be properly performed by overworked team members. It is a project manager's duty to find the underlying problem, not simply to mask it with massive amounts of overtime. By the same token, contractors should not be used to "make up time".
Contractors can be a real asset if used correctly. They should be given well-planned, specific tasks. Their hours should be closely monitored and their roles within the team should be well-defined.
In addition to contractors, the company should always be on the lookout for new talent. It is a good idea to always have resumes on files with reviews and comments. Project managers must be prepared to quickly replace an engineer who has decided to go elsewhere or an engineer who is not working out.
Another personnel issue that must be dealt with quickly is team morale. Always monitor the team for morale decay that can not only hurt job performance but can also significantly affect schedule.
The project manager should be ready at the end of the project to help in the team's transition. Engineer should be rewarded for their effort in one project by being given guidance in their transition to the next.
The most crucial thing for a software project manager is to do his best to keep the team focused during schedule slips, reorganization and all of the other distractions in the company. By using your team members and contractors effectively and within reasonable working hours, and keeping on top of the general work atmosphere, the project manager can go a long way toward keeping his people from burning out before the end of the project and maybe actually ready to start the next one when the time comes.
Managers should take care of the software projects by taking care
of the software engineers. They are the ones who carry out the
projects. They are the companies true assets and the source of
future revenue. A team that is well cared for can accomplish a
project much easier than an overworked, burnt-out team. People
finish projects, they make things happen, and therefore, they
should not be considered a secondary issue in the company's success.
[1] Maguire, Steve. Debugging The Development Process,
Redmond, Washington: Microsoft Press, 1994.
[2] Curtis, Bill, Hefley, William E. and Miller, Sally. Overview
of the People Capability Maturity Model, SEI, 1995.
[3] Maguire, Steve. "Getting Your Team Off on the Right Foot."
Software Development, May 1997.
[4] Curtis, Bill, Hefley, William E. and Miller, Sally. "Making
It Personal." Software Development, May 1997.
[5] Demarco, Tom and Tim Lister. Peopleware. New York:
Dorset House, 1987.
[6] Brooks, F.P. "No Silver Bullet: Essence and Accidents
of Software Engineering." IEEE Computer 20, April
1987.
[7] Brooks, F.P. The Mythical Man-Month. Reading, Massachusetts:
Addison-Wesley Publishing Co., Inc.
[8] Schulmeyer, G.G. "The Net Negative Producing Programmer."
American Programmer, June 1992.
Annette Mirantes graduated from Purdue University in 1986 with a BSEE. After graduation she began working as a hardware/software field service engineer for Schlumberger-Fairchild-Weston. She moved into the Systems Software Department in 1987 to work on software design and development. In 1988 she went to work for Data Measurement Corporation and continued software development for real-time thickness measuring gauges. In 1990 she was offered the opportunity to work on remotely piloted vehicles for Vega Precision Laboratories. This work continued until 1992 when she went to work for Orbital Sciences Corporation on the ORBCOMM satellite project. There she was worked on the entire lifecycle of the project. After launch and on-orbit testing of the satellites, she spend a year as a contractor in the video-on-demand project for Bell Atlantic/Nynex. She has spent the last two years working on satellite programs again for Orbital Sciences and is currently working on the NASA Far Ultraviolet Spectroscopic Explorer (FUSE) satellite for Johns Hopkins University.