2.6 Project Planning and Documentation Guide (PPDG)

 < Day Day Up > 



The PPDG contains a high-level overview of the contents of each of the documents that make up a company’s SEP. It is, in essence, the master plan. The information contained in this document can be used as a reference point for the information that can be found in each of the SEP documents. As the work is completed throughout each phase of the SEP, the deliverables are validated against the recommendations found in the PPDG and added to the project binder. A detailed outline of the PPDG is shown below. This outline is intended to help the Core Team stay focused on the various elements of each phase of the SEP. This outline also serves to standardize the software program management approach used in the delivery of systems throughout the enterprise. Note the close correspondence between the SEP roadmaps and the structure of the PPDG. It is not an accident.

 0   Introduction       0.1   Purpose of This Document       0.2   Copyright       0.3   Intended Audience       0.4   Inputs to This Document       0.5   Outputs from This Document       0.6   Distribution List   1   Phase 1: Requirements Evaluation and Proposal Phase       1.1   User Requirements Document Target Completion Notice (TCN)       1.2   User Requirements (URD)       1.3   Project Organization Documents (POD)             1.3.1 Sponsor Formalization Letter (SFL)             1.3.2 Letter of Appointment (LOA)             1.3.3 Core Team Roster (CTR)       1.4   Framework Rules (FR)       1.5   Framework Rules Document (FRD)   
 2   Phase 2: Analysis and Detailed Planning Phase       2.1   Project Definition Document Notebook (PDDN)            2.1.1 Project Objective Statement (POS)            2.1.2 Flexibility Matrix (FM)       2.2   Data Analysis Document (DAD)            2.2.1 Data Risk Analysis (DRA)       2.3   Technical Analysis Document (TAD)            2.3.1 Software Reengineering Assessment (SRA)            2.3.2 Technology Analysis (TA)            2.3.3 Technical Risk Analysis (TRA)            2.3.4 In-House/Contractor Analysis (IHCA)            2.3.5 Lease/Purchase Analysis (LPA)       2.4   High-Level Solution (HLS)       2.5   Bids/Proposals (BP)       2.6   Funding Documentation (FD)            2.6.1 Project Budget (PB)       2.7   Project Schedule (PS)            2.7.1 Critical Path (CP)            2.7.2 Task Duration Estimates (TDE)            2.7.3 Dependency Diagrams (DD)            2.7.4 Optimization Tradeoff Plan (OTP)            2.7.5 Resource Histogram (RH)            2.7.6 WBS Dictionary (WBSD)       2.8   Risk Analysis            2.8.1 Risk Management Matrix (RMM)            2.8.2 Risk Assessment Matrix (RAM)       2.9   Change Management Process (CMP)       2.10  Status Reports (SR)             2.10.1 Variance Reports (VR)             2.10.2 Adaptive Action Plan (AAP)       2.11  Review Package (RP)             2.11.1 Meeting Agenda (MA)             2.11.2 Project Definition Document (PDD)       2.12  Documents from Review Meeting (DRM)             2.12.1 Waiver/Exception to Required Standards (WERS)             2.12.2 Project Continuation Approval (PCA)   
           2.12.3 Project Team Review Minutes (PTRM)             2.12.4 Approval Letters (AL)   3   Phase 3: Detailed Design Phase       3.1   Product Requirements and Specifications (PRSpec)             3.1.1 System Infrastructure Requirements (SIR)             3.1.2 Software Requirements Specification (SRS)             3.1.3 Interface Requirements Specification (IRS)             3.1.4 Performance Requirements Specification (PRS)       3.2   Data Development Plans             3.2.1 Content Pipeline Document (CPD)             3.2.2 Data Distribution Plan (DDP)       3.3   Marketing Communication Plan (MCP)             3.3.1 Marketing Rollout Schedule (MRS)             3.3.2 Marketing Rollout Signoff (MRSO)       3.4   Contracts/Agreements (CA)       3.5   Project Transition Letter (PTL)       3.6   Software Development Plan (SDP)             3.6.1 Database Conversion Plan (DCP)             3.6.2 Quality Assurance Plan (QAP)             3.6.3 Human Factors Plan (HFP)       3.7   Test Plans             3.7.1 Stress Test Plan (SsTP)             3.7.2 Integration Test Plan (ITP)             3.7.3 Software Test Plan (STP)             3.7.4 Product Assurance Test (PAT)             3.7.5 User Acceptance Test (UAT)             3.7.6 MIS/Outside Certification Plan (MISCP)   4   Phase 4: Construction Phase       4.1   Product Deliverable            4.1.1 Source Code (SC)            4.1.2 Software Executable (SE)            4.1.3 Database Conversion Scripts (DCS)       4.2   Product/Project Signoff and Certification Letters            4.2.1 Product Assurance Signoff Letter (PASL)            4.2.2 Functional Certification Letter (FCL)            4.2.3 MIS Certification Letter (MISCL)   
          4.2.4 Data Certification Letter (DCL)       4.3   Product Manuals            4.3.1 Software User Manual (SUM)            4.3.2 Software Installation Manual (SIM)            4.3.3 Training Manual (TM)            4.3.4 Operations and Maintenance Guide (OMG)   5   Phase 5: Testing Phase       5.1   Create Test Log (TLS       5.2   Execute Test Cases            5.2.1 Compile Bug Tracking Reports (BTR)   6   Phase 6: Implementation Phase       6.1   User Training Plan (UTP)            6.1.1 Training Roster (TR)            6.1.2 Training Schedule (TS)            6.1.3 Training Signoff (TSO)       6.2   HW/SW/NW Equipment Installation Plan (SIP)       6.3   Rollout Plan (ROP)            6.3.1 Rollout Schedule (RS)            6.3.2 Rollout Signoff (RSO)   7   Phase 7: Customer Support Phase       7.1   Software Transition Plan (SWTP)            7.1.1 MIS Software Handoff Acceptance Letter (SHAL)            7.1.2 MIS Hardware Handoff Acceptance Letter (HHAL)            7.1.3 Hardware Life Cycle Management Plan (HLMP)            7.1.4 Help Desk Support Questions (HDSQ)   8   Phase 8: Completion Phase       8.1   Closeout Documents (COD)       8.2   Archive Project       8.3   Closeout Ritual   

As you can see from the outline, the PPDG constitutes a fairly comprehensive approach to project management in an organization. The Intranet software available with this book has a complete set of sample documents to illustrate each deliverable shown. It is of critical importance to understand the relationship between the SEP, the roadmaps that illustrate the various tracks, and deliverables each entity in the process is responsible for delivering, and the living document—the Bible of the project—the PPDG. This relationship cannot be taken for granted. It is precisely this relationship that defines a software program management function. The SPMO is tasked with responsibility to ensure a methodical execution of these processes that enable a corporation with effective Software Program Management capabilities.

When the Core Team has finished the URD, it is submitted to the SPMO and checked in for final review. It will be reviewed by the Project Sponsor, and, if it is approved, it will be placed in the project binder. The SPMO will then perform an internal audit of the Phase I process and create a project scorecard rating how well the team has done. The scorecard will then be reviewed by the Project Sponsor, and this is when the Phase I signoff should occur.

We have covered all significant aspects of Phase I of the SEP, Project Initiation, in this chapter. In Chapter 3, we delve deeper into the SEP, going into the SEP Planning Phase, where we discuss each of the many deliverables required to take a project from the planning to the design stage. The planning stage is crucial because mistakes made here can have huge impacts in later phases.

  Ponder this: "What is the biggest secret to successful project  management? Don’t ever charter a big project!" According to Bob  Lewis, any project lasting more than nine months or requiring  more than 12 people on the Core Team is doomed from the start. He  states the following reasons:    1. Big projects cannot be estimated.    2. Big projects mean no urgency.    3. Big projects reduce personal accountability.    4. Big projects mean big overhead.    5. Big projects mean big risk.   

The next time you start a project initiation phase, take a moment to review these thoughts and contemplate the effect of your actions. For more detail on these reasons, the reader is encouraged to consult Lewis’s book[8], IS Survival Guide.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net