Click here to visit the new WIKI version of this site!

SDLC Release Planning

Get *ALL* 100+ Editable Word, Visio, HTML & Project Source Documents (500+ Files) Totaling 1000+ Printed Pages for Only $497 - Buy I.T. Now!

SDLC

*DOWNLOAD NOW $199.95


 

SOP 1005: Release Planning

Objective: 
The objective of this Standard Operating Procedure (SOP) is to document the first phase of the System Development Life Cycle (SDLC). 
Scope: 
This SOP identifies the business areas (Contracting Organizations) of the company to for which the business strategy, priorities, and scope of the release/project prior to involving the Performing Organizations (i.e. Engineering) will be determined. In order to implement a release effectively, SDLC upper management needs to establish the infrastructure necessary to make decisions on all priorities across business areas so that Engineering can be effective in responding to the needs of the business.
Owner: 
Chief Technology Officer

Sections:

i Definitions
1 Process Flow Diagrams
2 Roles and Responsibilities
3 Metrics
4 Procedure Activities
5 Forms
6 Exceptions
7 Tools/Software/Technology Used
8 Attachments

Related Standard Operating Procedures:

1000 Program/Project Management
1040 Requirements Definition

Get "IT"
ScalabilITy - ReliabilITy
Flexibil
ITy - AgilITy
Longev
ITy - QualITy
.doc .xls .ppt .mpp .vsd .htm EdITable; Policies, Processes, Procedures, Projects Tasks, Diagrams, Forms & Files.
DOWNLOAD
Satisfaction Guaranteed.

-->

SDLC Standard Operating Procedures:

SDLC Framework:

SDLC Gates:

SDLC Roles and Responsibilities:

SDLC Forms:

SDLC Templates:

 

SOP 1005 - Release Planning Definitions 

Release Planning refers to the first phase in the System Development Life Cycle.

The main purpose of this phase is for the business areas (Contracting Organizations) of the company to determine the business strategy, priorities, and scope of the release/project prior to involving the Performing Organizations (i.e. Engineering). In order to implement a release effectively, SDLC upper management needs to establish the infrastructure necessary to make decisions on all priorities across business areas so that Engineering can be effective in responding to the needs of the business.

One of the keys to successful Release Planning is having a business strategy for the SDLC product and identifying requests/features that are aligned to that strategy, Release Planning should also include establishing overall budgets and business plans as well as identifying the relative priority of each request being considered for inclusion in a release.

To ensure that Engineering resources are being used wisely to deliver added business value; it is essential that requests be submitted using a well-defined and consistent process.

During the Release Planning phase, feasibility studies are performed, user requirements are defined, high level estimates are produced and compared to forecasts of the Performing Organization’s capacity, business cases are prepared and all possible projects are prioritised to assist in project selection.  Scenarios may be created to investigate possible combinations of projects (features) that would be affordable based on the capacity of the Performing Organization.  Many of these activities are performed on an ongoing basis as new customer requests are submitted.

The Product Group does most of the work performed in this phase.  Since the owner of this procedure is Engineering, this document will serve to provide guidelines for the Product Group, by specifying the expected inputs and outputs needed by Engineering.  This will ensure that the Release Planning phase is a success and that the release may proceed to the next phase in the System Development Life Cycle, the Definition Phase.   

 

     

1. Process Flow Diagrams 

 

Release Planning Overview

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  Click Image to Enlarge

 

2. Roles and Responsibilities

Role Responsibility

Release Planning Review Board

The Release Planning Review Board is responsible for evaluating, prioritizing, and determining which service requests will be included in the next release.  They ultimately direct the fate of the release and are the key decision-makers in the relative prioritization of requests and resource commitments.  The Release Planning Review Board is appointed by the OCE and should include the Project Sponsor and representative(s) (Director/V.P. level) from Product Management, Channel Marketing, Engineering, Technical Support, and Program/Project Management.  With the exception of the Project Sponsor and Program manager assigned to the release, the Release Planning Review Board members remain constant release after release. The Release Planning Review Board may or may not be the same the Gate Review Board defined below depending on how the organization structure is defined.

Gate Review Board

The Gate Review Board is composed of representatives from both the Performing and Contracting Organizations, as well as the Project Sponsor, Program Manager and Program Manager.  Gate Review Boards assess the deliverables at each gate in the System Development Life Cycle to insure that requirements have been met.  Also, the Gate Review Board’s specific knowledge of the project’s goals and status allow it to make informed decisions to which they are held accountable.

 Milestone/Gate reviews provide the mechanism for the management of the Performing Organization and the Contracting Organization to make decisions concerning the scope, cost and schedule of the project.  At each review, the members of the Gate Review Board are required to make decisions that are in the best interests of SDLC.  These decisions may involve making tradeoffs to arrive at an optimal decision.  It may be necessary to omit or remove scope in order to satisfy cost and schedule constraints.  Additional cost may be approved to maintain scope and schedule commitments.  A schedule delay may be agreed upon to enable required scope to be delivered within existing budgets.  Each case is unique and must be considered on its specific merits.

Contracting Organization

The organization that contracts with the Performing Organization to develop the project/release.  The contracting organization for all the releases at SDLC is mainly the Product Group.  Other Contracting Organizations include the Technical Support Group, and the Engineering Group.

The following organizations are defined in this document as part of the Product Group:

  • Sales and Advertising: The area that sells to ISPs, affinity groups, and advertisers, in both the domestic and international markets.

  • Marketing and Product: This area manages the portfolio of features and functionality for outbound marketing.

  • Strategic Development: Research and Development group viewing opportunities in emerging markets and up-selling existing accounts.

Performing Organization

The Performing Organization is the enterprise whose employees are most directly involved in defining the user requirements and enhancing the SDLC platform or system as defined by the Contracting Organization.  In the Release Planning Phase, all the Engineering departments will be considered the Performing Organization. The Engineering Department consists of Development (Sustaining, Advanced and Strategic), Validation/Quality Assurance, Operations (OCC, Release Engineering, Database Administration, Network and Operations Engineering), Systems Engineering/Architecture and project management.

Requestor

The member of the Contracting Organization that requests a new feature or enhancement to the system. The requestor is responsible for completing a Service Request Form.

Business Analyst

The member(s) of the Contracting Organization who fully analyze and document the user requirements (Scope of Work documents). These members have a good understanding of the SDLC system and a technical background which allows them to understand the impact of each user requirement on the system. They also perform usability studies and prototype the windows and dialog flows.

 

 

 

3. Metrics

 

Metric Description

Cycle Time

Cycle time is the number of days or hours necessary to complete requirements for a SDLC Business Gate and/or Milestone.

Defects

The delivery from one group to another that performs in a sub-standard form, as measured against specification/acceptance criteria, are recorded and reported at the end of the project.  (I don't get that sentence)  Root cause analysis from the correction of defects will be categorized, tracked and reported.

Change Agents

Individuals that analyse a process and recommend ways to improve it will be reported to Engineering management.  These individuals will receive recognition for their effort to compress cycle times and/or improve quality.

 

 

4. Procedure Activities

 

The foundation of release planning is the SDLC Business Gates.  The Release Planning Procedure focuses on Gates 12 through 10. Gate 12 begins Project Start up in which a Project Sponsor and Program Manager are assigned. Gate 11 begins the process of developing an approved set of features and a release strategy. Lastly Gate 10, involves approving the Scope of Work (SOW) for which the organization will commit, and develop the requirements.

 

Activity Description

Define SDLC Business Strategy

Prior to implementing a release, it is imperative that the OCE define a Business Strategy and/or Business Plan for the SDLC product.  A well-defined Business Strategy should define the goals of the company and the type of initiatives that should be pursued.  Without such a strategy it becomes very difficult, if not impossible for the Release Planning Review Board to prioritise and to select which requests/projects should be pursued in any given release.  The remainder of this document assumes that the goals of the SDLC product are well defined and that a Business Strategy is in place.

Gather Service Requests/Funneling Process

Requests are being made from any of the following four department sources: Engineering, Technical Support, Channel Marketing and Product Management.

Requests being made can vary greatly- they can range from a request for the introduction of a major new business process, to a request for a relatively minor content change

The reasons for requests can also vary – bug fixes, content changes, ISP/client needs, product development service/feature definitions, advertisers, new content tools, new architecture, etc.

Service requests begin with the initiation and approval, or rejection, of requests in the four departments.  Each department assigns designated representatives through whom all requests within that department flow.  These designated representatives gather Service Requests Forms initiated within their department and ensure they have been justified, adequately documented and classified.  They also ensure that each request is evaluated according to the pre-defined acceptance criteria as defined in the Service Request Form.  

Initiate Request

A requestor completing a Service Request Form will initiate the request. The requestor is responsible for clearly defining the service request by completely filling out the Service Request Form and forwarding it on to their designated representatives.

 If the request is not filled out completely, the designated representatives rejects it and returns the Service Request Form back to the requestor.

Maintain Master List of Service Requests

Once the designated representatives from the functional areas accept the Service Request Forms, they are sent to the Program Management Office (PMO), which maintains a master list of all Service Request Forms from all the functional areas. The Master Request List will contain all the information entered onto a Service Request Form as well as the following information:

  • Request status (Open, Closed)

  • Review board status (Approved, Rejected, On-Hold) 

  • Reject date

  • Rejection reason

  • Approve date

  • Approval reason

  • On-hold date

  • On-hold reason

  • Assigned release name

  • Priority number (in release)

  • Interested parties/distribution list

 

Gate/Activity Description

G-10: Requirements Scope Lock-Down

  • Business Objective: Approve the Scope of Work for which the organization will commit to develop requirements.

  • Owner: Project Manager

  • Review Board: Program Sponsor, Program Manager, Project Manager, Contracting Organization(s), and Performing Organization(s)

Project Manager

The Project Manager is responsible for ensuring that the following documents are completed with quality and meet acceptance criteria defined in this Procedure.

Contracting Organization (OWN)

  • Initial Portfolio Scope

  • Business Plan Impact Assessment

  • Scope of Work

Performing Organization (OWN)

  • Project Resource Plan

Responsible for scheduling, notification, meeting materials, meeting facilitation and meeting minutes for this formal Review Board meeting.

Review Board

Review the results of the concept phase and commit to the definition and planning of a project.  Target delivery windows may be established, but this does not constitute a commitment to deliver the project as it is defined at this point.  The additional definition and planning which takes place during the definition phase will increase knowledge about the scope, cost and schedule of the project which may result in changes to any or all of those parameters.

Review Board

The Review Board’s acceptance of the approved documents by the Receiving Organization moves each SOW document to the Development Function of the Performing Organization for analysis.

Project Manager

The Project Manager ensures coordination between Contracting and Performing Organizations.  Project Managers facilitate meetings and document meeting outcomes.  This effort is focused at reducing cycle time and maintaining the highest level of common understanding between parties.  Further, the Project Manager will refine the project plan incorporating data available.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Click Image to Enlarge

G-12: Project Start

  • Business Objective: Declare the start of the project. This gate is used to kick-off finalization of the feature set and project strategy.

  • Owner: Program Sponsor

  • Review Board: N/A

Designate Program Sponsor and Project Manager

Project Start begins with the designation of a Program Sponsor and Project Manager. The Program Sponsor is designated by OCE. The Program Manager assigns the Project Manager.  

Develop Release Strategy

The OCE with assistance from the Project Sponsor and Program Manager assigned to the release are responsible for developing a release strategy, which includes the following:

  • Release timeline

  • R&D Budget

  • Affordability Percentage

  • Anchor Objectives (or Strategic Business drivers) for the release

The main deliverable from this activity is the Release Definition Document to be completed by the Project Sponsor with the assistance of the Program Manager. The Release Definition Document defines the release timeline, release objectives, business justification, high-level milestones, high level resource requirements, and risks and dependencies. Upon completion, both the Project Sponsor and Program Manager sign the Release Definition Document.

Define Release Prioritization Criteria

The Program Sponsor and Program Manager, assigned to the release are responsible for working with the OCE to develop the release prioritisation criteria.

In preparing for the initiation of a release, one of the first steps that must take place is the establishment of the prioritisation categories, relative weighting factors and rating scales that will enable the calculation and assignment of business value.

Prioritize and Define Initial Release Scope

As described above, the Service Requests Forms approved by the functional areas are sent to the Program Management Office that maintains a master list.  Upon kicking off a project, the master list is given to the Release Planning Review Board for further review and prioritisation across all groups.

The Release Planning Review Board evaluates each Service Request Form, using the pre-defined prioritisation categories/weighting factors and determines a business value rating.  Using the release timeline and budget defined above, the Release Planning Review Board determines, at a high level, which of the requests should be considered for inclusion into the release.  The output from this step is a Prioritised List of requests that should be considered for inclusion into the release. Upon completion, the Program Manager and Project Sponsor present this list to the OCE for approval. The OCE either approves or rejects the list, if the list is rejected negotiations need to take place between the Release Planning Review Board and the OCE to determine the first cut at the release scope.

All Service Requests that are dropped from the release remain on the master list maintained by the PMO for future consideration.   

Once the first cut at the release scope is approved by the OCE, the Program Manager bundles the approved Service Requests Forms together and distributes them to the Performing Organization(s).

Estimate the Scope (High Level) 

The Performing Organization Manager(s) receive the first cut of the release scope along with the Service Request Forms for each item included in the release.  The Performing Organization Manager(s) provide a “quick quote” resource, time, and cost estimate for each proposed service request and determines whether or not the request is technically feasible.  Using the pre-defined release timeline (provided by the Project Sponsor), request priority number, and the high-level development estimates, the Performing Organization Manager(s) recommend which requests can be completed in the release timeframe.  The Program Manager will set up a pre-defined end date for when estimates need to be complete and returned to the Program Manager. 

Revise Release Scope

The development estimates are delivered back to the Program Manager who organizes a meeting with the Release Planning Review Board.  If necessary, the Release Planning Review Board revises the scope and priorities for the release.  All Service Requests that are rejected are placed back on the master list maintained by the PMO for future consideration.

Finalize Release Strategy and Features

Throughout this gate, the Program Manager is responsible for ensuring the following documents are completed with quality and meet defined acceptance criteria: 

  • Release Definition Document

  • “Quick Quote” Estimate for Release 

  • Release Strategy

  • Timeline

  • R&D Budget

  • Affordability Percentage

  • Service Requests to be included 

  • Anchor objectives

Approve Release Strategy and Features

Once all the documents are completed, the Program Manager will meet with the Release Planning Review Board to provide evidence that all requirements have been met for Gate 11.

Upon approval by the Release Planning Review Board, the Program Manager communicates all materials to the Contracting and Performing Organizations. The Program Manager will establish a preliminary project plan incorporating the project strategy and high-level effort estimates received within this Gate.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Click Image to Enlarge

G-11: Project Strategy Lock-Down

  • Business Objective: Approve a set of features and project strategy

  • Owner: Project Manager

  • Review Board: Program Sponsor, Program Manager, Project Manager, Contracting Organization(s), and Performing Organization(s)

Project Manager

The Project Manager is responsible for ensuring that the documents indicated in G-11b are completed with quality and meet the acceptance criteria defined in the Release Planning Procedure (SOP 1005)) 

Organizations:

  • Project Sponsor

  • Contracting

  • Performing

Program Sponsor (OWN)

  • Project Strategy including: Timeline, R&D Budget, Affordability Percentage, Scope of Work definitions and Anchor Objectives.

Contracting Organization (OWN)

  • Market Requirements Scope of Work

Performing Organization (OWN)

  • High Level Effort Estimate

Project Manager

The Project Manager establishes a preliminary project plan incorporating the project strategy and high-level effort estimates received within this gate. Once the above documents are accepted by the receiving organization the Project Manager will call the Review Board to session and provide evidence that all requirements have been met for Gate 11.

Review Board

Establish project strategy and the initial project constraints of scope, cost and schedule utilizing such factors as R & D Budget, Affordability Models and Anchor Objectives.

 

Upon approval, all materials are communicated to the Contracting and Performing Organizations.  The communication is focused at the approved anchor objectives, project strategy, initial project constraints and scheduling. The Project Manager is responsible for communications to all participating project areas.

Create Scope of Work documents

Once the initial scope of the release is defined, Business Analysts (from the Contracting Organization) work with the initial requestors to further define the requests that have been approved by creating Scope of Work (SOW) documents (see Appendix B for Scope of Work Requirements). In some cases, work sessions will be needed with members of Development to assist with technical questions.  These work sessions should be kept to a minimum to reduce drain on the technical resources.  The Program Manager will set up a pre-defined date specifying when the SOW’s need to be completed, allowing enough time for the SOW’s to be adequately defined.  All SOW’s not complete by the pre-defined deadline are at risk to be dropped from the release by the Release Planning Review Board.

Contracting Organization performs Quality Review on Scope of Work(SOW)

The Contracting Organization reviews each SOW for accuracy and completeness before sending it to the Program Manager.  If the SOW’s are not adequately filled out, they are sent back to the requestor to be completed.

Review Scope of Work (SOW) Documents for Completeness

The Program Manager collects and bundles the SOW’s and gives them to the Performing Organization managers to provide initial high-level cost and resource estimates.

The Performing Organization reviews each of the SOW’s for completeness.  If the SOW’s are not adequately filled out, they are sent back to the Contracting Organization to be completed.  The Contracting Organization(s) are given 5 business days to complete this task.  If the SOW is not complete within the stated time period, the SOW is in jeopardy of being dropped from the release.  In such a case, the Program Manager would escalate the issue to the Release Planning Review Board to obtain approval to drop the SOW from the Release.  

Develop Preliminary Resource, Time, and Cost Estimates

Each Performing Organization (Ops, Dev., QA, MIS, and Tech. Support) reviews each SOW that impacts them and provides a Project Resource Plan that includes resource, time, and cost estimates for each SOW.  The Project Resource Plan is delivered to the Program Manager.

Collect and Distribute Estimates

The Program Manager totals all estimates and creates an overall estimate for each SOW.  The Program Manager then totals all the SOW's estimates together to develop a total estimate for the release.  Using these estimates, the Program Manager meets with the Performing Organization(s) to determine how many of the SOW's can be completed in the defined release timeframe. If there is no pre-defined timeframe, the Performing Organization(s) states how long it would take to complete all SOWs. The prioritized list created in the previous gate is now used to recommend the release scope. The Performing Organization(s), if necessary, makes a recommendation to the Release Planning Review Board on which SOW’s can be accomplished in the timeframe of the release and which SOW’s should be dropped from the release.

Perform Business Plan Impact Assessment

The Program Manager meets with the Project Sponsor to review the resource, time, and cost estimates developed by the Performing Organization(s) for the release. Also presented at this meeting are any risks, issues, and dependencies that were identified in the Scope of Work (SOW) documents that need to be addressed before the project should proceed further.

The Project Sponsor compares these estimates to the Release Strategy (which included a timeline, a research and development budget, affordability percentage, service requests to be included, and any additional anchor objectives) and develops the Business Plan Impact Assessment.  This assessment recommends whether the delivered features, timeline, and cost are still justified.

At this time, the Project Sponsor working with the Program Manager may choose to discuss various time, cost (resource), and feature (quality) options with the Performing and Contracting Organization(s).

Create Initial Portfolio Scope

Based on the discussions with the Performing Organization(s) and Contracting Organization(s), the Project Sponsor and Program Manager adjust the scope of the release accordingly and develop an Initial Portfolio Scope.  This Initial Portfolio Scope lists all the SOWs to be included in the release. The Initial Portfolio Scope is sent to the Performing Organization(s) who are responsible for revising their Project Resource Plans. 

Prepare Package for Gate Review Board

The Program Manager is responsible for scheduling, notification, meeting materials, meeting facilitation and meeting minutes for this formal Gate Review Board Meeting.  The Program Manager packages and prepares the following documents for this meeting:

  • Scope of Work Documents - Owner: Contracting Organization(s)

  • Initial Portfolio Scope  - Owner: Contracting Organization(s)

  • Project Resource Plan  - Owner: Performing Organization(s)

  • Business Plan Impact Assessment  - Owner: Project Sponsor

Review and Approve Project Scope

The Gate Review Board at this point decides whether the release is still cost justified by reviewing all of the above documents. If the above documents are approved, the requirements are locked down and the Gate Review Board commits the organization to the further definition and plans the release. This does not constitute a commitment to deliver the project as it is defined at this point. The additional definition and planning, which takes place during the Requirements Definition, will increase knowledge about scope, cost and schedule of the release that may result in changes to any or all of those parameters.

If the above documents are not approved, the Gate Review Board either decides to drop the Release (project) or negotiates with the Performing Organization(s) and Contracting Organization(s) to revise the timeline, cost (resources), and/or scope. If the timeline, cost (resources), or scope is changed, all steps in this Gate will be repeated to revise the documents needed for gate approval. 

G-10: Requirements Scope Lock-Down

  • Business Objective: Approve the Scope of Work for which the organization will commit to develop requirements.

  • Owner: Project Manager

  • Review Board: Program Sponsor, Program Manager, Project Manager, Contracting Organization(s), and Performing Organization(s)

Project Manager

The Project Manager is responsible for ensuring that the following documents are completed with quality and meet acceptance criteria defined in this Procedure.

Contracting Organization (OWN)

  • Initial Portfolio Scope

  • Business Plan Impact Assessment

  • Scope of Work

Performing Organization (OWN)

  • Project Resource Plan

Responsible for scheduling, notification, meeting materials, meeting facilitation and meeting minutes for this formal Review Board meeting.

Review Board

Review the results of the concept phase and commit to the definition and planning of a project.  Target delivery windows may be established, but this does not constitute a commitment to deliver the project as it is defined at this point.  The additional definition and planning which takes place during the definition phase will increase knowledge about the scope, cost and schedule of the project which may result in changes to any or all of those parameters.

Review Board

The Review Board’s acceptance of the approved documents by the Receiving Organization moves each SOW document to the Development Function of the Performing Organization for analysis.

Project Manager

The Project Manager ensures coordination between Contracting and Performing Organizations.  Project Managers facilitate meetings and document meeting outcomes.  This effort is focused at reducing cycle time and maintaining the highest level of common understanding between parties.  Further, the Project Manager will refine the project plan incorporating data available.

                                        

 

 

5. Forms

Form Description

Service Request Form

Forms Archive

Scope of Work Form

Forms Archive

 

 

6. Exceptions

  • Technical expertise may require that an engineer complete the Purchase Order and order the required asset(s) instead of the Office Manager.

 

 

7. Tools/Software/Technology Used

  • Procurement Tracking Tool and/or Database

 

 

8. Attachments

 

(SDLC INTERNAL USE ONLY)

Purchase Editable Documents Today

 

Creative Commons License
Systems Development Life Cycle (SDLC) by Robert E. Stewart, Sr. is licensed under a Creative Commons Attribution 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://bobstewart.com/.