Part I: General Group Tasks


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.

Chapter 1 Administrative Duties That Lay the Project and Group Foundation

Deciding on the group's organization, role assignments, and how meetings should be run are basic administrative duties that must be discussed and resolved early on in the project so that a stable environment can be established for the evolution of the project. Though roles are assigned during the group's formation, they can change or rotate during the course of the project. Tasks assignments need to start soon after the group is formed, and will continue to be created and revised until the project is finished.

1.1 Group Organization

Unless you are required to use a specific organizational structure, you have options. There are numerous types of group organizations, but I will limit the discussion just a few. The types of group organization to be discussed 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.

Figure 1

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).

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).

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.1.4 Administrative Programming Team Variant

Some roles may need to be broken down in a lower level of granularity than the traditional APT offers. Customization is fine as long as the flavor of APT exists. The specific roles will vary depending on the project, but a sampling of roles can be found here.

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. Even if you are in a Software Engineering program, different courses will emphasize different concepts and artifacts, so it is also a good idea to participate in these aspects in all courses.

1.3 Distributing Tasks

Most task distribution occurs during the initial course of the project or phase, 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 someone else in 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.3.4 Documenting Task Delegation

It is one thing to delegate who is going to do what task, but it is another to document it so that you can manage status over the course of the project. You can use Microsoft Project or other tools. A simple tool to get you started is a spreadsheet used in the Introduction to Software Engineering course at my current university. The spreadsheet is assuming an incremental process, with a week-by-week breakdown. Initial tasks are listed to get the student teams started. The spreadsheet looks like this:

Figure 4. Blank PlannerTracker Spreadsheet with initial project tasks provided for teams.

You can customize the tracker spreadsheet to work with project length or process model. It can help you plan the tasks that you need to do for your project, document who is to do them, and how much time was estimated and actually spent doing these tasks. The screenshot shows the types of tasks that you want to account for such as drafting documents, learning new tools, and attending team meetings. The spreadsheet has instructions to guide you. For example, you want to multiple the time spent at a team meeting by the number of team members attending it (2 hour meeting * 5 team members = 10 hours). In industry time is often billed to a project and so you want to have an accurate reflection of effort expended. The spreadsheet in Figure 5 below has been filled out at the end of the first 2 weeks to show how it would be laid out in terms of tasks, who is responsible, and the estimation and tracking of hours.

Figure 5. Planning and Tracking Spreadsheet with Initial Project Data Entered

The spreadsheet also offers charts to help you analyze how your time is being spent, but that is to be discussed later.

1.4 Running Group Meetings

Running a group meeting is more than just a bunch of people sitting around a table. The following materials discussed the main points of running a meeting

Creating a meeting agenda and sticking to it helps manage distraction and off-topic conversation. Even limiting conversation to a time period can offer more structure and keep the meeting from going on to long. The time period depends on the topic, but 15-30 minutes is a good rule of thumb. If a topic needs more time, then you may need to reprioritize agenda items or call an additional meeting. A general structure is:

  1. Meeting Comes to Order
  2. Old Business (left over from a previous meeting, if any)
    1. Topic 1 - include time estimates
    2. Topic 2
    3. Topic N
  3. New Business
    1. Topic 1 - include time estimates
    2. Topic 2
    3. Topic N (Note: as new topics are brought up, either place them at the end of the list or table them for the next meeting)
  4. Closing meeting with reminder of what the deligated tasks and any deliverables are

While the team drives what will be talked about in the meeting, a single team member should create and maintain the agenda. Having someone in the role of Facilitator will help make sure that the meeting flows and that everyone gets to contribute. The Facilitator is usually not the Notetaker. The Facilitator should not be the domineering student, but this role can (but does not have to) be held by the Project Lead/Manager. The Faciliator is a powerful meeting role, as this person is instrumental to the achievement of the project's goals by keeping each topic on track through the inclusion of all team members. An atmosphere is achieved that intends to remove (or at least minimize) intimidation, personal attacks, and domineering behavior.

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.

Chapter 2 Successful Group Dynamics

In order for a group to be successful, it must be able to be effective in generating ideas, coming to consensus, and interacting effectively with members from diverse backgrounds. This will insure workflow and allow prosperous working relationships to develop. Individuals with diverse backgrounds will introduce various, and oftentimes differing ideas, that must be discussed, debated, and revised so that a consensus can be reached.  Since the initial team meetings are often awkward, the "getting to know each other" phase, participation by all members and fair discussion is particularly important to get the project off on the right foot.

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.2.1 What Consensus Is and What Consensus is Not

Consensus is often misunderstood. Many people think that it means that everyone thinks that the decision is the best one. That is not what consensus means. Consensus means that during the process of coming to the decision, the ideas/position of each person on the team was listened to. The decision derived, when consensus and negotiation are followed, is often viewed as the best course of action as it is based on the collective effort and ideas of the team. So in hearing from everyone, there may be pieces from different people's approach that build on each other and eventually form a team solution. However, it may not mean that everyone feels that the solution is the best one (after all some people only like things one way - theirs).

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.

Table 1

Chapter 3 Project Management

Effective project management means that the project must remain on schedule while remaining true to the specifications (and in industry, within the budget). To achieve this, the group must constantly be aware of the project's specifications and any changes that may occur during the course of the project. Revision will be continuous throughout the various phases of the product's development. In industry, it is often impossible for everyone in the group to have such insight into the whole project because of its scale and complexity. Since you are in an academic setting, you will have to keep abreast of how the project is progressing at all times.

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.

Let's revisit the planning and tracking spreadsheet that I introduced in Section 1.3.4. The spreadsheet is useful for planning out project tasks and who will do them. To fully use the spreadsheet and manage the project, you also want to estimate how long it will take to complete the task (do this before you actually do the task) and record how long it took to complete the task. Gaining experience with estimation will help you manage your time and the project in the long run. Even if you find that you were WAY off in your estimations, record them anyway. Your instructor will not penalize you for it, this is part of learning to be a software developer.

Another important piece mentioned previously is that if you are going to have more than one person contribute to a task include their hours too - even if it is a meeting. A sample from the spreadsheet is below in Figure 6.

Figure 6. Planner Tracker Spreadsheet with Initial Tasks Information Entered (Note that the Comments column is made narrow to enable everything to fit)

As you enter the actual time for each task, the spreadsheet will tell you the extent of your error in estimation per task. As you progress through the project, you will hopefully see the amount of error decrease as you become more proficient with estimation. True proficiency takes time over several projects.

The full power of the Planner Tracker Spreadsheet lies with the charting tools. Notice that there are several worksheets in the spreadsheet. One of the sheets is an instruction sheet, but the rest are charts to help you assess how your time is being spent on the project. Figure 7 shows a summary of your team's project data and Figure 8 shows a sampling of the charts generated for different perspectives of the data.

Figure 7. Summary Project Data for the Project Worksheet in Figure 6

Figure 7. Sample of Charts Generated for the Project Worksheet from Figure 5

The spreadsheet with the sample data is available so that you can see all of the charts and other details.

TIP: At your weekly meeting, the team should go over the schedule to discuss the status of the project and adjust the schedule if needed.

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 (or CVS, Subversion, etc.) 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.
 
3.3 Choosing the Right Tools

There are many tools to use for virtually all aspects of project management, and software development for that matter. In this section, I will discuss some general tools that people use or may be thinking of using to assist with various aspects of project management. This is not a chapter about hard core tools, as you will have a discussion in class about that (and there are many web pages about that already)

Finding tools is easier nowadays than it has ever been. Many companies have relationships with universities whereby tools are available to you for free or at least free at school. Some companies have academic versions that you can download from their websites. There are also many open source tools that you can use.

When a tool is selected (and it should be someones task to research and even evaluate tools), everyone should agree to it. It would also be a good idea to hold a mini workshop so that you all are confidant as to how to use the tool, installing the tool, etc.

Beyond software development tools, you may use technology/tools that you use everyday as part of conducting your project. Do so not because you have it already, but because it is the best choice. For example, I have seen students take pictures of the whiteboard with their cell phones rather than write down the contents to save time. However the pictures are unreadable, and the knowledge it lost. TIP: Cell phone pictures also do not work as mock-up prototypes either.

Here are some thoughts on tools and technologies that you may be considering to use for your project:

Tool / Technology Things to Consider
Creating Your Own Tool Why spend time reinventing the wheel. This can be a large misuse of your time and effort that can be used towards the project. I have seen students do this.
Instant Messaging In common use. Instantaneous, but can be a poor substitute for a face-to-face meeting (when warrented). Slow typists will hate this. Some labs may block this though and it can also be a distraction.
Web-based Collaboration Tools (e.g. Groove, Breeze) There are lots of tools out there for this that provide features for communication, calendering, collaboration, etc. It depends on the tool. Breeze for example provides whiteboard, text communication, and webcam support (and phone) so you can show your ideas to a stakeholder or discus things amongst yourselves. You can save discussions. Groove has similar features and more and it also offers file sharing, calendaring, task management and other features. Breeze is not free but your school may have a site license for it. Groove has a limited free version.
Email Great as a communication tool, though not instantaneous. Not a good idea to use it to keep track of your project as it won't be organized.
GMail and Other Google Services (e.g. Calendaring) I have seen students swear by Google's tools as the account offers a large quota. Google Calendaring tool can be very helpful with personal scheduling and finding common meeting times.
Blogs Blogs can be useful for keeping a personal project journal. If you are required to keep a project log, you may be able to use this instead. It is easy for you to create, easy for your teammates to look at if needed, and easy for your instructor to check on to see how you are doing.
Wikis This is a good and easy way for everyone in the team to communicate about the project, and be able to refer to the communication at a later point in time. It is also easy for the instructor to check in on the team at any time.

As technology changes, tools will come and go but you want to think critically about their use in your projects.

Chapter 4  What You Need to Know About Risk

Risk and the software project goes beyond the risk of not getting a good grade.  Risk management is a area that concerns planing for what can happen in the course of the project.  Technically risk is not necessarily a bad thing, but for our purposes risk generally means that the project may be open to harm.  If risk is not planned for, the what if turns into what do I do now (sometimes referred to as firefighting - putting out fires).  Once risk is identified, analyzed and monitored then "the right risks can be taken at the right time" according to the Software Engineering Institute.  Since you and your team has a limited amount of time and resources to dedicate to the project, effective risk management will minimize surprises and allow you to work on the project and towards your goals.  Projects where risk is dealt with cost less to complete and are finished earlier (and have more predictable schedules) as a result to the increased focus and planning.

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. You can use this spreadsheet to help you manage risks.

4.1  Identifying Risks
 
The first step to managing risk is 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.

If you are using the provided risk management spreadsheet, enter each risk on it's own row. The following image shows a sample risk:

Figure 9. Sample screenshot from Risk Management Spreadsheet

Don't leave this list alone during the project. You may feel that you need to modify the risks during the project.

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, though for your project your instructor may simply require that you use the Likart scale of Very Low, Low, Medium, High, and Very High.  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.  In the spreadsheet (shown in Fig. 9) the probability is quantified as a number between 0 and 1, where is a 100% likelihood of the risk occurring. You want to enter a probability for each risk. Since you are working in a spreadsheet, you can sort the risks based on probability if you need to for further analysis. 

Next the impact that each risk has on the project needs to be estimated.  There are many scales that can be used here, where each item on the scale is associated with a value. For example, 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.  The spreadsheet uses a simple 3-item scale of Low, Medium, and High.

If a risk has a low probability of occurring, but has a devastating impact on the schedule it needs to be dealt with ahead of time (e.g. planning).  So while the probability that the project will fall behind due to the team's lack of familiarity with Java is low (.2), the impact to the project would be high (I'm assuming that there are five or six members on the team).  Enter the impact of the risk to the project for each risk in your spreadsheet.
 
 The following is an additional sampling of risks, and how they would be categorized for a hypothetical project.

Risk Probability and Impact Measurement Table
Risk Probability Impact
1.  2 team members withdraw from the class during coding. .25 High
2. The test cases are too general. .75 High
3. Some of the code does not follow the coding standards. .5 Med
4. The user documentation does not correspond to the feature set.  .25 Low
5.  The client is not satisfied with the program's interface.  .5 High

Some risk management analysis activities include a step 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.  This is where exposure comes in to play. Exposure is a calculation based on the probability of a risk and its impact. Thus the exposure formula will vary depending on how impact is used (e.g. 1 impact or broken down into several for example). The spreadsheet takes a simple approach where exposure where the exposure is calculated as probability * impact. Impact is quantified as low = 1, medium = 5 and high = 10. In the spreadsheet the exposure is calculated for you.

Once the exposure is calculated, 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/High impact risks as that may not be practical. The exposure calculation takes both the probability and impact values and gives you a single value. The value of exposure is that you can sort your risks based on it, and select which risks to plan and manage based on a threshold value that you select. For example, you may decide to plan for all risks whose exposure value is greater than 5.

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:

Some people refer to Action Planning as fire fighting since you are doing what ever it takes to squelch the problem (the way a firefighter deals with a fire).  Action Planning may happen at times, but it is not preferred since it takes time away from other things and other surprises can pop up - then the project can really get out of control.  Action Planning is still mentioned since you can't account for everything that could ever happen (as if life were that simple..).  Contingency Planning is true planning - the risk is monitored and when a trigger (or threshold is reached) then plan flies into action.

The spreadsheet can be customized to provide a column for each of the items discussed above. At a minimum, the spreadsheet has columns for who is responsible, the mitigation plan, and the status of the risk. The screenshot below in Figure 10 shows a risk with all of these parts filled in:

Figure 10. Risk Management Spreadsheet with an Elaborated Risk

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.  In the spreadsheet there is a column to keep notes on the status of each risk. Even if the risk has not presented itself or there may only be indicators, you should note this in the status column.

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 a document, like the spreadsheet, that can be shared with the team and maintainable by the team member.