Talk:Project Plan

Title page

Notice:  ''This document is the property of Compu-Quote Inc.. Any use of this material, its content concepts, estimations or particulars of any sort is strictly prohibited without the express written permission of Compu-Quote Inc.''

Purpose
The purpose of this document is to communicate the project plan to all project team members and to provide a framework for which the Rating Services Update S project will be governed by.

About This Version
This is the initial version of this document. It has been created based on the planned changes and will be updated with outcomes of the kickoff meeting.

Introduction
Update S completion date has been positioned in line with the planned deployment of Rate Bridge for Axa which is in a June/July timeframe. To mitigate the risk of slipping deadlines, RCT mid rollout we be implemented independently of this update and developed/tested/deployed on an independent schedule. ING Rate Bridge will be no earlier than October, but could be later, hence it will likely be deployed as part of update T. However this is all subject to change if Axa ’ s timeline for supporting Rate Bridge slips. If, as the project schedules pan out, Axa is significantly delayed and ING holds to August then update S could be rolled out as late as October with both products included.

Executive Summary
This update is intended to coincide with the planned availability of the Axa Rate Bridge launching in summer 2007.


 * We will create innovative solutions to eliminate the need for brokers using Fortus WS to do updates excluding the scenario of a temporary loss of internet connectivity.
 * We plan to address some workflow inefficiencies, primarily saving of data the user currently is required to re-enter each time they quote as well as support reprinting the app.
 * We have an abundance of usability items planned for this release that we expect positive feedback from.

As well, we intend to improve the overall quality and stability of the product from the following fronts. We will endeavor to complete as many minor defects and minor enhancements requested by brokers as time permits. We will identify and address code quality opportunities including error handling and componentizing of database and UI functionality.

This project will be done independently of the RCT mid year system enhancements thus avoiding the unnecessary dependency between RCT and AXA rate bridge.

Project Mission Statement

 * Ensure update is a positive experience for clients
 * Minimize Update Related phone calls
 * Minimize the effort required for brokers and support to deal with the update.
 * Provide quality enhancements that will benefit brokers
 * Make changes to improve quality and efficiency of future releases.
 * Identify opportunities to rewrite convoluted code
 * Improve workflows and UI when possible
 * Improve error handling and reporting to avoid mysterious/unsolvable support issues
 * Componentized code, 4 tiered approach
 * Identify Repeatable Processes
 * Test cases
 * Tools
 * Stakeholders

Business Goals \ Business Alignment

 * Position our products to be the workflow of choice for brokerage and company EDI initiatives.
 * Rate Bridge initiatives
 * Save everything
 * Continuing steps to provide a web rating solution for brokers.
 * Eliminate need for updates (creates value for Fortus WS product)
 * Web

Project Scope
The following section indicates the included and excluded scope of the project. Any item not specifically mentioned as included is deemed excluded. Modifications to the defined scope after the scope document has been signed off must follow the change management process outlined later in this document.

Included Scope

 * The development and testing of enhancements to the core rating services products based on the requirements as identified in the Update S Requirements.doc.
 * The development and testing of changes to the internal tools required to change as result of new features and files.
 * The development and testing required to ensure continued support of various rating services add ons, including
 * Integration
 * EzLeads
 * CSIO Application forms
 * Supported and soon to be supported EDI ’ s and Credit scores
 * Custom carrier preferred business enhancements
 * Banners
 * Inter Groupe Import/Export
 * Deployment of product to customer base
 * Deployment of product to customer base

Excluded Scope

 * Enhancements to MIReports, TravelRater or FarmRater products.

Deliverables and Major Milestones
 

Risk Management Process
Compu-Quote follows a team based risk management philosophy. It is the responsibility of each team member to ensure that all identifiable risks logged and have appropriate control plans in place. The project manager will facilitate the risk management processes by holding planning meetings to assist in the identification of risks and to develop appropriate control actions. The project manager will document all identified risks using the standard CQ template. When necessary the project manager will request the assistance of CQ ’ s Software Architects to identify and control technical risks.

During the course of the project, the status of risks will be monitored. The regular status report will contain a risk section where each identified risk will be listed along with a corresponding status of the monitoring and control procedures. In addition, a section of time within each status meeting will be allocated to discuss risks. Project team members are encouraged to report any new risks to the project manager for documentation and control.

Compu-Quote classifies risks by probability as well as impact. Below is a summary of each classification:

Refer to risk document for risks

1.1 Issues


 * Issues will be monitored daily.
 * They will be recorded in the issues document, dated, tracked, and a status kept (on hold, in progress, initiated, resolved)
 * Unresolved and recently resolved issues will be included in the project status report.

Dependencies

 * Rate Bridge AXA Ear marked for July Deployment
 * EDI
 * CS

Related Projects

 * Various EDI projects
 * Various EZLeads Work orders
 * Mid Year RCT
 * Rate Bridge AXA
 * Rate Bridge ING
 * IRCA Detailed Analysis

Project Team Directory
1.2 Roles and Responsibility Matrix

SP-Sponsor, PM-Project Manager, BA-Business Analyst, AE-Architect\Engineer, DL-Development Lead, DEV-Developer, QAL-QA Lead, QA-QA Analyst, CL-Client

P – Participant, A-Accountable, R-Review Required, S-Sign-off Required, O-Optional Review

Personal Communications
All team members are encouraged to have open communication with each other. Team members should respond to all project related communication within one business day or alternatively provide notice of when a response will be forthcoming. Any verbal communication where a decision has been made that affects other team members should be documented and forwarded to the entire project team.

Team Status Meetings
Team meetings will be conducted on a weekly basis on Tuesdays at 9:15am in the green room. The meetings will last no more than 30 minutes and will include designated representatives of the project team members. Representatives are responsible for raising issues on behalf of other team members and relaying relevant communications back to team members. The agenda for each meeting will be determined prior to the meeting but will include: Status from Team Leaders, Risk Review and Issue Review. Where lengthy discussion occurs, the project manager will ask the issue to be taken offline. The attendees of the subsequent meeting will report back to the project manager of any decisions made and of issues/risks arose.

The project manager will facilitate the meeting and record minutes. The minutes will be published on the project website Development Wiki Site as soon as possible after the meeting.. Minutes become official documents of the project and therefore should be reviewed for accuracy and completeness.

Other Team Meetings
Team members should feel free to use meetings where deemed necessary to achieve an appropriate level of communication. If you anticipate the meeting lasting longer than 30 minutes, an agenda should be prepared and minutes from this meeting documented. The minutes of the meeting should be provided to the people involved in the meeting & the project manager.

Status Reports
Project Status reports will be published every other week on the project website Development Wiki site including the following: Management Summary, Progress to date, Tasks behind schedule, Unplanned Work Done, Tasks in Jeopardy, Project Buffer, Risk Status, Issue Status, Outstanding Items, Action Items, Project Schedule and Defect Status.

Documentation Standards
This section will indicate any special formatting required for documents more than 3 pages in size not on the Wiki site. At a minimum all CQ project documents must have the following:


 * Cover page including title and version
 * Document Control Sheet indicating the following: title, owner, version, date, soft copy location, hard copy location, distribution, distribution restrictions, document history.
 * Table of Contents
 * Header and Footer

This document can be used as a template (by removing the sections that are not required for your document).

Documents should be viewable and readable using MSOffice tools.

Documentation Storage
All softcopies should be saved in the following folder: ## Error converting ##: [../../../../devel/cq/Update P/ q:\devel\cq\Update S\]. Relevant documents will be available under the Project Wiki site.

Project Quality Management
In order to ensure that quality is built into the management of this project and the product, the following elements will be requested and/or activities will be conducted:


 * Scope Statement to be approved off by the sponsor.
 * Project Schedule developed and monitored.
 * Weekly meeting to be held with the team to review project.
 * Regular status reports to selected stakeholders.
 * Customer representation by support and reps involved throughout the project.
 * Issues will be logged and managed on a daily basis.
 * All action items will be logged and managed on a daily basis.
 * Change process implemented and followed.
 * Risk analysis performed throughout the project.
 * Defects will be logged and managed using Compu-Quote Defect Web site (Bugzilla).
 * Project Post Implementation reviews will be performed at the close of the project. Team members will be expected to submit their comments at that time (see Appendix A: Project Performance Appraisal, Appendix B: Post Implementation Review).

Defect Classification
The following priority and severity tables will be used to classify software defects.

Defect Reporting


 * All defects will be reported through defect website (Bugzilla).
 * Provide detailed steps to recreate the error. The more details given, the easier it will be to reproduce the error.
 * Attach printouts or profiles to assist in recreating (where applicable).
 * Severity levels, priority and Status and developer will be assigned to each defect.
 * BA ’ s are responsible for reviewing defect status and priority and following up on outstanding defects.
 * Defect meetings will be held as needed, conducted by BA ’ s

Workflow

Defects that are reported will be recorded in the defect list. The defect will be assigned a Severity, Priority and Status. During testing, the QA Leader and Development Leader will conduct a daily review of the outstanding defects to determine what can/will be corrected. The defect will be then be reassigned and reprioritized as needed. It is the responsibility of the programmer to review the defect list and correct the defects assigned to him/her. Once the problem has been resolved, Programming will notify QA; QA will retest the defect. If the problem is fixed, the defect will be closed. If not, the defect will be reset to Open and resubmitted to Programming.

Product Maturity
Using the defect classification table the software product will be deemed deliverable (either final or to next phase) when the number of defects by severity are below those stated below.

Minimum to Deliver for Pilot (beta) Testing

Minimum to Deliver to Production

2 Project Work Breakdown Structure

Change Management
Since business is dynamic, changes to the scope of the project may be required. A formal change management process is necessary to ensure that scope changes positively impact the deliverables of the project and that all impacts are effectively communicated to all stakeholders. The change management process will allow appropriate project stakeholders to make cost and benefits tradeoffs based on analysis of the requested changes. The process for this is as follows:


 * A CQ change request form is completed and submitted to the Project Manager.
 * The Project Manager will review the request and initiate an impact assessment within three business days of receiving the request.
 * An impact assessment will be conducted outlining the cost, time and quality implications of the request.
 * The Project Manager will provide the assessment to the Project Sponsors for approval.
 * If approved the Project Manager will Update Project documentation and communicate the change to all stakeholders.

Supporting Documents
Refer to project Wiki for links to supporting documents.