18 March 2004 / Rev. 01 Cyber Blue – Team 234 Perry Meridian High School Indianapolis, IN Design Review Process Documentation This document is intended.

Slides:



Advertisements
Similar presentations
Summer Internship Program Outline
Advertisements

1 PROJECT MANAGEMENT ROLE OF KEY PERSONNEL Bernd Madauss International Space University Strasbourg February, 2011
TRANSFORMING CAPABILITY SUPPORT MATERIALS HUMAN RESOURCE MANAGEMENT FOR INNOVATION The Photonics Experience Case Study Introduction The Photonics case.
1 Colorado Department of Health Care Policy and FinancingColorado Department of Health Care Policy and Financing The Case Manager’s Guide to Critical Incident.
Development Processes and Product Planning
1 Dissertation Process 4 process overview 4 specifics –dates, policies, etc.
Systems Engineering Management
CBIIT Quality Assurance Process Preston Wood NCI CBIIT Government Quality Representative (GQR) January 2014 RS.
Project Name Steering Committee Meeting Project Manager: Project Manager Name Program Manager: Program Manager Name Project Sponsor: Project Sponsor Name.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Internal Auditing and Outsourcing
LSU 07/07/2004Communication1 Communication & Documentation Project Management Unit – Lecture 8.
Environmental Impact Assessment Prepared by: Miss Syazwani Mahmad Puzi School of Bioprocess Engineering UniMAP.
What is Business Analysis Planning & Monitoring?
Qantas Brand Refresh Kristy Dixon – Masters of Applied Project Management University of Adelaide 2013 Results of Risk Analysis Plan Hypothetical Project.
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
OSF/ISD Project Portfolio Management Framework January 17, 2011.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 4.1.
© Grant Thornton | | | | | Guidance on Monitoring Internal Control Systems COSO Monitoring Project Update FEI - CFIT Meeting September 25, 2008.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
Recap from last week Understand organizations, including the four frames, organizational structures. Explain why stakeholder management and top management.
1 The Impact of SAS 112 on Governmental Financial Statement Audits GAQC Member Conference Call January 4, 2007 Presented by Chuck Landes, CPA.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Automatic Shift Controls for ATV Sponsored by: Joel Notaro Polaris Industries Advised by : Professor George Slack Project Family: Modular, Scalable, Open.
Creating Pathways for Education, Career and Life Success Webinar: Developing a Pathways Plan January 18, 2013 Facilitated by Jeff Fantine, Consultant.
Executive Session Director’s CD-3b Review of the MicroBooNE Project January 18, 2012 Dean Hoffer.
普 华 永 道 Phase 1: Project Preparation Phase 1: Project Preparation Phase Overview Phase Overview.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
STEP 4 Manage Delivery. Role of Project Manager At this stage, you as a project manager should clearly understand why you are doing this project. Also.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
Risk Management How To Develop a Risk Response Plan alphaPM Inc.
Introducing Project Management Update December 2011.
Strategies for Knowledge Management Success SCP Best Practices Showcase March 18, 2004.
Introduction This presentation is intended as an introduction to the audit process for employees of entities being audited by MACD. Please refer to the.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
Compliance Monitoring and Enforcement Audit Program - The Audit Process.
Page 1 of 13 Texas Regional Entity ROS Presentation April 16, 2009 T EXAS RE ROS P RESENTATION A PRIL 2009.
SOLUTION What kind of plan do we need? How will we know if the work is on track to be done? How quickly can we get this done? How long will this work take.
VEX Robotics Team “Kickoff” Sept. 17 th, Topics Welcome and Introductions Contact form for ACTC Robotics Website Robotics Handbook Team Website.
Project Chartering & Approval Process
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Tata McGraw CHAPTER 4 Product and Service Design.
Pilot Grant Program EGAD Study OCCUPATIONAL & ENVIRONMENTAL HEALTH.
Company LOGO. Company LOGO PE, PMP, PgMP, PME, MCT, PRINCE2 Practitioner.
ICAJ/PAB - Improving Compliance with International Standards on Auditing Planning an audit of financial statements 19 July 2014.
DESIGN OF PRODUCTS AND SERVICES Chapter Three Copyright © 2014 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin.
7 November 2006Program Management Basics Purdue FIRST Programs Slide 1 Program Management Basics Purdue FIRST Programs Chris Fultz Rolls-Royce Corporation.
Mid-Year Performance Review Process University System of New Hampshire System Office | 5 Chenell Drive, Suite 301, Concord, NH
IS&T Project Reviews September 9, Project Review Overview Facilitative approach that actively engages a number of key project staff and senior IS&T.
MGT 437 OUTLET Become Exceptional/mgt437outlet.com FOR MORE CLASSES VISIT
Project Management PTM721S
ROLE of a Continuous Improvement LEADER
Software Project Configuration Management
PLANNING, MATERIALITY AND ASSESSING THE RISK OF MISSTATEMENT
Chapter 6: Database Project Management
Quality Workshop The Local Council Award Scheme is a great guide for good practice in our sector and a way for councils to build confidence in their.
ITPD ISSUE MANAGEMENT PROCESS SEPTEMBER 5, 2008
Phase 1 Tollgate Review Discussion Template
This presentation document has been prepared by Vault Intelligence Limited (“Vault") and is intended for off line demonstration, presentation and educational.
Chapter 2 The Process of Design.
Sweet Adelines International
Lockheed Martin Canada’s SMB Mentoring Program
Overview: ICS Evaluation Procedures
Hands-On: FSA Assessments For Foreign Schools
PSS verification and validation
ePerformance: A Process Crosswalk May 2010
WORKSHOP People Change Management Strategy
Presentation transcript:

18 March 2004 / Rev. 01 Cyber Blue – Team 234 Perry Meridian High School Indianapolis, IN Design Review Process Documentation This document is intended for use, adaptation and adoption by FIRST robotics teams. This design review process has proven to be a valuable tool for Cyber Blue and it is willingly shared with the FIRST community.

18 March 2004 / Rev. 02 Cyber Blue 234 – Design Review Process Topics: Design Review Process – Introduction Project Management Selection of Review Team Gated Review – Steps * Goals and Objectives Setting * Requirements Documents * Reviews Risk Mitigation Activity In-Service Reviews Root Cause / Corrective Action

18 March 2004 / Rev. 03 Cyber Blue 234 – Design Review Process Design Review Process – Introduction Many successful engineering based companies utilize review processes to improve the probability of success on new projects. Success may be measured by schedule, cost, reliability, safety or other factors. The intent of the review process is for the project team to present the current status of the program to an independent audit team and allow the auditors to ask questions, identify potential problem areas and direct future actions of the project team as required. The auditors are not there to tear the project apart, but instead to make it better. The auditors are usually company employees working in other areas of the business. In many companies, projects have “gated reviews”. At each major phase in the project specific requirements must be met. Once the requirements are met, the “gate” is opened to allow the project to move on to the next phase.

18 March 2004 / Rev. 04 Cyber Blue 234 – Design Review Process Design Review Process – Introduction For the 2004 FIRST season, Cyber Blue adopted a gated review process with a goal to both improve the overall design of their robot and to introduce the team members to the process. Cyber Blue implemented a 4 gate process with reviews for Concept, Preliminary Design, Detailed / Critical Design, and Production / Operational Readiness Review. In previous years, Cyber Blue has completed just one review, the Detailed Design / Critical Design Review. Reviews included technical information on the robot as well as program status on outreach activities, animation and our Chairman’s entry. Prior to the kick-off, requirements for each gate were agreed and the schedule for reviews was set. A review team was assembled and the reviewers agreed to the schedule.

18 March 2004 / Rev. 05 Cyber Blue 234 – Design Review Process Project Management The first action taken by the team was to identify an overall program schedule. Microsoft Project was used for this function. Large copies of the schedule were posted in the teams meeting rooms. The kick-off and ship dates were identified on the schedule. The team then identified target dates for major milestones such as an agreed concept, preliminary design, final drawings, drivable robot, completed robot and practice time. Design review dates were set just before each of these major milestones. This allowed the team to present the proposed decisions to the reviewer and receive their comments before making the final decisions. The program schedule is included in the following pages. The team was able to maintain most of the schedule but did not have the intended practice time before shipping the robot. In the coming weeks, the team will utilize a root cause / corrective action process to help improve this schedule for 2005.

18 March 2004 / Rev. 06 Cyber Blue 234 – Design Review Process Selection of Audit (Review) Team Cyber Blue recruited a Technical Advisory Committee (TAC) from our two main sponsors – Rolls-Royce and Allison Transmission (General Motors). The TAC members are all senior engineering managers and experienced in project and program evaluations. All TAC members committed to the review schedule. In addition to the designated reviews, the TAC members attended the Kick-Off event to see and learn the game first-hand (this proved to be a great benefit to the process) and the team Open House just before ship date.

18 March 2004 / Rev. 07 Cyber Blue 234 – Design Review Process Gated Reviews - Steps The major steps to a successful gated review process are: * Goals and Objectives Setting * Schedule of Reviews * Defining Documentation Requirements * Conducting Reviews * Risk Mitigation Activity * Root Cause and Corrective Action Where Required

18 March 2004 / Rev. 08 Cyber Blue 234 – Design Review Process Goals and Objectives Setting The first step in the process is to identify the required reviews, the goal of each review and the questions to be answered by the presenters. Each review had “exit criteria” that needed to be met before moving on to the next step. Each review built on information and decisions made in the previous review and much of the presentation material was used at multiple reviews. Cyber Blue determined that a Concept Review, Preliminary Design Review, Detailed / Critical Design Review and Production Review were required during the build season. An informal “In-Service” review will be held to evaluate robot performance in actual competitions to determine if modifications are required. The following pages identify each review and the goal and exit criteria.

18 March 2004 / Rev. 09 Cyber Blue 234 – Design Review Process Schedule of Reviews: Day 1January 10Program Kick-Off Day 6January 15Concept Review Day 13January 22Preliminary Design Day 20January 29Detailed Design / Critical Design Day 34February 12*Production / Operational Readiness Day 45February 23Demonstration Night / Open House * This review moved to February 16 th due to review team travel conflict.

18 March 2004 / Rev. 010 Cyber Blue 234 – Design Review Process Defining Documentation Requirements The team operated to two major documents – the FIRST Robot manual and the team’s “Technical Requirements Document”. The FIRST Robotics Manual provided the details of the game and build rules and requirements. The Technical Requirements Document provided additional details specific to Cyber Blue. This document was developed and revised as the build season progressed and more requirements were defined. At the final review, compliance to the Technical Requirements Document was demonstrated to the TAC.

18 March 2004 / Rev. 011 Cyber Blue 234 – Design Review Process Conducting Reviews - General Each review was student developed and student led and adapted from templates from sponsoring company processes. All but one review was held at the school, in the robot build area to provide easy access to parts and drawings. The Concept Review was very informal, with sketches, chalk board drawings and wooden prototypes. The Detailed Design / Critical Design was the most significant review with a formal slide presentation and larger review panel. This review was held at the Rolls-Royce facility. The Technical Advisory Committee watched, listened, asked questions and provided advise and comments at each step. Cyber Blue team members captured notes and comments at each review. These comments were then discussed at the next meeting and many implemented right away. Presentations and notes from each review are maintained in a file.

18 March 2004 / Rev. 012 Cyber Blue 234 – Design Review Process Conducting Reviews – Kick-Off GOAL: Introduce students and review panel to the 2004 Robotics Challenge. EXIT CRITERIA: None

18 March 2004 / Rev. 013 Cyber Blue 234 – Design Review Process Conducting Reviews – Concept Review GOAL: Gain approval of the feasibility of the robot concept(s) presented. EXIT CRITERIA / PRESENTATION: Presentation of multiple concepts and process to determine final selection. Descriptions of concepts still under consideration to carry forward. Program Schedule Matrix of the following for evaluated concepts: Critical Features / Critical Capabilities / Risks Technology Requirements / Resource Requirements

18 March 2004 / Rev. 014 Cyber Blue 234 – Design Review Process Conducting Reviews – Preliminary Design Review GOAL: Gain approval of the viability of the robot concept presented. EXIT CRITERIA / PRESENTATION: Presentation of a fully developed single concept. Explanation of final decisions leading to the selected concept. Program Schedule Description of concept selected: Critical and Key Features / Critical and Key Capabilities Preliminary Risk Matrix, Key Risks, Mitigation Actions Technology Requirements / Resource Requirements

18 March 2004 / Rev. 015 Cyber Blue 234 – Design Review Process Conducting Reviews – Detailed / Critical Design Review GOAL: Confirm the viability of the robot and progress of design activity EXIT CRITERIA / PRESENTATION Complete design definition and Analytical verification of design decisions. Safety assessment / Durability assessment / Testing plans Program schedule Description of robot Critical and Key Features and Capabilities Updated Risk Matrix, Key Risks, Mitigation Actions Technology Issues / Resource Issues

18 March 2004 / Rev. 016 Cyber Blue 234 – Design Review Process Conducting Reviews – Fabrication / Operational Readiness GOAL: Confirm the viability of the robot to be constructed as designed. Confirm the viability of the robot to perform as intended. EXIT CRITERIA / PRESENTATION Confirmation that the Requirements of FIRST have been met Confirmation that the Requirements of Cyber Blue have been met Robustness of design Capabilities Program Schedule

18 March 2004 / Rev. 017 Cyber Blue 234 – Design Review Process Conducting Reviews – Demonstration Night / Open House GOAL: Demonstration of robot capabilities, driving, strategy in action. Celebrate completion of the program

18 March 2004 / Rev. 018 Cyber Blue 234 – Design Review Process Risk Mitigation Activity As part of the overall review process, risks were identified during each phase of the project and discussed internally and with the TAC. The team was introduced to a process of “IF / THEN” risk identification and mitigation. Each student was required to identify 3 risks to add to the overall risk matrix. IF – Identify an action or event that might occur THEN – Identify what happens when the IF occurs LIKELIHOOD – Identify how likely the IF statement is to occur IMPACT – identify the impact to the program when the IF occurs Likelihood and Impact are indicated as Low (L), Medium (M) or High (H) MITIGATION - Identify what can be done to remove or reduce the likelihood of the IF occurring

18 March 2004 / Rev. 019 Cyber Blue 234 – Design Review Process Risk Mitigation Activity EXAMPLE IF the pneumatics lose pressure when power is cut THEN the robot might drop back to the floor LIKELIHOOD – High with the wrong solenoids IMPACT – HIGH (loss of 50 points) MITIGATION – Use only double acting solenoids so that pressure is maintained when power is cut at the end of the match.

18 March 2004 / Rev. 020 Cyber Blue 234 – Design Review Process Risk Mitigation Activity Risks are then ranked by likelihood and impact and effort is focused on mitigating the higher likelihood and higher impact risks first. At one of the reviews, one member of the TAC also suggested we also identify cost of mitigation in our matrix. Cost could be dollars or time or impact to the rest of the robot design. This added information lets the team decide to mitigate some risk that might be low likelihood / low impact that is low cost or very easy to correct. Some risks cannot be mitigated due to costs, time, weight, power or other factors.

18 March 2004 / Rev. 021 Cyber Blue 234 – Design Review Process In Service and Post Season Reviews: During competitions, the team is completing ongoing, informal “In-Service Reviews” based on how the robot performs during matches. The data obtained from competition performance will be captured and used to make modifications to the robot and to improve future designs. A formal “post season” review will again identify what the team and the robot did well and what could be improved. Notes from this review will be used as the team launches the 2005 first season.

18 March 2004 / Rev. 022 Cyber Blue 234 – Design Review Process Root Cause / Corrective Action: The team will be utilizing a Root Cause / Corrective Action (RCCA) process to continually improve the performance of the team and the robot. The first RCCA event will be completed during the competition season. This review will address the causes of the schedule delays leading to limited practice time for the robot and will be led by a Black Belt / Six Sigma expert from Rolls-Royce. Following the competition season, other RCCA events will scheduled as required.

18 March 2004 / Rev. 023 Cyber Blue 234 – Design Review Process Electronic Data: This document may be downloaded electronically from either Resources Tab - Cyber Blue 234 Design Review Process 2004 (Or) - Team Organization Section, Cyber Blue 234 Design Review Process 2004 Questions or Comments to: Chris Fultz -