Planning Document ResearchColab
Team: Reckless 7
1
Contents 1. Project Summary .................................................................................................................................... 3
2. Methodology ............................................................................................................................................ 3
3. Work Breakdown Structure and estimates .......................................................................................... 4
4. Sequence of Activity ................................................................................................................................ 5
5. Timeline ................................................................................................................................................... 6
6. Human Resource Management.............................................................................................................. 6
6.1 Roles and Responsibilities ................................................................................................................ 7
6.3 Project Organizational Charts ....................................................................................................... 10
6.4 Staffing Management ...................................................................................................................... 11
7. Procurement Management ................................................................................................................... 11
7.1 Procure Management Approach ................................................................................................... 11
7.2 Procurement Definition .................................................................................................................. 12
7.3 Type of Contract to be used ........................................................................................................... 12
7.4 Procurement Risks .......................................................................................................................... 12
7.5 Procurement Risk Management .................................................................................................... 12
7.6 Cost Determination ......................................................................................................................... 13
7.7 Procurement Constraints ............................................................................................................... 13
7.8 Contract Approval Process ............................................................................................................ 14
7.9 Decision Criteria ............................................................................................................................. 14
7.10 Vendor Management .................................................................................................................... 15
8. Risk Management ................................................................................................................................. 15
8.1 Risk Identification ........................................................................................................................... 15
8.3 Risk Qualification and Prioritization ............................................................................................ 16
8.4 Risk Monitoring .............................................................................................................................. 16
8.5 Risk Mitigation and Avoidance ..................................................................................................... 17
8.6 Risk Register.................................................................................................................................... 17
9. Configuration Management ................................................................................................................. 18
9.1 Roles and Responsibilities .............................................................................................................. 18
9.2 Configuration Control .................................................................................................................... 19
9.3 Configuration Status Accounting .................................................................................................. 19
9.4 Change Request Form .................................................................................................................... 20
10. Communication Plan .......................................................................................................................... 22
2
10.1 Communications Management Approach .................................................................................. 22
10.2 Communications Management Constraints ............................................................................... 22
10.3 Stakeholder Communication Requirements .............................................................................. 23
10.4 Roles ............................................................................................................................................... 23
10.5 Communication Methods and Technologies ............................................................................... 25
10.6 Communications Matrix .............................................................................................................. 26
10.7 Guidelines for Meetings ................................................................................................................ 27
11. Change Management .......................................................................................................................... 27
11.1 Change Management Approach .................................................................................................. 27
11.2 Definitions of Change ................................................................................................................... 28
11.3 Change Control Board ................................................................................................................. 29
11.4 Roles and Responsibilities ............................................................................................................ 30
11.5 Change Control Process ............................................................................................................... 30
11.6 Change Management Log ............................................................................................................ 31
11.7 Change Management log format ................................................................................................. 33
12. Quality Assurance ............................................................................................................................... 33
12.1 Quality Management Approach .................................................................................................. 33
12.2 Quality Requirements / Standards .............................................................................................. 34
12.3 Quality Assurance ......................................................................................................................... 35
12.4 Quality Control Measurements ................................................................................................... 36
13. Release .................................................................................................................................................. 37
14. Budget .................................................................................................................................................. 38
14.1 Measuring Project Costs .............................................................................................................. 38
14.2 Reporting Format ......................................................................................................................... 38
14.3 Cost Variance Response Process ................................................................................................. 39
14.4 Cost Change Control Process....................................................................................................... 39
14.5 Project Budget ............................................................................................................................... 39
3
1. Project Summary Software Project Management course teacher has recently approved the Researchcolab.com
project to move forward for project initiation as an academic project. This project will result in
the development of a research collaboration and data collection’s web based platform. It will
perform this features through review management, data sharing, idea discussion and profiles
management. This project will result in greater acceptability of researcher’s work by performing
an extensive manuscript review. Expert reviewer will investigate every research element of
researcher’s paper, such as soundness of study design, reporting of method, significance to field,
ethical soundness, and sufficiency of data analysis. They’ll also provide a detailed check of journal
compatibility to minimize chances of rejection.
2. Methodology The requirements and solutions of this project evolve through collaboration between a cross-
functional teams. Agile software development process is best suite in this scenario and will be
followed in this project. To control the project coordination and continuous improvement the
scrum process will be followed. The team members will have meetings in regular interval and
discuss about their progress and difficulties they will face.
We have formed our team with seven members. The team will be working for a real life project
for approximately four months. To reach optimum goal, the whole activities within the project are
divided into many tasks and the members are assigned to that specific task. Though there are many
tasks need to be done within four months and some of our team members are efficient enough to
work, we have selected the best person to play the role in the team. Some of our members are
assigned to multiple tasks but they have their own special role for the project. The following table
contains name of the team members and project responsibilities that are assigned to that person.
Name of the member Assigned task
Md. Adiluzzaman Adil Project Management
Minhas Kamal System Analysis
Kishan Kumar Ganguly Development
Md. Rakib Hossain Quality Assurance
Mostaque Ahmed Documentation
A.H.M. Azimul Haque Communication & Collaboration
Israt Fatema Shantu Documentation
4
3. Work Breakdown Structure and estimates The WBS for this project is shown in the table below.
Level 1 Level 2 Level 3 Milestones Date
1 Researchcolab
1.1 Initiation 1.1.1 Evaluation & Recommendations 1.1.2 Develop Project Charter 1.1.3 Deliverable: Submit Project Charter 1.1.4 Project Sponsor Reviews Project Charter 1.1.5 Project Charter Signed/Approved
Project Defined
and Initiation
Performed
30 Sep, 2016
16 Oct, 2016 19 Oct, 2016
20 Oct, 2016
29 Oct, 2016
1.2 Planning 1.2.1 Create Preliminary Scope Statement 1.2.2 Determine Project Team 1.2.3 Project Team Kickoff Meeting 1.2.4 Develop Project Plan 1.2.5 Submit Project Plan 1.2.6 Milestone: Project Plan Approval
Scope and Plan
Described 30 Oct, 2016
1 Nov, 2016 2 Nov , 2016 2 Nov , 2016 3 Nov , 2016 3 Nov , 2016
1.3 Execution
1.3.1 Project Kickoff Meeting 1.3.2 Verify & Validate User Requirements 1.3.3 Design System 1.3.4 Procure Hardware/Software 1.3.5 Install Development System 1.3.6 Testing Phase 1.3.7 Install Live System 1.3.8 User Training 1.3.9 Go Live
Execution
Performed 4 Nov, 2016 6 Nov, 2016
8 Nov, 2016 11 Nov, 2016 12 Nov, 2016 15 Nov, 2016 16 Nov, 2016 17 Nov, 2016 17 Nov, 2016
1.4 Control 1.4.1 Project Management 1.4.2 Project Status Meetings 1.4.3 Risk Management 1.4.4 Update Project Management Plan
Project
Documents
Updated
17 Nov, 2016
18 Nov, 2016 17 Nov, 2016 18 Nov, 2016
1.5 Closeout 1.5.1 Audit Procurement 1.5.2 Document Lessons Learned 1.5.3 Update Files/Records 1.5.4 Gain Formal Acceptance 1.5.5 Archive Files/Documents
Project Complete
18 Nov, 2016 18 Nov, 2016 18 Nov, 2016 19 Nov, 2016 19 Nov, 2016
5
4. Sequence of Activity
1 Researchcolab
1.1 Initiation
1.1.1 Evaluation & Recommendations
1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project
Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
1.2 Planning
1.2.1 Create Preliminary Scope
Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan
Approval
1.3 Execution
1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development
System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Control
1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan
1.5 Closeout
1.5.1 Audit Procurement
1.5.2 Document Lessons Learned
1.5.3 Update Files/Records
1.5.4 Gain Formal Acceptance
1.5.5 Archive Files/Documents
6
5. Timeline
2016
2016
Sep
Oct
No
v
9/3
0/2
01
6 -
10
/15
/20
16
Evaluatio
n &
R
ecom
me
nd
ation
s 10/16/2016
- 1
0/1
8/2
01
6
Develo
p P
roject
Ch
arter 1
0/1
9/2
016
- 1
0/2
0/2
016
Deliverab
le: Sub
mit
Pro
ject Ch
arter 10/20/2016
- 10/28/2016
Pro
ject Spo
nso
r Review
s P
roject C
harter
10/29/2016
Pro
ject Ch
arter Sign
ed/A
pp
roved
10/30/2016
- 11/1/2016
Create P
relimin
ary Scop
e Statem
ent
11/2/2016
Determ
ine
Pro
ject Team
11/2/2016
Pro
ject Team K
ickoff
Meetin
g
11/2/2016
Develo
p
Pro
ject Plan
11/3/2016
Sub
mit
Pro
ject Plan
11/3/2016
Milesto
ne: P
roject P
lan
Ap
pro
val 11/4/2016
- 11/5/2016
Pro
ject Kicko
ff M
eeting
11/6/2016 -
11/7/2016
Verify &
Valid
ate User
Re
qu
iremen
ts 11/8/2016
- 11/10/2016
Design
System
11/11/2016
Pro
cure
Hard
ware/So
ftware
11/12/2016
- 11/15/2016
Install D
evelop
me
nt
System
11/15/2016
Testing
Ph
ase
11
/16
/2
01
6
Install Live
System
11/17/2016
User
Trainin
g
11/17/2016
Go
Live
11/17/2016
Pro
ject M
anagem
en
t 11/18/2016
Pro
ject Status
Meetin
gs 11/17/2016
Risk
Man
ageme
n11/18/2016
Up
date P
roject
Man
ageme
nt P
lan
11/18/2016
Au
dit
Pro
curem
en
t 11/18/2016
Do
cum
en
t Lesso
ns
Learn
ed
11/18/2016
Up
date
Files/Reco
rds
11/19/2016
Gain
Form
al A
cceptan
ce
11/19/2016
Arch
ive Files/D
ocu
men
ts
7
6. Human Resource Management The purpose of the Researchcolab Human Resource Plan is to achieve project success by ensuring
the appropriate human resources with the necessary skills are acquired, resources are trained if any
gaps in skills are identified, team building strategies are clearly defined, and team activities are
effectively managed. If used effectively, this plan will serve as a tool to aid in the management of
this project’s human resource activities throughout the project until closure.
This human resources management plan includes:
Roles and responsibilities of team members throughout the project
Project organization charts
Staffing management plan
6.1 Roles and Responsibilities
Project Team roles and responsibilities:
All team members must clearly understand their roles and responsibilities in order to successfully
perform their portion of the project. Listed below are the roles and responsibilities for the
Researchcolab.com project team:
Project Manager (1 position) –
Responsible for all management for the Researchcolab.com Project.
Responsible for planning, creating, and/or managing all work activities, variances, tracking,
reporting, communication, staffing, and internal coordination with course coordinator.
Designer (1 position)
Responsible for all design and analysis of the Researchcolab.com project.
The designer will assist the implementation work in the distribution and monitoring of the
Researchcolab.com.
8
Programmer (1 position) –
Responsible for coding and programming for the Researchcolab.com Project.
Responsible for risk identification, determining impacts of change and configuration change
requests, and status reporting.
Must be proficient in programming Language: C#, Platform: ASP.NET, Framework: MVC,
Backend: ASP.NET MVC Entity Framework Code First, Frontend: Razor , Database:
SQLServer.
Quality Assurer (1 position) –
Responsible for assisting the Project Manager in creating and tracking quality control and
assurance standards.
Responsible for maintaining quality control and assurance logs, and configuration
management throughout the project.
Technical Writer (1 position) –
Responsible for compiling all project documentation and reporting into standard organizational
formats.
Responsible for assisting the Project Manager in Configuration Management and revision
control for all project documentation.
Testing Specialist (1 position) –
Responsible for helping establish testing specifications for the Researchcolab.com Project with
the assistance of the Programmers.
Responsible for ensuring all testing is complete and documented.
Responsible for ensuring all testing resources are coordinated.
Trainer and communication Lead (1 position)-
Identify team member with skills need for project roles.
9
Identify & schedule necessary training for team members within IIT.
Schedule necessary recreation as motivation purpose for project team members.
Responsible for writing duties during all project meetings and maintaining all project
communication distribution lists.
Project Stakeholders Roles & Responsibilities
Listed below are the roles and responsibilities for the Researchcolab.com project stakeholders:
Project Sponsor
Provides vision, direction, and policy leadership for the project
Assists in removing barriers and supports change management initiatives
Participates in the Steering Committee, and provides support to this group as needed
Has overall authority for the project
Responsible for ensuring that deliverables and functionality are achieved as defined in the Project
Charter and subsequent project plans
Steering Committee
Acts as the Project stakeholders group
Ensures that the deliverables and functionality of the project are achieved as defined in the project
initiation documents and subsequent project plans
Provides high-level project direction, receives project status updates, and addresses and resolves
issues, risks, or change requests
10
6.3 Project Organizational Charts
The following RACI chart shows the relationship between project tasks and team members. Any
proposed changes to project responsibilities must be reviewed and approved by the project
manager. Changes will be proposed in accordance with the project’s change control process. As
changes are made all project documents will be updated and redistributed accordingly.
Roles PM Designer Programmer Training
Leads QA
Testing
Specialist
Technical
write
Project
Sponsor
Steering
Committee
Requirements
Gathering A R R C R C I C I
Design A R C C I I C I
Coding A R R I I I
Testing A C C R R I I C
Implementation A R C I C C I C
Conduct
Training A R C C I I C
Documentation A C R I C
Key:
R – Responsible for completing the work
A – Accountable for ensuring task completion/sign off
C – Consulted before any decisions are made
I – Informed of when an action/decision has been made
11
6.4 Staffing Management
Staff Acquisition:
For the Researchcolab.com Project the project staff will consist entirely from IIT Software Project
Management class. The Project Manager will form the project team in order to identify and assign
resources. All resources including the project manager must be approved by the course teacher
before the resource may begin any project work.
Resource Calendars:
The Researchcolab.com Project is scheduled to last 3 months with 7 hours/persons per week. The
Project will require all project team members for the entire duration of the project.
Training:
There is currently no training scheduled with regards to the Researchcolab.com Project since the
project team has adequate staff (7 members) with required skill sets. However, if training
requirements are identified or there is a need for recreational activities, funding will be provided
from the project reserve.
7. Procurement Management This Procurement Management Plan sets the procurement framework for this project. It will serve
as a guide for managing procurement throughout the life of the project and will be updated as
acquisition needs change. This plan identifies and defines the items to be procured, the types of
contracts to be used in support of this project, the contract approval process, and decision criteria.
7.1 Procure 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 Project Management will then review
the procurement list prior to submitting it for contracts and purchasing. The management will
review the procurement items, determine whether it is advantageous to make or buy the items, and
begin the vendor selection, purchasing and the contracting process.
12
7.2 Procurement Definition
The following procurement items have been determined to be essential for project completion
and success.
Item/Services Justification Needed By
Laptop, 7 Pcs Needed for the project staffs to start their works 31 July, 2016
Desktop Computer,
3 Pcs
Needed for the developers to start the main
development works
15 August, 2016
Internet
Connectivity
Needed for R&D and communication 31st July, 2016
In addition to the above list of procurement items, the following individuals are authorized to
approve purchases for the project team:
Name Role Adiluzzaman Adil Project Manager
7.3 Type of Contract to be used
All items and services to be procured for this project will be solicited under firm-fixed price
contracts. The management will then solicit bids from various vendors in order to procure the
items within the required time frame and at a reasonable cost under the firm fixed price contract
once the vendor is selected.
7.4 Procurement Risks
All procurement activities carry some potential for risk which must be managed to ensure project
success. While all risks will be managed in accordance with the project’s risk management plan,
there are specific risks which pertain specifically to procurement which must be considered:
- Unrealistic schedule and cost expectations for vendors
- Supply capacity capabilities of vendors
- Configuration management for upgrades and improvements of purchased technology
- Potential delays in shipping and impacts on cost and schedule
- Questionable past performance for vendors
- Potential that final product does not meet required specifications
These risks are not all-inclusive and the standard risk management process of identifying,
documenting, analyzing, mitigating, and managing risks will be used.
7.5 Procurement Risk Management As previously stated, project risks will be managed in accordance with the project’s risk
management plan. However, for risks related specifically to procurement, there must be additional
consideration and involvement. Project procurement efforts involve external organizations and
13
potentially affect current and future business relationships as well as internal supply chain and
vendor management operations. Because of the sensitivity of these relationships and operations
the project team will include the project sponsor and a designated representative from the
contracting department in all project meetings and status reviews.
7.6 Cost Determination For this project we will issue a Request for Proposal (RFP) in order to solicit proposals from
various vendors which describe how they will meet our requirements and the cost of doing so. All
proposals will include vendor support for items A, B, and C (from procurement definition
paragraph) as well as the base and out-year costs. The vendors will outline how the work will be
accomplished, who will perform the work, vendors’ experience in providing these goods, customer
testimonials, backgrounds and resumes of employees performing the work, and a line-item
breakdown of all costs involved. Additionally, the vendors will be required to submit work
breakdown structures (WBSs) and work schedules to show their understanding of the work to be
performed and their ability to meet the project schedule.
All information must be included in each proposal as the proposals will be used as the foundation
of our selection criteria. Proposals which omit solicited information or contain incomplete
information will be discarded from consideration.
7.7 Procurement Constraints There are several constraints that must be considered as part of the project’s procurement
management plan. These constraints will be included in the RFP and communicated to all vendors
in order to determine their ability to operate within these constraints. These constraints apply to
several areas which include schedule, cost, scope, resources, and technology:
Schedule:
Project schedule is not flexible and the procurement activities, contract administration, and
contract fulfillment must be completed within the established project schedule.
Cost:
Project budget has contingency and management reserves built in; however, these reserves
may not be applied to procurement activities. Reserves are only to be used in the event of an
approved change in project scope or at management’s discretion.
Scope:
All procurement activities and contract awards must support the approved project scope
statement. Any procurement activities or contract awards which specify work which is not in
14
direct support of the project’s scope statement will be considered out of scope and
disapproved.
Resources:
All procurement activities must be performed and managed with current personnel. No
additional personnel will be hired or re-allocated to support the procurement activities on this
project.
Technology:
Parts specifications have already been determined and will be included in the statement of
work as part of the RFP. While proposals may include suggested alternative material or
manufacturing processes, parts specifications must match those provided in the statement of
work exactly.
7.8 Contract Approval Process The first step in the contract approval process is to determine what items or services will require
procurement from outside vendors. This will be determined by conducting a cost analysis on
products or services which can be provided internally and compared with purchase prices from
vendors. Once cost analyses are complete and the list of items and services to be procured
externally is finalized, the purchasing and contracts department will send out solicitations to
outside vendors. Once solicitations are complete and proposals have been received by all vendors
the approval process begins. The first step of this process is to conduct a review of all vendor
proposals to determine which meet the criteria established by the project team and the
management. Purchases less than BDT 50,000/= only require the approval of the Project Manager;
whereas, purchases greater than BDT 50,000/= must be approved by the management. For these
larger purchases the management will meet to determine which contract will be accepted.
7.9 Decision Criteria
The criteria for the selection and award of procurement contracts under this project will be based
on the following decision criteria:
- Ability of the vendor to provide all items by the required delivery date
- Quality
- Cost
- Expected delivery date
- Comparison of outsourced cost versus in-sourcing
- Past performance
These criteria will be measured by the contracts review board and/or the Project Manager. The
ultimate decision will be made based on these criteria as well as available resources.
15
7.10 Vendor Management
The Project Manager is ultimately responsible for managing vendors. In order to ensure the timely
delivery and high quality of products from vendors the Project Manager will meet weekly with
each vendor to discuss the progress for each procured item. The meetings can be in person or by
teleconference. The Project Manager will be responsible for scheduling this meeting on a weekly
basis until all items are delivered and are determined to be acceptable.
8. Risk Management
Risk is inevitable in a business organization when undertaking projects. However, the project
manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided between
two types, negative impact risk and positive impact risk. The project manager will plan their
strategy based on four steps:
Risk Identification
Risk Quantification
Risk Response
Risk Monitoring and Control
8.1 Risk Identification
The category of risks identification is listed below-
1. General Risk:
a) The project may not be completed within deadline
b) The project may fail to maintain its budget
c) Poor project planning
d) Academic study may hinder the progress of this project
e) Project milestones are not defined clearly
f) Ineffective project management
g) Monitoring the progress of this project is not done properly
h) Inadequate estimation of required resources
i) Poor communication among the project members
j) Individual member might fail to meet his/her deadline.
16
2. Subject oriented risk:
i. Development oriented –
a. Developers do not have the specialized skills needed for this project
b. Insufficient knowledge about the new technology required by the project
c. The technology used in the project is outdated
ii. Testing oriented –
a. The testing of this project might not be done properly
iii. Design oriented –
a. The problem can exist in the design phase
iv. Quality control oriented –
a. The quality of the project is not up to mark
b. The system may fail during its execution
8.3 Risk Qualification and Prioritization 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.
8.4 Risk Monitoring
Regular monitoring and review of risks is an important part of the ReasearchColab program. It
ensures that new risks are; detected; added to the Risk Register, managed and that action plans are
implemented and progressed effectively. The ReasearchColab monitoring and review strategies
include:-
Risk management will be a stander topic of discussion in the monthly board project
meeting. This agenda will cover the review of risk register and its update information.
The Project Manager will monitor day-to-day progression of Risk Management Action
plans.
17
8.5 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.
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.
8.6 Risk Register The Risk Register for this project is a log of all identified risks, their probability and impact to the
project, the category 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 assign a risk manager to ensure adherence to the agreed upon mitigation
strategy. The each risk manager will provide the status of their assigned risk at the bi-weekly
project team meeting for their risk’s planned timeframe.
Severity and likelihood of the risks will be scaled in the following ways-
Categorized Harm Severity Severity Level Risk
Normal 1 Very Low
Negligible 2 Low
Marginal 3 Moderate
Critical 4 High
Catastrophic 5 Extreme
18
The likelihood category will be defined as follows:
Likelihood Category Likelihood Level
Less Likely 1
Likely 2
Very Likely 3
9. Configuration Management In order to effectively manage the Reserchcolab.com Project, a coordinated Configuration
Management (CM) Plan is needed. This plan will establish CM roles and responsibilities and
describe how the Reserchcolab.com Project team will track, implement, and communicate
configuration items (CIs) and changes throughout the project lifecycle.
9.1 Roles and Responsibilities
The following roles and responsibilities involve to the CM Plan for Researchcolab.com Project.
Configuration Control Board (CCB)
The CCB is comprised of the Researchcolab.com Project Sponsor, Project Manager and Quality
Assurer. The CCB is responsible for the following:
Review and approve/reject configuration change requests
Ensure all approved changes are added to the configuration management log.
Seeking clarification on any CIs as required
Project Manager
The Project Manager is responsible for:
Overall responsibility for all CM activities related to the Researchcolb.com project
Identification of CIs
All communication of CM activities to project team
Participation in CCB meetings
Re-baselining, if necessary, any items affected by CM changes
19
Quality assurer
The Configuration Manager is responsible for:
Overall management of the Configuration change
Identification of CIs
Providing configuration standards and templates to the project team
All identified CIs will be assigned to a right job.
Ensure all change requests comply with change request templates and standards prior to
the CCB
9.2 Configuration Control
The Researchcolab.com Project will use a standardized configuration control process throughout
the project lifecycle in order to ensure all CIs are handled in a consistent manner and any approved
changes are fully reviewed regarding impact and communicated to project team.
Any configuration changes which are identified by the project team 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.
As CIs are identified by the project team, the Configuration Manager will assign a CI name and
the CI will be then assigned to the concern person. It is necessary that for any software changes,
testing is conducted by the testing specialist in order to validate any changes made.
9.3 Configuration Status Accounting
It is important that for the Researchcolab.com 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 Saturday. These reports will consist of the following
information as part of the configuration status section:
20
1) Change requests
a. Aging - How long change requests have been open
b. Distribution – number of change requests submitted by project team
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
Prior to the final implementation, the CM will work with project team to ensure all CIs are updated
with latest release versions.
9.4 Change Request Form
Name and location of Individual
Submitting Request
Machine ID
Date and time
Type of Change Request (i.e.
software, hardware, problem
report)
21
Description of the Change
Requested
Is this an “Error” or
“Enhancement?”
Severity Level H: Hinder Operations. No Work
Around exists.
HM: Hinder Operations. An
acceptable Work Around exists
ML: Does not hinder operations.
No acceptable Work Around
exists.
L: Does not hinder operations. An
acceptable Work Around exists.
Date Needed
Who developed and is
maintaining the application
Name of
application
Is this a Software or Hardware
modification?
Operational Context What was occurring when this
happened?
How can this be recreated (if
possible)?
Describe the frequency of
occurrence.
22
10. Communication Plan This Communications Management Plan sets the communications framework for this project. It
will serve as a guide for communications throughout the life of the project and will be updated as
communication needs change. This plan identifies and defines the roles of persons involved in
this project. It also includes a communications matrix which maps the communication
requirements of this project.
10.1 Communications 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.
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 team members/stakeholders remain aware
and informed of any changes to communications management.
10.2 Communications 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
23
schedule constraints. Any deviation of these timelines may result in excessive costs or schedule
delays and must be approved by the project sponsor.
10.3 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.
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 secure means or through internal
project resources, all stakeholders must have the necessary access to receive project
communications.
10.4 Roles
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.
Stakeholders
Normally Stakeholders includes all individuals and organizations who are impacted by the project.
For this project, we are defining the stakeholders with whom we need to communicate with and
are not included in the other roles defined in this section. The stakeholders include executive
management with an interest in the project and key users identified for participation in the project.
Customer
24
The customer for this project is the Software Project Management course teacher, Ajmal Huda.
As the customer who will be accepting the final deliverable of this project, he will be informed of
the project status including potential impacts to the schedule for the final deliverable and the
product itself.
Project Manager
The Project Manager has overall responsibility for the execution of the project. The Project
Manager manages day to day resources, provides project guidance and monitors and reports on the
project. The Project Manager is the primary communicator for the project distributing information
according to this Communications Management Plan.
Project Team
The Project Team is comprised of all persons who have a role performing work on the project.
The project team needs to have a clear understanding of the work to be completed and the
framework in which the project is to be executed. Since the Project Team is responsible for
completing the work for the project they played a key role in creating the Project Plan including
defining its schedule and work packages. The Project Team requires a detailed level of
communications which is achieved through day to day interactions with the Project Manager and
other team members along with weekly team meetings.
Technical Lead
The Technical Lead is a person on the Project Team who is designated to be responsible for
ensuring that all technical aspects of the project are addressed and that the project is implemented
in a technically sound manner. The Technical Lead is responsible for all technical designs,
overseeing the implementation of the designs and developing as-build documentation. The
Technical Lead requires close communications with the Project Manager and the Project’s other
Team members.
25
10.5 Communication Methods and Technologies
The project team will determine the communication methods and technologies based on several
factors to include: stakeholder and project’s team members’ communication requirements and
available technologies.
Researchcolam.com project maintains a Shared web platform, a closed group account on Facebook
which all project team members use to provide updates, archive various documents, access project
data and conduct project communications at any point in time. This shared web platform also
provides the ability for stakeholders and project team members to collaborate on project work and
communication.
26
10.6 Communications Matrix
The following table identifies the communications requirements for Researchcolab.com project.
Communication
Type Objective of Communication Medium Frequency Audience Owner Deliverable Format
Kickoff Meeting
Introduce the project team and the
project. Review project objectives
and management approach.
Face to Face Once Project Team
Stakeholders
Project
Manager
Agenda
Meeting Minutes
Soft copy archived on
project Shared web site
Project Team
Meetings
Review status of the project with the
team.
Face to Face
Conference
Call
Weekly Project Team Project
Manager
Agenda
Meeting Minutes
Project schedule
Soft copy archived on
project Shared web site
Technical Design
Meetings
Discuss and develop technical
design solutions for the project. Face to Face As Needed
Project
Technical Staff Designer
Agenda
Meeting Minutes
Soft copy archived on
project Shared web site
Weekly Project
Status
Presentation
Report on the status of the project to
course teacher
Power Point
Presentation
Weekly
Course Teacher
Other project
teams
Project
Manager
Power Point Slide
updates
Soft copy archived on
project Shared web site
Project Status
Reports
Report the status of the project
including activities, progress, costs
and issues.
Email Monthly
Project Sponsor
Project Team
Stakeholders
Course Teacher
Project
Manager
Project Status
Report
Project schedule
Soft copy archived on
project Shared web site
27
10.7 Guidelines for Meetings
Meeting Agenda
Meeting Agenda will be decided 5 working days in advance of the meeting. The Agenda should
identify the team member for each topic. The first item in the agenda should be a review of action
items from the previous meeting.
Meeting Minutes
Meeting minutes will be uploaded on the project’s web site within 1 business days following the
meeting by project manager. Meeting minutes will include the status of all items from the agenda
along with new action items.
Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include both
the action item along with the owner of the action item. Meetings will start with a review of the
status of all action items from previous meetings and end with a review of all new action items
resulting from the meeting. The review of the new action items will include identifying the owner
for each action item.
11. Change Management The Change Management Plan is created for the Researchcolab.com Project in order to set
expectations on how the approach to changes will be managed, what defines a change, the purpose
and role of the change control board, and the overall change management process. All stakeholders
will be expected to submit or request changes to the Researchcolab.com Project in accordance with
this Change Management Plan and all requests and submissions will follow the process detailed
herein.
11.1 Change Management Approach
The Change Management approach for the Researchcolab.com Project will ensure that all
proposed changes are defined, reviewed, and agreed upon so they can be properly implemented
28
and communicated to all stakeholders. This approach will also ensure that only changes within
the scope of this project are approved and implemented.
The Change Management approach consists of three areas:
Ensure changes are within scope and beneficial to the project
Determine how the change will be implemented
Manage the change as it is implemented
The Change Management process has been designed to make sure this approach is followed for
all changes. By using this approach methodology, the Researchcolab.com Project Team will
prevent unnecessary change from occurring and focus its resources only on beneficial changes
within the project scope.
11.2 Definitions of Change
There are several types of changes which may be requested and considered for the
Researchcolab.com Project. Depending on the extent and type of proposed changes, changes
project documentation and the communication of these changes will be required to include any
approved changes into the project plan and ensure all stakeholders are notified. Types of changes
include:
Scheduling Changes: changes which will impact the approved project schedule. These
changes may require fast tracking, crashing, or re-baselining the schedule depending on
the significance of the impact.
Budget Changes: changes which will impact the approved project budget. These changes
may require requesting additional funding, releasing funding which would no longer be
required, or adding to project or management reserves. May require changes to the cost
baseline.
Scope Changes: changes which are necessary and impact the project’s scope which may
be the result of unforeseen requirements which were not initially planned for. These
changes may also impact budget and schedule. These changes may require revision to
WBS, project scope statement, and other project documentation as necessary.
29
The project manager must ensure that any approved changes are communicated to the project
stakeholders. Additionally, as changes are approved, the project manager must ensure that the
changes are captured in the project documentation where necessary. These document updates must
then be communicated to the project team and stakeholders as well.
11.3 Change Control Board
The Change Control Board (CCB) is the approval authority for all proposed change requests
pertaining to the Researchcolab.com Project. The purpose of the CCB is to review all change
requests, determine their impacts on the project risk, scope, cost, and schedule, and to approve or
deny each change request. The following chart provides a list of the CCB members for the
Researchcolab.com Project:
Name Position CCB Role
Md. Adiluzzaman Adil Project Manager CCB Manager
Kishan kumar Ganguly
Md. Rakib Hossain
Software Architect & Developer
CCB Member
Minhas Kamal
A.H.M. Azimul Haque
Designer & Developer
CCB Member
Mostaque Ahmed
Israt Fatema Shantu
Documentation
CCB Member
As change requests are submitted to the Researchcolab.com Project Manager by the project
team/stakeholders, the Project Manager will log the requests in the change log and the CCB will
convene every other Saturday to review all change requests. For a change request to be approved,
all CCB members must vote in favor. In the event, more information is needed for a particular
change request, the request will be deferred and sent back to the requestor for more information or
clarification. If a change is deemed critical, an ad hoc CCB meeting can be called in order to review
the change prior to the next scheduled bi-weekly CCB meeting.
30
11.4 Roles and Responsibilities
The following are the roles and responsibilities for all change management efforts related to the
Researchcolab.com Project:
Project Sponsor:
Approve all changes to budget/funding allocations
Approve all changes to schedule baseline
Approve any changes in project scope
Chair the CCB
Project Manager:
Receive and log all change requests from project stakeholders
Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB
Seek clarification from change requestors on any open issues or concerns
Make documentation revisions/edits as necessary for all approved changes
Participate on CCB
Project Team/Stakeholders:
Submit all change requests on change request forms
Provide all applicable information and detail on change request forms
Be prepared to address questions regarding any submitted change requests
Provide feedback as necessary on impact of proposed changes
11.5 Change Control Process
The Change Control Process for the Researchcolab.com Project will follow the organizational
standard change process for all projects. The project manager has overall responsibility for
executing the change management process for each change request.
1) Identify the need for a change (Stakeholders) – Change requestor will submit a completed
change request form to the project manager.
2) Log change in the change request register (Project Manager) – The project manager will
keep a log of all submitted change requests throughout the project’s lifecycle.
31
3) Evaluate the change (Project Manager, Team, and Requestor) – The project manager will
conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and
scope and seek clarification from team members and the change requestor.
4) Submit change request to CCB (Project Manager) – The project manager will submit the
change request, as well as the preliminary analysis, to the CCB for review.
5) Obtain Decision on change request (CCB) – The CCB will discuss the proposed change
and decide whether or not it will be approved based on all submitted information.
6) Implement change (Project Manager) – If a change is approved by the CCB, the project
manager will update and re-baseline project documentation as necessary.
11.6 Change Management Log
Following instructions are followed for capturing change requests in the project-
Column Instructions for Completing Change Request Document
A ID: A unique ID number used to identify the change request in the change
management tracking log.
B Current Status: This column should be populated with the change request's current
status.
o Open: The change request is currently open but has not yet been addressed.
o Work In Progress: The change request is being actively worked to develop a
resolution.
o Closed: The change request is no longer considered an active project threat and
can be closed with or without resolution.
Some other potential options include:
o Late: The change request resolution is not yet resolved and it is past the expected
resolution date.
o On Hold: The change request has been put on hold.
o Combined: Two change requests found to be similar have been combined.
C Priority: This column should be populated with the priority of the change request.
Valid options include the following: Critical, High, Medium and Low. These are
defined as follows:
o Critical: change request will stop project progress if not resolved.
o High: change request will likely move the project back in terms of budget or
timeline, or will materially affect quality or scope.
o Medium: change request will have material effect on project, has potential to be
moved to high category and/or requires significant resources to manage.
o Low: change request is expected to have a moderate effect on the project, but
will require resources to address.
32
D Change Request Description: This column should be populated with a description
of the change request.
E Assigned to Owner: This column should be populated with the name of the change
requests owner. The individual most responsible for working towards resolving the
change request.
F Expected Resolution Date: This column should be populated with the date that the
change request is expected to be resolved.
G Escalation Required (Y/N): This column should be populated with “Yes” if the
change request needs to be escalated and “No” if escalation is not needed to
resolve the change request.
H Action Steps: This column should be populated with the proposed steps to address
the change request. Examples include, but are not limited to, developing
alternatives analysis or submitting a change request.
I Impact Summary: This column should be populated with a description of the
impact of the change request. The impact may be expressed in terms of one or
more of the following: schedule, scope, resources, and space. The impact
description should also include a reference to any milestones impacted.
J Change Request Type: This column should be populated with the change request
type. Valid options include the following:
Product, Project, Other. These are defined as follows:
o Product: The change request impacts the products being developed.
o Project: The change request impacts the project developing the product.
o Other: The change request impacts other areas.
K Date Identified: This column should be populated with the date that the change
request was identified.
L Associated ID(s): This column should contain the project ID of any associated
milestones that may be impacted by a change request or that the change request is
dependent upon for resolution.
M Entered By: This column should be populated with the name of the individual who
first identified the change request.
N Actual Resolution Date: This column should be populated with the date that the
change request was actually resolved.
O Final Resolution & Rationale: This column should be populated with a description
of the final resolution of and rationale for the change request. The resolution may
be expressed in terms of one or more of the following: schedule, scope, resources,
and space. The resolution description should also include a reference to the
milestones impacted.
33
11.7 Change Management log format
PROJECT NAME: RESEARCHCOLAB.COM
PROJECT MANAGER NAME:
ID CURRENT
STATUS
PRIORITY CHANGE
REQUEST
DESCRIPTION
ASSIGNED
TO
OWNER
EXPECTED
RESOLUTION
DATE
ESCALATION
REQUIRED
Y/N
ACTION
STEPS
IMPACT
SUMMERY
CHANGE
REQUEST
TYPE
ACTUAL
RESOLUTION
DATE
FINAL
RESOLUTION
&
RATIONALE
1
2
3
12. Quality Assurance The Quality Management Plan for the Researchcolab.com project will establish the activities,
processes, and procedures for ensuring a quality product upon the conclusion of the project. The
purpose of this plan is to:
Ensure quality is planned
Define how quality will be managed
Define quality assurance activities
Define quality control activities
Define acceptable quality standards
12.1 Quality Management Approach
The quality management approach for the Researchcolab.com project will ensure quality is
planned for both the project deliverables and processes. In order to be successful, this project will
meet its quality objectives by utilizing an integrated quality approach to define quality standards,
measure quality and continuously improve quality.
The quality management plan identifies these key components:
Objects of quality review Quality Measure Quality Evaluation Methods
Project Deliverables Deliverable Quality Standards
Completeness and Correctness
Criteria
Quality Control Activities
Project Processes Process Quality Standards
Stakeholder Expectations
Quality Assurance Activities
34
The following is a brief explanation of each of the components of the quality management plan.
Project Deliverables
and Processes
The key project deliverables and processes subject to quality review.
Deliverable
Quality Standards
and
Completeness and
Correctness
Criteria
The quality standards that are the “measures” used to determine a
successful outcome for a deliverable.
The completeness and correctness criteria describe when each
deliverable is complete and correct as defined by the customer.
Deliverables are evaluated against these criteria before they are
formally approved.
Process
Quality Standards
and
Stakeholder
Expectations
The quality standards that are the “measures” used to determine if
project work processes are being followed.
Stakeholder expectations describe when a project process is effective
as defined by the project stakeholders. An example is the expectation
to be regularly informed monthly of project status.
Quality Control
Activities
The quality control activities that monitor and verify that the project
deliverables meet defined quality standards.
Quality Assurance
Activities
The quality assurance activities that monitor and verify that the
processes used to manage and create the deliverables are followed
and are effective.
Quality improvements will be identified by any member of the project team or quality assurer.
Each recommendation will be reviewed to determine the cost versus benefit of implementing the
improvement and how the improvement will impact the deliverables 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.
12.2 Quality Requirements / Standards
Product Quality:
The product quality standards and requirements will be determined by the project team and quality
assurer. These standards will primarily be based on the project teams’ identified documented
35
standards for web based platform. There may be product-specific quality standards identified that
are not currently part of the documented standards. In this case, the quality assurer will review
these newly identified standards and incorporate them into project documentation if approved.
The project team will also document any newly identified quality standards into the
Researchcolab.com project plan and ensure communication with all team members/stakeholders.
Process Quality:
The process quality standards and requirements will be determined by the project team and quality
assurer. Many of these standards will be based on existing website process standards. However,
it is anticipated that there will be several unique steps in the developing of the Researchcolab.com
project which will require new quality standards. The Researchcolab.com project team will work
with the quality assurer to establish acceptable standards and document these standards for
incorporation into Researchcolab.com project plan. These standards will be communicated to all
project team members/stakeholders.
12.3 Quality Assurance
The quality assurance of the Researchcolab.com Project focuses on the processes used in the
developing of the web based platform. In order to ensure quality, an iterative quality process will
be used throughout the project life cycle.
The Researchcolab.com Project Manager and the project team will perform assessments at planned
intervals throughout the project to ensure all processes are being correctly implemented and
executed. The table below provides the key quality assurance activities for the Researchcolab.com
Project:
Activity Coverage Description
Preconditions Every public method Use if-statements at the beginning of public methods to
validate each argument value. This helps to document
assumptions and catch invalid values before they can
cause faults.
Assertions Every private method Assertions will be used to validate all arguments to
private methods. Since these methods are only called
from our other methods, arguments passed to them
should always be valid, unless our code is defective.
Assertions will also be used to test class invariants and
some post-conditions.
36
Review
meetings
Weekly, once before
release, every source
file
In these reviews, an agenda item will include a review
of project processes, any inconsistency and/or audit
findings from the Quality assurer, and a discussion on
process improvement initiatives.
Unit testing 100% of public
methods, 75% of
statements, 100% of
public methods, 75%
of statements
We will develop and maintain a unit test suite using
the JUnit framework. We will consider the boundary
conditions for each argument and test both sides of
each boundary. Tests must be run and passed before
each commit, and they will also be run by the testing
team. Each public method will have at least one test.
And, the overall test suite will exercise at least. 75% of
all executable statements in the system
Manual
system
testing
100% of UI screens
and fields, 100% of
specified requirements
The QA team will author and maintain a detailed written
suite of manual tests to test the entire system through
the user interface. This plan will be detailed enough that
a person could repeatedly carry out the tests from the
test suite document and other associated documents
Regression
testing
Run all unit tests
before each commit,
run all unit tests
nightly
We will use selenium tool to frequently rerun all
automated tests, including those that have previously
been successful. This will help catch regressions (bugs
that we thought were fixed, but that appear again).
Load, stress,
and capacity
testing.
Simple load testing,
detailed analysis of
each scalability
parameter.
Use Apache JMeter tool to test load, stress and capacity
of the system.
Process
improvement
Weekly Quality assurance reviews, findings, and assessments
should always 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.
12.4 Quality Control Measurements
All Researchcolab.com Project products and processes must be measured and fall within the
established standards and tolerances. The below logs 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.
37
Quality Assurance Log
ID # Date Process
Measured
Required
Value
Actual
Measured
Acceptable?
(Y/N)
Recommendation Date
Resolved
Quality Control Log
ID
#
Date Deliverables
Measured
Required
Value
Actual
Measured
Acceptable?
(Y/N)
Recommendation Date
Resolved
13. Release The project release contains the following deliverables:
Deliverable Description Date
Project
Management
Reports
This deliverable describes about the entire project plan.
It contains which development process to follow, how to
coordinate between team members, which development
tools to follow.
15th August,
2016
SRS & Design
document
The architecture of the software and UX design is
described in this report.
25th October,
2016
Configuration
Manual
Configuration Manual describes about how to configure
the tools and what environment is required for running
the software.
20th
November,
2016
Executable code
module The actual tool will be provided.
26th
November,
2016
38
14. Budget 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 project team 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. The Project Sponsor has the authority to make changes
to the project to bring it back within budget.
14.1 Measuring Project Costs
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)
Cost Performance Index (CPI)
If the Schedule Performance Index or Cost Performance Index has a variance of between 0.1 and
0.2 the Project Manager must report the reason for the exception. If the SPI or CPI has a variance
of greater than 0.2 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.
Performance Measure Yellow Red
Schedule Performance Index (SPI) Between 0.9 and 0.8 or
Between 1.1 and 1.2
Less Than 0.8 or Greater
than 1.2
Cost Performance Index (CPI) Between 0.9 and 0.8 or
Between 1.1 and 1.2
Less Than 0.8 or Greater
than 1.2
14.2 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.
39
14.3 Cost Variance Response Process
The Control Thresholds for this project is a CPI or SPI of less than 0.8 or greater than 1.2. 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.
14.4 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.
14.5 Project Budget
The cost estimation is the approximation of the cost related to a project or operation. This
project includes the cost of –
1. Opex
2. Capex
1. Opex: Opex consists of all the operational costs. They include-
Working hour
Logistic support
Utility
Miscellaneous
Work hour breakdown
Total persons working 7
Work hour per person per day 1
Total working days 60
Total work hours per person 60
Work hours in total 420
40
Logistic support needed
1. Transport cost
2. Report printing
3. Web Hosting
Utility necessity
1. Internet bill
Miscellaneous
1. Contingency
2. Capex: The capital expenditure for this project only consists of the laptop and desktop
computers used for the development of this project.
A breakdown of the total cost for the project
Type Sector Breakdown Frequency Amount (BDT)
Opex
Project staffing
Total work
hours 420
Daily 63,000/= BDT Cost per person
per hour
150/=
BDT
Logistic
Transport 1,000/=
BDT
Ongoing 11,500/= BDT Report Printing 1,500/=
BDT
Web hosting 9,000/=
BDT
Utility
Internet bills (7
person, 2
months)
7,000/=
BDT Ongoing 7,000/=
Miscellaneous Ongoing 2,000/=
Capex
Laptop Laptop computers 7 Pcs One time 2,80,000/=
Desktop Desktop computers 3 Pcs One time 1,20,000/=
Premises Ongoing 2,40,000/=
Total anticipated costs 7,23,500 /=
