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.

PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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




PROJECT MANAGEMENT - CE00348-3
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


PROJECT MANAGEMENT - CE00348-3
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 company’s 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.



PROJECT MANAGEMENT - CE00348-3
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.
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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.

PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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


PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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

PROJECT MANAGEMENT - CE00348-3
14

Expected duration is given by,
ExpcctcJ Ðurotion =
0ptimistic Ðurotion +4 - Rcolistic Ðurotion +Pcssimistic Ðurotion
6

Variance is given by,
Iorioncc = _
Pcssimistic Ðurotion -0ptimistic Ðurotion
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



PROJECT MANAGEMENT - CE00348-3
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,
E¡¡ort (PH) = A × Sizc
B
× H
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
Exponcntiol B =
Iotol Roting
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
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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)
Function Points = Count Iotol × [0.65 +0.01 × (F
i
)
= 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.
Iincs 0¡ CoJc (I0C) = rotio _
SI0C
FP
] o¡ [o:o × Function Points (FP)
= 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
PROJECT MANAGEMENT - CE00348-3
18

EFFORT REQUIRED
E¡¡ort (PH) = A × Sizc
B
× H
= 2.94 × 47.645
1.15
× 0.7259
= 181.5281
F¡¡urt (PM) = 182 Perxun Munth

PROJECT DURATION
IÐEI = 3 × (PH)
(0.33+0.2×(B-1.01))

= 3 × (182)
(0.33+0.2×(1.15-1.01))

= 19.329 montbs
TDFF = 2û munthx

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 Jc:clopcrs

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)

Ðc:clopmcnt Cost = SI0C × Cost pcr SI0C
= 47645.444 - 200
= Rs. 9,529,000


PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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.

PROJECT MANAGEMENT - CE00348-3
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 Thilok’s 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,
PROJECT MANAGEMENT - CE00348-3
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 charter’s 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 site’s 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.


PROJECT MANAGEMENT - CE00348-3
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. “Lecturer’s 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
PROJECT MANAGEMENT - CE00348-3
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.
PROJECT MANAGEMENT - CE00348-3
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,
E¡¡ort (PH) = A × Sizc
B
× H
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.
PROJECT MANAGEMENT - CE00348-3
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.

COCOMO’s other equation is,
IÐEI = 3 × (PH)
(0.33+0.2×(B-1.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.




PROJECT MANAGEMENT - CE00348-3
27

REFERENCE
Leung H., Fan Z., (n.d), Software Cost Estimation, [online] Available: http://doc-08-8k-
docsviewer.googleusercontent.com/viewer/securedownload/hnllvp835hfud3q01m3ohjfmp9k
[28
th
February 2011]

Horowitz E., et al, (1998), COCOMO II Model Definition Manual [online] Available: http://doc-
0g-8k-
docsviewer.googleusercontent.com/viewer/securedownload/hnllvp835hfud3q01m3ohjfmp9kd98
p [28
th
February 2011]


Pressman, R.S. (2001) Software Engineering:Apractitioner’s Approach, 5
th
edition, New York:
Casson, T.

Project Management Institute (2008) A Guide to the Project Management Body of Knowledge,
4
th
edition, Pennsylvania: Project Management Institute, Inc.

Sommerville, I., (2006), Software Engineering, 8
th
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 [01
st

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]

PROJECT MANAGEMENT - CE00348-3
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]











PROJECT MANAGEMENT - CE00348-3
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. Stakeholder’s 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
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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



PROJECT MANAGEMENT - CE00348-3
32

BASELINE SCHEDULE
GANTT CHART
Primary activities of WBS elements identified and Gantt chart was developed with appropriate
predecessors and resources.


PROJECT MANAGEMENT - CE00348-3
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

PROJECT MANAGEMENT - CE00348-3
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.


PROJECT MANAGEMENT - CE00348-3
35

PROJECT MANAGEMENT - CE00348-3
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”.

PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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
Unit Testing, Integration Testing As needed
The details must be displayed in a
comparative manner
Unit Testing, Integration Testing As needed
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
Unit Testing, Integration Testing As needed
PROJECT MANAGEMENT - CE00348-3
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
Unit Testing, Integration Testing As needed
Add new users and update current users Unit Testing, Integration Testing As needed
Retrieve purchase details to deliver the
instrument
Unit Testing, Integration Testing As needed
Retrieve reservations details to keep the
instrument reserved
Unit Testing, Integration Testing As needed
Calculate cost for repair and update in
system
Unit Testing, Integration Testing As needed
Update status of instruments that were
requested by customers
Unit Testing, Integration Testing As needed
Retrieve transactions data for accounting
and billing purposes
Unit Testing, Integration Testing As needed
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.

PROJECT MANAGEMENT - CE00348-3
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


PROJECT MANAGEMENT - CE00348-3
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.

PROJECT MANAGEMENT - CE00348-3
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.
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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)


PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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 kitten’s 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
P
r
o
b
a
b
i
l
i
t
y
Impact
Risk
Puppies
Kittens
Tigers
Alligators
PROJECT MANAGEMENT - CE00348-3
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
PROJECT MANAGEMENT - CE00348-3
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.

PROJECT MANAGEMENT - CE00348-3
50

COMMUNICATION MANAGEMENT PLAN
PROJECT TEAM DIRECTORY
Role Name Email Phone
Project Sponsor/Client Jagath Perera jagathperera@gmail.com 0112347564
0773487634
Project Manager Charith
Sooriyaarachchi
charithsoori@apiitit.com 0779765323
Business Analyst Maheeka Jayasuriya maheekaj@apiitit.com 0714574284
Software Team Lead Thilok Gunawardena thilok@apiitit.com 0776536997
Head of Operations
Management
Heshan Anthony anthony@apiitit.com 0772983486
Head of Functional
Management
Sukitha Nadeeshan sukitha@apiitit.com 0775998775
Head of Portfolio
Review Board
Isuru Gunasekara isuru@apiitit.com 0774579336

PROJECT MANAGEMENT - CE00348-3
51

COMMUNICATIONS MATRIX
Communi
cation
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
Manage
r
Meeting
Minutes
Project
Team
Meetings
Review status of
the project
Face to Face Once a
fortnight
(Friday)
Project Team Project
Manage
r
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
(5
th
of
every
month)
Portfolio Review
Board
Project
Manage
r

Project
Status
reports
Report the status of
the project
(Activities,
Progress)
Email Monthly
(10
th
of
every
month)
Project Sponsor,
Project Team,
Head of
Portfolio Review
Board
Project
Manage
r
Project
Status Report
Project
Team
Meeting
reports
Submit Project
Team Meeting
minutes
Email Once a
fortnight
(Friday)
Head of
Portfolio Review
Board
Project
Manage
r
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

PROJECT MANAGEMENT - CE00348-3
52

EARNED VALUE EVALUATION
PROJECT MANAGEMENT - CE00348-3
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): 10
th
April 2010
Reporting Period: 10
th
March 2011 – 9
th
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.
PROJECT MANAGEMENT - CE00348-3
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


PROJECT MANAGEMENT - CE00348-3
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
2
8
-
D
e
c
1
7
-
J
a
n
6
-
F
e
b
2
6
-
F
e
b
1
8
-
M
a
r
7
-
A
p
r
2
7
-
A
p
r
1
7
-
M
a
y
6
-
J
u
n
2
6
-
J
u
n
1
6
-
J
u
l
5
-
A
u
g
2
5
-
A
u
g
1
4
-
S
e
p
4
-
O
c
t
Earned Value Analysis
Cumilative Planned
Value(PV)
Cumilative Actual Cost (AC)
PROJECT MANAGEMENT - CE00348-3
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
- 19/04/2011 Not yet Started
Develop UI 28/03/2011-
11/04/2011
04/04/2011 15/04/2011 Not yet
completed
Develop Middle-
Tier
13/04/2011-
31/08/2011
- 19/04/2011 Not yet Started
Develop
Database
31/03/2011-
14/04/2011
05/04/2011 18/04/2011 Not yet
completed

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
PROJECT MANAGEMENT - CE00348-3
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 (15
th
April to 15
th
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 request has been sent to Portfolio Review Board and Functional
Management to hire another two QA Engineers for one month (15
th
April to 15
th
May) from
another project team. This will help to get the project back to Baseline Schedule.

6.0 Project Monthly Status Report/Signatures
Project Name: On-line Customer Service System(CSS) for Sarasi Musical Centre
Project Manager: Charith Sooriyaarachchi
I have reviewed the information contained in this project Monthly Status Report and agree:
Name Title Signature Date







PROJECT MANAGEMENT - CE00348-3
58

INDIVIDUAL REFLECTION

CRITICAL EVALUATION

RISK MANAGEMENT
According to PMI (2004, p.237) the process of Risk Management is consists with six major
stags. Those are Risk Management Planning, Risk Identification, Qualitative Risk Analysis,
Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control.
Risk Management Planning stage is the approach to risk management activities of the project.
According to PMI (2004, p.243), Risk Breakdown Structure (RBS) is a good approach to the
Risk Management since this can be used as a previously prepared categorization to the risks to be
identified.
The second stage of Risk Management is Risk Identification. There is large number of risk
identification techniques in the Information Technology industry. According to a recent article
published by The Hampton Group (2011), Risk Identification process can be carried out by
considering the size of the project. Since the project is identified as a medium size project, the
risk identification process has broken up with separate group working through the identification
process.
The techniques of Documentation Reviews, Brainstorming and Risk Assessment Meeting have
been used in the identification of the risks (PMI, 2004, p.248). Three separate people from
project team carried out these risk identification processes. Brainstorming was carried out by the
Team Lead of the project team, Documentation Reviews has done by the Business Analyst and
the Risk Assessment Meeting was led by the Project Manager.
According to the PMI (2004), a Checklist Analysis can be developed to identify risks in the
project. But the PMI (2004) itself mentions that checklist can be quick and simple, so it is
impossible to build an exhaustive risk analysis. On the other hand Turbit (2005, p.1) implies that
the best approach to identify risk is to use a combination of brainstorming and reviewing of
standard risk lists. A recent article from Mind Tools (2011) illustrates that having a complete list
of risks together with the people involving in those risks will be a good starting point to the next
stage (Qualitative Risk Analysis) of Risk Management.
PROJECT MANAGEMENT - CE00348-3
59

The third and fourth stages of Risk Management are Qualitative and Quantitative Risk Analysis.
Although PMI (2004, p.237) mentions Qualitative Risk Analysis and Quantitative Risk Analysis
as two stages in Risk Management, Mind Tools (2011) suggests to consider this as one stage.
Mind Tools (2011) provides a useful framework called “Risk Impact Probability Chart” (refer
Quantitative and Qualitative Risk Analysis) which helps to decide which risks need more
attention. The Risk Impact Probability Chart has been taken to account in prioritizing the risks
associated with the project.
Both PMI (2004) and Mind Tools (2011) states that the risks should be prioritized using
Probability and Impact Matrix and this is where Mind Tools (2011) suggest to use their
framework of “Risk Impact Probability Chart”. On the other hand Tusler (1996) provides another
diagram which illustrates how to categorize risks. According to his article, the risks are divided
in to four main categories called “Tigers”, “Puppies”, “Alligators” and “Kittens”. Since this
diagram is good as the Risk Impact Probability Chart, it has also taken to account in prioritizing
risks.
As an end to the Quantitative Risk Analysis, Mind Tools (2011) states risks can be further
estimated by multiplying its impact into the probability of occurrence. This gives a value for
each risk and this is the method used in this project.
The next stage of Risk Management is Risk Response Planning. After prioritizing and ranking
the risks in the project, a risk response plan has to be developed. According to PMI (2004,
p.261), there are eight risk response strategies. These strategies can be divided in to four groups
as: Strategies for positive risks, Strategies for negative risks, Strategies for both positive and
negative risks and Contingent Response Strategy. All the risks identified in this project are
negative risks. Thus four strategies out of eight can be used and the used strategies are Risk
Avoidance, Risk Mitigation and Risk Acceptance.
On the other hand, an article of Mind Tools (2011) states a different approach in Risk Response
Planning. According to the article risks can be managing in three of ways such as: By using
existing assets, by contingency planning and by investing in new resources.
 By using existing assets – This involves improvements to existing methods and systems
in order to plan the risk.
PROJECT MANAGEMENT - CE00348-3
60

 By contingency planning – This involves deciding to accept the risk, but develop a plan
to minimize a risk’s effect if it happens. Equals to Acceptance Strategy and Contingency
Response Strategy.
 By investing in new resources – This involves bringing new resources to plan the risk.
Equals to Mitigation, Avoidance and Transfer.
However, the approach from PMI (2004) is clearer than the approach of Mind Tools (2011) and
as mentioned above PMI risk response strategies are used in the Risk Management Plan.
The final step of Risk Management is Risk Monitoring and Control. This step is mainly based on
the Recommended Preventive Actions and Recommended Corrective Actions to the identified
risks. (PMI, 2004, p.267) The project Risk Monitoring and Control plan is provided with
required actions.

COMMUNICATIONS MANAGEMENT AND MONITOR/CONTROL
According to PMI (2004, p.221) Project Communications Management involves four main steps.
Those are Communications Planning, Information Distribution, Performance Reporting and
Manage Stakeholders. The very first step is Communications Planning. According to PMI (2004,
p.225) this step determines the information and communications needs for the stakeholders. The
output of this step is Communication Management Plan.
However, the communication management plan provided in this project consists of two main
documents. A Project Team Directory is provided in order to keep the information about project
stakeholders and a Communication Matrix is provided to keep the communication objectives of
the project. These two documents almost fulfill the Communications Management Plan required
for the project.
According to PMI (2004, p.227) a communications management plan provides the following
criteria and those criteria are compared with the communication management plan provided in
the project.
 Stakeholder Communication Requirements – Provided in Project Team Directory
 Information to be communicated – Provided in Communication Matrix
PROJECT MANAGEMENT - CE00348-3
61

 Person Responsibility for communicating the information – Provided in Communication
Matrix
 Person of group who will receive the information – Provided in Communication Matrix
 Frequency of the communication – Provided in Communication Matrix
Furthermore, a recent article published about Communications Strategy states that, a
Communication Strategy is to document how information will be disseminated to, and receive
from, all stakeholders in the activity. (Anon, 2010) According to this article, it identifies the
medium and frequency of communication between the different parties. As this article suggests, a
stakeholder analysis was carried out and a Stakeholder Register is developed in the beginning of
the project. The communication management plan is mainly based on the stakeholders identified
in the Stakeholder Register.

GROUP DYNAMICS
According to McMillan (2011), “a group can be defined as a several individuals who come
together to accomplish a particular task or goal”. Contribution of each player in the team will
cause to the failure of success in achieving the goal.
The expectation of assignment is to prepare a complete project document considering all the
aspects of Project Management. As mentioned above, since this is a group project, the final
outcome of the project will highly be dependent on contribution of each and every group
member. All three members of our group wanted to complete the assignment successfully,
therefore everyone were interested on the assignment from the beginning.
A study by Tuckman (1960 cited McMillan 2011) shows that there are five stages of group
development.
 Forming – This is the orientation period of the group. The major goals of the group have
not been established and the leadership of the group has not been determined. (Luthans,
2005 cited McMillan 2011). Therefore in this stage, members learn the rules and the trust
and openness are developed. (Tuckman 1960 cited McMillan 2011)
Mapping the Forming stage with the group which we formed for this module expresses a
little different from the above. Since we (Maheeka, Charith and me) were worked as a
PROJECT MANAGEMENT - CE00348-3
62

group before, most of the characteristics of forming stage were disappeared. The trust and
openness between three of us had been developed and a major goal for the group was also
mentioned in the assignment. Therefore, to complete the Forming stage, all we had to do
was to establish a leadership and while Charith had shown his leadership skills well in the
last time we worked in this group, Maheeka and me proposed Charith as the leader for
this assignment as well.
 Storming – This is the stage that group expresses the highest level of disagreement and
conflict. These can be happened as a result of struggling for the power and leadership.
(Tuckman 1960 cited McMillan 2011)
As a result of the long term trust and openness, the Storming stage almost did not
occurred in our group. It is true that our group often had some disagreements concerning
individual ideas, but our group never had any disagreements addressed in the Storming
stage. This could probably have happened unless we had not worked as a group before.
 Norming – This is the stage where the group members will begin to develop a feeling of
group cohesion and identity. Responsibilities are divided among the group members and
the group decides how it will evaluate progress. (Tuckman 1960 cited McMillan 2011)
In our project this stage was started after the first meeting with the client. All three
members of the group had to meet the owner of Sarasi Musical Center as a starting point
to the project. After this meeting Charith, the Project Manager, developed a Gantt chart
and responsibilities were divided among the members. A Project Charter was developed
by Maheeka and I started to evaluate my responsibilities in the project.
 Performing – This stage starts when the group has matured and attains a feeling of
cohesiveness. The group discussions were held and members of the group make decisions
together. (Tuckman 1960 cited McMillan 2011)
The Performing stage was the most important stage for our group. Since the assignment
which we have assigned is consists with six stages which have strong relationships to
with each other, a good communication should happen between the group members in
order to make it a success. Therefore, the group discussions were the key to our
assignment. Since, an output of one particular stage is an input to another stage, all the
members of the project should perform their best to generate a better output.
PROJECT MANAGEMENT - CE00348-3
63

 Adjourning – Some groups are relatively permanent (Luthans, 2005 cited McMillan
2011). Some groups disband after the accomplishment of the task. Members of the group
experience feelings of sadness as they prepare to leave. (Tuckman 1960 cited McMillan
2011)
This stage was related to our project to some extent. Our group was formed only for two
months. After the assignment submission, this stage is to be happened.

Above five stages describes how our group was developed in order to fulfill the requirements of
Project Management study module assignment.
PROJECT MANAGEMENT - CE00348-3
64

REFERENCES
AJ Design Software (2011) Variance At Completion VAC Equations Formulas Calculator.
[Online]. Available from:
http://www.ajdesigner.com/phpearnedvalue/variance_at_completion_equation.php [Accessed: 28
February 2011]

Anon (2010) OGC –Communications strategy. [Online]. Available from:
http://www.ogc.gov.uk/documentation_and_templates_communications_strategy_.asp
[Accessed: 02 March 2011]

Anon, (2007) PMA – Welcome. [Online]. Available from: http://www.pma.doit.wisc.edu/
[Accessed: 01 March 2011]

Anon, (n.d.) eplc_quality_management_template. [Online]. Available from:
http://docs.google.com/viewer?a=v&q=cache:CdA14J0EGzAJ:www.hhs.gov/ocio/eplc/EPLC%2
520Archive%2520Documents/15%2520-
%2520Quality%2520Management%2520Plan/eplc_quality_management_template.doc+Organiz
ation,+responsibilities,+and+interfaces&hl=en&gl=lk&pid=bl&srcid=ADGEESgQ7YEmltIFcF
GCKTUBpVxGGgvlJyGd7ZwDiZ2ydgWWB0ueNnb_GCPg2gb0LLsdcAfvQCNEey-
2LLh0tAfwF64L8NEtuy3ymqFT2J_6D3Fg-
dQkAxrtSVrQ7N3A3D7n0wglA3YS&sig=AHIEtbSgrwVVvXmPxxy5Jlo8GhoYGnTzgA&pli=
1 [Accessed: 28

February 2011]

Applied Testing and Technology. (2009). Types of Software Testing. [Online]. Available from:
http://www.aptest.com/testtypes.html [Accessed: 23 February 2011]

CVR/IT (2002) Project Management Training, Project Support, PMO Support, Project
Management Consulting Services, Project Staffing. [Online]. Available from: http://www.cvr-
it.com/ [Accessed: 01 March 2011]

McMillan, A. (2011) Group Dynamics - organization, levels, examples, type, company, Group
development, Group types, Group structure, Group roles. [Online]. Available from:
http://www.referenceforbusiness.com/management/Gr-Int/Group-Dynamics.html [Accessed: 01
March 2011]

Mind Tools (2011) Risk Analysis Techniques - Problem-Solving Training from MindTools.com.
[Online]. Available from: http://www.mindtools.com/pages/article/newTMC_07.htm [Accessed:
28 February 2011]

Mind Tools (2011) Risk Impact/Probability Chart - Project Management Tools from
MindTools.com [Online]. Available from:
http://www.mindtools.com/pages/article/newPPM_78.htm [Accessed: 27 February 2011]
PMI (2004). A Guide to the Project Management Body of Knowledge. Third Edition.
Pennsylvania: Project Management Institute, Inc.
PMI (2008). A Guide to the Project Management Body of Knowledge. Fourth Edition.
Pennsylvania: Project Management Institute, Inc.
PROJECT MANAGEMENT - CE00348-3
65


Rehan, S. (2011a). Quality Management, CE00348-3. [Lecture notes] Quality Management.
Project Management. Asia Pacific Institute of Information Technology, Computing, Sri Lanka,
14
th
February.

Rehan, S. (2011b). Risk Management, CE00348-3. [Lecture notes] Risk Management. Project
Management. Asia Pacific Institute of Information Technology, Computing, Sri Lanka, 19
th

February.

Rehan, S. (2011d). Earned Value Analysis, CE00348-3. [Lecture notes] Earned Value Analysis.
Project Management. Asia Pacific Institute of Information Technology, Computing, Sri Lanka,
28
th
February.

SoftwareArchitectures.com (2010) Quality Attributes. [Online]. Available from:
http://www.softwarearchitectures.com/go/Discipline/DesigningArchitecture/QualityAttributes/ta
bid/64/Default.aspx [Accessed: 28

February 2011]

The Hampton Group (2011) Project Risk Management. [Online]. Available from:
http://www.4pm.com/articles/risk.html [Accessed: 25 February 2011]

Tulser, R. (1996) The Elements of Project Risk Management. [Online]. Available from:
http://www.netcomuk.co.uk/~rtusler/project/elements.html [Accessed: 21

February 2011]

Turbit, N. (2005) Project Risk Management Overview. [Online]. Available from:
http://www.projectperfect.com.au/info_risk_mgmt.php [Accessed: 27 February 2011]
PROJECT MANAGEMENT - CE00348-3
66

APPENDIX - POWER INTEREST GRID
Power/interest grid – group stakeholders based on their authority (power) and their interest.
(PMI, 2008) Power interest grid is shown below.















Keep Satisfied Manage Closely
Monitor
(Minimum Effort)
Keep Informed
High
Low
High Low
Power
Interest
PROJECT MANAGEMENT - CE00348-3
67

APPENDIX - STAKEHOLDER REGISTER
The following table is created after the completion of Identify Stakeholders process and all the
stakeholders in the project are identified and listed down.
The Stakeholder Category column is filled with the use of Power/Interest Grid which was
described above.
Name Department/
Company
Role Expectations Influenc
e/
Interest/I
nvolvem
ent
Impact/
Importanc
e/ Power
Stakehold
er
Category
Saman
Nawarathne
APIIT IT
Solutions
Chief
Executive
Officer
Monthly status
reports of project
High High Key
Players
(Manage
Closely)
Charith
Sooriyaarachc
hi
APIIT IT
Solutions
Project
Manager
On-time delivery High High Key
Players
(Manage
Closely)
Jagath Perera Sarasi
Musical
Center
Owner
(Sponsor of the
project)
On-time delivery,
High quality product,
Ease of
implementation
High High Important
Players
(Keep
Satisfied)
Parents Ease of use, Trusted
and accurate online
shopping
Low Low Other
Players
(Monitor)
Students who
learn music
Ease of use, Trusted
and accurate online
shopping
Low Low Other
Players
(Monitor)
Musicians/Arti
sts
Ease of use, Trusted
and accurate online
High High Key
Players
PROJECT MANAGEMENT - CE00348-3
68

shopping (Manage
Closely)
Government No violation of rules
and regulations
Low High Important
Players
(Keep
Satisfied)
Bank No violation of rules
and regulations
Low High Important
Players
(Keep
Satisfied)
APIIT IT
Solutions
Operations
Management
Monthly status
reports of project
High High Key
Players
(Manage
Closely)
APIIT IT
Solutions
Development
Team
Accurate and enough
information on
current system,
Guidance on
developing system
High High Key
Players
(Manage
Closely)
Business
Partners
Train system users High Low Affected
Players
(Keep
Informed)
Sarasi
Musical
Center
Employees Ease of use, Reduced
work load, No risk
on current
employment
High High Key
Players
(Manage
Closely)
APIIT IT
Solutions
Functional
Management
Monthly status
reports of project
High High Key
Players
(Manage
Closely)
PROJECT MANAGEMENT - CE00348-3
69

APIIT IT
Solutions
Portfolio
Review Board
Monthly status
reports of project
High High Key
Players
(Manage
Closely)
Competitors Low Low Other
Players
(Monitor)









PROJECT MANAGEMENT - CE00348-3
70

APPENDIX – REQUIREMENTS DOCUMENT
NON-FUNCTIONAL REQUIREMENTS
ID Description Priority
1 Deliver product within 180 days H
2 Should not exceed the budget of Rs.800,000 H
3 The system should be up and running 24 hours a day and 7 days a week M
4 All functionalities needs to have a minimum response time of 5 seconds M
5 System will utilize a maximum of 10GB bandwidth each month M
6 System should display a minimum of 95% accuracy H
7 An external web server needs to be implemented M
8 Use JSP and Myself for development M
9 Should be able to update inventory data from the current database of
Inventory and POS system
H
10 Transactions must be secured using SSL protocol as the minimum H
11 System should be secure from security violation and vulnerabilities H
12 A new database must be implemented to cover all the functionalities of this
system
H
13 A user friendly system must be developed, considering the ISO standard
for HCI
L
14 Solution should not interrupt or disrupt any of the current operations H
15 Solution must be fully tested before deployment H
16 The source codes must be provided to client H
17 Source codes must follow Secure Coding Guidelines for the Java
Programming Language, Version 3.0
M
18 A weekly status report must be provided to client M
19 Documentations and plans must follow PMI standards M
20 User manuals and training for the employees must be provided prior and
during implementation
M
21 System maintenance services will be free of charge for 1 year and
thereafter a 15% of total project cost will be charged annually
M
PROJECT MANAGEMENT - CE00348-3
71

FUNCTIONAL REQUIREMENTS
ID Description Priority
User : Customers
22 Login to the system H
23 Register in the system H
24 Search instruments by category M
25 Quality, brand, price, guarantee, features of instruments must be available M
26 The details must be displayed in a comparative manner M
27 Enable payments through Visa and PayPal both H
28 Request for a repair H
29 Display cost for repair H
30 Reserve instruments with an advance payment of 5-15% of original value H
31 Purchase instruments H
32 Request items that are not currently available in-store, and inform when such
a requested item is available
M
User : Administrator
33 Login to the system H
34 Add new users and update current users H
User : Cashier
35 Login to the system H
36 Retrieve purchase details to deliver the instrument H
37 Retrieve reservations details to keep the instrument reserved H
38 Calculate cost for repair and update in system H
39 Update status of instruments that were requested by customers M
40 Retrieve transactions data for accounting and billing purposes H

H = High; M = Moderate; L = Low



PROJECT MANAGEMENT - CE00348-3
72

APPENDIX – DATA GATHERING
INTERVIEW WITH MARKETING MANAGER

1. What are the services provided by your company?
a. Sell instruments
b. Take reservations for instruments
c. Undertake repairs
d. Import instruments upon customer request

2. What is the expectation of having a customer support service system?
a. increase profit by 20%
b. more interactions of customers with the company
c. more sales
d. more customer satisfaction

3. What are the functionalities you expect of this system?
a. purchase instrument
b. reserve instruments
c. repairs requesting and tracking
d. request for instruments

4. What are the categories, brands of instruments available for sale?
a. Wind instruments
b. Percussion instruments
c. Brass instruments
d. String instruments
e. Electrical instruments
f. All of these are again categorized as eastern and western

5. Can you explain the process of purchasing an instrument?
a. Visit the shop
PROJECT MANAGEMENT - CE00348-3
73

b. select instruments - our staff helps in this process
c. make payment and take the instruments
d. or for reservation
e. visit the shop
f. select instrument
g. pay an advance of 5-15% of the original value and it is reserved
h. collect the instrument within 4 weeks , if not collected the advance is refunded

6. What are the services provided?
a. Support for selecting items
b. Purchasing items
c. Repairing - we normally provide a guarantee of 1-2 years during which repairing
is free of charge, there after the charge depends on the type of repair. repairs are
categorized as the categories of music itself
d. Reserve items by paying an advance
e. Make a request for an item -if the instrument can be manufactured in-house or
imported we will inform the customer and he can pay an advance for it to keep it
reserved

7. How do you handle repairs? Can you explain the procedure?
a. The customer needs to bring the instrument to the shop or factory complex
b. make a call to the company and someone will be sent to collect the
instrument(only possible within a certain area close to the factory or showroom)
c. We give a due date and an estimated cost to the customer depending on the type
of repair
d. The customer can make a call to check the status or we inform the customer as to
the repair is complete
e. If customer requests we deliver to house or he can visit the showroom/factory to
collect it.
PROJECT MANAGEMENT - CE00348-3
74

f. The cost for a repair is calculated based on the type of fault, tools needed and the
parts. Also a service charge will be added. This only applies after guarantee period
has expired, or if the instrument was not bought from our company.

8. Up to what extent of purchase and repairing service do you expect to be included in this
system?
a. Register as customers in the company
b. Should allow customers to purchase items and pay
c. make requests for new items
d. reserve instruments with an advance paid
e. make repair requests
f. keep track of repairs

9. What is your expected implementation when an item is purchased by a customer? Do you
deliver it through an employee of company or any other delivery service?
a. Yes we deliver it to customer through employee

10. Who will be the employees using this system? How?
a. Update status of the repairs
b. Get reservation details to mark as reserved at the showroom
c. The requested instruments have to be checked whether possible to be made
available and update that data in customer profile
d. Perform billing operations, update prices of repair transactions, and purchases, etc
e. Update the instrument details

11. What is the average number of transactions per annum? Is purchasing or repairing
occurring most?
a. around 150 average transactions a day including both purchases and repairs for
showroom and factory both
b. purchasing occurs more than repairs

PROJECT MANAGEMENT - CE00348-3
75

12. What is your expectation of the project in terms of budget, schedule and quality?
Budget and duration should not exceed Rs. 8,000,000 9 months

INTERVIEW WITH THE IT MANAGER

1. What is the current IT infrastructure in this company? What are the systems running?
a. We have computerized system for;
i. Accounts handling
ii. Inventory control
iii. POS system
b. All these systems use an MsSql database which we installed long time back.

2. What are your requirements for the system?
a. We need full administrator authority with separate levels for users within the
organization. That is, management staff, the administrators and other staff, normal
users who updates the transactions in the system.

3. Do you want this system to be merged and compatible with the current system or as a
separate stand alone application?
a. No, the current system is poorly designed. Therefore, we want this as a separate
application.

4. How do you want to deploy the web-server? Do you want it at the company premises?
a. We only need full authority of data in the system, and we do not need it is inside
company. We don't have computer experts inside company to do, the sever and
database maintaining. Therefore we need this to be separated from the company.

5. What is the level of computer usage among employees?
a. They are not expert users but since they use the POS and inventory control
system, they do have a fair understanding of how systems work and they are fairly
manageable.
PROJECT MANAGEMENT - CE00348-3
76

b. We have a young staff and they are familiar with internet, therefore they are a bit
more than novice users
c. Anyhow, the system should be user friendly so that any person who might be new
to this can get familiar with the system fast

6. What are your opinions about the technology needed to be used for the development?
a. The system should run on an external web server. We do like system developed
using open source technologies like Java and MySql since we do not need to
bear any unwanted cost. Since system need not have any relationship with current
IT infrastructure this can be done easily.

PROJECT MANAGEMENT - CE00348-3
77

GENERAL PUBLIC – SURVEY


PROJECT MANAGEMENT - CE00348-3
78

APPENDIX - PROJECT TEAM

Role
Number of
Personnel

Salary ( monthly)
Project manager 1 200,000 LKR
Software Architect - Lead 1 160,000 LKR
Software Architect 1 150,000 LKR
DB Engineer Lead 1 160,000 LKR
DB Engineer 1 150,000 LKR
Quality Assurance Engineer - Lead 1 50,000 LKR
Quality Assurance Engineer 2 40,000 LKR
Development Team Lead 1 120,000 LKR
Developer SME 3 120,000 LKR
Developer 5 80,000 LKR
UI Engineer Lead 1 50,000 LKR
UI Engineer 1 40,000 LKR
Software Trainer - Lead 1 40,000 LKR
Software Trainer 1 40,000 LKR


PROJECT MANAGEMENT - CE00348-3
79

APPENDIX – DATA FLOW DIAGRAM
Request confirmation
Update
Item details
Purchase details
P
a
y
m
e
n
t

d
e
t
a
i
l
s
P
u
r
c
h
a
s
e

d
e
t
a
i
l
s
R
e
q
u
e
s
t

a
c
c
e
p
t
e
d

n
o
t
e
Inform updates
Request item details
1.0
Register
Customer
5.0
Request
repair
4.0
Reserve
item
3.0
Purchase
item
2.0
Request
new item
8.0
Retrieve
Transactions
7.0
Add/Edit
Users
6.0
Add/Edit
items
Customer
Reservations
Repairs
Item Requests
Users
Items
Cashier
Admin
Customer
Sales
Customer details
Registration details
Customer details
Provide
transaction
information
G
e
t

d
e
t
a
i
l
G
e
t

d
e
t
a
i
l
Get details
Get detail
Request details
User details
Confirmation
User details
Transaction details
9.0 Update
transactions
G
e
t

d
e
t
a
i
l
G
e
t

d
e
t
a
i
l
Get detail
Repair requests
R
e
p
a
i
r

d
e
t
a
i
l
s
P
a
y
m
e
n
t

d
e
t
a
i
l
s
P
a
y
m
e
n
t

c
o
n
f
i
r
m
a
t
i
o
n

Confirmation
R
e
s
e
r
v
a
t
i
o
n

d
e
t
a
i
l
s
Update transactions
Update
Update
Item details
Item details
Confirmation
R
e
s
e
r
v
a
t
i
o
n

d
e
t
a
i
l
s


PROJECT MANAGEMENT - CE00348-3
80

APPENDIX – COCOMO ESTIMATE REFERENCES

EARLY DESIGN AND POST-ARCHITECTURE EFFORT MULTIPLIERS

(Horowitz E., et al, 1998)
COCOMO COST DRIVERS AND THEIRINFLUENCE ON THE NOMINAL EFFORT

(Leung H., Fan Z., n.d.)

PROJECT MANAGEMENT - CE00348-3
81

APPENDIX - CHANGE REQUEST FORM
Project Name: On-line Customer Service System (CSS) for Sarasi Musical Centre
CHANGE IDENTIFICATION
1. Title:
2. Request date:
3. Type of request:
User request Technical request Standard request other
4. Reason for change:
CHANGE EVALUATION
Effort Estimates (hours) to change Project Timeline impact
Project Plans Task timeline(s) Yes No
Requirements Milestone timeline(s) Yes No
Decision Current released timeline Yes No
Test Future release timeline Yes No
Implementation Other timeline(s) Yes No
Risk evaluation
Recommendation

DECISION/APPROVAL
1. Decision date:
2. Decision by:
Project Manager request Change Management committee
3. Decision :
Deny/Cancel Postpone until _____ Approve
4. Comments :
CHANGE TRACKING
PROJECT MANAGEMENT - CE00348-3
82

Project plan N/A By Date : Comments
Requirements N/A By Date : Comments
Design N/A By Date : Comments
Test cases N/A By Date : Comments
User training N/A By Date : Comments
Online help N/A By Date : Comments
User procedure N/A By Date : Comments
Construction N/A By Date : Comments
Change document N/A By Date : Comments


(Adopted from: DHS-Oregon department of human services, n.d.)

PROJECT MANAGEMENT - CE00348-3
83





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. Stakeholder’s 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
PROJECT MANAGEMENT - CE00348-3
84

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
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
PROJECT MANAGEMENT - CE00348-3
85

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
1.3.3.3.1. Back up databases
1.3.3.3.2. Application Deploying
PROJECT MANAGEMENT - CE00348-3
86

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
PROJECT MANAGEMENT - CE00348-3
87

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

PROJECT MANAGEMENT - CE00348-3
88

Sign up to vote on this title
UsefulNot useful