Sample Capstone Project

Collar Finder Management Consultancy Inc.
Curriculum Vitae Management System
A Project Development Plan

Presented to the Faculty of the Graduate School
Asia Pacific College, Makati City
In Partial Fulfillment of the

Requirements of the Degree
Master in Information Technology
JAN LUDVIK B. RANESES

April 2016
ACKNOWLEDGEMENTS
I would like to extend my biggest thanks to everyone who has become a part of this
project. This is a son of my labors and a fruit of our best moments together. This is
possible through the guidance of the Lord Almighty.
Thank you very much.
-JAN LUDVIK BALBOA RANESES, MIT
2
Table of Contents
ACKNOWLEDGEMENTS ..........................................................................................................................................2
1. Project Overview .................................................................................................................................................6
1.1 Project Name ....................................................................................................................................................6
1.2 Project Description ........................................................................................................................................6
1.2.1 Business Objectives ..............................................................................................................................7
1.2.2 Business Case ..........................................................................................................................................7
1.2.3 Project Objectives ..................................................................................................................................8
1.2.4 Project Success Criteria ......................................................................................................................8
1.3 Project Completion Date .............................................................................................................................9
1.4 Project Budget .................................................................................................................................................9
1.5 Project Sponsors ..........................................................................................................................................10
1.6 Project Key Deliverables ...........................................................................................................................10
2.0 Project Glossary ................................................................................................................................................11
2.1 Key Terms .......................................................................................................................................................11
2.2 Acronyms ........................................................................................................................................................11
3.0 Project Scope ......................................................................................................................................................12
3.1 Product Characteristics / Requirements ...........................................................................................12
3.2 Product Acceptance Criteria ...................................................................................................................13
3. Product Deliverables ..................................................................................................................................14
3.1. Project Management – Related Deliverables .......................................................................14
3.2. Product- Related Deliverables ...................................................................................................15
4. Project Exclusions ........................................................................................................................................16
5. Project Assumptions and Constraints .................................................................................................16
4. Project Organization .........................................................................................................................................17
4.1.Project Organization Chart .....................................................................................................................17
4.2. Project Team Staff, Roles and Responsibilities .............................................................................18
4.3.Deliverables Responsibility Matrix ......................................................................................................20
5.0 Project Management Approach ..................................................................................................................22
6.0 Project Technical Approach .........................................................................................................................23
6.1 Product Development Methodology ...................................................................................................23
6.2 Development Tools .....................................................................................................................................24
6.3 Technical Architecture ..............................................................................................................................24
7.0 Baseline Plans ....................................................................................................................................................26
7.1 Scope Baseline ..............................................................................................................................................26
7.2 Schedule Baseline ........................................................................................................................................35
1
7.2.1 Milestone List .......................................................................................................................................35
7.3 Cost Baseline .................................................................................................................................................36
7.4 Quality baseline ............................................................................................................................................37
8.0 Management Plans ..........................................................................................................................................40
8.1 Scope Management Plan ..........................................................................................................................40
8.1.1 Scope Management Approach .......................................................................................................40
8.1.2 Roles and Responsibilities ..............................................................................................................41
8.1.3 Scope De[inition ..................................................................................................................................42
8.1.4 Scope Validation ..................................................................................................................................42
8.1.5 Scope Control ........................................................................................................................................43
8.1.6 Scope Management Tools ................................................................................................................45
8.2 Change Management Plan .......................................................................................................................45
8.2.1 Change Management Approach ....................................................................................................45
8.2.2 De[initions of Change ........................................................................................................................46
8.2.3 Change Control Board .......................................................................................................................46
8.2.5 Change Control Process ...................................................................................................................47
8.2.6 Change Management Tools .............................................................................................................47
8.3 Requirements Management Plan .........................................................................................................48
8.3.1 Requirements Management Approach ......................................................................................48
8.3.3 Requirements Prioritization Process .........................................................................................50
8.3.4 Con[iguration Management ............................................................................................................50
8.3.5 Requirement Traceability Matrix .................................................................................................52
8.3.6 Requirements Management Tools ...............................................................................................52
8.4 Con[iguration Management Plan ..........................................................................................................53
8.4.2 Con[iguration Control .......................................................................................................................54
8.4.3 Con[iguration Management Database .......................................................................................55
8.4.4 Con[iguration Status Accounting .................................................................................................56
8.4.5 Con[iguration Audits .........................................................................................................................58
8.4.6 Con[iguration Management Tools ................................................................................................59
8.5 Schedule Management Plan ....................................................................................................................59
8.5.1 Schedule Management Approach ................................................................................................59
8.5.3 Schedule Control .................................................................................................................................61
2
8.5.4 Schedule Changes and Thresholds ..............................................................................................62
8.5.5 Schedule Change Control Process ................................................................................................63
8.6 Cost Management Plan ..............................................................................................................................64
8.6.1 Cost Management Approach ..........................................................................................................64
8.6.3 Project Cost Measurements ............................................................................................................65
8.6.4 Project Cost Reporting Format .....................................................................................................66
8.6.5 Cost Variance Process .......................................................................................................................67
8.6.6 Cost Change Control Process .........................................................................................................67
8.6.7 Cost Management Tools ...................................................................................................................67
8.7 Quality Management Plans .....................................................................................................................68
8.7.1 Quality Management Approach ....................................................................................................68
8.7.3 Quality Requirements/ Standards ...............................................................................................70
8.7.4 Quality Assurance ...............................................................................................................................71
8.7.5 Quality Control .....................................................................................................................................73
8.7.6 Quality Control Measurements .....................................................................................................75
8.7.7 Quality Management Tools .............................................................................................................76
8.8 Risk Management Plan ..............................................................................................................................77
8.8.1 Risk Management Approach ..........................................................................................................77
8.8.3 Risk Identi[ication ..............................................................................................................................78
8.8.4 Risk Quali[ication and Prioritization ..........................................................................................78
8.8.5 Risk Monitoring ...................................................................................................................................80
8.8.6 Risk Mitigation and Avoidance ......................................................................................................81
8.8.7 Risk Register Management .............................................................................................................82
8.8.8 Risk Management Tools ...................................................................................................................83
8.9 Human Resource Management Plan ...................................................................................................83
8.9.1 Staf[ing Management ........................................................................................................................83
8.9.2 Human Resource Management Tool ...........................................................................................84
8.10 Communications Management Plan .................................................................................................84
8.10.1 Communication Management Approach ...............................................................................84
8.10.2 Roles and Responsibilities ...........................................................................................................85
8.10.3 Communication Management Constraints ............................................................................86
8.10.4 Stakeholder Communication Requirements ........................................................................87
8.10.5 Communication Methods and Technologies ........................................................................88
3
8.10.6 Communication Matrix ..................................................................................................................90
8.10.7 Communication process ................................................................................................................92
8.10.8 Communication Standards ...........................................................................................................92
8.10.9 Communication Escalation Process .........................................................................................93
8.11 Stakeholder Management Plan ...........................................................................................................95
8.11.1 Stakeholder Registry ......................................................................................................................95
8.11.2 Stakeholder Analysis Matrix ........................................................................................................96
8.11.3 Stakeholder Management Strategy ..........................................................................................98
8.12 Procurement Management Plan ......................................................................................................100
8.12.1 Procurement Management Approach ..................................................................................100
8.12.2 Procurement De[inition ..............................................................................................................100
9.0 Appendices .......................................................................................................................................................102
9.1 APPENDIX A – Project Cost- Bene[it Analysis ..............................................................................102
9.2 APPENDIX B – Systems Requirements Speci[ication ................................................................105
9.2.1 INTRODUCTION ................................................................................................................................105
9.2.2 PROJECT DESCRIPTION ................................................................................................................105
9.2.3 BUSINESS CONTEXT .......................................................................................................................109
9.2.4 SYSTEM OVERVIEW ........................................................................................................................110
9.2.5 USE CASE MODEL ............................................................................................................................115
9.2.6 Speci[ic Requirements ...................................................................................................................125
APPENDIX .......................................................................................................................................................133
9.3 APPENDIX C – Project Methodology ................................................................................................135
9.4 APPENDIX D - Product Development Methodology ..................................................................139
9.5 APPENDIX E – Development Tools Speci[ication ........................................................................143
9.6 APPENDIX F – Infrastructure Speci[ications .................................................................................145
9.7 APPENDIX G – Detailed Schedule ......................................................................................................146
9.8 APPENDIX H – Detailed Funding Requirements and Cost Estimates .................................152
9.9 APPENDIX I – Risk Register ..................................................................................................................156
4
5
1. Project Overview
1.1 Project Name
Collar Finder Management Consultancy Inc. Curriculum Vitae Management System
(CFMCICVMS)
1.2 Project Description
The CFMCICVMS will be developed for Collar Finder Management Consultancy Inc.
Collar Finder Management Consultancy Inc., an executive search firm. It has been doing
business for a year. Their corporate office is situated at 28th Floor Cityland Pasong Tamo
Tower u2807 2210 Chino Roces Avenue Makati City. Currently they have 5 Project
Associates working on different clients’ requirements with the CEO/ Owner Mr. Hernard
Honcolada.
CFMCI is an organization which aims for convenience, efficiency and consistency
advantages that the CFMCI CV Management System can give. One similarity among
Executive Search firms is a long response time regarding client requirements. This is a
problem being faced by all and having this kind of application can help lessen the
response time and create a good relationship with the clients. According to the CEO, 55%
of the total response time is being spent in reviewing collected CVs.
The centralization of processes is taking its rise in a lot of organizations nowadays. Aside
from the fact that is the current trend, organizations are taking this opportunity to increase
the quality of services they offer and increase profit. CFMCI has been established for
6
over a year and they have been finding ways of how they can improve the business
process to cater faster service and to have higher income. This product will be used to
contribute to the fulfilment of its vision, mission and goals. This solution will aid the
whole organization in implementing executive search activities wherein CV review
which is the backbone of the whole process will be very convenient and fast as the
software will narrow down possible candidates for different client requirements. This will
also help the organization in its goals in catering faster service to its clients.
1.2.1 Business Objectives
1. Increase annual revenue by 20%
2. Improve response time to client requirements by 10% every year.
1.2.2 Business Case
The proponent wished to develop a software to manage the CVs collected by the Collar
Finder Management Consultancy Inc. during executive search activities. This solution
will intend to develop features to create a centralized storage for the CVs collected over
time, an interface for the CEO to monitor CV uploading activities, an interface for an
easier manner of searching through the CVs using word/phrase match and frequency
indicators and an interface for viewing CVs categorized thru search tags.
This solution will aid the whole organization in implementing executive search activities
wherein CV review which is the backbone of the whole process will be very convenient
and fast as the software will narrow down possible candidates for different client
7
requirements. This will also help the organization in its goals in catering faster service to
its clients. It will also save up human resource efforts as well as man power costs.
With just a simple project, Collar Finder will be able to return its investment in just a
year. In 5 years, it will be able to add an additional of Php 10,360,119.04 revenue due to
faster service rendered because of the advantages brought by the proposed solution.
Details of Cost – Benefit Analysis in Appendix A.
1.2.3 Project Objectives
1. Improve response time by 40% to client requirements by reducing
searching time over collected CVs to increase revenue.
2. Provide a single centralized storage for the CVs collected over time
3. Allow the CEO to monitor CV uploading activities (to the centralized
storage) by project associate, duration or both in real-time.
1.2.4 Project Success Criteria
Key Area Criteria

Schedule 1. The project must be delivered by February 13, 2017.
Budget 2. The project must not exceed the budget of four hundred
sixty thousand pesos (Php 460,000)
Product 3. The project must be formally accepted by the project
sponsor through the product acceptance criteria defined in
3.2
8
Quality 4. 4. All high-priority functionality defined in the
requirements specification is delivered in the first
release.
5.
6. 5. The number of residual defects does not exceed to 3

per module.
Satisfaction 6. Train 100% of staff within the 4 day training period
7. Improve customer satisfaction by 65% over the first three
months
1.3 Project Completion Date
February 29, 2017
1.4 Project Budget
The table below is the summarized Project Budget.
Table 1: Summary of the Project Budget

Item Description Estimated Percentage
Cost
1 Software Cost Php 8,100.00 2.03%
2 Hardware/Network Cost Php 2140.00 0.54%
3 Operational Cost Php 20, 086.04 5.06%
4 Labour Cost Php 85.97%
342,286.53
5 Training Php 3,200.00 0.81%
6 Effort Cost Php 20,800.00 5.24%
Sub Total Php 100%
396,612.57
*** Contingency Php 51,559.63 13%
Total Cost Php 448,172.20

***See Appendix H for details.
9
1.5 Project Sponsors
The CEO of the Collar Finder Management Consultancy Inc.
1.6 Project Key Deliverables

The table below show the Project Deliverables per Project Phase with its Target Date
Table 2: Project Key Deliverable per Project Phase

Project Phase Project Deliverables Target Date
Mm/dd/year
Project management Project Approval 01-27-2017
Procurement Plan
Audit Findings and Reviews
Analysis Phase Requirements Management Plan 08-08-2016
Conceptual System Designs
High Level Project Strategies
Acceptance Criteria
Information Retention Criteria
Test Cases
Design Phase Solution for the Module Designs 08-30-2016
Module Design Document
Coding Phase Administrator Module 11-28-2016
Project Associate Module
CEO Module
Module Coding Document
Unit Test Results Document
Misc Elements of the Solution
Testing Phase Software 01-12-2017
System Test Report
Defect and Classification Tracking and
Methods
Updated Test Files and Records
Approved UAT
Deployment User Training Materials 01-26-2017
Training
User Support Documentation
GoLive
10
2.0 Project Glossary
2.1 Key Terms
1. Curriculum Vitae - a brief account of a person's education, qualifications, and
previous experience, typically sent with a job application.
2. Project Associate – the personnel in-charge of finding possible human
resource match/es to client requirements
3. CEO – the owner and the top executive of CFMCI
4. Administrator – will act as the manager for accounts being used with the
CFMCICVMS, he has the capability to activate or deactivate a certain user
account
2.2 Acronyms
1. CFMCI - Collar Finder Management Consultancy Inc.
2. CFMCICVMS - Collar Finder Management Consultancy Inc. Curriculum
Vitae Management System
3. CV - Curriculum Vitae
4. CI – Configuration Item/s
11
5. CM – Configuration Manager
6. CCB – Change Control Board
7. CMDB – Change Management Database
8. PMI – Project Management Institute
3.0 Project Scope
3.1 Product Characteristics / Requirements
The table below shows the product features description.
Table 3: Product Features

Feature Number Description
1 Access Management
1.1 User Registration

1.2 User Log In
1.3 User Detail Update
1.4 Administrator interface for activating and

deactivating registered users
2 a centralized storage for the CVs collected over
time
3 an interface for uploading CVs to the central storage
with meta tags(First Name, Middle Name, Last Name
Position, and extra 10 tags) with CV preview feature
4 an interface for editing the details of the uploaded

CVs to the central storage
5 an interface for the CEO to monitor CV uploading
activities
6 interface for CV Search
12
6.1 an interface for an easier manner of searching
through the CVs using candidates’ last name,
word/phrase match and search tags
6.2 An interface for previewing and downloading
searched CV/s
3.2 Product Acceptance Criteria
The table below shows the defined criteria for product acceptance.
• 95% of product-related deliverables has been delivered within schedule.
• All requirements have been formally approved through the following reviews:
a. Requirement Review
b. Design Review
c. Code Review
d. Deployment Plan Review
e. Test Plan Review
f. Test Cases Review
• The system has successfully passed series of test such as the following:
a. Unit Testing
b. Integration Testing
c. Functional Testing
d. Systems Testing
13
e. User Acceptance Testing / Quality Assurance
• The system has been successfully deployed by the project team. All of the following
success indicators must be accomplished:
a. Training materials have been developed and distributed to target users
b. Training has been conducted
c. User Support has been properly documented
d. New solution has been properly installed and fully functional.
e. Installation performance monitoring has been conducted
3. Product Deliverables
3.1. Project Management – Related Deliverables
The table below shows the Project Management-Related Deliverables along with their
Target Date.
Table 4: Project Management- Related Deliverables

Number Deliverable Target Date
1 Project Proposal 06/14/16
2 Project Charter 06/29/16
3 Project Goals 06/29/16
4 Project Schedule 06/29/16
5 Project Budget 06/29/16
6 Work Breakdown Structure 06/29/16
7 Project Management & Project Team Members 06/06/16

List
8 Procurement Plan 08/30/16
9 Project Review Report 01/12/17
10 Project Close out Document 01/27/17
14
3.2. Product- Related Deliverables
The table below shows the Product -Related Deliverables along with their Target Date.
Table 5: Product-Related Deliverables

Number Deliverable Target Date
1 Prototype 07/11/16
2 Requirements Model 07/20/16
3 Requirements Management Plan 07/27/16
4 Conceptual Systems Design 07/27/16
5 Testing, Training and Implementation Strategy 08/01/16
6 Acceptance Criteria 08/02/16
7 Information Retention Criteria 08/03/16
8 Test Cases 08/05/16
9 Solution Design for Admin, Project Associate, CEO 08/26/16

Module
10 Development Environment 08/31/16
11 Admin, Project Associate, CEO Module 11/11/16
12 Module Coding Documentation 11/16/16
13 Unit Testing Results/Documentation 11/22/16
14 Test Environment and data, Training Content, 11/24/16

Implementation Components
15 Resolved Bugs 12/13/16
16 Testing Metrics 12/14/16
17 Test Reports 1/12/17
18 Training Materials 1/17/17
19 User Support Documentation 1/24/17
20 Installed System 1/26/17
15
4. Project Exclusions
The following items will not be included in the project:
• The project will not be providing any ongoing support/ maintenance for the
system once it has been implemented.
• This project will not be delivering any additional business reports aside from
the defined reports in the project charter.
• Actual uploading of the collected CVs
5. Project Assumptions and Constraints
The table below shows the Assumptions and Constraints in 3 Key Areas – People,
Process and Technology
Table 6: List of Project Assumptions and Constraints per Key Area

Assumptions
PEOPLE All important stakeholders will be available to attend
important meetings
Unit testers will be available and be able to perform unit
testing on schedule
In house developers will always be available on the allotted
man hours for development.
PROCESS Approvals schedule may vary according to the availability of
the Project Sponsor
TECHNOLOGY When the existing 10TB memory reached the critical level
(90% full), a purchase of an additional memory will be made.
Constraints
16
PEOPLE The development of the project will be dependent to the 2 IT
personnel of CFMCI who can perform 8-hour development
activities every day. Both are capable of VB Programming as
well as SQL coding. They are also capable of doing many
network structure.
Project Associates will act as Unit Testers
PROCESS User passwords must be minimum of 6 alpha-numeric keys.
Testing and QA process cannot be done in full-time since
testers are also the Project Associates
TECHNOLOGY The development of the product will be dependent on the
existing hardware as the CEO wants to utilize existing
hardware
The system will run with a server infrastructure but software
resources will be locally available in each unit.
4. Project Organization
4.1.Project Organization Chart
a. External Interfaces
The diagram below shows the external entities of the project which compose the users of
the application.
Project
Associates
CFMCICVMS
CEO Administrator
Figure 1: Project External Interfaces
17
b. Internal Interfaces
The diagram below shows the internal entities of the project which compose the people
involved in the development, testing and implementation of the project.
Figure 2: Project Internal Interfaces
Project Sponsor
Project Manager
System Analyst Programmers(2) QA Analyst Tester 1 Tester 2
4.2. Project Team Staff, Roles and Responsibilities
The table below shows the project team roles with their responsibilities.
Table 7: Project Team Staff, Roles and Responsibilities

Roles Responsibilities
18
Project Sponsor • Provides the direction of the project.
• Monitor the project’s progress.
• Define Project Management process with the Project
Manager.
• Arrange the timeline of the project with the Project
Manager
• Sign the Project Acceptance Document.
• Sign the Project Charter
• Sign the Project Plan
Project Manager • Ensure that the Project Team completes the project
• Develops the Project Plan with the team
• Manages the team’s performance of project tasks
• Responsible for the outcome (success or failure) of the
project.
System Analyst • Conducts One-on-One interview with the Stakeholder
• Participates in the Group Interview with the Stakeholder
• Participates in Phase Sign-off Meetings
• Conduct a Follow People Around Elicitation Technique
• Consolidate the requirements from Elicitation
• Rationalize Requirements
• Model the Requirements
• Define Specifications
• Participates in the Evaluation of Reuse, Buy(Rent), Build
Alternatives
• Create Requirements Management Plan
• Build Conceptual Systems Design
• Develop High Level Project Strategies
• Capture Additional Client Information
• Validate standards and guidelines for the Modules
• Design the Solution for Screen Layout, Program, Security,
Architecture and Logical Datastores of the Modules
• Document the Design phase
• Construct Misc Elements of the Solution
• Participates in the preparation of the Implementation
• Participates in the Development of Training Materials
• Participates in the Training , User Support Documentation
19
QA Analyst • Responsible in Deliverable Review, Audit Review
• Responsible in Informing Project Sponsor for Audit
• Responsible for Conducting Preliminary Audit Review and
the Audit Plan
• Responsible in Documenting the Audit Findings and
Reports
• Responsible for validating and closing none conformities
• Meeting the Project Sponsor for Audit Activity
• Responsible for closing the Audits
• Quality Control
Programmer • Stores and assemble delivered hardware and software

products
• Configure the Server
• Set up training and staging environment
• Code the application modules.
• Develops technical specifications and plans.
• Maintains the system.
• Resolve reported bugs.
• Conduct unit testing.
• Conduct application fine tuning.
• Defines restrictions, security and data integrity of the
database.
• Install and create database
• Create encoding log monitoring sheet
• Defines procedures for backup and recovery
Tester • Design and develop test plans.

• Conduct functional and integration testing.
• Prepare test cases.
• Execute test cases.
• Log bugs encountered issue register.
• Sign – off functional and integration of modules.
4.3.Deliverables Responsibility Matrix
This table indicates the person Responsible, Accountable, Consulted and Informed for
each project deliverable.
20
Table 8: Deliverables Responsibility Matrix
Project Deliverables PS PM SA P QAA T
Project Proposal A/C R - - - -
Project Charter A/C R - - - -
Project Goals A/C R - - - -
Project Schedule A/C R - - - -
Project Budget A/C R C C I I
Work Breakdown Structure A/C R C I I I
Project Management & Project A/C R I I I I

Team Members List
Procurement Plan A/C R C I I I
Project Review Report A/C C I I R I
Project Close out Document A/C R I I I I
Legend:
PS – Project Sponsor PM- Project Manager

SA – Systems Analyst P- Programmer
QAA – QA Analyst T – Tester
21
5.0 Project Management Approach
In executing the project management, waterfall approach will be implemented. Waterfall
approach will work well for this kind of small, well defined project. This kind of
approach best fits this kind of project since at the beginning of the project specifics will
be clearly defined. This approach is simple and easy to understand and use.
In this model phases are processed and completed one at a time and phases do not
overlap. It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process. Project management, both at internal level and client’s
level, is easy again because of visible outputs each phase. Deadlines can be set for the
completion of each phase and evaluation can be done from time to time, to check if
project is going as per milestones. Since output is produced after each stage, therefore it
has high visibility. The client and project manager gets a feel that there is considerable
progress. Here it is important to understand that in any project, psychological factors also
play an important role.
It is also beneficial if this approach will be used since the amount of resources for it are
minimal. This would not incur extra cost for the project.
Mentioning its strengths as an effective approach this explains why this methodology is
pro- quality. This project has its center in its functions on how it can help the current
system of the client and playing dull regarding the quality will be a major setback for the
project.
See Appendix C for details.
22
6.0 Project Technical Approach
6.1 Product Development Methodology
In developing the project, the waterfall methodology will be implemented. The project
will be divided into sequential phases. Emphasis will be on planning, time schedules,
target dates, budget and implementation of the entire system. A tight control will be
maintained over the life of the project via extensive written documentation, formal
reviews and approval or signoff by the user and the information technology management
at the end of most phases before beginning the next phase. A written documentation is an
explicit deliverable of each phase.
This model will involve documenting the project in advance, including the user interface,
user stories, and all features’ variation and outcomes.
This methodology has been chosen because the requirements are very well known, clear
and fixed. Also, the product definition is stable so it is a good thing to use this
methodology. This methodology will also best fit small projects like this one where
technology is easily understood and there is no ambiguous requirement. See details in
Appendix D
23
6.2 Development Tools
The list below shows the development tool that will be used during product development
Table 8: Product Development Tools

a. Hardware (2) Lenovo ThinkPad L430 2465 - C 1000M / 1.8 GHz
(1) HPE ProLiant DL80 Gen9 Server
b. Software Visual Studio
HelpNDoc
Time Travel Tracing
Microsoft Office Word 2013
Microsoft Office Excel 2013
c. Database MySQL, MySQL Connector
6.3 Technical Architecture
Figure 3: Development Environment Technical Architecture
24
The system resources will be client based to avoid heavy network traffic so most
processes will take place in the terminals instead in the server. The server’s purpose will
be purely for data and file retrieval. This kind of architecture will be implemented since
the CEO is highly concerned with the project budget. Many better architecture can be
implemented but budget is a big consideration.
For Business Process Diagrams, please see APPENDIX B: Project SRS Section 5
25
7.0 Baseline Plans
7.1 Scope Baseline
The table below shows the scope baseline thru WBS, WBS ID, Effort, Resources, Start
and End Date.
Table 9: Scope Baseline

EFFOR RESOURC
WBS ID WBS DESCRIPTION T ES FROM TO
161.15 1/27/2
1 Project Management days 6/6/2016 017
Analyst[50
%],Project
manager,Pr
oject 6/14/2
1.1 Initiation 7 days Sponsor 6/6/2016 016
Analyst,Pro
ject
manager[5 6/15/201 6/29/2
1.2 Planning 10 days 0%] 6 016
160.38 1/26/2
1.3 Execution days 6/6/2016 017
Project 6/10/2
1.3.1 Acquire Project Team 5 days manager 6/6/2016 016
Identify and Hire Additional 6/10/2

1.3.1.1 Team Members 5 days 6/6/2016 016
6/6/20
1.3.1.2 Resource Contract Signing 0.5 days 6/6/2016 16
Project 6/6/20
1.3.1.3 Deploy Team 0.5 days manager 6/6/2016 16
Project 6/6/20
1.3.1.4 Roll-Off Team 0.5 days manager 6/6/2016 16
8/26/201 8/31/2
1.3.2 Procurement 2 days 6 016
Project 8/26/201 8/30/2
1.3.2.1 Plan Procurements 1 day manager 6 016
Project 8/30/201 8/31/2
1.3.2.2 Administer Procurements 0.5 days Sponsor 6 016
Project 8/31/201 8/31/2
1.3.2.3 Close Procurements 0.5 days manager 6 016
26
Analyst,Proj
ect
manager,Pro
grammer
1,Programm
er 2,Tester
1,Tester 7/4/20
1.3.3 Project Kickoff Meeting 0.75 days 2(User) 7/4/2016 16
Project
Conduct Analysis Phase Sign Off manager,An 8/8/20
1.3.4 Meeting 0.5 days alyst 8/5/2016 16
Project
Conduct Design Phase Sign Off manager,An 8/26/201 8/26/2
1.3.5 Meeting 0.5 days alyst 6 016
Analyst,Proj
ect
manager,Pro
grammer
Conduct Construct Phase Sign Off 1,Programm 11/25/20 11/28/2
1.3.6 Meeting 0.53 days er 2 16 016
Analyst,Pro
grammer
1,Programm
er 2,Project
manager,Tes
Conduct Test Phase Sign Off ter 1,Tester 1/12/201 1/12/2
1.3.7 Meeting 0.2 days 2(User) 7 017
Analyst,Pro
grammer
1,Programm
er 2,Project
manager,Tes
ter 1,Tester
Conduct Implementation Phase 2(User),Proj 1/25/201 1/26/2
1.3.8 Sign Off Meeting/Final Approval 0.47 days ect Sponsor 7 017
7.25 1/12/2
1.4 Monitoring and Control days 1/3/2017 017
1/10/2
1.4.1 Quality Assurance 5.25 days 1/3/2017 017
1/3/20
1.4.1.1 Deliverable review 0.5 days QA Analyst 1/3/2017 17
1/4/20
1.4.1.2 Audit Review 1 day QA Analyst 1/3/2017 17
Inform Project Sponsor for 1/4/20

1.4.1.3 Audit 0.25 days QA Analyst 1/4/2017 17
Conduct Preliminary Audit 1/5/20

1.4.1.4 Review 0.5 days QA Analyst 1/4/2017 17
1/6/20
1.4.1.5 Execute Audit Plan 1 day QA Analyst 1/5/2017 17
27
Document Audit Findings 1/6/20
1.4.1.6 and Reports 0.5 days QA Analyst 1/6/2017 17
Validate and Close non 1/9/20

1.4.1.7 conformities 0.5 days QA Analyst 1/6/2017 17
QA
Meeting with Project Sponsor Analyst,Proj 1/9/20
1.4.1.8 for Audit Activity 0.5 days ect Sponsor 1/9/2017 17
1/10/2
1.4.1.9 Close Audit 0.5 days QA Analyst 1/9/2017 017
Tester
1,Tester
2(User),QA 1/10/201 1/12/2
1.4.2 Quality Control 2 days Analyst 7 017
Project
manager,A
nalyst,Proj
ect
Sponsor,Pr
ogrammer
1,Program
mer
2,Tester
0.28 1,Tester 1/26/201 1/27/2
1.5 Project Management Sign-off days 2(User) 7 017
131.03 1/12/2
2 Execution days 7/4/2016 017
22.3 8/8/20
2.1 Analysis days 7/4/2016 16
12.45 7/25/2
2.1.1 Requirements Specifications: days 7/4/2016 016
7/14/2
2.1.1.1 Elicitation 5.25 days 7/4/2016 016
Analyst,Test
er
2.1. One-on-One Interview 2(User),Proj 7/5/20
1.1.1 with the Stakeholder 0.5 days ect manager 7/4/2016 16
2.1. Group Interview with the Analyst,Proj 7/5/20
1.1.2 Stakeholder 0.5 days ect manager 7/5/2016 16
Programme
r
1[75%],Proj
ect
2.1. manager,An 7/11/20
1.1.3 Prototyping 1.98 days alyst 7/5/2016 16
2.1. Conduct a Follow Analyst,Proj 7/13/201 7/14/2
1.1.4 People Around Elicitation Technique 1 day ect manager 6 016
28
7/14/201 7/20/2
2.1.1.2 Validation 4 days 6 016
2.1. Consolidate the 7/14/201 7/14/2
1.2.1 Requirements from Elicitation 0.5 days Analyst 6 016
2.1. Rationalize the 7/14/201 7/15/2
1.2.2 Requirements 0.5 days Analyst 6 016
2.1. 7/15/201 7/20/2
1.2.3 Model The Requirements 3 days Analyst 6 016
2.1. Create Process 7/15/201 7/18/2
1.2.3.1 Models(UML) 1 day 6 016
2.1. Create Data 7/18/201 7/19/2
1.2.3.2 Models 1 day 6 016
2.1. Create Data Flow 7/19/201 7/20/2
1.2.3.3 Diagram 1 day 6 016
7/20/201 7/22/2
2.1.1.3 Specification 2.2 days Analyst 6 016
2.1. Prioritize the 7/20/201 7/20/2
1.3.1 Requirements 0.2 days 6 016
2.1. Ensure Traceability of 7/20/201 7/20/2
1.3.2 the Requirments 0.5 days 6 016
2.1. Ensure Testability of the 7/20/201 7/21/2
1.3.3 Requirments 0.5 days 6 016
2.1. Create Business 7/21/201 7/22/2
1.3.4 Requirements Report 1 day 6 016
Project 7/22/201 7/25/2
2.1.1.4 Verification 1 day manager 6 016
2.1. Conduct Requirements 7/22/201 7/22/2
1.4.1 Review 0.5 days 6 016
2.1. 7/22/201 7/25/2
1.4.2 Obtain Sponsor Sign Off 0.5 days 6 016
Evaluate Reuse, Buy(Rent), Build Analyst,Proj 7/25/201 7/25/2

2.1.2 Alternatives 0.25 days ect manager 6 016
Create Requirements Management 7/25/201 7/27/2

2.1.3 Plan 2 days Analyst 6 016
7/25/201 7/27/2
2.1.4 Build Conceptual Systems Design 2 days Analyst 6 016
Analyst[50
%],Project
Develop High level Project manager[50 7/27/201 8/1/20
2.1.5 Strategies 3 days %] 6 16
7/27/201 7/28/2
2.1.5.1 Establish Testing Strategy 1 day 6 016
29
7/28/201 7/29/2
2.1.5.2 Establish Training Strategy 1 day 6 016
Establish Implementation 7/29/201 8/1/20

2.1.5.3 Strategy 1 day 6 16
Capture Additional Client Analyst,Proj 8/3/20

2.1.6 Information 2 days ect manager 8/1/2016 16
8/2/20
2.1.6.1 Develop Acceptance Criteria 1 day 8/1/2016 16
Develop Information 8/3/20

2.1.6.2 Retention Criteria 1 day 8/2/2016 16
Tester
1,Tester 8/5/20
2.1.7 Create Test Cases 2 days 2(User) 8/3/2016 16
8/8/20
2.1.8 Sign Off Analysis Phase 0.1 days 8/8/2016 16
15.75 8/30/2
2.2 Software Design days 8/8/2016 016
Administrator Module/Project 12.75 8/24/2

2.2.1 Associate Module/ CEO Module days 8/8/2016 016
Validate Standards and 8/8/20

2.2.1.1 Guidelines for Administrator Module 0.5 days Analyst 8/8/2016 16
Validate Standards and
Guidelines for Project Associate 8/9/20
2.2.1.2 Module 0.5 days Analyst 8/8/2016 16
Validate Standards and 8/9/20

2.2.1.3 Guidelines for CEO Module 0.5 days Analyst 8/9/2016 16
Design the Solution for
Screen layouts for Adminsitrator 8/10/2
2.2.1.4 Module 0.75 days Analyst 8/9/2016 016
Screen layouts for Project Associate 8/10/201 8/11/20
2.2.1.5 Module 0.75 days Analyst 6 16
Design the Solution for 8/11/201 8/11/20

2.2.1.6 Screen layouts for CEO Module 0.75 days Analyst 6 16

2.2.1.7 Programs for Adminsitrator Module 1 day Analyst 6 016

2.2.1.8 Programs for Project Associate Module 1 day Analyst 6 016

2.2.1.9 Programs for CEO Module 1 day Analyst 6 016

2.2.1.10 Security for Project Associate Module 1 day Analyst 6 016

2.2.1.11 Security for Adminsitrator Module 1 day Analyst 6 016
30
2.2.1.12 Security for CEO Module 1 day Analyst 6 016

2.2.1.13 Architecture for Adminsitrator Module 0.5 days Analyst 6 016

2.2.1.14 Architecture Project Associate Module 0.5 days Analyst 6 016

2.2.1.15 Architecture for CEO Module 0.5 days Analyst 6 016
Logical Datastores for Adminstrator 8/23/201 8/23/2
2.2.1.16 Module 0.5 days Analyst 6 016
Logical Datastores for Project 8/23/201 8/24/2
2.2.1.17 Associate Module 0.5 days Analyst 6 016

2.2.1.18 Logical Datastores for CEO Module 0.5 days Analyst 6 016
8/24/201 8/26/2
2.2.2 Document 1.5 days Analyst 6 016
Analyst[50
%],Project
manager[50 8/26/201 8/30/2
2.2.3 Sign Off Design Phase 1 day %] 6 016
61.78 8/30/201 ######
2.3 Coding days 6 ###
Construct Development 8/30/201 8/31/2

2.3.1 Environment 0.5 days 6 016
Programmer
1[50%],Pro
grammer 8/31/201 9/14/2
2.3.2 Administrator Module 10 days 2[50%] 6 016
Programmer
1[50%],Pro
grammer 9/14/201 10/12/
2.3.3 Project Associate Module 20 days 2[50%] 6 2016
Programmer
1[50%],Pro
grammer 10/12/20 11/11/2
2.3.4 CEO Module 20 days 2[50%] 16 016
Programmer
1[50%],Pro
grammer 11/11/20 11/16/2
2.3.5 Document 3 days 2[50%] 16 016
Programmer
1[50%],Pro
grammer 11/16/20 11/22/2
2.3.6 Unit Testing 4 days 2[50%] 16 016
31
####### ######
2.3.6.1 Administrator Module 1 day # ##
####### ######
2.3.6.2 Project Associate Module 1 day # ##
####### ######
2.3.6.3 CEO Module 1 day # ##
####### ######
2.3.6.4 Document 1 day # ##
Construct Misc Elements of the 11/22/20 11/25/2

2.3.7 Solution 3.5 days 16 016
Analyst,Test ####### ######
2.3.7.1 0.5 days er 1,Tester 2 # ##
Construct Testing Project ####### ######

2.3.7.2 Environment and Data 1.5 days manager # ##
Construct Implementation Project ####### ######

2.3.7.3 Compoonets 1.5 days manager # ##
Analyst,Proj
ect
manager,Pro
grammer
1,Programm
er 2,Tester 11/28/20 11/28/2
2.3.8 Sign Off Construct Phase 0.25 days 1,Tester 2 16 016
31.2 11/28/20 1/12/2
2.4 Testing days 16 017
Programmer
1[50%],Pro
grammer 11/28/20 12/13/
2.4.1 Resolve Bugs 10 days 2[50%] 16 2016
Testing Metrics(Total errors/
period, error categories, product defect 12/13/20 12/14/
2.4.2 metrics) 1 day Tester 1 16 2016
12/14/20 12/15/
2.4.3 Regression testing 0.75 days Tester 1 16 2016
12/15/20 12/16/
2.4.4 Managing Test Cases 0.75 days Tester 1 16 2016
12/16/20 12/16/
2.4.5 Validate Test Coverage 0.75 days Tester 1 16 2016
12/16/20 12/19/
2.4.6 Integration Test 0.75 days Tester 1 16 2016
Tester
1[50%],Test
er 2(User) 12/19/20 12/26/
2.4.7 System Test 4.5 days [50%] 16 2016
32
####### ######
2.4.7.1 Security Testing 1 day # ##
####### ######
2.4.7.2 Requirements Testing 0.5 days # ##
####### ######
2.4.7.3 Usability Testing 1 day # ##
####### ######
2.4.7.4 Interface Testing 0.5 days # ##
####### ######
2.4.7.5 Installation Testing 0.5 days # ##
####### ######
2.4.7.6 System Test Reporting 1 day # ##
Defect and Classification Tracking 12/26/20 12/29/

2.4.8 and methods 3 days 16 2016
Tester
1[50%],Test
er 2(User) 12/29/20 1/2/20
2.4.9 Update Files/Records 1 day [50%] 16 17
Tester
1,Tester
2(User),Proj
ect
manager,Pro 1/3/20
2.4.10 User Acceptance Testing 1 day ject Sponsor 1/2/2017 17
QA
Analyst,Test
er 1,Tester
2(User),Proj
ect
manager,Pro 1/12/201 1/12/2
2.4.11 Sign Off Test Phase 0.25 days ject Sponsor 7 017
9.97 1/12/201 1/26/2
3 Deployment days 7 017
Analyst,Pro
grammer
1,Program 1/12/201 1/13/2
3.1 Prepare for Implementation 1 day mer 2 7 017
1/13/201 1/23/2
3.2 User Training 6 days 7 017
1/13/201 1/17/2
3.2.1 Develop Training Materials 2 days Analyst 7 017
Analyst,Proj 1/17/201 1/23/2
3.2.2 Conduct Training 4 days ect manager 7 017
1/23/201 1/24/2
3.3 User Support Documentation 1 day Analyst 7 017
33
Programme
r 1,Project 1/24/201 1/25/2
3.4 Implement the Solution/Go LIVE 1 day manager 7 017
Installation Management and 1/24/201 1/25/2

3.4.1 Coordination 0.5 days 7 017
Installation Performance 1/25/201 1/25/2

3.4.2 Monitoring 0.5 days 7 017
Analyst,Pro
ject
manager,Pr
oject
Sponsor,Pr
ogrammer 1/26/201 1/26/2
3.5 Sign Off Implementation Phase 0.5 days 1 7 017
34
7.2 Schedule Baseline
7.2.1 Milestone List
The table below shows the list of Project Milestones and their Target Date.
Table 10: Milestone List

No. Milestone Target Date
1 Sign-off acquire project team 06/10/2016
2 Sign-off Project Kickoff Meeting 07/04/2016
3 Sign- off Analysis Phase 08/08/2016
4 Sign-off Design Phase 08/30/2016
5 Sign-off Procurement 08/31/2016
6 Sign-off Construct Phase 11/28/2016
7 Sign-off Test Phase 1/12/2017
8 Sign-off Quality Assurance 1/10/2017
9 Sign-off Quality Control 1/12/2017
10 Sign-off Implementation Phase 1/26/2017
11 Sign-off Project Management 1/27/2017
35
7.3 Cost Baseline
The table below provides summary funding requirements along with their percentage to
the total budget with project cost contingency shown as a separate cost item.
Table 11: Summary of Project Funding Requirements
Item Description Estimated Cost Percentage

1 Software Cost Php 8,100.00 2.03%
2 Hardware/Network Cost Php 2140.00 0.54%
3 Operational Cost Php 20, 086.04 5.06%
4 Labour Cost Php 342,286.53 85.97%

5 Training Php 3,200.00 0.81%
6 Effort Cost Php 20,800.00 5.24%
Sub Total Php 396,612.57 100%
*** Contingency Php 51,559.63 13%

Total Cost Php 448,172.20
Cost Baseline S-Curve

₱500,000
₱375,000
₱250,000
₱125,000
₱0
June August October December
Baseline
Figure 4: Cost VS Time S-Curve
36
7.4 Quality baseline
Based on the gathered and elicited project requirements, company standards, and
applicable industry standards, the following quality metrics was established for this
project:
Table 12: Product Quality Baseline

Project Metric Measure Target
Objectives
Total elements usability index of all 70.00%
Usability elements
Total number of elements
Total actual response time of all 2-5 seconds
processes
Number of processes
Efficiency
Total handled transactions per > 4 Transaction
second
Total attributes of software that < 1.00%

1. Improve bear on frequency of failures
response time Total faults in the software
by 40% to
Total software faults per module < 1.00%
client Reliability
requirements Total software processes per
by reducing module
searching time Total recovery time <1
over collected
Standard recovery time
CVs to
increase Total present and appropriate tasks 95.00%
revenue. per module
Total required tasks per module
Total correct results per module 95%
37
95%
Total expected correct results per
Functional module
ity Total successful interaction with 95%
the database
Total interaction with the database
Total number of successful access 0%
of unregistered users
Total number of registered users
Total recovery time <1
Reliability
2. Provide a
Total data retrieval in seconds of all 2-5 seconds
single
processes per module
centralized Efficiency
storage for the Total process per module
CVs collected
over time Total number of successful access 0%
Functional of unregistered users
ity
Usability elements
Total actual response time of all 2-5 seconds
processes
Efficiency Number of processes
Total handled transactions per > 4 Transaction
second
Total attributes of software that < 1.00%
3. Allow the bear on frequency of failures
CEO to monitor Total faults in the software
CV uploading
activities (to the Total software faults per module < 1.00%
Reliability
centralized Total software processes per
storage) by module
project associate,
38
storage) by
project associate, Total recovery time <1
duration or both
in real-time. Standard recovery time
Total present and appropriate tasks 95.00%
per module
Functional module
ity Total successful interaction with 95%
the database
Total number of successful access 0%
of unregistered users
39
8.0 Management Plans
8.1 Scope Management Plan
8.1.1 Scope Management Approach
The scope for this project was defined through a comprehensive requirements collection
process. First, a thorough analysis was performed on the company’s current system based
on employee and user feedback through requirements eleicitation. From this information,
the project team developed the project requirements documentation, the requirements
management plan, and the requirements traceability matrix for what the new software
application must accomplish.
The project description and deliverables were developed based on the requirements
collection process and input from subject matter experts in software design, technical
support, programming and business applications. This process of expert judgment
provided feedback on the most effective ways to meet the original requirements of
providing a new software platform from which the company can improve its financial
tracking and internal financial processes. The scope will be defined through the Scope
Statement, WBS, WBS Dictionary and Statement of Work.
The scope will be measured and verified using Scope Baseline, Quality Checklists to be
created by the analyst.
40
For scope change, the Project Management Institute (PMI) philosophy of managing
change will be adapted wherein changes will be prevented if possible, if inevitable,
evaluate the impact of the change on the other constraints of the project then create
options to reduce the impact like compressing the schedule. After this, the change request
must be approved by the project manager then by the Project Sponsor.
The final deliverable and project acceptance will be forwarded to the project manager
first then to the Project Sponsor.
The analyst and project manager will be responsible for these activities.
8.1.2 Roles and Responsibilities
The table below shows the roles and responsibility for the Scope Management Plan
Table 12: Scope Management Plan Roles and Responsibilities

Role Responsibility
Analyst • Responsible for the elicitation, validation and specification
of requirements
• Responsible for the Requirements documentation,
requirements management Plan and Requirements
Traceability matrix
• Responsible for creating the Scope Baseline and Quality
checklists
• Responsible for the creating the final deliverables and
submitting it to the Project Manager
• Responsible for creating and accomplishing change requests
41
Project Manager • Responsible for the requirements verification
• Responsible for creating the WBS, WBS Dictionary and
Statement of Work, work performance measurements,
Organizational process assets updates
• Will approve the final project deliverables then forward it to
the Project Sponsor
• Will be forwarding the project acceptance to Project
Sponsors
Project Sponsor • Responsible for approving the final project deliverables and
project acceptance
8.1.3 Scope Definition
After the requirements collection, the scope will be define using the Project Charter,
Requirements documentation and Organizational process assets. Techniques like expert
judgement, product analysis, and alternatives identification will be used. Outputs like
Project scope statement and Project document updates will be expected. The Project
Scope must include scope description, acceptance criteria, deliverables, exclusions,
constraints and assumptions while updates must include stakeholder register.
Then from here the WBS can now be created by decomposition technique. Results shall
be the WBS, WBS Dictionary and Project Document Updates.
8.1.4 Scope Validation
The scope validation process focuses mainly on customer acceptance. The project
customer will formally accept all the project deliverables. This process will occur at the
42
end of each phase. During the process, the customer gives their feedback on the work that
was performed.
For validation, outputs from the previous stages are needed. Among these are the Project
Management Plan, Requirements Documentation, Requirements Traceability Matrix and
the validated deliverables. These will be measured, examined and work must be verified
versus requirements and acceptance criteria.
From here acceptable deliverable, change requests and project document updates must be
established.
The Project
Management Plan,
Customer gives
Requirements
feedback on the work
Documentation,
that was performed Change request/s will
Requirements Deliverables will be Project Documents
through inspection be forwarded if there
Traceability Matrix accepted will be updated
(basing in the is any
and the validated
forwarded
deliverables are
documents)
forwarded to
customer
Figure 5: Scope Validation Process Diagram
8.1.5 Scope Control
43
This process will involve the monitoring of the status of the project and management of
changes to the scope. The process will also involve the assessment of additional
requirements from the customer overlooking the project scope. Managers will measure
the work product against the scope baseline to ensure that the project stays on track to
prevent any unnecessary changes.
For this stage, the project management plan, work performance information,
requirements documentation, requirements traceability matrix and organizational process
assets are needed. Through variance analysis, cause and degree of variance vs. scope
baseline and corrective/ preventive actions can be determined.
After the variance analysis, the work performance measurements, corrective action
chosen, reasons and lesson learned and change requests must be established while
updated organizational process assets on causes of variances, and other updates on
management plan and documentation must be done.
44
Managers will measure
Monitoring of the status Assessment of additional the work product against
of the project and requirements from the the scope baseline to
management of changes customer overlooking the ensure that the project
to the scope project scope stays on track to prevent
any unnecessary changes.
Figure 6: Scope Control Process Diagram
8.1.6 Scope Management Tools
1. WBS Template (Microsoft Office Excel)
2. WBS Dictionary (Microsoft Office Excel)
3. Requirements Documentation Template(Microsoft Office Word )
4. Requirements Traceability Matrix(Microsoft Office Word)
5. Change Requests Template (Microsoft Office Word)
6. Variance Analysis Results Template (Microsoft Office Word)
8.2 Change Management Plan
8.2.1 Change Management Approach
The change management plan will be consisted of three major steps – planning,
evaluating and approving. Planning is consisted by change control procedures and change
45
control plan while evaluating is consisted by change control meetings. Approving or
tracking is consisted by change control board, change authorization procedures and
change control system.
8.2.2 Definitions of Change
The table below shows the definition of each Classified Kind of Change that will be used
for the Project
Table 13: Definition for Kind of Change

Kind of Change Definition
1. Defect Repair Defects or nonconforming products which have already
been created as a result of project work must be modified or
repaired
2. Corrective Action An activity which realigns the project work, which is not
conforming to the project management plan
3. Preventive action An activity which ensures that the future project work will
be aligned with the project management plan
4. Updates Changes to the project management plan itself
8.2.3 Change Control Board
The change control board will be composed of the Project Manager, the Systems Analyst
and the Project Sponsor. The PMI philosophy are simplified by preventing changes if
possible, if inevitable, evaluate the impact of the change on the other constraints of the
project then create options to reduce the impact like compressing the schedule. After this,
the change request must be approved by the project manager then by the Project Sponsor.
46
The table below shows the roles and responsibilities for the Change Management Plan.
Table 14: Change Management Roles and Responsibilities

Role Responsibility
Analyst • Responsible for creating and accomplishing change
requests
Project Manager • Will approve the change request then forward it to
the Project Sponsor
Project Sponsor • Responsible for approving the change request.
8.2.5 Change Control Process
Planning is Approving the

Evaluating
consisted by Change Tracking the
change through
change control Authorization Change Control
change control
procedures and Procedures by System
meetings
change control the Change
Figure 7: Change Control Process
8.2.6 Change Management Tools
1. Change Control Plan Template (Microsoft Office Word)
2. Change Control Meeting Minutes Template (Microsoft Office Word)
3. Change Request Template (Microsoft Office Word)
47
8.3 Requirements Management Plan
8.3.1 Requirements Management Approach
The approach we will use for requirements management for the project will be broken
down into four areas: requirements identification, requirements analysis, requirements
documentation, and ongoing requirements management.
• Requirements Identification: The project team will facilitate various methods to
collect requirements which includes: one-on-one interviews with the stakeholder,
group interview with the Stakeholder, prototyping, follow people around Elicitation
Technique, questionnaires and surveys. These will be conducted among the project
stakeholders to ensure all requirements are captured.
• Requirements Analysis: The project team will analyze requirements to determine if
they fall into project or product categories. Additionally, this analysis will determine
where in the WBS the requirements will fall or what work activities correspond to
particular requirements. Accountability and priority for each requirement will also be
determined as part of the analysis. Finally, metrics and acceptance criteria must be
determined for all requirements in order to provide a baseline for understanding when
a requirement has been fulfilled to an acceptable level.
• Requirements Documentation: Once requirements have been identified and
analyzed, they will be documented and assigned to accountable personnel. These
requirements will be added to the project plan and the project team will determine
what methodology the accountable personnel will use to track and report on the status
of each requirement. All requirements will also be added to the project requirements
48
checklist which must be completed before formal project closure is accepted by the
project sponsor.
• Ongoing Requirements Management: Throughout the project lifecycle, the project
manager will ensure all team members are reporting requirement status and raising
any issues or concerns with their assigned requirements as appropriate. As the project
matures there may be situations in which requirements must change or be altered in
some way. The project team must follow the established change control process in
order to propose any changes to requirements and receive approval from the change
control board. Ongoing requirements management also includes receiving approval of
all requirements by all vested parties as part of project closure.
The table below shows the roles and responsibilities for the Requirements management
Plan
Table 15: Roles and Responsibilities for the Requirements Management Plan
Role Responsibility
Analyst • Responsible for requirements elicitation, specification,
validation and verification.
• Responsible for the Requirements Analysis and Documentation
• Responsible for creating and accomplishing change requests
49
Project Manager • Responsible for requirements elicitation, specification,
validation and verification.
• Responsible for ensuring all team members are reporting
requirement status and raising any issues or concerns with their
assigned requirements as appropriate
• Will approve the change request then forward it to the Project
Sponsor
• Responsible in making the necessary changes to the matrix and
communicate those changes to all project stakeholders.
Project Sponsor • Responsible for approving the change request.
Programmer • Responsible for prototyping
8.3.3 Requirements Prioritization Process
The Project manager will facilitate stakeholder meetings in order to establish priorities
for all project requirements. This project will use a three-level scale in order to prioritize
requirements.
The table below illustrates these levels and defines how requirements will be grouped:
Table 16: Requirements Priority Definition

Priority Level Definition
High These requirements are mission critical. They are required for
project/product success or for progression to the next project phase.
Medium These requirements support product/process operations but can be
completed under the next product release.
Low These requirements are quality and/or functional process
enhancements and are desirable if time and resources permit.
8.3.4 Configuration Management
50
For this project, the Requirements Management Plan will utilize the configuration
management activities outlined in the Configuration Management Plan. Key items
include documentation/version control and change control:
a) Documentation and Version Control: All project documentation will be loaded
into the Configuration Management Database (CMDB) as the central repository
for the project. Appropriate permissions will be granted to the project team for
editing and revising documentation. Any proposed changes to project requirements
must be reviewed by the Configuration Control Board (CCB) and have written
approval by the project sponsor before any documentation changes are made. Once
these proposed changes are approved and the documentation is edited, the project
manager will be responsible for communicating the change to all project
stakeholders.
b) Change Control: Any proposed changes in project requirements must be carefully
considered before approval and implementation. Such changes are likely to impact
project scope, time, and/or cost, perhaps significantly. Any proposed changes to
project requirements will be reviewed by the CCB. The role of the CCB is to
determine the impact of the proposed change on the project, seek clarification on
proposed change, and ensure any approved changes are added to the CMDB. The
project sponsor, who also sits on the CCB, is responsible for approving any
changes in project scope, time, or cost and is an integral part of the change review
and approval process.
51
8.3.5 Requirement Traceability Matrix
Below is the requirements traceability matrix template for the project. The purpose of the
requirements traceability matrix is to ensure all product requirements are completed in
accordance with the project charter. This matrix provides a thread from all product
requirements through design, testing, and user acceptance. Design document and charter
references are contained in the Project Configuration Management Plan. Any approved
changes in project scope or requirements will result in changes to the traceability matrix
below. Based on impacts of the approved changes, the Project Manager will make the
necessary changes to the matrix and communicate those changes to all project
stakeholders.
Table 17: Requirements Traceability Matrix Template

Project Name Business Area
Project Manager Business Analyst

Lead
QA Lead Target
Implementation
Date
Req. # Requirement Design Document Charter Test User Comme

Description Reference Reference Case Acceptance nts
Referen Validation
ce
1 xxxxxxxxxxxxxxxx XX-001 0.0.0 TS001

xxx
2 xxxxxxxxxxxxxxxx XX-002 0.0.0 TS002

xxx
8.3.6 Requirements Management Tools
52
1. Requirements Traceability Matrix (Microsoft Office Word)
2. Stakeholder Meetings Minute Template (Microsoft Office Word)
3. Project Configuration Management Plan Template (Microsoft Office Word)
4. Prototyping (Visual Studio 2008)
8.4 Configuration Management Plan
The table below shows the roles and responsibilities for the Configuration Management
Plan
Table 18: Configuration Management Plan Roles and Responsibilities

Role Responsibility
Analyst · Overall management of the CMDB
· Identification of CIs
· Providing configuration standards and templates to the project
team
· Providing any required configuration training
Project Manager · Overall responsibility for all CM activities related to the NexGen
project
· Identification of CIs
· All communication of CM activities to project stakeholders
· Participation in CCB meetings
• Re-baselining, if necessary, any items affected by CM changes
• Ensure all change requests comply with organizational templates
and standards prior to the CCB
• Identification of CIs
Project Sponsor · Chairing all CCB meetings

• Providing approval for any issues requiring additional scope,
time, or cost
C o n f i g u r a t i o n · Review and approve/reject configuration change requests
Control Board · Ensure all approved changes are added to the configuration
management database (CMDB)
• Seeking clarification on any CIs as required
53
8.4.2 Configuration Control
The project will use a standardized configuration control process throughout the project
lifecycle in order to ensure all Configuration Items (CI) are handled in a consistent
manner and any approved changes are fully vetted regarding impact and communicated
to stakeholders.
As CIs are identified by the project team, the Configuration Manager will assign a CI
name and the CI will be entered into the CMDB in an “initiate” status. The CI will then
be assigned to an engineer focus group. Each member of a CIs focus group will have the
ability to access the CI through the CMDB, make changes and edits, and enter the CI
back into the CMDB with a description of the change/edit annotated in the CMDB log.
It is imperative that for any software changes testing is conducted by the focus group in
order to validate any changes made. The Project Manager assigned to manage the focus
group is responsible for ensuring that testing has been conducted, changes are entered
into the CMDB log, and that all changes/edits are saved properly into the CMDB. The
Project Manager is also responsible for assigning new version numbers and CMDB status
for any changes made by his/her assigned focus group.
Many times a CI will have a relationship with one or more other CIs within a project. The
Project Manager and the Analyst will work together to ensure these relationships are fully
54
understood. They will also then be responsible for illustrating these relationships and co-
dependencies in the CMDB to ensure a full understanding of each CI and how they relate
to one another.
Any configuration changes which are identified by the project team or stakeholders must
be captured in a configuration change request (CCR) and submitted to the CCB. The
CCB will review, analyze, and approve/deny the request based on the impact, scope,
time, and cost of the proposed change. If the change is approved, the project requirements
will be re-baselined (if necessary) and all changes will be communicated to the project
team and stakeholders by the Project Manager. Denied CCRs may be re-submitted with
additional or new information for re-consideration by the CCB.
8.4.3 Configuration Management Database
The Configuration Management Database (CMDB) will be the centralized repository for
all configuration information for the project. The CMDB provides a common platform
for the project team to edit, change, revise, and review CIs and also to ensure all
documents and data are updated with the latest revision and release formats.
Access to the CMDB will be granted and governed by standard UNIX permissions. Two
types of CMDB access will be granted for the project:
1. Full read and write access will be granted to the Analyst and Project
Manager. They will be authorized to access the CMDB to make
55
changes, edit documents and data, and review and approve versions
and CI status.
2. Read only access will be granted to the Project Sponsor and all other
stakeholders. This access will allow these individuals to view all CIs
and CI data but they will not be authorized to make any changes. If
these individuals identify the need for a change or edit they will notify
the Analyst who will review the notification and provide feedback.
The CMDB will provide assurance that members of the project team are always working
off of the latest version of software, data, and documentation. However, it is important to
maintain the history of these assets throughout the project lifecycle. As these assets are
changed and updated, the Project Manager will be responsible for updating the status of
the CI and providing new revision numbering. This numbering will be done in
accordance with company’s standard revision control numbering process wherein higher
version numbers indicate more recent versions of the software, data, or documentation.
8.4.4 Configuration Status Accounting
It is important that for the project and the Project Sponsor have the ability to review
configuration status at any given time. The Project Manager will also submit weekly
reports, to include configuration status, every Friday. These reports will consist of the
following information as part of the configuration status section:
56
1) Change requests
a. Aging - How long change requests have been open
b. Distribution – number of change requests submitted by owner/group
c. Trending – what area(s) are approved changes occurring in
2) Version Control
a. Software
b. Hardware
c. Data
d. Documentation
3) Build Reporting
a. Files
b. CI relationships
c. Incorporated Changes
4) Audits
a. Physical Configuration
b. Functional Configuration
Prior to any new software releases, the Analyst will work with the Project Manager to
ensure all CIs are updated with latest release versions.
57
8.4.5 Configuration Audits
Configuration audits will be an ongoing part of the project lifecycle. The purpose of the
configuration audit is to ensure all team members are following the established
procedures and processes for configuration management. Project audits for the Project
will occur prior to any major software release or at the Project Manager or Sponsor’s
discretion if they determine the need for one.
All configuration audits will be performed by the Analyst. Throughout the project the
Analyst works closely with Project Manager to ensure that all configuration processes
and procedures are being followed. As part of the configuration audit the Analyst will
perform the following tasks:
1. Establish an audit environment in the CMDB
2. The Analyst will copy all of the latest software, data, and document versions into
the audit environment
3. The Analyst will ensure all versions are correctly numbered and that version
control has been performed properly
4. The Analyst will analyze historical versions and timestamps of all software, data,
and documents to ensure all changes/edits were properly recorded and captured
5. The Analyst will copy latest software versions and conduct software testing to
ensure requirements are being met
6. The Analyst will ensure all required artifacts are present and current in the CMDB
58
7. The Analyst will ensure all approved CCRs have been incorporated into the
project and are recorded in the CMDB
Once the audit has been performed, the Configuration Manager will compile his/her audit
findings. For each finding, the Analyst must work with the Project Manager/Team to
identify the corrective action(s) necessary to resolve the discrepancy and assign
responsibility for each corrective action. Upon completion of the project audit and
findings, the Analyst will note all discrepancies and compile a report to be presented to
the Project Manager and Sponsor.
8.4.6 Configuration Management Tools
1. Project Manager Weekly Report Template (Microsoft Office Excel)
2. Project Manager Weekly Report Template (Microsoft Office Word)
3. PowerShell DSC
8.5 Schedule Management Plan
8.5.1 Schedule Management Approach
Project schedules will be created using MS Excel 2010 starting with the deliverables
identified in the project’s Work Breakdown Structure (WBS). Activity definition will
identify the specific work packages which must be performed to complete each
deliverable. Activity sequencing will be used to determine the order of work packages
and assign relationships between project activities. Activity duration estimating will be
59
used to calculate the number of work periods required to complete work packages.
Resource estimating will be used to assign resources to work packages in order to
complete schedule development.
Once a preliminary schedule has been developed, it will be reviewed by the project team
and any resources tentatively assigned to project tasks. The project team and resources
must agree to the proposed work package assignments, durations, and schedule. Once this
is achieved the project sponsor will review and approve the schedule and it will then be
baselined.
The following will be designated as important activities related to the project schedule:
• Completion of scope statement and WBS/WBS Dictionary
• Baselined project schedule
• Approval of final project budget
• Project kick-off
• Approval of roles and responsibilities
• Requirements definition approval
• Completion of data mapping/inventory
• Project implementation
• Acceptance of final deliverables
The table below shows the roles and responsibilities for the Schedule Management Plan.
60
Table 19: Schedule Management Plan Roles and Responsibilities
Role Responsibility
Project Team · Responsible for participating in work package definition,
sequencing, and duration and resource estimating
· will also review and validate the proposed schedule and
perform assigned activities once the schedule is approved
· Providing configuration standards and templates to the project
team
· Providing any required configuration training
Project Manager • Responsible for facilitating work package definition,
sequencing, and estimating duration and resources with the
project team
• will also create the project schedule using MS Project 2007
and validate the schedule with the project team, stakeholders,
and the project sponsor
• will obtain schedule approval from the project sponsor and
baseline the schedule
Project Sponsor • will participate in reviews of the proposed schedule and
approve the final schedule before it is baselined
P r o j e c t · will participate in reviews of the proposed schedule and assist
Stakeholders in its validation.
8.5.3 Schedule Control
The project schedule will be reviewed and updated as necessary on a weekly basis with
actual start, actual finish, and completion percentages which will be provided by task
owners.
The project manager is responsible for holding weekly schedule updates/reviews;
determining impacts of schedule variances; submitting schedule change requests; and
reporting schedule status in accordance with the project’s communications plan.
61
The project team is responsible for participating in weekly schedule updates/reviews;
communicating any changes to actual start/finish dates to the project manager; and
participating in schedule variance resolution activities as needed.
The project sponsor will maintain awareness of the project schedule status and review/
approve any schedule change requests submitted by the project manager.
8.5.4 Schedule Changes and Thresholds
If any member of the project team determines that a change to the schedule is necessary,
the project manager and team will meet to review and evaluate the change. The project
manager and project team must determine which tasks will be impacted, variance as a
result of the potential change, and any alternatives or variance resolution activities they
may employ to see how they would affect the scope, schedule, and resources. If, after this
evaluation is complete, the project manager determines that any change will exceed the
established boundary conditions, then a schedule change request must be submitted.
Submittal of a schedule change request to the project sponsor for approval is required if
either of the two following conditions is true:
62
• The proposed change is estimated to reduce the duration of an individual
work package by 10% or more, or increase the duration of an individual
work package by 10% or more.
• The change is estimated to reduce the duration of the overall baseline
schedule by 10% or more, or increase the duration of the overall baseline
schedule by 10% or more.
Any change requests that do not meet these thresholds may be submitted to the project
manager for approval.
Once the change request has been reviewed and approved the project manager is
responsible for adjusting the schedule and communicating all changes and impacts to the
project team, project sponsor, and stakeholders. The project manager must also ensure
that all change requests are archived in the project records repository.
8.5.5 Schedule Change Control Process
Any changes in the project scope, which have been approved by the project sponsor, will
require the project team to evaluate the effect of the scope change on the current
schedule. If the project manager determines that the scope change will significantly affect
the current project schedule, he/she may request that the schedule be re-baselined in
consideration of any changes which need to be made as part of the new project scope.
63
The project sponsor must review and approve this request before the schedule can be re-
baselined.
8.6 Cost Management Plan
8.6.1 Cost Management Approach
Costs for this project will be managed at the third level of the Work Breakdown Structure
(WBS). Control Accounts (CA) will be created at this level to track costs. Earned Value
calculations for the CA’s will measure and manage the financial performance of the
project. Although activity cost estimates are detailed in the work packages, the level of
accuracy for cost management is at the third level of the WBS. Credit for work will be
assigned at the work package level. Work started on work packages will grant that work
package with 50% credit; whereas, the remaining 50% is credited upon completion of all
work defined in that work package.
Cost variances < 1 in the cost and schedule performance indexes will change the status of
the cost to cautionary; as such, those values will be changed to green in the project status
reports. Cost variances of > 1 in the cost and schedule performance indexes will change
the status of the cost to an alert stage; as such, those values will be changed to red in the
project status reports. This will require corrective action from the Project Manager in
order to bring the cost and/or schedule performance indexes below the alert level.
Corrective actions will require a project change request and be must approved by the
Project Sponsor before it can become within the scope of the project.
64
The table below shows the roles and responsibilities for the Cost Management Plan.
Table 19: Schedule Management Plan Roles and Responsibilities

Project Manager • The Project Manager will be responsible for managing
and reporting on the project’s cost throughout the
duration of the project.
• During the monthly project status meeting, the Project
Manager will meet with management to present and
review the project’s cost performance for the preceding
month. Performance will be measured using earned
value.
• The Project Manager is responsible for accounting for
cost deviations and presenting the Project Sponsor with
options for getting the project back on budget.
Project Sponsor • The Project Sponsor has the authority to make changes
to the project to bring it back within budget.
8.6.3 Project Cost Measurements
Performance of the project will be measured using Earned Value Management. The
following four Earned Value metrics will be used to measure to projects cost
performance:
• Schedule Variance (SV)
• Cost Variance (CV)
• Schedule Performance Index (SPI)
65
• Cost Performance Index (CPI)
If the Schedule Performance Index or Cost Performance Index has a variance greater than
1 the Project Manager must report the reason for the exception. If the SPI or CPI has a
variance of less than 1 the Project Manager must report the reason for the exception and
provide management a detailed corrective plan to bring the projects performance back to
acceptable levels.
Table 20: Performance Measure Result Interpretation

Performance Measure Green Red
Schedule Performance Index (SPI) >1 <1
Cost Performance Index (CPI) >1 <1
8.6.4 Project Cost Reporting Format
Reporting for cost management will be included in the monthly project status report. The
Monthly Project Status Report will include a section labeled, “Cost Management”. This
section will contain the Earned Value Metrics identified in the previous section. All cost
variances outside of the thresholds identified in this Cost Management Plan will be
reported on including any corrective actions which are planned. Change Requests which
are triggered based upon project cost overruns will be identified and tracked in this
report.
66
8.6.5 Cost Variance Process
The Control Thresholds for this project is a CPI or SPI of less than 1 or greater than 1. If
the project reaches one of these Control Thresholds a Cost Variance Corrective Action
Plan is required. The Project Manager will present the Project Sponsor with options for
corrective actions within five business days from when the cost variance is first reported.
Within three business days from when the Project Sponsor selects a corrective action
option, the Project Manager will present the Project Sponsor with a formal Cost Variance
Corrective Action Plan. The Cost Variance Corrective Action Plan will detail the actions
necessary to bring the project back within budget and the means by which the
effectiveness of the actions in the plan will be measured. Upon acceptance of the Cost
Variance Corrective Action Plan it will become a part of the project plan and the project
will be updated to reflect the corrective actions.
8.6.6 Cost Change Control Process
The cost change control process will follow the established project change request
process. Approvals for project budget/cost changes must be approved by the project
sponsor.
8.6.7 Cost Management Tools
1. Earned Value Management Plan Template (Microsoft Office Word and Excel)
2. Cost Variance Corrective Action Plan (Microsoft Office Word)
67
8.7 Quality Management Plans
8.7.1 Quality Management Approach
The project team will work with the Quality Group to define and document all
organizational and project specific quality standards for both product and processes. All
quality documentation will become part of the Project Plan and will be transitioned to
operations upon the successful completion of the project.
Metrics will be established and used to measure quality throughout the project life cycle
for the product and processes. The QA Analyst will be responsible for working with the
project team to define these metrics, conduct measurements, and analyze results. Metrics
will focus on the following:
• Schedule
• Cost
• Product and Process
o Usability
o Functionality
o Reliability
o Efficiency
Quality improvements will be identified by any member of the project team or by the
quality assurance analyst. Each recommendation will be reviewed to determine the cost
68
versus benefit of implementing the improvement and how the improvement will impact
the product or processes. If an improvement is implemented the project manager will
update all project documentation to include the improvement and the quality manager
will update the organizational documentation the improvement affects.
The table below shows the roles and responsibilities for the Quality Management Plan.
Table 21: Quality Management Plan Roles and Responsibilities

Role Responsibility
QA Analyst • Defining the testing activities for subordinates – testers or
test engineers.
• All responsibilities of test planning.
• To check if the team has all the necessary resources to
execute the testing activities.
• To check if testing is going hand in hand with the software
development in all phases.
• Prepare the status report of testing activities.
• Required Interactions with customers.
• Updating project manager regularly about the progress of
testing activities.
69
Testers • To read all the documents and understand what needs to be
tested.
• Based on the information procured in the above step
decide how it is to be tested.
• Inform the test lead about what all resources will be
required for software testing.
• Develop test cases and prioritize testing activities.
• Execute all the test case and report defects, define severity
and priority for each defect.
• Carry out regression testing every time when changes are
made to the code to fix defects.
8.7.3 Quality Requirements/ Standards
For this project quality standards will be based from the attributes defined ISO 9126.
Quality metrics will be based from the following attributes defined in ISO 9126.
a) Functionality. Characteristics relating to achievement of the basic purpose
for which the software is being engineered.
b) Reliability. Characteristics relating to the capability of software to maintain
its level of performance under stated conditions for a stated period of time.
c) Usability. Characteristics relating to the effort needed for use and on the
individual assessment of such use, by a stated or implied set of users
d) Efficiency. Characteristics related to the relationship between the level of
performance of the software and the amount of resources used, under stated
conditions.
70
8.7.4 Quality Assurance
For the QA, the project management Plan which includes the Quality management plan,
Process Management Plan, Quality Metrics, Work performance information that includes
technical performance measures, project deliverables status, schedule progress and cost
incurred and quality control measurements are needed to initiate this step
71
For the Quality Assurance, activities below will be performed:
Table 23: QA Techniques Activities

Techniques Activities
Quality Audits – Are structured and independently reviewed to check the project
activities comply with organizational policies and procedures
– Identifying all of the good/best practices being implemented –
Identifying all the gaps/shortcomings
– Sharing the good practices introduced or implemented in similar
projects
– Proactively offering assistance in positive manner to improve
implementation of process to help the team raise productivity
– Highlighting contributions of each audit in the lesson learned
Process Analysis – Identifying needed improvements
– Examining experienced problems, constrains, and non-value
added activities
– Includes root cause analysis (problem, cause, preventive actions)
The quality manager will provide quality management and conduct process audits on a
weekly basis, monitor process performance metrics, and assure all processes comply with
project and organizational standards. If discrepancies are found, the QA Tester will meet
with the Project Manager and review the identified discrepancies.
The Project Manager will schedule regularly occurring project, management, and
document reviews. In these reviews, an agenda item will include a review of project
processes, any discrepancies and/or audit findings from the quality manager, and a
discussion on process improvement initiatives.
72
Process improvement is another aspect of quality assurance. Quality assurance reviews,
findings, and assessments will result in some form of process improvement and, as a
result, product improvement. All process improvement efforts must be documented,
implemented, and communicated to all stakeholders as changes are made.
8.7.5 Quality Control
The “V” Model will be used for the quality control of the project. This is to ensure that
the system is thoroughly tested and is aligned to the business requirements.
Figure 8: V Model Diagram
V model is a software development model that is based on the relationship between each
phase of the development life cycle as described in a typical Waterfall model of software
development and its associated phase of testing. The idea of the V-model is to have an
implementation plan for the software testing at each level namely component, interface,
73
system, acceptance and release of the software project which need to be adhered to
eliminate discrepancies in the software simultaneously rather than waiting for the
software development process to complete before handling it to the software testers.
The project team will document and finalize user requirements. The signed off user
requirements will be used by the System Analyst for designing the system. The developer
will then create a screen prototype to be approved by the Project Sponsor and Users. The
signed off design solutions will be coded by the Developers. The developers will then
setup and configure the test environment.
After coding the modules, the Developers will perform unit testing to evaluate if the
individual parts of the program are operating properly. Upon passing the unit and
function testing accordingly, the modules will be then integrated and tested. Integration
testing identifies problems that occur when modules are combined. Non-functional
testing will also occur during integration testing. Stress testing and performance testing
are included in the non-functional testing. When all the modules are integrated, system
testing through UAT will follow. This is to detect any inconsistencies between the
modules that are integrated and the hardware. System testing tests not only the design but
also the behavior and the expectations of the customer. Pilot run will follow after system
testing.
74
During UAT, the end users are invited to test the system to validate the functionalities and
to verify if the data generated are correct. Users will then sign off the UAT that will
signify that the system is ready for implementation.
8.7.6 Quality Control Measurements
All Project products and processes must be measured and fall within the established
standards and tolerances. The below log will be used by the project and quality teams in
conducting these measurements and will be maintained for use as supporting
documentation for the project’s acceptance.
75
The table below shows the Quality Assurance and Quality Control Log Template
Table 24: Quality Assurance and Quality Control Log Template

Tri D Process Required Actual Acceptable Recommen Date
al # at Measured Value Measured ? (Y/N) dation Resolve
e d
8.7.7 Quality Management Tools
1. Quality Assurance Log Template (Microsoft Office Word)
2. Quality Control Log Template (Microsoft Office Word)
3. Microsoft Office Excel
76
8.8 Risk Management Plan
8.8.1 Risk Management Approach
The approach we have taken to manage risks for this project included a methodical
process by which the project team identified, scored, and ranked the various risks. The
most likely and highest impact risks were added to the project schedule to ensure that the
assigned risk managers take the necessary steps to implement the mitigation response at
the appropriate time during the schedule. Risk managers will provide status updates on
their assigned risks in the weekly project team meetings, but only when the meetings
include their risk’s planned timeframe. Upon the completion of the project, during the
closing process, the project manager will analyze each risk as well as the risk
management process. Based on this analysis, the project manager will identify any
improvements that can be made to the risk management process for future projects. These
improvements will be captured as part of the lessons learned knowledge base.
The table below shows the roles and responsibilities for the Risk Management Plan
Table 24: Risk Management Plan Roles and Responsibilities

Project Manager • Serve as Risk manager
• Approves Risk Management Plan
• Define Risk management Plan
• Participate in the risk management process
• Maintain the risk register
• Take the ownership of risk mitigation, planning and
execution
77
Project Sponsor • Informed about major risks and provides input to risk
mitigation strategies
• Participate in the risk management process
System Analyst • Writes the Risk Management plan
Project Team • Participates in the risk management process
8.8.3 Risk Identification
For this project, risk identification was conducted in the initial project risk assessment
meeting. The method used by the project team to identify risks was the Crawford Slip
method. The project manager chaired the risk assessment meeting and distributed
notepads to each member of the team and allowed 10 minutes for all team members to
record as many risks as possible.
a) Expert Interview: Two Expert Interviews were held for this project. The
interviews revealed several risks which were then mitigated by making
changes to the project plan. The remaining risks are included in the Risk
Register.
b) Risk Assessment Meeting: A risk assessment meeting was held with key
team members and stakeholders. The risks identified during this meeting were
added to the project plan and Risk Register.
c) Historical Review of Similar Projects: The project team reviewed the
history of similar projects in order to determine the most common risks and
the strategies used to mitigate those risks.
8.8.4 Risk Qualification and Prioritization
78
In order to determine the severity of the risks identified by the team, a probability and
impact factor was assigned to each risk. This process allowed the project manager to
prioritize risks based upon the effect they may have on the project. The project manager
utilized a probability-impact matrix to facilitate the team in moving each risk to the
appropriate place on the chart.
Once the risks were assigned a probability and impact and placed in the appropriate
position on the chart, the recorder captured the finished product and the project manager
moved the process on to the next step: risk mitigation/avoidance planning.
79
8.8.5 Risk Monitoring
The table below shows the sample Risk Mitigation Plan
Table 25: Sample Risk Mitigation Plan

RISK MITIGATION PLAN
RTP No.: 1 Project Phase: Integration Testing
Milestone: Sign-off Testing Phase
Potential Failure: The modules produced is not efficient or optimal for deployment
Mitigation Plan: Systems Analyst should define standard method in using test
cases and test case summary
Detailed Remar
Steps Date of Completion ks Validated By
Verified By:
Name: Signature: Date:
Remarks:
Approved By:
Name: Signature: Date:
80
8.8.6 Risk Mitigation and Avoidance
The project manager has led the project team in developing responses to each identified
risk. As more risks are identified, they will be qualified and the team will develop
avoidance and mitigation strategies. These risks will also be added to the Risk Register
and the Project Plan to ensure they are monitored at the appropriate times and are
responded to accordingly. If necessary, the Risk Management Plan will be updated.
The risks for this project will be managed and controlled within the constraints of time,
scope, and cost. All identified risks will be evaluated in order to determine how they
affect this triple constraint. The project manager, with the assistance of the project team,
will determine the best way to respond to each risk to ensure compliance with these
constraints.
In extreme cases it may be necessary to allow flexibility to one of the project’s
constraints. Only one of the constraints for this project allows for flexibility as a last
resort. If necessary, funding may be added to the project to allow for more resources in
order to meet the time (schedule) and scope constraints. Time and scope are firm
constraints and allow for no flexibility. Again, the cost constraint is flexible only in
extreme cases where no other risk avoidance or mitigation strategy will work.
See details in Appendix I.
81
8.8.7 Risk Register Management
The risk register will be maintained in order to track risks and associated mitigation
strategies. This section describes the risk register criteria as well as where the risk register
is maintained and how these risks are tracked in the project schedule.
The Risk Register for this project is a log of all identified risks, their probability and
impact to the project, the project objective they belong to, mitigation strategy, and when
the risk will occur. The register was created through the initial project risk management
meeting led by the project manager. During this meeting, the project team identified and
categorized each risk. Additionally, the team assigned each risk a score based on the
probability of it occurring and the impact it could potentially have. The Risk Register
also contains the mitigation strategy for each risk as well as when the risk is likely to
occur.
Based on the identified risks and timeframes in the risk register, each risk has been added
to the project plan. At the appropriate time in the plan—prior to when the risk is most
likely to occur—the project manager will be the risk manager to ensure adherence to the
agreed upon mitigation strategy. The risk manager will provide the status of the risks at
the weekly project team meeting for the risk’s planned timeframe.
82
See details in Appendix I.
8.8.8 Risk Management Tools
1. Risk Mitigation Template (Microsoft Office Word)
2. Risk Register Template (Microsoft Office Word)
8.9 Human Resource Management Plan
8.9.1 Staffing Management
a) Staff Acquisition: The programmers will consist entirely of internal resources.
There will be outsourcing/contracting performed for the Project Manager, Analyst
and QA Analyst. The Project Manager will negotiate with the CEO in order to
identify and assign resources in accordance with the project organizational
structure. The testers will be coming from the Project Associates of the company.
The project team will not be co-located for this project and all resources will remain
in their current workspace.
b) Training: There is currently no training scheduled with regards to the Project since
the staffs has adequate required skill sets. However, if training requirements are
identified, funding will be provided from the project reserve.
c) Performance Reviews: The project manager will review each team member’s
assigned work activities at the onset of the project and communicate all
expectations of work to be performed. The project manager will then evaluate each
team member throughout the project to evaluate their performance and how
effectively they are completing their assigned work. Prior to releasing project
resources, the project manager will meet with the CEO and provide feedback on
83
employee project performance. The CEO will then perform a formal performance
review on each team member.
d) Recognition and Rewards: Although the scope of this project does not allow for
ample time to provide cross-training or potential for monetary rewards there are
several planned recognition and reward items for project team members.
• Upon successful completion of the project, any team member who satisfactorily
completed all assigned work packages on time will receive a certificate of thanks
from the CEO.
8.9.2 Human Resource Management Tool
1. Certificate Template (Microsoft Office Word)
2. Employee Project Performance Review Template (Microsoft Office Excel)
8.10 Communications Management Plan
8.10.1 Communication Management Approach
The Project Manager will take a proactive role in ensuring effective communications on
this project. The communications requirements are documented in the Communications
Matrix presented in this document. The Communications Matrix will be used as the guide
for what information to communicate, who is to do the communicating, when to
communicate it and to whom to communicate.
84
As with most project plans, updates or changes may be required as the project progresses
or changes are approved. Changes or updates may be required due to changes in
personnel, scope, budget, or other reasons. Additionally, updates may be required as the
project matures and additional requirements are needed. The project manager is
responsible for managing all proposed and approved changes to the communications
management plan. Once the change is approved, the project manager will update the plan
and supporting documentation and will distribute the updates to the project team and all
stakeholders. This methodology is consistent with the project’s Change Management Plan
and ensures that all project stakeholders remain aware and informed of any changes to
communications management.
The table below shows the roles and responsibilities for the Communications
Management Plan.
Table 26: Communications Management Plan Roles and Responsibilities

b. Project Sponsor • The project sponsor is the champion of the project
and has authorized the project by signing the project
charter.
• This person is responsible for the funding of the
project and is ultimately responsible for its success.
Since the Project Sponsor is at the executive level
communications should be presented in summary
format unless the Project Sponsor requests more
detailed communications.
85
c. Program Manager • The Program Manager oversees the project at the
portfolio level and owns most of the resources
assigned to the project. The Program Manager is
responsible for overall program costs and profitability
as such they require more detailed communications
than the Project Sponsor.
d. Key Stakeholders • Normally Stakeholders includes all individuals and
organizations who are impacted by the project. For
this project we are defining a subset of the
stakeholders as Key Stakeholders. These are the
stakeholders with whom we need to communicate
with and are not included in the other roles defined in
this section.
• The Key Stakeholders includes executive
management with an interest in the project and key
users identified for participation in the project.
e. Change Control • The Change Control Board is a designated group
which is reviews technical specifications and
Board authorizes changes within the organizations
infrastructure.
• Technical design documents, user impact analysis
and implementation strategies are typical of the types
of communication this group requires.
8.10.3 Communication Management Constraints
All project communication activities will occur within the project’s approved budget,
schedule, and resource allocations. The project manager is responsible for ensuring that
communication activities are performed by the project team and without external
resources which will result in exceeding the authorized budget. Communication activities
will occur in accordance with the frequencies detailed in the Communication Matrix in
order to ensure the project adheres to schedule constraints. Any deviation of these
86
timelines may result in excessive costs or schedule delays and must be approved by the
project sponsor.
Collar Finder organizational policy states that where applicable, standardized formats and
templates must be used for all formal project communications. Collar Finder
organizational policy also states that only the CEO may authorize the distribution of
confidential information. The project manager is responsible for ensuring that approval is
requested and obtained prior to the distribution of any confidential information regarding
this project.
8.10.4 Stakeholder Communication Requirements
As part of identifying all project stakeholders, the project manager will communicate
with each stakeholder in order to determine their preferred frequency and method of
communication. This feedback will be maintained by the project manager in the project’s
Stakeholder Register. Standard project communications will occur in accordance with the
Communication Matrix; however, depending on the identified stakeholder
communication requirements, individual communication is acceptable and within the
constraints outlined for this project.
In addition to identifying communication preferences, stakeholder communication
requirements must identify the project’s communication channels and ensure that
stakeholders have access to these channels. If project information is communicated via
87
secure means or through internal company resources, all stakeholders, internal and
external, must have the necessary access to receive project communications.
Once all stakeholders have been identified and communication requirements are
established, the project team will maintain this information in the project’s Stakeholder
Register and use this, along with the project communication matrix as the basis for all
communications.
8.10.5 Communication Methods and Technologies
The project team will determine, in accordance with the organizational policy, the
communication methods and technologies based on several factors to include:
stakeholder communication requirements, available technologies (internal and external),
and organizational policies and standards.
Collar Finder maintains a Dropbox platform within the office which all projects use to
provide updates, archive various reports, and conduct project communications. This
platform enables senior management, as well as stakeholders with compatible technology,
to access project data and communications at any point in time. Dropbox also provides
the ability for stakeholders and project team members to collaborate on project work and
communication.
88
Collar Finder maintains software licenses for MS Excel software. All project teams are
responsible for developing, maintaining, and communicating schedules using this
software. PERT Charts are the preferred format for communicating schedules to
stakeholders. The project schedule will be maintained on both the Dropbox platform.
All project communication and documentation, in addition to being maintained on the
Dropbox platform, will be archived on the internal Collar Finder shared drive which
resides in the PMO program directory. Organizational naming conventions for files and
folder will be applied to all archived work
89
8.10.6 Communication Matrix
The following table identifies the communications requirements for this project.
Table 27: Project Communication Requirements

Communic Objective Mediu Freque Audienc Owne Deliver Format
ation Type of m ncy e r able
Communic
ation
Kick-off Introduce - Face Once - Project Projec - - Soft
Meeting the project to Face Sponsor t Agenda copy
team and - Project Mana - archived
the project. Team ger Meeting on
Review - Minutes Dropbox
project Stakehol site and
objectives ders project
and website.
managemen
t approach.
Project Review - Face Weekly - Project Projec - - Soft
Team status of the to Face Team t Agenda copy
Meetings project with - Mana - archived
the team. Confer ger Meeting on
ence Minutes Dropbox
Call - site and
Project project
Schedul website.
e
Technical Discuss and - Face As - Project Techn - - Soft
Design develop to Face Needed Technica ical Agenda copy
Meetings technical l Staff Lead - archived
design Meeting on
solutions Minutes Dropbox
for the site and
project. project
website.
90
Weekly Report on - Face Monthl - PMO Projec - Slide - Soft
Project the status of to Face y t Updates copy
Status the project - Mana - archived
Meetings to Confer ger Project on
managemen ence Schedul Dropbox
t. Call e site and
project
website.
Project Report the - Email Monthl - Project Projec - - Soft
Status status of the y Sponsor t Project copy
Reports project - Project Mana Status archived
including Team ger Report on
activities, - - Dropbox
progress, Stakehol Project site and
costs and ders Schedul project
issues. - PMO e website.
91
8.10.7 Communication process
The communication flowchart below was created to aid in project communication. This
flowchart provides a framework for the project team to follow for this project. However,
there may be occasions or situations which fall outside of the communication flowchart
where additional clarification is necessary. In these situations the Project Manager is
responsible for discussing the communication with the Project Sponsor and making a
determination on how to proceed.
Does CEO
Meet CEO to
make
Figure 9: Communication Process
8.10.8 Communication Standards
For this project, Collar Finder will utilize standard organizational formats and templates
for all formal project communications. Formal project communications are detailed in the
project’s communication matrix and include:
92
a) Kick-off Meeting – project team will utilize Collar Finder standard templates for
meeting agenda and meeting minutes. Additionally, any slides presented will use the
Collar Finder standard slideshow template.
b) Project Team Meetings – project team will utilize Collar Finder standard
templates for meeting agenda and meeting minutes. Additionally, any slides
presented will use the Collar Finder standard slideshow template.
c) Technical Design Meetings - project team will utilize Collar Finder standard
templates for meeting agenda and meeting minutes. Additionally, any slides
d) Weekly Project Status Meetings - project team will utilize Collar Finder
standard templates for meeting agenda and meeting minutes. Additionally, any slides
e) Project Status Reports – project team will utilize Collar Finder standard
templates for meeting agenda and meeting minutes. Additionally the standard project
status report document, available on the share drive, will be used to provide project
status.
Informal project communications should be professional and effective but there is no
standard template or format that must be used.
8.10.9 Communication Escalation Process
93
Efficient and timely communication is the key to successful project completion. As such,
it is imperative that any disputes, conflicts, or discrepancies regarding project
communications are resolved in a way that is conducive to maintaining the project
schedule, ensuring the correct communications are distributed, and preventing any
ongoing difficulties. In order to ensure projects stay on schedule and issues are resolved,
Collar Finder will use its standard escalation model to provide a framework for escalating
communication issues.
The table below defines the priority levels, decision authorities, and timeframes for
resolution.
Table 28: Priority Levels Definition

Priority Definition Decision Timeframe for
Authority Resolution
Priority 1 Major impact to project or CEO/Project Within 4 hours
business operations. If not Sponsor
resolved quickly there will be a
significant adverse impact to
revenue and/or schedule.
Priority 2 Medium impact to project or CEO/Project Within one
business operations which may Sponsor business day
result in some adverse impact to
revenue and/or schedule.
Priority 3 Slight impact which may cause Project Within two
some minor scheduling difficulties Manager business days
with the project but no impact to
business operations or revenue.
94
Priority 4 Insignificant impact to project but Project Work continues
there may be a better solution. Manager and any
recommendation
s are submitted
via the project
change control
process
8.11 Stakeholder Management Plan
8.11.1 Stakeholder Registry
Once all the project stakeholders have been identified, the project team will categorize
and analyse each stakeholder. The purpose of this analysis is to determine the
stakeholders’ level of power or influence, plan the management approach for each
stakeholder, and to determine the appropriate levels of communication and participation
each stakeholder will have on the project.
The project team will categorize stakeholders based on their department. Once all
stakeholders have been categorized, the project team will utilize a power/interest matrix
to illustrate the potential impact each stakeholder may have on the project. Based on this
analysis the project team will also complete a stakeholder analysis matrix which
illustrates the concerns, level of involvement, and management strategy for each
stakeholder.
95
The chart below will be used to establish stakeholders and their levels of power and
interest for use on the power/interest chart as part of the stakeholder analysis.
Table 29: Project Stakeholders Power and Interest

Key Department Name Power Interest
(1-5) (1-5)
A Top Management Hernard Honcolada 5 5
B Operations Cess Castro 1 2
C Operations Krissam Tapa 1 2
D Operations Emylou Llanes 1 2
E Operations Irene Esquillo 1 2
F Operations Joshua Saguid 1 2
G MIS/ Project Team Wilhelm Kaibigan 2 3
H MIS/ Project Team Jake Leuterio 2 3
I Project Team Jan Ludvik Raneses 5 5
J Project Team Systems Analyst 3 5
K Project Team QA Analyst 2 2
8.11.2 Stakeholder Analysis Matrix
Below is the power/interest chart for the project stakeholders. Each point represents a
stakeholder/s in accordance with the key in the chart above.
96
A, I
K G, H
B-F
Figure 10: Stakeholder Power-Interest Chart
Based on the power and interest analysis and chart above, stakeholders B, C, D, E, F and
K will require minimal management effort as they reside in the lower left quadrant of the
matrix. Stakeholder G and H in the lower right quadrant, must be kept informed through
frequent communication on project status and progress. Stakeholders A, I and J, in the
upper right quadrant, are key players and must be involved in all levels of project
planning and change management.
97
8.11.3 Stakeholder Management Strategy
The table below shows the Stakeholder Management Strategies.

Table 30: Stakeholder Management Strategy
Stakeho Concerns Quadrant Strategy

lder
A Product and Process must Key Give feedback to
comply acceptance criteria Player deliverables.
Clarify test and quality results
with the project manager, QA
Analyst and testers.
B Systems Analyst must clearly Minimal Clarify questions during
understand end-user Effort requirements definition
perspective activities
C Systems Analyst must clearly Minimal Clarify questions during
D Systems Analyst must clearly Minimal Clarify questions during
E Systems Analyst must clearly Minimal Clarify questions during
F Systems Analyst must clearly Minimal Clarify questions during
G Questions regarding design Keep Work closely with the
solutions Informed systems analyst before
starting construct phase.
H Questions regarding design Keep Work closely with the
solutions Informed systems analyst before
starting construct phase.
I Resource and scheduling Key Obtain feedback on project
constraints for production once Player planning. Frequent
project is started communication and
addressing concerns are
imperative
98
J Ensures all design solutions Key Obtain feedback from project
will be understood by Player sponsor and end-users to
Programmer ensure clarity of requirements
K Product and process must meet Minimal Communicate test results and
quality metrics Effort performance specifications
and obtain feedback on
customer requirements or any
changes. Provide frequent
status reports and updates.
99
8.12 Procurement Management Plan
8.12.1 Procurement Management Approach
The Project Manager will provide oversight and management for all procurement
activities under this project. The Project Manager will work with the project team to
identify all items to be procured for the successful completion of the project. The CEO
will review the procurement items, determine whether it is advantageous to make or buy
the items, and begin the vendor selection and purchasing. For purchases, direct
purchasing will be made since supplies to be purchased are just minimal.
Services to be procured for this project will be solicited under firm-fixed price contracts.
The project team will work with the contracts. The company’s hiring policy will be
implemented.
8.12.2 Procurement Definition
The following procurement items and/or services have been determined to be essential
for project completion and success. The following list of items/services, justification, and
timeline are pending PMO review for submission to the contracts and purchasing
department:
Table 31: Procurement Items and Justification

Item/Service Justification Needed By
Software
100
Visual Studio Needed for software development 07/05/2016
Time Travel Tracing Needed for tracing previous versions of the 07/05/2016
software.
Hardware
UTP Cable Needed for network set up 08/31/2016
rj45 Needed for network set up 08/31/2016
Switch Needed for network set up 08/31/2016
Router Needed for network set up 08/31/2016
In addition to the above list of procurement items, the following individuals are
authorized to approve purchases for the project team:
Table 32: Authorized Team Members to Approve Purchases

Name Role
Jan Ludvik B. Raneses Project Manager
To Follow System Analyst
101
9.0 Appendices
9.1 APPENDIX A – Project Cost- Benefit Analysis
The table below shows the net present value in 5 years. 10% discount factor has been
used to calculate Net Present Value.
Table 33: Project Cost-Benefit Analysis

CollarFinder Management Consultancy Inc. Curriculum Vitae(CV) Management
System
DISCOUNT
RATE 0.1
Year CF DCF PV
0 -448,172.20 1 -448,172.20
1 2,851,200.00 0.909090909 2,592,000.00
2 2,851,200.00 0.826446281 2,356,363.64
3 2,851,200.00 0.751314801 2,142,148.76
4 2,851,200.00 0.683013455 1,947,407.96
5 2,851,200.00 0.620921323 1,770,370.88
NET PRESENT VALUE 10,360,119.04
Below is the detail of the computed benefit of Php 2, 851, 200. 00.
Table 34: Product Benefit Calculation

Benefits computed from
Commission (income) percentage 12% annual salary(12 - 18 months)

Lowest Salary in History 30,000.00
Annual Salary (12 months) 360,000.00
Income for placement 43200
Additional Placement using the system 66
102
₱2,851,200.0
Additional Income (Benefit ) 0
Table 35: Project Benefit Calculation Basis

66 additional Placements
Annual
Job Requirements from clients 230
Average Number of Entertained
requirements 130
Percentage 57%
Placement Percentage 66%
Annual Total Placements 86
Annual Total Working Days (Including Sat) 288

Average num of days spent on a req. 2 days
Average in hours 17.723 hours
** delay is on reviewing CVs
55% of time is consumed, 15% of time in
collecting new CVs, remaining 30%
is for contacting and processing
Time Spent on reviewing CVs 9.75 hours
Time Spent on Collecting new CVs 2.66 hours
Time Spent for contactinga nd
Processing 5.32 hours
Average Total time spent for a
requirement 17.72 hours
Using the system
Total Time spent on reviewing CVs

for a requirement would be reduced to 1 hour
Time Spent on Collecting new CVs 2.66 hours
Time Spent for contactinga nd
Processing 5.32 hours
103
Average Total time spent for a
requirement 8.98 hours
Time saved 8.75 hours
Total Time saved in a year 1137.2 hours
Total time saved in a year in days 142.15 days
Additional number of requirements that can
be
entertained 127
104
9.2 APPENDIX B – Systems Requirements Specification
9.2.1 INTRODUCTION
Purpose
This specification documents the functional and non-functional requirements for
the Collar Finder Management Consultancy Inc. Curriculum Vitae Management
System (CFMCICVMS), including design constraints and other related factors, to
support the Collar Finder Management Consultancy Inc. Curriculum Vitae
Management System Product Vision document (see Appendix A)
Scope
This specification provides a comprehensive view of the requirements for
CFMCICVMS to implement the features and functionalities as specified in the
CFMCICVMS Product Vision document (see Appendix A)
9.2.2 PROJECT DESCRIPTION
Project Owner
The CFMCICVMS will be developed for Collar Finder Management Consultancy
Inc. Collar Finder Management Consultancy Inc. is an executive search firm. It
has been doing business for almost a year. Their corporate office is situated at
28th Floor Cityland Pasong Tamo Tower u2807 2210 Chino Roces Avenue
Makati City. Currently they have 5 Project Associates (working on different
clients’ requirements) working with the CEO/ Owner Mr. Hernard Honcolada.
105
Project Overview
CFMCI is an organization that aims for convenience, efficiency and consistency
that the CFMCI CV Management System can give. One similarity among
Executive Search firms is a long response time regarding client requirements.
This is a problem being faced by all and having this kind of application can help
lessen the response time and create a good relationship with the clients.
The centralization of processes is taking its rise in a lot of organizations
nowadays. Aside from the fact that is the current trend, organizations are taking
this opportunity to increase the quality of services they offer and increase profit.
CFMCI has been established for over a year and they have been finding ways of
how they can improve the business process to cater faster service and to have
higher profit. This product will be used to contribute to the fulfilment of its vision,
mission and goals. This solution will aid the whole organization in implementing
executive search activities wherein CV review which is the backbone of the whole
process will be very convenient and fast as the software will narrow down
possible candidates for different client requirements. This will also help the
organization in its goals in catering faster service to its clients. It will also save up
human resource efforts as well as man power costs.
106
Problem Statement
The problem of uncentralized organizing and managing of collected

CVs from executive search activities
affects the CEO, the Project Associates and the whole

institution of CFMCI
the impact of which time-consuming searching and reviewing activities

over collected Cvs for a possible candidate for a
certain client requirement
a successful solution An application which shall be used for a centralized

would be storage for the CVs collected over time, for
uploading CVs to the central storage with meta
tags(First Name,Middle Name, Last Name Position,
and extra 10 tags) with CV preview feature, for
editing the details of an Uploaded CV, for the CEO
to monitor CV uploading activities by project
associate, duration or both, for an easier manner of
searching through the CVs using last name of
candidate, word/phrase match and search tags , for
previewing and downloading searched CVs. This
would come with User Registration interface and an
Administrator interface for activating and
deactivating user accounts
Product Vision Statement
For the CEO and Project Associates
107
who have the need to make their type of work
convenient to perform as well as to maximize their
time and effort in performing daily task.
CFMCI CV is an application
Management System
that provides features user registration, administrator
interface for activating and deactivating user
accounts, an interface to store CVs into a
centralized storage, an interface for the CEO to
monitor CV uploading activities by project
associate, duration or both, an interface for an easier
manner of searching through the CVs using last
name of candidate, word/phrase match and search
tags.
Unlike the current system which is unorganized which
results to inconvenience when it comes to managing
the collected CVs over time and reviewing them
whenever there is a client requirement
our product will provide and interface for
- a centralized storage for the CVs collected over
time
- an interface for uploading CVs to the central
storage with meta tags(First Name,Middle Name,
Last Name Position, and extra 10 tags) with CV
preview feature
- an interface for editing the details of an Uploaded
CV
- an interface for the CEO to monitor CV
uploading activities by project associate, duration
or both
- an interface for an easier manner of searching
through the CVs using last name of candidate,
word/phrase match and search tags and
previewing CVs
- and interface for previewing and downloading
searched CVs
- User Registration interface
- An Administrator interface for activating and
deactivating user accounts
108
9.2.3 BUSINESS CONTEXT
Current Business Process
Project Associates save the collected CVs in different ways in each. Other Project
Associates cannot directly access the CVs collected by other Project Associates.
Searching through the CVs collected from the start of their operations is very
tiring and time consuming. Search accuracy is very low as it relies only in human
capabilities.
Sometimes, the CEO also perform searching activities and he needs to copy files
from each Project Associate every time. The CEO experience cannot monitor if
the subscription from different CV downloading sites like Monster.com are being
maximized.
Proposed Business Process
The diagram below shows the Proposed Business Process for the project.
109
Figure 11: Proposed Business Process
9.2.4 SYSTEM OVERVIEW
System Perspective
Figure 12: System Perspective
110
System Interfaces
External Interfaces
There is no External Interface for the project
Hardware Interfaces
The table below shows the hardware interfaces needed for the project.
Table 36: Hardware Interfaces

Processor RAM Disk
(minimum) Space
Database server Intel iCore 3 2GB 1TB
Project Associate Intel Celeron 1.8GHz 1GB 500G

Terminal B
Operating server All Intel or AMD – 1Ghz 1GB 3GB
CFCMI CV Mgt Sys Intel iCore 3 1GB 500M

B
MySQL 5.7 All Intel or AMD – 1Ghz 256MB 100M
B
Software Interfaces
1. Project Associate / CEO / Administrator PC
- Windows 7 OS
- CFMCI CV Management System
2. CFMCICVMS Database Server
-MYSQL 5.7
3. Development
- Visual Basic 2008
- MYSQL 5.7
111
- Apache
-Windows 7 OS
Communication Interface
- FTP
-ODBC- mySQLClient Connection
User Interfaces
The table below show the user interfaces for the project.
Table 37: User Interfaces

ID No. User Interface Description User
A1 Log- In UI Authentication / Project Associates,

Authorization CEO, Administrator
A2 User registration Registration for User Project Associates,
UI Accounts CEO, Administrator
A3 Manage Account Account details and Project Associates,
Password Update CEO, Administrator
B1 Project Associate Let the Project Associate Project Associate,

and CEO Search and the CEO Search CEO
CV UI through the CVs saved in
the storage
PA1 Project Associate Let The Project Project Associate
Upload CV UI Associate Upload CV/s
PA2 Project Associate Let the Project Associate Project Associate
Edit Uploaded Edit the details of the
CV Detail uploaded CV
112
CEO1 CEO View Let the CEO view CEO
Reports UI different Reports
regarding uploading
activities(by PA,
Duration, PA and
Duration or compare the
PAs in a certain
Duration)
AD1 Administrator Let the Administrator Administrator
Manage User activate and deactivate
Accounts UI registered user accounts
Assumptions and Dependencies
The following assumptions and dependencies of the capabilities of the CFMCI
CV management system as outlined in this document:
a. The development of the project will be dependent on the existing
hardware as the CEO wants to utilize existing hardware
b. For the initial run of the project, it will also use the existing storage
with the capacity of 10 TB. The CEO confirmed that a purchase for an
upgrade will be just made if the storage went full.
c. The system will be dependent to the 2 IT Personnels of CollarFinder
Consultancy who can perform 6 hours of development activities every
day. Both are capable of VB Programming as well as SQL coding.
They are also capable of doing many network structure.
113
d. The system resources will be client-based while the database will be
server-based.
Summary of System Capabilities
The table below shows the summary of system capabilities of the product
Table 38: Summary of System Capabilities

Expected Benefits Solution Features
A more organized or • a centralized storage for the CVs
standardized way of storing collected over time
collected CVs
Reduced searching time over • a centralized storage for the CVs
thousands of CVs that they collected over time
have already collected over • an interface for an easier manner of
time searching through the CVs using
candidates’ last name, word/phrase
match and search tags and previewing
CVs
• an interface for editing the details of an
Uploaded CV
• User Registration interface
• Administrator interface for activating
and deactivating registered users
• and interface for previewing and
downloading searched CVs
Reduced number of Project • a centralized storage for the CVs
Associates needed to comply collected over time
with different client • an interface for an easier manner of
requirements(direct effect to searching through the CVs using
man power cost) candidates’ last name, word/phrase
CVs
Uploaded CV
114
Provided access to all of the • a centralized storage for the CVs
collected CVs from different collected over time
sources (Applicants, CV • an interface for an easier manner of
Downloading sites) of all searching through the CVs using
team members. candidates’ last name, word/phrase
CVs
• User Registration interface
• Administrator interface for activating
and deactivating registered users
Increased revenue of an • an interface for uploading CVs to the
additional Php 4,050,000 in central storage with meta tags(First
just a year due to improved Name,Middle Name, Last Name
response time to client Position, and extra 10 tags) with preview
requirements resulting to feature
Uploaded CV
• an interface for the CEO to monitor CV
uploading activities by project associate,
duration or both
• an interface for an easier manner of
searching through the CVs using
candidates’ last name, word/phrase
CVs
Monitoring capabilities for • an interface for the CEO to monitor CV
the CEO over the CV uploading activities by project associate,
uploading activities duration or both
Uploaded CV
9.2.5 USE CASE MODEL
115
Use Case Diagrams
1. Project Associate Use Case
Figure 12: Project Associate Use Case

2. CEO Use Case
Figure 13: CEO Use Case
3. Administrator Use Case
116
Figure 14: AdminsitratorUse Case
Actor Catalogue
The table below shows the actors of the system together with their description.
Table 39: Actor Catalogue

ID No. Actor Description Represented user
1 Project People who works for Project Associates

Associate CFMCI by finding
possible candidates for
client requirement/s.
2 CEO People who owns the CEO
business. he sometimes
do searching activities
and monitors the
uploading activities of
the Project Associate
3 Administrator People managing the Administrator
Registered Account in
the System. Can
Manage his own
Account by updating his
user details and user
password
117
Use Case Catalogue
The table below shows the Use Case Details and Descriptions.
Table 40: Use Case Catalogue

ID No. Use Case Brief Description
UA-1 Identify Self PA, CEO and Adminstrator Log In.

Provide option for CEO and PAs if not
yet registered.
UA-2 Register Account Register a new Account for the PAs
and CEO.
UA-3 Manage Account PA, CEO and Adminstrator manage
Account. Update their user details and
user password. To update Password,
the current password must be entered
and confirmed correctly.
UB-4 Search Through Search, Preview or Download CV.
CVs Searching can be via Last Name,
Search Tag or Word/ Phrase Match
U1-1 Upload CVs Upload CV to the storage. The Project

Associate must upload unique files.
U1-2 Edit Detail of The Project Associate can edit the

Uploaded CV detail of an uploaded CV.
U2-1 View Uploading The CEO can generate reports to

Reports monitor the uploading activities of the
Project Associates
U3-1 Manage User The administrator can activate or

Accounts deactivate a user account which has
been registered.
118
Activity Diagrams
1. Manage Account: (UC- UA-3)
Figure 15: Manage Account Activity Diagram
2. Search through CVs: (UC – UB -4)
Figure 16: Search through CVs Activity Diagram
119
3. Upload CV: (UC – U1-1)
Figure 17: Upload CV Activity Diagram
4. Edit Detail of Uploaded CV: (UC- U1-2)
Figure 18: Edit Detail Uploaded Activity Diagram
120
5. View Upload Reports: (UC – U2 - 1)
Figure 19: View Upload Reports Activity Diagram
6. Manage User Accounts: (UC – U3-1)
121
Figure 20: Manage User Accounts Activity Diagram
Sequence Diagrams
1. Manage Account: (UC- UA-3)
Figure 21: Manage Account Sequence Diagram
2. Search through CVs: (UC – UB -4)
122
Figure 22: Search through CVs Sequence Diagram
3. Upload CV: (UC – U1-1)
Figure 23: Upload CV Sequence Diagram
123
4. Edit Detail of Uploaded CV: (UC- U1-2)
Figure 24: Edit detail of Uploaded CV Sequence Diagram
5. View Upload Reports: (UC – U2 - 1)
Figure 25: View Upload Reports Sequence Diagram
124
6. Manage User Accounts: (UC – U3-1)
Figure 26: Manage User Accounts Sequence Diagram
9.2.6 Specific Requirements
USE CASE Diagrams
Functional Requirements
The table below shows the functional requirements for the product.
Table 41: Functional Requirements
D Requirement References
No.
1 All users must be asked first to enter user UC UA -1
name and password to enter the system
2 All users must be allowed to register an UC UA - 2
account
125
3 All users must be allowed to update their UC UA– 3 ,
User Account details and User Password Activity Diagram #
1 and Sequence
Diagram # 1
4 The Project Associate and the CEO must UC UB-4, Activity
be allowed to search through the uploaded Diagram #2 and
CVs using Last Name, Search tags and Sequence Diagram
Word/Phrase Matches #2
5 The Project Associate must be allowed to UC UB-4, Activity
preview and download searched CVs Diagram #2 and
Sequence Diagram
#2
6 The Project Associate must be allowed to UC U1- 1, Activity
Upload CV/s Diagram #3 and
Sequence Diagram
#3
7 The Project Associate must be allowed to UC U1- 1, Activity

preview files before uploading Diagram #3 and
Sequence Diagram
#3
8 The Project Associate must be allowed to UC U1-2, Activity

edit the details of their uploaded CVs Diagram #4 and
Sequence Diagram
#4
9 The CEO must be allowed to view UC U2-1, Activity
different reports about the Uploading Diagram #5 and
activities of The Project Associates Sequence Diagram
#5
10 The Administrator must be allowed to UC U3 -1 , Activity
manage User Account Status (Activate or Diagram #6 and
Deactivate) Sequence Diagram
#6
Data Requirements
126
Entity Relationship Diagram
Figure 27: Data Requirements
Database Design
127
Figure 28: Database Design
Business Rules
The table below shows the business rules of the company
Table 42: Business Rules

UC UA - 2
ID Business Rules Applies to. .
No.
1 User Account name must be consisted with the First Name and Users Table
the Last Name of the employee (Ex. SamSmith)
2 The user password must be a minimum of 6 alpha- numeric Users Table
characters
UC U1-1
1 The Project Associate cannot upload identical CVs Uploads

Table,
Activities
Table
UC U1 -2
1 The Project Associate cannot upload identical CVs Uploads
Table,
Activities
Table
UC U3-1
1 The User accounts status can be classified as Deactivated or UsersTable
Activated
128
Requirements
The table below shows the different metrics that the product must successfully pass on.
Table 43: Product Requirements

Project Objectives Metric Measure Target
Usability elements
Total actual response time of all 2 - 5
processes seconds
Number of processes
Efficiency
Total handled transactions per second > 4
Transactio
n
Total attributes of software that bear < 1.00%

on frequency of failures
3. Improve response
time by 40% to Total faults in the software
client Reliability Total software faults per module < 1.00%
requirements by Total software processes per module
reducing
searching time Total recovery time <1
over collected Standard recovery time
CVs to increase
revenue.
per module
Functionali module
ty Total successful interaction with the 95%
database
129
Total number of successful access of 0%
unregistered users
Total recovery time <1
Reliability
4. Provide a single Total data retrieval in seconds of all 2 - 5
centralized processes per module seconds
Efficiency
storage for the Total process per module
CVs collected
over time
Functionali unregistered users
ty
Usability elements
Total actual response time of all 2 - 5
processes seconds
Number of processes
Efficiency
Total handled transactions per second > 4
Transactio
n
Total attributes of software that bear < 1.00%
3. Allow the CEO to on frequency of failures
monitor CV Total faults in the software
uploading activities
(to the centralized Reliability Total software faults per module < 1.00%
storage) by project Total software processes per module
associate, duration Total recovery time <1
or both in real-time.
per module
130
Functionali module
ty Total successful interaction with the 95%
database
unregistered users
131
Glossary
Candidate - A certain person possible for a Job
Client Requirement - Job Vacancy from a client that CFMCI needs to fill
in
Project Associate – Employees in-charge of finding a possible candidate

for a client requirement
Activate – Registered User Account Status allowed to Log In

to the System
Deactivate - Registered User Account Status NOT allowed to

Log In to the System
Acronyms and Abbreviations
CFMCI – Collar Finder Management Consultancy Inc.
CFMCIMS – Collar Finder Management Consultancy Inc.

Management System
CV – Curriculum Vitae
PA – Project Associate
CEO – Chief Executive Officer
132
APPENDIX
Table 43: List of Prototype Functionalities

ID Requirement References
No.
1 All users must be asked first to enter user name and UC UA -1
password to enter the system
2 All users must be allowed to register an account UC UA - 2
3 All users must be allowed to update their User Account UC UA– 3 , Activity
details and User Password Diagram # 1 and
Sequence Diagram #
1
4 The Project Associate and the CEO must be allowed to UC UB-4, Activity
search through the uploaded CVs using Last Name, Diagram #2 and
Search tags and Word/Phrase Matches Sequence Diagram #
2
5 The Project Associate must be allowed to preview and UC UB-4, Activity
download searched CVs Diagram #2 and
Sequence Diagram #
2
6 The Project Associate must be allowed to Upload CV/s UC U1- 1, Activity
Diagram #3 and
Sequence Diagram #
3
7 The Project Associate must be allowed to preview files UC U1- 1, Activity

before uploading Diagram #3 and
Sequence Diagram #
3
8 The Project Associate must be allowed to edit the details UC U1-2, Activity
of their uploaded CVs Diagram #4 and
Sequence Diagram #
4
133
9 The CEO must be allowed to view different reports about UC U2-1, Activity
the Uploading activities of The Project Associates Diagram #5 and
Sequence Diagram #
5
10 The Administrator must be allowed to manage User UC U3 -1 , Activity
Account Status (Activate or Deactivate) Diagram #6 and
Sequence Diagram #
6
134
9.3 APPENDIX C – Project Methodology
• INITIATION

• PLANNING

• EXECUTION

• MONITORING AND CONTROL
Figure 29: Waterfall Approach
The project will follow a waterfall approach wherein it will be consist of the following
steps
1. Initiation
This is the start of the project, and the goal of this phase is to define the project in a
high level. This begun with a business case. This is where the research and proving
has been done. It is classified in this stage that the project must be undertaken.
Important stakeholders have their due diligence to help decide if the project is for
“go”. It is also when the project charter has been accomplished. The project charter
outlines the purpose and requirements of the project. This has included the business
needs, stakeholders and the business case.
135
2. Planning
This is a very crucial part of the approach since this focuses on developing a
roadmap that everyone must follow. This is where the goals have been set. The
S.M.A.R.T. method has been implemented. This method has been chosen because
this will ensure that the goals have been thoroughly vetted. It was also chosen
because it provides a way to clearly understand the implications of the goal-setting
process.
Also during this stage, the scope of the project was defined and the project
management plan was developed. Cost, quality, available resources and the realistic
time table was identified. The project plans also included establishing baselines
performance measures. These was generated through the scope, schedule and cost of
the project. The baseline has been identified because it is essential to determine if the
project is on track.
Roles and responsibilities were clearly defined. This will impose knowledge for
everyone regarding their involvement to the project and how they are accountable
for each assigned responsibility or task.
In this stage, the Scope Statement, Work Breakdown Schedule, Milestones, Gantt
Chart, Communication Plan and Risk Management Plan were made.
3. Execution
This is the phase where deliverables are developed and completed. Status reports and
meetings, development updates, and performance reports will be done here. This is
136
also were the kick-off meeting will be done to officially start the Project Execution
where the teams member are informed.
During this phase the following will be accomplished:
a. Develop Team
b. Assign resources
c. Execute project management plans
d. Procurement management
e. Direction and management from the Project manager for the project
execution
f. Task assignments
g. Status meetings
h. Update on project schedule
4. Monitoring and Control
This is where the project progression and performance will be measured. Everything
will also be ensured that they are happening aligned with the project management
plan. Key performance indicators will be defined to determine that the project is on
track.
For this project, Project Objectives, Effort and Cost Tracking and Project
Performance will be used as KPI
137
138
9.4 APPENDIX D - Product Development Methodology
• ANALYSIS

• DESIGN

• CODING

• TESTING
Figure 30: Waterfall Product Development Methodology
The Waterfall methodology—also known as the Waterfall Model—is a sequential
software development process, where progress flows steadily toward the conclusion (like
a waterfall) through the phases of a project (that is, analysis, design, coding , testing).
1. Analysis
The product development team will analyze the requirements, and fully understand the
problems. This will be a research phase that will include no building except for the
prototyping. The team attempts to ask all the questions and secure all the answers they
need to build the product requirement.
For this phase, requirements will be specified using the 4 basic steps of requirements
definition – elicitation, validation, specification, and verification.
139
Activities for each step is enlisted below:
a. Elicitation
i. One- on- One Interview wiwth Stakeholder
ii. Group Interview with the Stakeholder
iii. Prototyping
iv. Conducting a Follow people Around Elicitation Technique
b. Validation
i. Consolidating the Requirements from Elicitation
ii.Rationalizing the Requirements
iii.Modeling the Requirements(UML, Data Models, DFD)
c. Specification
i. Prioritizing the Requirements
ii.Ensuring traceability of the Requirements
iii.Ensuring Testability of the Requirements
iv.Creating Business Requirements Report
140
d. Verification
i. Requirements Review
ii. Obtaining Sponsor Sign off
During Analysis, activities like evaluating reuses, buy(rent), build alternatives, creating
requirements management plan and building conceptual Systems Design as well as
developing high level project strategies, capturing additional client information and
creating test cases will also be included.
2. Design
The analyst will design technical solutions to the problems set out by the product
requirements, including scenarios, layouts and data models. This phase will be
accompanied by documentation for each requirement, which enables other members of
the team to review it for validation.
3. Coding
First the programmers will be setting a development environment to work with. For the
software the technical implementation begins when the design has been approved. After
coding, Unit testing will be performed. Constructing miscellaneous elements of the
solution- testing environment and data, training content and implementation components
will be constructed. These steps will be accompanied by documentation.
4. Testing
141
Upon completion of full implementation, testing needs to occur before the product can be
released to customers. The software testing team will use the design documents, personas
and user case scenarios delivered by the product manager in order to perform the test
cases. Tests like regression testing, integration testing and system testing will be
performed.
142
9.5 APPENDIX E – Development Tools Specification
The table below shows the hardware needed for development
Table 44: Hardware needed for Development

Specific Detail/s Qty
Lenovo ThinkPad L430 · Intel Celeron (1.8 GHz) 2
2465 - C 1000M / 1.8 · 1 GB Memory 320 GB HDD
GHz · Intel HD Graphics 3000
· 1366 x 768
· Windows 7 Professional 64-bit
· DVD±R/RW
HPE ProLiant DL80 • Intel® Xeon® E5-2600 v4 product 1
family
• 2 Processors
• Memory: 3 TB
• 24 DIMM Slots
• DDR4
• 1Gb 331i Ethernet Adapter 4 Ports per
controller
• 2 Flex Slot
• 6 Expansion Slots
The table below shows the software needed for development
Table 45: Software needed for Development

Visual Studio For creating the app for Windows by using 2
a single IDE
HelpNDoc Easy to use yet powerful help authoring 1
environment which can generate various
documentation formats from a single source
Time Travel Tracing Traces the process of execution and allow 1
debugger to move back and forth in the
process execution time.
RegexBuddy A very useful tool in working with regular 1
expressions
143
Microsoft Office Word For documentation purposes 2
2013
Microsoft Office Excel For documentation purposes 2
2013
The table below shows the database tools needed for development
Table 46: Database Tools needed for Development

MySQL 5.7 MySQL is an open-source relational 1
database management system. It is one of
the most widely used dbms. Programmers
are literate with this.
MySQL Connector – net An extension that is needed to connect the 1
6.9.8 VB program to the dbms
144
9.6 APPENDIX F – Infrastructure Specifications
Figure 31: Infrastructure Specifications
Each end-user will be working from their work stations and will be given their own
access level. The client terminals will be connected to the server through a wired Local
Area Network to assure reliability and speed within transactions. This is a low-cost yet
effective kind of solution for the proposed system. The system will have client-based
resources and server-based database. This kind of structure has been chosen because of
the fact that the system will be process-based. Process based in the sense that data storage
and retrieval must be smoothly done and having this kind of structure will prevent too
much data traffic since the end-users are expected to engage with the system concurrently
145
9.7 APPENDIX G – Detailed Schedule
A. Gantt chart.
The tables below represents the summary of the schedule of the project.
Table 47: The Detailed Schedule of the Project
Tasks 1- 51
146
147
Tasks 51- 100
148
149
Tasks 101-141
150
151
9.8 APPENDIX H – Detailed Funding Requirements and Cost Estimates
A. Labor Cost Estimates.
The table is broken down per role, estimated number of man-hour per role, the
rate per hour and its total cost
Table 48: Labour Cost Estimates

NO. OF MAN TOTAL
LABOR COST HOUR Rate / HR COST
Roles
Project Sponsor 32.67 ₱400.00 ₱13,068.00
₱102,756.4
Project Manager 277.72 ₱370.00 0
System Analyst 460.65 ₱210.00 ₱96,736.50
Programmer 1 316.38 ₱187.50 ₱59,321.25
Programmer 2 211.17 ₱187.50 ₱39,594.38
QA Analyst 60 ₱200.00 ₱12,000.00
Tester 1 111.05 ₱100.00 ₱11,105.00
Tester 2 77.05 ₱100.00 ₱7,705.00
₱342,286.5
TOTAL 3
B. Schedule Cost Estimates.
The table shows the schedule based on the project plan. The schedule is broken
down into project phases.
Table 49: Schedule Cost Estimates
PROJECT PHASE NO. OF MAN DAYS
PROJECT MANAGEMENT 36
Project Initiation 7
152
Project Planning 10
Execution 11.5
Monitoring & Control 7.25
PM Sign-Off 0.25
EXECUTION 131.03
Analysis 22.3
Software Design 15.75
Coding 61.78
Testing 31.2
DEPLOYMENT 10
TOTAL 177.03
153
C. Hardware and Software Cost.
The table below shows the Hardware and Software costs of the project.
Table 50: Hardware and Software Costs
TOTAL
QTY UNIT UNIT PRICE COST
Software
Visual Studio 2 pcs ₱3,000.00 ₱6,000.00
HelpNDoc (Open Source) 1 pc ₱0.00 ₱0.00
Time Travel Tracing 1 pc ₱2,100.00 ₱2,100.00
RegExBuddy(Open Source) 1 pc ₱0.00 ₱0.00
Microsoft Office Word
2013(pre-installed) 2 pcs ₱0.00 ₱0.00
Microsoft Office Excel
2013(pre-installed) 2 pcs ₱0.00 ₱0.00
Hardware/Network
UTP Cable 50 meters ₱20.00 ₱1,000.00
rj45 20 pcs ₱7.00 ₱140.00
Switch 1 pc ₱500.00 ₱500.00
Router 1 pc ₱500.00 ₱500.00
Lenovo ThinkPad L430 2465 -
C 1000M / 1.8 GHz (existing) 5 pcs ₱0.00 ₱0.00
HPE ProLiant DL80
Server(existing) 1 pcs ₱0.00 ₱0.00
TOTAL ₱10,240.00
154
D. Operation Cost
The table below shows the Operations Cost of the project.

Table 51: Operation Costs
TOTAL
QTY UNIT UNIT PRICE COST
Operation Cost
Electricity (Aircon + computer 1545.
units) 08 hours ₱13.00 ₱20,086.04
TOTAL ₱21,614.71
E. Training & Effort Cost
The table below shows the Training and Effort Costs for the Project
Table 52: Training and Effort Costs
UNIT TOTAL
QTY UNIT PRICE COST
Training 4 days ₱800.00 ₱3,200.00
Effort Cost ₱20,800.00
meeting
Meetings 32 s ₱550.00 ₱17,600.00
Communications 32 weeks ₱100.00 ₱3,200.00
TOTAL ₱24,000.00
155
9.9 APPENDIX I – Risk Register
A. Risk Measurements Definition
The tables show on how to assess risk and calculate risk rating given the
following as reference.
Table 53: Risk Measurements Definition

RISK SYMBO
MEASUREMENT L DEFINITION
Severity Rating SR Impact to the Project
Probability Rating PR Probability of Potential failure to happen
B. Risk Measurements Definition – Severity Level

The table below shows the description of the Severity levels to be used in this project.
Table
C.54: Risk Measurements Definition – Severity Level
SEVERITY
LEVEL RATING DESCRIPTION
More than an hour, less than a day delay to the
Low 1 project
More than a day, less than a week delay to the

Medium 2 project
Severe 3 More than a week of delay to the project
The table below shows the Risk Frequency Probability.
Table
D.55: Risk Measurements Definition – Frequency of Occurrence
PROBABILITY RATING DESCRIPTION
Low 1 20% below probability
Moderate 2 21%- 50%
156
High 3 51% above
C. Risk Calculation
The formula to determine the risk rating is:
D. RR = SR + OR
where, RR is the Risk
Rating SR is the
Severity Rating OR is
the Occurrence Rating
D. Acceptable Level Definition
The table shows the Acceptable level of Severity and the

Frequency of happening
Table 56: Acceptable Level Definition

RISK MEASUREMENT SYMBOL RATING
Severity Rating SR 2
Occurrence Rating OR 2
This mean that risk rating with the value of 4 or less than 4 is acceptable. While risk
rating with higher value of 4 is not acceptable and those potential failures are need to be
mitigated.
157
E. Risk Register
The table below shows the risks of the project alongside with each probability,
impact, preventive action and risk assessment
Table 57: Risk Register
Milesto Targ Risk Preventive S P R Ris Risk Mitigation
ne et Action R R R k Prior
Date Asse ity
ssme
nt
Sign-off 06/10 Acquiring project Have advanced 3 2 5 Miti 2 If unavoidable,
a c q u i r e /2016 team takes longer postings on gate prioritize the
project than expected d i f f e r e n t Systems Analyst
team platforms. since it is urgent.
Then extend
acquiring of
other project
team members
up to 5 days.
Sign-off 07/04 A n u m b e r o f Communicate to 1 1 2 Acce -
P r o j e c t /2016 stakeholders are stakeholders in pt
Kickoff not available advance through
Meeting email and secure
commitment.
Reschedule
earlier if there
will be
unavailability of
stakeholders
Assigned activities Discuss scope of 2 3 5 Miti 3 Include scope of
to project team a s s i g n e d gate assigned tasks to
members may lack activities during contract
on details which kickoff meeting.
are important to the
project
S i g n - 08/08 Interview with the Prepare and 2 3 5 Miti 4 Upon realization
o f f /2016 stakeholder/s are categorize gate of a neglected
Analysis ineffective as some i n t e r v i e w requirement,
Phase requirements are questions as well s e n d
not mentioned or as follow up communication
discussed questions prior to (following the
interview. communication
escalation
process) to
stakeholder to
ask about the
requirement.
158
A number of Let interviewee 1 3 4 Acce -
business process/es enumerate all pt
was not performed b u s i n e s s
during follow processes during
people around interview. Enlist
elicitation and set as guide
during follow
people around
elicitation.
System analyst Counter check 1 3 4 Acce -
failed to specify requirements pt
details of certain versus business
requirement process.
R e q u i r e m e n t Set rubrics for 1 3 4 Acce -
prioritization was r e q u i r e m e n t pt
incorrect prioritization
scheme.
Traceability Align traceability 1 1 2 Acce -
measures are measures to pt
improper for some i n d u s t r y
a number of standards
requirements
Testability Align testability 1 1 2 Acce -
measures are measures to pt
improper for a i n d u s t r y
number of standards
requirements
Some existing Get a list of 3 1 4 Acce -
resources are not m a t e r i a l s pt
considered for the inventory from
solution the CEO.
Approval of Provide graphic 1 1 2 Acce
Requirements takes representations pt
longer than to presentations
expected and reports to
impose higher
understanding.
Sign-off 08/30 S t a n d a r d s a n d P r o v i d e 2 1 3 Acce -
D e s i g n /2016 guidelines for the guidelines first pt
Phase modules have not before designing.
been clearly
defined
The design solution Consult the MIS 3 1 4 Acce -
for the modules are department pt
inappropriate for before finalizing
the available the design
resources solutions.
159
The Project Update the 1 1 2 Acce -
Management project manager pt
Document has not regarding new
been updated details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.
Approval of Design Provide graphic 1 1 2 Acce
Solution takes representations pt
longer than to presentations
expected and reports to
impose higher
understanding.
Sign-off 08/31 Different actual Base SRP from 1 2 3 Acce -
Procure /2016 cost of materials c a n v a s s i n g pt
ment f r o m s u g g e s t e d activity.
retail prices
Sign-off 11/28 D e l a y o n t h e Programmer 2 3 3 6 Miti 1 Have the absent
Constru /2016 coding process and must be always gate programmer
ct Phase constructing i n f o r m e d make up
implementation r e g a r d i n g absences through
components progress of weekends
because of an Programmer 1
emergency from
one of the
programmers
Too many errors/ Unit Test after 3 1 4 Acce -
bugs have been every function to pt
detected during p r e v e n t
Unit testing cumulative bugs.
P r o j e c t Update the 1 1 2 Acce -
management Plan project manager pt
Document has not regarding new
been updated details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.
160
T e s t i n g The quality 1 1 2 Acce -
Environment and analyst must pt
data is ensure that the
inappropriate with t e s t i n g
the designed environment and
solution data is
appropriate by
reviewing versus
the business
process and
i n d u s t r y
standards.
Sign-off 1/12/ R e s o l v i n g b u g s Report bugs as 3 2 5 Miti 5 Have 2
T e s t 2017 takes longer than s o o n a s t h e y gate programmers
Phase expected have been work for a bug
detected
Testing Metrics are Testing metrics 2 2 4 Acce -
incomplete must be pt
coordinated to
the project
manager and
system analyst to
e n s u r e
appropriateness
a n d
completeness
Fixing defects/ Fix defects/ 3 2 5 Miti 6 Have 2
errors/bugs takes errors/bugs as gate programmers
longer than soon as they are work for a bug
expected reported
Sign-off 1/10/ R e v i e w s a n d Prepare all things 2 2 4 Acce -
Quality 2017 Audits took longer needed before pt
Assuran than expected Reviews and
ce Audits to save
time.
Project Sponsor is Provide email 1 2 3 Acce -
not available for report. Proceed pt
the meeting of the through video
Audit Activity or conferencing if
Close Audit possible or video
recording as last
option.
Sign-off 1/12/ UAT takes longer Let users test 2 2 4 Acce -
Quality 2017 than expected through cross pt
Control examining versus
d e f i n e d
requirements and
quality measures
161
Sign-off 1/26/ End users have Provide 15 3 2 5 Miti 7 Provide CBT
Impleme 2017 l o n g e r l e a r n i n g v a r i a t i o n gate materials so
ntation curve than examples of users can review
Phase expected transactions per things at home
module. Discuss
their concerned
modules only
Training materials P r o v i d e 1 1 2 Acce -
are inadequate additional pt
t r a i n i n g
materials(Total
numbers of
trainee + (Total
numbers of
trainee * 20% ))
User Support Update the 1 1 2 Acce -
Documentation has project manager pt
not been updated regarding new
details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.
Sign-off 1/27/ Unavailability of Send emails 5 1 1 2 Acce -
P r o j e c t 2017 stakeholders for the days before close pt
Manage project close out out and secure
ment confirmation. If
inevitable,
reschedule to an
earlier time.
A p p r o v a l t a k e s Provide graphic 1 2 3 Acce
l o n g e r t h a n representations pt
expected to presentations
and reports to
impose higher
understanding.
162

Sample Capstone Project

Uploaded by

Copyright:

Available Formats

Sample Capstone Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample Capstone Project

Uploaded by

Copyright:

Available Formats

Collar Finder Management Consultancy Inc.

Curriculum Vitae Management System

A Project Development Plan

In Partial Fulfillment of the

JAN LUDVIK B. RANESES

Thank you very much.

-JAN LUDVIK BALBOA RANESES, MIT

1.1 Project Name

Collar Finder Management Consultancy Inc. Curriculum Vitae Management System

1.2 Project Description

CFMCI is an organization which aims for convenience, efficiency and consistency

of the total response time is being spent in reviewing collected CVs.

whole organization in implementing executive search activities wherein CV review

1.2.1 Business Objectives

1. Increase annual revenue by 20%

2. Improve response time to client requirements by 10% every year.

1.2.2 Business Case

Details of Cost – Benefit Analysis in Appendix A.

1.2.3 Project Objectives

1. Improve response time by 40% to client requirements by reducing

searching time over collected CVs to increase revenue.

3. Allow the CEO to monitor CV uploading activities (to the centralized

storage) by project associate, duration or both in real-time.

1.2.4 Project Success Criteria

Key Area Criteria

6. 5. The number of residual defects does not exceed to 3

1.3 Project Completion Date

February 29, 2017

1.4 Project Budget

The table below is the summarized Project Budget.

Table 1: Summary of the Project Budget

Total Cost Php 448,172.20

The CEO of the Collar Finder Management Consultancy Inc.

1.6 Project Key Deliverables

Table 2: Project Key Deliverable per Project Phase

2.1 Key Terms

1. Curriculum Vitae - a brief account of a person's education, qualifications, and

previous experience, typically sent with a job application.

2. Project Associate – the personnel in-charge of finding possible human

resource match/es to client requirements

3. CEO – the owner and the top executive of CFMCI

CFMCICVMS, he has the capability to activate or deactivate a certain user

1. CFMCI - Collar Finder Management Consultancy Inc.

2. CFMCICVMS - Collar Finder Management Consultancy Inc. Curriculum

Vitae Management System

6. CCB – Change Control Board

7. CMDB – Change Management Database

8. PMI – Project Management Institute

3.0 Project Scope

3.1 Product Characteristics / Requirements

The table below shows the product features description.

Table 3: Product Features

1.1 User Registration

1.3 User Detail Update

1.4 Administrator interface for activating and

4 an interface for editing the details of the uploaded

3.2 Product Acceptance Criteria

• 95% of product-related deliverables has been delivered within schedule.

d. Deployment Plan Review