Chapter 1 | Chapter 2 |Chapter 3 | Chapter 4
Administrative tasks, group dynamics, and project management are all general group tasks that must be established and maintained for the duration of the project. As a result, stability and continuity can be maintained, though group issues and goals should be open to discussion, and possible revision, at any time.
1.1 Group Organization
There are numerous types of group organizations, but I will limit the discussion to three. The three types of group organization are the Chief Programming Team, the Egoless Programming Team, and the Administrative Programming Team. Each team organization has its own advantages and disadvantages that can be analyzed in regard to the project at hand.
1.1.1 Chief Programmer Team
The objectives of the Chief Programmer Team (CPT) are to provide a high degree of formalization within a strict organizational structure, clear leadership through the chief programmer, and the possibility of specialization through formational separation. The reporting structure, the relationships between team members, and job functions are strict defined. A rigid hierarchical structure facilitates management control, visibility of product and personnel, communication, and product structure. The chief programmer and the backup programmer are familiar with every aspect of the project, which provides continuity. The CPT roles are that of: chief programmer, backup programmer, programming secretary, junior programmers, and an optional project administrator.
The Chief Programmer (CP) is one of the technical experts, and the undisputed leader of the team. Since the chief programmer is the leader, he/she is answerable for the team's success or failure. In addition, all of the initial design documents (the requirement specification document and the design document) are to be developed by the chief programmer. The coding and testing of critical parts of the system is also his/her responsibility. Lastly, the chief programmer closely guides and supervises the other team members. Needless to say, considerable technical expertise and management experience (or ambition) are necessary. Specifically, management skills include people skills, the ability to plan and control the execution of a plan, setting realistic goals and priorities, assigning tasks, and evaluating and reporting progress to upper-management.
The Backup Programmer (BP) is the backup leader and peer to the chief programmer. This person must be totally familiar with the project to be able to take over leadership when necessary and to participate in all important technical decisions. Responsibilities of the backup programmer are to conduct research for the chief programmer and the test plan. Since the backup programmer has the secondary leadership role to that of the chief programmer, he/she does not have the decision-making power, but must be prepared to take over leadership and make any necessary decisions should the case arise. Because of this, the backup programmer has to possess the same technical and managerial skills as the chief programmer does.
The Programming Secretary (PS) is responsible for keeping all documents current and accessible to the team, maintains the libraries, test data, test results, and all project documentation. Skills necessary for this role are technical writing, programming (not to the extent that the JP's possess), file management, knowledge of support tools, and communication.
The Junior Programmers (JP) implement the code according to the chief programmer's directives. Skills necessary for this role are time management and programming. Communication skills are not a rigid requirement, since the design specifications will be presented to the JP and communication is only conducted with the chief programmer.
The Project Administrator (PA) takes over some of the chief programmer's administrative tasks, such as scheduling tasks. This role is optional. Skills that the project administrator should posses are management skills like those outlined for the chief programmer.
The communication structure of the Chief Programmer Team is that of a wheel (see Figure 1). The chief programmer resides at the center of the wheel, which reflects the structural leadership of the team. All peripheral positions communicate directly with the chief programmer, and any communication amongst the peripheral positions are approved by the chief programmer to insure CP control and continuity. Problems with the wheel structure, are the possibility of overwhelming the chief programmer and the under utilization and dissatisfaction of the peripheral positions.
Overall, this communication structure changes during the various project phases. For example, during the design phase the junior programmers are unnecessary and are omitted from the general CPT communication network (see Figure 2).
During the implementation phase, the communication phase looks like the general wheel structure (see Figure 1). However, when the testing phase in initiated the communication structure changes once again to reflect the role of the backup programmer as testing director (see Figure 3).
Advantages of the Chief Programmer Team organization are that specialization is utilized, the leadership is strictly defined and continuous, and there is strict control over the project. In addition, no conflicts arise due to an ambiguous reporting structure or conflicting goals and directives set by several people. The CPT is good for a project with a limited scope, that has a hierarchical structure that can be partitioned into modules that fit the group managers skill levels. This structure is also advantageous for large teams projects, and they do occur in some classes. In one of my undergraduate class projects, the entire class was one team working on one project. The first thing we did was to take inventory of skills and experience (and initiative), then we divided into units. Some of the units corresponded to those described here.
Disadvantages of the Chief Programmer Team are the wheel communication structure that can either overwhelm the chief programmer, the under utilization and dissatisfaction of the other roles due to the lack of professional growth, and potential role clashes between the chief and backup programmer since both have similar skills and leadership ambition. Also, the chief programmer has a lot of power and this could bring out the worst in the CP.
What place does the Chief Programmer Team have in a student project? Well you may find some facets of CPT useful to your group. The CPT offers structure where there is no structure, and some people work well with structure. The first couple of class meetings after teams have been assigned can be chaotic and awkward. While you may not want some of the rigidity of CPT's structure, the defined roles as determined by the experience and skill of group members can be useful in forming a team rather than just a group of people assigned to do a project together. When your group is initially formed, you must acquaint yourself with the experience and skills of each of your teammates and the CPT structure can give the team some place to start. As a team, roles can be assigned as described above. For example, a senior generally has more experience and insight than a sophomore or junior and that senior member of the team may be assigned the role of the Chief Programmer or a similar role. Also, the less experienced members of the team may take the role of Junior Programmers. Assigning roles can take many forms as experience and skill are examples. The different means of assigning roles will be discussed later (Section 1.2).
1.1.2 Egoless Programming Team
The Egoless Programming Team (EPT) is the exact opposite of the CPT. In the EPT structure there are no strictly defined roles or reporting structure. In fact there are no roles at all, except those that are decided upon by the group that can be rotated or changed at any point in the project. The EPT is based on full cooperation and that everyone is responsible for everything. The team works for a common goal.
The reasoning behind the concept of an Egoless programming team is the premise that it is dangerous and unproductive to simply allow programmers to "sit on their code" and regard it as an extension of their egos. This results in tunnel vision that disallows the programmer to locate all bugs. The existence of flaws in code, would thus bruise the programmer's ego since the code is an extension of oneself. Thus, debugging is not as thorough. When code sharing is a matter of routine, better quality results since the code is integrated better, is more readable, is more reliable, and everybody is involved equally. So that's why this type of team organization is called the Egoless Programming Team. Aren't you glad you asked?
Code sharing, as described above, can also be done in the CPT. The chief programmer can institute a procedure for code sharing among the junior programmers. However the full benefits of code sharing are reaped from less directive environments (as the literature tells us).
All team member must be able to function democratically, accept votes as binding (and not try to sabotage results that one didn't vote for), handle the lack of an imposed structure, possess team building skills, accept cooperation and communication, and work on negotiation and conflict resolution. Also everyone must be able to acknowledge each others as equals, collectively have enough expertise for the project, and be able to set and achieve their own directives and tasks. EPT members must be able to deal with the lack of imposed structure, which will appear as chaos in the early phases of the group. The early phases of the group will take the longest to complete, since the plans, schedules, and important development decisions are made during this phase. The democratic process takes time, and conflicts will occur. All member must accept this fact, but be able to negotiate.
Though the concept of an Egoless Programming Team seems impossible and chaotic, there is a definable structure of evolution. An Egoless Programming Team goes through four phases of development: Forming - team member selection, Storming - positions of power are fought for, Norming - the group gives itself rules, and Performing - the group works towards achieving a goal and is productive. In other team organizations, these phases are previously defined and are virtually unchangeable.
The advantages of the Egoless Programming Team are increased team spirit, a high degree of work autonomy, more challenge and job variety for the team members that results in professional growth, greater job satisfaction, and better software. The EPT organization is best suited for small projects, with small teams of people who are familiar with one another.
Disadvantages of the Egoless Programming Team are the lack of a definite leader, conflict resolution takes time, issue and personal conflicts are likely to occur, and individual team members can become isolated and unproductive. Not everyone is cut out for the EPT approach. Some people may be immature or lazy and may need the structure that one of the other team approaches provides. The key ingredient for a successful group member in an Egoless Programming Team is initiative - the personal initiative to work efficiently and the initiative to work with others as equals. As you don't want to find out half-way through the project that a teammate is not meant to participate in the EPT approach, one of the first group tasks is to honestly as yourselves whether you are up to the EPT approach. If you are not or feel that someone else in the group is not, be honest (but tactful) with one another about misgivings. For example if Bob admits to the group that he is a procrastinator, the group (or someone therein) can work with Bob to draw up task lists by subdividing tasks and assigning each of those subtasks due dates.
1.1.3 Administrative Programming Team
The Administrative Programming Team is organized by administrative tasks that encompasses both the CP Team and the EP Team. Distinct roles can be created, but they can revolve and thus allow for professional growth. The roles within the APT are: project manager, toolsmith, librarian, quality assurer, and configuration manager. As you progress through your Software Engineering coursework, you will become familiar with some of these roles in much greater depth.
The Project Manager is the channel of communication between the group and the customer (in your case, customer is usually the professor). All disputes, questions, and comments between the two entities are conducted through the manager, though the manager represents the group during on-the-spot decisions and negotiations. The manager also maintains the project schedule, though he/she does not solely decide on arbitrary dates. The project schedule itself is agreed upon by the entire team, the manager revises the tasks and dates on the document. In addition, group meetings are conducted by the manager as he/she is responsible for initiating the agenda. All team members can send a message (verbal or written) to the manager to add a particular topic to the next agenda, or add the subject at the appropriate time during the meeting. Law is not laid down by the manager, but rather proposed and negotiated. The skills necessary for a successful manager are the same as the Chief Programmer's prerequisites: people skills, the ability to plan and control the execution of a plan, setting realistic goals and priorities, and evaluating and reporting progress to upper-management.
The Toolsmith researches the project's tools, trains the group on their use, when necessary. Project tools are generally comprised of software, such as a compiler, debugger, or prototype tool (e.g. Visual Basic, Director, or pen and paper mock-ups of the user interface). In addition, any research that has to be done is also the toolsmith's task. This is a fun job for anyone who likes to play with new toys (figuratively speaking), and who is adept at research.
The Librarian maintains the team's project documents. Meeting minutes, status reports, requirement specification document, design documents, the project schedule, and any other relevant documents are organized for the team's reference. The Librarian does not write all of these documents, instead he/she maintains that the latest versions of the project documents and all of the minutes and status reports are available to all members of the team. The librarian is usually the person who acts as the scribe during meetings and status reports, but that task can be rotated. Necessary skills for this importance job are good organizational skills and writing skills. The Librarian may want to consider creating a team website to archive these documents.
The Quality Assurer is in charge of the project testing and assures compliance with the requirement specification document (as well as the other design documents). Test cases are designed and conducted by the QA, so that debugging can be as thorough as possible. Compliance with the requirement specification document must be constant during the project, rather than at the end. Compliance should be constant throughout the design process, rather than as a pleasant coincidence during the final demonstration. Testing experience is preferred for this role, but all computer scientists should be in this position at least once in their careers. Attention to detail is a required skill for this job.
The Configuration Manager has the important task of maintaining the program files for the team by identifying, organizing, and controlling modifications to the software project. In particular, version control is a significant, ongoing job that effects the entire project. This is a very important job since having multiple versions of a file, much less the whole program, only brings frustrate to the team. No one wants to backtrack through code the night before the project is due. In addition, coding standards must be set to insure consistency. For example, variable names, and header files (if C or C++ is being used) must be consistent. Unix has it's own version control system, that can be used as a tool. Organizational skills and attention to detail are vital Configuration Manager skills.
Although each role has its own set of administrative tasks, programming responsibilities are shared by all. Design and documentation are also shared group tasks. Like the Egoless Programming Team, tasks and proposals are agreed upon. Proposals are presented to the group, discusses, revised when necessary, agreed upon and carried out. Communication is also like that of the Egoless Programming Team, except that the manager deals with the customer. Aspects of the Chief Programming Team include: the division of skills as they pertain to roles, and the importance of the manager to communication with external entities. This team structure is a workable median in the team structure spectrum, but only for small groups (those fewer than 8 people). This team model can work well for student teams since some work is shared, but expertise in a particular area is still being tapped into. As with any of the other models, feel free to customize the roles and structure.
1.2 Assigning Roles
Now that you have read about the various options for organizing your group, you may want some tips as to how to assign these newly discovered roles. Roles, like those presented in Section 1.1, can be assigned according to an individuals personality, technical (or otherwise) expertise, and/or initiative. Although group members may volunteer for roles, other factors should be taken into consideration. For example, a talkative person may be assigned the role of Presenter (conducting formal reviews of project milestones). Having the skill to ramble on does not make someone an effective speaker who can articulate the team's position to the professor or class. While everyone should get a chance to practice speaking to small groups, the first presenter should be a seasoned speaker who can act as a good role model. Also if someone is accomplished at a particular task, such as writing, then that person would be a natural as the Scribe. If no one is experienced at the tasks involved with a particular role, such as that of Manager, then someone who needs the practice or feels that he/she can meet the challenge should undertake the role. If either no one or too many people vie for a role, then the role can be revolved or re-arranged so that the joy can be shared amongst the group. Remember that roles are not cast in stone for all eternity. If you and/or other team members have a problem with the assigned roles, then discuss and revise them. Besides learning the intricacies of Software Engineering, the purpose of this course is to provide opportunities for you to practice writing and speaking. During your coursework you will not get many opportunities to write documents and speak to an audience in the context of Computer Science, and you should take advantage of these opportunities before you enter the "real world." Also by participating in the creation of the documents and diagrams, and in presenting them, you are able to reinforce their content for your own understanding.
1.3 Distributing Tasks
Most task distribution occurs during the initial course of the project, and various factors can affect which group member will undertake which task. While role definitions are usually the dominant deciding factor in task distribution, a group members' expertise or a temporary time or schedule conflict can affect the delegation of tasks.
1.3.1 Matching Tasks to Roles
Tasks which are appropriate for a particular role can be assigned to that role, thus insuring that the group member will incorporate the task into similar tasks that are already being undertaken. The Chief Programming Team and the Administrative Programming Team distributes task in this manner. However, the Egoless Programming Team will use another means since it has no well-defined roles to use for assignments.
You want to eliminate redundant work and minimize wasted resources. If for nothing else, no one likes their time wasted. There are plenty of tasks to be distributed during the project. Also keep in mind that some tasks overlap roles. In this case divide the task and assign the applicable components to the applicable roles. If such a task will be assigned to one person, that person can consult other team members. Just because team members are assigned roles, that does not mean that you will not discuss the details of task execution with other members of your team.
1.3.2 Matching Tasks to Abilities
A task can be relegated to a group member who has expertise relating to a particular task, if there are no objections from the other members. All group organization types can utilize these means of assigning tasks, but in the case of the Chief Programming and Administrative Programming Teams the group member who has the ability will most likely have the role in the first place. However, this is not always the case.
If you see a task that appeals to you, then speak up. If you don't, then the chance may not come around again. Also the task may be assigned to someone who may not want it and thus not perform the task as well as it could have been. Besides learning about the intricacies of Software Engineering, the other purpose of the course is to provide you with opportunities of personal growth. Taking advantage of these opportunities now can pay off later. A good example of this is writing documents and making presentations. These tasks are not status tasks amongst those of us who have chosen Computer Science or Engineering as our career or tasks that you may feel to be a strength, but you will not get many opportunities to exercise these skills in this context.
1.3.3 Time/Schedule Conflicts Between A Group Member and The Milestone or Task At Hand
A group member, whom under ordinary circumstances would undertake the task, may need to have his/her task(s) temporarily reassigned to the rest of the group. If such an occasion arises, be supportive since everyone in the group will probably require such assistance sometime during the quarter. When the task load needs to be suddenly redistributed, the task load of each remaining team member needs to be balanced in terms of project task load and general task load (in terms of other classes). Keep in mind that being supportive is different from being a doormat. No one group member should abuse the generosity of other group members during the project. In one of my teams, one member continuously lamented on how busy he was in his other classes and did not have the time to do his tasks. At first we were supportive, but he abused his excuse and we called him on it. After all he was not the only person to have other classes that required our time.
1.4 Running Group Meetings
Group meetings are most efficient when issues are prioritized and discussed in timely manner. Time limits should be set for general group meetings (not necessarily for working meetings) so that the appropriate blocks of time can be set aside for the meeting. If general time limits are adhered to then there will be less likelihood that time will be wasted with superfluous chit-chat. The issues to be discussed should be decided upon in advance, but a block of time of time during the meeting (at the beginning or the end) should be made available to discuss "hot" topics that have arisen quickly and recently.
Also, minutes should always be taken at meetings. As a result, the team can have documentation as to what was discussed and what was agreed upon. Besides the minutes, it is also beneficial to have hard copies of the project schedule and relevant project printouts. At the end of each meeting, all team members should be clear as to what was decided for each agenda item and what tasks need to be accomplished (by when and by whom). If necessary, the group leader should designate someone to be responsible for bringing copies of documents to meetings on a regular basis. A team Web page is an effective means for document distribution since team members can consult with minute archives and the most recent copies of documents will be available.
Meetings are not productive unless all group members come to the meeting prepared. If you are not prepared for a meeting, you are wasting your teammates' time. If you have a task that needs to be completed by the time of the meeting and you will not be ready, tell your teammates BEFORE the meeting. Also rather than saying that you are not done, you should say what you have done and what resources you need in order to be done by the time of the meeting. If you need some help, ask a teammate. If you will have 4 classes done by the time of the meeting, and the fifth one is pseudocoded, make the appropriate arrangements with your teammates. Meetings should not be postponed and additional meetings should not be necessary in order to compensate for late work.
Lastly, everyone should attend group meetings whenever possible. If for some reason you can't attend a particular meeting, let someone else know and make plans to drop off the work/printouts needed for the meeting and to get the meeting minutes as soon as possible so that you won't be left behind the team.
2.1 Generating Ideas and Strategies
Participation by all group members is essential for idea generation during the group discussion. In addition, group members must listen to one another so as to have a general foundation for group discussion. If group members cannot listen effectively to one another, then valuable ideas will be lost and precious time will be wasted going around in circles with ineffectual (and often off-the-topic) discussion.
2.1.1 Participation
Each group member must participate in the group discussion, so as to best insure that as many issues or options as possible are introduced. Equal representation is necessary for a group discussion, so that each member feels personally involved in the project. In addition, if someone has contributed a good idea, then acknowledge it. This may be especially important in the beginning of the group formation. Such positive acknowledgment will promote self-confidence and security within the group. And when people feel secure in the group, they are not likely to perceive criticism of their ideas as personal attacks. Even if you are not the team leader, you should still practice these points since you can make a connection with a teammate and you can be a good role model for others.
Also, don't let one person take over the group. If one person seems to be dominating the discussion, you might say, "Thanks, I've got it," (or something to that effect) when a major point is made and move on to someone else. You may find the prospect of asserting yourself to a domineering person in a group setting to be uncomfortable, but you want to make sure that your ideas get heard and that you enjoy your team experience (and the rest of the team too). Everyone should get a chance to participate, and there will be many good ideas that need to be heard.
A strategy for participation is group brainstorming, in the form of Round Robin. Round Robin entails going around the table and asking for an idea from each person, while one member writes down the list of the ideas preferably on a whiteboard (to promote group discussion). After the Round Robin, discussion about the idea can ensue. This may be a good starting point in a group's initial strategy sessions so that everyone may get an opportunity to contribute ideas. Besides providing the passive or shy members an opportunity to participate, this method will also help insure that ideas are heard in the first place rather than being lost in the shuffle.
2.1.2 Listening
Without basic listening skills, issues will not be resolved and the project cannot progress. Hence, listening to other team members is essential for the projects success. The difficulty with effective listening stems from the fact that you think much more rapidly than you speak. Since the words you are listening to come slowly in relation to your thoughts, your brain tends to make up time doing other things, like thinking of a rebuttal to what is being said or evaluating the speaker.
Effective listening is the best way to gather information. In addition, if you expect your peers to embrace your ideas, then you should at least show some courtesy and listen to their ideas. Examples of listening skills are jotting down a speaker's main points, and asking substantive questions after the speaker has finished. Writing down everything the speaker has said is not a mark of a good listener, because the task of writing will overtake the task of listening. Taking some notes on important points is sufficient. Also, a manager who listens well encourages better listening on the part of the other team members. Besides the act of listening, your body language says to your teammates whether you are listening or not. Besides taking notes, look at the speaker occasionally. You don't want to appear mechanical or that you are trying to stare them down, but you do want to be attentive.
2.2 Coming To Consensus
Groups must be able to negotiate and compromise in order to work out differences. Even minor points may require negotiation so as to insure that the solution is viable and binding in the long run. Groups should strive for consensus so that everyone in the team understands and agrees with the solution. Consensus will also combat domination by a single group member. Consensus will promote teamwork, rather than isolation.
Part of consensus is often negotiation. The idea behind negotiation is to create a "win-win" solution for everyone involved. When one person or group wins and the other person/group loses, feelings are hurt and that can only hurt the team in the long run. Negotiation can manifest itself in compromise, but compromise does not lower the effectiveness of the solution. One example of compromise can be that Bob's design for the Graphical User Interface will be used instead of Mary's design, but Mary's design for the database will be used instead of Bob's design. Also the team can compromise on one item, as long as it has several components that can be negotiated. The negotiated result consists of several effective ideas from several team members - everyone wins. When team members feel that they have a personal share in the project, they will continue to work towards team goals.
2.3 Making Diversity Work For You
The most effective groups can be those in which its group members come from diverse backgrounds, including but not limited to ethnicity, gender, and experience. Diversity introduces a variety of talent, enables fresh perspectives and thought patterns. Innovative ideas and strategies, that otherwise may have gone unnoticed, can be embraced and utilized for the project. Think of differences among group members as assets. You will discover that problems get solved, often more creatively, when various perspectives are brought to them. Differences should be valued.
As of this writing, my last team consisted of members from different backgrounds based on ethnicity, age, gender, and experience. We did not know each other before the course, and we were one of the only heterogeneous groups and one of the only groups who did not already know one another. The result was a project derived from innovative design and thoroughly documented. The combination of industry experience, academic experience, creativity, and ingenuity was an asset. Sure we had our problems, but that's what negotiation is for (Section 2.2).
2.4 Tips For Group Success
The following tips are for group managers, but you should keep them in mind as well regardless of your role in the team.
3.1 Maintaining the Group's Conceptual Understanding of the Entire Project
At least one person, usually the Project Manager, must have a clear vision of the entire project from specification through testing and release. As a result, any questions brought up by other group members can be answered and the individual can check another group member's work against the project's goals to insure compliance with the Requirement Specification Document and any relevant, previously agreed-upon programming or design standards. Understanding the scope of the project may seem secondary to the functional completion, but as the project grows in complexity the necessity of maintaining understanding will become clearer.
Maintaining control of the project can be difficult, because of the:
Intangibility of the product during most of the development process, for which there are no visible milestones to measure progress and quality as there are for a physical product (e.g. a car). This invisibility is compounded for large software projects, for which logical complexity cannot be maintained in one person's mind, and for which development must be partitioned into a number of tasks assigned to different people. As a student, you will have milestones that will be graded and a project that is of a manageable size (as compared to those projects encountered in industry).
Management complexity. In an overly ambitious project, managers who do not understand the magnitude and detail of what they are managing are easily misled by subordinates. Conversely, lower-level staff (in your case, other team members) may be unable to appreciate the significance of details and fail to report serious problems. This is especially true during implementation.
Vulnerability of design. Since software system modules are not visibly connected, in contrast to hardware systems, the impact of a change is often not readily apparent even to the designers of the system until the integration phase. Small changes to code, which may seem insignificant on the surface, can drastically effect a calling module. For example, if a module is expecting an integer and instead receives a cardinal, then the calling modules assertion cannot be met. Using the Iterative model of software development can help minimize this issue.Why bother maintaining a thorough understanding of the project? Well, results of poor software project control may produce inadequate software that does not meet user requirements, is over-budget and late, is not easily maintainable, and is not robust (or any combination thereof). Also the system may be inordinately expensive due to unconstrained goldplating (the addition of superfluous features). Since students projects are small (when compared to large-scale, industrial projects), you will have an excellent opportunity to practice effective software engineering on a manageable scale.
The most effective means of maintaining control over the project is for one group member to have the design documents and update them as necessary. Otherwise time will be wasted if three people have made changes to the project design and backtracking is necessary to create an up to date specification. Changes can be made, but the whole group must be made aware of them. Try to maintain the documents as changes happen rather than at the end of the project. You will not remember all of the changes or you will have lost your notes. Also there will be plenty of work to do at the end of the quarter/semester, and you do not want to take time away from end-of-project tasks in order to bring your specification and design documents up to date.
3.2 Keeping the Project on track
Maintaining a project schedule entails recognizing time constraints and deadlines while insuring that the project meets the original specifications. A project schedule, which includes a list of goals, deliverables, and who is working on specific tasks, must be maintained at all times. This will insure that resources are being allocated to all tasks and each group member is aware of his/her job.
When I was a student in Software Engineering I, my team and I structured our project so that it consisted of three levels of modules. We grouped two to four modules together into a subgoal, and assigned each subgoal to one team member. A goal was considered to be a distinct and testable feature, for example when the generated document could be saved to a file was a goal. We designated a person to keep tabs on the teams progress, and to catch any lapses in manpower allocation. When Lee needed help on a subgoal, I helped her complete it when I was done with mine. We didn't want anyone to be overburdened, and we all helped each other.
Goals allow for a manageable, modular progression of integration and testing, rather than the "Big Bang" method. The Big Bang integration and testing method is when everyone turns in their work at once, compiles it, executes it, and runs for cover as errors and core dumps spray from the terminal. Needless to say, the Big Bang is not recommended when compared to the modular method of division. Even at the graduate level, I still see groups using the Big Bang method of integration. Sad but true. Of course these same groups never had their testing or documents ready to turn in (or at best looked like they hadn't slept that whole week). Lastly, the division of work into modules does not mean that team members work separately. Feel free to assist one another and ask questions concerning project understanding. You wouldn't want any unpleasant surprises the day of the project integration.
3.2.1 Working Under Time Constraints and Deadlines
When considering the feasibility of the project and its phases of development, you must take time constraints into account when negotiating milestone deadlines with the professor. When making time estimates in the beginning, do not work under the false assumption that everything will always work correctly the first time. Allow time for debugging, testing, and quality assurance. People often underestimate the time necessary to complete tasks. I suggest multiplying the amount of time that you estimate by two to arrive at a more accurate estimate of time to complete the task. You are not "padding" your work time (which most professors frown upon). Instead you need to use the suggestion as an assistant in estimating how much time will be needed throughout the project.
Also in the course of the project or project phase, you should keep in mind that manpower or other resources may need to be reallocated in order to most effectively meet a deadline (especially when the deadline is very close at hand). If you fall behind in a particular project phase, try to have subgroups work in parallel. For example, part of the team can finish Phase 2 while the rest of the team starts on Phase 3. As a result, you can keep the project on schedule or at least minimize the damage of double maintenance (the simultaneous revision of two or more files that result in one set of revisions overwriting the other file). Even when deadlines are approaching fast, do not ignore your documentation. If you leave the revision of documents until the end, you will waste precious time at the end and you will not remember all of the modifications.
3.2.2 Maintaining the Project Specification's Integrity
The project must reflect the design specifications at all times so as
to avoid any confusion of the requirements by a group member at a later
phase. Although the design can change, the project's revisions must be
traceable and accurately portray the most recent revisions. To accomplish
this, keep a list of changes made to the design specifications and maintain
an archive of design documents (and other documents associated with the
project) that have the revisions present in a chronological order. That
way you, or any other group member thereof, can backtrack changes made
to the project when the need arises. Keeping these documents in a
binder, where the newest version is presented first in it's tab divided
section, makes presentation efficient in team meetings and in team-client
meetings. Also all versions of all documents should be saved on a
hard drive and backed up. Your team may also want to archive the
documents on the team web site so that any team member can trace back through
the documents at any time. When you keep copies of documents in several
places, you will want to make sure that each document source is updated
at the same time.
The following sections describe the process for managing risk. The process is simple and straightforward, and the time that your team takes to plan for risk today will save you heartache tomorrow.
4.1 Identifying Risks
The first step to managing risk ts to recognize that risk exists and
to identify the various forms that risk takes in a project. For the
purposes of your class project, team brainstorming will be the most useful
way of identifying risks. As with brainstorming in other areas, the
different perspectives of team members will produce an extensive list of
possible items. Risk identification needs to be done during the initial
planning phase of the project and the time you take planning for risk will
pay off in the long run (according to research). As this
project is probably your first experience in risk management, you may want
to consult the SEI
Taxonomy-Based Risk Identification Questionnaire for ideas. The
SEI Questionnaire can be overwhelming though and you can start your brainstorming
session with the question "What issues do we need to consider during the
course of the project (e.g. What can go wrong)." When identifying
risks, you will want to be detailed. Sure you will end up with a
long list, but that is what you will want. Using the Cause-Effect
or wishbone diagram methods may be useful in the early stages of risk identification.
4.2 Analyzing Risks
After your team has identified risks, you will need to analyze them
in terms of their priority and probability. After all you can't plan
for all risks, and you will need to dedicate your resources to planning
for the appropriate risks that are most likely to happen and/or can cause
the most damage. There are many facets to risks and how they can
effect the project, and the team needs to analyze each risk.
First the probability of a risk surfacing needs to be quantified.
In some projects there are ways to measure the probability, but for the
purposes of your project the Likart scale of Very Low, Low, Medium, High,
and Very High will suffice. For example the probability of two members
of your team dropping the class may be Low, but the probability of one
member of the team dropping the class may be High. So for the list
of risks that the team identified earlier, quantify the probability of
each risk occurring in the form of a table. You should cluster related
risks together.
| Risk | Probability (Very Low, Low, Medium, High, Very High) |
| 1. 2 team members withdraw from the class during coding. | Low |
| 2. The test cases are too general. | High |
| 3. Some of the code does not follow the coding standards. | Medium |
| 4. The user documentation does not correspond to the feature set. | Low |
| 5. The client is not satisfied with the program's interface. | Medium |
Next the impact that each risk has on the project needs to be estimated.
If a risk has a low chance of occurring, but has a devastating impact on
the schedule it needs to be dealt with ahead ot time (e.g. planning).
According to the United States Air Force there are four categories of the
impacts of risk: Negligible, Marginal, Critical, and Catastrophic.
These categories will be used as its own Likart scale of measurement.
So while the probability of two members of the team dropping the class
is low the impact to the project would be Critical (I'm assuming that there
are five or six members on the team). You can add these impact measurements
to the probability table that you constructed as in the example:
| Risk | Probability | Impact |
| 1. 2 team members withdraw from the class during coding. | Low | Critical |
| 2. The test cases are too general. | High | Critical |
| 3. Some of the code does not follow the coding standards. | Medium | Marginal (that is arguable) |
| 4. The user documentation does not correspond to the feature set. | Low | Marginal |
| 5. The client is not satisfied with the program's interface. | Medium | Catastrophic |
There is another step in risk analysis where you would need to quantify the risk's impact on the cost, performance, schedule, and support of the project but I will stop here. For most of you the above risk measurement will suffice as long as your risk identification takes these categories into account. After you have constructed these analysis tables, you will need to determine which risks you will plan and monitor since you cannot deal with all possible risks. You need to examine the table and determine a criteria that will allow you to chose which risks to plan for and monitor. You cannot simply take all of the high probability or all of the Catastrophic risks as that may not be practical.
4.3 Planning for Risks
After the risks have been analyzed, a risk management plan should be created in order to address each risk in terms of rationale and a plan of action. The risk management plan should be maintained in format that can be easily sorted and filtered by team members. Some sort of tabular form, such as a spreadsheet, would work fine since you won't have much time to format the plan, but a database would be an alternative that could take too much of your time.
For each risk that you identify and deem worthy of planning for, the following should be documented:
4.4 Monitoring Risks
After you and your team has completed all of these steps, the process isn't done. Someone on the team will need to monitor the risks and keep track of how the risks change. You will also discover that new risks will surface as your project proceeds. Although most of the risk management resources will be needed for the initial planning phase, keep some time and documentation resources available to monitor risks during the rest of the project's life.
Since someone should be in charge of risk monitoring, the risk analysis
tables and risk management plan should be maintained in an actual document
that can be shared with the team and maintainable by the team member.