Archives of Directives

Archive

DOE G 200.1-1 App E, Appendix E Stage Exit Process Guide

Functional areas: Information Technology

Describes the standard system development lifecycle (SDLC) methodology used for systems developed and maintained for the Department Of Energy.
g2001-1ae.pdf94.96KB
Version history and related documents

Superseded by

A newer version replaces this document.

View full version history

Document text

Text extracted from the attached file. Refer to the original document for the authoritative version.

Section 1

Software Engineering Methodology Appendix E Stage Exit Process Guide Table of Contents Section Page 1.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-1 Timing/Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-1 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-2 Process Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-2 Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-3 Relationship to Other System Development Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-3 Process Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1-3 2.0 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-1 Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-1 Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-1 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-2 Plan Stage Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-3 Schedule Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-3 Distribute Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-3 Receive Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-4 Prepare Action Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-4 Conduct Exit Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-5 Meeting Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-5 Management Briefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-5 Responsibility Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-6

Section 2

DOE G 200.1-1 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E-ii List of Examples Example Page 1 Stage Exit Notification Memo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-8 2 Stage Exit Distribution List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-9 3 Stage Exit Participation - LAN Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-10 4 Stage Exit Participation - Mainframe Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-11 4A Stage Exit Participation - Client/Server Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-12 5 Stage Exit Position Response Form - Sent to Approver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-13 6 Stage Exit Position Response Form - Concur With Qualifications . . . . . . . . . . . . . . . . . . . . . E.2-14 7 Stage Exit Position Response Form - Non-Concur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2-15 List of Templates Stage Exit Notification Memo Stage Exit Position Response Form DOE G 200.1-1 Change Control Page 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E-iii Revision date: 10/12/95 Author: Andy Bicocchi a. Section(s): Throughout document Page number(s): Throughout document Summary of change(s): Revise the process to align it with the Software Engineering Methodology (SEM), which is replacing the System Development Guide (SDG). b. Section(s): Throughout document Page number(s): Throughout document Summary of change(s): Changed Service Areas to the more generic Support Areas. c. Section(s): Change Control Page Page number(s): E-v Summary of change(s): Added the change control page. d. Section(s): Process measurements Page number(s): E.1-3 Summary of change(s): Revised the process measurements section; added qualifications measurements. e. Section(s): Responsibility Matrix Page number(s): E.2-6 Summary of change(s): Updated the responsibility matrix to reflect current environment. f. Section(s): Management Briefings Page number(s): E.2-5 Summary of change(s): Added management briefings section - a new process activity. g. Section(s): Diagram/Process Flow Page number(s): E.2-2 Summary of change(s): Added management briefing box to the process flow diagram. Revision date: Author: DOE G 200.1-1 1.0 Overview 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.1-1 Section: 1.0 Overview Introduction: The DOE Software Engineering Methodology (SEM) describes the standard system development lifecycle (SDLC) methodology used for systems developed and maintained for the Department Of Energy. For better manageability and control, each system development effort is organized into logical, related segments called stages. Each stage must be officially exited (approved) before the next stage can begin. The decision points at the end of each stage are called Stage Exits. A Stage Exit is the vehicle for securing the concurrence (i.e., approval) of designated individuals to continue with the project and move forward into the next stage of development or maintenance. The concurrence is an approval (sign-off) of the deliverables for the current stage of development including the project plan. It indicates that all qualifications (issues and concerns) have been closed or have an acceptable plan for resolution.

Section 3

Purpose: The purpose of a Stage Exit is to: C Allow all functional areas involved with the project to review the current project plan. This includes, at a minimum, a detailed plan for the next stage, and high-level plans for the remainder of the project. C Provide a forum to raise qualifications (issues and concerns) if issues exist that will impact the project plan. C Ensure an acceptable action plan exists for all qualifications raised. C Obtain concurrence on current stage deliverables, and to begin the next stage of development. Applicability: This process is applicable to all system development and maintenance efforts that follow the SEM. Timing/ Frequency: A Stage Exit is conducted at the end of each stage of development or maintenance. DOE G 200.1-1 1.0 Overview 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.1-2 Diagram: The following figure shows the timing of Stage Exits, relative to the SDLC. Stage Exits +))))))))0))))))))0))))))))0))))))))0))))))))0)))))))), * * * * * * * ? ? ? ? ? ? ? * * * * * * * * /))))))))3))))))))3))))))))3))))))))3))))))))3))))))))3))))))))1 *Planning*Reqrmts *Fnc Dsgn*Sys Dsgn*Programg*Soft Int*Installa* R RDefinitnR R R R& TestngR & AcptnR S))))))))))))))))))))))))))) S D L C )))))))))))))))))))))))))Q< Process Ownership: The following table identifies the Stage Exit process sponsor and process owner. The responsibilities of the process sponsor include approving the initial process definition document and changes during process improvement. The responsibilities of the process owner include assuring the process is working once implemented, and conducting ongoing process improvement. The process was originally developed with the support of a cross- functional process team. Some of the team members have since moved on to other positions, and have been deleted from the table. The team developed the Stage Exit process under the direction of the DOE Chief Information Officer. After initial implementation, some members of the team have met periodically to review process improvement recommendations. NAME RESPONSIBILITY BUSINESS FUNCTION E-MAIL PHONE Wayne Jones Process Sponsor Technical Monitor wayne.jones@ (301) 903-4655 hq.doe.gov Andy Bicocchi Process Owner Quality Assurance andrew.bicocchi (301) 903-0616 @hq.doe.gov Lew Bachman Consultant Quality Assur. lew.bachman@ (301) 903-0880 hq.doe.gov Beth Willis Consultant Software Development elizabeth.willis@ (301) 903-0878 hq.doe.gov DOE G 200.1-1 1.0 Overview 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.1-3 Change Control: The Stage Exit process is a component of the SEM. Changes to this process will be instituted using the same change mechanism that has been implemented to process changes to the SEM. All requests for change should be directed to the Manager of the site Quality Team. Relationship to Other System Development Processes: The Stage Exit process is a primary component of the DOE SDLC. Together with other processes it serves to assure a consistent and predictable outcome in the resulting software products. The Stage Exit process is complementary to other processes such as In-Stage Assessments and Structured Walkthroughs. Process Measurements:

Section 4

Defines the measurements that will allow for determining the effectiveness of the process at work. The main process measurement vehicle will be qualifications (issues) that are raised and closed. For each stage, the following qualification data will be collected: @ Quantity @ Severity Level - Low - Medium - High @ Qualifications Closed @ Qualifications Remaining Open There are a number of tools that can be used to help track qualifications. These range from a word processor like Word Perfect to a project manager like Microsoft Project. DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-1 Section: 2.0 Process Scope: The Stage Exit process begins with a notification to the extended development team (e.g., system Owner, user point-of-contact, support areas) that a stage exit has been scheduled. The process ends with the receipt of concurrence from the designated approvers to proceed to the next stage. Concurrence indicates that all known issues have an acceptable plan for resolution. Customers: The customers of the Stage Exit process are those individuals or organizations that will use the output of the process. The primary customers are: C Software development department C System owner C User point of contact (POC) C Quality Assurance (QA) Suppliers: The following individuals or organizations provide input to the Stage Exit process: C System owner C Project manager's manager C User POC C QA C Support areas Input: The following are the minimum inputs to the Stage Exit process: C System development lifecycle deliverable(s) C Initial project plan developed during the planning stage C Updated project plan revised during all subsequent stages C Issues to be addressed (generic) C Qualifications from the approvers C Issues that remain open from the In-Stage Assessment DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-2 Diagram: The following diagram depicts the Stage Exit process flow. +))))))))))))))))), PLANNING * * Stage Exit milestones STAGE * PLAN PROJECT's * defined in the project * STAGE EXITS * plan for each SEM stage * * .)))))))))))))))))- +))))))))))))))))), ALL * * Schedule exit for the STAGES * SCHEDULE * current stage; notify * CURRENT EXIT * participants (memo) * * * * .))))))))0))))))))- * ? * +))))))))))))))))), * * * Distribute current project * * DISTRIBUTE * plan and any other items * * CURRENT * needed to exit stage * * PROJECT PLAN * * .))))))))0))))))))- * ? * +))))))))))))))))), * * * Receive positions and * * RECEIVE * qualifications (if any) * * POSITIONS * from participants * * * * .))))))))0))))))))- * ? * +))))))))))))))))), * * * Prepare plans to resolve * * PREPARE * qualifications (if any * * ACTION PLANS * were raised) * * * * .))))))))0))))))))- * ? * +))))))))))))))))), * * * Present plans for addressing * * CONDUCT * qualifications and secure ? * CLOSURE MEETING * concurrence * * .)))))))))))))))))-

Section 5

+))))))))))))))))), * * Provide a briefing of status, issues, PERIODIC * BRIEF UPPER * risk, from the QA analyst's * LEVEL MANAGER * perspective * * .)))))))))))))))))- DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Project manager is the generic term for the person responsible for1 planning and day-to-day control of the project; e.g., task leader, team manager, or project leader. In the Planning Stage, participants include all support areas. 2 Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-3 Plan Stage Exits: In the Planning stage, the planned date for exiting each stage of development is identified and documented in the project plan. It is common practice for the Stage Exit date for the next stage to be more specific and the dates for subsequent stages to be high level milestones. Schedule Exit: For each stage, as soon as practical, the actual Stage Exit date should be established and the exit meeting scheduled. Two or three weeks prior to the exit meeting, a memo is sent to all persons participating in the stage exit to communicate the following information. C Notify participants that a stage exit has been scheduled. Participants include approvers (e.g., system owner), support area representatives (e.g., Network Engineering), and individuals with a need to know (e.g., contractor management). C Request that the approvers provide feedback one week before the exit meeting. This will allow the project manager time to work issues and develop action plans1 prior to the exit meeting. C Invite participants to attend the exit meeting. Examples of a memo, distribution list, and response forms are provided in the example section of this guide. Distribute Materials: The current project plan, and any other material relevant to exiting the stage, should be distributed to the participants along with the memo. Relevant materials include for2 example known issues, and unplanned deliverables. The participants should be familiar with planned deliverables (e.g. the Requirements document in the Requirements Definition stage) since it is common practice for them to review drafts as they are developed. If this is not the case, then planned deliverables also need to be distributed at this time. The project plan is dynamic and typically undergoing changes up to the last minute, and is distributed (together or under separate cover) at the same time as the stage exit notification memo. DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-4 Receive Positions: A position is required from the list of approvers. This position can be concur, concur with qualifications, or non-concur. The implication of each is as follows: C Concur - Proceed with the project according to the current plan. An example would be where the approver is not aware of any issues for the current stage. C Concur with qualifications - There are issues or concerns. The project can proceed according to the current plan if an acceptable action plan is developed for each issue by the stage exit meeting. An example would be where there is no plan for testing an interface to an existing system that is being changed. C Non-concur - There are very significant issues or concerns. The project should not move to the next stage until issue(s) are resolved. An example would be where funding for the project has been withdrawn or not appropriated.

Section 6

All qualifications (issues/concerns) must be communicated to the project manager. The position response form contains space for this purpose, however other forms of communication may be used. Responses are not required from individuals in the "Support" or "Information" categories of the distribution list; however, they are encouraged to review the deliverables and provide feedback that may have an impact on the project plan. Prepare Action Plans: The project manager must prepare an action plan to address each qualification received. Sometimes action plans extend beyond the stage exit milestone. This is acceptable, if it will not negatively impact the current project plan. These action plans are then presented at the stage exit meeting. Conduct Exit Meeting: At the exit meeting, the project manager presents positions from the approvers, along with qualifications raised during the stage exit process, and issues that remain open from the In- Stage Assessment (ISA). Action plans must also be presented for each qualification or issue. The objective is to demonstrate that all issues have been resolved, the current plan is sound, and the project is under control. The results of the meeting are documented in summary form, and include positions, qualifications, action plans, and follow up activity. Output: The work products produced when the Stage Exit process is executed consists of the following: C Positions from the approvers C Qualifications (if any) from review of the deliverables C Action plans to resolve all qualifications/issues. DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-5 Meeting Outcome: The results of the exit meeting will determine the next step in the development process. The project will proceed in one of the following directions. C Project proceeds to the next stage according to plan. There were no qualifications raised. C Project proceeds to the next stage according to plan. All qualifications raised had an acceptable action plan. C Project cannot proceed to the next stage because significant issues were raised that do not have acceptable action plans to resolve; e.g., funding withdrawn. Schedule a follow-up exit meeting to review action plans and reach concurrence to proceed. Management Briefings: Periodically, (e.g. quarterly) the quality assurance analyst will brief the senior or upper level manager (e.g. functional, or contract manager if appropriate) regarding the health and well being of the project, from the QA analyst's perspective. This will minimize the possibility of any surprises later and, if issues exhist, they can be addressed timely. The briefing should cover the following areas: @ Project status @ Issue(s) (if any) @ Project risk(s) @ Action(s) required to remove issues or mitigate risk Prior to briefing the upper level manager, the QA analyst will brief the project manager and the project managers's manager. This should be more as a matter of courtesy; there should be no surprises, since these persons are involved with the project ongoing. If serious issues exhist, the QA analyst will provide a briefing on an unscheduled basis, rather than wait until the next periodic meeting. Responsibility Matrix: The following matrix defines the responsibilities of the various parties involved in the Stage Exit process. DOE G 200.1-1 2.0 Process 5-21-97 Stage Exit Process Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-6

Section 7

Pr oj ec t M an ag er ( 1) Su pp or t A re as ( 2) Q ua lit y A ss ur an ce ( Q A ) Sy st em O w ne r U se r PO C Pr oj ec t M gr .'s M gr . ( 3) Pr oc es s O w ne r/ T ea m Schedule Stage Exit P R Distribute current project plan and P other materials Review project plan etc. R R R R R Concur/non-concur P P P P Prepare action plans P Conduct exit meeting P S Monitor process effectiveness P S Continuous process improvement S S S P P = Perform R = Review S = Support (1) Project Manager is the generic term for the person responsible for planning and day-to-day control of the project; e.g., task leader, team manager, project leader. (2) For example, Information Development, Training, Network Planning. (3) The Project Manager's manager or above. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-7 Example Forms The following pages provide filled in examples that can be used as a guide for completing the Stage Exit documents. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-8 Example 1 Stage Exit Notification Memo Date: April 15, 1996 To: Distribution list From: John Doe, Project Manager Subject: Requirements Defintion Stage Exit for the New Billing System The Requirements Definition Stage Exit for the New Billing System (NBS) has been scheduled. The exit meeting will be held on June 1, 1996 from 9:00 a.m. to 11:00 a.m. at the Important Building, room A410. Positions, qualifications, and action plans will be reviewed at this meeting. The review material is attached. A response is required by May 15, from those persons designated as approvers on the distribution list. All others are encouraged to provide feedback and attend the exit meeting. The approver's response may be a position of concur, concur with qualifications (issues), or non-concur. A position form is attached for your convenience. A non-response has the effect of a concurrence for that approver. If you have any questions, please contact me at (301) 555-1234 or Mary Smith at (301) 555-1235 for assistance. Project Manager Attachment cc: Distribution list (attached) Project notebook/file (memo only) As appropriate In the Planning Stage, the distribution list must include all support3 areas. In subsequent stages, only the support areas involved. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-9 Example 2 Stage Exit Distribution List Distribution list: APPROVAL Function A. B. Brown Client Representative Concurs that project is ready to proceed C. D. Green Project Mgr.'s Mgr. into next stage, based on completed E. F. Grey User POC deliverables for the current stage, a G. H. White Quality Assurance sound revised project plan for next stage, A. A. Azur System Owner and no open issues. SUPPORT Function3 I. J. Smith Documentation Reviews revised project plan for their K. L. Jones Network Engineering functional area involvement and services M. N. King Training that project is dependent upon. O. P. Johnson Security Provides feedback to the project manager. Q. R. Other others as appropriate INFORMATION Function Q. R. Here Owner management Provided for information purposes. S. T. There User management Feedback is welcome, but not required. U. V. Every Contractor management W. X. Where others as appropriate Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-10 Example 3 Stage Exit Participation - LAN Project

Section 8

S))) SYSTEM DEVELOPMENT LIFECYCLE STAGES / EXITS S))< Planning Reqrmts Functl System Progrmg Soft Intg Instaln Design Design & Testng & Acptn APPROVERS SE SE SE SE SE SE SE System Owner R R R R R R R User POC R R R R R R R Project Mgr.'s Mgr. R R R R R R R Quality Assurance R R R R R R R SUPPORT AREAS Network Engineering N X X X Network Operations N X X X Computer Operations N System Programming N Data Base Administration N System Software Administr. N Capacity Planning N Security N X Documentation N X X X X X Training N X X X X Records Management N X Micro Systems Research N X IRM Planning N X SE = Stage Exit. R = Participation is required. N = Notification. All areas are notified when the first Stage Exit is scheduled. X = Sample selection. Note: This is only an example. The project manager must identify those support areas who need to participate in each stage of development for a given project. The actual list of participants may vary from the example provided. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-11 Example 4 Stage Exit Participation - Mainframe Project S))) SYSTEM DEVELOPMENT LIFECYCLE STAGES / EXITS S))< Planning Reqrmts Functl System Progrmg Soft Intg Instaln Design Design & Testng & Acptn APPROVERS SE SE SE SE SE SE SE System Owner R R R R R R R User POC R R R R R R R Project Mgr.'s Mgr. R R R R R R R Quality Assurance R R R R R R R SUPPORT AREAS Network Engineering N Network Operations N Computer Operations N X X X X System Programming N X X X Data Base Administration N X X X X System Software Administr. N X X X X Capacity Planning N X X Security N X Documentation N X X X X X Training N X X X X Records Management N X Micro Systems Research N X IRM Planning N X SE = Stage Exit. R = Participation is required. N = Notification. All areas are notified when the first Stage Exit for a project is scheduled. X = Sample selection. Note: This is only an example. The project manager must identify those support areas who need to participate in each stage of development for a given project. The actual list of participants may vary from the example provided. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-12 Example 4A Stage Exit Participation - Client/Server Project S))) SYSTEM DEVELOPMENT LIFECYCLE STAGES / EXITS S))< Planning Reqrmts Fuctnl System Progrmg Soft Intg Instaln Design Design & Testng & Acptn APPROVERS SE SE SE SE SE SE SE System Owner R R R R R R R User POC R R R R R R R Project Mgr.'s Mgr. R R R R R R R Quality Assurance R R R R R R R SUPPORT AREAS Network Engineering N X X X Network Operations N X X X Computer Operations N X System Programming N X Data Base Administration N X X X System Software Administr. N Capacity Planning N X X Security N X Documentation N X X X X X Training N X X X X Records Management N X Micro Systems Research N X IRM Planning N X SE = Stage Exit. R = Participation is required. N = Notification. All areas are notified when the first Stage Exit is scheduled. X = Sample selection. Note: This is only an example. The project manager must identify those support areas who need to participate in each stage of development for a given project. The actual list of participants may vary from the example provided. Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-13 Example 5 Stage Exit Position Response Form ******** TO BE SENT TO APPROVERS ********

Section 9

Project name: New Billing System (NBS) Project stage: Analysis Return form to: John Doe, Project Manager CDSI / CXXI / Room 1234 Return by: May 15, 1996 Position: G Concur. Proceed with the project according to the current plan. G Concur with qualifications. Issue(s) exist. The project can proceed according to the current plan if there is an acceptable action plan for each issue by the stage exit meeting. G Non-concur. Significant issue(s) exist. The project should not proceed to the next stage until the issue(s) is resolved. Qualifications (issues): Approver: C. D. Whomever (please print) Signed: Date Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-14 Example 6 Stage Exit Position Response Form ******** RECEIVED FROM AN APPROVER - CONCUR WITH QUALIFICATIONS ******** Project name: New Billing System (NBS) Project stage: Analysis Return form to: John Doe, Project Manager CDSI / CXXI / Room 1234 Return by: May 15, 1996 Position: G Concur. Proceed with the project according to the current plan. % G Concur with qualifications. Issue(s) exist. The project can proceed according to the current plan if there is an acceptable action plan for each issue by the stage exit meeting. G Non-concur. Significant issue(s) exist. The project should not proceed to the next stage until the issue(s) is resolved. Qualifications (issues): 1. In the requirements document, there are no requirements for expected response times, for both the first and subsequent screens of each transaction. 2. The maximum concurrent number of users will be 150, rather than 130 as stated in the requirements document. 3. The prerequisite equipment cannot be installed earlier than October 1, 1996. This creates a 2-week variance from the current project plan of record. Approver: C. D. Whomever (please print) Signed: Signature Date April 26, 1996 Date: June 3, 1994 Appendix E Page Rev Date: October 12, 1995 E.2-15 Example 7 Stage Exit Position Response Form ******** RECEIVED FROM AN APPROVER - NON-CONCUR ******** Project name: New Billing System (NBS) Project stage: Analysis Return form to: John Doe, Project Manager CDSI / CXXI / Room 1234 Return by: May 15, 1995 Position: G Concur. Proceed with the project according to the current plan. G Concur with qualifications. Issue(s) exist. The project can proceed according to the current plan if there is an acceptable action plan for each issue by the stage exit meeting. % G Non-concur. Significant issue(s) exist. The project should not proceed to the next stage until the issue(s) is resolved. Qualifications (issues): 1. The proposed technical solution will require extensive retraining of personnel in the branch offices. There is no funding available for this activity this year or in the foreseeable future. A different solution must be explored. Approver: C. D. Whomever (please print) Signed: Signature Date April 26,1994 Templates The following pages can be copied and used for the Stage Exit documents. Stage Exit Notification Memo Date: To: Distribution list From: [project manager] Subject: [stage name] Stage Exit

Section 10

The [stage name] Stage Exit for [project name] has been scheduled. The exit meeting will be held on [date], from [start time] to [end time], at [location including room number]. Positions, qualifications, and action plans will be reviewed at this meeting. The review material is [attached or has been distributed previously]. A response is required by [date] from those persons designated as approvers on the distribution list. All others are encouraged to provide feedback and attend the exit meeting. The approver's response may be a position of concur, concur with qualifications (issues), or non-concur. A position form is attached for your convenience. If no response is received, a position of concur will be assumed for that approver. If you have any questions, please contact me at [area code/phone number or electronic address] or [alternate name, phone number] for assistance. [sign here if hardcopy] Project Manager Attachment cc: Distribution list (attached) Project notebook/file (memo only) [list individuals as appropriate] Stage Exit Position Response Form Project name: Project stage: Return form to: Return by: Position: G Concur. Proceed with the project according to the current plan. G Concur with qualifications. Issue(s) exist. The project can proceed according to the current plan if there is an acceptable action plan for each issue by the stage exit meeting. G Non-concur. Significant issue(s) exist. The project should not proceed to the next stage until the issue(s) is resolved. Qualifications (issues): Approver: (please print) Signed: Date

Something wrong with this record? Tell us