2001ict Projectmanagement Assignment 3

Project Plan
KAAS Solutions
INFO@KAASSOLUTIONS.COM.AU
APRA Enterprise Risk

Management and
Compliance SaaS
2001ICT - Project Management Group 2
Project Plan APRA
Table of Contents
1. Project Charter................................................................................................... 4
1.1 Company Information...................................................................................4
Business Experience........................................................................................ 4
Project Description.......................................................................................... 5
Project Objectives............................................................................................ 5
Project Objectives and Success Criteria...........................................................0
Approach......................................................................................................... 0
Stakeholders - APRA........................................................................................ 1
Stakeholders KAAS Solutions........................................................................1
Start and Finish............................................................................................... 2
Budget............................................................................................................. 2
1.2 Stakeholder Analysis.................................................................................... 3
Stakeholder Analysis Details........................................................................... 3
1.3 Communication Strategy.............................................................................. 5
Team Communication...................................................................................... 5
Stakeholder Communication...........................................................................5
Issue Tracking.................................................................................................. 5
2. Project Scope..................................................................................................... 8
2.1 Project Scope Description.............................................................................8
2.1.1 Functional Scope Description.....................................................................8
Application Security......................................................................................... 8
Data Storage................................................................................................... 8
Risk Management............................................................................................ 8
Compliance Management................................................................................9
2.2.2 User Story Board..................................................................................... 10
Application Security....................................................................................... 10
Data Storage................................................................................................. 10
Risk Management.......................................................................................... 10
Compliance Management..............................................................................11
2.2.3 Assumptions............................................................................................ 12
2.2 Project Deliverables.................................................................................... 12
3. Work Breakdown Structure..............................................................................14
3.1 WBS Tree.................................................................................................... 15
3.2 WBS Table................................................................................................... 16
Page 1 of 73
Project Plan APRA
3.2.1 Work Breakdown Structure Project Procurement...............................16

3.2.2 Work Breakdown Structure Project Development..............................16
3.2.2 Work Breakdown Structure Maintenance...........................................18
4. Estimation........................................................................................................ 19
4.1 Choice of Technique....................................................................................19
4.2 Justification................................................................................................. 19
4.3 Estimation.................................................................................................. 19
Metric Definitions.......................................................................................... 19
Story Points................................................................................................... 20
5. Schedule.......................................................................................................... 24
Gantt chart....................................................................................................... 24
Minimising slippage....................................................................................... 25
Network Diagram.............................................................................................. 25
6. Change Management Plan............................................................................... 26
6.1 Change Management................................................................................. 26
6.1.1 Change Management Approach...........................................................26
6.1.2 Change Control Procedure....................................................................27
6.1.3 Audits and Review................................................................................30
6.2 Configuration Management........................................................................33
6.2.1 Configuration Items.............................................................................. 33
6.2.2 Configuration Management System.....................................................34
7. Risk Management Plan.................................................................................... 36
7.1. Risk Management Strategy.......................................................................36
7.1.1. Risk Identification................................................................................37
7.1.2. Risk Classification................................................................................ 37
7.1.3. Risk Response..................................................................................... 39
7.1.4. Unidentified Risks................................................................................ 40
7.2. Risk Monitoring Strategy........................................................................... 41
7.3. Risk Control Register................................................................................. 42
8. Post Project Review.......................................................................................... 43
8.1 Success criteria.......................................................................................... 43
8.2 Project Achievements................................................................................. 43
8.3 Schedule reporting..................................................................................... 44
8.4 Review of Techniques................................................................................. 46
8.5 Lessons Learned......................................................................................... 46
9. Project Management........................................................................................ 47
9.1 Status Summary......................................................................................... 47
Page 2 of 73
Project Plan APRA
9.2 Task List...................................................................................................... 49

9.3 Time Sheets................................................................................................ 52
Appendices.......................................................................................................... 55
Appendix A Change Request Form.................................................................55
Appendix B Issue Submission Form................................................................57
Page 3 of 73
Project Plan APRA
1. Project Charter
Revision History
Date
30-0714
31-0714
31-0714
01-0814
05-0814
05-0814
05-0814
08-0814
10-0814
10-0814
27-0814
26-0914
26-0914
Versi
on
1.0
Author
Addition / Alteration
Juan L Sajn
1.1
Zyion Attiig
Added company info

Added business experience
Added Project Description
1.2
Juan L Sajn
Added Communication Strategy
1.3
Juan L Sajn
Added Start and Finish Dates
1.4
Zyion Attiig
1.5
Marcus Alroy
Added Risk Management

Added Compliance Management
Added Reporting
1.6
Juan L Sajn
Added Objectives Success Criteria
1.7
Devan Kotze
Added Approach
1.8
Marcus Alroy
1.9
Devan Kotze
Added Stakeholders APRA

Added Stakeholder KAAS
Added Stakeholder Details
2.0
Devan Kotze
Added Budget
2.1
Zyion Attiig
2.2
Marcus Alroy
Amended development approach

Amended start and finish
Added to communication strategy
Added project issue tracking system
Amended Project Description
1.1 Company Information

Project Title:
Compliance (SaaS)
APRA Enterprise Risk Management and
Project Manager:
Juan Luis Sajn
Company Name:
KAAS Solutions
Team Members:
Kotze
Zyion Attiig, Juan Luis Sajn, Marcus Alroy, Devan
Page 4 of 73
Project Plan APRA
Business Experience
KAAS focuses on providing it clients with innovative solutions customized for
their business needs. We are an Australian company that has been in operation
for 2 years. We have previous experience in developing desktop, mobile and web
applications for both small and medium sized businesses. Our aim is to provide
our clients with an innovative and unique experience that will ease the transition
to the new system and provide the most suitable solution possible.
We provide data driven applications that focuses on scalability, data integrity
and security that incorporates the clients pre-existing systems. Our specialties
and experience in developing software applications includes but are not limited
to:
Content Management
Resource Management
Inventory and Stock Control
Purchasing and Ordering Systems
Project Management
Risk and Compliance Maintenance
Project Description
The Australian Prudential Regulation Authority (APRA) is the prudential regulator
of the Australian financial services industry. It oversees banks, credit unions,
building societies, general insurance and reinsurance companies, life insurance,
friendly societies, and most of the superannuation industry.
Currently, the Risk Management and the Compliance Management teams at
APRA carry out their functions with manual processes. APRA is seeking a tender
to procure Software as a Service (SaaS) to manage its enterprise risks and
compliance obligations, which includes automatic allocation, reminders, workflow
and reporting.
The solution that is to be created is to cover around 100 standard users and
around 4 administrators, this solution needs to be cover the business for not only
just present time but also for the future. More employees will be coming to work
with the business so this does need to be an expandable solution.
At the completion of the project the business will need to have a software
solution set up with a secure database set up to store the information and the
current staff will need to be trained on how to use the software.
Project Objectives
The objective of the project is to deliver an Enterprise Risk Management and
Compliance Management SaaS Application to APRA.
Page 5 of 73
Project Plan APRA
The system is to be based on APRAs Enterprise Risk Management Framework

(ERMF) and comply with the ISO 31000 standard for risk management and the
Australian Standard on Compliance 3806-2006.
Risk Management
The risk management capabilities of the system will allow user to create update
and modify risk scenarios and mitigations.
Users will be able to review and approve risk scenarios and mitigations
The framework for risk management will include risk rating tables, risk
categories and risk target and tolerance levels.
Compliance Management
The compliance management capabilities of the system will allow for users to
record, update and modify compliance obligations including risk mitigations and
operating procedures.
Users will be able to review and accept obligations and operating procedures.
The system will use automated workflows that will notify users of assignments,
review, approval and reminders.
Reporting
The system will allow users to produce reports for risks and obligations, including
dashboard capabilities like heat maps, matrices and graphs.
Data and Security
The SaaS application will support secure transmission and storage of data and
comply with the Archives Act of 1983.
The SaaS application will support secure transmission and storage of data.
The system will only be accessible via the use of a secure username and
password.
Hardware
To supply the hardware for the server it has been recommended to use a Cloud
Hosting service as opposed to installing hardware. A hosting service has been
chosen since it will allow for scaling application cost based on data usage.
Maintenance
The system will require a maintenance plan for three years starting from time of
user acceptance.
The maintenance will include database backups, bug and error checking,
performance monitoring and compatibility checking.
Project Objectives and Success Criteria

Project Objective
Success Criteria
Scope
The scope of the project is to deliver

an Enterprise Risk Management and
Compliance Management SaaS
Application to APRA.
Page 6 of 73
Design and Implement an

Enterprise Risk Management
and Compliance Management
SaaS Application
The scop
agreed u
Manager
the Key A
Please see project objectives for

detailed description
Project Plan APRA
Time
The time allocated for the project
development has been divided into a
series of sprints, the sprints will last for
a period of 2 weeks.
Cost
The budget for the project has been
developed by determining the cost to
perform a development sprint by the
number of sprints required.
The cost of a sprint is calculated by the
cost of a staff member for the duration
of a sprint.
The maintenance and support budget
has been developed by calculating the
cost of the estimated hours required per
week.
Additional costs will be listed as
procurement items.
The SaaS Application will

provide suitable report
facilities
The SaaS Application will be
installed and running on a
Cloud Server
The Application will provide
secure login and data storage
KAAS will provide a 3 year
support and maintenance plan
All projec
have sign
by both a
KAAS So
The application development is to

be completed in the allocated
amount of development sprints
The allocated amount of
development sprints was suitable
to complete the project
development
Stakeholder feedback was
delivered in a timely manner
The time
to be agr
project M
and by th
APRA.
The project was developed within

the allocated budget
The quoted budget is comparable
to the actual project costing
The budg
is to be a
project M
and by th
APRA.
The proje
procurem
both the
Solutions
party at
made.
All projec
signed a
authorizi
Solutions
Approach
The development process chosen is an agile development process, as we believe
it will deliver the best results to the client in the shortest possible time. The agile
approach focuses on an iterative approach allowing for a flexible adaptable
development process catered to the needs of the project. The agile development
Page 1 of 73
Project Plan APRA
approach will minimise project risks by allowing for continuous development,

stakeholder feedback and input.
The project development will be conducted in a series of sprints. Each sprint will
last for a period of two weeks and will consist of an analysis, design,
implementation, test and review stage.
The agile approach will focus on delivering a prototype in the early stages that
will be developed into application as the project proceeds. The objective of the
prototype is to deliver the minimum viable product to the client to prevent the
risk of missing scope. Once the prototype has been developed to a stage where
it can fulfil its functions, the development will focus on the user experience,
application performance and prevention of user error.
Development Life Cycle
Justification
The agile development approach has been selected due to its ability to be
flexible and its focus on stakeholder feedback. Using an agile development life
cycle it will be possible for project changes to be implemented at the beginning
of each sprint and the progress can be reviewed as it proceeds. This
development approach will allow to components of the software to be
implemented in stages and planning of the next sprint based on feedback
presented from the previous sprint. By allowing the stakeholders to test a
prototype throughout development lowers the risk of missing project scope and
helps produce a higher quality product to the client.
Page 1 of 73
Project Plan APRA
Stakeholders - APRA
Stakeholder
Raphael Yuki
(Manager),
Martin Griffiths
(Risk
Management and
Manager),
Domingo Alvarez
(Compliance
Management)
Risk Owners and
Obligation
Owners and
delegates
APRA Staff
Members
Qty.
4
Role and Responsibility

Will require Elevated Administrative Access
to Application
Required to verify project specifications and
components completeness
100
Will require Read/Write Access to Application

Will be required to test and provide
Application feedback
600
Currently do not require access
Stakeholders KAAS Solutions

Name
Juan Luis Sajn
Position Title
Project Manager
Client Liaison
Roles and Responsibilities

Develop Project Plan
Liaise with Client Contacts
Manage Team Interactions
Manage Project Progress
Provide Project Task Control
Review Project Components
Marcus Alroy
Systems analyst
Quality Control
Tester
Determine Project Requirements and

Scope
Perform Risk Analysis
Determine Project Feasibility
Validate System Requirements
Validate Project Components
Perform Test Cases
Devan Kotze
User Experience
Design
Develop Prototype
Develop Screen Flows and Screen
Designs
Develop diagrams and UML
Determine Required Input Validation
and Error Checking
Design Reports
Develop User Interface
Zyion Attiig
Software
Engineer
Develop Technical Requirements

Specifications
Implement System Components
Integrate System Components
Page 2 of 73
Project Plan APRA
Develop Test Cases

Perform Test Cases
Start and Finish

The project development has been broken down into a series of six sprints, each
sprint will last for a period of two weeks. This means that the development will
last for a period of twelve weeks in total.
The project start date is determined by the expected date to procure the project
contract, this is dependent on timely feedback to the third submission to the
proposal.
The project has been estimated to start on Monday 3 rd of November and
conclude on Friday 30th of January. These dates have allowed for a week break
between the Christmas and New Year break.
Budget
The budget for the project has been determined by breaking down the project
development into a series of development sprints. The cost of a development
sprint is $8000 the cost has been calculated by determining the cost of four
developers and the overhead of the resources required.
The project will also incur the monthly cost of server hosting and project support
and maintenance.
Item
Development Sprints x6
Microsoft Azure Server Hosting
3 years support and maintenance
Page 3 of 73
Cost
$48 000
$800 per month
$800 per month
Project Plan APRA
1.2 Stakeholder Analysis

Name of Client Liaison:
Juan Luis Sajn
Stakeholder Analysis Details

Stakeholder
Information
Required
Raphael Yuki
(Manager),
Martin Griffiths
(Risk
Management and
Manager),
Domingo Alvarez
(Compliance
Management)
Risk Owners and

Obligation
Owners and
delegates
Project Manager
and Client
Liaison.
Work Products
Project Plan
Project
Agreement
Test Reports
Progress Reports
End User
Documentation
Training
Design
Specifications
End User
Documentation
Training
Project
Completion
Project Plan
Client
Agreement
Project Tasks
Communication
Methods
APRA Stakeholders
Administrative
Meetings
Reports
Access to
Application
Email
Project Plan
Phone
Project
Application Tests
Agreement
Feedback
User Tests
Results
Read Write
Access to
Application
User Tests
User Feedback
Application Tests
Feedback
Results
Email
KAAS Stakeholders
Project Plan
Meetings
Client
Reports
Email
Agreement
SaaS Application Phone
Page 4 of 73
Strategy
APRA management will report directly to the

KAAS project manager.
APRA management is required to verify the
project agreement and plan before work can
commence.
APRA management will send application
feedback and test results directly through the
SaaS application.
APRA risk and obligation owners will report
directly to their management, but can
address concerns to KAAS via the project
manager.
APRA risk and obligation owners will send
application feedback and test results directly
through the SaaS application.
The Project Manager will pass information

and reports to and from APRA to KAAS.
The project manager will develop a project
Design
Specifications
Test and Bug
Reports
User feedback
Project Plan APRA

agreement and plan to be verified by APRA
management before work is commenced.
Design
Specifications
The project development team will report

directly to the project manager.
The project manager will monitor the
communication process and ensure that the
appropriate information is being received by
both parties in order to prevent
communication breakdowns.
Project
Development
Team
Project Plan
Project Tasks
Design
Specifications
Server Access
Test and Bug
Reports
User feedback
Project Plan
SaaS Application
Design
Specifications
Email
Meetings
Reports
Phone
The Development Team uses Scrum

management to track team progress and
allocate resources effectively.
The Development will report directly to the
KAAS project manager.
The Development Team will receive user
feedback and test reports.
Page 5 of 73
Project Plan APRA
1.3 Communication Strategy

Team Communication
The team will use several communication methods during the project the main
one being scrum meeting. A team scrum meeting will be performed each
morning to keep the team on track and informed of progress. This is also a handy
time to receive team feedback and progress reports.
The team are issued project tasks through the use of task management software.
The software system allows the project manager to issue a task to a developer
and attach and receive feedback and status updates about the task. The
software allows the project manager to control who is working on what task and
what task need to be completed.
Stakeholder Communication
The main method of communication for the projects stakeholders is via email.
The email system will allow for communication history and tracking of
conversations. There are several documents that have been created to manage
communication events like project changes and issues.
Stakeholders are informed of project progress at the end of each sprint cycle in a
sprint report. The sprint report will provide information about project milestones,
project changes and the progress. As well as a sprint report the project manager
will review the project with the management team from APRA.
Issue Tracking
To track and manage project issues the project manager will use a project issue
log. This log will be used to manage the status of any issues that may occur that
effect the time, cost, quality, scope and resources. Project issues can be
submitted to the project manager directly or via email, a project issue
submission form has been created for the project. The log will be reviewed by the
development team at the beginning and end of each sprint cycle. The project
manager will update the log as issues are discovered or resolved. The project
issues will be distributed to team members and APRA management only in a
sprint report.
Page 6 of 73
Communication
Required
Project
Authorisation
Verification
Project Changes
Who
Project Plan APRA
Communication Method
Project Manager
Signed hard copy
APRA Manager
Signed hard copy
Project Progress
Project Manager
Project Progress
Development Team
Risk Occurrences
Project Manager
Risk Occurrences
Development Team
Project Tasks
Development Team
Communication
Breakdown
Errors Bugs
APRA Manager
Development Team
End Users
End Users
User Tests
End Users
Presentation Meeting
Email
Scrum Meeting
Email
Email
Phone
Meeting
Email
Phone
Meeting
Task Management Tool
Scrum Meeting
In Person
Email
Phone
Through Application Error
Logs and Bug Reports
Test Report
Email
Page 7 of 73
When to Report
Report to
Before
Commencement of
Sprint
Before
Commencement of
Sprint
Sprint Completion
APRA Manager
Sprint Completion
Project Manager
Immediately
APRA Manager
Immediately
Project Manager
Task Completion
Project Manager
Immediately
Project Manager
Immediately
Development Team
End of test phase
Development Team
Project Manager
APRA Manager
Project Plan APRA
Project Issue Log

ID No.
Description
Solution
Impa
ct
Rati
ng
Submitted By
Date
Received
Stat
us
Date
Rectified
I-001
I-002
*Impact Rating: Low = components function as intended, Med = functionality is effected, High = component does not function
*Status: O = Open, C = Closed
Page 8 of 73
Project Plan APRA
2. Project Scope
Revision History
Date
06-0814
12-0814
12-0814
26-0914
Versi
on
1.0
Author
Devan Kotze
Added Scope Statement
1.1
Devan Kotze
Added Scope Description
1.2
Zyion Attiig
1.3
Zyion Attiig
Added Application Security

Added Data Storage
Amended project deliverables
2.1 Project Scope Description

2.1.1 Functional Scope Description
ID
No.
Functional Description
Priorit
y
Rating
M
H
M
H
Application Security
1.0
1.1
1.2
1.3
The application will provide a secure connection using

SSLv3.1 and TLS v1.2.
The system will only be accessible via the use of a
username and password.
The system will consist of two access levels
administrative and a general user access level.
Usernames and passwords will be encrypted.
Data Storage
2.0
2.1
2.2
2.3
2.4
The SaaS application will be built for Microsoft Azure

Cloud server
The SaaS application will use Microsoft Active Directory
The application data will be stored using Microsoft SQL
Server 2012.
The database data will be encrypted and will require
secure access
The data storage will comply with the Archives Act of
1983.
Risk Management
3.0.
0
3.0.
1
The Enterprise Risk Management (ERM) SaaS will be

used by APRA to assist in the management of its
enterprise risks and mitigation based on APRAs
Enterprise Risk Management Framework (ERMF).
The service must provide risk owners with visibility and
ownership of their risks, and the ability to assign and
approve risks.
Page 9 of 73
Project Plan APRA
Ability to Manager Risk Scenarios and Mitigation

3.1. The application will be able to create modify and update
0
risk scenarios including emerging risks.
3.1. The application will have search and filter search results
1
and view risk scenarios and mitigations.
3.1. The application will be able to assign owners to risk
2
scenarios and mitigations.
3.1. The application will be able to enter risk consequence
3
and likelihood.
3.1. The service will be able to calculate a risk rating based
4
on the risk rating model.
Ability to Manage Risk Framework
3.2. Risks can be organised into categories and hierarchies,
0
which can then be updated.
3.2. The risk rating model can be configured for; all risks, risk
1
categories and to individual risk scenarios.
Ability to Configure Workflow for Managing Risks
3.3. The application will provide configurable workflows
0
based on APRAs risk management process.
3.3. The application will be able to set reminders and
1
notifications for managing risks and mitigations.
3.3. Risks will have an approval and review process.
2
3.3. Attestations can be made and viewed by risk owners
4
and approved by workflow.
Ability to Report
3.4. Reports will be sortable and will be able to be filtered to
0
show only relevant results.
3.4. Reports will be able to generate risk matrices that can
1
provide coloured indications of high-risk areas.
3.4. Reports will provide some graph and chart capabilities.
2
3.4. Reports will be exportable to Ms Word and Ms Excel.
3
4.0.
0
4.0.
1
The Compliance Management SaaS will assist APRA to

manage its compliance obligations
The solution will enable obligation owners and
compliance management manager greater visibility of
the obligations
Compliance with Standard
4.1. The Compliance Management system will be required to
0
comply with the Australian Standard AS 3806-2006.
Ability to Manage Obligations
4.2. Ability to create, update and modify compliance
0
obligations
4.2. Ability to search and view obligations
1
3.2. Ability to create, update and modify risk mitigation
2
strategies for an obligation
Page 10 of 73

4.2.
3
4.2.
4
4.2.
5
Project Plan APRA
Ability to create, update and modify operating

procedures for an obligation
Ability to assign obligations to an owner or delegate
Ability to enter risk ratings, consequence and likelihood

for not complying with obligations utilising the risk
management framework
Ability to calculate the risk rating utilising the risk
management framework
Ability to link risk scenarios with a compliance obligation
Priorit
y
Rating
4.2.
6
4.2.
7
Ability to Configure Workflow Obligations
4.3. Compliance workflows will be configured based on
0
APRAs compliance management process
4.3. The system will produce reminders and notifications of
1
the due date of obligations automatically
4.3. Obligations will be able to be approved and reviewed
2
through workflow
4.3. Attestations by obligation owners can be viewed, signed
3
and approved by workflow
Ability to Report
4.4. Reports on obligation information can be prepared by
0
information on obligation, owner, due date, age, noncompliance
4.4. Reports will be configurable as required by the use of
1
sorts and filters
4.4. Reports will provide dashboard capabilities like heat
2
map, matrices and graphs
4.4. Reports will be exportable to Ms Word and Ms Excel.
3
2.2.2 User Story Board

ID
No.
User Story
1.0
1.1
1.2
1.3
The users will connect to the application with a secure

connection using SSLv3.1 and TLS v1.2.
Users will only be able to access the application via the
use of a username and password.
Risk owners and obligation owners will receive greater
visibility and flexibility in managing risks and obligation
that they are responsible for.
Users name and passwords will be encrypted for
security
Data Storage
2.0
The users will connect to the Microsoft Azure Cloud

Page 11 of 73
2.1
2.2
2.3
2.4
Project Plan APRA
server
The users will use Microsoft Active Directory
The application users will store data in the Microsoft SQL
Server.
The users data will be encrypted and will require secure
access to the database
The users will store data in compliance with the Archives
Act of 1983.
M
H
M
H
Risk Management
3.0.
0
The users will be able to assist in the management

APRAs enterprise risks and mitigation based on APRAs
Enterprise Risk Management Framework (ERMF).
3.0. Risk owners will be presented with visibility and
1
ownership of their risks, and the ability to assign and
approve risks.
Ability to Manager Risk Scenarios and Mitigation
3.1. Users will be able to create modify and update risk
0
scenarios including emerging risks.
3.1. Users will be able to search and filter search results and
1
view risk scenarios and mitigations.
3.1. Users will be able to assign owners to risk scenarios and
2
mitigations.
3.1. Users will be able to enter risk consequence and
3
likelihood.
3.1. Users will be able to calculate a risk rating based on the
4
risk rating model.
Ability to Manage Risk Framework
3.2. Users will be able to organise risks into categories and
0
hierarchies, which can then be updated.
3.2. Users can configure the risk rating model for; all risks,
1
risk categories and to individual risk scenarios.
Ability to Configure Workflow for Managing Risks
3.3. Users will be able to configure workflows based on
0
APRAs risk management process.
3.3. Users will be able to set reminders and notifications for
1
managing risks and mitigations.
3.3. Users will be able to approve and review risks.
2
3.3. Risk owners can make attestations which can be viewed
4
by risk owners and approved by workflow.
Ability to Report
3.4. Users will be able to Reports will be able to sort and
0
filter reports to show only relevant results.
3.4. Users will be able to generate risk matrices that can
1
provide coloured indications of high-risk areas.
3.4. Users will be able to generate reports that provide some
2
graph and chart capabilities.
3.4. Users will be able to export reports to Ms Word and Ms
3
Excel.
Page 12 of 73
Project Plan APRA
4.0. The users will be able to assist APRA to manage its
0
compliance obligations
4.0. Obligation owners and the Compliance Management
1
Manager will receive greater visibility of the obligations
Compliance with Standard
4.1. The Compliance Management teams using the system
0
will operate in compliance with the Australian Standard
AS 3806-2006.
Ability to Manage Obligations
4.2. Users will have the ability to create, update and modify
0
4.2. Users will have the ability to search and view obligations
1
2
risk mitigation strategies for an obligation
3
operating procedures for an obligation
4.2. Users will have the ability to assign obligations to an
4
owner or delegate
4.2. Users will have the ability to enter risk ratings,
5
consequence and likelihood for not complying with
obligations utilising the risk management framework
4.2. Users will have the ability to calculate the risk rating
6
utilising the risk management framework
4.2. Users will have the ability to link risk scenarios with a
7
compliance obligation
Ability to Configure Workflow Obligations
4.3. Users will have the ability to configure Compliance
0
workflows based on APRAs compliance management
process
4.3. Users will be able to produce reminders and notifications
1
of the due date of obligations automatically
4.3. Users will be able to be approve and review obligations
2
through workflow
4.3. Obligation owners can make attestations that can be
3
viewed, signed and approved by workflow
Ability to Report
4.4. Users can prepare reports on obligation information by
0
4.4. Users will be able to sort and filter reports to show only
1
relevant results.
4.4. Users will be able to produce reports with dashboard
2
capabilities like heat map, matrices and graphs
4.4. Users will be able to export reports to Ms Word and Ms
3
Excel.
Page 13 of 73
Project Plan APRA
2.2.3 Assumptions
ID
1
2
3
4
Assumption
Users will require Internet Access and a Web Browser to Access the SaaS
Application
Ms Office is not supplied but application will send data to Ms Word and Ms
Excel
No server or computer hardware will be supplied but a hosting service for
the server has been recommended.
Transferral of data to the new system is not included.
2.2 Project Deliverables

Deliverable
Screen Designs and
Screen Flows
Prototype
Ms SQL Data
Management System
SaaS Application
Source Code
Description
The screen designs of the
Application and the flows
of direction from one
screen to another will be
produced as a document
The prototype will be a
development version of
the interface with limited
functionality.
This systems is needed

to store the data that is
being input by the
employees of APRA.
The cloud program that
will be made for the
users so that they are
able to easily add and
manage risks.
The source code for the
project. This is generally
stored in a git repository.
Meeting Minutes
The meeting minutes

from both staff meetings
and meetings APRA
management
End User
Documentation
Documents and help for

the clients to go to after
the product has been
delivered.
Page 14 of 73
When
End of the design sprint
Delivered at the end of

the prototype
development sprint and
updated and presented
till UI specifications are
met
On project completion.
The source code for the

project will be available
via git. The source code
will be submitted at the
end of the project to
APRA
These will be made
available to all that
attended the meeting on
conclusion of the
meeting.

End User Training
3 years Support and

Maintenance
Test Reports
Project Reports
Bug Reports
Project Plan
User Training to help

smooth the transition to
the new software
solution.
Backing up of the
database, Performance
checks, checking of bug
reports and Reviewing of
the application.
The reports and
statistical information
received from the testing
phase
Reports on the
production of the
software and the
productivity of the
project overall.
Bug reports will be stored

on the server and serious
bug reports will be
emailed directly to KAAS
Solutions
Project plan consisting of
an Introduction, scope
statement, feasibility
report, work breakdown
structure.
Page 15 of 73
Project Plan APRA

Training broken into a few
sections when the project
is being integrated.
From the project
completion to three years
from then.
End of Application test

phase
Reports will be delivered

at the end of each phase
of the project, at the end
of the project a larger
report will be given with
more details.
Maintenance and support
reports will be given after
the software has been
implemented.
As bugs occur
The project plan will be

delivered as the first
stage submission for
tender.
Project Plan APRA
3. Work Breakdown Structure

Revision History
Date
20-0814
26-0914
Versi
on
1.0
Author
Devan Kotze
2.0
Zyion Attiig
Added Project Procurement

Added Project Developments
Amended WBS Tree
Page 16 of 73
Project Plan APRA
3.1 WBS Tree
Please see attached image
Page 17 of 73
Project Plan APRA
3.2 WBS Table

3.2.1 Work Breakdown Structure Project Procurement
Task
ID
0.1.0
0.2.0
0.3.0
0.4.0
Task
Produce a project plan consisting of an
Introduction, scope statement,
feasibility report, work breakdown
structure.
First Stage Submission to request
Proposal
Stage one revision, project estimation,

project schedule, change approach
outline.
Second Stage Submission to Request
Proposal
0.5.0
Stage two revision, risk analysis.
0.6.0
Final Submission to Request Proposal
Duration
Predecessors
Monday 28
July 2014
Client request
for proposal
Monday 28
July 2014 5pm, Friday
29 Aug
2014
September
2014
0.1.0
September
2014 - 5pm,
Friday 26
Sep 2014
October
2014
October
2014 Sunday 19
Oct 2014
Stage 1
Evaluation and
Feedback
0.3.0
Stage 2
Evaluation and
Feedback
0.5.0
3.2.2 Work Breakdown Structure Project Development

Task
ID
1.0.0
1.1.0
1.1.1
1.2.0
1.3.0
1.3.1
1.3.2
1.4.0
1.4.1
Task
Duration
First Sprint User Needs Analysis

Implement Scope Requirements for
Application Security and Data Storage
Review Project Scope and Submission
Feedback
Amend any changes required to
specifications
Setup Team Communication Channels
and Allocate Project Resources
Develop Technical Specifications, charts
diagrams
Develop Screen Designs
Design Screen Flows
Procure SaaS Application Server Hosting
Configure Server Connection
2 weeks
Page 18 of 73
Predecessors
1 Day
1.0.0
1 Day
1.1.0
1 Day
1.1.1
3 Days
1.1.0
3 Days
2 Days
1 Day
1 Day
1.3.0
1.3.0
1.1.1
1.4.0

1.4.2
1.4.3
1.5.0
1.5.1
1.6.0
1.6.1
2.0.0
2.0.1
2.0.2
2.1.0
2.1.1
2.2.0
2.2.1
2.3.0
2.3.1
3.0.0
3.0.1
3.0.2
3.1.0
3.1.1
3.1.2
3.2.0
3.3.0
3.3.1
4.0.0
4.0.1
4.0.2
4.1.0
4.1.1
4.2.0
4.3.0
4.4.0
3.4.1
5.0.0
Configure Database Server

Configure User Accounts and Active
Directories
Test Server Secure Connection
Test Designs with Specification
Review Designs and Specifications with
Key Stakeholders
APRA Approves and Validates Designs
Second Sprint Prototype
Develop Prototype of Risk Management
and Compliance Management System
Review Project Designs
Implement Required Changes
Implement Database Table Structures
Test Database Table Structure
Develop Prototype Screen Designs
Test Prototype
Review Prototype with Key Stakeholders
APRA Approves and Validates Prototype
Third Sprint Implementation
Implement functionality into Prototype
Review Project Prototype and
Specifications
Implement Application Database
Connection
Implement Application Data Access Layer
Implement Application Business Logic
Layer
Test Functional Prototype
Review Functional Prototype with Key
Stakeholders
APRA Approves and Functional Prototype
Fourth Sprint - User Experience and
Feedback
Test performance and effectiveness of
application and ability to manage errors
Review Project Prototype and
Specifications
Implement Application Workflow
Management
Test Application Workflows
Implement User Error Control and Input
Validation
Alpha Testing User Experience and
Performance Testing
Review Testing with Key Stakeholders
User Accepts Application Functionality
Fifth Sprint Reports
Implementation
Page 19 of 73
Project Plan APRA

1 Day
1 Day
1.4.1
1.4.1
1 Day
1 Day
0.5 Days
1.4.1
1.4.2
1.5.1
0.5 Days
2 weeks
1.6.0
1.6.1
0.5 Days
1 Days
5 Days
2 Days
5 Days
2 Days
0.5 Days
0.5 Days
2 weeks
2.0.0
2.0.1
2.0.2
2.1.0
1.6.1
2.2.0
2.2.1
2.3.0
2.3.1
0.5 Days
3.0.0
1 Days
1 Days
3.0.1
3.0.2
4 Days
4 Days
3.0.2
3.0.2
2 Days
0.5 Days
3.1.2
3.2.0
0.5 Days
2 weeks
3.3.0
3.3.1
0.5 Days
4.0.0
1 Days
3 Days
4.0.1
4.0.2
2 Days
5 Days
4.1.0
4.1.1
3 Days
4.2.0
1 Day
0.5 Days
2 weeks
4.3.0
4.4.0
4.4.1
5.0.1
5.0.2
5.1.0
5.1.1
5.1.2
5.1.3
5.2.0
5.3.0
5.4.0
5.4.1
6.0.0
6.0.1
6.0.2
6.1.0
6.1.1
6.2.0
6.3.0
6.4.0
Implement reporting System and

improvements
Review Project Prototype, Specifications
and Test Feedback
Implement Reports
Implement Report dashboard capabilities
like heat map, matrices and graphs
Implement report exporting capabilities
to Ms Office
Test Reporting System
Customise User Experience and Improve
Application Performance
User Alpha Testing
Review Testing with Key Stakeholders
APRA Approves Application Suitability
Sixth Sprint Integration
The Application will be integrated into a
production environment
Review Project Prototype, Specifications
and Test Feedback
Application is integrated into production
environment
User Beta Testing
Develop End User Documentation
User Acceptance Testing
APRA Accepts Completion of Project
Scope
Project Plan APRA
0.5 Days
5.0.0
1 Days
4 Days
3 Days
5.0.1
5.0.2
5.1.0
3 Days
5.1.1
2 Days
3 Days
5.1.2
5.1.3
3 Days
1 Day
0.5 Days
2 weeks
5.2.0
5.3.0
5.4.0
5.4.1
0.5 Days
6.0.0
1 Days
3 Days
6.0.1
6.0.2
2 Days
5 Days
5 Days
0.5 Days
6.1.0
6.0.2
6.1.1
6.3.0
Duration
Predecessors
3 Year
Plan
Integration
3.2.2 Work Breakdown Structure Maintenance

Task
ID
M
M
M
M
M
0.0
0.1
0.2
1.0
1.1
Task
Maintenance
Maintenance duration is calculated by
the amount of time allocated each week
to the specific task.
Backup Database
Receive Bug Reports
Review Application
Provide Application Support
Provide Application Reports to Key
Stakeholders
Page 20 of 73
0.5
0.5
0.5
0.5
0.5
Days
Days
Days
Days
Days
6.4.0
6.4.0
6.4.0
6.4.0
6.4.0
Project Plan APRA
4. Estimation
Revision History
Date
250914
Versi
on
1.0
Author
Devan Kotze
Completed choice of technique

Completed Justification
Completed Estimation
4.1 Choice of Technique

In this project, KAAS Solutions will use the agile story point counting technique to
count story points.
4.2 Justification
The Agile story point counting technique was chosen as it was the most
appropriate for the agile approach. The appointed to work on Enterprise Risk
Management and Compliance is fairly new and needs an elastic environment in
order to adjust to the pace of the team as a whole. Agile story point counting will
allow for elasticity.
All Agile requirements will be displayed as user stories with each having a rating of
complexity. Due to the project being large in size, it along with its features should
be estimated for example sprints, risk and time required. This also justifies the
chosen estimation technique. The teams development rate will be updated after
each sprint in order for the estimation to be as accurate as possible.
4.3 Estimation
Metric Definitions
Sprint - The project is to be conducted using Sprints x 6
Effort - the number of the team members (rating of 1 to 5) required to

work on the user story.
Risk - the possibility of something going wrong on any particular user

story (rating of 1 to 5).
Resources - the amount of hardware, software, equipment and money

that is required to work on the project.
Page 21 of 73
Project Plan APRA
Level Of Complexity (User Story Totals)

Value of Total
Level
1-8
Low
8-16
Medium
16-20
High
Page 22 of 73
Project Plan APRA
Story Points
ID
No.
User Story
1.0
1.1
1.2
1.3
2.0
2.1
2.2
2.3
2.4
3.0.0
3.0.1
3.1.0
3.1.1
3.1.2
Priori
ty
Sprin
t
Effort
Risk
Resour
ces
Total
The users will connect to the application with a secure

connection using SSLv3.1 and TLS v1.2.
Users will only be able to access the application via the use
of a username and password.
Risk owners and obligation owners will receive greater
visibility and flexibility in managing risks and obligation that
they are responsible for.
Users name and passwords will be encrypted for security
1,2
10
11
The users will connect to the Microsoft Azure Cloud server

The users will use Microsoft Active Directory
The application users will store data in the Microsoft SQL
Server.
The users data will be encrypted and will require secure
access to the database
The users will store data in compliance with the Archives Act
of 1983.
H
M
H
1,2
4
1,2
2
2
3
2
2
2
2
2
3
6
6
8
1,2
11
1,2
The users will be able to assist in the management APRAs

enterprise risks and mitigation based on APRAs Enterprise
Risk Management Framework (ERMF).
Risk owners will be presented with visibility and ownership of
their risks, and the ability to assign and approve risks.
1,2
1,2
Users will be able to create modify and update risk scenarios

including emerging risks.
Users will be able to search and filter search results and view
risk scenarios and mitigations.
Users will be able to assign owners to risk scenarios and
mitigations.
1,2
Page 23 of 73
Project Plan APRA
3.1.3
3.1.4
Users will be able to enter risk consequence and likelihood.

Users will be able to calculate a risk rating based on the risk
rating model.
M
L
5
6
1
1
1
1
1
1
3
3
3.2.0
Users will be able to organise risks into categories and

hierarchies, which can then be updated.
Users can configure the risk rating model for; all risks, risk
categories and to individual risk scenarios.
1,2
11
1,2
H
M
1,2
4
1
2
2
2
2
2
5
6
Users will be able to sort and filter reports to show only

relevant results.
Users will be able to generate risk matrices that can provide
coloured indications of high-risk areas.
Users will be able to generate reports that provide some
graph and chart capabilities.
Users will be able to export reports to Ms Word and Ms Excel.
11
The users will be able to assist APRA to manage its

Obligation owners and the Compliance Management Manager
will receive greater visibility of the obligations
1,2
1,2
4.1.0
The Compliance Management teams using the system will

operate in compliance with the Australian Standard AS 38062006.
1,2
11
4.2.0
Users will have the ability to create, update and modify

1,2
10
3.2.1
3.3.0
3.3.1
3.3.2
3.3.4
3.4.0
3.4.1
3.4.2
3.4.3
4.0.0
4.0.1
Users will be able to configure workflows based on APRAs

risk management process.
Users will be able to set reminders and notifications for
managing risks and mitigations.
Users will be able to approve and review risks.
Risk owners can make attestations which can be viewed by
risk owners and approved by workflow.
Page 24 of 73

4.2.1
3.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.3.0
4.3.1
4.3.2
4.3.3
4.4.0
4.4.1
4.4.2
4.4.3
Project Plan APRA
Users will have the ability to search and view obligations

Users will have the ability to create, update and modify risk
mitigation strategies for an obligation
Users will have the ability to create, update and modify
operating procedures for an obligation
Users will have the ability to assign obligations to an owner
or delegate
Users will have the ability to enter risk ratings, consequence
and likelihood for not complying with obligations utilising the
risk management framework
Users will have the ability to calculate the risk rating utilising
the risk management framework
Users will have the ability to link risk scenarios with a
compliance obligation
H
H
1,2
3,4
2
3
1
2
3
2
6
7
1,2
1,2
1,2
Users will have the ability to configure Compliance workflows

based on APRAs compliance management process
Users will be able to produce reminders and notifications of
the due date of obligations automatically
Users will be able to be approve and review obligations
through workflow
Obligation owners can make attestations that can be viewed,
signed and approved by workflow
Users can prepare reports on obligation information by

Users will be able to sort and filter reports to show only
relevant results.
Users will be able to produce reports with dashboard
capabilities like heat map, matrices and graphs
Users will be able to export reports to Ms Word and Ms Excel.
14
12
12
Totals
Page 25 of 73
11
113
99
117
329
Project Plan APRA
Each sprint will be will be re-evaluated and updated according to the results
obtained from the last one. This will ensure that everyone has a clear and
accurate understanding of how much time, and resources each user story will
require in order to complete.
Page 26 of 73
Project Plan APRA
5. Schedule
Revision History
Date
24/09/
14
25/09/
14
25/09/
14
26/09/
13
Versi
on
1.1
Author
Marcus Alroy
Added Minimising slippage
1.2
Marcus Alroy
Completed Minimising slippage
1.3
Zyion Attiig
Created Gantt chart
1.4
Marcus Alroy
Inserted Gantt chart and network

diagram
Gantt chart

Page 27 of 73
Project Plan APRA
Minimising slippage
Minimising delays and sticking to the schedule is a huge focus for this project,
slipping past due dates is something that can hinder the performance of the
entire group which will in turn lead to quality lacking later on during the progress
of the project. We have taken many steps to try make the process of completing
this project easier for everyone that is going to be working on the project, the
risks of the project have been assessed by the group and the organisation of the
schedule and workloads have been set out to try minimise the risks that the
team will face as we work on this project.
For this project to go smoothly the team and the client will need to prepare for
the training time when the new software is being deployed, another issue that
will need to be done is some basic stress testing which may put some delays on
the project if anything is needing to be repaired or redone.
We have created a network diagram and a Gantt chart for this project, the
reasons behind these choices are that we are able to show the data in an easier
to understand format while still being able to show the critical path of the project
so that it is clear to the stakeholders.
In order to show the stakeholders that the project is sticking to schedule and is
keeping up with a certain amount of quality we have opted for a system where
change revision is a task that must be performed at the beginning and the end of
a section during the project. This system is beneficial to the entire project and
also to the stakeholders as it keeps the team updated with the opinions of the
clients or stakeholders. At the beginning of each section we get check over the
feedback of previous projects and attempt to cover the issues that we might
receive back from the stakeholders before we send the section for feedback.
After a section of a project has been completed we take the completed work over
to the stakeholders and gather their opinions, after the opinions of the company
stakeholders have been gathered we are able to edit that section of the project
so that by the end of the project we will not need to spend extra time going back
to old work.
Network Diagram
Page 28 of 73

Page 29 of 73
Project Plan APRA
Project Plan APRA
6. Change Management Plan

Revision History
Date
17-0914
Versi
on
1.1
Author
Zyion Attiig
Completed Change Management

Approach
Completed Change Control Register
Completed Change Request Form
Completed Change Management
Procedure
Completed Change Procedure Flow
Chart Completed Audits and Review
Completed Review Procedure Flow
Chart
Completed Configuration Management
Completed Configuration Items
Completed Configuration Management
System
Amended Change Management
Procedure
Amended Configuration Management
Amended Change Request Form
Amended Change Procedure Flow
Chart Amended Audits and Review
Amended Review Procedure Flow Chart
20-914
1.2
Zyion Attiig
24-914
1.3
Zyion Attiig
6.1 Change Management

6.1.1 Change Management Approach
There are several key elements involved in the change management strategy for
the project, the project manager from KAAS Solutions will oversee this process.
Each request for change will need to be managed effectively through the proper
means of communication. Change requests will sent directly to the project
manager as a change request form and logged into the change control register.
The change control register is primarily used by the project manager to track and
monitor the status of each change request.
Before a change can be implemented into the project the impacts of the change
must be determined. Implementing the change is discussed with the
Page 30 of 73
Project Plan APRA
development team members who develop a technical solution. The solution to

the change is then presented to the APRA Change Review Board (CRB) that has
the ability to accept, reject or redesign the proposal. The project manager will
send a change impact report to the CRB at the end of each sprint cycle.
The project manager has several systems in place to manage change and
reconfigure items. The development team are informed of changes and kept up
to date with the current project scope with morning scrum meetings. Task
management software is used by the development team to keep updated with
the latest project information. The development team uses a system of version
control software to maintain the integrity of configuration items and minimise the
impact of implementing project changes.
Change Hierarchy
6.1.2 Change Control Procedure

The following procedure has been developed for a safe integration of each
change request;
1. A change request document is submitted
A change request document must be completed and sent to the project
manager. The project manager will be responsible for overseeing the
change request and monitoring the status of the change. Change Request
Form
2. The change control register is updated by project manager
A change control register will be used throughout the project development
to record and monitor the status and details of each change request. The
project manager will be required to keep the change control register up to
date and ensure that change requests are added. Change control register
Page 31 of 73
Project Plan APRA
3. Change impact is assessed

Each change request will need to be analysed to determine the project
impact, this will be performed mainly by the project manager. The project
manager will consult with the stakeholders effected by the change and
determine the change impact.
4. Proposed specifications are developed
Once the impact is determined the development team will determine the
specifications for the change and produce new design and specification
documents.
5. Approval of change
The change specifications will be sent to APRA Change Review Board
(CRB) and will need to be approved by both the project manager and the
CRB. If the change specification are approved they will be implemented, if
not the will have to option to close or redesign the change request
specifications.
6. Update configuration items
The configurations items for the project need to be updated with new
versions and reissued to the effected stakeholders. These changes will
need to be verified by the project manager before release to ensure all
specifications are met. Configuration item history record
7. Implement changes
The amended configuration items are presented to the team in their
morning scrum meet. The changes are implemented into the project and
development tasks are issued. The development team submit completed
project changes via source code management, the project tasks are
checked for quality by the project manager. If the project task has been
completed successfully the project manager integrates them into the
project and marks it as ready for review.
8. Review Change Implementation
The project items are reviewed and the actual impact of the change will be
compared to the estimated impact of the change by both the CRB and the
project manager. If the change is completed to the specification the
change will be marked as closed or else it will be reissued as a new
version.
Page 32 of 73

Change Procedure Flow Chart
Page 33 of 73
Project Plan APRA
Project Plan APRA
6.1.3 Audits and Review

The project manager communicates with the development team at the beginning
of each day in a morning scrum meeting, this is to ensure that the developers
are aware of their tasks and their task requirements. The project manager issues
tasks to each team member with the use to task management software that
sends the team member the required information.
When a team member completes a task he reports to task status via the task
management software to the project manager and uploads the completed
module to the source code repository. When the project manager receives the
task complete update from the developer he checks it against specifications and
validates that it meets requirements. If the module meets requirements the task
will be marked as completed and the module will be integrated into the project. If
there is a variance between the task requirements and the submitted module the
task is reissued or redesigned depending on the developer feedback.
For a project change objective can be marked as completed it must be presented
to the APRA Change Review Board to authorise that the requirements have been
completed. If a project objective has not been completed correctly the CRB can
have the development team review and redesign the variance. Once a project
objective has been authorised by the CRB it can then be marked as complete
and the change request will be closed.
Page 34 of 73
Review Procedure Flow Chart
Page 35 of 73
Project Plan APRA
Project Plan APRA
Change Control Register

ID No.
Title
Description
Impa
ct
Rati
ng
Requested By
Date
Received
Stat
us
Date
Implemen
ted
C-001
C-002
*Impact Rating: Low = minor change single components, Med = functionality changed multiple components, High = redesign
effects all components
*Status: A = Approved, D = Declined, S = Submitted for approval.
Page 36 of 73
Project Plan APRA
6.2 Configuration Management

6.2.1 Configuration Items
Configuration
Item
Change Register
Baseline
Requirements
Scope
Project
Objectives
Acceptance
Criteria
WBS
Budget
Schedule
Risk Matrix
Designs
The change register is baselined as version 1.0 at the

completion of the project plan.
Re-baselined daily during the project by the project
manager as change request forms are submitted and
change request status changes.
The requirements are baselined as version 1.0 at the
Re-baselined during the project when changes are
accepted that effect the project requirements.
The project scope is baselined as version 1.0 at the
accepted that effect the project scope.
The project objectives is baselined as version 1.0 at
the completion of the project plan.
accepted that effect the project objectives.
The acceptance criteria is baselined as version 1.0 at
the completion of the project plan.
accepted that effect the project acceptance criteria.
The WBS is baselined as version 1.0 at the
accepted that effect the project WBS plan.
The budget is baselined as version 1.0 at the
accepted that effect the project budget.
The schedule is baselined as version 1.0 at the
accepted that effect the project schedule.
The risk matrix is baselined as version 1.0 at the
Re-baselined during the project when new risks are
foreseen, changes to components are made or new
components are added to the project, a risk
assessment will need to be performed.
The design specifications are baselined as version
Page 37 of 73
Project Plan APRA
1.0 at the completion of the project plan.

Re-baselined as during the project when changes are
accepted that effect the project design
specifications.
6.2.2 Configuration Management System

The configuration management for the project will be overseen and controlled by
the project manager. The project manager uses several systems to ensure that
the current versions are correct and stakeholders have the correct information.
The project manager will manage the versioning of the configuration items. The
version history of the configuration items are logged in the configuration item
history record, this so the project manager knows which version is current.
For a configuration Item to be authorised for project integration it must be
presented to the APRA Change Review Board (CRB), which has been established
to ensure that the changed components reflect their requirements. It is the
responsibility to ensure that the change is suitable and the impact is required to
meet their requirements.
To manage configuration items and project source code the development team
uses source code management software. The project manager maintains source
code and document repositories that contain all the configuration items for the
project. When a team member completes a component it is uploaded via the
source code management, the project manager reviews the component before it
is merged into the project.
The project manager uses a task management software to send and receive task
information to team members. The task management software is used to track
the status of each task and ensure that the team member is up to date with the
current task information. The project manager also uses scrum meetings with the
development team members to discuss project scope and ensure that the
developers are up to date with the current version.
Item Configuration
The configuration items for the project are configured using semantic versioning,
the versioning system is as follows;
Version Numbers: MAJOR.MINOR.PATCH
Patch = change single to a single components, bug fixes and
maintenance.
Minor = functionality added, multiple components changed.
Major = redesign, incompatible changes to API.
Page 38 of 73
Page 39 of 73
Project Plan APRA
Project Plan APRA
Configuration Item History

Record
Configuration Item
Version
No.
Version
Date
Update Details
Page 40 of 73
Project Plan APRA
7. Risk Management Plan

Revision History
Date
12-0914
13-0914
18-914
19-1014
Versi
on
0.1
Author
Zyion Attiig
Created Risk Register Template
0.1
Zyion Attiig
Developed risk management strategy
0.2
Zyion Attiig
1.0
Zyion Attiig
Completed risk management strategy

Completed risk monitoring strategy
Completed risk register
7.1. Risk Management Strategy

The risk management strategy has been broken into three stages the first being
risk identification, the second being risk classification and the third managing
risks. Each of these stages have several components designed to maximise the
completeness of the risk assessment.
Allowances have been made for risk occurrences that are not identified in the
initial risk analysis. Unidentified risks will be managed as part of a review and
reassessment process.
Page 41 of 73
Project Plan APRA
7.1.1. Risk Identification

The risk identification process consists of several stages to help and identify all
of the possible risks that will have an impact on the project. To simplify this
process risks will be categorised into related groups based on the areas of the
project they will have the most impact upon. To determine the risks that are
involved in the project four sets of tools will be used being;
Documentation Review Key project documents will be reviewed to

assist with the identification with risks, the main documents of interest in
this process are scope and project objectives, schedule and estimation,
stakeholder plan and communication plan.
Information Gathering The risk information gathering will consist of
four stages the first being a brainstorming session conducted by the
development team. From the brainstorming a survey and set of questions
and an initial set of risks are determined. Using the Delphi technique the
surveys will be distributed and the answers will be reviewed to refine the
identified risks. The Delphi technique will be repeated until all key
stakeholders can agree on risk data. Key project stakeholders that hold
expert knowledge in the development will be interviewed to gather their
information. After all the risks have been determined root cause analysis
Page 42 of 73
Project Plan APRA
will be performed to determine the cause event to assist determining a

suitable mitigation.
SWOT The SWOT technique is used to determine the strengths,
weaknesses, opportunities and threats involved in identified risks. This will
be used to help maintain strengths and iron out weaknesses in the project
development.
Expert Judgement The use of this technique has been suggested since
the project is to develop a risk management system for specialists in the
field as see risk input from ARPA as a valued resource. The project
development team have some familiarity with similar projects and would
be of benefit to the project.
Once a risk has been identified the risk details will be entered into the risk
register and the risk will be analysed and managed accordingly.
7.1.2. Risk Classification

Identified risks will be categorised in accordance with the risk taxonomy. The
likelihood and impact of the risks will be detailed in a risk matrix and the results
will be recorded as part of the risk control register. Each project risk has an
option to perform a quantitative risk analysis but this is only if extra information
is required to assess the risk properly.
Qualitative Risk Analysis

The qualitative risk analysis for the project will consist of using a risk taxonomy
to categorize risks into risk categories. A risk matrix will be used to determine
the likelihood, impact and rating of risks. The urgency of risks will be determined
by the risk rating that is calculated from the likelihood of the occurrence and the
risk impact.
The likelihood, impact of risks have been given a number scale to calculate the
rating. Each scale has been assigned a tolerance level of low, medium and high
based on their number value. Risks that have been determined as having a high
rating will be reviewed more frequently and thoroughly that risks with a low
rating and will be given a higher priority. This information will be stored as a risk
matrix in the risk control register and will be applied to each identified risk. The
risk matrix is colour coded to provide easy identification or risk impacts and
ratings.
Category
Likelihood
Impact
Risk Rating
(Likelihood multiplied by
Impact)
Risk Rating Scale

Scale
Low
15
12
15
12
1 25
18
Page 43 of 73
Moderate
3
3
High
4+
4+
9 15
16+
Project Plan APRA
Likelihood / Impact Matrix
4
4
3
Likelihood
2
2
1
1
Impact
Risk Rating
Linear (Risk Rating)
If a risk event cannot be assessed properly there is an extra option to seek

expert judgement from both internal and external sources. This will include the
use of both interview and survey techniques to establish risk inputs and outputs.
Quantitative Risk Analysis

There is an option to perform a quantitative risk analysis, but due to the context
and the feature requirements of the project it has not been added as a
requirement for each risk identified. This is due to the project success not
dependant on the project sales or profits. There has also been an assumption
made that information submitted from APRA would provide a reliable source of
information.
Risk Taxonomy
The risk taxonomy describes how the risks will be categorised for the project,
each risk category has been assigned an ID attributed assigned to identified risks
as part of their risk ID number.
Risk Taxonomy
Scope
Time
Estimation
ID
Attribute
SCO
TI
EST
Description
Scope risks are any threats or opportunities that
are associated with the project objectives and
the work that needs to be completed by the
project.
These are the risks that pose a direct impact on
the time allocation to the project, this could
involve downtime or incorrect time allocation
Estimation risks are risks that are directly related
Page 44 of 73
Quality
QAL
Communication
COM
Human
Resources
HR
Risk
RI
Procurement
PRO
Integration
IN
Hardware
Software
SO
Legal
LE
Privacy
PRI
Security
SEC
Project Plan APRA
to project budgeting and expenses.

Risks associated with project standards and the
work completed and is it being completed to
stakeholder expectations. This also includes risks
involved with the quality of outsourced
information.
Risks involved with communication between all
project stakeholders.
This risk category is used for any staff threats or
opportunities that are involved with managing
teams of staff or contractors used in the project.
These are the risks that are associated with risk
management.
These are the risks that can occur in obtaining
items needed for the project development.
These are the risks that are associated with
integrating the project and having it available for
its intended purpose
This category is for all risks associated with
hardware required for the project.
The software category is to contain risks
associated with computer and mobile software
required for the project. This also includes
development software like SDKs and libraries.
These are the project risks that are associated
with legal requirements of the project.
These are risks associated with privacy and
disclosure of project and stakeholder
information.
These are the risks involved in addressing
security concerns for the project, this category
includes both physical and cyber security threats
and opportunities.
7.1.3. Risk Response

The risk response plan has broken the risks responses into three main categories
that each provide a separate set of strategies for managing each risk event.
Positive Risk Management
Positive risks are the risks that provide a benefit to the project. The strategies for
dealing with positive risks include;
Exploit This strategy will be used for positive impacts to reap the full
benefits of the opportunity, this strategy could include reallocation of
resources to achieve the maximum benefit from the situation.
Page 45 of 73
Project Plan APRA
Enhance The enhance strategy is used to increase the probability of the

risk event occurring. This strategy involves determining the driving factors
of the risk event and allocating resources to ensure that it occurs.
Share The share risk strategy is applied to risks where the ownership of
the risk can be shared with a third party allowing both parties to reap the
benefits.
Accept The acceptance strategy is applied to take advantage of the risk
occurrence without actively allocating resources to the risk.
Negative Risk Management

Negative risks are the risk occurrences that have a negative effect on the project
objectives. The strategies for dealing with negative risks include;
Avoid The avoidance strategy is used in cases where the impact is high
and the risk should be avoided. This strategy involves managing the
project resources so that the risk event is minimised or prevented from
occurring.
Transfer The risk transfer strategy is used to transfer the ownership of a
risk occurrence to a third party. This is not seen as a desired option as it
does not prevent the risk occurrence and does consume funds to
compensate the new risk owner.
Mitigate This strategy is used by the development team to prevent the
risk from occurring and to lessen the impact of the risk. The risk mitigation
process may involve the review of processes and strategies to prevent risk
occurrences.
Accept This strategy is used when it is not feasible to implement other
strategies or the risk impact is very low. This strategy is used when no
action is taken to prevent or lessen the impact of the risk occurrence. In
most cases where risks are accepted there is contingency resources added
to the project objective.
Contingent Risk Management

Contingent risk strategies are used for certain events that require special
attention or a special response plan. Contingency plans are often implemented
by the result of another risk strategy not being addressed properly or the basic
strategies are not suitable for managing the risk occurrence.
7.1.4. Unidentified Risks

The risk occurrences can have a major impact to the project development and no
possible risk events should be ignored. All impacting risks will need to be
reported to the project manager so the risk can be properly assessed.
Unidentified have been broken into two categories that detail how the events will
be managed so their impact can be assessed.
Page 46 of 73
Project Plan APRA
Risks that have not impacted the project yet

Newly identified risks will be added to the risk control register and assessed at
the end of each development sprint. This will mean that the risk control register
will need to be reconfigured as per the project configuration plan.
Risks that have impacted the project

If a newly identified risk has already impacted the project, extra steps will be
taken to ensure that the impacts and a management strategy for the risk
occurrence has been determined. The strategy for managing this risk will need to
be integrated as soon as possible and the risk will need to be marked as open.
With the new risk impact new project projections will need to be reconfigured as
per the project configuration plan.
7.2. Risk Monitoring Strategy

Risk monitoring occurs throughout the project, the level of monitoring for risks is
determined by the risk rating. Before a risk can be monitored it needs to be
identified and added to the risk control register so the strategies can be
determined. Once a risk has been identified it can then be assessed and
monitored accordingly.
Risk Assessment
The key element to the project risk assessment is the use of a risk control
register. The role of the risk control register is to record the details of identified
risks and the agreed upon outputs. Once a risk has been identified and
categorized in accordance with the risk taxonomy, the qualitative risk analysis is
performed. The qualitative risk analysis is used to determine the likelihood,
impact and risk rating. Once the risk rating has been established the level of
monitoring for the risk is determined. The risk assessment will also determine if
the data collected for the risk is sufficient, if the risk requires more analysis a
quantitative risk analysis can be performed which will focus on the expert
judgement technique for analysis.
Risk Scheduling
Risk scheduling is dependent on the rating of the risk, risks that have a high
rating will be assessed on a daily basis by the project manager to determine
impacts that may have occurred. Using scrum meetings with the team will allow
for the project manager to keep a close eye on internal risk events as they occur
and issue the appropriate response quickly to the team. Moderately rated risks
will be assessed as each triggering event in the project is performed. All risks will
be assessed at the beginning and reviewed at the end of each development
sprint. Mitigations and contingency plans for risks events will be implemented as
Page 47 of 73
Project Plan APRA
required and approved, highly rated risk events will take priority over lower rated
risk events.
Risk Monitoring
Activity
Risk Identification
Qualitative Risk
Analysis
Quantitative Risk
Analysis
High Rated Risks
Risk Review
Risk Reassessment
Review Scheduling
A risk identification process will be added to each
development sprint. The level of thoroughness of the
process will decrease as the project develops and as
the risk register grows.
This will occur when new risks are added to the
register and as risk inputs and outputs change.
This analysis will only occur when the current
information is not sufficient.
Risks with a high risk rating will be closely monitored
by the project manager or should be appointed to a
risk owner to monitor the situation on a daily basis.
Risks will be reviewed at the end of each sprint
allowing for risk impacts to be managed before the
next sprint begins.
A risk reassessment will occur at the end of each
development sprint, in cases where a high risk
impact has occurred this may occur sooner.
Risk Review
The risk review process occurs at the end of each development sprint. The
review of each risk will include a risk audit, this is the comparison of the
projected inputs and outputs to determine any variances. This is where the
effectiveness of risk management strategies will be determined. The review will
be conducted with the development team, this is an important opportunity to
receive team feedback and strategies about risk events.
Risk Reassessment
A reassessment of the risk control register will be conducted at the end of each
sprint. The reassessment will include the opening and closing of risks, an
assessment of project variances and team brainstorming to identify new risks.
7.3. Risk Control Register

The risks control register is used to monitor and track the status of identified
risks.
Please see the attached Microsoft Excel spread sheet for the complete risk
control register.
Page 48 of 73
Project Plan APRA
8. Post Project Review

Revision History
Date
19/10/
14
19/10/
14
19/10/
14
Versi
on
3.0
Author
Devan Kotze
Status Summary Improved
3.1
Marcus Alroy
3.2
Marcus Alroy
Added Success Criteria & Project

Achievements
Added Schedule reporting
8.1 Success criteria
Provide a detailed Introduction to the project that gives the team a clean
guide to use when looking at the scope and dates of the project.
Put together a scope that shows the skills that we have learnt while also
being able to identify all of the project requirements and deliverables.
Present a neat WBS Tree and table that is able to show data cleanly.
Complete and up to date timesheets with work allocations on each
submission.
Came up with the most suitable project type to use (eg, Waterfall, Agile.)
Identified the most suitable way to work out a budget for the project.
Determined a cost for the business to keep the solution running over time.
Identify a realistic schedule with work completion times.
Produce charts or a diagram to show the schedule.
Produce an easy to understand format for the change management plan.
8.2 Project Achievements

The Introduction section of the report was written clearly and was set out in a
way where if a team member needed to view the business details it was
available to browse quickly and grab the information that they needed. After the
first submission the Project Description was updated to add some more
information about the project and start and finish dates were amended to add
the real dates in. Tables and charts were used effectively in this section to show
the data in an easier to understand format, instead of looking at walls of text
anyone can go over these sections and browse the content quickly. The scope of
the report has been split into three tables and this format allows us to have
tables that will detail each section of the assignment, each table shows the
description of the tasks and the priority with the rating. The tables are all broken
Page 49 of 73
Project Plan APRA
up into sections so that if a certain section needs to be found it isnt a huge task
to quickly find what is needed and have a look at the task details.
The Work Breakdown Structure was broken up into a Tree and a Table, the Tree
was set out cleanly and included every stage of the project broken into sprints.
Each object included the Task ID with the name of each job that needed to be
completed. The table was set out with four columns that show the Task ID,
description of the task, duration of the task and the Predecessors of the task.
This layout ensures that the tables are easy to understand and include all of the
information that will be required. Each section of the assignment has included a
revision history at the beginning and timesheets have been filled in for section
nine of the reports. Work was allocated to each group member at the beginning
of each section of the assessment and each person has been filling in revision
history as they go along and edit content from that section of the assignment.
We assessed the project upon receiving the assignment and come to the
conclusion that Agile would be the best type to go with, this included the team
breaking down the requirements and attempting to predict the development of
the project. After we had decided that we would use Agile we then discussed the
budget of the project, the budget of the project was something that was hard to
work with in the beginning because the type of project but we broke it down into
sections and looked at the ongoing cost of the technology we wanted to use to
produce a realistic figure for the assignment.
In the schedule we included a Gantt chart and a network diagram, this section
focused on these two charts because of the amount of detail that goes into
them. Zyion created the Gantt chart in Project Libre and included every task that
needed to be complete. The Change Management Plan was created by Zyion and
included a lot of detail, the procedure of handling the changes was broken down
into eight step and then placed into a flow chart. Another section of this task was
handling audits and reviews by the client, Zyion broke this section up into a
couple of paragraphs explaining what would happen in morning meetings and
reviews then placed the planned information into another detailed flowchart.
8.3 Schedule reporting
Task
Project Charter
Company Info
Business Experience
Project description
Project
Objectives/Success
Criteria
Risk Management
Reporting
Data & Security
Objectives Success
Criteria
Approach
Stakeholders APRA
Due Date
Completion Date
3 Aug
31 July
31 July
31 July
31 July
30 July
30 July
31 July
29 AUG
27 Aug
17 Aug
17 Aug
17 Aug
17 Aug
5 Aug
8 Aug
10 Aug
Page 50 of 73
5
5
5
5
5
Aug
Aug
Aug
Aug
Aug
8 Aug
10 Aug
Project Plan APRA
Stakeholder KAAS
Start Finish
Budget
10 Aug
1 Aug
27 Aug
10 Aug
1 Aug
27 Aug
Stakeholder Analysis
Details
Communication Strategy
29 AUG
10 Aug
31 July
10 Aug
10 Aug
31 July
Scope
Project Scope Statement
Scope Description
Data Storage
29 AUG
6 Aug
12 Aug
12 Aug
12 Aug
12 Aug
6 Aug
12 Aug
12 Aug
12 Aug
Risk Management
Enterprise Risk
Management
Risk
Scenarios/Mitigation
Risk Framework
Workflow Configuration
Reporting
29 AUG
13Aug
16 Aug
13 Aug
14 Aug
14 Aug
15 Aug
16 Aug
16 Aug
15 Aug
16 Aug
16 Aug
Obligations
Workflow Obligations
Reporting
29 AUG
17 Aug
17 Aug
17 Aug
17 Aug
17 Aug
17 Aug
17 Aug
Assumptions
Product Deliverables
29 AUG
19 Aug
19 Aug
19 Aug
WBS
Project Procurement
Project Developments
29 AUG
20 Aug
20 Aug
20 Aug
20 Aug
20 Aug
Estimation
Estimation
Justification
26 SEPT
18 Sept
18 Sept
20 Sept
17 Sept
20 Sept
Schedule
Scheduling
26 SEPT
16 Sept
22 Sept
22 Sept
Management Plan
Change Approach
Control Procedure
Audits/Reviews
26 SEPT
16 Sept
19 Sept
19 Sept
8 Sept
8 Sept
8 Sept
8 Sept
Configuration
Management
Configuration Items
Configuration System
26 SEPT
15 Sept
21 Sept
21 Sept
15 Sept
12 Sept
Page 51 of 73

Project Management
Status Summary
Task List
26 SEPT
Sept
1 Sept
Project Plan APRA

10 Sept
10 Sept
1 Sept
For each task we set individual due dates that we would focus to have that
section completed by, the majority of that work was completed either on
or before that date. Some jobs slipped behind and were completed after
the date. Most deadlines were met but some tasks had to be reviewed
later on after their due dates to add more detail, we believe the group met
our deadlines to the best of our ability because we were able to
communicate with each other easily and discuss the contents of each
section in depth. The main reason we set early due dates for separate
tasks is so that we were able to get an early go at the work before the due
date of each workbook audit, this makes sure that by the time it comes to
handing work in everything was done and all we needed to do was review
the report contents.
8.4 Review of Techniques

A number of techniques were used to improve both quality and efficiency,
some being more effective than others. The team made use of a "Google
Doc" to initiate the assignment. This was good initially however is
became troublesome after some time. We found that splitting the sections
between members allowed us to complete each section thoroughly as the
person working on it had full knowledge about what they had done in that
section and what still needs to be done. The completed sections would be
emailed to the Project Manager who would then add the section to the
report and update the file online. Facebook was used to communicate with
the team as well as a place to store all current and past versions of the
Workbook. We discovered that communicating via Facebook as well as
using it as a file exchange site worked much better than Google Docs for
this particular Workbook. The Facebook page contained phone numbers,
emails and also served as a team Q&A form. Most of the sections were
completed using the templates however additional research was
performed in order to ensure a good standard.
8.5 Lessons Learned

The workbook has showed the team how important it is to communicate
as often as possible. Overall progress was at its best while having a
constant line of communication. One of the biggest mistakes made during
this particular workbook would be little or no communication for the first
week after the first submission. The team also needed time to get to know
each other. It is hard to jump into a project with a group while not having a
clear understanding about the different strengths in each individual group
member. This however improved naturally over time as the team became
more engaged in discussions. We have noticed that individual team
Page 52 of 73
Project Plan APRA
members do not always notice all mistakes due to the fact that they are
seeing it all the time. We found that it helps to read over a team members
work to ensure that there are no additional errors. This works simply
because the second person to read it sees it for the first time and finds it
easier to spot errors. We have also divided the work differently. At the
start all team members worked on the same task to try and complete it as
fast as possible. We soon discovered that it was an ineffective method and
started to assign sections to each member. By doing this, each member
completed their section thoroughly and little changes were needed in
order to merge sections. This along with regular team meetings and
ongoing communication allowed the team to comfortably reach the final
product on time.
Page 53 of 73
Project Plan APRA
9. Project Management
Time and date allocation of ongoing/completed tasks. Tasks found within the
project, as complete by individuals, for future reference.
9.1 Status Summary

Week
1
(28/07
3/08)
2 (3/08
4/10)
3
(11/08
17/08)
4
(17/08
24/08)
5
(25/08
29/08)
6 (1/09
5/09)
7 (812/09)
8(15/0
919/09)
9(22/0
Development
Description
Company Info,
Business
experience,
project
description and
communication
strategy.
Success Criteria,
Approach,
Start/Finish,
Project scope
statement.
Stakeholder
analysis details
(APRA + KAAS).
Scope, Risk
management.
Compliance
management
WBS, Table +
Tree.
Progress
Comments
Completed
Simple part completed as group,

no changes were needed and
processes used in order to
complete work is general
knowledge.
Completed
Utilising lecture techniques to

complete scope statement, rest
completed, general knowledge.
Completed.
Utilising lecture techniques

again to complete all areas.
Slow but
completed.
Utilising lecture resources, was

time consuming. Had to wait for
completion of scope in order to
have enough information to
complete.
Final look at criteria.
Budget,
finalisation of all
documents
Completed
Task List
Completed
Revision and
check back over
completed areas
+ (6,9)
Scheduling,
Change Approach,
Estimation,
Justification
Configuration
Complete to
best degree
Completed
Completed
Page 54 of 73
Divide of final areas culminating

up to section 9.
Group Look back at all areas to
make sure complete and
feedback areas rectified before
moving on to new sections.
A number of different charts
used, as previously taught. Use
of general knowledge.
Utilizing management

929/09)
10(6/1
011/10)
11(13/
1017/10)
Management,
Management Plan
Post Project
Review, Risk
Management Plan
Revision + Check
over areas
(6,7,8,9)
Project Plan APRA

knowledge + taught means.
Completed
Lecture Resources, Risk

management was lengthy.
Completed
Final looks at criteria and group

collaboration.
Status Summary Conclusion

Project During Third phase ran smoothly and successfully. All areas have been
completed on track, without any need for one particular area to be completed
before other, team was able to move on with work where they saw fit, updating
as they went. Set back in this section was during later stages, when team no
longer used the Google Document. Google Document did not allow for adequate
formatting, a single word document did. Subsequently the project manager had
to continue to be given electronic updates by the team, was then required to find
and implement them into final formatted work. This process over group online
and in person means became a minor trouble but still easy over it counterpart
option Google Documents. The report was finalised and ready for submission on
the required date. All team members where adequately informed of submission
and satisfied in having this action fulfilled.
Page 55 of 73
Project Plan APRA
9.2 Task List
Task
Project Charter
Company Info
Business
Experience
Allocati
on
Due
Date
Status
KAAS
Team
Juan L Sajn
29 AUG
Juan L Sajn
31 July
Complet
e
Complet
e
Complet
e
31 July
Page 56 of 73
Comments

Project
description
Zyion Attiig
Project
Objectives/Succe
ss Criteria
Risk
Management
Compliance
Management
Reporting
KAAS
Team
Aug
Zyion Attiig
Aug
Marcus
Alroy
Aug
Aug
Juan L Sajn
5 Aug
8 Aug
Stakeholders
APRA
Stakeholder
KAAS
Start Finish
Devan
Kotze
Marcus
Alroy
Marcus
Alroy
Juan L Sajn
Budget
Juan L Sajn
27 Aug
Stakeholder
Analysis
Details
KAAS
TEAM
Devan
Kotze
Juan L Sajn
29 AUG
KAAS
Devan
Kotze
Devan
Kotze
Zyion Attiig
29 AUG
6 Aug
Zyion Attiig
12 Aug
Communication
Strategy
Scope
Project Scope
Statement
Scope
Description
Application
Security
Data Storage
Risk
Management
Enterprise Risk
Management
Risk
Scenarios/Mitiga
Complet
e
29 AUG
Zyion Attiig
Data & Security

Objectives
Success Criteria
Approach
31 July
Project Plan APRA
10 Aug
10 Aug
1 Aug
10 Aug
31 July
12 Aug
12 Aug
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
29 AUG
Zyion Attiig
13Aug
Zyion Attiig
14 Aug
Complet
e
Complet
e
Page 57 of 73
May alter, due to

unforseen reasons.
Easily extendable, not
much room for
alterations in sprints.

tion
Risk Framework
Workflow
Configuration
Reporting
Compliance
Management
Obligations
Workflow
Obligations
Reporting
Zyion Attiig
15 Aug
Devan
Kotze
Marcus
Alroy
16 Aug
Zyion Attiig
17 Aug
Zyion Attiig
17 Aug
Marcus
Alroy
17 Aug
Marcus
Alroy
WBS
Project
Procurement
Project
Developments
Devan
Kotze
Devan
Kotze
Estimation
Justification
Schedule
Scheduling
Management
Plan
Change
Approach
Control
Procedure
Audits/Reviews
Configuration
Management
Configuration
Items
Complet
e
Complet
e
Complet
e
29 AUG
Assumptions
Product
Deliverables
Estimation
16 Aug
Project Plan APRA
Devan
Kotze
Devan
Kotze
Marcus
Alroy
29 AUG
19 Aug
29 AUG
20 Aug
20 Aug
26
SEPT
18 Sept
18 Sept
26 SEPT
16 Sept
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
26 SEPT
Juan L Sajn
16 Sept
Zyion Attiig
19 Sept
Zyion Attiig
19 Sept
Complet
e
Complet
e
Complet
e
26 SEPT
Zyion Attiig
21 Sept
Complet
e
Page 58 of 73

Configuration
System
Zyion Attiig
21 Sept
Project
Management
Status Summary
Juan L Sajn
Sept
Task List
Juan L Sajn
1 Sept
Zyion Attiig
17 OCT
Identification
Zyion Attiig
Risk Class
Zyion Attiig
Unidentified
Risks
Monitoring
Strategy
Control Register
Zyion Attiig
Zyion Attiig
Zyion Attiig
Project
Achievements
Scheduled
Reporting
Review
Techniques
Lesions Learned
Complet
e
26 SEPT
Risk
Management
Plan
Strategy
Post Project
Review
Success Criteria
Project Plan APRA
Complet
e
Complet
e
Delegated
19 OCT
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Link to external excel

Spreadsheet
19 OCT
Marcus
Alroy
Marcus
Alroy
Marcus
Alroy
Devan
Kotze
Devan
Kotze
Appendices
Forms
n/a
Plan Documents
Timesheets
Juan L Sajn
19 OCT
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
Complet
e
n/a
n/a
Additional forms can

added.
29 OCT
n/a
n/a
On going.
Page 59 of 73
Project Plan APRA
9.3 Time Sheets

(Note: Time spent is a general estimation, date is when the task was initiated
and then completed, does not necessarily denote exact timings)
Name:
Date
Juan L Sajn
Task
30 July
30 July
31 July
31 July
1 Aug
Time
spent
0.5 hour
0.5hour
2hours
1 hour
1hour
5 Aug
27 Aug
29 Aug
1 Sept
2 Sept
10 Sept
18 Sept
20 Sept
28 Sept
4hours
3hours
2hours
2hours
6 Hours
2 Hours
1 Hour
2 Hours
5 Hours
6 Oct
11 Oct
17 Oct
4 Hours
Objectives Success Criteria

Budget
Final Formatting
Task Listing
Revisions
Status Summary
Change Approach
Audit/ reviews
Secondary Finalization/ Reviewing/
Formatting
Project Management, liaison and
formatting
+ Review update section 9
Third Finalization/
Reviewing/Formatting
4 Hours
Comments
Company Info
Business Experience
Project Description
Communication Strategy
Start Finish
Page 60 of 73
[Altered for
Assessment
timeline]
Delegations made.
As project Group
Name:
Date
Devan Kotze
Task
6 Aug
8 Aug
10 Aug
12 Aug
16 Aug
20 Aug
Time
spent
2hours
3hours
1hour
3hours
3hours
1hour
20 Aug
2 Sept
17 Sept
20 Sept
28 Sept
1hour
6 Hours
2 Hours
2 Hours
5 Hours
14
15
15
17
5
4
4
2
Project Developments
Revision
Estimation
Justification
Formatting
Scheduling Reports
Review Techniques
Lessons Learned
Third Finalization/
Oct
Oct
Oct
Oct
Name:
Date
Comments
Project Scope Statement

Approach
Stakeholder Details
Scope Description
Workflow Configuration
Project Procurement
Assumptions
made
As project group
Marcus Alroy
10 Aug
10 Aug
17 Aug
Time
spent
3hours
3hours
1hour
19 Aug
20 Aug
2 Sept
22 Sept
3hour
1hour
6 Hours
6 Hours
28 Sept
5 Hours
10
12
13
17
4
4
4
2
Oct
Oct
Oct
Oct
Project Plan APRA
Task
Comments
Stakeholders APRA
Stakeholders KAAS
Reporting
Product Deliverables
Project Objectives Reporting
Revision
Scheduling

Formatting
Post Project review
Success criteria
Project Achievements
Third Finalization/
Page 61 of 73
As Project group
Many Iteration,
changes and
revisions on model
used.
Name:
Date
Zyion Attiig
July
Aug
Aug
Aug
Aug
Aug
Aug
Time
spent
2hour
1 hour
1hour
1hour
1hour
1hour
2hours
17 Aug
28 Aug
2hours
5hours
2 Sept
8 Sept
12 Sept
15 Sept
20 Sept
25 Sept
28 Sept
6
1
1
1
2
2
5
8 Oct
8 Oct
11 Oct
12 Oct
14 Oct
14 Oct
15 Oct
16 Oct
3
4
3
4
4
4
3
7
31
12
12
13
14
15
17
Project Plan APRA
Hours
hour
hours
hour
hour
hours
hours
Task
Comments
Project description
Data Storage
Enterprise Risk Management
Risk Scenarios
Risk Framework
Obligations
Compliance Management Workflow
Final Formatting, Review and
Corrections
Revision
Control Procedure
Configuration Systems
Configuration Items
Audit Reviews
Forms
Formatting
Risk Management Plan
Risk Management Strategy
Risk Identification
Risk Class
Risk Response
Unidentified Risk
Risk Monitoring
Risk Control Register
Page 62 of 73
As Project group
Appendix Addition
External Excel Doc
Project Plan APRA
Appendices
Appendix A Change Request Form
Change Request
Compliance SaaS
Date Submitted:
Change Order
No.
Title of Change
Required:
Submitted by:
Position:
Contact:
Priority
Low
Medium
High
Expected Impact
Low
Medium
High
Change Category
Scope
Schedule
Cost
Technology
Other
Description of change
Events that made this change necessary
Justification for the change
Page 63 of 73
Project Plan APRA
Impact of the proposed change

Scope:
Schedule
:
Cost:
Staffing:
Risk:
Other:
Suggested implementation if the change request is approved
Approval Stage
Approval details
Reviewed By
Project Manager
approved request
Development Team
approved new
specifications
Approved by APRA
Change Review
Board
Page 64 of 73
Date
Approved/Rejec
ted
Project Plan APRA
Appendix B Issue Submission Form
Project Issue Submission Form

Compliance SaaS
Date Submitted:
Title of Change
Required:
Submitted by:
Position:
Contact:
Change Order No.
Scope
Schedule
Description of issue
Issue Category
Cost
Technology
Events that made this issue occur
Proposed Resolution
Page 65 of 73
Other

2001ict Projectmanagement Assignment 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2001ict Projectmanagement Assignment 3

Uploaded by

Copyright:

Available Formats

Project Plan

APRA Enterprise Risk

2001ICT - Project Management Group 2

Project Plan APRA

2001ICT - Project Management Group 2

Project Plan APRA

3.2.1 Work Breakdown Structure Project Procurement...............................16

2001ICT - Project Management Group 2

Project Plan APRA

9.2 Task List...................................................................................................... 49

2001ICT - Project Management Group 2

Project Plan APRA

Added company info

Added Communication Strategy

Added Start and Finish Dates

Added Risk Management

Added Objectives Success Criteria

Added Stakeholders APRA

Amended development approach

1.1 Company Information

APRA Enterprise Risk Management and

Juan Luis Sajn

Zyion Attiig, Juan Luis Sajn, Marcus Alroy, Devan

2001ICT - Project Management Group 2

Project Plan APRA

2001ICT - Project Management Group 2

Project Plan APRA

The system is to be based on APRAs Enterprise Risk Management Framework

Project Objectives and Success Criteria

The scope of the project is to deliver

Design and Implement an

2001ICT - Project Management Group 2

Please see project objectives for

Project Plan APRA

The SaaS Application will

The application development is to

The project was developed within

2001ICT - Project Management Group 2

Project Plan APRA

approach will minimise project risks by allowing for continuous development,

Development Life Cycle

2001ICT - Project Management Group 2

Project Plan APRA

Role and Responsibility

Will require Read/Write Access to Application

Currently do not require access

Stakeholders KAAS Solutions

Roles and Responsibilities

Determine Project Requirements and

Develop Technical Requirements

2001ICT - Project Management Group 2

Project Plan APRA

Develop Test Cases

Start and Finish

2001ICT - Project Management Group 2

Project Plan APRA

1.2 Stakeholder Analysis

Juan Luis Sajn

Stakeholder Analysis Details

Risk Owners and

APRA management will report directly to the

The Project Manager will pass information

2001ICT - Project Management Group 2