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.
Superseded By:
DOE O 415.1, Information Technology Project Management on Dec 03, 2012
Version history and related documents
Superseded by
A newer version replaces this document.
- DOE O 415.1Information Technology Project Management (Dec 03, 2012)
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