You are on page 1of 24

Quality Engineering Tool

This report is to formally summarize our recent project proposal and the Project Management Plan for the development of a web base software application Quality Engineering Tool for our clients. Upon a preliminary interview with our clients, we had met to discuss preliminary problem areas: areas for formulating a solution for establishing a standardized platform for communication between the software developers and the testers. This was to improve the software product development process for the projects taken over by the company. As a result of that first meeting, we identified the requirements and expectations of the end users from the product.

Page 1

1.0 Project Charter Report


1.1 Company Background:
Soft Inc is a private sector software development firm with 2600 employees with annual revenue of $300m. The software core development teams are located in 12 different states. This company serves about 200 clients located all over the globe.

1.2 Project Overview


The existing system to keep track of requirements is paper-based. It is burdensome for companies to go through the documented requirements when theres a need to update it. Managing resources and deadlines are quite challenging in order to achieve goals. Proper communication is needed between developers and QA engineers for fixing bugs.

1.3 Problem Statement


As there is a decrease in the earnings by 40 percent over the last two years the revenue is decreased by 10 percent, it is further expected to decrease by another 20 percent. The expense and loss of important clients both are expected to increase by 10 percent. Causes: No systematic planning between business processes there is a delay in communication between intra-team and inter-team Quality of product also decreased by 20 percent leading to hiring of additional developers and testers leading to increase in expense Customer satisfaction decreased by 50%

Page 2

1.4 Statement of Objective


To provide a Web-based Project Management tool within 18 months that keeps a track of all projects, their requirements, resources , critical errors, cost deadlines electronically. Decrease the amount of bugs and errors by at least 80 percent within an year of deployment , align the processes by establishing clear relationship with the goals and objectives to be achieved Improve customer satisfaction by 90 percent and enable increase in earnings by 30 percent causing an increase in revenue by 20%. Assumptions Upcoming market value changes have not been considered. Staff skill-sets are assumed to be consistent over the 22 month period. Changes in Business Rules are not considered. Constraints Time period of 18months Total budget of $2 Million Waterfall model lifecycle

Page 3

1.6 Project Deliverables

Phase
Initiation

Start Date 3/19/12

End Date 4/13/12

Deliverables
Project proposal Initial Project plan Project scope Feasibility document Refined project plan Implementation plan System architecture design User-interface design and technical specifications Database design and technical specifications Functional front end Functional database Unit test cases and results Test script for front end and database Integration test cases and results Functional Front end at the production environment Functional Database at production environment Final project document

Planning Website Design

4/16/12 7/6/12

7/6/12 9/27/12

Website Development 9/27/12 Quality Assurance 4/24/13

4/24/13 7/16/13

Implementation

7/16/13

8/26/13

Project Close out

8/26/13

10/4/13

Page 4

1.7 Stakeholder Analysis

Stakeholder

Role

Impact

Influence

Risk Tolerance

Needs

Responsibility Ensures projects feasibility scope and stakeholder interest Cost budget, WBS, resource allocation, etc

Project Director Project Manager

Decision making Managing and controlling project

Mediumhigh High

High

Low-Medium

Project Idea, Change request, Project Progress Support from higher management and updates about project from junior management Project idea and scope

High

Low

Business Analyst

Designing project & Decision making

Low

LowMedium

Low

Gather user requirements

Software architect

Co-ordinate teams day to day activities

Medium High

Medium

Medium

Requirements, design, reports, updates on project

Resolving technical issues

Project Team

Design, develop, test the new software

LowMedium

LowMedium

Medium-high

Milestones and tasks from supervisors

Develop and support software and database implementation

Project Sponsor

Sponsor Project

High

High

Low

Project managers expertise and support of organization

Provide monetary support to the project

Page 5

1.8 SWOT Analysis


Strengths: Internal capabilities, skills, structure, tools, etc. of the organization that can be used to meet the organizations future objectives. Weaknesses: Areas where the organization lacks the internal skills, capabilities, tools, support, etc. necessary for accomplishing future objectives. Opportunities: External factors that the organization should be able to use to achieve its objectives. Threats: External factors that are obstacles to the organizations ability to achieve its objectives.

Strengths

a) b) c) d) e)

Experience, Knowledge of the project team ISO Certifications Unique Selling Points Likely ROI IT systems, processes and communication techniques.

Weakness

a) b) c) d) e)

Communication gap Requirement gathering Bug Tracking Delays in implementation Customer satisfaction

Opportunities

Threats

a) Powerful communication between team b) Market growth and development c) Resource allocation on tasks d) Increase in customer satisfaction by providing solution on time a) External economy conditions. b) Political effects c) Market demands d) Legal and SOX related clauses and conditions. e) Competitors

Page 6

2.0 Project Structure and Communication Plan

2.1 Team Structure


Steering committee President

Financial advisors Legal Advisors Project Manager (1)

Software Architect (1)

Business Analyst (1)

Software Designer (1)

Software Developer (1)

QA Tester (1)

Database Architect (1)

The above chart describes the hierarchy of the project team. It consists of 3 steering committee members. Project manager reports to project director Software Architect and Business Analyst reports to Project Manager Software Designer, Software Developer and QA Tester reports to Software Architect

Page 7

2.2 Staffing Plan:


The team for the project will be as following: Project Director Project Manager Business Analyst Software Architect Web and Database Designer Database Architect Software Developer QA tester

2.3 Communication Plan:


Groups/Individuals involved
Software architect & Project Manager

Type of communication
Checkpoint meeting

Frequency

Purpose

Weekly

Provide updates on progress of project deliverables

Business analyst & Project Manager

Checkpoint meeting

Weekly (Initial 3 months)

Report the gathered requirements and discuss the analysis criteria

Project Manager and project director

Board Meeting

Tri-weekly

Provide updates on progress of project deliverables and discuss the involved or possible risks and faults Provide updates on the deliverables and progress of the development, discuss about the bugs and changes and refinements in the application model

Software developer, Database admin, Web developer, Quality analyst and project manager

Team meeting

Weekly

Page 8

3.0 Project Work


3.1 Project Scope
Project Goal: To provide a web based multi role system to monitor processes by keeping track of requirements, resources, critical errors, cost and timelines. Features in scope: Centralized data repository Tested graphical user interface Global access with authentication Report generation capabilities Bug tracker Features out of scope: Training end users to use the new application

3.2 Work break structure


WBS in Appendix A.

3.3 Network Diagram


System Designin g Project preparation

Implementation

Testing Define Authorizations Start End Training

Page 9

3.4 Resource Allocation Matrix Resource Allocation Matrix in Appendix B.

3.5 Cost Loading Information Sheet


The cost loading information sheet gives a detailed description of the project participants, their base pay rate and the project hours put in by them.

Skill/Resource

Initials PD

Standard Rate $100/hr $75/hr $35/hr $55/hr

Calendar Type 40hr/wk 40hr/wk 40hr/wk 40 hr/wk

Cost per week $4000 $3000 $1400 $2,200

Project Director PM Project Manager Database Administrator Software Architect Software Developer Database Designer QA tester DBA SA

SWD SDD QA

$38/hr $40/hr $30/hr

40hr/wk 40hr/wk 40hr/wk

$1,520 $1600 $1200

Page 10

3.6 Milestones

Milestones Project Preparation Define Authorizations Confirm Approval to proceed System Architecture & Design Database Implementation Website Implementation User Acceptance Testing and Quality Assurance Go Live

Date Complete 4/6/2012 5/22/2012 4/13/2012 6/29/2012 1/9/2013 4/24/2013 7/16/2013 10/4/2013

Page 11

3.7 Quality Plan


Project Quality Project equipment and Work Instructions will be documented and included as per company policies. Overall Quality: The overall quality of the project will be handled by the Project Manager and the Project Director. Every stage of implementation will involve detailed review, either weekly or biweekly or triweekly.

Deliverables Project Charter

Quality Event Expert Review by Board of Director

Quality Material Standards for Project Charter: Scope, Objectives, Budget, Strategies

Purpose Ensure the information is accurate and wellconstructed prior to submission to Steering Committee Ensure the information is complete and fit prior to submission to Project Manager Ensures well-structured and accurate design of the plan prior to submission to Project Manager Ensures proper sequence of activities are performed and validate both content and structure of deliverables

Work Plan

Formal Inspection by Steering Committee

Procedures for Work Plan: WBS, Project Schedule, Project Budget

Project Control Plan

Peer Review by Steering Committee

User Guides for Control Plan: Project Staffing, Communication Plan, Resource Plan Checklist for Design Framework: Stages and Activities, Content Format, Design Architecture Standards for Test Framework: Testing tool, Risk Management, Quality Assurance, Backup

Design Framework

Walkthrough by Project Manager/ Consultant

Test Framework

Formal Inspection by Project Manager/ Consultant

Ensures accuracy and security of the project deliverables.

Page 12

4.0 Project Control


4.1 Project Budget

Page 13

4.2 Project Management Tools


This includes various tools used for various tasks during the entire project cycle from project planning, scheduling , breaking down of the project into various tasks, maintaining hours put in by the employee for payroll purposes and checking employee involvement in the project,

PM Tools MS PROJECT MS Power Point MS Word/ Excel

Functionality Gantt Chart, WBS, Cost and Budget reports Presentations of project plans Reports, documentations, Tables.

Page 14

4.3 Action Request Document Doc No: Doc Type: Preparer's Information
Name: Department: Phone Number: E-mail address:

Date Assigned:

Type of Action
New Document Update/Change Revision

Document History

Title

Status
Mandatory Non-mandatory

Review Scope:

Reviewer's Name: Document Approval

Print Name

Signature

Date

Page 15

4.5 Risk Analysis


Purpose and Objective Risk Management is the systematic process of identifying, analyzing, and responding to project risks. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives. A risk management plan defines how a project team will handle risks to achieve that goal.

Probability of occurrence

The following tables describes the probability of occurrence


Probability range 91% through 99% 61% through 90% 41% through 60% 11% through 40% 1% through 10% Natural Language expression Probability value used for calculations Very likely to occur 95% Probably will occur 76% May occur about half of the 51% time Unlikely to occur 26% Very unlikely to occur 5% Numeric Score 5 4 3 2 1

Page 16

RISK IMPACT
Impact Description Natural language expression Impact value used for calculations Numeric score

An event that, if it occurred, would cause project failure (inability to achieve minimum acceptable requirements)

Critical

Cost of variance

10

An event that, if it occurred, would cause major cost/ schedule increases. Secondary requirements may not be achieved.

Serious

Cost of variance

An event that, if it occurred, would cause moderate cost/ schedule increases, but important requirements would still be met.

Moderate

Cost of variance

An event that, if it occurred, would cause only a small cost/schedule increase. Requirements would still be achieved.

Minor

Cost of variance

An event that, if it occurred, would have no effect on the project.

Negligible

Cost of variance

Page 17

Risk tolerance matrix Low Risk: Has little or no potential for increase in cost, disruption of schedule, or degradation of performance. Actions within the scope of the planned project and normal management attention should result in controlling acceptable risk. No response plans will be made for these risks. The project will monitor for them and manage them as they come up. Moderate Risk: May cause some increase in cost, disruption of schedule, or degradation of performance. Special action and management attention may be required to control acceptable risk. The project will do some response planning for these risks. High Risk: Likely to cause significant increase in cost, disruption of schedule, or degradation of performance. Significant additional action and high priority management attention will be required to control acceptable risk. The project will do in-depth response plans for these risks.

Probability Very likely to occur (5) Probably will occur (4) About 50% chance of occurring (3) Unlikely (2) Very unlikely to occur (1)

Negligible (1) 5 4 3 2 1

Minor (3) 15 12 9 6 3

Moderate (5) 25 20 15 10 5

Serious (8) 40 32 24 16 8

Critical (10) 50 40 30 20 10

Page 18

Risk Plan
Risk Description Probability Categor y Trigger Risk Response Contingency

Failure to redesign business process, Failure to design an enterprisewide design, which supports data integration. If there is insufficient training of staff or lack of proper skillset, it would not only lead to bad resource utilization and problems in using the technology at hand If management fails to implement appropriate level of control, it could lead to disastrous results like cost overrun, time slippage, scope creep etc. If the management fails to establish and adhere to some standard specifications, there would be inconsistent and unclear data which would be difficult to comprehend at a later stage If there is a Lack of full time commitment of stakeholders to project management and project activities, it may lead to the project taking a backseat and the team members losing interest

Impact

Process

New business process does not cover the desired functionality Find it difficult to use new technology

Thorough AS-IS, TOBE analysis, Business process reengineering activities should be implemented Complete utilization of both the organizations resources expertise

Business process analyst will review all the activities under project managers supervision Training session will be provided to employees to enhance expertise

Skill

Manageme nt structure and strategies

Cost overrun, Time slippage, scope creep noticed

Software systems design

Required senior management support and project sponsorship. Well defined communication network should be implemented Detailed requirement specification and implementation plan should be created

Project managers will use relevant dashboards and metrics to track and monitor projects.

Business analyst will review BRDs and FRS, Project manager will approve the documents before getting into design phase. Project manager will conduct two status meetings weekly to involve the project team and consultants

User involvement and training

Stakeholders putting the project priorities in back seat

Stakeholders involvement in decision making process should be encouraged

If technological bottlenecks are not dealt with in a planned manner, it would only lead to bad performance and bad numbers as far as result is concerned

Technology planning/Int egration

Progress matrix showing undesired members

System testing prior to system integration

System testing plan will be reviewed and changed to accommodate the issues.

Page 19

If changes are not executed in a centralized way, it may lead to unawareness and ignorance about the current status

10

Project phases are not implemented as planned

Metrics will aid PM in making right decisions during all the phases of projects

If communication is not effective, co-ordination would not be in sync

10

Team unaware of the current changes and progress of the phase

Weekly meetings should be scheduled to improve the communications among team members

4.6 Project Closeout The last major phase of a project's life cycle is the close-out. Closing a project should be a fairly routine process. The key elements to project close-out are: Accepting the project's products indicated by user sign-off Completing the Post Implementation Evaluation Report (PIER) Disbursing the resourcesstaff, facilities, and automated systems Conducting a lessons learned session Completing and archiving project records Recognizing outstanding achievement Celebrating project completion Providing post project maintenance benefits. The first step of the close-out process is the user's acceptance of the system. This is a critical and important step, as the user decides when the project is completed. Acceptance is based upon the success criteria defined in the very early concept and planning stages of the project.

Page 20

Appendix A

Page 21

Page 22

Page 23

Appendix B

Page 24

You might also like