Vous êtes sur la page 1sur 49

___________________________________

South East Gippsland University


___________________________________

Automated Student
Management System
(ASMS)
Project Plan

Date: 20/08/2012

Prepared by ITPM Group 2


University of Colombo School of Computing

Table of Contents
1. Introduction and Objectives of the Project Plan ................................................................................. 4
1.1 Overview of the Organization ....................................................................................................... 4
1.2 Current Situation and Problem/ Opportunity Statement ............................................................... 4
1.3 Project Objectives ......................................................................................................................... 5
2. Project ................................................................................................................................................. 6
2.1 Project Information ....................................................................................................................... 6
2.2 Project Objectives ......................................................................................................................... 6
2.3 Project Approach .......................................................................................................................... 7
2.4 Roles and Responsibilities ............................................................................................................ 7
2.5 Project Constraints ........................................................................................................................ 8
2.6 Assumptions.................................................................................................................................. 8
2.7 Preliminary Schedule and Budget Estimates ................................................................................ 9
2.7.2 Preliminary Budget Estimate ............................................................................................... 10
2.8 Plan Modification Rules ............................................................................................................. 10
2.9 Approval Signatures.................................................................................................................... 10
3. Project Scope Management Plan....................................................................................................... 11
3.1 Product description ..................................................................................................................... 11
3.2 Project Deliverables .................................................................................................................... 11
3.3 Scope Statement .......................................................................................................................... 12
3.31 Within Scope ......................................................................................................................... 12
3.3.2 Out of Scope ........................................................................................................................ 13
3.3.3 Project Success Criteria ....................................................................................................... 13
3.4 Work Breakdown Structure Development .................................................................................. 14
3.5 Scope Change Management Process........................................................................................... 15
3.5.1 Scope of Change Requests ................................................................................................... 15
3.5.2 Change Request Process ...................................................................................................... 16
3.5.3 Change Control Team .......................................................................................................... 16
3.6 Plan Modification Rules ............................................................................................................. 17
4. Schedule management plan............................................................................................................... 17
4.1 Project Schedule.......................................................................................................................... 17
Assumptions.................................................................................................................................. 17
5. Cost Management Plan ..................................................................................................................... 17
5.1 Project Budget............................................................................................................................. 19
5.2 Budget Constraints ...................................................................................................................... 19
6. Quality Management plan ................................................................................................................. 21
2|Page

6.1 Quality Standards ........................................................................................................................ 21


6.2 Quality Metrics ........................................................................................................................... 23
6.3 Quality Management Approach .................................................................................................. 23
6.4 Quality Assurance ....................................................................................................................... 24
6.5 Quality Control ........................................................................................................................... 25
6.5.1 Quality Control Reviews ...................................................................................................... 25
6.5.2 Quality Control Activities .................................................................................................... 25
6.5.3 Measures of Software Quality.............................................................................................. 26
7. Risk management plan ...................................................................................................................... 27
7.1 Risk Management Strategies ....................................................................................................... 27
7.2 Risk Management Tools ............................................................................................................. 28
7.3 Data Sources ............................................................................................................................... 29
7.4 Risk Categories ........................................................................................................................... 30
7.5 Risk Probability and Impact........................................................................................................ 32
8. HR management plan ........................................................................................................................ 33
8.1 Project Organization ................................................................................................................... 33
8.1.1 Project Team ........................................................................................................................ 33
8.1.2 Organization Structure ......................................................................................................... 34
8.1.3 Stakeholders ......................................................................................................................... 35
8.2Resource Requirements ............................................................................................................... 37
8.3 Resource Assignment.................................................................................................................. 38
9. Communication plan ......................................................................................................................... 45
9.1 Stakeholder Analysis .................................................................................................................. 45
9.2 Project Reports ............................................................................................................................ 47
9.3 Project Meetings ......................................................................................................................... 48
9.4 Project Information Accessibility ............................................................................................... 48
9.5 Communications Summary ......................................................................................................... 49

List of Figures
1. WBS
2. Organizational Structure
3. Resource Histogram

3|Page

1. Introduction and Objectives of the Project Plan


1.1 Overview of the Organization
South East Gippsland University is a modern academic organization. The Student
Management System of the University provides support for the universitys endeavours,
teaching and research. The goal of the management of the University is to continue with the
improvement of its systems to achieve service excellence and cost advantages. The proposed
project is attempting to revolutionize the service delivery to key stakeholders and foster
excellence in teaching, research, and public service that will establish the University as a
leader among the nation's major research universities.
The University currently has an aging student management system. It currently runs on old
technology, which is difficult and expensive to maintain, and does not provide the flexibility
and services needed in a modern academic organization. Implementing an appropriate
replacement presents an opportunity to integrate new technology such as SMS
communication with students (i.e. for the delivery of results), and use of social media (such
as Facebook, You Tube and Twitter), therefore increasing the overall ability of students to
communicate with the university and to facilitate the university with better communication
and feedback with students.

1.2 Current Situation and Problem/ Opportunity Statement


Currently at South East Gippsland University there is a separate and costly infrastructure for
student enrolments, students updates, alumni management and results publishing services.
Some of the systems rely on out-dated and unsupported equipment. The current technology
has limited flexibility for new, expanded and integrated services. A system is required to
support all the communications, infrastructure, and services to students and staff. Therefore
they are going to implement a new Automated Student Management System (ASMS) to
avoid those limitations.
The ASMS Project will renew the student management services and infrastructure at South
East Gippsland University. The University will implement a state-of-the-art web based
system to provide a higher level of service at lower cost for University customers. The system
will integrate the use of SMS and other social media technology with the student
management system. The ASMSs strategy is to change all of its obsolete student
management systems (student enrolment system, student reporting system (for lecturers and
administrative staff to view results), the results submission system (for lecturers to submit
results) and the results publication system that publish results to students.
The new implementation will provide one integrated system instead of an assortment of
systems, integration with other technologies (such as SMS), applications and social media,
availability of trained systems-developers and Lower operational costs for the University.
4|Page

The existing student management suite cannot utilize cost-effective new technology (SMS
and other social media) and cannot be effectively maintained due to a scarcity of trained
systems-developers due to the age of the system and the compartmentalised nature of
previous enhancements of the systems.
In this situation, the University will update its aging student management suite of systems.
The existing systems will be replaced with a modern, integrated system. This modernization
is expected to enhance service delivery to faculty, students and staff in ways that cannot
effectively be accomplished with the existing core technology resources in place.

1.3 Project Objectives


Objectives

Transform and advance quality in teaching, research, and public service.


Enable new voice and data applications to support the University's mission.
Provide a robust, flexible, ways of communication between students and the university
to meet the communications requirements of the instructional faculty, researchers, and
students.
Upgrade technology infrastructure and support the organization.

Potential Benefits new ASMS.

A modern, state-of-the-art student management system. Integration with other


technologies and applications.
Improved services for all staff and students
Quicker and more responsive action on new and change service requests and
troubleshooting.
Simplified billing.

Upgrade of systems will reduce maintenance overheads on current old systems

A more dependable, robust and secure network.


University staff will benefit as they will not have to use multiple systems.

New technology already used by students will be utilised for student management
processes. This will provide the university with immediate feedback about the service
quality and what students think about the degrees and units taught.

5|Page

2. Project
2.1 Project Information
Project Start Date:

2nd of May, 2012

Project End Date:

30th of May, 2014

Project Manager:

Mr. Waruna Kodituwakku

Project Sponsor:

Information Technology Services (ITS), South East Gippsland University.

2.2 Project Objectives


Objectives

Transform and advance quality in teaching, research, and public service.


Enable new voice and data applications to support the University's mission.
Provide a robust, flexible, ways of communication between students and the university
to meet the communications requirements of the instructional faculty, researchers, and
students.
Upgrade technology infrastructure and support the organization.

Potential Benefits new ASMS.

A modern, state-of-the-art student management system. Integration with other


technologies and applications.
Improved services for all staff and students
Quicker and more responsive action on new and change service requests and
troubleshooting.
Simplified billing.

Upgrade of systems will reduce maintenance overheads on current old systems

A more dependable, robust and secure network.


University staff will benefit as they will not have to use multiple systems.

New technology already used by students will be utilised for student management
processes. This will provide the university with immediate feedback about the service
quality and what students think about the degrees and units taught.

6|Page

2.3 Project Approach


Project Approach Phase

Description

Project Initiation & Planning

In this phase all initiation activities such


as resource allocation, planning and
approving project charter will be done.
In this phase following activities will be
done.
1. Monitoring & Control
1. Requirement Analysis & Specification
2. Design
3. Implementation
4. Quality Management
5. Training

Project Execution

Installation

Install all the software, database and


hardware components.

Maintenance

Monitor and take actions to solve issues


and gather requirement for further
enhancements.

2.4 Roles and Responsibilities


Name

Role

Position

Contact Information

Waruna Kodituwakku

Project Manager

Project Manager

vharshana@gmail.com

Charaka Hettiarachchi

Accountant

Accountant

djchar89@gmail.com

Shanika Udeshini

Human
Resources
Manager

Human Resources
Manager

udeshini14@gmail.co
m

Aloka Weerasuriya

Communications Communications
Manager
Manager

alokaweerasooriya07@
gmail.com

Dasitha Wijesundara

Business Analyst

Business Analyst

dasitha07@gmail.com

Harshani
Wickramarachchi

Quality
Assurance
Analyst

Quality Assurance
Analyst

wwharshi@gmail.com

7|Page

NimalBandara

Network
Engineer

Network Engineer

mhnirmalj@gmail.com

Kumudu Lokuge

Assistant
Network
Engineer

Assistant Network
Engineer

mrkumudu@gmail.co
m

Sadishani Rangika

Network
Operators

Network Operators

utsadishan@yahoo.co
m

Sunil de zoysa

Security
Specialist

Security Specialist

sunilkgfd@yahoo.com

Nirmal Perera

User Interface
Designer( LMS
expertise)

User Interface
Designer( LMS
expertise)

nirmalpra@gmail.com

2.5 Project Constraints


Resource Constraints

Some staff resources will be available only on a part-time basis.

Budgetary Constraints

Salary scheme for employees will be based on the current market situation and total
employee costs will be at around 60% of the project budget.
No additional cost for Wireless broadband hardware and software apart from $50,000.

Schedule Constraints

Project requires to be implemented within 24 months or less time frame and the
existing services have to be maintained continuously.
Project Team does not work on weekends.

Quality Constraints

Deliverables of the project plan and ASMS System should be subject to quality review
process throughout the designing and implementation process.

2.6 Assumptions
Resource Assumptions

Project staff resources will be available when and as they are needed.
Required hardware resources will be available when and as they are needed.
8|Page

Required customer resources will be available when and as they are needed.
A significant percentage of the project staff will be experienced with the technical
environment.
Access to industry experts and specialized skills will occur as needed.

Delivery Assumptions

Deliverables will be subject to no more than a specific number of review cycles.


Software and Equipment order lead times are known and can be expected to be met.

Environmental Assumptions

No industrial action will be taken that will affect the project.


Issues will be resolved in a timely manner.

Budgetary Assumptions

The statistics used in preparing the estimates are accurate within a given percent.
Outsourced consulting will be limited to a specified number of days at a specified rate per
day.

Functionality Assumptions

The scope of the project is limited to that described in the project scope statement.

2.7 Preliminary Schedule and Budget Estimates


2.7.1 Preliminary Schedule
Phase

Estimated Duration
(Days)

Project Initiation & Planning

48 days

Monitoring & Control

130 days

Requirement Analysis &


Specification

55 days

Quality Management

10 +176 days (parallel)

Design

50 days

Implementation

100 days

Installation

25 days

9|Page

Testing

110 days (parallel)

Training

30 days (parallel)

Maintenance

65 days(parallel)

2.7.2 Preliminary Budget Estimate


Cost Areas

Total Employee cost

1,700,000.00

Total software cost

1,100,000.00

Total Hardware cost

100,000.00

Total service charges

20,000.00

Total Overhead cost

30,000.00

Total Outsourced Costs

50,000.00

Total

3,000,000.00

2.8 Plan Modification Rules


Only the project manager has the authority to change this project charter. Before getting approval by
the sponsor any change will be informed to project team members via email. After getting approval
there will be any change will be not approved.

2.9 Approval Signatures


Project Manager:
As project manager on Automated Student Management Project, I have reviewed the information
contained in the Project Charter and agree to its content.

Name

Position

Signature

Date

10 | P a g e

The signatures above represent stakeholders agreement and acknowledgement of the information
contained in this document.

3. Project Scope Management Plan


3.1 Product description
The new Automated Student Management System (ASMS) will be a web based software
application for the administration, documentation, tracking, reporting, communication and
delivery of education courses or training programs online. The ASMS will be able to do the
following.

Centralize and automate administration


Use self-service and self-guided services
Assemble and deliver learning content rapidly
Consolidate training initiatives on a scalable web-based platform
Support portability and standards
Personalize content and enable knowledge reuse
Deliver online training and webinars
Communication through SMS and social media such as Face book and YouTube.

ASMSs range from systems for managing training and educational records, to software for
distributing and delivering of online courses, augment on-campus courses and deliver online
training, as well as automate record-keeping and student registration. Student self-service
(e.g., self-registration on instructor-led training), training workflow (e.g., user notification,
manager approval, wait-list management), the provision of on-line learning (e.g., computerbased training, read & understand), on-line assessment, management of continuous
professional education (CPE), collaborative learning (e.g., application sharing, discussion
threads), and training resource management (e.g., instructors, facilities, equipment), are all
important dimensions of the Student Management System.

3.2 Project Deliverables

Software Documentation
o System Documentation
o User Documentation (User Manual)

Project documentation
o Software Requirements Specification (SRS)
o Software Design Specification (SDS)
11 | P a g e

o Software Project Management Plan (SPMP)


o Software Test Plan (STP)
o Software Quality Assurance Plan (SQAP)
o Software Configuration Management Plan (SCMP)
o Software Verification and Validation Plan (SVVP)

3.3 Scope Statement

Project Title

: Automated Student Management System (ASMS)

Prepared by

: Waruna Kodituwakku, Project Manager (vharshana@gmail.com)

Project Justification:
The South East Gippsland University, requested this project be done to support the
management of students of university in meeting its strategic goals. This system will help to
reduce operational costs and improve profitability of the university by providing One
integrated system instead of an assortment of systems, integration with other technologies
such as SMS communication (i.e. for the delivery of results) and applications and social
media (Facebook, YouTube) and availability of trained systems-developers.

3.3.1. Within Scope


1. Requirement gathering and defining: Project team will contact university lecturers,
administrative staff and students to determine the best interface and website content. This
will be backed up by prototypes of the major parts of the software and existing system for
more feedback.
2. System capacity: The systems capacity to hold files for the staff, student and
management will be unlimited by the software, but by the hardware capacity therere
using.
3. Expert Database: Since ASMS will be receiving many user requests, a dedicated
database is required to record and organize requests in order for best possible response
time and the ability to quickly and easily review past complaints or suggestions.
4. Installation: Once the system is completely implemented and agreed on, System
Development team will install it on all of the necessary components.

12 | P a g e

5. Testing: Testing will include the development of test plans to document how the system
will be tested, who will do the testing, and how bugs will be reported. We will provide
additional Network security for the University Network to prevent unauthorized accesses.
6. Maintenance: We will provide maintenance for the system and the website for 1 year of
the installation date. There will be a well-defined plan for rolling out the new system,
supporting users, and providing updates, enhancements, or other support, as required.
7. Security: All services must be secure with restricted access rights.

8. Training: A 40 days training period will be available of the universitys staff and system
administrative staff on how to use the system. Starting from top level staff and covering
all other relevant parties of the university staff.
9. User Manual: A user manual for the staff will be available. Also, an online user manual
on the website will be available for the users.

3.3.2 Out of Scope


1. All retraining and further maintenance will be responsible of the university
2. All data entering, registration of users, course delivery and etc will be undertaken by
universitys administrative processes as part of operations.
3. Any upgrades required to other systems to enable them to work with the new ASMS.
4. Any social media element such as User Generated Content, communities or moderated
forums.
5. The network room/space, proposed will be delivered by the university.
6. All advertising and marketing required for launch and on an ongoing basis will not be
delivered or paid for by this project
7. Any recruitment required of resources for university purposes once the new system
launches and training and testing completed.

3.3.3 Project Success Criteria


Our goal is to complete the project within 24 months. The initial budget will not be exceeded.
In order to meet this goal each team member must put in three work hours per week.
Deliverables must be completed on time and within the sponsors specifications. Late
completion of the project is not acceptable.

13 | P a g e

3.4 Work Breakdown Structure Development


Work Breakdown Structure (WBS) is developed as a chart in which the critical work
elements, called tasks, of the project are illustrated to portray their relationships to each other
and to the project as a whole. This WBS will assist key personnel in the effective allocation
of resources, project budgeting, procurement management, scheduling, quality assurance,
quality control, risk management, product delivery and service oriented management.
The project tasks are categorized into ten phases. Each of these phases is then subdivided
further down to sub phases. Each sub phase of the main phases may be subdivided into at
most two sub phases. Here we have used top-down approach to create the WBS.
Project Manager, Software Architect, Programmer, Business Analyst, Quality Assurance
Analyst, Database Administrator, Software Designer Technical writers, Human Resources
Manager and Web Developers engaged in developing the WBS.
(For detailed WBS refer Appendix B)

14 | P a g e

3.5 Scope Change Management Process


The purpose of the Scope Change Management Plan is to:
1. Manage and control scope change during the implementation of the Project.
2. Ensure that the project is implemented on time and within the approved budget and
scope.
3. Evaluate and prioritize all changes to the project implementation plan at the
institutional level.
4. Provide a process for implementing change required by the system.

3.5.1 Scope of Change Requests


The following change requests will be addressed by the Scope and Change Management
Plan:
1.
2.
3.
4.
5.
6.
7.

Modifications to software.
Purchase of 3rd party software.
Changes to contracted professional services (e.g. additional consulting visits).
Scope (includes modules, data conversion and migration, interfaces, etc.).
Milestone dates, including interim milestones and major go-lives.
Additional project spending (hardware, training, conferences, etc).
Functionality required by policy changes at the university and/or external mandates.

The following change requests will not be addressed by the Scope and Change Management
Plan:
1. Policy / process changes. May occur as a result of a change request.
2. Requests for modifications to current systems which are not to be replaced. Changes
may occur as a result of integration, migration, and conversion decisions.
3. Re-allocation of contracted professional services hours. May occur due to a change
request, but specific requests to re-allocate service hours will not be accepted without
justification based on the change.
4. Changes to existing systems

3.5.2 Change Request Process


Step1 - Person who wants to initiates Change Request by completing the Change Request
Information section on the Change Request Form and submitting to Project Manager.
Step 2- Project Manager Reviews the request identifies needed information and next steps to
complete; enters into Change Request Log. Project manager communicates and coordinates
with appropriate personnel to gather required information.
Step 3 - Project Manager prepares and submits Change Request Impact Analysis section and
submits it to the Change Control Team.
Step 4 - Development Team receives weekly updates of pending change requests and
provides input as needed / requested.
Step 5 - Change Control Team approves/denies change request, provides Final
Recommendation on the Change Request Form and advises project Manager and If
appropriate, forward for review and disposition.
Step 7 - Project Manager communicates the decision to:
a. The person who is making the request of the Change Review Team decision.
b. Development Team/ Designers/ Analysts
c. All Project members and appropriate interested parties.
d. Makes appropriate entries into the Change Management Request Log.
Step 8 - Modify Implementation plan and documentation as needed to incorporate approved
change.
Requests resulting in changes to the vendor contract require approval from the Project
Sponsor and no changes to the contract should be acted upon or conveyed as an approved
change until we have verified that we are in compliance with the original contract. Changes
to software, budget, or contracted hours will be reviewed, managed and approved by the
Project Manager. First priority will be given to change requests for mission-critical functions
and/or services. Other criteria for evaluating change requests will be approved by the Change
Review Team. Documents using in this process will be Change Request Form, Change
Request Log and Scope Change Management Plan
3.5.3 Change Control Team
Following personnel will be the members of the Change Control Team
1.
2.
3.
4.

Project Manager
Business Analyst
Software Developing Manager
Change Review Team members
16 | P a g e

3.6 Plan Modification Rules


Only the project manager has the authority to change this plan. Notification of scheduled and
unscheduled updates to the plan will be communicated via e-mail to all project participants.
The plan will only receive further baselines if significant change in scope occurs.

4. Schedule management plan


4.1 Project Schedule
Milestone

Completion Date

Project Charter Approved

07/08/2012

All project deliverables have been delivered

03/01/2013

All deliverables have been delivered

22/03/2013

Evaluate project quality

Starting from 24th of 2013


After that once a week

Create Software Design Specification (SDS)

14/06/2013

Implementation Completed

01/11/2013

Installation Completed

06/12/2013

Director view of the system

03/01/2014

Upload current data to the system

30/04/2014

Testing Completed

09/05/2014

Training Completed

30/05/2014

(For detailed schedule plan (Gantt chart) refer Appendix A)


Assumptions

Project Team does not work on weekend days.


We outsource Security Specialist , Legal consultant, Network Engineer, Network
Operator, User Interface Designer ( LMS Expertise ) for the project

Assume following team members will work on the project to achieve the goals as mentioned
bellow.

CIO - He works First week of the May 2012 and some additional 15 hours. All
together 55 hours.

17 | P a g e

IT Project Manager He works through all stages of the project, Project Monitoring
and Control, Project Initiation and additional 22 hours.

Accountant Works for 4 hours per month for entire project. And some additional
hours regarding when its needs for the project.

Human Resource Manager - He works especially on managing human resources


and training university staff. 320 hours on whole project.

System Administration - He works specially on Installation, Resolve technical


problems, Resolve technical problems. We allocate 200 days for him

System Architect - He assign to work on Design stage from April 2013 up to June
2013 other and additional hours spend for the iterations 200 hours on whole project.

Software Development Manager He works for additional plugins that integrate for
the student management system and the design. We allocate 200 hours for him.

Software Engineer / Developer - He works for additional plugins that integrate for
the student management system and the design. We allocate 340 hours for each.

Test Manager - He works in System testing stage we allocate 1120 hours for each of
them. Starting from December 9 2013.

Technical Writers He works 120 days specially the areas of Requirement Analysis,
Specification ,Design and User Documentation

Help Desk level 2 - Allocate for 60 days for training the staff starting from February
2014 and ends May 2014. (2 steps)

Quality Assurance (QA) Analyst He works on Quality Plan and Monitor product
quality .( Meet the company deliverables together with web developer, Database
Admin, Data warehouse Engineer and Business analysis) we allocate 480 hours with
Additional hours for referring the quality of the project

Business Analyst He specially works on Requirement Analysis, Specification,


Develop Software Quality Management Plan and Manage Risk areas and with
additional hours we allocate 560 hours for him.

Network Operator - Work 2 month (June 2013 and August 2013) 160 hours per each
with additional hours apply for maintenance.

Network Engineer - Work 2 month (June 2013 and August 2013) 60 hours with
additional hours apply for maintenance.

Database Administrator - He works specially on Installation, Design and Monitor


product quality. (Meet the out project deliverables together with web developer,
18 | P a g e

Database Admin, Data warehouse Engineer and Business analysis) with additional
hours we allocate 560 hours for him.

Data - warehouse Engineer - He works specially on Installation, Design and Monitor


product quality. (Meet the out project deliverables together with web developer,
Database Admin, Data warehouse Engineer and Business analysis) with additional
hours we allocate 580 hours for him.

Web Developer
o

He works June 2013 October 18 2013.He works 8 hours per week. 1920 hours
per each. And he also allocate for 60 days for training the staff .He got to have
some extra hours to train the staff and other developing purposes.

5. Cost Management Plan


5.1 Project Budget

Cost Areas
Total Employee cost

$
1,650,670.00

Total software cost

932,487.95

Total Hardware cost

96,910.00

Total service charges

14,670.00

Total Overhead cost

27,044.00

Total Outsourced Costs

49,204.00

Total

2,770,985.95

(For detailed budget refer Appendix D)

19 | P a g e

5.2 Budget Constraints

We use Budgetary Estimate for almost all cost fields.


We use following professional tools for the ASMS project and we purchase them - Web
Studio 5.0 (15 users) , CS Adobe 6 Master Collection 2 yrs (with renewal ), Database and
DB Firewall (Oracle), MyEclips Bling Edition (2 yrs) , Security software (Kaspersky) ,
MS Project Standard 2010. They are Budget Estimates.
Web Developers may use for staff training also.
Student management System cost includes the all license fees and the integration
modules of it. Has no additional cost apart from what allocates from budget.
IT work desk Implementation has no additional cost apart from what allocates from
budget.
We never allow any amount of Money for the maintenance of the system after the June
2014
We do abide for the security of the network system for 6 months after 2014 June(as
standard procedure)
No additional cost for Wireless broadband hardware and software apart from $50,000
No additional cost for Wireless broadband maintenance e apart from $5,000/annual

5.3 Budget Assumptions

The currency use for calculations is US dollars.


Administration costs not exceed $5000
Reserves $6,806 as Reserves for use unexpected costs that when project is going on.
We outsource Security Specialist , Legal consultant, Network Engineer, Network
Operator, User Interface Designer ( LMS Expertise ) for the project
Security Specialist assign for security testing purposes.
We consider that there are no more additional money to spend on training the staff but as
if they need we will negotiate it with Utility and System and functional Testing Cost.
We didnt include additional food and beverages cost the final budget as they appear on
utility cost.
We assume that current network system of the University has to be upgrade (we already
examined) so we include Hardware maintenance & implementation for it.
We add 10 PC maintenance cost and the software renewal cost to the budget.( developers
usages)

20 | P a g e

6. Quality Management plan


6.1 Quality Standards
Project process/ Reports

Quality Standards

Project Planning and Management

Team members will go through the case study and


understand the current situation and the project manager
will closely monitor the process of collecting of project
information for the status reports.

Project Plan
Configuration Management
Plan
Quality Assurance Plan
Project Status
Reports/ongoing Project
Management
Technology Assessment
Report
Feasibility Report

Requirements Analysis Process

Prototypes and other


diagrams
Flowcharts
System Requirements
Specification Document
(SRS)
Functional Specifications
Document (FS)
Requirements Traceability
Matrix
Use Cases

Design

System Design Document


System Security Consensus
Document (SSCD)
Security Plan
Data Retention Plan
Disaster Recovery Plan
Unit and Integration Test
plan (Begin)
Conversion Plan (Begin)

IEEE 1058

Once the requirement analysis process is complete in that


case team members provide comprehensive documentation
covering all requirements gathered.

IEEE 830

Transform the requirements into complete and detailed


system design specifications. Once the design is approved,
the Development Team begins the Development Phase.

IEEE 1016

21 | P a g e

Implementation Plan
Operation or System
Administration Manual
(Begin)
Maintenance Manual
(Begin)
Training plan
User Manual (Begin)
Requirements Traceability
Matrix (Update)

Implementation

Finalized System
Documentation
Post-Implementation
Review Summary
Methodology Compliance
Form
System Manual
Program Manual
Data Manual
Application Operation
Manual
Application User Manual
Computer Operating
Procedures Manual

Testing

Unit and Integration Test


plan
Software Validation and
Verification Plan (SVVP)
Software Test
Documentation (STD)
Maintenance

Maintenance Manual
Maintenance and Support
Services From

By using the architecture document from the design phase


and the requirement document from the analysis phase, the
team will build exactly what has been requested.

The team will be test the system in the relevant


environment and fix the errors.

IEEE 1012
IEEE 829
Keeps the system up to date with environment changes and
changing user requirements.

IEEE1993

22 | P a g e

6.2 Quality Metrics

Project Deliverables

Quality Metrics

Tensile Strength

The system will be used in various industrial environments


under high material stress loads.

Shear Strength

The system will be subject to potentially high stress torque


loads in various applications.

Customer Satisfaction

The customers should be given the customer satisfaction


form and the customer satisfaction of the system should
reach the expected level.

Material Scrap

The system should ensure whether it is following the metrics


which internally established for measuring and controlling
material scrap for manufacturing efforts of it.

Product Defect Rate

The system should ensure whether it is following the metrics


which internally established for measuring and controlling
product defects.

6.3 Quality Management Approach


Tool

Use of Tool

Person Responsible

Total Quality
Management (TQM)

Aims to produce product and service Quality Assurance Analyst


specifications with zero defects.
TQM creates a virtuous cycle of
continuous improvement that boosts
production, customer satisfaction
and profits.

Quality Management
Framework (QMF)

The QMF standardizes processes,


allowing for increased efficiencies.
These processes strengthen supplier
management techniques in addition
to robust cost control, thereby
improving overall profit. And by
implementing the QMF we ensure
security compliance across a project
lifecycle.

Project Manger

23 | P a g e

Six Sigma

Improve the quality of process


outputs by identifying and removing
the causes of defects (errors) and
minimizing variability in
manufacturing

Quality Assurance Analyst

6.4 Quality Assurance


Stage

Deliverable

Work Product

QA Activity

Planning

Project Plan

Project Schedule

ISA Process- (review


process and audit contents )

Preparation

Functional Requirements
Document

Revised Project
Plan

ISA Process- (review


process and audit contents )

Traceability
Matrix

ISA Process- (review


process and audit contents )

Revised Project
Plan

Trace design components to


requirements

Acquisition Plan
Installation Plan

Software Design

Functional Design
Document
Security Plan
Training Plan

Trace requirements to

System Test Plan

design components

Acceptance Plan
Conf. Mgmt. Plan
Conversion Plan
Programming and
Integration

Site Installation Plan,


System Documentation

System Testing and Test results, System


Acceptance
Documentation

Revised Project
Plan
Revised
Plan

ISA Process- (review


process and audit contents )

Project ISA Process- (review


process and audit contents )

Operational System

24 | P a g e

6.5 Quality Control


6.5.1 Quality Control Reviews

Bendability Reviews:
These reviews are initialized by Project Management Team. These reviews can take
place as part of the Final Plans Processing.

Constructability and Right of Way Reviews:


These reviews allow input from the departments, for constructability reviews and
assist in the Right of Way Office in reducing right of way costs.

Checking procedures

Checking Reports
o Avoid redundant data.
o Support for focusing on major issues.
o Makes data & structures consistent.
Checking Drawings
o Provides the design according to the requirement of project.
o Provides complete & clear idea of project.
o Provides coordination with other aspects of the project.
o Gives compatible standards and good plans preparation practice
Checking Calculations
Checking Correspondence

6.5.2 Quality Control Activities


1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

Check that assumptions and criteria for the selection of data and the different factors
related to data are documented.
Check for transcription errors in data input and reference.
Check the integrity of database files.
Check for consistency in data.
Check that the movement of inventory data among processing steps is correct.
Check for uncertainties in data, database files etc.
Undertake review of internal documentation.
Check methodological and data changes resulting in recalculations.
Undertake completeness checks.
Compare results to previous results.
Defining and classifying the severity of defects.
Inspecting documents.
Inspecting code .(either manually or via automatic static code analysis)
Testing executable software. For example: module, unit, integration, system and
acceptance testing.
25 | P a g e

Recording of defects.
16. Setting quality control limits outside of which corrective action must be taken.
17. Tracking corrective action on defects.
18. Defect data analysis tracking defect trends over time.
15.

6.5.3 Measures of Software Quality


Metric

Formula

Significance

Code
defect
density
NDT/KLOC
(in system test)

Indicates the quality of the code presented to the


system test group

Code
defect
density
NDO/KLOC
(in operation)

Indicates the quality of the code delivered to the


customer

Defect removal NDT/(NDT


efficiency
NDO)

+ Indicates the effectiveness of the test function in


removing defects from the delivered software product

Where:
KLOC = Thousand Lines of Code
NDT = Number of Defects Detected in Testing
NDO = Number of Defects Detected in Operation

Assumptions
We have to ensure the quality of the data of the existing system and the data entering process
of the new system. So we are using a Data Base Administrator (DBA) and a Data
Administrator (DA). As we have to increase the communication process of the system, we
have to use some extra plug-in so we are using two Software Engineers and one Software
Manager (SM) to supervise them. Once a week we are conducting a meeting to ensure the
quality of the process. So DBA, DA, SM and the two Quality Assurance Analysts are
participating to the meeting and they are finally providing a weekly Status Report to the
Quality Manager.

26 | P a g e

7. Risk management plan


7.1 Risk Management Strategies
When developing a system, an area of uncertainty that comes along with developing system.
The purpose of the risk management plan is to establish the framework in which the project
team will identify risks and develop strategies to reduce or avoid those risks.
Process Name

Process Description

Risk Identification

Risk identification should be done in initial step of the


project. So we going to held a project risk assessment
meeting at the beginning. There are few methods to
identify risks. Such as Brainstorming, Delphi Technique,
NGT, Crawford slip etc here we planned to use
Crawford method. In risk assignment meeting Project
manager distribute slips among all team members and
asked to write down every possible risks which related to
the our project within 5 minutes.

Risk
Qualification
Prioritization

Risk Monitoring

and In order to determine the effectiveness of the risks


identified by the team, a probability and impact factor
assign to each risk. This process allows the project
manager to prioritize risks based on the effect they may
have on the project. The project manager develops a
probability impact matrix to facilitate the team in moving
each risk to the appropriate place on the chart. Once the
risks were assigned a probability and impact and placed in
the appropriate position on the chart, the recorder
captured the finished product and the project manager
moved the process on to the next step: risk
mitigation/avoidance planning.
In this step the identified greatest risks have been added to
the project plan and ensure that they are monitoring at the
appropriate time in the project schedule. During team
meetings the Risk manger discussed the status of that risk.
Here we take the risk which is relevant to that time period
according to the schedule. Risk monitoring will be a
continuous process throughout the life of this project.
According to the project schedule The Project manager
ensured that the Risk manager provide the necessary
updates about risk status, trigger conditions,
documentation about risk response etc

27 | P a g e

Risk Mitigation and Avoidance

The project manager led the team to develop responses to


each identified risk. Then the project team develops
avoidance and mitigation strategies. Those risks will be
added to the Risk register and the project plan to ensure
that they are monitored at the appropriate time and
responded to the particular risk. All risks which are
relevant to this project will be managed and controlled
within the project time, scope & cost. All identified risks
will evaluated in order to determine the best way to
respond to each risk to ensure compliance with these
constraints. In extreme cases it may be necessary to allow
flexibility to one of the projects constraints. Here time
and scope are not flexible constrains. Otherwise it will
affect the whole project schedule. Cost is the only flexible
constrain which can change.

Risk Register

The risk register is a record of all identifies risks, their


probability and impact, risk categories, mitigation
strategies etc The risk register also will create at the
initial step of the project. During risk management
meeting, team will identified and categorized each risk.
Based on identified risks and time frames in the risk
register each risk been added to the project plan. Risk
manager will assign a risk manager to ensure agreed
mitigation strategy. Risk manager will provide status
reports of assigned risks according to the planned
timeframe.

7.2 Risk Management Tools

Tool Name

Tool Description

Risk Audits

Risk audits examine and document the effectiveness of


risk responses in dealing with identified risks and their
root causes, as well as the effectiveness of the risk
management process.

Risk Status Report

Weekly report generated by the project team to provide


stakeholders with regular updates on risks and actions
taken to mitigate risks.

Status Meetings

Project risk management can be an agenda item at


periodic status meetings. That item may take no time or

28 | P a g e

Preparing Resource Scope


Statements
Risk Trigger Questions

Risk Lists

Technical Performance
Measurement

a long time, depending on the risks that have been


identified, their priority, and difficulty of response. Risk
management becomes easier the more often it is
practiced, and frequent discussions about risk make
talking about risks, particularly threats, easier and more
accurate.
Defines all project inputs that need to be analyzed as a
part of the risk analysis procedure and this includes
defining expected performance levels.
Lists of situations or events in a particular area of a
municipality that can lead to risk identification. These
are situations or areas where risks have been discovered
within the organization. These trigger questions may be
grouped by areas such as performance, cost, schedule,
software etc
Usually lists of risks that have been found in similar
municipalities and/or similar situations. Caution must
be used when using this type of information to ensure it
is relevant and applicable to the current situation.
Technical performance measurement compares
technical accomplishments during project execution to
the project management plan's schedule of technical
achievement. Deviation, such as demonstrating more or
less functionality than planned at a milestone, can help
to forecast the degree of success in achieving the
project's scope.

7.3 Data Sources

Data Source Name

Data Source Description

Surveys

Technique where lists of questions are developed to seek


out risk in a particular area. A limitation of this method
is that people inherently don't like to complete surveys
and may not provide accurate information. The value of
the surveys may be difficult to determine due to
subjectivity in the answers or because of the focus of the
questions themselves.

Lessons Learned Database

Project Manager maintained database with previous risk


management documentation from earlier projects

29 | P a g e

Experiential Knowledge

The collection of information that a person has obtained


through their experience. Caution must be used when
using any knowledge based information to ensure it is
relevant and applicable to the current situation.

Documented Knowledge

The collection of information or data that has been


documented about a particular subject. This is a source
of information that provides insight into the risks in a
particular area of concern.

Historical Information

Basically the same as documented knowledge. The


difference is that historical information is usually widely
accepted as fact.

Engineering Templates

A set of flow charts for various aspects of the


development process. These templates are preliminary in
nature and are intended as general guidance to
accomplish a top down assessment of activities.

7.4 Risk Categories


Categories

Description

Schedule Risk

Wrong time estimation


Unexpected project scope expansions

Budget Risk

Wrong budget estimation


Cost overruns

Operational Risks

Insufficient resources
No proper system training
No proper resource planning
Less communication in team

Technical Risks

Changing requirements
System is complex to implement
o The number of features
o The volume of content
o The levels of permissions required
o The expected volume of traffic
o The expected number of users
o The expected response times

30 | P a g e

Client or target environment Risk

The level of internet access


The level of interaction with the system required
The impact of the solution on the people using it
The quality of the equipment being used, SMS
gateway/plug-in required etc

Production System Risk

The provision for support and maintenance


The experience of the production support team
members
The age of the production system and versions of
software
The level of supporting documentation and
training

31 | P a g e

7.5 Risk Probability and Impact


Item

Probability (P)

Impact (I)

Total Risk
Score(PxI)

Software & Hardware changes

0.8

6.4

Poor schedule estimation

0.6

4.2

Poor budget estimation and cost


overruns

0.6

4.2

High response time of the system

0.6

3.0

System breakdowns

0.5

10

5.0

High volume of traffic to the system

0.5

3.0

Insufficient resources

0.4

3.2

Lack of communication between team


members

0.3

1.8

Changing requirements & scope


expansions

0.3

2.1

Employee turnover

0.3

1.2

Lack of skills in selected team members

0.3

2.1

Conflict between team members and


university management

0.2

1.0

Conflicts between team members

0.2

1.0

Difficulties in training university staff


to the new system

0.2

0.6

Team member changes

0.1

0.3

University not satisfy about final


outcome

0.1

0.8

Unexpected sudden project closedown

0.1

0.9

Changes in University management

0.1

0.4

32 | P a g e

8. HR management plan
8.1 Project Organization
8.1.1 Project Team
Name

Role

Phone Number Email Address

Waruna
Kodituwakku

Project Manager,
System Admin
System Architect

+94712092875

vharshana@gmail.com

Harshani
Wickramaarac
hi

Quality Assurance
Analysis, Test
Manager, Database
Admin

+94717652239

wwharshi@gmail.com

Aloka Lakmali

Communication
Specialist, Web
Developer, Help
Desk officers

+94774409754

alokaweerasooriya07@g
mail.com

Dasitha
Wijesundara

Business Analyst,
Database warehouse
Engineer

+94718774454

dasitha07@gmail.com

Shanika
Udeshini

HR Manager,
Software Developer,
Help Desk officers

+94776786279

udeshini14@gmail.com

Charaka
Hettiaarachchi

Accountant, Software
Development
Manager, Technical
Writer

+94714438974

djchar89@gmail.com

NimalBandara

Network Engineer

+94784568454

mhnirmalj@gmail.com

Kumudu Lokuge

Assistant Network
Engineer

+94778763944

mrkumudu@gmail.com

Sadishani Rangika

Network Operators

+94714424587

utsadishan@yahoo.com

Sunil de zoysa

Security Specialist

+94753546291

sunilkgfd@yahoo.com

Nirmal Perera

User Interface
Designer( LMS
expertise)

+94779752638

nirmalpra@gmail.com

33 | P a g e

8.1.2 Organization Structure

(For detailed Resource Allocation Plan refer Appendix C)

34 | P a g e

8.1.3 Stakeholders

Information
Technology
Services

Priyantha
Galpaya

Waruna
Harshana

Dasitha Wijeysundara
Charaka Hettiaarachchi
Shanika Udeshinii

Students,
Lecturers,
Administra
tive Staff

Thomas
Andrewson

ChandanaIru
galbandara

Dr.
David
Gibson

Aloka Lakmali
Harshani Wickramarachchi
Nimal Bandara
Kumudu Lokuge
Sadishani Rangika
Nirmal Perera
Sunil De Zoyza
Role on
Project

Project
Sponsor

Chief
Information
Officer
(CIO)

Project
Manager

Project Team

Key
Stakeholde
r

Change
Control
Board

Legal
consultant

Steering
Committee

Organization

South East
Gippsland
University

Exilesoft
(Pvt.) Ltd.

Exilesoft

Exilesoft (Pvt.) Ltd.

South East
Gippsland
University

Information
Technology
Services

Ruhunu
Legal
solutions pvt
ltd

South East
Gippsland
University

priyantha197
8@gmail.co
m

vharshana
@gmail.com

Itsdep.ymail
.com

chan24@ym
ail.co

davefast@ya
hoo.com

Contact
Information

(Pvt.) Ltd.

itpm-group-02@gmail.com

35 | P a g e

Prefers use of
email
for
project
documents

Responsible
for Develop,
maintain, and
facilitate
implementati
on of a sound
and
integrated IT
architecture
as such they
require more
detailed
communicati
ons

Manages day
to day
resources,
provides
project
guidance and
monitors and
reports on the
projects
metrics

Need to have a clear


understanding of the work
to be completed and the
framework in which the
project is to be executed.

Keep
Suggestions
for managing informed of
project
relationships all
progress

Keep
all
information
about
the
project
progress.

He is the
primary
communicator
for the project
distributing
information
according to
this
Communicati
ons
Management
Plan

Require a detailed level of


communications which is
achieved through day to
day interactions with the
Project Manager and other
team members along with
weekly team meetings.

Unique Facts

Keep
informed
about
current
changes
and can get
feedback to
assist the
progress

reviews
technical
specificatio
ns and
authorizes
changes
within the
organization
s
infrastructur
e

Interest about
the
legal
facet of the
project

Ensure that
changes
within
the
organization
are effected
in such a way
that
it
benefits the
organization
as a whole

Technical
design
documents,
user impact
analysis and
implementat
ion
strategies
are used to
communicat
e with them.

Keep
informed
about
the
legal facts of
the project

Steering
Committee
requires
communicati
on on matters
which will
change the
scope of the
project and
its
deliverables

36 | P a g e

8.2Resource Requirements

SW developer
CIO
SW development manager

20

Technical Writer
Security Specialist
Test Manager

15

Help Desk Officers


Web Developer
Data-Warehouse Eng:

10

Database Admin
Network Operator
Assistant Network Engineer

Network Engineer
Business Analyst
HR manager

0
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec

No of Employees

25

2012

2013
year/Month

2014

Accountant
QA Analyst
System Admin

37 | P a g e

1
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.3.9
1.4
1.4.1
1.4.2

Project Initiation and


Planning
Start Project
Define Project Scope
Project Planning
Create task list
Create estimates
Create network diagram (PERT)
Create work breakdown structure (WBS)
Create schedule (GANTT)
Create milestone plan
Create organization plan
Allocate resources
Assign Roles and responsibilities
Establish Project Environment
Identify & acquire equipment and tools for the
project
Supporting Staff

38 | P a g e

NirmalPerera

Sunil de zoysa

SadishaniRangika

KumuduLokuge

NimalBandara

CharakaHettiarachi

ShanikaUdeshini

AlokaLakmali

HarshaniWathsala

Sub Task 2
Waruna Harshana

Sub Task 1

Task Name

ID

Dasitha Wijesundara

8.3 Resource Assignment

1.4.3
1.4.4
1.4.5
1.5
1.6
2
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.3.1
2.3.2
2.3.3
2.4
2.4.1
2.4.2
2.5
2.5.1
2.5.2
2.5.3

Communication Procedure
Documentation Procedure
Workplace
Develop Project Charter
Project Charter Approved
Project Monitoring and Control
Manage Risk
Monitor risks
Specify responses
Manage Human Resources
Develop HR Plan
Form project team
Train project team
Adapt team
Manage scope / cost / schedule
Monitor product changes
Monitor project changes
Renegotiate scope / cost / schedule
commitments
Manage communications
Implement communications methods and
strategies
Distribute information
Documentation
Project team meetings
Retain records
Maintain project charter

39 | P a g e

2.5.4
2.6
2.7
2.8
2.8.1
2.8.2
2.8.3
2.8.4
2.8.5
2.9
2.10
2.11
2.11.1
3
3.1
3.1.1
3.1.2
3.1.3

3.2
3.2.1

document updates
Request for proposal submitted
Response from the client
Manage integration
Update project plan
Update communications plan
Update quality plan
Update risk management plan
Update HR plan
Manage user acceptance
Finalize the conformation
from the university
All project deliverables have been delivered
project closeout
Requirement Analysis and Specification
Requirement
Identification
Prepare research instruments
Interview users
Draft requirements document
Review requirements document
Finalize requirements document
Domain Analysis
Technical feasibility
Operational feasibility
Economic feasibility
Legal feasibility

40 | P a g e

3.3
3.3.1
3.3.2
3.3.3
3.4
4
4.1
4.1.1
4.1.2
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.4
4.5
5
5.1
5.1.1
5.1.2
5.1.3
5.2
5.3
5.3.1
5.3.2
5.3.3
5.4

Software Requirement Specification (SRS)


Identify general background of the project
Requirement analysis and elicitation
Requirement specification
All deliverables have been delivered
Quality Management
Develop Software Quality Management Plan
Define quality criteria
Define quality assessment methods
Monitor product quality
Analyze defects reported
Analyze change requests submitted
Analyze tests failed
Analyze requirements revised
Perform audits/ Quality Improvements
Evaluate project quality
Design
Architectural Design
Develop use cases
Create data architecture
Create hardware architecture
Purchase student management system
Design the Database
Design database for sub system
design central database system
Provide weekly updates
Interface Designing

41 | P a g e

5.4.1
5.4.2
5.4.3
5.5
5.6
6
6.1
6.2
6.2.1
6.2.2

Design user interfaces

Design software interfaces

Design additional plug-ins


Develop System Architecture

Create Software Design Specification (SDS)


Implementation
Develop Prototype with Purchased student management system
Wireless communication
Check the drawbacks of the wireless broadband
Implement wireless broadband hardware &
software

6.2.3
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
6.3.8
6.3.9
6.3.10
6.4
6.5
6.6

Integration it to the current university network


Develop System
Develop UI
Develop objects
Develop workflow
Develop rules
Develop middle tier
Develop database
Develop connections with other systems
Develop permissions
Develop migration scripts
Develop System Documentation
IT service help desk establish
Create User Documentation
Implementation Completed

42 | P a g e

7
7.1
7.2
7.3
7.3.1
7.3.2
7.4
7.5
8
8.1
8.1.1
8.1.2
8.1.3
8.1.4
8.1.5
8.2
8.3
8.4
8.4.1
8.4.2
8.4.3
8.4.4
8.5
8.6
8.7
8.8
8.9

Installation
Develop Installation Plan
Install Software
Database
Migrate data (previous)
Back up databases
Install Hardware components
Installation Completed
Testing
Develop Tests
Develop Unit Tests
Develop System Tests
Develop integration tests
Develop environment tests
Develop migration tests
Configure test environment
Select Testing tools
Execute tests
Execute manual tests
Execute automated tests
Execute beta test
Execute user acceptance test
Analyze test results
Compile test statistics
Version finalized
Version approved for deployment
Upload current data to the system

43 | P a g e

8.10
9
9.1
9.1.1
9.1.2
9.1.3
9.1.4
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
9.3.5
9.4
9.4.1
9.4.2
9.5
10
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8

Testing Completed
Training
Form Staff
Identify project HR requirements
Select staff members
Recruit consultants
Hire new staff
Schedule training
Train Staff
Develop project training materials
Attend business orientation
Attend technical orientation
Attend internal class
Attend external class
Adapt team
Attend team-building activity
Support remote/virtual/telecommuting work
Training Completed
Maintenance
Perform impact analysis
Monitor user acceptance
Monitor performance
Monitor defects
Resolve training and support issues
Resolve technical problems
Analyze statistics
Gather requirements for enhancements

44 | P a g e

9. Communication plan
9.1 Stakeholder Analysis

Information
Technology
Services

Priyantha
Galpaya

Waruna
Kodituwakku

Dasitha Wijeysundara
Charaka Hettiaarachchi
Shanika Udeshinii

Students,
Lecturers,
Administrative
Staff

Thomas
Andrewson

ChandanaIrug
albandara

Dr. David
Gibson

W.L.A.T.A.Lakmali
Harshani
Wickckramaarachchi
Nimal Bandara
Kumudu Lokuge
Sadishani Rangika
Nirmal Perera
Sunil De Zoyza
Role on
Project

Project
Sponsor

Chief
Information
Officer (CIO)

Project Manager

Project Team

Key Stakeholder

Change
Control
Board

Legal
consultant

Steering
Committee

Organization

South East
Gippsland
University

Exilesoft (Pvt.)
Ltd.

Exilesoft (Pvt.)
Ltd.

Exilesoft (Pvt.) Ltd.

South East
Gippsland
University

Information
Technology
Services

Ruhunu Legal
solutions (Pvt)
ltd

South East
Gippsland
University

Priyantha1978
@gmail.com

vharshana
@gmail.com

itpm-group02@googlegroups.com

itsdep.ymail.c
om

chan24@ymai
l.co

davefast@yah
oo.com

responsible for

manages day to

Need to have a clear

reviews

Interest about

Ensure that

Contact
Information
Unique Facts

Prefers use

45 | P a g e

of email for
project
documents

Develop,
maintain, and
facilitate
implementation
of a sound and
integrated IT
architecture as
such they
require more
detailed
communication
s

day resources,
provides project
guidance and
monitors and
reports on the
projects metrics

understanding of the
work to be completed
and the framework in
which the project is to be
executed.

technical
specifications
and
authorizes
changes
within the
organizations
infrastructure

the legal facet


of the project

changes within
the
organization
are effected in
such a way
that it benefits
the
organization
as a whole

Level of
Interest

High

High

High

High

Medium

High

High

High

Level of
Influence

High

High

High

High

Low

High

High

High

Suggestions
for managing
relationships

Keep
informed of
all project
progress

Keep all
information
about the
project
progress.

He is the primary
communicator for
the project
distributing
information
according to this
Communications
Management Plan

Require a detailed level


of communications
which is achieved
through day to day
interactions with the
Project Manager and
other team members
along with weekly team
meetings.

Keep informed
about current
changes and can
get feedback to
assist the progress

Technical
design
documents,
user impact
analysis and
implementati
on strategies
are used to
communicate
with them.

Keep informed
about the legal
facts of the
project

Steering
Committee
requires
communicatio
n on matters
which will
change the
scope of the
project and its
deliverables

46 | P a g e

9.2 Project Reports


Data Needed

Frequen
cy of
Collectio
n

Responsible Party
for Data Collection
& Analysis

Report Media
& Format

Responsible
Party for
Distributing
Report

Trend
Analysis

Past project
data,Previous Status
reports

Monthly

Project Team

Printed
document with
calculations

Project Manager

Variance
Analysis

Proposed
results,actual results

Biweekly

Project Team

Through email,
favourable and
adverse
mentioned

Project Manager

Previous
records,estimations,

Monthly

Project Team

Printed
copy,handed

Project Manager

Earned
Value
Analysis

proposed bugdet

individually

Schedule
Status

Tracking Gantt Chart

BiWeekly

Project Team

Status Form

Project Manager

Project
progress
Report

Work has been


completed and works
to be completed
through the meetings
that have among
project team

BiWeekly

Project Team

Printed
document

Project Manager

Project
Status
Report

Status of the project


including activities,
progress, costs and
issues, e-mails (sent
by team members),
Analyzing the
workload

Monthly

Project Sponsor

Printed
document

Project Manager

Project Team
Stakeholders

47 | P a g e

9.3 Project Meetings


Purpose

Frequenc
y

Attendees

Reporting
Requirements

Kickoff
Meeting

Introduce the project team and


the project. Review project
objectives and management
approach

Once

Project Sponsor,
Project Manager,
Project Team,
Stakeholders, CIO

Meeting
Minutes

Status
Review
Meeting

Update on project status

Weekly

Project Manager,
Project Team

Meeting
Minutes,
variance and
trend analysis,
Status report

Monthly
Project Status
Meetings

Report on the status of the


project to management

Monthly

Project Manager, PMO

Monthly Status
Report

Project Status
Reports

Report the status of the project


including activities, progress,
costs and issues

Monthly

Project Sponsor,
Project Team, Project
manager, CIO,
Stakeholders

Project Status
Report

Technical
Design
Meeting

Discuss and develop technical As needed Project Technical staff


design solutions for the project

Design
specification
documents,Req
uirement
specification
documents

9.4 Project Information Accessibility


It is important to keep project information secured from outsiders and it is critical to the
success of the project. Considering about the ASMS project of South East Gippsland
University it is very important to keep all information in a secured place and allow access
those information to relevant persons. So consider about those facts we are going to store all
the information related with the ASMS project in a web site that created for the project. Team
members and stakeholders can access that information by log in to the site to do that first they
have to register to the site and create user accounts. Administrator of the site will grant the
relevant privileges to the users according to their user level.

48 | P a g e

In addition to that all the documents that related to the project will be e-mailed to the project
management group mail. For an example people who responsible to do the work allocated by
project manager, after completing the work he can send it to the group mail. So anyone
interest with it can access it according to their necessity.

9.5 Communications Summary

Stakeholder

Type

Communication
Medium

Frequency

Responsible Party

Kickoff Meeting

Face to Face

Once

Project Manager

By Weekly

Project Manager

As Needed

Project Technical Lead

Monthly

Project Manager

Monthly

Project Manager

Project Sponsor
Project Team
Key Stakeholders
Project Team

Project Team
Meetings

Face to Face
Conference Call

Project Technical
Staff

Technical Design Face to Face


Meetings

PMO(Project
Management
Office)

Monthly Project
Status Meetings

Project Sponsor
Project Team
Key Stakeholders
PMO

Project Status
Reports

Face to Face
Conference Call

Email

49 | P a g e

Vous aimerez peut-être aussi