Operations Proposal

From ZenWiki

Contents 1 Acknowledgement 2 Purpose 3 Point of Contact 4 Proposal 4.1 Software Development Process 4.1.1 Objective 4.1.2 Analysis 4.2 Team Roles 4.2.1 Objective 4.2.2 Analysis 4.3 Meeting Process 4.3.1 Objective 4.3.2 Approach 4.3.2.1 Attendance 4.3.2.2 Decision Making 4.3.2.3 Meeting Roles 4.3.2.4 Meeting types and objectives 4.3.2.5 Post Mortem 4.3.3 Analysis 4.4 Training Process 4.4.1 Objective 4.4.2 Approach 4.4.3 Analysis 4.5 Prototyping Process 4.5.1 Objective 4.5.2 Approach 4.5.3 Analysis 4.6 Tracking Process 4.6.1 Objective 4.6.2 Approach 4.6.3 Analysis 4.7 Tracking Proposals 4.7.1 Objective 4.7.2 Approach 4.7.3 Analysis 4.8 Project Tracking 4.9 Change Management Process 4.10 Test Process 4.11 Risk Management Process 4.11.1 Objective 4.11.2 Approach 4.11.3 Analysis 4.12 Reflection 5 Sources

Acknowledgement

Team Zen would like to recognize Simulacrum (2006) for their thorough operations proposal document that served us as a basis for writing ours.

Purpose

This document proposes the processes to be followed by Team Zen during the development of a tool that will assist SEI employees during the course of a SMART engagement with a client.

Point of Contact

The point of contact for this document is Session Mwamufiya. Questions and/or comments can be emailed to smwamufi@andrew.cmu.edu

Proposal

Software Development Process

Objective

The team’s development process and team roles are defined in the Zen Development Method (ZDM) file. We will use ZDM throughout the project, and it currently focuses on the pre-implementation phases of the project. The implementation an post implementation phases of the project will also be covered by the ZDM, and will be defined at a later date.

Analysis

We will determine whether the process is being followed and whether it is working for us by the number of missed tasks in a given iteration (higher than 6 will be a cause of concern) and record this analysis in our reflection page.

Team Roles

Objective

We have established roles in order to assign and track responsibilities in an objective way. Role definitions can be found in the Zen Development Method file.

Analysis

At the beginning of every iteration, we will review the tasks that need to be completed by each role, and at the beginning of the next iteration, we will review whether or not the tasks were completed. We will note down all role conflicts in our reflections area

Meeting Process

Objective

We have defined guidelines to be followed in every formal meetings (status, client, …) in order to have meetings that are efficient and effective.

Approach

An effective meeting needs the following rules defined:

1. Attendance
2. Decision making
3. Meeting roles
4. Meeting types and objectives
5. Post mortem

Attendance

Two types of people will attend the meetings

1. Participants: People who have responsibilities and/or deliverables to be presented during the meeting
2. Attendees: People who do not have responsibilities and/or deliverable to be presented during the meeting, but whose presence and advice are solicited.

Participants who are not able to attend should inform the agenda owner at least 2 hours prior to the meeting.

Decision Making

The decisions during the meeting will go through the following process:

1. Consensus: the Facilitator will determine if a consensus is reached if not,
2. Democratic vote: the simple majority wins, if majority is not possible, or if there is strong opposition,
3. The discussion will be taken offline, and the team lead will consult with each party, and the mentors if needed, and attempt to build a compromise. If no compromise is reached,
4. Team Lead decision

Meeting Roles

• Facilitator: Keep discussion on track, and mediate decision process.
• Scribe: Annotate discussion. Create tasks and actions items in the task tracking system (defined in the Tracking Process section below) after the meeting.
• Time keeper: keep track of time and warn facilitator of topic overrun.

Meeting types and objectives

• Status: Weekly meeting to track status of the project. The initial agenda must be sent at least 24 hours before the meeting. Revised agendas can be sent at least 2 hours before the meeting.

Expected outcome:

1. Address the tasks due between last meeting and the day of the current meeting
2. Every team member knows how many tasks were missed
3. Define reasons for eventual missed tasks
4. Team members know the expected tasks for next week
5. Clarify tasks due the following week with task owners
6. Every team member knows of all the changes that occurred to the project (proposals, risks,etc)
7. Address any pending issues
8. Assign a completion level to all tasks

Duration: Maximum 1 hour.

• Client: Weekly meeting to exchange information with the client about the project. The initial agenda must be sent at least 48 hours before the meeting. Revised agendas can be sent at least 5 hours before the meeting.

Expected outcome:

1. Inform client of past week accomplishments.
2. Update client of goals for the current week.
3. Answer questions from the team or from the client. Questions must be sent to the client with the agenda.
4. Get feedback from the client about direction of the project.

Duration: Typically 1 hour, but more if needed

• Working: Called by any team member, with the agreement of the majority of the team, to address an issue/risk. The member calling the meeting will create the agenda and send it to the other members at least 24 hours before the meeting.

Expected outcome: At the end of any given topic discussion, the discussion leader for that topic must be able to consider that topic:

1. Closed
2. Pending with assigned action item
3. Added to a new agenda for an extra meeting

Duration: Maximum 1 hour.

Roles:
Facilitator: Member who calls the meeting
Scribe: Appointed by agenda owner

• Planning: At the beginning of every iteration, a planning meeting will be held to plan the tasks required to meet the milestones of that iteration.

Expected outcome:

1. A consensus understanding of the iteration’s milestones
2. A plan for each week of the iteration, covering the tasks required to reach each milestone

Duration: Maximum 1 hour.

• Reflection: At the beginning of every iteration, the team will meet to evaluate the progress of the project based on the proposals. The process and roles will also be evaluated.

Post Mortem

At the end of a meeting, a wrap-up will include a recap of the:

1. items discussed
2. change in risks, if any
3. action items that resulted from the meeting

After every formal meeting described above, every team member must send their rating of the meeting to the team lead. The rating scale is as follows:

1. Poor
2. Fair
3. Good
4. Excellent

In the event of a ranking of 1 or 2, the team member must also submit some comments on how the meeting could have been improved.

Analysis

In every reflection meeting we will elicit issues and improvements from the previous iteration and analyze whether the process is being followed by using the following checklist:

1. Have all the meeting templates been followed?
2. Are team members satisfied with the framework of the current process? If not, what are the proposed changes?
3. Are action items put into the project management tool after each meeting?
4. Are minutes posted on the wiki?
5. Are the average meeting ratings at least a 3 (good)?

The results from this analysis will be recorded in our reflection page

Training Process

Objective

In order to enable the team members to execute the tasks in a competent manner, we have defined how the team members will be trained in different subjects relevant to the project.

Approach

Training topics should result from knowledge determined as essential to the team, or an experiment conducted for furthering architectural knowledge or general implementation research. The responsible engineer for any experiment conducted by the team may decide that knowledge dispersal of the experiment results is necessary. The responsible engineer will schedule training time, ask mentors and/or technical advisors about the subject, and devise a training plan for the subject.

The training plan must include:

• The goal for that training subject.
• How will this training be useful for the project?
• Who will participate in the training
• Training schedule

Any additional information on the subject should be available from the associate experiment's wiki page.

Analysis

During our reflection meetings we will analyze whether the process is being followed by using the following checklist

1. Was a training goal clearly defined?
2. Track artifacts, if any, produced using techniques learned through the training plan.
3. Where the participants present at the training?
4. Record team members’ voiced their opinions and recommendations about the training.

The results from this checklist will be recorded in our reflection page.

Prototyping Process

Objective

We will use prototypes (paper, system, ...) to help us refine our solution's design and implementation.

Approach

Our prototype process will be as follows:

1. Team meeting to decide whether a prototype is needed.
2. A one-page prototype proposal is created as documentation.
3. The proposal is reviewed by the team and a decision is made to move forward with the prototype.
4. The prototype is developped.
5. The outcome of the prototype, if successful, is incorporated in the solution.

Analysis

We will use the following checklist to analyze our prototype process:

1. Were prototypes decided upon in a team meeting?
2. Was a prototype proposal document created?
3. Was the prototype proposal reviewed by a mentor?
4. Did the team decided to go ahead with the prototype?
5. If GO decision is made, how long did it take to develop the prototype?
6. If the prototype was deemed successful, was it incorporated in the solution?

The results from this checklist will be recorded in our reflection page.

Tracking Process

Objective

We want to ensure that tasks are completed in a timely manner with acceptable results.

Approach

Team Zen will perform different types of tasks. For a general task tracking process we will begin by using Excel (then we will migrate to PhProjekt or Microsoft Project) as our project management tool to assign, prioritize and track tasks and milestones. Milestones will be set by the team lead in order to track progress.

Additionally, tasks will also be assigned by the team lead, whenever necessary. In this case the team lead will be responsible for adding the tasks to the project management tool.

Team members must agree with the tasks they are responsible for. In case of delays, the team member must notify the team lead at least 48 hours from the next status meeting. This period is used to re-plan resource usage to complete the tasks. If a team member fails to warn the team lead, the offending member will buy a dozen doughnuts for the next status meeting.
After 2 warnings for the same team member within a month, the team lead will talk with him/her and attempt to find a solution to make him/her comply.
More than 2 warnings from the same team member within a month, will indicate that the team member is not able to keep up with the rest of the team productivity. A meeting will be called by the team lead to evaluate the team member needs (training, motivation, etc).

Analysis

We will use the reflection meeting to analyze if the tracking process is being followed.

We will use the following checklist 1. Were all the tasks included in the tracking system? 2. Are all the tasks that are completed closed according to the tracking system? The results from this checklist will be recorded in our reflection page.

Tracking Proposals

Objective

We want to guarantee the quality of the proposals

Approach

We will assign individual team members to create a proposal, who will be the point of contact (POC) for the proposal.

We will use the following cycle

1. The POC is assigned and writes an initial draft of a proposal
2. The teem makes its initial proposal review
3. Changes are incorporated
4. Mentors review the proposal
5. Changes are incorporated
6. Team reviews a second time
7. Changes are incorporated
8. Mentors review a second time
9. Changes are incorporated
10. Team reviews a third time
11. Changes are incorporated

Analysis

In order to analyze whether the process was followed, we will use the following checklist:

1. Did the mentors review it?
2. Did the rest of the team review it (either individually or in a team review session)?
3. Were the changes that were agreed upon incorporated?
4. How many times were the proposals updated (if we modify the same section more than 3 times in a single iteration it will be a sign of concern)

The results from this checklist will be recorded in our reflection page.

Project Tracking

The project tracking process is defined in the Planning Proposal, which is accessible via the link.

Change Management Process

The Change Management Process is in its separate file and can be accessed via the link.

Test Process

Please refer to the Quality Assurance Plan

Risk Management Process

Objective

The purpose of this is to ensure that risks are identified, analyzed, and mitigated in a timely manner before they are able to seriously hinder our project.

Approach

The Risk Manager will be the primary point of contact for all risks. We will be following the general structure of SEI's Risk Management Paradigm as follows:

• Identify: Risks will be identified during any team meetings or by individual team members (in which case he/she will report the risk at a team meeting). The scribe will record any risks identified during the status meeting discussion. During the postmortem, the scribe or facilitator will review the meeting and the team will attempt to identify any additional risks that may have come up. The Risk Manager will be responsible for adding these risks to the list.
• Analyze: The Risk Manager will be responsible for determining the probability, impact, and timeframe of each risk identified. In addition, the Risk Manager will also determine the priority of each risk as it is identified.
• Plan: Risks that are not ranked or not in the top 3 priority will not have formal mitigation strategies assigned to them, but the Risk Manager should be responsible for being aware of the risk status and determining whether a mitigation strategy is needed. Risks that are in the top 3 priority will be assigned a mitigation strategy shortly after identification

Mitigation strategies will be determined in a short brainstorm meeting between 2-3 team members through the following process:

1. The team members involved and the risk manager will rate each of the strategies to come up with the top two to act as a primary mitigation strategy and a backup mitigation strategy
2. A trigger date will also be determined by the team as a deadline for when the risk needs to be mitigated. Once this trigger date is reached, the team will evaluate the risk at the next status meeting to determine whether a backup mitigation needs to go into place or if a plan reassessment is required
3. The risk manager will assign one team member to be a point of contact (POC) for the risk mitigation. The POC will be responsible for ensuring that the risk is mitigated before the trigger date.

• Track: Each of the current top 3 risks will be presented during the team's weekly status meeting. The status and progress of the mitigation strategies will be assessed by each POC and any changes to the risk prioritization will be made
• Control: During status meetings, each risk will be assessed by the team and marked as the following:
  • Open: The risk is still present and should remain in the top 3 priority. Risks that remain open may have new priorities assigned to them in the top 3 during the status meeting
  • Closed: The risk has been mitigated or has passed, OR a more critical risk has taken its place in the top 3. If a risk is moved off the list in this fashion, the Risk Manager will be responsible for replacing it with a new risk, arranging a mitigation strategy session, and assigning a new POC for it after the meeting.

Outside of the top 3 risks, the Risk Manager will be responsible for updating other risks. These should be done as their status changes (e.g., they are successfully mitigated)

• Communicate: The Risk Manager will keep an updated list of each risk on our risks page, which can be accessed via this link [TBD]. Any new risks not identified in a formal meeting should be communicated to the group through either informal discussion or email. Risk process reviews and feedback will be done during reflection meetings. Any request for risk reprioritization outside of formal meetings should go through the Risk Manager, who will be responsible for moving or closing the risk.

Analysis

In every reflection meeting we will analyze if the process is being followed by using the following checklist:

1. Does each risk have a probability, impact, and timeframe associated with it?
2. Do the top 3 risks have mitigation strategies?
3. Were risks reprioritized during status meetings?
4. Did the top 3 risks have trigger dates for when they should have been mitigated?
5. Did the top 3 risks have a POC assigned to them?

Furthermore, we should be able to know our risk process is working based on the following:

1. Identified risks are successfully mitigated before the trigger date
2. Problems with the project that were not originally identified as risks are minimized
3. Team members are not spending more than two hours a week due to too much risk overhead
4. The schedule takes into account identified risks and provides affordances for mitigation
5. Root cause of schedule slips should not be traced back to low priority risks

Reflection

Reflections are performed at the beginning of every iteration. Each role is assigned a specific proposal to base its reflection on. All of our reflection can be found on our reflection page, accessible via Team Reflection.

Sources

http://www.sei.cmu.edu/risk/paradigm.html
http://dogbert.mse.cs.cmu.edu/mse2005/projects/Pandora/public_html/index.html
http://dogbert.mse.cs.cmu.edu/mse2006/wikis/Simulacrum-Wiki-03292006/