submitted to - docshare01.docshare.tipsdocshare01.docshare.tips/files/7287/72872992.pdf · we would...

Submitted By:

Charith Devaka Sooriyaarachchi CB003344

Thilok Gunawardena CB00

Maheeka Jayasuriya CB003346

Submitted To:

Mr. Syed Rehan

Module Title and Code:

CE00348-3

Project Management

Intake Code:

GF10B1SE

Assignment Title:

Sarasi Musical Centre Web Application Development Project Plan

Date Assigned:

Date Due:

PROJECT MANAGEMENT - CE00348-3

1

ACKNOWLEDGEMENT

First and foremost we would like to convey our sincere gratitude to our lecturer Mr.Syed Rehan,

who gave us all the necessary knowledge on Project Management, guiding us in the correct path

to achieve our goals in the project as well as to build a good career in the field of Software

Engineering. All the support given by him was really helpful in order to successfully complete

the project.

We would like to thank APITT laboratory and APIIT library that helped us providing the

necessary resources regarding the subject and all the friends who help us with even a word of

help. All the help given by everyone was really meant to us in every way.


2

TABLE OF CONTENTS

TABLE OF CONTENTS ................................................................................................................ 2

PROJECT CHARTER .................................................................................................................... 4

CHANGE MANAGEMENT PLAN ............................................................................................ 11

TIME AND COST ESTIMATION .............................................................................................. 13

PROBABILISTIC (DEFINITIVE) ESTIMATION MODEL .................................................. 13

CONSTRUCTIVE COST MODEL (COCOMO) .................................................................... 15

ESTIMATED BUDGET ........................................................................................................... 19

JUSTIFICATION ..................................................................................................................... 20

REFLECTION .............................................................................................................................. 21

REFERENCE ................................................................................................................................ 27

WORK BREAKDOWN STRUCTURE ....................................................................................... 29

BASELINE SCHEDULE ............................................................................................................. 32

GANTT CHART ...................................................................................................................... 32

CRITICAL PATH ANALYSIS ................................................................................................ 33

PROJECT CRASHING ............................................................................................................ 34

QUALITY MANAGEMENT PLAN ........................................................................................... 36

RISK MANAGEMENT................................................................................................................ 41

RISK MANAGEMENT PLAN DOCUMENT ........................................................................ 42

RISK QUALIFICATION AND PRIORITIZATION ............................................................... 45

RISK MONITORING AND CONTROL ................................................................................. 48

COMMUNICATION MANAGEMENT PLAN .......................................................................... 50

COMMUNICATIONS MATRIX ............................................................................................. 51


3

EARNED VALUE EVALUATION ......................................................................................... 52

PROJECT MONTHLY STATUS REPORT ............................................................................ 53

INDIVIDUAL REFLECTION ..................................................................................................... 58

APPENDIX - POWER INTEREST GRID ................................................................................... 66

APPENDIX - STAKEHOLDER REGISTER .............................................................................. 67

APPENDIX REQUIREMENTS DOCUMENT ........................................................................ 70

APPENDIX DATA GATHERING ........................................................................................... 72

APPENDIX - PROJECT TEAM .................................................................................................. 78

APPENDIX DATA FLOW DIAGRAM ................................................................................... 79

APPENDIX COCOMO ESTIMATE REFERENCES .............................................................. 80

APPENDIX - CHANGE REQUEST FORM ............................................................................... 81


4

PROJECT CHARTER

Project Name: On-line Customer Service System (CSS) for Sarasi Musical Centre

Date: 20.01.2011

Project Sponsor: Jagath Perera, Owner, Sarasi Musical Centre

Project Manager: Charith Sooriyaarachchi

Executive Summary:

Sarasi Musical Centre is leaders in musical instrument industry in Sri Lanka. They have a

showroom at Maradana and also own a couple of factory complexes. Apart from selling

instruments at the showroom, they also undertake repairing of instruments. They need to increase

their revenue by introducing a better customer support service. Therefore, they have decided to

host a web application that fulfils this requirement.

Business Need:

Since the development of Sri Lankan music industry, new industrial competitors have come in to

picture. The company is aware of the role they acted in music industry for more than a decade

and they want to enhance their business opportunities to remain stable in the industry. This

system is developed to support the organizational need of increasing their revenue under such

competitive circumstances. With the number of music instrument showrooms available, there is a

market demand for a more customer oriented service. Therefore Sarasi Musical Centre needs to

address these factors by implementing an on-line customer support system. The system needs to

increase customer satisfaction and interaction with the company through process improvement.

Business Objectives:

The business objective of this project is to,

Develop and implement an on-line customer support system within the next 180 days

Increase company transactions by 20% in the by the following 2 years after implementation

Complete implementation of the system within a budget of Rs. 8,000,000


5

Project Description:

This system allows customers to make transactions with the company online. All the services

provided at the shop and factories should have a representation on the website. This system

should be integrating with some of the current systems to acquire data. Other functionalities

expected by the system to perform are described later. The new system needs to run smoothly

with this integration and should provide effective and accurate results.

Constraints:

All hardware and software must be purchased in accordance to the allocated budget.

The budget and duration of the project should not exceed Rs. 8,000,000 and 180 days

respectively

The new system must be compatible with the current IT infrastructure of the company

Assumptions:

The following assumptions will be acknowledged as true and correct upon agreement and

signature of this document.

The project has complete support of the project sponsors, stakeholders including the

employees of the company

The company employees will be communicated the purpose of the system prior to

deployment

Access to companys current IT infrastructure will be provided as an when needed

The database and the current system this system uses are fault and error free. Therefore

any miscalculation or fault caused in CSS due to those factors will not be addressed

The inflation remains constant throughout the project life cycle

The internet usage in Sri Lanka is 1.7 million as of 2010 and the number of average

transactions for the company is approximately 200 at both shop and factory. Sri Lankan

population is 20 million. Therefore the maximum amount of hits that can be expected is

approximately 20 a day.


6

Scope Statement:

The services for the web application are only within Sri Lanka. The application is in English. It

should have a user friendly and pleasurable interface.

It should allow purchasing instruments, reserving instruments and making repair requests and

keep track of them. All the information presented should be in an easy to access manner. All

personnel, hardware and software resources needed, will be purchased and managed by the

project team. The web application will be hosted in a shared database because the number of web

requests per day is fairly low (approximately 20). Project budgeting, scheduling and resources

will all be managed by the Project Manager, Any additional resources needed has to be approved

by the project sponsor. The project concludes after the final report is submitted within 20days

after completed deployment. The transactions must be secure. The development platform is

open-source according to the clients request and decided to use JSP and MySql database. The

new system should be able to get data and write to the existing MsSql database and interact with

the existing systems for Inventory Management. This application will help the users to purchase,

request, reserve and request for repairing of musical instruments easily.

Expert judgment, interviews with company IT manager and marketing manager and a survey for

the general public will be conducted to identify the requirements.

Project parameter ranking is as follows;

Ranking Parameter Comments

1 Scope The web application has to increase the number of transactions in the

company. With the number of expected users also less, the functionality has to

be fully met to achieve the target.

2 Cost The budget for the project is fixed at Rs.8,000,000

3 Time The web application should be up and running by the deadline. Deadline is on

06.09.2011. The profit transaction should be achieved within 2 years. If the

deadline is missed this target is not met.

4 Quality A stable system is needed since this application needs to bring profit to the

company. It should provide a pleasurable experience for the users to attract

more users. Bugs in the web application will cause customer dissatisfaction.

Transactions must be fully secured.


7

Product Acceptance Criteria:

Delivery deadline of the project is 06.09.2011

The new application should provide purchase, request, reserve instruments and make repair

request on-line queries. It also provides repair tracking. The company employees should

be able to follow these transactions and update the statuses of them.

Payments should be secure and accurate

The web application should operate 24 hours a day and 7 days a week

Expenditure of project should not exceed Rs.8,000,000

Errors Threshold Rate should not exceed 4%

Project Deliverables:

Software:

Customers should be able to,

Register in the system

Login to the system

Instrument comparison in terms of price, brand, appearance and features

Search instruments

Shopping cart for purchasing

Reserve instruments

Request instruments that are not currently available in store

On line payment with Visa

Make repair requests

Check status of the repairs

Administrators (Employees) should be able to,

Login to the system

Add new users to the system and update current users

Perform all tasks performed by cashiers

Cashiers (Employees) should be able to,

Login to the system

Update repair statuses

Retrieve purchase and reservation data to deliver or keep instrument reserved


8

Retrieve customer data for delivery and accounting purposes

Perform billing operations

The application,

Should be able to update its data from the current inventory system database

Should be secure to perform transactions

Should have a database to cover the web application functionalities

Should not be susceptible to external attacks

Documentation:

Project plan

Source code and design document

Final report

User manual

Technical report

Project Requirements:

Solution must adhere to all the functional requirements agreed upon

Solution must not interrupt or disrupt any of the current operations

Solution must be fully tested before deployment

The web server must be hosted at the client with no involvement to Development

Company or any other external parties.

The source codes must be provided to the client

A weekly status report must be provided to the client

User manuals and trainings for the employees should be provided prior and during

implementation.

System maintenance services will be free of charge for one year and thereafter 15% of the

total project cost will be charged as maintenance per year.

Project Exclusions

Printable reports and other reports not defined in the deliverables

FAQ, forums or tutorials


9

The database implemented should not need to cover all the business functionalities. Only

the required functionalities for the application

Roles and responsibilities

Name Role Responsibilities

Jagath Perera Sponsor Approve or reject scope, cost or time change requests as appropriate Evaluate need for project scope changes Evaluate deliverables Charith Sooriyaarachchi

Project Manager

Measure and verify project scope, budget and time Approve or reject change requests for scope, cost and time by performing impact assessment Organize and conduct team meetings to discuss the progress and problems Find solutions for problems faced during project not solved by the team lead Update and create project documents All communications with the client and the team lead

Thilok Gunawardena

Team lead Measure and verify project scope, budget, quality and time Participate in impact assessments of change requests All communications with the team members and the project manager Guide and facilitate the team and facilitate Maheeka Jayasuriya Saman Perera Nimal Gamage

Team members

Participate in team meetings and discussions of project scope Evaluate the project scope All communications with the team lead Discuss problems faced and ideas for actions to take with the team

Risks:

The following risks for the project have been identified. The project manager is responsible to

take necessary actions to avoid or mitigate these.

Disruptions to current operations during implementation

Potential security threats to the system

Summary Milestone Schedule:

Following is the estimated summary milestone schedule which is bound for modifications which

will be informed by the project manager through status reports.


10

Project Milestone Target duration (days) Target date Project commencement - 17.01.2011 Complete project planning 30 28.02.2011 Complete solution design 20 31.03.2011 Complete solution coding 100 09.06.2011 Complete testing and implementation 20 10.08.2011 Deploy solution 3 04.09.2011 Project closure 10 07.09.2011 Total No. Of Days 180

Project Approval Requirements:

Project is successfully completed when the system is fully tested and implemented and the final

reports have been submitted. Success will be determined by the project sponsor, Mr. Jagath

Perera, who will also authorize the completion of the project.

Project Manager:

Charith Sooriyaarachchi is the Project Manager for the CSS project for Sarasi Musical Centre He

is responsible for all project tasks, scheduling and communications regarding the project. He will

also coordinate all resource, schedule and budget requirements. He is authorized to approve

budget expenditures up to and including the approved amount. Any additional changes to the

estimations for cost and budget will require him to communicate to Project Sponsor. He will

provide weekly status reports to the Project Sponsor.

Authorization:

Approval by the Project Manager:

Date:

---------------------

Charith Sooriyaarachchi

Project Manager

Approved by the Project Sponsor:

Date:

---------------------

Jagath Perera

Owner, Sarasi Musical Center


11

CHANGE MANAGEMENT PLAN

Project Name: On-line Customer Service System (CSS) for Sarasi Musical Centre

Prepared by: Project Manager

Date: 05.03.2011

Purpose:

Ensure that all changes to the project are reviewed and approved in advance All changes are coordinated across entire project All stakeholders are notified of approved changes to the project All project change requests must be submitted in written form using the change request

form provided in Appendix

Goals:

Give due consideration to all requests for change Identify, define, evaluate, approve and track changes through to completion Modify project plans to reflect the impact of the changes requested Negotiate changes and communicate them to all affected parties

Responsibilities:

Role Responsibility

Project Manager Develop change management plan

Facilitate and execute change management process

Conduct reviews with stakeholders and senior management

Change Management committee Identify, define and evaluate change requests and feasibility of adopting the

change

Client Make change requests, accept/ reject change impact


12

Change Management Process:

Submit written CR Review CR Accept?

Perform analysis

Yes

Develop

recommendation

No Notice submitter

Accept?

Update project

documents

Yes

Re-plan

No Reject CR

Notify all

stakeholders

Appeal?

Yes

No

End

Start

Notice submitter Appeal?

Yes

No End

Notice submitter

End

(Adopted from: CVR/IT, 2004)

Change Management and Control:

Change Documents to review

Scope Scope statement, WBS, budget, schedule, resource plan, risk response plan, requirements, specification

Schedule Schedule, budget, resource plan, risk response plan

Budget Budget, schedule, resource plan, risk response plan

Quality Budget, schedule, resource plan, risk response plan, quality plan, requirements, specifications

Changes to the project documents require version history to be updated and the prior versions will be maintained in the archive.

For this project, all electronic documents are maintained in a central storage available at, pm-project (available at http://code.google.com/p/pm-project/)

Authorization:

Approval by the Project Manager: Date: --------------------- Charith Sooriyaarachchi Project Manager


13

TIME AND COST ESTIMATION

PROBABILISTIC (DEFINITIVE) ESTIMATION MODEL

The following table is the application of the PERT technique to calculate the activity durations

Table 1 : Activity Durations

ID Activity Name Duration(days) Optimistic Pessimistic Realistic Expected Variance

1 Project charter 3 6 4 4.16 0.25 2 Scope planning 3 5 3 3.33 0.11 3 Requirements management plan 7 12 10 9.83 0.69 4 Project schedule 3 4 3 3.17 0.03 5 cost management plan 4 6 5 5 0.11 6 Develop quality management plan 4 6 5 5 0.11 7 Risk register 3 5 4 4 0.11 8 Design UI 10 15 12 12.17 0.69 9 Design Middle-Tier 35 40 35 35.83 0.69 10 Design Database 10 12 10 10.33 0.11 11 Design Test cases 8 10 9 9 0.11 12 Develop Training 4 5 5 4.83 0.03 13 Develop UI 17 20 20 19.5 0.25 14 Develop Database 10 12 10 10.33 0.11 15 Develop Customer forms 40 50 44 44.33 2.78 16 Develop staff forms 40 50 44 44.33 2.78 17 Develop Tests cases 7 10 8 8.17 0.25 18 Execute Usability Tests 3 4 3 3.17 0.03 19 Execute Unit Test 80 100 88 88.67 11.11 20 Execute Database Test 12 15 12 12.5 0.25 21 Execute Acceptance 3 5 4 4 0.11 22 Deploy Application to Web Server 2 3 2 2.17 0.03 23 Go Live 2 3 2 2.17 0.03 24 Establish standards and procedures 1 1 1 1 0 25 Design technical infrastructure 2 4 3 3 0.11 26 Select tools 3 5 4 4 0.11 27 Monitor project quality 170 180 180 178.33 2.78 28 Form project team 2 3 2 2.17 0.03 29 Manage Project Team 174 177 176 175.83 0.25 30 Attend status meetings 180 200 190 0 11.11 31 Conduct Procurements 15 20 18 17.83 0.69 32 Complete documentation 190 200 190 0 2.78 33 Attend Lessons Learned meeting 2 3 2 2.17 0.03 34 Evaluate product quality 4 5 4 4.17 0.03


14

Expected duration is given by, = + 4 + 6

Variance is given by, = 6

2

Following is the budget estimation to complete the project. All activities are considered

sequential except, activities 27,29,30,32. The total duration is calculated considering those as

parallel activities.

When the wages of the project team is considered, (provided in appendix) the total development

cost can be calculated as follows.

Team Members No of

Personnel

Salary

(monthly)

Duration

(months)

Total (LKR)

Software Architect 1 150,000 1 150,000

DB Engineer 1 160,000 1 160,000

UI Engineer Lead 1 50,000 1 50,000 UI Engineer 1 40,000 1 40,000

Development Team Lead 1 120,000 9 1,080,000

Developers SME 1 120,000 9 1,080,000 Developers 3 80,000 8 1,920,000

Total Development Cost 4,480,000


15

CONSTRUCTIVE COST MODEL (COCOMO)

Out of the four estimation models defined in the COCOMO II model, early design model was

used for this estimation. The recommendation for this model is when requirements are known

and design not been started. These requirements are filled at this stage of the project, which

makes this model most suitable.

According to Sommerville (2006, p. 628), the effort is estimated by using the formula, = The size is given in KSLOC (Kilo Source Lines of Code). This number is calculated using

function points in the system. Unlike COCOMO 81 model, COCOMO II is for object oriented

development. The constant values of B and M in COCOMO 81 is not applicable here. These

values are project specific and needs to be calculated separately.

CALCULATING THE EXPONENTIAL B

Exponential B is based on five scale factors which are rated on a six point scale from very low

to extra high (5 to 0). These ratings are based on assumed values for this project (Sommerville,

2006, p. 632)

Table 2: Five scale factors for

COCOMO

= 100

+ 1.01

=14

100+ 1.01

= 1.15

CALCULATING MULTIPLIER M

Multiplier M is based on seven project and process characteristics. The rating values are based

on the; Early design and post-architecture effort multipliers and COCOMO cost drivers and their

influence on the nominal effort tables provided in the appendix.

Factor Rating

Precedetedness 4

Development flexibility 1

Architecture/risk resolution 0

Team cohesion 5

Process maturity 4

Total rating 14


16

Table 3 : Cost driver influence for COCOMO

The equation for calculating the multiplier is as follows; (Sommerville, 2008, p. 629)

Multiplier M = RCPX RUSE PDIF PERS PREX SCED FCIL

= 1.07 0.82 1.07 0.86 0.95 1.04 0.91

= 0.7259

FUNCTION POINT CALCULATION

According to Pressman (2007, p. 89-90) and Longstreet D. (n.d.); the function point calculation

is as follows.

Table 4 : Function Point Calculation

Information Domain Value Count Count Estimated

Count

Weight FP

Count REC DET FTR Optimistic Most Likely Pessimistic

Internal logical files [ILFs] 8 20 - 26 28 31 28.16 10 281.6

External interface files [EIFs] 4 13 - 15 17 20 17.16 5 85.83

External Inputs [EIs] - 33 8 33 37 41 37 6 222

External Outputs [EOs] - 23 4 22 27 30 27.33 7 191.31

External Inquiries [EQs] - 9 3 10 12 16 12.33 4 49.32

Total Count 830.06

The calculations were based on the Data Flow Diagram provided in the Appendix.

Factor Value

Product reliability and complexity (RCPX) 1.07

Reuse required (RUSE) 0.82

Platform difficulty (PDIF) 1.07

Personnel capability (PERS) 0.86

Personnel experience (PREX) 0.95

Schedule (SCED) 1.04

Support facilities (FCIL) 0.91


17

COMPLEXITY ADGUSTMENT FACTOR

According to Pressman (2007, p.91), the complexity adjustment factors are rated on a not

important or applicable) to 5 (absolutely essential).

Table 5 : Complexity Adjustment Factor Calculation

Function point calculation formula is as follows (Pressman, 2007, p.90) = [0.65 + 0.01 () = 830.06 [0.65 + 0.01 17]

= 680.6492

According to Quantitative Software Management Inc. (2009), for a project with average amount

of project data available and developed in Java, the SLOC/FP (Source Lines of Code/ Function

Points) ration is 55. Using this value to calculate the number of lines of codes gives the

following. = () = 55 680.6492

= 47645.444

Factor Value

Backup and recovery 3

Data communications 1

Distributed processing 0

Performance critical 1

Existing operating environment 0

On-line data entry 5

Input transaction over multiple screens 1

Master files updated on-line 5

Information domain values complex 0

Internal processing complex 0

Code designed for reuse 2

Conversion/installation in design 3

Multiple installations 0

Application designed for change 1

Total Value 17


18

EFFORT REQUIRED = = 2.94 47.6451.15 0.7259

= 181.5281

PROJECT DURATION = 3 ()(0.33+0.21.01) = 3 1820.33+0.21.151.01 = 19.329

Therefore according to this estimate one person needs 20 months to complete the project. Hence,

to complete the project in 9 months, it requires;

20

9= 2.22 3

By considering the lines of codes calculated in this model, the total development cost can be

calculated as below. (Assuming cost per line of code is at Rs. 200)

= = 47645.444 200 = . 9,529,000


19

ESTIMATED BUDGET

Table 6 : Estimated budget

Ref. TOTAL ESTIMATED BUDGET

1.0 Selection Process

Expenditure Cost (daily) Duration (days) Total (LKR)

1.1 Travel and expenses 1000 3 3000

1.2 Legal assistance 5000 3 15,000

1.3 Consultant Assistant 3000 3 9,000

TOTAL SELECTION PROCESS COST 27,000

2.0 Project Team

Team Members No of

Personnel

Salary

(monthly)

Duration

(months)

Total

2.1 Project Manager 1 200,000 9 1,800,000

2.2 Software Architect 1 150,000 1 150,000

2.3 DB Engineer 1 160,000 1 160,000

2.5 Quality Assurance Engineer Lead 1 50,000 8 400,000 2.6 Quality Assurance Engineer 1 40,000 8 320,000

2.7 UI Engineer Lead 1 50,000 1 50,000 2.8 UI Engineer 1 40,000 1 40,000

2.9 Development Team Lead 1 120,000 9 1,080,000

2.10 Developers SME 1 120,000 9 1,080,000 2.11 Developers 3 80,000 8 1,920,000

2.12 Software Trainer Lead 1 40,000 8/20 32,000 2.13 Software Trainer 1 40,000 6/20 24,000

TOTAL PROJECT TEAM COST 7,056,000

3.0 Implementation Process

3.1 Software Total (LKR)

3.1.1 Operating System Linux 0 3.1.2 Integrated Development Environment (IDE) 0

3.1.3 Server 0

3.1.4 Database MySQL 0 3.2 Hardware Total (LKR)

3.2.1 Tomcat 6.0 Server 5,000

TOTAL IMPLEMENTATION PROCESS COST 5,000

Other costs Total (LKR)

4.0 Office facilities 300,000

5.0 Travel and Transport 80,000

6.0 Support staff wages 200,000

TOTAL OTHER COSTS 580,000

TOTAL ESTIMATED BUDGET 7,641,000


20

JUSTIFICATION

The development costs calculated for the two estimation models were Rs. 4,480,000 and Rs.

9,529,000 respectively for definitive and COCOMO. The estimation obtained for COCOMO is

greater than of definitive. We have to identify which of the above two estimations are reliable.

The definitive estimation was based on expert judgment, where as COCOMO was based on the

functionality of the system.

When discussing COCOMO estimation, the SLOC was calculated via the function points (FP).

The number of DETs (Data Element Type), REC (Record Element Type) and FTR (File Type

Referenced) used in FP calculation might change when it comes to actual implementation. At this

estimation stage the designing of the system is not done. Only after designing phase is done,

those parameters become accurate. Therefore, there are a number of errors associated with the FP

calculation. Also, the language used for this project is Java. It is an object oriented language. For

an object oriented language, Object Point analysis must be used and not Function Point analysis.

This has caused further error in the estimation. This is the reason for the very high difference

between the development costs of the two models.

On the other hand PERT estimation has used expert judgment for estimation. Expert judgment is

a better option than COCOMO. The reason is that, expert judgment takes all the quantitative and

qualitative factors into consideration when coming up with estimation. The environmental

factors, inflation, and political factor all these are very important to a project. These are missed

out in COCOMO. The exponential value B and multiplier M calculation also only focuses on

development aspect. The external factors are completely left out. Therefore, I think definitive

estimation is the better estimation to be used here.


21

REFLECTION

This project has a few project management areas which were divided among the group members.

Therefore, each member becomes knowledgeable in their respective areas. This chapter provides

a reflection on the experiences and the knowledge gained by each individual.

This project required a group of 3 students to select a project and to carry out the main planning

tasks for that project. A team is a small number of people with complementary skills who are

committed to a common purpose, performance goal and approach for which they are mutually

accountable (Katzenbatch J.R. and Smith D.K., 1993). We had a common goal in this project. We

all wanted to submit an excellent piece of work as the final submission. Our group was Charith,

Thilok and I. Charith was appointed as the leader of the group Thiloks and mine suggestion.

According to Curtis R. (1995), there are four stages in group development. They are forming,

storming, norming and performing. I and Charith have done a lot of projects together in a group.

Thilok was the new member to our group. Although he was new to working with us in projects

we have done tutorials in class and studies and were very familiar with each other. Therefore, we

were able to start ahead straight away with performing stage. This was very advantageous, since

this helped us save a lot of time.

Thilok was able to find a software project very early of the assignment hand-in. The project was

interesting and we were good enough to have an early start. We reviewed our work often and this

helped us to identify flows and errors which we were able to correct and move on. Since most of

the activities in the project are dependent of each other, other members were able to tell what

he/she needs as output from an activity. This resulted in a number of rework, but the output is

benefitted. I believe we did a good job as a team. This group is the best and the easiest to go with

group I was in since my second year. I am also satisfied with the amount of work we did and the

quality of that work we produced as a team.

Project Charter

This was the very first task we had to do in the project. According to Project Management

Institute (2008, p. 44), the project charter includes the definition of initial scope, the resources,


22

and when the charter is approved by all the related parties, the project can be considered as an

officially authorized project.

The charter included; business need, business objective, project description, constraints,

assumptions, initial scope statement, product acceptance criteria, deliverables, requirements,

exclusions, roles and responsibilities, risks, summary milestone schedule and project approval

requirements. This document defines the boundaries of the project. The scope statement was

done after developing the charter, which created new requirements and boundaries. Therefore the

original scope statement defined at the charter was changed later. It would have been highly

advantageous if the charters initial scope statement could have been made more accurate at the

first stage. I realized that the amount of data gathering that was performed was not sufficient. But

this problem was later corrected with help interviews and surveys, those results are presented in

the appendix.

When selecting a suitable template for the charter, I went through a number of options. The

requirements of PMI were not completely met in most of them. The best template that addresses

PMI requirements was found at Project Management docs website. This sites template was used

to create the charter and also provided guidance to other stages of plan.

As a group we discussed about the charter made necessary changes and also got feedback from

the lecturer which obviously resulted in more changes. Theses feedbacks helped us to create a

good charter which provided a good start to the project.

Change Management Plan

Change is one of the most common terms that occur in project management. There is no project

without a single change to initial scope, schedule and budget. The reason is that unless it is done,

we do not know what can happen. The consequences of certain activities will require changes to

the project. Change management plan is the document that specifies how to deal with this

change and what must be done in order to adopt a change.


23

Change management process has three stages.

Phase 1 - Preparing for change (Preparation, assessment and strategy development) Phase 2 - Managing change (Detailed planning and change management

implementation)

Phase 3 - Reinforcing change (Data gathering, corrective action and recognition) (Decker T., 2011)

The change management plan needs to address all these phases.

According to Mills C. (2008), change management plan is a formal process for tracking and

documenting changes to system and code. Schedule and budget should be added to this

definition.

A template was referred to create the change management plan. The important part of the plan as

I see is the change management process. I drew a flow chart to represent this procedure. It was

also based on a template. Other sections included in the change management plan were;

purpose, goals, responsibilities, change management and control. The change request form

should address all these areas and the phases discussed above. The form is attached in the

appendix.

Time and cost estimation

Estimation means to approximate or predict a quantity based on information available at the

time (Business Dictionary, 2011). This section addresses the estimating of the project duration

and the budget.

This was the most complicated part of the project I did. It took a considerable amount of time for

me to understand the flow of it and how to actually apply. Lecturers feedback helped me to

clarify the doubts I still had after conducting a lot of research. The research was conducted on the

two models mentioned in the assignment specification, definitive model and COCOMO model.

The definitive model corresponded to the PERT estimation. PERT is Program Evaluation and

Review Technique. Another term that often comes with PERT is the CP, Critical Path. Critical

path corresponds to the duration of the project. The activities are arranged based on their


24

dependencies and duration to identify the critical tasks that delays the project if at least one of it

is delayed. This is done via the PERT estimation. Therefore, this estimation became an input to

the scheduling process. Therefore, this had to be done as soon as possible.

PERT uses three-point estimate to define an approximate range for an activities cost/duration.

They are,

1. Most Likely - The cost of the activity, based on realistic effort assessment for the required

2. Optimistic - The activity cost based on analysis of the best-case scenario for the activity.

3. Pessimistic - The activity cost based on analysis of the worst-case scenario for the

activity.

(PMI, p.172)

In this assignment I used these three estimates to calculate the activity durations which are

provided in the definitive estimation chapter. The estimates were obtained with help from

experts. The formulas used for the calculation are also mentioned.

A problem I faced with the PERT estimation was that how these result in identifying the project

duration. It was a misunderstanding to think that PERT gives the project duration. All it gives is

the activity duration. The project duration must be calculated later in the scheduling process.

With these duration estimates, and the resource allocation for the tasks and based on the wage

data, the cost for the project was determined.

COCOMO has two versions. COCOMO II model addresses the non-structured programming

language based development, where as COCOMO 81 addresses structured programming

development. Since we use Java as the development language, COCOMO II model had to be

used.

COCOMO II has three main models.

1. Application composition model - Used during the early stages of software engineering,

when prototyping of user interfaces, consideration of software and system interaction,

assessment of performance, and evaluation of technology maturity are paramount.


25

2. Early design stage model - Used once requirements have been stabilized and basic

software architecture has been established.

3. Post-architecture-stage model - Used during the construction of the software.

(Pressman, p.133)

Therefore, the model suited for this model was early design stage model. The basic formula of

COCOMO II is given by, = This equation gives the effort of the project in Person Months.

Different models require different methods for calculating the variables in this. The early design

model requires function point analysis to determine the size which is given as KSLOC (Kilo

Source Lines of Code). The other variables; A is a constant; exponential B was calculated based

on five scale factors of COCOMO and multiplier M was calculated based on the cost drivers for

COCOMO.

Function Point Analysis (FPA) is a method to break systems into smaller components, so they

can be better understood and analyzed. (Longstreet D., n.d.)

Function point counting process requires the Data Flow Diagram to identify the components of

the calculation. These components are rated based on DETs (Data Element Type), REC (Record

Element Type) and FTR (File Type Referenced).

(Source: Longstreet D., n.d.)

The counting had to be done carefully and it was a time consuming task. Based on the RET, FTR

and DET values for a component a rating is done which contributes to the final FP count. Using

this count and the ratio of SLOC/FP for Java language which was 55 for a project with average

information, the SLOC was calculated and was used in COCOMO equation to find the effort.


26

COCOMO only gives the development cost of the project. When a cost is given for a SLOC, the

total development cost can be calculated using the total SLOC.

Comparison of the two development cost values obtained for the two models, results in the

comparison to reject one model and to accept another. This information is presented in the

justification of this chapter.

COCOMOs other equation is, = 3 ()(0.33+0.21.01) This gives the duration for a single person to complete the project. This value has to be divided

by the project duration to get the number of developers needed. This number must fit in to the

development cost calculated above.

The reasoning behind using definitive modeling is given in the time and cost estimation chapter.

To create the budget, other factors were also considered. The budget is also given in that chapter.

Throughout the assignment duration we worked smoothly as a team. Ideas were communicated

and discussed and problems were solved, which helped a great deal in the final output. All the

members worked hard and supported each other well. We started working on this project from

the very beginning. During the CCSD submission we had to refrain from touching PM because

of the work load in CCSD was too much. However, we did not face any problems in time

because we had already started when CCSD submission drew closer. We worked as a team

throughout and I believe the final output has its results.


27

REFERENCE

Leung H., Fan Z., (n.d), Software Cost Estimation, [online] Available: http://doc-08-8k-docsviewer.googleusercontent.com/viewer/securedownload/hnllvp835hfud3q01m3ohjfmp9k [28th February 2011] Horowitz E., et al, (1998), COCOMO II Model Definition Manual [online] Available: http://doc-0g-8k-docsviewer.googleusercontent.com/viewer/securedownload/hnllvp835hfud3q01m3ohjfmp9kd98p [28th February 2011] Pressman, R.S. (2001) Software Engineering:Apractitioners Approach, 5th edition, New York:

Casson, T.

Project Management Institute (2008) A Guide to the Project Management Body of Knowledge,

4th edition, Pennsylvania: Project Management Institute, Inc.

Sommerville, I., (2006), Software Engineering, 8th Edition, Addison Wesley.

Longstreet D. (n.d.), Function Points Analysis Training Course

CVR/IT. (2004), Change management plan template, [online] Available:

http://nfe2009.googlecode.com/files/Change_Management_Plan_Template.doc [05th February

2011]

Quantitative Software Management Inc., (2009), Function Point Languages Table, [online]

Available: http://www.qsm.com/?q=resources/function-point-languages-table/index.html [01st

March 2011]

Katzenbach, J.R. & Smith, D.K. (1993), The Wisdom of Teams: Creating the High-performance

Organization, Boston: Harvard Business School

Project Management Docs (2009), Templates [online], Available:

http://www.projectmanagementdocs.com [Accessed 15.01.2011 to 03.03.2011]


28

Decker T. (2011), Change management - the systems and tools for managing change [online],

Available: http://www.change-management.com/tutorial-change-process-detailed.htm [Accessed

28.02.2011]

DHS-Oregon department of human services, (n.d.), Change management plan template [online],

Available :

http://www.oregon.gov/DHS/admin/bpm/btm/docs/change_mgmt_plan_template.doc?ga=t

[Accessed 03.03.2011]

Mills C. (2008), Leading Your Organization through Change: A Management Plan 5 Rules for

Success [online], Available: http://www.tagonline.org/articles.php?id=266 [Accessed 03.03.2011]


29

WORK BREAKDOWN STRUCTURE

According to clients requirements Top Down structure was selected as WBS development

methodology. Final products for WBS were identified according to project scope statement.

Project Title: On-line Customer Service System (CSS) for Sarasi Musical Centre

Date Prepared: 05.02.2011

1. On-line Customer Service System 1.1. Initiation

1.1.1. Manage Integration planning 1.1.1.1. Project charter development

1.1.2. Manage HR planning 1.1.2.1. Stakeholders analysis.

1.2. Planning 1.2.1. Manage Integration planning

1.2.1.1. Project Management Plan 1.2.2. Manage Scope planning

1.2.2.1. Scope Defining 1.2.3. Manage Schedule Planning

1.2.3.1. Define activities 1.2.3.2. Estimate Activity Resources 1.2.3.3. Develop schedule

1.2.4. Manage Requirement gathering 1.2.4.1. Requirements Collecting

1.2.5. Manage test planning 1.2.5.1. Test plan Creation

1.2.6. Manage cost planning 1.2.6.1. Estimate cost 1.2.6.2. Budget Determining

1.2.7. Manage quality planning 1.2.7.1. Quality Planning

1.2.8. Manage HR planning 1.2.8.1. Human Resources Plan Development

1.2.9. Manage communications planning 1.2.9.1. Communication Planning

1.2.10. Manage risk planning 1.2.10.1. Risk management planning

1.3. Execution 1.3.1. Manage Design

1.3.1.1. Develop use cases 1.3.1.2. Design Software

1.3.1.2.1. UI Designing


30

1.3.1.2.2. Middle-Tier Designing 1.3.1.2.3. Database Designing 1.3.1.2.4. Training Designing

1.3.1.3. Design Test 1.3.1.3.1. Usability Tests Designing 1.3.1.3.2. Unit Test Designing 1.3.1.3.3. Database Test Designing 1.3.1.3.4. Acceptance Test Designing

1.3.2. Manage Development 1.3.2.1. Develop Training 1.3.2.2. UI Developing

1.3.2.2.1. Login 1.3.2.2.2. Shopping Cart 1.3.2.2.3. Registration 1.3.2.2.4. Comparison 1.3.2.2.5. Search 1.3.2.2.6. Repair 1.3.2.2.7. Staff view

1.3.2.3. Middle-Tier Developing 1.3.2.3.1. Login 1.3.2.3.2. Shopping Cart 1.3.2.3.3. Registration 1.3.2.3.4. Comparison 1.3.2.3.5. Search 1.3.2.3.6. Repair 1.3.2.3.7. Staff view

1.3.2.4. Develop Database 1.3.2.5. Configured Software 1.3.2.6. Customized User Documentation 1.3.2.7. Customized Training Program Materials 1.3.2.8. Tests Developing

1.3.2.8.1. Usability Tests Developing 1.3.2.8.2. Unit Tests Developing 1.3.2.8.3. System Tests Developing 1.3.2.8.4. Integration Tests Developing 1.3.2.8.5. Environment Tests Developing 1.3.2.8.6. Test Documentation Creating

1.3.2.9. Tests Executing 1.3.2.9.1. Usability Tests Designing 1.3.2.9.2. Unit Test Designing 1.3.2.9.3. Database Test Designing 1.3.2.9.4. Acceptance Test Designing

1.3.3. Manage Deployment 1.3.3.1. Schedule User Training 1.3.3.2. Schedule User Training 1.3.3.3. Rollout


31

1.3.3.3.1. Back up databases 1.3.3.3.2. Application Deploying 1.3.3.3.3. Verification tests 1.3.3.3.4. Go Live

1.3.4. Manage quality 1.3.4.1. Manage quality assurance

1.3.4.1.1. Project standards and procedures establishing 1.3.4.1.2. Technical infrastructure Designing 1.3.4.1.3. Project environment Configuring 1.3.4.1.4. Perform audits

1.3.5. Manage HR 1.3.5.1. Project team forming 1.3.5.2. Project Team Managing

1.3.6. Manage communications 1.3.6.1. Attend status meetings 1.3.6.2. Communication management plan

1.4. Closing 1.4.1. Manage maintenance

1.4.1.1. Performance Monitoring 1.4.1.2. Training and support issues Resolving 1.4.1.3. Technical problems resolving

1.4.2. Manage acceptance 1.4.2.1. Demo product to SHs, SMEs and FMs

1.4.3. Manage communications closure 1.4.3.1. Documentation Completion 1.4.3.2. Attend Lessons Learned meeting

1.4.4. Manage quality closure 1.4.4.1. Product quality Evaluating

1.4.5. Manage risk closure 1.4.5.1. Identify future risks

1.4.6. Manage procurement closure 1.4.6.1. Close out contracts

1.4.7. Manage HR closure 1.4.7.1. Provide PE feedback to team members 1.4.7.2. Provide PE feedback to team members' managers 1.4.7.3. Provide PE feedback to vendors and consultants

1.4.8. Manage integration closure 1.4.8.1. Consolidate and index documentation 1.4.8.2. Create summary statistics for historical reference


32

BASELINE SCHEDULE

GANTT CHART

Primary activities of WBS elements identified and Gantt chart was developed with appropriate

predecessors and resources.


33

CRITICAL PATH ANALYSIS

One critical path identified for the project as highlighted in represented in the following network

diagram.

Identified Critical path is 4, 6, 7, 10 ,11 ,13 ,14, 16, 17, 19,20 ,22, 23, 25, 26, 30, 37, 42, 44, 53,

54, 56, 57, 58 59,64, 65, 66 which is highlighted with a completion time of 179 days


34

PROJECT CRASHING

Activity ID

Activity Normal Time

Crash Time Normal cost(LKR)

Crash Cost(LKR)

Crash coat/day

40 Design Middle-Tier 14 10 301000 387000 21500

50 Develop Middle-Tier 100 96 3200000 3328000 32000

61 Execute Acceptance Test 2 - 6000 - -

64 Deploy Application to Web Server

1 - 18000 - -

66 Schedule user training 1 - 10000 - -

Determine Budget, Design UI and Design Middle- Tier activities has latency comparing to base

line and because of that project duration is expanded to 183 days where client required project in

180 days and project baseline is planned for 179 days. The project needed to crash activities to

reduce project duration to 179 days which is 4 days of crashing.

Crashing of five project activities on critical path that not yet finished was considered and the

details are as follows.

The lowest cost activities on the critical path, activity 61 was considered and it has already crashed to the maximum desired level of crashing. Other two critical activities

also in the maximum desired level of crashing

The next lowest cash activity on the critical path activity 40 was considered and it can be further crashed to a crash time of 8 days and crash cost of 21500 LKR per day. The new

critical path was calculated and path stays the same with new activity duration of 179

days.


35


36

QUALITY MANAGEMENT PLAN

1.0 INTRODUCTION

The Project Quality Management process determines three main processes which should be

achieved by the project performing organization. These processes are called Quality Planning,

Quality Assurance and Quality Control. (PMI, 2004, p.179)

The Quality Management Plan document is to highlight above mentioned three steps on the

project of Sarasi Musical Center Online Customer Service System.

1.1 PURPOSE OF PROJECT QUALITY MANAGEMENT PLAN

According to PMI (2004, p.181), a Quality Management Plan increases the productivity of a

project as follows.

Customer Satisfaction Improves customer satisfaction Prevention over inspection Reduces project costs Management responsibility Ensures product quality Continues Improvement Assures continues improvement of the product

(PMI, 2004, p.181)

2.0 PROJECT QUALITY MANAGEMENT

2.1 QUALITY PLANNING

Quality Planning involves in identifying which quality standards are relevant to the project and

the way of achieving those standards. (PMI, 2004, p.183)

2.1.1 DEFINE PROJECT QUALITY

According to PMI (2004, p.180) quality is the degree to which a set of inherent characteristics

fulfill requirements.


37

2.1.2 MEASURE PROJECT QUALITY

The following table illustrates the standards which have to be followed throughout the project

life cycle.

Quality ID

Software Quality

Quality Measure Quality Role

Q1 Functionality Login to the system Team Lead Q2 Functionality Register in the system Team Lead Q3 Functionality Search instruments by category Team Lead Q4 Functionality Quality, brand, price, guarantee, features of

instruments must be available Team Lead

Q5 Functionality The details must be displayed in a comparative manner

Team Lead

Q6 Functionality The details must be displayed in a comparative manner

Team Lead

Q7 Functionality Enable payments through Visa and PayPal Team Lead Q8 Functionality Request for a repair Team Lead Q9 Functionality Display cost for repair Team Lead Q10 Functionality Reserve instruments with an advance payment of

5-15% of original value Team Lead

Q11 Functionality Purchase instruments Team Lead Q12 Functionality Request items that are not currently available in-

store, and inform when such a requested item is available

Team Lead

Q13 Functionality Add new users and update current users Team Lead Q14 Functionality Retrieve purchase details to deliver the

instrument Team Lead

Q15 Functionality Retrieve reservations details to keep the instrument reserved

Team Lead

Q16 Functionality Calculate cost for repair and update in system Team Lead Q17 Functionality Update status of instruments that were requested

by customers Team Lead

Q18 Functionality Retrieve transactions data for accounting and billing purposes

Team Lead

Q19 Cost and Schedule

Deliver product within 180 days Project Manager

Q20 Cost and Schedule

Should not exceed the budget of Rs.800,000 Project Manager

Q21 Availability The system should be up and running 24 hours a day and 7 days a week

Q22 Performance All functionalities needs to have a minimum response time of 5 seconds

Team Lead

Q23 Performance System should display a minimum of 95% accuracy

Team Lead

Q24 Reusability Should be able to update inventory data from the Database


38

current database of Inventory and POS system Administrator Q25 Security Transactions must be secured using SSL protocol

as the minimum Senior Network Engineer

Q26 Security System should be secure from security violation and vulnerabilities

Senior Network Engineer

Q27 Usability A user friendly system must be developed, considering the ISO standard for HCI

Team Lead

Q28 Testability Solution must be fully tested before deployment Senior Quality Assurance Engineer

Q29 Source codes must follow Secure Coding Guidelines for the Java Programming Language, Version 3.0

Team Lead

Q30 Documentations and plans must follow PMI standards

Business Analyst

2.2 QUALITY ASSURANCE

According to PMI (2004, p.187), Quality Assurance is the application of planned, systematic

quality activities to ensure that the project will employ all the processes needed to meet the

requirements.

2.2.1 ANALYZE PROJECT QUALITY

The following table illustrates how the identified quality standards are achieved in the project by

performing a Quality Assurance Activity.

Process Quality Standards/Stakeholder Expectations

Quality Assurance Activity Frequency

Login to the system Unit Testing, Integration Testing As needed Register in the system Unit Testing, Integration Testing As needed Search instruments by category Unit Testing, Integration Testing As needed Quality, brand, price, guarantee, features of instruments must be available

Unit Testing, Integration Testing As needed

The details must be displayed in a comparative manner


The details must be displayed in a comparative manner


Enable payments through Visa and PayPal Unit Testing, Integration Testing As needed Request for a repair Unit Testing, Integration Testing As needed Display cost for repair Unit Testing, Integration Testing As needed Reserve instruments with an advance payment of 5-15% of original value



39

Purchase instruments Unit Testing, Integration Testing As needed Request items that are not currently available in-store, and inform when such a requested item is available


Add new users and update current users Unit Testing, Integration Testing As needed Retrieve purchase details to deliver the instrument


Retrieve reservations details to keep the instrument reserved


Calculate cost for repair and update in system


Update status of instruments that were requested by customers


Retrieve transactions data for accounting and billing purposes


Deliver product within 180 days Audit project schedule plan, Audit monthly status reports

Once a month

Should not exceed the budget of Rs.800,000

Audit project budget estimation, Audit monthly status reports

Once a month

The system should be up and running 24 hours a day and 7 days a week

Functional Testing, Performance Testing

Once

All functionalities needs to have a minimum response time of 5 seconds

Performance Testing As needed

System should display a minimum of 95% accuracy

Performance Testing, Load Testing As needed

Should be able to update inventory data from the current database of Inventory and POS system

Compatibility Testing As needed

Transactions must be secured using SSL protocol as the minimum

Functional Testing, Conformance Testing

As needed

System should be secure from security violation and vulnerabilities

Functional Testing, Conformance Testing

As needed

A user friendly system must be developed, considering the ISO standard for HCI

Conformance Testing As needed

Solution must be fully tested before deployment

System Testing Once

Source codes must follow Secure Coding Guidelines for the Java Programming Language, Version 3.0

Conformance Testing During Unit Testing

Documentations and plans must follow PMI standards

Audit project documentation Once a month

The data belongs to Frequency column in above table varies due to product defects.


40

2.2.2 IMPROVE PROJECT QUALITY

In order to improve the quality of the project, a defect management mechanism is being

followed. The following table illustrates a sample Defect Log which is used to record the

software defects identified in Quality Assurance process. (Rehan, 2011a)

Defect ID

Description of Defect

Severity (Critical/Moderat

e/Low)

Priority (High/Moderate/

Low)

Assigned to Current Status

QD001 The application does not login to the system successfully

Critical High Shanil Perera Error not get solved yet

2.3 QUALITY CONTROL

The Quality Control process should be performed throughout the project and it involves

monitoring specific project results to determine whether they comply with relevant quality

standards and identifying ways to eliminate causes of unsatisfactory results. (PMI, 2004, p.190)

The following diagram illustrates a sample Test Case used in order to carry out Quality Control

process.

Business Case Scenario

Name of Tester

Test Script How the script supposed to

behave

How the script actually behaves

Status of test

Login to the system Namal Fernando

Login to the system successfully

Logged in to the system successfully

Pass


41

RISK MANAGEMENT

Project Risk Management is a process which concerns with six major processes which are

updated throughout the project. The probability and impact of all positive and negative risks are

considered and increasing the probability of positive risks and decreasing the probability of

negative risks will be the objective of whole process. (PMI, 2004) According to PMI (2004), the

Project Risk Management processes include the following:

Risk Management Planning Risk Identification Qualitative Risk Analysis Quantitative Risk Analysis Risk Response Planning Risk Monitoring and Control

According to PMI (2004, p.241) the each of the above processes generates an output and all

these outputs are very important documents in terms of Risk Management. In order to identify

and avoid the risks related to the project which is being developed, a Risk Management Plan

should be prepared and reviewed by the Project Sponsor.


42

RISK MANAGEMENT PLAN DOCUMENT Project Name: On-line Customer Service System (CSS) for Sarasi Musical Centre

Company Name: Sarasi Musical Centre

Date: 21/01/2011

Introduction

The risks related to the project are identified and monitored throughout this document and all six

steps required in this process are fully described and documented.

Risk Management Approach

Risk Management Planning: the first step and the approach to the Risk Management Plan starts

with the Risk Breakdown Structure (RBS). (PMI, 2004, p.244)

Project

Technical Risks Project Management Risks Organizational Risks External Risks

Technology

Performance

Reliability

Requirements

Estimating

Planning

Controlling

Funding

Project Dependencies

Market/Economy

Country/Political/Social

Factors

Technical Resources

Human Resources

PMI (2004, p.244)

The above diagram illustrates the RBS for the project.


43

Risk Identification

According to the standard methods of PMI (2004, p.247) the risks associated with the project are

identified with the use of Risk Identification tools and techniques.

Documentation Reviews The past project plans and documentations are reviewed. Information Gathering Techniques

Brainstorming The project team performed the brainstorming session. Basically, the ideas about the project risks are generated and collected for consideration in Risk

Assessment Meeting. The Risk Breakdown Structure is used for this activity.

Risk Assessment Meeting The key stakeholders and team members participated. The results of the Brainstorming session are concerned and categorized by the types

mentioned in the Risk Breakdown Structure. New risks are identified and categorized.

Interviewing One expert interview was held for this project. (PMI, 2004, p.247)

The following table illustrates what are the risks identified for the project and what are the

methods used to identify those risks. Risk The method identified Category (According

to RBS) Under estimation of schedule Documentation Reviews Management Risks

(Estimating/Planning) Under estimation of resources Documentation Reviews Management Risks

(Estimating/Planning) Under estimation of budget Documentation Reviews Management Risks

(Estimating/Planning) Continues changes of the scope statement (Project scope)

Documentation Reviews Management Risks (Controlling)

The project requirements are not clearly identified

Risk Assessment Meeting/ Documentation Reviews

Management Risks (Planning)

The technology used is failed to fulfill the requirements of the project.

Brainstorming Technical Risks (Technology)

The development team is not familiar with the chosen technology.

Brainstorming Technical Risks (Technology)

The members of the project team leave the project

Risk Assessment Meeting Organizational risks (Human Resources)

The members of the project team will Risk Assessment Meeting Organizational risks


44

not be able to work because of the unexpected circumstance (i.e., Illnesses)

(Human Resources)

Failure of equipment Interviewing Technical Risks (Technical Resources)

The efficiency of the system is lower than the client expects.

Interviewing Technical Risks (Requirements)

Less reliability of the system Interviewing Technical Risks (Reliability)

The developed system fails to address the user requirements.

Brainstorming/ Documentation Reviews

Technical Risks (Requirements)

Due to the errors occur in the developed system, the final product fails the user acceptance test.

Interviewing Technical Risks (Requirements, Reliability, Performance)

The developed web application cannot be hosted in the Web Server due to technical errors (i.e., different types of platforms).

Risk Assessment Meeting Technical Risks (Technology, Technical Resources)

The developed web application cannot be hosted in one of the organizations current Web Servers (i.e., not enough resources) and a new Server have to be purchased.

Brainstorming Technical Risks (Technical Resources)

The security features of the developed web application are poor.

Brainstorming Technical Risks (Performance)

The government appoints new rules which highly impacts on the business transactions of the client, so the client terminates the project.

Brainstorming External Risks (Country/Political/Social Factors)

The client is not comfortable in affording the system in end of the development due to economic facts.

Brainstorming/ Interviewing

Organizational risks (Funding)

In the stages of Gathering Requirements and Requirement Analysis, the company employees (Employees of Sarasi Musical Center) will not provide required information.

Risk Assessment Meeting Organizational risks (Project Dependencies)


45

RISK QUALIFICATION AND PRIORITIZATION

Qualitative Risk Analysis and Quantitative Risk Analysis

According to the standard methods of PMI (2004, p.253, 257), the Outputs of the Qualitative

Risk Analysis and Quantitative Risk Analysis steps are identified and given below.

Probability and Impact Matrix

10

9

8

7

6

5

4

3

2

1

1 2 3 4 5 6 7 8 9 10

(MindTools, 2011)

The above chart represents the following characteristics.

Low impact Scale of: 1 to 5

High Impact Scale of: 6 to 10

Low probability Scale of: 0.01 to 5.99

High probability Scale of: 6.00 to 10.00

Low impact/Low probability Identified as Low level risks.

Low impact/High probability Identified as Medium level risks.

Probability of

Occurrence

Impact of Risk

Medium-level Risk

Medium-level Risk Low-level Risk

High-level Risk


46

High impact/Low probability Identified as Medium level risks.

High impact/High probability Identified as High level risks.

The following table illustrates how the Risk Scores are given to each Risk, according to the

Probability and Impact Matrix.

Risk Probability (P) of

Occurrence

Impact (I) of Risk

(1 -10)

P*I Priority (Rank)

Under estimation of schedule 0.90 10 9 1 Under estimation of resources 0.30 4 1.2 10 Under estimation of budget 0.30 10 3 4 Continues changes of the scope statement (Project scope)

0.70 4 2.8 5

The project requirements are not clearly identified 0.20 9 1.8 7 The technology used is failed to fulfill the requirements of the project.

0.10 3 0.3 14

The development team is not familiar with the chosen technology.

0.10 4 0.4 13

The members of the project team leave the project 0.60 9 5.4 2 The members of the project team will not be able to work because of the unexpected circumstance (i.e., Illnesses)

0.50 8 4 3

Failure of equipment 0.30 3 0.9 12 The efficiency of the system is lower than the client expects.

0.20 7 1.4 9

Less reliability of the system 0.30 7 2.1 6 The developed system fails to address the user requirements.

0.30 7 2.1 6

Due to the errors occur in the developed system, the final product fails the user acceptance test.

0.10 10 1 11

The developed web application cannot be hosted in the Web Server due to technical errors (i.e., different types of platforms).

0.10 4 0.4 13

The developed web application cannot be hosted in one of the organizations current Web Servers (i.e., not enough resources) and a new Server have to be purchased.

0.10 3 0.3 14

The security features of the developed web application are poor.

0.20 8 1.6 8

The government appoints new rules which highly impacts on the business transactions of the client, so the client terminates the project.

0.01 10 0.1 15

The client is not comfortable in affording the system in end of the development due to economic facts.

0.01 10 0.1 15


47

In the stages of Gathering Requirements and Requirement Analysis, the company employees (Employees of Sarasi Musical Center) will not provide required information.

0.20 5 1 11

In the end of the Quantitative Risk Analysis, the risks identified for the project are prioritized.

The following diagram illustrates a complete visual overview on all the risks and the according

to the Probability and Impact, the risks are divided in to four categories.

(Tulser, 1996)

According to Tulser (1996) the risks fall under Tigers category are the most dangerous risks.

These risks should immediately be monitored and controlled. Alligators are the second level of

risks which can be avoided with care. The risks belong to puppies category can be avoided with a

little care and the risk in kittens category can probably be ignored.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10

Pro

ba

bil

ity

Impact

Risk

Puppies

Kittens

Tigers

Alligators


48

RISK MONITORING AND CONTROL

According to the standard methods of PMI (2004, p.267), the Outputs of the Risk Monitoring

and Control step are identified and given below.

Risk Priority

Risk Response Strategy

Actions to implement Risk Manager

1 Under estimation of schedule Avoidance Gantt chart, Expert Judgment and Analyzing past projects

Project Manager

2 The members of the project team leave the project

Avoidance Salary bonuses, Reduce the workload on each employee

Project Manager

3 The members of the project team will not be able to work because of the unexpected circumstance (i.e., Illnesses)

Mitigation Reduce the workload on each employee

Project Manager

4 Under estimation of budget Avoidance Earn Value Analysis, Expert Judgment, Analyzing past projects

Project Manager

5 Continues changes of the scope statement (Project scope)

Avoidance Signed off System Requirements Specification Document, Proper Change Management Plan

Business Analyst

6 Less reliability of the system Mitigation Use of best software engineering practices

Team Lead

6 The developed system fails to address the user requirements.

Avoidance Signed off System Requirements Specification Document, Use of best software engineering practices

Business Analyst

7 The project requirements are not clearly identified

Avoidance Signed off System Requirements Specification Document, Continues communication with the client

Business Analyst

8 The security features of the developed web application are poor.

Avoidance Use of best software engineering practices

Team Lead

9 The efficiency of the system is lower than the client expects.

Mitigation Signed off System Requirements Specification Document, Continues communication with the client, Use of best software engineering practices

Team Lead

10 Under estimation of resources Mitigation Expert Judgment, Analyzing past projects

Project Manager

11 In the stages of Gathering Requirements and Requirement Analysis, the company employees (Employees of Sarasi Musical Center) will not provide required

Mitigation Continues communication with the company employees, Signed off System Requirements Specification Document

Business Analyst


49

information. 11 Due to the errors occur in the

developed system, the final product fails the user acceptance test.

Avoidance Use good Quality Assurance team, Use of industry standard testing techniques

Team Lead

12 Failure of equipment Mitigation Use of daily data backups, Quality Assurance techniques on equipment and software.

13 The developed web application cannot be hosted in the Web Server due to technical errors (i.e., different types of platforms).

Avoidance Quality Assurance techniques on Web Server, Reports from Database Administrator and Senior Network Engineer.

Team Lead

13 The development team is not familiar with the chosen technology.

Mitigation Equip the project technical team (Software Engineers) with the people who have knowledge on the chosen technology.

Team Lead

14 The technology used is failed to fulfill the requirements of the project.

Avoidance Expert Judgment, Analyze past projects

Team Lead

14 The developed web application cannot be hosted in one of the organizations current Web Servers (i.e., not enough resources) and a new Server have to be purchased.

Avoidance Reports from Database Administrator and Senior Network Engineer.

Team Lead

15 The government appoints new rules which highly impacts on the business transactions of the client, so the client terminates the project.

Accepting

15 The client is not comfortable in affording the system in end of the development due to economic facts.

Mitigation Signed off Project Charter Business Analyst

Sponsor Acceptance

Approved by the Project Sponsor: ---------------- Date: -----------------

Jagath Perera,

Chairman, Sarasi Musical Center.


50

COMMUNICATION MANAGEMENT PLAN

PROJECT TEAM DIRECTORY

Role Name Email Phone

Project Sponsor/Client Jagath Perera [email protected] 0112347564

0773487634

Project Manager Charith

Sooriyaarachchi

[email protected] 0779765323

Business Analyst Maheeka Jayasuriya [email protected] 0714574284

Software Team Lead Thilok Gunawardena [email protected] 0776536997

Head of Operations

Management

Heshan Anthony [email protected] 0772983486

Head of Functional

Management

Sukitha Nadeeshan [email protected] 0775998775

Head of Portfolio

Review Board

Isuru Gunasekara [email protected] 0774579336

mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


51

COMMUNICATIONS MATRIX

Communication Type

Objective of Communication

Medium Frequency Audience Owner Deliverables

Project Kickoff Meeting

Introductory meeting on the project, project team and the approach to the project.

Face to Face Once Project Sponsor, Project Team, Portfolio Review Board, Functional Management, Operations Management

Project Manager

Meeting Minutes

Project Team Meetings

Review status of the project

Face to Face Once a fortnight (Friday)

Project Team Project Manager

Meeting Minutes

Technical Design Meetings

Discuss technical problems raised in the implementation

Face to Face As needed Project Team Team Lead

Meeting Minutes

Project Status Meetings

Reports on the status of the project to the management

Face to Face Monthly (5th of every month)

Portfolio Review Board

Project Manager

Project Status reports

Report the status of the project (Activities, Progress)

Email Monthly (10th of every month)

Project Sponsor, Project Team, Head of Portfolio Review Board

Project Manager

Project Status Report

Project Team Meeting reports

Submit Project Team Meeting minutes

Email Once a fortnight (Friday)

Head of Portfolio Review Board

Project Manager

Project Team Meeting minutes

Technical Design Meeting reports

Submit Technical Design Meeting minutes

Email After every Technical Design Meeting

Project Manager Team Lead

Technical Design Meeting minutes


52

EARNED VALUE EVALUATION


53

PROJECT MONTHLY STATUS REPORT

APIIT IT Solutions

Project Monthly Status Report

Project Name: On-line Customer Service System(CSS) for

Sarasi Musical Centre

Prepared By: Project Manager

Date (MM/DD/YYYY): 10th April 2010

Reporting Period: 10th March 2011 9th April 2011

1.0 Executive Summary

Green

(Controlled)

Yellow

(Caution)

Red

(Critical)

Reasons for Deviation

Schedule [X] The project is already behind the

schedule. Causes the errors the

data used to estimate the

schedule.

Budget [X] Being behind the schedule causes

to hire additional human

resources. One additional

Database Developer and one

additional UI Engineer have to be

hired for the months of March and

April in order to get the project to

the schedule.

Scope [X] The situation is under control.

Quality [X] The situation is under control.

Green Project is within budget, scope and on schedule.

Yellow Project has deviated slightly from the plan but should recover.

Red Project has fallen significantly behind schedule, is forecast to be significantly over budget,

and/or has taken on tasks that are out of scope.


54

2.0 Controls

Issue Status: The issue in the estimation in scheduling is reported to the management.

Change Status: Since the schedule of the project is only behind six days, a request for a change is

not considered yet.

Risk Status: The risk of under estimation of schedule is identified as the most important risk in

the Risk Management Plan, with the priority rank of 1. Since the Risk Monitoring and Control

stages have not been conducted properly, recommended corrective actions have to be taken.

3.0 Budget Report

Earned Value Analysis Summary

The following table illustrates a summary of values used in the Earned Value Analysis.

Jan Feb Mar Apr May Jun Jul Aug Sep

Monthly Planned Value

(PV)

574000 460000 419500 1300833 625833 533333 533333 533333 553333

Monthly Actual Cost (AC) 576300 465000 420000 1400000

Monthly Earned Value

(EV)

574000 430000 390500 1290500

Cumulative Planned

Value(PV)

574000 1034000 1453500 2754333 3380166 3913499 4446832 4980165 5533498

Cumulative Actual Cost

(AC)

576300 1041300 1461300 2861300

Cumulative Earned Value

(EV)

574000 1004000 1394500 2685000

Project EV at 31st March

(BCWP)

1394500

Project PV at 31st March

(BCWS)

1453500

Project AC at 31st March

(ACWP)

1461300


55

PV (BCWS) - 1453500

AC (ACWP) - 1461300

EV (BCWP) 1394500

Comments: A crashing should be done in the project Gantt chart to take the project back to the Baseline

schedule.

4.0 Schedule Report Only late milestones and milestones belong to report period are listed.

Milestone Approved Schedule

Actual Current Forecast

Status

Develop Quality Management Plan

07/03/2011-15/03/2011

09/03/2011-16/03/2011

- Completed

Quality Plan Approved

15/03/2011-15/03/2011

16/03/2011-16/03/2011

- Completed

Develop Risk Management Plan

15/03/2011-22/03/2011

18/02/2011-24/03/2011

- Completed

Risk Management Plan Approved

22/03/2011-22/03/2011

24/03/2011-24/03/2011

- Completed

LKR 0.00

LKR 1,000,000.00

LKR 2,000,000.00

LKR 3,000,000.00

LKR 4,000,000.00

LKR 5,000,000.00

LKR 6,000,000.00

28

-De

c

17

-Ja

n

6-F

eb

26

-Fe

b

18

-Ma

r

7-A

pr

27

-Ap

r

17

-Ma

y

6-J

un

26

-Ju

n

16

-Ju

l

5-A

ug

25

-Au

g

14

-Se

p

4-O

ct

Earned Value Analysis

Cumilative Planned

Value(PV)

Cumilative Actual Cost (AC)


56

Develop Procurement Management Plan

22/03/2011-24/03/2011

24/03/2011-28/03/2011

- Completed

Procurement Management Plan Approved

24/03/2011-24/03/2011

28/03/2011-28/03/2011

- Completed

Determine Budget

07/03/2011-11/03/2011

08/03/2011-12/03/2011

- Completed

Cost Performance Baseline

11/03/2011-11/03/2011

12/03/2011-12/03/2011

- Completed

Project Management Plan Baselined

24/03/2011-24/03/2011

28/03/2011-28/04/2011

- Completed

Design UI 24/03/2011-28/03/2011

30/03/2011-31/03/2011

- Completed

Design Middle- Tier

24/03/2011-13/04/2011

30/03/2011 18/04/2011 Not yet completed

Design Database 24/03/2011-31/03/2011

29/03/2011-04/04/2011

Completed

Software Design Approval

13/04/2011-13/04/2011

- 18/04/2011 Not yet Started

Design Test Cases

13/04/2011-20/04/2011


Develop UI 28/03/2011-11/04/2011


Develop Middle-Tier

13/04/2011-31/08/2011


Develop Database

31/03/2011-14/04/2011


5.0 Accomplishments

Accomplishments during this reporting period:

As requested from the Portfolio Review Board and Functional Management, one Database

Developer was provided to the project for the months of March and April (For the tasks of

Design Database and Develop Database).

As requested from the Portfolio Review Board and Functional Management, one UI Engineer

was provided to the project for the months of March and April (For the task of Design UI).

Plans during the next reporting period:

The task named Design Middle Tier which belongs to Project Execution stage is behind the


57

schedule in five days. A request has been sent to Portfolio Review Board and Functional

Management to hire another two Software Developers for one month (15th April to 15th May)

from another project team. This will help to get the project back to Baseline Schedule.

The task named Design Test Cases which belongs to Project Execution stage is behind the

schedule in six days. A requ