Seabase I Case Study

Module F

The next day (Tuesday, Sept. 28) JoAnn and Ken meet to discuss the project. Bob did not attend.

Minutes of Sept. 28 CS Team meeting

They agreed to make their development process more rigorous, with more documentation (including a timeline) and standard formats for documents. Agenda items are to be agreed upon before meetings. The to-do lists are to include task assignments to particular team members.

They draw up a to-do list. Among the items on the list are:

  • asking Hank a question about the code (JoAnn's job);
  • sending email to the crane email list (which includes everyone involved in the project), asking for requirements from the engineering teams (JoAnn's job);
  • working on understanding the existing code (Ken's job).

They discuss whether use-case analysis might be helpful.

They sketch out the documentation to provide for Hank and Dave.

Finally, they plan their goals for three upcoming meetings:

  • The Team Leaders' meeting on Sept. 29,
  • the CS class meeting with Dave on Sept. 30, and
  • the post-class meeting of the CS team on Sept. 30.

Later that day, JoAnn sends email to the other team members:

 
Ken and Bob: 
		
Nancy replied to my email requesting requirements by saying she
doesn't have them either.

Also, Ken and I had a really productive meeting this morning and I will 
be getting out drafts of timeline, resource list, introduction, and 
minutes from meeting hopefully by later today.

--JoAnn
  1. How do the issues that JoAnn and Ken raise in this meeting correspond to the brainstorming meeting, and the meeting they had with Hank?
  2. There is a decision to making meetings and documentation more formal and standardized.
    • Looking back at the risk document, what risks might this mitigate?
    • From your perspective on the project, is this a step in the right direction? Does it address any of the risks that you perceive in the project?
    • How important is documentation in this project? Why?
  3. Note all the "brainstorming" and "planning" references in this meeting and the previous two meetings.
    • What was solved in these meetings?
    • What was left unanswered?
    • What new questions were raised?
  4. The project's faculty advisors still seem unable to settle on what they want from the CS team.
    • How does this affect the team?
    • What is the CS team doing to address this problem?
    • What are other ways to deal with lack of definite requirements from the "powers-that-be"?
  5. The to-do lists now include information on which team member is in charge of which task.
    • What problems do you see this as addressing?
    • What are some other ways to promote ownership of project tasks?
  6. Bob was unable to attend this meeting. What was the impact of his absence?
    • How would you establish consequences for missing meetings?
    • What might they be?
    • How would you enforce them?
  7. Do you feel that the CS team is "on track" now? Explain your answer.

The biggest question still remains? "Who is doing what?"

This module shows JoAnn and Ken's follow-up meeting after the previous day's meeting with Hank. We see mostly JoAnn trying to pull the project together, trying for a "fresh start" (in week 5!) From her comments, it looks like she (and Ken) finally have a handle on what everybody needs to do, especially her.

This module raises issues of team/leader roles. Some possible classroom questions: Should JoAnn delegate more? Less? How can she enforce her decisions?

In the "To Do" list, people have been assigned to tasks. This is an important step: establishing personal responsibility for getting particular things done. But it must be accompanied with monitoring of team members, to make sure they indeed accomplish their tasks. Students can look ahead in later modules, to see whether the team members actually do what they are assigned to do.

This module also raises the question of what to do with members who fail to attend meetings, which can easily be moved to the larger discussion of what to to with team members who fail to carry their weight. Many students have experienced this, and the discussion may become quite spirited since the case study provides an safe frame.

Looking ahead, there are multiple times where one member or another misses a meeting. A good exercise would be to have students record their answers now, and use them as criteria (modifiable?) to judge reasons/excuses later.

The issue of working/dealing with "the boss" (the person in power, or with some authority; here, the faculty advisors) is an important one, and one the students will undoubtedly encounter in thier "real life" as professionals. Many will have already developed some strategies; but how appropriate are they for the workplace? JoAnn indicates her concern about Hank and Nancy: not wanting to "abuse their time or do improper reaching around". Yet the team does something that could indeed be considered "reaching around": asking for requirements via the project-wide email list.

Need to be careful not to pose anyone as "the bad guy" here; everyone has different perspectives and priorities.