| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
2. PROJECT PERSONNEL To determine the project schedule and estimate the associated effort and costs, we need to know approximately how many people will be working on the project, what tasks they will perform, and what abilities and experience they must have so they can do their jobs effectively. In this section, we look at how to decide who does what and how the staff can be organized. Staff Roles and Characteristics In Section 2, we examined several software process models, each depicting the way in which the several activities of software development are related. No matter the model, there are certain activities necessary to any software project. For example, every project requires people to interact with the customers to determine what they want and by when they want it. Other project personnel design the system, and still others write or test the programs. Key project activities are likely to include 1. requirements analysis 2. system design 3. program design 4. program implementation 5. testing 6. training 7. maintenance 8. quality assurance However, not every task is performed by the same person or group; the assignment of staff to tasks depends on project size, staff expertise, and staff experience. There is great advantage in assigning different responsibilities to different sets of people, offering "checks and balances" that can identify faults early in the development process. For example, suppose the test team is separate from those who design and code the system. Testing new or modified software involves a system test, where the developers demonstrate to the customer that the system works as specified. The test team must define and document the way in which this test will be conducted and the criteria for linking the demonstrated functionality and performance characteristics to the requirements specified by the customer. The test team can generate its test plan from the requirements documents without knowing how the internal pieces of the system are put together. Because the test team has no preconceptions about how the hardware and software will work, it can concentrate on system functionality. This approach makes it easier for the test team to catch errors and omissions made by the designers or programmers. It is in part for this reason that the clean room method is organized to use an independent test team, as we will see in later sections (Mills, Dyer, and Linger 1987). For similar reasons, it is useful for program designers to be different from system designers. Program designers become deeply involved with the details of the code, and they sometimes neglect the larger picture of how the system should work. We will see in later sections that techniques such as walkthroughs, inspections, and reviews can bring the two types of designers together to double-check the design before it goes on to be coded, as well as to provide continuity in the development process. We saw in Section 1 that there are many other roles for personnel on the development or maintenance team. As we study each of the major tasks of development in subsequent sections, we will describe the project team members who perform those tasks. Once we have decided on the roles of project team members, we must decide which kinds of people we need in each role. Project personnel may differ in many ways, and it is not enough to say that a project needs an analyst, two designers, and five programmers, for example. Two people with the same job title may differ in at least one of the following ways: ability to perform the work
Each of these characteristics can affect an individual's ability to perform productively. These variations help to explain why one programmer can write a particular routine in a day, whereas another requires a week. The differences can be critical, not only to schedule estimation, but also to the success of the project. To understand each worker's performance, we must know his or her ability to perform the work at hand. Some are good at viewing "the big picture," but may not enjoy focusing on detail if asked to work on a small part of a large project. Such people may be better suited to system design or testing than to program design or coding. Sometimes, ability is related to comfort. In classes or on projects, you may have worked with people who are more comfortable programming in one language than another. Indeed, some developers feel more confident about their design abilities than their coding prowess. This feeling of comfort is important; people are usually more productive when they have confidence in their ability to perform. Interest in the work can also determine someone's success on a project. Although very good at doing a particular job, an employee may be more interested in trying something new than in repeating something done many times before. Thus, the novelty of the work is sometimes a factor in generating interest in it. On the other hand, there are always people who prefer doing what they know and do best, rather than venturing into new territory. It is important that whoever is chosen for a task be excited about performing it, no matter what the reason. Given equal ability and interest, two people may still differ in the amount of experience or training they have had with similar applications, tools or technique& The per son who has already been successful at using C to write a communications controller is more likely to write another communications controller in C faster (but not necessarily more clearly or efficiently) than someone who has neither experience with C nor knowledge of what a communications controller does. Thus selection of project personnel involves not only individual ability and skill, but also experience and training. On every software development or maintenance project, members of the development team communicate with one another, with users, and with the customer. The project's progress is affected not only by the degree of communication, but also by the ability of individuals to communicate their ideas. Software failures can result from a breakdown in communication and understanding, so the number of people who need to communicate with one another can affect the quality of the resulting product. FIG. 9 shows us how quickly the lines of communication can grow. Increasing a work team from two to three people triples the number of possible lines of communication. In general, if a project has n workers, then there are n(n - 1)/2 pairs of people who might need to communicate, and 2^n - 1 possible teams that can be created to work on smaller pieces of the project. Thus, a project involving only 10 people can use 45 lines of communication, and there are 1023 possible committees or teams that can be formed to handle subsystem development! Many projects involve several people who must share responsibility for completing one or more activities. Those working on one aspect of project development must trust other team members to do their parts. In classes, you are usually in total control of the projects you do. You begin with the requirements (usually prescribed by your instructor), design a solution to the problem, outline the code, write the actual lines of code, and test the resulting programs. However, when working in a team, either in school or for an employer or customer, you must be able to share the workload. Not only does this require verbal communication of ideas and results, but it also requires written documentation of what you plan to do and what you have done. You must accept the results of others without redoing their work. Many people have difficulty in sharing control in this way. Control is an issue in managing the project, too. Some people are good at directing the work of others. This aspect of personnel interaction is also related to the com fort people feel with the jobs they have. Those who feel uncomfortable with the idea of pushing their colleagues to stay on schedule, to document their code, or to meet with the customer are not good candidates for development jobs involving the management of other workers. Thus, several aspects of a worker's background can affect the quality of the project team. A project manager should know each person's interests and abilities when choosing who will work together. SIDEBAR 1 explains how meetings and their organization can enhance or impede project progress. As we will see later in this section, employee background and communication can also have dramatic effects on the project's cost and schedule. ============= SIDEBAR 1 MAKE MEETINGS ENHANCE PROJECT PROGRESS Some of the communication on a software project takes place in meetings, either in person or as teleconferences or electronic conversations. However, meetings may take up a great deal of time without accomplishing much. Dressler (1995} tells us that "running bad meetings . can be expensive . . . a meeting of eight people who earn $40,000 a year could cost $320 an hour, including salary and benefit costs. That's nearly $6 a minute." Common complaints about meetings include: The purpose of the meeting is unclear. The attendees are unprepared. Essential people are absent or late. The conversation veers away from its purpose. Some meeting participants do not discuss substantive issues. Instead, they argue, dominate the conversation, or do not participate. Decisions made at the meeting are never enacted afterward. Good project management involves planning all software development activities, including meetings. There are several ways to ensure that a meeting is productive. First, the manager should make clear to others on the project team who should be at the meeting, when it will start and end, and what the meeting will accomplish. Second, every meeting should have a written agenda, distributed in advance if possible. Third, someone should take responsibility for keeping discussion on track and for resolving conflicts. Fourth, someone should be responsible for ensuring that each action item decided at the meeting is actually put into practice. Most importantly, minimize the number of meetings, as well as the number of people who must attend them. ============= Work Styles Different people have different preferred styles for interacting with others on the job and for understanding problems that arise in the course of their work. For example, you may prefer to do a detailed analysis of all possible information before making a decision, whereas your colleague may rely on "gut feeling" for most of his important decisions. You can think of your preferred work style in terms of two components: the way in which your thoughts are communicated and ideas gathered, and the degree to which your emotions affect decision making. When communicating ideas, some people tell others their thoughts, and some people ask for suggestions from others before forming an opinion. Jung (1959) calls the former extroverts and the latter introverts. Clearly, your communication style affects the way you interact with others on a project. Similarly, intuitive people base their decisions on feelings about and emotional reactions to a problem. Others are rational, deciding primarily by examining the facts and carefully considering all options. We can describe the variety of work styles by considering the graph of FIG. 10, where communication style forms the horizontal axis and decision style the vertical one. The more extroverted you are, the farther to the right your work style falls on the graph. Similarly, the more emotions play a part in your decisions, the higher up you go. Thus, we can define four basic work styles, corresponding to the four quadrants of the graph. The rational extroverts tend to assert their ideas and not let "gut feeling" affect their decision making. They tell their colleagues what they want them to know, but they rarely ask for more information before doing so. When reasoning, they rely on logic, not emotion. The rational introverts also avoid emotional decisions, but they are willing to take time to consider all possible courses of action. Rational introverts are information gatherers; they do not feel comfortable making a decision unless they are convinced that all the facts are at hand.
In contrast, intuitive extroverts base many decisions on emotional reactions, tending to want to tell others about them rather than ask for input. They use their intuition to be creative, and they often suggest unusual approaches to solving a problem. The intuitive introvert is creative, too, but applies creativity only after having gathered sufficient information on which to base a decision. Winston Churchill was an intuitive introvert; when he wanted to learn about an issue, he read every bit of material avail able that addressed it. He often made his decisions based on how he felt about what he had learned ( Manchester 1983). To see how work styles affect interactions on a project, consider several typical staff profiles. Kai, a rational extrovert, judges her colleagues by the results they pro duce. When making a decision, her top priority is efficiency. Thus, she wants to know only the bottom line. She examines her options and their probable effects, but she does not need to see documents or hear explanations supporting each option. If her time is wasted or her efficiency is hampered in some way, she asserts her authority to regain control of the situation. Thus, Kai is good at making sound decisions quickly. Marcel, a rational introvert, is very different from his colleague Kai. He judges his peers by how busy they are, and he has little tolerance for those who appear not to be working hard all the time. He is a good worker, admired for the energy he devotes to his work. His reputation as a good worker is very important to him, and he prides himself on being accurate and thorough. He does not like to make decisions without complete information. When asked to make a presentation, Marcel does so only after gathering all relevant information on the subject. Marcel shares an office with David, an intuitive extrovert. Whereas Marcel will not make a decision without complete knowledge of the situation, David prefers to follow his feelings. Often, he will trust his intuition about a problem, basing his decision on professional judgment rather than a slow, careful analysis of the information at hand. Since he is assertive, David tends to tell the others on his project about his new ideas. He is creative, and he enjoys when others recognize his ideas. David likes to work in an environment where there is a great deal of interaction among the staff members. Ying, an intuitive introvert, also thrives on her colleagues' attention. She is sensitive and aware of her emotional reactions to people and problems; it is very important that she be liked by her peers. Because she is a good listener, Ying is the project member to whom others turn to express their feelings. Ying takes a lot of time to make a decision, not only because she needs complete information, but also because she wants to make the right decision. She is sensitive to what others think about her ability and ideas. She analyzes situations much as Marcel does, but with a different focus; Marcel looks at all the facts and figures, but Ying examines relational dependencies and emotional involvements, too. Clearly, not everyone fits neatly into one of the four categories. Different people have different tendencies, and we can use the framework of FIG. 10 to describe those tendencies and preferences. Communication is critical to project success, and work style determines communication style. For example, if you are responsible for a part of the project that is behind schedule, Kai and David are likely to tell you when your work must be ready. David may offer several ideas to get the work back on track, and Kai will give you a new schedule to follow. However, Marcel and Ying will probably ask when the results will be ready. Marcel, in analyzing his options, will want to know why it is not ready; Ying will ask if there is anything she can do to help. Understanding work styles can help you to be flexible in your approach to other project team members and to customers and users. In particular, work styles give you information about the priorities of others. If a colleague's priorities and interests are different from yours, you can present information to her in terms of what she deems important. For example, suppose Claude is your customer and you are preparing a presentation for him on the status of the project. If Claude is an introvert, you know that he prefers gathering information to giving it. Thus, you may organize your presentation so that it tells him a great deal about how the project is structured and how it is progressing. However, if Claude is an extrovert, you can include questions to allow him to tell you what he wants or needs. Similarly, if Claude is intuitive, you can take advantage of his creativity by soliciting new ideas from him; if he is rational, your presentation can include facts or figures rather than judgments or feelings. Thus, work styles affect interactions among customers, developers, and users. Work styles can also involve choice of worker for a given task. For instance, intuitive employees may prefer design and development (requiring new ideas) to maintenance programming and design (requiring attention to detail and analysis of complex results). Project Organization Software development and maintenance project teams do not consist of people working independently or without coordination. Instead, team members are organized in ways that enhance the swift completion of quality products. The choice of an appropriate structure for your project depends on several things:
Good project managers are aware of these issues, and they seek team members who are flexible enough to interact with all players, regardless of work style. One popular organizational structure is the chief programmer team, first used at IBM (Baker 1972). On a chief programmer team, one person is totally responsible for a system's design and development. All other team members report to the chief programmer, who has the final say on every decision. The chief programmer supervises all others, designs all programs, and assigns the code development to the other team members. Assisting the chief is an understudy, whose principal job is substituting for the chief programmer when necessary. A librarian assists the team, responsible for maintaining all project documentation. The librarian also compiles and links the code, and performs preliminary testing of all modules submitted to the library. This division of labor allows the programmers to focus on what they do best: programming.
The organization of the chief programmer team is illustrated in FIG. 11. By placing all responsibility for all decisions with the chief programmer, the team structure minimizes the amount of communication needed during the project. Each team member must communicate often with the chief, but not necessarily with other team members. Thus, if the team consists of n - 1 programmers plus the chief, the team can establish only n - 1 paths of communication (one path for each team member's interaction with the chief) out of a potential n(n - 1)/2 paths. For example, rather than working out a problem themselves, the programmers can simply approach the chief for an answer. Similarly, the chief reviews all design and code, removing the need for peer reviews. Although a chief programmer team is a hierarchy, groups of workers may be formed to accomplish a specialized task. For instance, one or more team members may form an administrative group to provide a status report on the project's current cost and schedule. Clearly, the chief programmer must be good at making decisions quickly, so the chief is likely to be an extrovert. However, if most of the team members are introverts, the chief programmer team may not be the best structure for the project. An alternative based on the idea of "egoless" programming, as described by Weinberg (1971). Instead of a single point of responsibility, an egoless approach holds everyone equally responsible. Moreover, the process is separated from the individuals; criticism is made of the product or the result, not the people involved. The egoless team structure is democratic, and all team members vote on a decision, whether it concerns design considerations or testing techniques. Of course, there are many other ways to organize a development or maintenance project, and the two described above represent extremes. Which structure is preferable? The more people on the project, the more need there is for a formal structure. Certainly, a development team with only three or four members does not always need an elaborate organizational structure. However, a team of several dozen workers must have a well defined organization. In fact, your company or your customer may impose a structure on the development team, based on past success, on the need to track progress in a certain way, or on the desire to minimize points of contact. For example, your customer may insist that the test team be totally independent of program design and development. Researchers continue to investigate how project team structure affects the resulting product and how to choose the most appropriate organization in a given situation. A National Science Foundation (1983) investigation found that projects with a high degree of certainty, stability, uniformity, and repetition can be accomplished more effectively by a hierarchical organizational structure such as the chief programmer team. These projects require little communication among project members, so they are well-suited to an organization that stresses rules, specialization, formality, and a clear definition of organizational hierarchy. TABLE 5 Comparison of Organizational Structures Highly Structured Loosely Structured High certainty Uncertainty Repetition New techniques or technology Large projects Small projects On the other hand, when there is much uncertainty involved in a project, a more democratic approach may be better. For example, if the requirements may change as development proceeds, the project has a degree of uncertainty. Likewise, suppose your customer is building a new piece of hardware to interface with a system; if the exact specification of the hardware is not yet known, then the level of uncertainty is high. Here, participation in decision making, a loosely defined hierarchy, and the encouragement of open communication can be effective. TABLE 5 summarizes the characteristics of projects and the suggested organizational structure to address them. A large project with high certainty and repetition probably needs a highly structured organization, whereas a small project with new techniques and a high degree of certainty needs a looser structure. SIDEBAR 2 describes the need to balance structure with creativity. ============ SIDEBAR 2 STRUCTURE VS. CREATIVITY Kwide (1997) reports the results of experiments by Sally Philipp, a developer of software training materials. When Philipp teaches a management seminar, she divides her class into two groups. Each group is assigned the same task: to build a hotel with construction paper and glue. Some teams are structured, and the team members have clearly defined responsibilities. Others are left alone, given no direction or structure other than to build the hotel. Philipp claims that the results are always the same. "The unstructured teams always do incredibly creative, multistoried Taj Mahals and never complete one on time. The structured teams do a Day's Inn [a bland but functional small hotel], but they're finished and putting chairs around the pool when I call time," she says. One way she places structure on a team is by encouraging team members to set dead lines. The overall task is broken into small subtasks, and individual team members are responsible for time estimates. The deadlines help to prevent "scope creep," the injection of unnecessary functionality into a product. The experts in Kunde's article claim that good project management means finding a balance between structure and creativity. Left to their own devices, the software developers will focus only on functionality and creativity, disregarding deadlines and the scope of the specification. Many software project management experts made similar claims. Unfortunately, much of this information is based on anecdote, not on solid empirical investigation. ============ |
