GROUP ASSIGNMENT

ACTIVITY 4:
OTHER PROJECT PLANS

GOH JIN KAI (PBS171021499)

SIVASAKTI MARIMUTHU (PBS16211313)
ANI FADILAH BINTI DAHRI (PBS16221413)

SOFTWARE PROJECT MANAGEMENT (SIM5308)

PROF. MADYA DR. MARZANAH A. JABAR
PUTRA BUSINESS SCHOOL

4 DECEMBER 2017
DOCUMENT CHANGE CONTROL

Revision Number Date of Issue Author(s) Notes

Goh Jin Kai
Supporting
SPMP_V1.4 4.12.2017 Sivasakti Marimuthu
Process Plans
Ani Fadilah Dahri

i
CONTENTS

4. SUPPORTING PROCESS PLAN .................................................................... 1

4.1 Risk Management Plan ................................................................................ 1
4.2 Verification and Validation Plan.................................................................. 1
4.3 Documentation Plan ..................................................................................... 1
4.4 Quality Management Plan ............................................................................ 1
4.5 Reviews and Audits ................................... Error! Bookmark not defined.
4.6 Configuration Management Plan ................................................................. 4
4.7 Communication Management Plan .............................................................. 9

REFERENCES ......................................................................................................... 14

APPENDICES ............................................................................................................ 1

ii
4. SUPPORTING PROCESS PLAN
4.1 Risk Management Plan
This section will discuss the methods, tools and techniques used to manage
project risk. The goal of risk management is to identify and mitigate potential sources
of expense or delay. Some risks are common to every project phase, and some risks
are closely associated with a particular project phase. Risks for this project have been
classified accordingly:

4.1.1 Risk Categorization Table

A risk categorization table will be maintained for the duration of the project.
This table will list the current project risks, the indicators that determine the rating
(High, Medium, Low) of the risk, and the current rating of the risk, obtained by
comparing the current situation of the risk item against the risk indicators. The risk
categorization table will be maintained by the project manager, but will be distilled to
produce Top Risks report which will be reviewed at weekly project status meetings.
A preliminary risk categorization table has been populated with risks and risk status,
where applicable, and included accordingly. If it is too soon to evaluate a risk, this is
identified in the risk status column as Too soon. Each item described here will be
reviewed weekly in project status meetings. New risks may be added to the Risk
Categorization table by the project manager at any time. The risk should be added to
the appropriate category with an associated risk rating indicator and initial risk rating.

4.1.2 Top Risks

The Top Risks report will consist of the top risks posed to the project, with
ranking determined by the risk rating for the risk item. The resolution approach,
responsibility assignment, and expected resolution date will be included. The Top
Risks report is included in Appendix A.

1
4.2 Verification and Validation Plan

This section briefly describes the Verification and Validation (V&V) approach
for the project.

4.2.1 Scope

Formal validation and verification will be performed on the following project

work products and are listed below in order of occurrence:
Software requirements
Software architecture
Software interface design
Database design
Implemented software interfaces

The main V&V activities performed on these work products will be inspections
and reviews. Audits may also be performed on request. All other work products will
be informally verified and validated to some degree, but they will not receive formal
verification and validation from the verification and validation team members.

4.2.2 Responsibilities

The verification and validation team consists of the following resources:

System Architect (Lead)
System Analyst
System Tester 1
System Tester 2

Each of the validation and verification activities are included in the project WBS
(see subsection 4.1). The specific responsibilities of resources and resource
collaborations are identified in subsection 2.2. The team Lead, identified above, has
responsibility for focusing and coordinating the V&V effort of each resource listed in
this section and is ultimately responsible for the outcome of the activities of the team.

2
4.2.3 Tools & Techniques

Each of the items listed in the Scope subsection of this section will be verified
and validated to ensure that they account for all items in the products of the preceding
activity. The first item, which has no precedent, will be verified and validated against
documented customer meetings to ensure that all requirements are included in the
SRS.
Tracing will be used to trace the existence of features between phases back to
the original requirements and avoid the introduction of unnecessary work into the
products. In particular, the following will be traced:
User requirements to software requirements
Software requirements to interface requirements
Architecture requirements to interface requirements
Interface requirements to database requirements
Software tests to interface requirements
Acceptance tests to user requirements

The information produced by tracing will be used during software inspections.

Software inspections will ensure that work products are faithfully representing the
goals set out for them by the predecessor documents.
Black-box testing will be performed on the implemented software interfaces to
ensure that the outputs of each interface are consistent with what is input, based on the
interface design. The Software Test Plan (STP) will specify the methods to be used.

The following tools will be used to assist with V&V:

IBM Rational RequisitePro - allows requirements tracing from inception
to facilitate requirements accountability
IBM Rational Robot - allows automated black-box testing by feeding
inputs and recording outputs

[due to page orientation differences, section 4.3 starts on the next page

3
4.3 Documentation Plan
This section covers the documentation plan for the project which contains plans for producing non-deliverable and deliverables
work products. The documentation plan also specifies the persons in charge for giving input information, assembling and evaluating
various documents. The documentation plan consist a list of documents to be prepared, the template or standard used for each
document, the individual that will prepare it, the individual that will review it, due dates for review copy and initial baseline version,
plus a distribution list for review copies and baseline versions.

The headings in the tables below are explained as the following:

- Document: the documentation work product defined by the remaining columns in the row
- Template/Standard: the template or standard the document is being based on (may be organizational or external)
- Preparer: the individual responsible for preparing the document
- Reviewer: the individual responsible for reviewing the document
- Review copy due: the due date on which the document will be available for review by the Reviewer
- Baseline version: (if relevant) the version of the document that represents the baseline for that document
- Distribution list: expected recipients of the review copies and baseline versions of the document
- WBS#: (if relevant) the WBS activity related with the creation of this document Deliverable documentation work products

1
Deliverable Documentation Work Products

Template/ Review Baseline

Document Preparer Reviewer WBS# Distribution List
Standard Copy Due Version
Installation Standard System System 30/03/2018 1.0 5.5.1 Document
Document Document Developer Analyst repository, Preparer,
Template v1.0 Reviewer, Project
Manager

End-user IEEE 1063-2001 System Project 30/03/2018 1.0 5.5.1 Document

documentation Analyst Manager repository, Preparer,
Reviewer, Project
Manager

Organization Based on System Project 30/03/2018 1.0 5.5.1 Document

Documentation existing Analyst Manager repository, Preparer,
Updates documentation Reviewer, Project
within the Manager
organization; no
formal template

Software IEEE 830-1998 System System 20/10/2017 1.0 2.2.3 Document

Requirements Architect Analyst, repository, Preparer,
Specification Project Reviewer, Project
(SRS) Manager Manager, System
Developer

2
 Template/ Review Baseline
Document Preparer Reviewer WBS# Distribution List
Standard Copy Due Version

Software IEEE 1016-1998 System Project 07/11/2017 1.0 3.3.2 Document

Design Architect, Manager repository, Preparer,
Specification System Reviewer, Project
(SDS) Analyst Manager, System
Architect, System
Analyst

Software IEEE 1058- Project Organization 24/10/2017 1.0 1.1.3 Document

Project 1998, IEEE Manager, Executive repository, Preparer,
Management 1074-1997 System Committee 2.3 Reviewer, Project
Plan (SPMP) (activities) Analyst Manager, System
Analyst,
Organization
Executive
Committee

Software Test Test Plan System Tester, Project 28/02/2018 1.0 5.5.1 Document
Plan (STP) template System Manager repository, Preparer,
(adapted from Developer Reviewer, Project
IEEE 829-1998) Manager, System
Developer, System
Tester

3
 Template/ Review Baseline
Document Preparer Reviewer WBS# Distribution List
Standard Copy Due Version

Software IEEE 730-2002 System Tester, Project 24/10/2017 1.0 1.1.3 Document
Quality System Manager repository, Preparer,
Assurance Plan Developer 2.3 Reviewer, Project
(SQAP) Manager, System
Developer, System
Tester

Software IEEE 828-1998 Database Project 24/10/2017 1.0 1.1.3 Document

Configuration Administrator, Manager repository, Preparer,
Management Server & 2.3 Reviewer, Project
Plan (SCMP) Network Manager, Database
Specialist Administrator,
Server & Network
Specialist

Software IEEE 1012-1998 System Project 27/02/2018 1.0 4.4.1 Document

Verification + IEEE 1012a- Developer Manager repository, Preparer,
and Validation 1998 Reviewer, Project
Plan (SVVP) Manager, System
Developer

4
Deliverable Documentation Work Products

Template/ Review Baseline

Document Preparer Reviewer WBS# Distribution List
Standard Copy Due Version
Project team Meeting Project Meeting 48 after N/A N/A Document
meeting minutes minutes Manager participants meeting repository, Reviewer
template v1.0
Project team Meeting Project Meeting 24 hours N/A N/A Document
meeting agendas Agenda Manager participants prior to repository, Reviewer
template v1.0 meeting
Requirements Technical System Review 48 hours N/A N/A Document
peer review Review Analyst Participants prior to repository, Reviewer
summaries Summary review
template v1.0
Design peer Technical System Review 48 hours N/A N/A Document
review Review Architect Participants prior to repository, Reviewer
summaries Summary review
template v1.0
Implementation Technical System Review 48 hours N/A N/A Document
peer review Review Developer Participants prior to repository, Reviewer
summaries Summary review
template v1.0
Installation Training Plan System N/A N/A N/A 5.1 Document
training plan template v1.0 Analyst repository, Preparer,
Project Manager

5
 Template/ Review Baseline
Document Preparer Reviewer WBS# Distribution List
Standard Copy Due Version
Site Installation Training Plan System N/A N/A N/A 5.1 Document
template v1.0 Analyst repository, Preparer,
Project Manager
Project Quality Audit System Meeting N/A N/A N/A Document
documentation template v1.0 Tester participants repository, Preparer,
reviews Reviewer, Project
(Quality) Manager
Closure review N/A System Meeting N/A N/A N/A Document
(Quality) Tester participants repository, Preparer,
Reviewer, Project
Manager
Software Training Plan System N/A N/A N/A 5.1 Document
Maintenance template v1.0 Analyst repository, Preparer,
training plan Project Manager

[due to page orientation differences, section 4.4 starts on the next page]

6
4.4 Quality Management Plan
4.4.1 Introduction
The Quality Management Plan provides the plans for ensuring that the project
fulfils its obligations to the process and the product as detailed in the requirements
specification, the document, supporting plans, and any standards, procedures or
guidelines to which the process or the product must observe. The Quality Management
Plan will include analysis, inspections, reviews, audits and assessments. The plan will
indicate the relationships among the quality assurance, verification and validation,
review, audit, configuration management, system engineering, and assessment
processes.

4.4.2 Scope
The processes used to create the following products will be tracked:
Software Requirement Specification (SRS)
Software Design Specification (SDS)
Software Project Management Plan (SPMP)
Software Risk Management Plan
Software Test Plan (STP)
Software Quality Assurance Plan (SQAP)
Software Configuration and Management Plan (SCMP)
Software Verification and Validation Plan (SVVP)
Software product object code
Software product binaries
End-user training program
End-user documentation

4.4.3 Reviews
Quality reviews will ensure that documentation products observe the standards
on which they are based (as per section 4.3), and that non-documentation work
products keep to the plans/designs laid out by their input criteria.
Once the product is completed, quality reviews of in-scope documentation work
products will be carried out. Reviews of in-scope non-documentation work products
will take place weekly during the active production periods.

1
 Each quality review will be in a meeting format and will need the attendance of
the following participants:
Project Manager
System Tester
Database Administrator
Network & Server Specialist

In addition, the attendance of leaders of teams involved in the production of

work products are compulsory as well.
Once all work products have been delivered, a closure review will be held for
the purpose of gathering lessons learned, and identifying process improvement
opportunities. This review will be conducted in a meeting format.

4.4.4 Audits
Brief, informal functional audits of in-scope work products will be conducted
during the software testing and integration phases and findings will be documented.
Physical audits of software source code will be carried out in order to ensure that
a minimum level of documentation quality exists. In addition, a quantity (% of
documentation to code) will be taken to provide an indicator as to whether there is
sufficient internal documentation being written.
Scheduled audits of other work products will not be held. However, audits may
be performed at the request of a project manager or senior executive. This is usually
done to verify adherence of procedures described in the other project plans, for
example SCMP, SVVP and others.
The procedure for requesting an audit is as the table below:
Step What Who
1 Make a formal, written request for an audit to Audit requestor (must be
the project manager a project manager or
- Specify configuration item(s) to be executive)
audited
2 Schedule audit session with resources required Project manager
for audit session
- System Tester
- Project manager
- Anyone else requested by audit requestor

2
Step What Who
3 Distribute audit agenda to resources Project manager
- Date of audit
- Required resources
- Purpose of audit
- Item(s) to be audited
4 Hold audit session Project manager

5 Distribute audit results Project manager

- Date of audit
- Audit participants
- Item(s) audited
- Conclusion
- Recommendations

3
4.5 Configuration Management Plan
4.5.1 Introduction
The Software Configuration Management (SCM) Plan specifically addresses
configuration management for software. The purpose of Software Configuration
Management (SCM), in general, is to establish and maintain the integrity of work
products using:
a) Configuration Identification
The purpose of Configuration Identification is to define the functional and
physical characteristics of a Configuration Item (CI) in sufficient detail so that it may
be developed, tested, evaluated, produced, competitively procured, accepted,
operated, maintained, and supported. Configuration Identification is established by
baselines plus approved changes.

b) Configuration Control
Configuration Control is the process of evaluating, approving or disapproving,
and managing changes to controlled items. This includes tracking the configuration
of each of the CIs, approving a new configuration if necessary, and updating the
baseline.

c) Configuration Status Accounting

This is the process of creating and organizing the information necessary for the
performance of configuration management. This information includes a listing of the
approved configuration identification, the status of proposed changes to the
configuration, and the implementation status of approved changes.

d) ConfigurationAudit
Configuration Audits are conducted to verify that a CI, or a collection of CIs that
make up a baseline, conforms to a specified standard or requirement. This includes
functional and physical configuration audits.

4
4.5.2 Configuration Management Roles and Responsibilities
a) Project Manager
Establish the overall project schedule for SCM activities with
Configuration Management Manager (CMM)
Validates that team members have been trained in and knowledgeable of
SCM concepts and techniques and that they are applied to project activities
Ensure compliance with the SCM standards and procedures set by the
CMM, the Change Control Board (CCB), and any other affected groups
as outlined in this plan
Participate as a member of the Change Control Board

b) Business Owner
Ensure compliance with the SCM standards and procedures set by the
CMM, the Change Control Board (CCB), and any other affected groups
as outlined in this plan
Participate as a member of the Change Control Board

c) Configuration Management Manager (CMM) Responsibilities

Document the SCM Plan with assistance from the Project Manager
Create and update the SCM Plan, as well as communicating the contents
of the plan to the project team
Identify the Configuration Items (CIs) to be managed under the SCM
processes
Create, manage and maintain the SCM Plan, standards, and procedures
Communicate any changes to the SCM Plan, standards, and procedures to
all stakeholders
Validate that all project team members involved in the SCM process
receive training on their roles
Update the SCM Plan, as appropriate
Communicate updates to the SCM Plan to the appropriate project team
members
Form and lead a SCM Team

5
 Approve changes to the SCM Plan
Function as the point of contact with Infrastructure Services to analyse
proposed changes and to insure interoperability between hardware and
software components

4.5.3 Software Configuration Management Tasks

Items in the following categories are selected to be placed under configuration
management:

Project Management documentation, including Project Plan and Project

Charter
Product documentation, including all deliverables
Models
Interfaces
Process descriptions
Product/Application data such as lookup tables, system files
Source code and executable code
Test scripts
Test data
Metrics, status reports, quality review reports, etc.
Support tools, including compilers, editors, testing tools

6
4.5.4 Configuration Items (CIs)
Responsible for
Configuration
placing item When item is put under control
Items
under control
Waterfall - Initiation & Planning Stage
Project Plan Project Manager
Exit (signed)
Software
Waterfall - Initiation & Planning Stage
Configuration CMM Manager
Exit
Management Plan
System
Maintenance Plan Analyst/CM Initiation & Planning Stage Exit
Manager
Waterfall -Requirements Stage Exit
Requirements
Specification
Business Owner Agile Backlog snap shot prior to
each implementation to production
Requirements Project Manager/
Waterfall -Requirements Stage Exit
Traceability Matrix System Analyst
Business Owners,
Use Cases Waterfall - Function Design Stage Exit
Test Manager
Waterfall Requirements Stage Exit
Infrastructure Project (signed)
Services Request Manager/DTMB
(ISR) Analyst Agile Last Product Increment
Planning for the project

Business Waterfall -Functional Design Stage

Owner)/Project Exit
Functional Design
Manager/System Agile prior to each implementation
Analyst to production

Business Waterfall - Initiation & Planning Stage

Test Plan Owner)/Test Exit
Manager Agile
Project Waterfall - System Design Stage Exit
System Design Manager/System Agile prior to each implementation
Analyst to production
Project Waterfall - Construction Stage Exit
Installation Plan Manager/System Agile Prior to each implementation
Analyst to production
Training Plan Business Owner Waterfall - Construction Stage Exit

7
 Responsible for
Configuration
placing item When item is put under control
Items
under control
Agile Prior to the FIRST
implementation to production
Business
Post Waterfall Implementation Stage Exit
Owner/Project
Implementation
Manager/System Agile Post - Every implementation
Evaluation Report to production
Analyst
Business
Stage Exit Owner/Project
All Stages
Approvals Manager/System
Analyst
Business
Initiation, Waterfall -Construction & Testing
Owner/Project Stage Exit
Requirements and
Manager/System
Design Plan
Analyst
Business Waterfall -Construction & Testing
Construction and Owner/Project Stage Exit
Testing Plan Manager/System
Analyst
Database Stored
DBA Initial unit test
Procedures

4.5.6 Training

The Project Manager is responsible for determining the SCM training needs of
the team. Potential training topics include:

Roles, responsibilities, and authority of configuration management staff

Configuration management standards, procedures, and methods
Configuration repository system

8
4.6 Communication Management Plan
4.6.1 Introduction
The overall objective of a Communications Management Plan is to promote
the success of a project by meeting the information needs of project stakeholders. The
Inventory Management System Communications Management Plan (CMP) defines
the projects structure and methods of information collection, screening, formatting,
and distribution and outline understanding among project teams regarding the actions
and processes necessary to facilitate the critical links among people, ideas, and
information that are necessary for project success.

4.6.2 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 projects
Change Management Plan and ensures that all project stakeholders remain aware and
informed of any changes to communications management.

4.6.3 Communications Management Constraints

All project communication activities will occur within the projects 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

9
Matrix in order to ensure the project adheres to schedule constraints. Any deviation of
these timelines may result in excessive costs or schedule delays and must be approved
by the project sponsor.

4.6.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 projects 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 projects communication channels and
ensure that stakeholders have access to these channels. If project information is
communicated via 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 projects
Stakeholder Register and use this, along with the project communication matrix as the
basis for all communications.

4.6.5 Communication Methods and Technologies

The project team will determine, in accordance with 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.
The company maintains a SharePoint platform within the PMO 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. SharePoint also provides the ability for stakeholders and project team
members to collaborate on project work and communication.

10
 For stakeholders who do not have the ability to access SharePoint, a web site
will also be established for the project. Access to the website will be controlled with a
username and password. Any stakeholders identified who are not able to access
SharePoint will be issued a unique username and password in order to access the web
site. The project manager is responsible for ensuring all project communications and
documentation are copied to the web site and that the content mirrors what is contained
on the SharePoint platform.

4.6.6 Communications Matrix

The following table identifies the communications requirements for this project.

Communication Objective of Audience Deliverable Format

Type Communication

Kick-off Meeting Introduce the project - Project - Agenda - Soft copy

team and the project. Sponsor - Meeting archived on
Review project - Project Team Minutes SharePoint
objectives and - Stakeholders site and
management project
approach. website.

Project Team Review status of the - Project Team - Agenda - Soft copy
Meetings project with the team. - Meeting archived on
Minutes SharePoint
- Project site and
Schedule project
website.

Technical Design Discuss and develop - Project - Agenda - Soft copy

Meetings technical design Technical Staff - Meeting archived on
solutions for the Minutes SharePoint
project. site and
project
website.

Monthly Project Report on the status - PM - Slide - Soft copy

Status Meetings of the project to Updates - archived on
management. Project SharePoint
Schedule site and
project
website.

11
Project Status Report the status of - Project - Project - Soft copy
Reports the project including Sponsor Status archived on
activities, progress, - Project Team Report SharePoint
costs and issues. - Stakeholders - Project site and
- PM Schedule project
website.

4.6.7 Communication Escalation Process

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, ABC Corp. 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.

Priority Definition Decision Timeframe for Resolution

Authority

Priority 1 Major impact to project or Vice Within 4 hours

business operations. If not President or
resolved quickly there will higher
be a significant adverse
impact to revenue and/or
schedule.

Priority 2 Medium impact to project or Project Within one business day

business operations which Sponsor
may result in some adverse
impact to revenue and/or
schedule.

Priority 3 Slight impact which may Project Within two business days
cause some minor Manager
scheduling difficulties with
the project but no impact to

12
 business operations or
revenue.

Priority 4 Insignificant impact to Project Work continues and any

project but there may be a Manager recommendations are
better solution. submitted via the project
change control process

13
REFERENCES

Roles of The System Developer. Retrieved 25 September, 2017, from

https://careertrend.com/roles-systems-developer-5922.html

Project Plan SJSU Library System. Retrieved 22 September, 2017, from

http://www.engr.sjsu.edu/gaojerry/course/131/SampleProjects/Planning_Doc.
pdf

Ajay, A., Chandrakanth, R.D., & Nagaraju, D. (2015). Governors State University:
Smart Inventory System. Retrieved 22 September, 2017, from
http://opus.govst.edu/cgi/viewcontent.cgi?article=1156&context=capstones

14
APPENDICES

APPENDIX A

Risk Management Supplements

1
 Risk Categorization Table

Risk Factors and Low Risk Medium Risk High Risk Risk Rating Comments
Categories Evidence (L) Evidence (M) Evidence (H) (H,M,L)
Mission and goals factors
Project fit Project fits Project limits Mid-project, the Unlikely to be an issue, since the project
within ability to take on project conflicts L involves sufficient resources and
area of expertise other attractive with a change in therefore sustains it.
and interest projects direction
Organization management factors
Project team stability Project staff are One or more key More than three
expected to stay project staff are key project staff
for the duration expected to leave are expected to L
of the project before their leave before
accountabilities their
are met accountabilities
are met
Project processes All project One or more More than three
processes are important and important and
defined and complex project complex project Too soon
being followed processes not processes not
defined or being defined or being
followed followed
Management support Recognizes the Partial Not committed Concerns all management
importance of recognition to project, or involved with project
the project and of importance of does not L
strongly the project or recognize it as
committed to commitment to important
its success

2
 seeing its
success
Performance Organization has Organization has Organization has Concerns all organization around
objectives verifiable Some no established the project
performance performance performance L
objectives and objectives, but requirements, or
reasonable not necessarily requirements are
requirements measurable ones not measurable
Executive Visible and Occasional No visible
involvement strong support support, provides support or no L
help on issues help offered
only when asked on unresolved
issued
Customer factors
Product fit Overall Overall Overall
inventory inventory inventory
management management management L
project fits project receiving project being
within company less interest questioned by
strategy within company company
Customer End-users are End-users play Minimal or no Too soon
involvement highly involved minor roles, end-user
with the project moderate impact involvement,
team, provide on system little end-user
significant input input
Customer experience End-users are End-users have End-users have
highly experience with no previous M
experience in similar project experience with
similar projects, similar project,

3
 have specific and have needs unsure of how
ideas on how in mind needs can be met
needs can be met
Customer acceptance End-users accept End-users accept End-users do not
concepts and most concepts accept any
details of and details of concepts or Too soon
system, process system, process design details of
is in place for in place for end- system
end-user user approvals
approvals
Customer training End-user End-user Training
needs training needs training needs requirements not L
considered, considered, identified or not
training in no training yet or addressed
progress or plan training plan is
in place in development
Budget/cost factors
Budget fit Cost Variance Cost Variance Cost Variance
(CV) shows that (CV) shows that (CV) shows that Too soon
project is in line project is project is
with or under exceeding exceeding
budget budget budget
by 1-5% by more than 5%
Project size Small, Medium, Large, highly
noncomplex moderate complex, or not M
or easily complexity, decomposable
decomposed decomposable

4
Technology Mature, existent, Existent, some New technology
in-house inhouse or a new use or M
experience experience Under
development,
little in-house
experience
Budget constraints Funds allocated Questionable Allocation in The budget allocated initially
without budget allocated doubt or subject H RM 100,000 was not sufficient where
constraints to change infrastructure budget has yet to factor in.
without
notice
Cost controls Well- System in place, System lacking M
established, weak in areas or non-existent
in place
Schedule factors
Delivery Stable Some uncertain Unstable, L
commitment commitment commitments fluctuating
dates commitments
Schedule fit Schedule Schedule Schedule
Variance (SV) Variance (SV) Variance (SV) Too soon
shows that shows that shows that
project is in line project is project
with or under exceeding is exceeding
schedule schedule by schedule by
1-5% more
than 5%
Development Team projects Team finds on Team projects
schedule that schedule is phase of the plan that two or more L
acceptable and to have a phases of

5
 can be met schedule that is schedule are
too aggressive unlikely to be
met
Project content factors
Requirements Requirements Some Requirements
progress definition is requirements definition phase M
progressing definition items will clearly not
according to are behind be completed on
schedule schedule schedule
Requirements All completely Some Some
complete and clear specified and requirements requirements H
clearly written incomplete or only in the head
unclear of the customer
System testability Software Some Most or all of the
requirements requirements system hard to M
easy to test, hard to test, or test, or no
planning test plans planning being
underway insufficient done
Design difficulty Well-defined Unclear how to Interfaces not
interfaces, design, or well-defined L
design aspects of design Or controlled,
well-understood undecided subject to change
System Clearly defined Some elements No clear plan or
dependencies dependencies of of the system are schedule for how M
the software well-understood the whole system
effort and other and planned, will come
parts of the others are not yet together
system comprehended

6
Documents stability Documents will Some documents Little chance of
be available on may be late and Getting M
time and will contain minor documents
contain few errors on time, many
errors corrections and
changes
expected
Implementation Algorithms and Algorithms Algorithms
difficulty design are and/or design and/or design
reasonable for have elements have Too soon
the somewhat components the
implementation difficult for the implementation
team to implementation team will find
implement team to very difficult to
implement implement
Performance factors
Hardware interface Hardware Hardware Hardware This will affect our ability to define
documentation interface interface interface Too soon hardware interfaces in the
documentation is documentation is documentation is requirements stage, and puts staff
delivered to delivered to not delivered to availability further downstream in
project team by project team by project team by question
deadline deadline, but is deadline.
incomplete.
Test capability Modular design Modular design No modular
allows for easy aids developing design or ability Too soon
coverage test test harnesses for to easily
planning and unit test establish
execution test coverage
planning

7
Expected test effort Good estimate Rough estimate Poor or no
available, readily of test time, mayestimate of test M
fits system be a bottleneck times, definite
acceptance in the process chance of
process bottleneck
Functionality Defined software Defined software Defined software
product highly product has good product has little M
functional, meets functionality, functionality,
all customer meets most many customer
needs customer needs needs not met
External hardware or Little or not Some integration Extensive
software interfaces integration or or interfaces interfaces M
interfaces needed required
needed

Project management factors

Approach Product and Planning and Weak or
process planning monitoring need nonexistent M
and monitoring enhancement planning and
in place monitoring
Communication Clearly Communicates Rarely
communicates some of the communicates Too soon
goals and status information clearly to the
between the some of the time team or to other
team and the rest who need to be
of the informed of team
organization status
Project manager Project manager Project manager Project manager
experience very experienced has moderate M

8
 with similar experience or has no
projects has experience experience
with different with this type of
types of projects project or is new
to project
management
Development process factors
Quality assurance QA system Procedures No QA process
approach established, established, but or established Too soon
followed, not well procedures
effective followed or
effective
Commitment process Changes to Changes to Changes to
commitments in commitments are commitments are Too soon
scope, content, communicated to made without
schedule are all involved review or
reviewed and involvement of
approved by all the team
involved
Use of defined Development Development No formal
engineering process process in place, process process M
established, established, but used
effective, not followed or
followed by is ineffective
team
Early identification Peer reviews are Peer reviews are Team expects to M
of defects incorporated used find all defects
throughout occasionally with testing

9
Change control for Formal change Change control No change
work products control process process in place, control process L
in place, not followed, or used
followed, is ineffective
effective
Defect tracking Defect tracking Defect tracking No process in
is defined, process defined, place to track L
consistent, but defects
effective inconsistently
used

Development environment factors

Hardware platform Stable, no Some changes Platform under
changes under evolution, development Too Soon
expected, but controlled along with
capacity is software
sufficient
Tools availability Tools in place, Tools available, Tools
documented, validated, some invalidated, Too soon
validated development proprietary, or
needed (or major
minimal development
documentation) needed, no
documentation
Configuration Configuration Some No configuration Too soon
management fully controlled configuration controls in place
controls in place

10
Security All areas following No security
following security measures in
security guidelines, data place, backup
guidelines, data backed up, lacking, disaster L
backed up, disaster recovery recovery not
disaster recovery system in place, considered
system in place, procedures
procedures followed
followed Some security
measures in
place, backups
done, disaster
recovery
considered, but
procedures
lacking or not
followed
Vendor support Complete Adequate Little or no
support support support, high L
at reasonable at contracted cost,
price and in price, reasonable and/or poor
needed time response time response time
frame
Staff factors
Staff adherence to Staff in place, no Staff available, Staff not
task Turnover some turnover available, H
expected, expected, some high turnover
working conflict in time expected, many
on assigned allocation, some members spend

11
 tasks, few fire fighting much time fire
diversions and fighting
little fire fighting
Mix of staff skills Good mix of Some disciplines Some disciplines M
disciplines inadequately not represented
represented at all
Product knowledge Very Some experience No experience in
experienced in developing developing this M
at developing this type of type of product
this type of product
product
Software Extensive Some experience Little or no
development experience with with similar experience with M
experience this type of projects similar projects
project
Training of team Training not Training for No training plan
required, or some areas not or training not L
training plan in available or readily available
place and training planned
training for future
ongoing
Team spirit and Strongly Willing to do Little or no
attitude committed to what it takes to commitment to M
success of get the job done the project, not a
project, cohesive team
cooperative
Team productivity All milestones deliverables Productivity low,
met, deliverables on time, milestones not Too soon
on time, productivity high met, delays in

12
 productivity high Milestones met, deliverables
some delays in
deliverables,
productivity
acceptable
Maintenance factors
Complexity Structurally Certain aspects Extremely
maintainable difficult to difficult to Too soon
(low complexity maintain maintain (high
measured or (medium complexity)
projected) complexity)
Change Team in place Team Team is unable
implementation can be experiences to respond to Too soon
responsive delays but customer needs
to customer acceptable to
needs customer
Support personnel In place, Missing some Significant
experienced, areas of discipline or Too soon
sufficient in expertise expertise
number missing

13
 Top Risks Report

ID Risk Item Probability Impact Prevention Correction Who Date

1 Budget underestimated - Low High Nil To have meeting with Project 18/10/2017
The initial budget project stakeholder to Stakehoder
allocation RM 100,000 present the additional Project
was not sufficient where costing of Manager
infrastructure budget has infrastructure to
yet to factor in increase project budget
2 Some requirements are High High Throughout the project When a problem Project 03/11/2017
not clearly defined due to and especially during occurs, the Project Manager
miscommunication among week project meetings, Manager arranges All team
team members. the Project Manager has meeting with all member
Misinterpretation of what to make sure every team involved parties to including
other team members say member understand the come to a common customer
and write might stand in task given by having understanding of the
the way of a common frequent talks with each requirements .
understanding of what to group member including
do and how to do it. This customer.
might lead to delays,
undesired results and
double work.

14
3 Staff not available or Medium High The Project Manager
absence in critical times should make planned
in the project absence a point on the
rst meeting to make sure between these two
that absence that is known
at that time is taken into
account in the schedule.
4 Staff spend much time Low Medium By stimulating the
fire fighting communication between
team members, conicts situation with the team
may be avoided.
Every role has a Project 08/11/2017
person to replace him. Manager
Communication All team
member
people is very
important. The vice
person should be
actively involved in all
work in order to be
able to replace his
counterpart. All
important information
and design decision
should be documented
in documents or
minutes, to make sure
that as little
information as possible
is lost.
The Project Manager Project 14/11/2017
will discuss the Manager
members in an eort to
clear the air.
15