Docstoc

Software Project Plan

Document Sample
Software Project Plan Powered By Docstoc
					This is a template a company can use to propose a software development project. This
template includes a project overview, project organization, project management
approach, configuration, quality assurance, deployment plan, pilot plan, conversion
approach, and much more. In addition, this template may be customized to provide for
any industry specific language that may be necessary. This template is ideal for small
businesses or other entities that want to propose a software development project.
               Document Name:         Software Project Plan
                   Project Name:      Project Name
                       Group Name:    Group Name


                            999999            Document Version:      nn.rr
                            00000             Document Revised:      MM/DD/YY
                            999999          Document Master List:    Link to Document Master List
                            888888             Template Version:     1.4
        Process Version                    Template Release Date


                           PROCESS ASSETS LIBRARY LINKS
       Business
     Technology
         Group:
         ETPC:
      Business:


                              DOCUMENT RELEASE NOTICE
Revisions to this document will be published to the Process Assets Library. Electronic copies outside the
PAL and all hard copies are uncontrolled and may not be the latest version. Users of this document are
responsible for using the most current version.
                            Name         Org/Group            Role              Phone               Date
     Prepared By:
 Peer Reviewer(s):
     QA Reviewer
      (if required):
     Approved by:
For issues related to document control, location or access, please notify the contact(s) below:
       Name               Org/Group                  Role                             Phone



                                             GLOSSARY
           Enterprise Glossary:




                                            Vendor – Proprietary
                                                                  Project Name Software Project Plan nn.rr



                                         REVISION HISTORY
Rev. #      Date          Sect./Page #            Revision Summary                          Author
1.0       MM/DD/YY




                                      Document Usage Information
The format captured within this document does not supersede good judgment nor does it necessarily
indicate order of execution. It is intended as a guide, as a shell to be modified according to the project’s
needs. The components contained here are recommendations only. Each change initiative must
determine which components are applicable based on the type of change.
NOTE: When publishing this document, the portions in blue italics are instructional only and should be
removed.



Project Terminology
Update this section with terms specific to the project. If they are general process related terms, they do
not need to be included here.
   #              Term                                          Description
   1.
   2.




Revision Date: MM/DD/YY                                                                          Page 3 of 31
Document Version: nn.rr
                                                                                             Project Name Software Project Plan nn.rr


                                                       TABLE OF CONTENTS
      Project Terminology ........................................................................................................................... 3
1.0   PROJECT OVERVIEW ......................................................................................................................... 6
      1.1 Background ............................................................................................................................... 6
      1.2 Scope and Impacts ................................................................................................................... 6
           1.2.1 System Impact ............................................................................................................... 6
      1.3 Communications ....................................................................................................................... 7
2.0   PROJECT ORGANIZATION ................................................................................................................ 8
      2.1 Staffing Plan & Responsibilities .............................................................................................. 8
      2.2 Interface Control ....................................................................................................................... 9
3.0   PROJECT MANAGEMENT APPROACH .......................................................................................... 11
      3.1 Plan Management .................................................................................................................... 11
      3.2 Scope Management ................................................................................................................ 11
      3.3 Monitoring and Control .......................................................................................................... 11
      3.4 Risks, Assumptions & Issues ................................................................................................ 11
      3.5 Operational Process ............................................................................................................... 12
           3.5.1 Tools, Techniques and Methods .................................................................................. 12
4.0   CONFIGURATION MANAGEMENT PLAN ....................................................................................... 14
5.0   QUALITY ASSURANCE PLAN .......................................................................................................... 15
      5.1 Quality Objectives ................................................................................................................... 15
      5.2 Quality Activities ..................................................................................................................... 16
6.0   RELATED DOCUMENTS ................................................................................................................... 17
7.0   DEPLOYMENT PLAN ........................................................................................................................ 18
      7.1 Scope ........................................................................................................................................ 18
           7.1.1 Goals & Objectives ....................................................................................................... 18
      7.2 Technology Deployment Approach ...................................................................................... 18
      7.3 Post Deployment Transition .................................................................................................. 19
           7.3.1 Participants................................................................................................................... 19
           7.3.2 Timeframe .................................................................................................................... 19
           7.3.3 Handoff to Business as Usual ...................................................................................... 19
      7.4 Escalation Plan ........................................................................................................................ 19
      7.5 Contingency Plan .................................................................................................................... 19
           7.5.1 General Considerations ............................................................................................... 20
           7.5.2 Situations Addressed ................................................................................................... 20
8.0   PILOT PLAN ....................................................................................................................................... 21
      8.1 Scope ........................................................................................................................................ 21
           8.1.1 Goals & Objectives ....................................................................................................... 21
           8.1.2 Schedule Overview ...................................................................................................... 21
      8.2 Pilot Design.............................................................................................................................. 22
           8.2.1 Requirements ............................................................................................................... 22
           8.2.2 Data Management Process.......................................................................................... 22
           8.2.3 Environment ................................................................................................................. 22
9.0   DRESS REHEARSAL PLAN ............................................................................................................. 23
      9.1 Scope ........................................................................................................................................ 23

Revision Date: MM/DD/YY                                                                                                                   Page 4 of 31
Document Version: nn.rr
                                                                                              Project Name Software Project Plan nn.rr


          9.1.1 Goals & Objectives ....................................................................................................... 23
          9.1.2 Schedule Overview ...................................................................................................... 23
     9.2 Dress Rehearsal Design ......................................................................................................... 23
10.0 CONVERSION APPROACH .............................................................................................................. 24
     10.1 Scope ........................................................................................................................................ 24
     10.2 Target Business Process Flows ............................................................................................ 24
          10.2.1 High Level Summary of Target Business Process Flows ............................................ 24
          10.2.2 Target Business Process Steps Description ................................................................ 25
     10.3 Conversion Approach (If Applicable) .................................................................................... 25
          10.3.1 High Level Summary of Conversion Steps .................................................................. 25
          10.3.2 Legacy Files to Be Converted ...................................................................................... 25
          10.3.3 Legacy Files/Information Not Being Converted ........................................................... 26
          10.3.4 Key Target System Files Created by Conversion / Static Run .................................... 26
          10.3.5 Target Database Changes ........................................................................................... 26
          10.3.6 Predecessor Task (inc. conversion prep activities, operational tasks, tasks by other
          applications, etc.) ...................................................................................................................... 26
          10.3.7 Successor Tasks (Includes Operational Tasks, Tasks by Other Applications, Etc.) ... 27
          10.3.8 Balancing Tasks (Related to Conversion Activities) .................................................... 27
     10.4 Implementation Approach (If Applicable) ............................................................................. 27
          10.4.1 Target System Actions Summary ................................................................................ 27
          10.4.2 Impacted Screens / User Interfaces ............................................................................. 27
          10.4.3 Reports (for Target systems) ....................................................................................... 28
          10.4.4 Forms/Correspondence ............................................................................................... 28
          10.4.5 System Interfaces (New or Modified Interfaces on Target Systems)........................... 28
          10.4.6 Target Database Tables / Master Template Files ........................................................ 28
          10.4.7 High Level Summary of Implementation Steps ............................................................ 29
          10.4.8 Predecessor Task (Includes Pre-Implementation Technical Tasks, Operational Tasks,
          Actions Required by Other Systems, Etc) ................................................................................. 29
          10.4.9 Successor Tasks (Includes Post-Implementation Technical Tasks, Operational Tasks,
          Actions Required by Other Systems, Etc) ................................................................................. 29
     10.5 Environment Requirements ................................................................................................... 29
          10.5.1 Physical Environment ................................................................................................... 29
          10.5.2 Logical Environment / Interface Diagram ..................................................................... 30
     10.6 Security Level .......................................................................................................................... 30
          10.6.1 Authentication .............................................................................................................. 30
          10.6.2 Entitlement Chart ......................................................................................................... 30
     10.7 First Day / Last Day Procedures ............................................................................................ 30




Revision Date: MM/DD/YY                                                                                                                   Page 5 of 31
Document Version: nn.rr
                                                                Project Name Software Project Plan nn.rr




                                1.0 Project Overview
1.1 Background
Brief text describing project background. An official statement of requirements is available as a part of
the Project Charter document of this project. Insert a link to Project Charter and Business Requirements.

1.2 Scope and Impacts

#       Item                                 Description
1       Project Type & Justification         Large/Small Project/Maintenance/Testing Only/Technology
                                             Support Service


2       Budget/ Estimated Effort

3       Project Start Date
4       Expected Project End Date


1.2.1 System Impact
This table shows the systems/areas impacted by this initiative and provides an overview of the actions
they need to perform for this initiative. A link to a separate Impact Analysis document, if it already
exists, can be included here and used in place of the table below. The tables below can be reused to
determine associate and customer impact. Information for this table is provided by the SMEs. This
section will contain the impact analysis; items impacted, new items to be created, existing items to be
changed, possible ripple effects on integration, cost impact, resource impact, etc. Include impacts to
Associates and Customers.
    #     Impacted System                                        General Approach
    1     System Name –                      System’s general approach or short description of actions
          EXAMPLE: FAST                         required to meet this initiative’s needs.
                                             EXAMPLE: Serve as the SOR (system of record) for
                                                Affinity/Military Bank account information
                                             EXAMPLE: Create a new batch feed to FSCICS




Revision Date: MM/DD/YY                                                                       Page 6 of 31
Document Version: nn.rr
                                                                Project Name Software Project Plan nn.rr




  #                                 Out of Scope System and Description
  1    The following systems/areas have participated in HLD meetings and have determined they have
       no impact (development or testing requirements) for this initiative. List Systems and Persons
       Names who are identified as having no impact
           FAST (Joe Smith)
           TAPS (Jane Wilson)


1.3 Communications
Describe the handling of communications for the project team (preferred types & alternatives, response
time expectations, frequency of communication, develop criteria to determine who to include and when to
include, describe when certain communication modes are used, escalation path, etc.). Provide the level of
detail appropriate for the project.




Revision Date: MM/DD/YY                                                                      Page 7 of 31
Document Version: nn.rr
                                                                   Project Name Software Project Plan nn.rr



                           2.0 Project Organization
2.1 Staffing Plan & Responsibilities
Define the number and types of personnel required for the project, the skill levels of the personnel and the
time and duration for which the personnel will be needed.
This list serves as your Project Team structure. Key responsibilities of Project Manager, software
Technology project manager, SDM, AM/ATL, QAA, CM Engineer, members of Change Control Board,
should be listed. Ensure business partners and any interfacing group members are also included.
Provide the level of detail necessary for management of the project. All individuals listed should receive
copies/updates to this section.
The examples have an extensive list of responsibilities, but the roles are intentionally left blank, as people
might assume different roles depending upon project needs and might have multiple responsibilities. The
completed table should have a name, organization, contact number, along with their responsibilities; if
desired, a role name may be assigned as well, e.g., Test Manager.
Note: If you maintain a separate project contact list which contains/fulfills this data, then delete the table
and provide a <link> to the contact information.


 Role         Name           Org.        Contact       Responsibilities
                                         Number
 Test         John Smith     CRE         204-345-      Test all phases as per Test Planning section.
 Manager                                 7865          Complete Test planning section of SE Template etc.
 Configurat   Adam           CRE         NNN-          Creating SCM Plan and oversee all SCM activities in
 ion          Gilchrist                  NNN-          the project. Participate in SCM Audit, etc.
 Manager                                 NNNN          Identify Configurable Item(s), Identify Baseline
                                                       item(s), Release CIs to Baselines, Evaluate Change
                                                       Impact, Approve, Authorize Change, Review,
                                                       approval & release of changed items, Maintain
                                                       Configuration Register
 .            Dean Jones     CRE         NNN-          Accountable for the production delivery as well as all
                                         NNN-          other change (non-initiative) of a functional capability
                                         NNNN          (group of application). Includes resources, expenses,
                                                       and quality. Escalation point for the Application Team
                                                       Lead
                                                       Oversee management of the production delivery as
                                                       well as all other change (non-initiative) of a functional
                                                       capability (group of applications). Includes
                                                       resources, expenses, and quality.
                                                       Responsible for multiple Development Leads and
                                                       technical Team Members. Staffs initiatives
                                                       appropriately to meet project objectives. Escalation
                                                       point for Development Lead.
                                                       Works with technical team to develop project
                                                       schedule, attends overall project team meetings,
                                                       coordinates efforts with TST project and technical
                                                       teams.
                                                       Conducting Baseline Audits, Tracking configuration
Revision Date: MM/DD/YY                                                                            Page 8 of 31
Document Version: nn.rr
                                                                 Project Name Software Project Plan nn.rr


 Role         Name           Org.       Contact      Responsibilities
                                        Number
                                                     issues to closure. Responsible for the completion of
                                                     the Software Project Plan.
                                                     Accountable for coordinating all of the
                                                     services/expenses of a given functional capability
                                                     (group of applications) delivered to a business
                                                     partner, both initiative and BAU. Aligned to
                                                     Relationship Manager/Business Partner.
                                                     Accountable for managing the resources and for
                                                     deliverables within the initiative lifecycle.
                                                     Accountable for coordinating the technology
                                                     resources within the project model and technical
                                                     deliverables within the initiative lifecycle..
                                                     Manages the complete lifecycle of an initiative,
                                                     including all resources/expenses in the project
                                                     model.
                                                     Complete Deliverables and updates in a timely
                                                     manner according to Detailed Schedule (workplan).
                                                     Respond to Technical Team requests in a timely
                                                     manner.
                                                     Communicates all known project information to the
                                                     Technology Managers and Leads in a timely and
                                                     appropriate manner (in writing).
                                                     Coordinate project across multiple lines of business,
                                                     both operational and technical.
                                                     Provides technical infrastructure support to
                                                     coordinate, design, build, and improve required
                                                     functionality.
                                                     Supply Chain Management manages the vendor
                                                     proposal and contract process for the initiative as
                                                     required.
                                                     Engage ET&D Infrastructure
                                                     Initiate Deployment Activities




2.2 Interface Control
Interface control activities coordinate changes to the project’s configurable items with changes to
interfacing items outside the scope of the plan. Hardware, system software, support software, and
deliverables should be examined for potential interfacing effects on the project.

Please provide the following:
     Nature of the interface
     Affected organizations
     How the interface code, documentation, and data are to be controlled

Revision Date: MM/DD/YY                                                                        Page 9 of 31
Document Version: nn.rr
                                                               Project Name Software Project Plan nn.rr


       How the interface control documents are approved and released into a specified baseline.

The following are the interfaces in the project:
   <ET&D Infrastructure>
   <Business Partner system>
   <Business Partner tools>
   <ESG tools>




Revision Date: MM/DD/YY                                                                    Page 10 of 31
Document Version: nn.rr
                                                                     Project Name Software Project Plan nn.rr



                 3.0 Project Management Approach
3.1 Plan Management
         Activities and responsibilities for continued project planning
         Update frequency for the Project Plan
         How changes to the plan are evaluated and approved
         How changes to the plan are to be made and communicated


Activity                     Responsibility                 Frequency
Project Plan Review,                                        Beginning of the project
Approval and Release

3.2 Scope Management
Describe how changes to scope and requirements will be managed and controlled on this project. Provide
the name(s) of the person(s) whose approval is necessary on changes to project scope. Are there
different types of scope changes that require different levels of approval? How long can scope be
changed - is there a “freeze date"?

3.3 Monitoring and Control
The purpose of this section is to ensure that the project defines:
             Reporting mechanisms
             Reviews and audits for project control
             Report formats
             Relationships between monitoring & QA or Configuration Management
           Tools and techniques used to monitor adherence to this plan
This should be defined as part of the Operational Process for the project or in tables within this section.
Describe how the project costs will be tracked and how budget variances will be handled.
Describe how project effort will be tracked and how schedule variance will be handled. Will all project
team members be required to report time worked on each task? If so, what tool(s) will be used? Are there
criteria below which schedule variance is not reported?

3.4 Risks, Assumptions & Issues
                         Risks                                               Assessment
Risk information (identification, mitigations and        Insert link to FMEA, Risk Assessment or equivalent
contingency plans ) will be assessed and tracked         here.
as an integral part of this project


  #                                          Assumption                                          Confirmed
                                                                                                    by

Revision Date: MM/DD/YY                                                                         Page 11 of 31
Document Version: nn.rr
                                                                        Project Name Software Project Plan nn.rr


  #                                           Assumption                                               Confirmed
                                                                                                          by
 1        Assumptions about People, e.g., Hiring/Staffing, Resources, Skills, Organizations,
          Management Commitment & Ownership, etc.
 2        Assumptions about Processes, e.g., Training/Education, Communication,
          Workflow, etc.
 3        Assumptions about Technology, e.g., System Development, Equipment, etc.


                  Issue Management
Identify criteria for issue prioritization and closure.      Insert link to Issues List or equivalent here
Describe management of issues (how long before
escalation, how often reviewed/updated).



3.5 Operational Process
The primary purpose of this section will be to define the project’s process in terms of deliverable
commitments and activities that will be accomplished.

Insert link to the DML, if used. The DML Document Master List will reflect the deliverables to be produced
for the project.

Insert link to MS Project Work plan or WBS Project Schedule.

Define activities, verification and validation and work items for milestones.
          Define the frequency of project status reports, who will prepare it and list the recipients
          Define the frequency and list of participants for Project Team meetings
          Project meetings that will include a governance event must be attended either by the project
               sponsor or delegate with decision authority
          State any additional PMRs that will be conducted in the project apart from phase end
          Define project-level tailoring


3.5.1 Tools, Techniques and Methods
Specify in the appropriate section below any tool, technique or method that will be employed during the
project’s lifecycle to manage this effort. This should include not only the standard tools identified below
but also any others that may require expertise from project team members.

3.5.1.1     Tool Use Identification
Place a check mark next to those tools which are being used for this project. Modify the table to
add/delete tools, change source or purpose as needed. Note: If testing tools are NOT identified in the
Test Plan, they may be identified here.
              Tool Description                 Source               Purpose
Standard Tools In Use
           Vendor                              Third Party          Effort Tracking


Revision Date: MM/DD/YY                                                                               Page 12 of 31
Document Version: nn.rr
                                                          Project Name Software Project Plan nn.rr


          Tool Description                Source        Purpose
        Vendor/Process Assets Library     Third Party   Document Retention &
        (PAL)                                           Storage


        Microsoft Word                    Third Party   Documentation
        Microsoft Excel                   Third Party   Documentation
        Microsoft Visio                   Third Party   Presentation/
                                                        Org Chart
        Microsoft Outlook                 Third Party   Communication
        Microsoft Project 2000            Third Party   Schedule/detailed plan
        Microsoft PowerPoint              In-house      Documentation/
                                                        Presentation
        Vendor/Work Execution             In-house      Work in Process
        ITCI                              In-house      Incident Tracking
        Change Man                        Third Party   Configuration
                                                        Management
        Peregrine                         Third Party   Problem Ticket Tracking
        Vendor                            In-house      Process Compliance
        Other (Specify – add additional
        rows as needed)




Revision Date: MM/DD/YY                                                              Page 13 of 31
Document Version: nn.rr
                                                                Project Name Software Project Plan nn.rr




              4.0 Configuration Management Plan
Follow the Enterprise or BTG / CIO Group Configuration Management Policy for documenting and
planning how the project will manage the configuration of all work products. View the Configuration
Management Supporting Process page in the Waterfall Process Navigation Tool




Revision Date: MM/DD/YY                                                                      Page 14 of 31
Document Version: nn.rr
                                                                   Project Name Software Project Plan nn.rr




                        5.0 Quality Assurance Plan
The purpose of this Quality Assurance Plan (QAP) is to define the techniques, procedures, and
methodologies that will be used for your project. The project QA Plan provides a road map for instituting
software quality assurance in your project.

Quality Assurance is an “umbrella activity” that is applied at each step in the software process. Your QA
Plan component of the Software Project Plan should encompass your planned approach for the effective
application of methodologies and tools, formal technical review, peer review approach, process to handle
change control and insure traceability is retained.

The use of this plan will help assure the following:
 (1) That software development, evaluation and acceptance standards are developed, documented and
followed.
(2) Planning for the reviews (SPP, MR, FTR) has been documented within your plan.
(3) How you will communicate results of software quality assurance reviews and audits to Senior
Management.

External quality records for the project will be maintained in the QAG folder. Project quality records will be
maintained on Vendor <provide link>

If a BTG or Divisional QA Plan exists place link here and note deviations.

5.1 Quality Objectives
Include a link to the Project Charter or BRD to reference CTQs that are inclusive of these items,
Functionality, Usability, Performance, Reliability, Readiness, Portability, Documentation, Maintainability,
Information quality (validity, accuracy, timeliness and completeness).
The quality objectives for the project are given below as examples:
S#   Quality Factors                Quality Objectives for the Software/Solution/Deliverables
1.   Functionality                  Example: Should meet all requirements stated in the HLD, LLD, Test
                                    scripts
2.   Reliability                    Example: Reviews should be completed within the 3 day SLA
                                    Audit NCR should be closed within 20 days of the Audit Closing
                                    Meeting
3.   Maintainability                Example: Should be well-structured and well-documented with all
                                    planned QA Reviews (SPP,MR,FTR)
4.   Readiness                      Example: Fully tested, Technical Review completed, Ready for
                                    install
5.   Others




Revision Date: MM/DD/YY                                                                          Page 15 of 31
Document Version: nn.rr
                                                                     Project Name Software Project Plan nn.rr


5.2 Quality Activities
The purpose of this section is to tailor the quality assurance activities to the needs of this project.

The quality activities for the project are given below as examples:
       Activity             Accountability             Estimate                     Example
Peer Review               Project Team           Ex: 20 person hours      Example: HLD/Walkthrough
                                                                          - The HLD will have a
                                                                          walkthrough to ensure all of
                                                                          the critical components and
                                                                          business requirements have
                                                                          been addressed.
QA Review                 QA Group               Ex: 3 person hours       Example: SPP will have a
                                                                          QA review completed to
                                                                          ensure the proper planning
                                                                          objectives have been
                                                                          addressed
Management Review         Project Team           Ex: 5 person hours       Example: Management
                                                                          Review will take place in
                                                                          order to communicate
                                                                          project risk, status, etc. to
                                                                          Senior Management
Technical Review          Technology             Ex: 1 person hour        Example: TR will be
                          project manager                                 completed before the
                                                                          product is released into the
                                                                          production environment.
(if sampling) Will
reviews be performed
on deliverables?



Process References
For additional information on Quality Activities review the Enterprise or BTG / CIO Group Peer Review
and or Quality Assurance Policies and or Process Handbooks.
View the Quality Assurance Supporting Process page in the Waterfall Process Navigation Tool.




Revision Date: MM/DD/YY                                                                             Page 16 of 31
Document Version: nn.rr
                                                                   Project Name Software Project Plan nn.rr




                             6.0 Related Documents
<List related documents for this initiative and their PAL links>


      Document Name               Version #                                PAL Link
 Project Charter                 <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Business Requirements           <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Impact Assessment (IA)          <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 High Level Design (HLD)         <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Master LLD                      <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Test Plan(s)                    <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Project Roster/Contact List     <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 ET&D Infrastructure
                                 <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Documentation
 Issues List                     <vXX.XX>       <Insert links to the PAL folder in which the document resides. >
 Other                           <vXX.XX>       <Insert links to the PAL folder in which the document resides. >




Revision Date: MM/DD/YY                                                                        Page 17 of 31
Document Version: nn.rr
                                                                   Project Name Software Project Plan nn.rr




                                 7.0 Deployment Plan
    Not            <If this document section does not apply to your project, enter an ‘NA’ here, delete
 Applicable        subsections below and move to the next section.>


What is a Deployment Plan?
The purpose for the Deployment Plan is to outline the method, techniques, and measurements to guide
the deployment and implementation of the change initiative or project and to identify problems or issues
that may arise during the execution with a detailed action plan for minimizing the impact.

7.1 Scope
7.1.1 Goals & Objectives
The success of the deployment is dependent on certain events taking place, and certain aspects of the
change project working properly. It is crucial that the most vital aspects of the deployment be outlined in
this section.

7.1.1.1    “Show Stopper” Events
“Show stopper” events are those, which will stop execution of the project. It is important to understand
what events need to be successfully deployed in their original form to continue moving forward. “Show
stopper” events stop the other aspects of deployment, until the issue is resolved.

7.1.1.2    High Priority Events
A high priority event is a task or aspect of the initiative that should be given great attention. This event
must be completed to finish implementation. These are not as crucial to the process as “show stopper”
events. However, high priority events must be resolved within an agreed upon window to continue with
the deployment.

7.1.1.3    Low Priority Events
These events are necessary to the project or initiative and must be completed; however the timing is not
crucial to the success of deployment. These events can be resolved after the change project has been
implemented.

7.2 Technology Deployment Approach
The general approach to technology deployment should be outlined here.
The technology deployment plan gives the deployment team the ability to identify application and
balancing contacts and serves as a tool for cross-referencing and verifying the information that
applications submit throughout the process. Information that should be gathered include, but not limited
to; participants, application being changed, assumptions made by participant.
The plan for technology deployment should include information pertaining to the following, as a minimum:
         Control room location and dates (if applicable)
         Staffing matrix for the control room
         Communication protocol for deployment (e.g., wallet cards, status lines, update meetings)
Revision Date: MM/DD/YY                                                                          Page 18 of 31
Document Version: nn.rr
                                                                 Project Name Software Project Plan nn.rr


       Participant guide listing the parties involved in deployment from internal and external support, and
        field support (e.g., NHL liaison for initiatives impacting Banking Centers)
        First Day Processing considerations (any special instructions for initiating the changed
         processing)
The plan should be updated and distributed during workgroup meetings, or otherwise on a regular basis.
It is important that this plan is well documented and the participants and responsible parties are made
known of the progress.

7.3 Post Deployment Transition
7.3.1 Participants
The participants that will use the project or initiative in normal production need to be listed here. The
team should keep in mind the end-users and groups support them. All the appropriate relationships and
contact information should be documented here; this will be the point of contact to verify readiness and
coordinate to resolve issues.

7.3.2 Timeframe
During the early stages of deployment, the normal production teams and support groups, to define when
the deployment team will be rolling off the initiative and when the normal production support groups will
be fully supporting the end-user again.
NOTE: The timeline should take into account a mutually decided upon window of overlap, and staged roll-
off of the deployment team.

7.3.3 Handoff to Business as Usual
The hand-off to business as usual should be documented as a timeframe and phased process. It is
highly suggested that this be set as a formal meeting, incorporated into an afternoon of final updates to
the support groups and end-users along with an opportunity to ask questions of the subject matter
experts, as well as the deployment team.
After the handoff occurs, the Application Control Plan will come into effect, so be sure to include a
review and agreement upon the Control Plan, Service Level Agreements, etc. during the Handoff
meeting. This is also a good time to review and confirm the VENDOR Data Collection Plan.
At the handoff meeting, be sure to set up the Lessons Learned activity.

7.4 Escalation Plan
This section is used to provide details of the plan to determine when and whether the deployment team
should discontinue a rollout and initiate the contingency plan, or continue with the deployment, based on
any risk identified during execution.
This plan should include the process to communicate between the technicians, command center,
deployment team, project management team, the client or any other responsible parties. The escalation
process allows the information to reach those persons with the power to make the decision to continue or
to cease and rebuild.

7.5 Contingency Plan
The contingencies should be done in great detail with special attention paid to the responsible parties and
the contacts for each contingency. This will expedite the resolution of issues, should they come up during
Revision Date: MM/DD/YY                                                                        Page 19 of 31
Document Version: nn.rr
                                                                   Project Name Software Project Plan nn.rr


implementation. The plans will be detailed and an example of at least one life of an issue should be
documented here

7.5.1 General Considerations
List any general situations to consider when looking at mitigating risk or instituting a contingency plan.

7.5.2 Situations Addressed
Describe specific situations that can be overcome with a contingency plan. These situations can take
place at any point in the project, including implementation. Include the probability of the situation
happening (H,M,L), the degree of impact (H,M,L), describe the impact of that situation, describe any
specific action that will reduce the probability of the situation occurring.
Specific actions plans including communication will be detailed in the Execute/Deploy plan. Note:
Outstanding issues should be added to the project issues list.




Revision Date: MM/DD/YY                                                                          Page 20 of 31
Document Version: nn.rr
                                                                    Project Name Software Project Plan nn.rr



                                        8.0 Pilot Plan
    Not           <If this document section does not apply to your project, enter an ‘NA’ here, delete
 Applicable       subsections below and move to the next section.>


What is a Pilot Plan?
The Pilot Plan Template provides an outline to the design and criteria expected in a real-world scenario to
realize the initial impact to customers and associates. A Pilot allows for viewing these expected benefits
during a small-scale deployment. Use of a Pilot and the Pilot Plan is highly suggested for projects with
high customer and associate impact.
A Pilot differs from a Dress Rehearsal in that a Pilot is a small-scale implementation into the production
environment, whereas a Dress Rehearsal is performed in a simulated environment. Pilots tend to be more
limited in scope, as a demonstration of a solution, while a Dress Rehearsal is a practice run for a full-
scale implementation.
The quality tools that support the creation of this document are:
Improvement and Development Path Tools:
       FMEA
       Poka Yoke

8.1 Scope
It is important to outline the parameters of the Pilot, so that the project is tested and appraised properly.
Scope should include notes on dates, duration, participants and purpose. Note: Include risks,
assumptions and issues in previous Project Plan section with a reference from this section.

8.1.1 Goals & Objectives
Before the Pilot is engaged, it is important to decide what will constitute a success. The factors that are
to be uncovered and achieved by the Pilot should be documented for reference. This is a crucial part of
the Pilot Plan; the Pilot’s aim is to identify the benefits seen by the associate or customer. These benefits
and the expected outcomes should be documented and prioritized for success.
The success of the project should be linked directly to the project initiative and established CTQ’s as well
as indirectly to the Pilot execution. For example - directly, if the project initiative expects $5 M in cost
savings, what proportion of that savings needs to be seen in the Pilot? And indirectly, if the group has
given itself 4 hours to work through a given issue, how well did the group stick to that?
Identify and Include success and failures for pilot in this section.

8.1.2 Schedule Overview
As a reference, there should be an overview of the tasks and action items that will be done during the
Pilot. This will include a high-level version of the Detailed Schedule, grouping events per day or week. A
link to the Project Schedule should be included here.




Revision Date: MM/DD/YY                                                                           Page 21 of 31
Document Version: nn.rr
                                                                Project Name Software Project Plan nn.rr


8.2 Pilot Design
8.2.1 Requirements
The Pilot core concept and the Pilot environment should have the requirements and associated peripheral
connections identified.
For example, if this were a computer upgrade, the Pilot environment server would have certain
parameters to work within – available memory, speed of computer processor, etc. Additionally, there
would be programs and databases that would have to interact with the new upgrades; these too would
have to be added to the server in order to create the appropriate interactions.

8.2.2 Data Management Process
This section should outline the process and or system to be used for recording the analysis of information
or data produced during the Pilot. The system should be well documented and the instructions for such
should be in a separate approach document.
Note; be sure that everyone has the appropriate access to any computer or system you may choose to
use for data management.

8.2.3 Environment
The environment for the Pilot should be a stand-alone area, which cannot interfere with normal
production. It should be chosen based upon the criteria and desired impact from the Business Case and
Project Charter. The environment is not limited to the physical and inanimate. The teams and
departments necessary for the Pilot should also be outlined and documented here.
The security for the Pilot environment should be the same as the production environment. Plan to delete
test data once the pilot is complete. These are controls needed to protect customer data.




Revision Date: MM/DD/YY                                                                      Page 22 of 31
Document Version: nn.rr
                                                                  Project Name Software Project Plan nn.rr



                          9.0 Dress Rehearsal Plan
    Not          <If this document section does not apply to your project, enter an ‘NA’ here, delete
 Applicable      subsections below and move to the next section.>


9.1 Scope
It is important to outline the parameters of the Dress Rehearsal, so that the implementation is tested and
appraised properly. Scope should include general notes on dates, duration, participants and purpose.
Note: Include risks, assumptions and issues in previous Project Plan section with a reference from this
section.

9.1.1 Goals & Objectives
Before the Dress Rehearsal is started, it is important to decide what will constitute a success. The factors
that are to be uncovered and achieved by the Dress Rehearsal should be documented for reference.
This is a crucial part of the Dress Rehearsal Plan; the Dress Rehearsal's aim is to practice the
implementation. The expected outcomes should be documented and prioritized for success. Outline
success and failure criteria.

9.1.2 Schedule Overview
As a reference, there should be an overview of the tasks and action items that will be done during the
Dress Rehearsal. This will include a high-level version of the project's Detailed Schedule, grouping
events per day or week. A link to the Project Schedule should be provided here.

9.2 Dress Rehearsal Design
9.2.1.1   Requirements
The systems and processes involved in the Dress Rehearsal, as well as the Dress Rehearsal
environment, should have the requirements and associated peripheral connections identified.

9.2.1.2   Data Management Process
This section should outline the process and or system to be used for recording the analysis of information
or data produced during the Dress Rehearsal. The system should be well documented and the
instructions for such should be in a separate approach document.
Note; be sure that everyone has the appropriate access to any computer or Internet system you may
choose to use for data management.

9.2.1.3   Environment
The environment for the Dress Rehearsal should be a stand-alone area, which cannot interfere with
normal production. It should be chosen based upon the criteria and desired impact from the Business
Case and Project Charter.
The environment is not limited to the physical and inanimate. The teams and departments that are
necessary for the Dress Rehearsal should also be outlined and documented here.
The security for the Dress Rehearsal environment should be the same as the production environment.
Plan to delete test data once testing is complete. These are controls needed to protect customer data.

Revision Date: MM/DD/YY                                                                        Page 23 of 31
Document Version: nn.rr
                                                                Project Name Software Project Plan nn.rr



                     10.0            Conversion Approach
    Not          <If this document section does not apply to your project, enter an ‘NA’ here, delete
 Applicable      subsections below and move to the next section.>


The Conversion Approach section is recommended for large systems conversion projects.
Use the Conversion Approach Plan as outlined in the Conversion Process Guidelines.
NOTE: Include risks, assumptions and issues in previous Project Plan section with a reference from this
section.

10.1 Scope
If Conversion approach, provide a high level summary of Conversion activities including type of
conversion (manual/automated), process for receiving conversion files (NDM, T1 Line, tape), timing of
conversion file receipt and LPAR to be used for conversion activity. If Implementation Approach, provide
high level summary of systematic change, timing of when change will be implemented to production,
impacted systems, impact to production processing, etc. General description should also include a high
level summary of conversion and/or daily processing balancing activities. Applications should complete
all portions of the document that are applicable to their project efforts.

10.2 Target Business Process Flows
10.2.1 High Level Summary of Target Business Process Flows
Please provide a high level summary of the proposed manual business activities involved from a
Customer and/or Associate perspective in the target environment.




Revision Date: MM/DD/YY                                                                       Page 24 of 31
Document Version: nn.rr
                                                                                                            Project Name Software Project Plan nn.rr


10.2.2 Target Business Process Steps Description
This section describes the function associated with each of the steps within the Business Process Flows within the target environment


                          Process
      Process Name                    Process Step Name          Step Type               Functional Description              Business / Access Rules
                           Step #
A. Process One            A1         Process One – Sub 1       Auto / Manual                                                Table driven, production
                                                                                                                            parameter driven, on-line
                                                                                                                            edits, etc
                          A2         Process One – Sub 2       Auto/ Manual
B. Process Two            B1         Process Two – Sub 1
                          B2         Process Two – Sub 2
C. Process Three          C1         Process Three – Sub 1


10.3 Conversion Approach (If Applicable)
10.3.1 High Level Summary of Conversion Steps

 #                                                  Conversion Specification                                                          Confirmed By
 1.
 2.

10.3.2 Legacy Files to Be Converted

                                         Sending                                         Conversion
 #             File Name                                   Delivery Mechanism                                   Date Sent           Responsible
                                        Application                                       Volume
1.                                                         NDM, T1, physical          Number of
                                                           tape, etc.                 converting
                                                                                      accounts, remarks,
                                                                                      data entities, etc.


Revision Date: MM/DD/YY                                        Vendor – Proprietary                                                     Page 25 of 31
Document Version: nn.rr
                                                                                                    Project Name Software Project Plan nn.rr


2.

10.3.3 Legacy Files/Information Not Being Converted

#              File Name / Field Name                      System of Record            Data Retention Period           System Contact

1.
2.

10.3.4 Key Target System Files Created by Conversion / Static Run

#                     File Name                         Creating Application                Date Created                 Responsible

1.
2.

10.3.5 Target Database Changes

                              Database Table / Master
 #           System                                        N/C/D          Description of Update        Database Table / Master File Type
                                       File

1.                           Database or Master File        New,                                      CV, TV, DB2, VRLS, INFMX, ORCL,
                             Name or ID                    changed,                                   IMSFF, IMSFP, etc
                                                           deleted
2.

10.3.6 Predecessor Task (inc. conversion prep activities, operational tasks, tasks by other applications, etc.)

     #                                  Task Description                                          Responsibility           Date of Execution
     1.
     2.

Revision Date: MM/DD/YY                                     Vendor – Proprietary                                               Page 26 of 31
Document Version: nn.rr
                                                                                                     Project Name Software Project Plan nn.rr


10.3.7 Successor Tasks (Includes Operational Tasks, Tasks by Other Applications, Etc.)

     #                                 Task Description                                            Responsibility           Date of Execution
     1.
     2.

10.3.8 Balancing Tasks (Related to Conversion Activities)

     #                                 Task Description                                             Responsible             Date of Execution
1.
2.


10.4 Implementation Approach (If Applicable)
10.4.1 Target System Actions Summary

     #             System                                 Actions                                          Items Impacted
     1.    System Name              Describe action that needs to take place to system   Modules, Tables, PCD, JCL, etc
     2.

10.4.2 Impacted Screens / User Interfaces

 #             System          Screen / UI Name              N/C/D                                    Description
 1.       System name       Screen or UI name          New, changed,        Description of the screen/UI updates
                                                       deleted
 2.




Revision Date: MM/DD/YY                                     Vendor – Proprietary                                                Page 27 of 31
Document Version: nn.rr
                                                                                                          Project Name Software Project Plan nn.rr


10.4.3 Reports (for Target systems)

#          System                  Report Name               N/C/D               Description                Frequency            Delivery Channel

1.    System name         Report name or ID              New, changed,                               Daily / weekly /           Web / paper / etc
                                                         deleted                                     monthly / etc
2.

10.4.4 Forms/Correspondence

                               Form /                Form/                      Form/
                                                                                                                                         Delivery
#         System          Correspondence        Correspondence    N/C/D    Correspondence             E/P           Frequency
                                                                                                                                         Channel
                                Type                 Name                    Description
1.                        Form, screen print,                                                      Electronic/   Daily / weekly /      Web, paper
                          .pdf file, etc                                                           paper         monthly
2.

10.4.5 System Interfaces (New or Modified Interfaces on Target Systems)

                                                                                     File /
          From           To          Owner               Interface                                  Messaging               Message
#                                               N/C/D                     B/O       Request                                                   Frequency
         System        System        System             Description                                  Protocol               Format
                                                                                     Name
1.    Originating     Destinatio    Interface                          Batch /                 TCP , MQ , etc            OAG, OFX, XML      Daily, weekly,
      system          n system      owner                              online                                                               monthly
2.

10.4.6 Target Database Tables / Master Template Files

                              Database Table / Master                                                                   Database Table/ Master File
 #           System                                       N/C/D                      Description
                                       File                                                                                       Type
 1.                          Database or Master File                                                                    CV, TV, DB2, VRLS, INFMX,
                             Name                                                                                        ORCL, IMSFF, IMSFP, etc


Revision Date: MM/DD/YY                                      Vendor – Proprietary                                                       Page 28 of 31
Document Version: nn.rr
                                                                                                      Project Name Software Project Plan nn.rr


 2.

10.4.7 High Level Summary of Implementation Steps

  #                                    Task Description                                         Responsibility              Date of Execution
 1.
 2.

10.4.8 Predecessor Task (Includes Pre-Implementation Technical Tasks, Operational Tasks, Actions Required by
       Other Systems, Etc)

  #                                    Task Description                                         Responsibility              Date of Execution
 1.
 2.

10.4.9 Successor Tasks (Includes Post-Implementation Technical Tasks, Operational Tasks, Actions Required by
       Other Systems, Etc)

  #                                    Task Description                                         Responsibility              Date of Execution
 1.
 2.


10.5 Environment Requirements
10.5.1 Physical Environment
Insert physical environment diagram here; include summary paragraph that describes any project specific changes to the hardware configuration
or system architecture.




Revision Date: MM/DD/YY                                       Vendor – Proprietary                                                Page 29 of 31
Document Version: nn.rr
                                                                                                                Project Name Software Project Plan nn.rr


10.5.2 Logical Environment / Interface Diagram
Insert logical environment diagram; include a summary paragraph that describes any project specific changes to existing interfaces or introduction
of new interfaces.

10.6 Security Level
10.6.1 Authentication
If applicable, describe existing authentication technology and procedures. Please describe if system access is granted through normal Information
Security channels or if special internal security exists for a given application. If internal security setup exists, then please document how access is
provided to an individual user.

10.6.2 Entitlement Chart

#               ID             Element          Description               User Sub-Groups                 User Group                    Type
1.       The label or       Examples:      Description of what      A defined group of people          Bank group             Update, Create, View,
         name of the        Component,     the entitlement          that receives the entitlement.     responsible for any    Delete, etc.
         specific element   Service,       provides to the sub-     This column should                 number of sub-
         that performs or   Module,        groups.                  document how people are            groups.
         enables the        Screen, etc.                            grouped based on the
         entitlement                                                business requirements.
2.


10.7 First Day / Last Day Procedures
First Day is defined as the first day that Associates would access the new target (model) systems. Examples could also include swap out of legacy
items such as tickets, forms and brochures.
     #           Task Description              Responsibility                  Date                  Time (if
                                                                                                     known)
 1.
 2.


Revision Date: MM/DD/YY                                           Vendor – Proprietary                                                     Page 30 of 31
Document Version: nn.rr
                                                                                     Project Name Software Project Plan nn.rr



				
DOCUMENT INFO
Description: This is a template a company can use to propose a software development project. This template includes a project overview, project organization, project management approach, configuration, quality assurance, deployment plan, pilot plan, conversion approach, and much more. In addition, this template may be customized to provide for any industry specific language that may be necessary. This template is ideal for small businesses or other entities that want to propose a software development project.
This document is also part of a package Product Development Kit 71 Documents Included