| Date post: | 07-Nov-2015 |
| Category: |
Documents |
| Upload: | ilham-widyasa |
| View: | 7 times |
| Download: | 0 times |
___________________________________
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
2 | P a g e
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
3 | P a g e
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
4 | P a g e
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.
5 | P a g e
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.
6 | P a g e
2. Project
2.1 Project Information
Project Start Date: 2nd of May, 2012
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.
Project End Date: 30th of May, 2014
7 | P a g e
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.
Project Execution In this phase following activities will be
done.
1. Monitoring & Control
1. Requirement Analysis & Specification
2. Design
3. Implementation
4. Quality Management
5. Training
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 [email protected]
Charaka Hettiarachchi Accountant Accountant [email protected]
Shanika Udeshini Human
Resources
Manager
Human Resources
Manager
m
Aloka Weerasuriya Communications
Manager
Communications
Manager
alokaweerasooriya07@
gmail.com
Dasitha Wijesundara Business Analyst Business Analyst [email protected]
Harshani
Wickramarachchi
Quality
Assurance
Analyst
Quality Assurance
Analyst
8 | P a g e
NimalBandara Network
Engineer
Network Engineer [email protected]
Kumudu Lokuge Assistant
Network
Engineer
Assistant Network
Engineer
m
Sadishani Rangika Network
Operators
Network Operators [email protected]
m
Sunil de zoysa Security
Specialist
Security Specialist [email protected]
Nirmal Perera User Interface
Designer( LMS
expertise)
User Interface
Designer( LMS
expertise)
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.
9 | P a g e
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
10 | P a g e
Testing 110 days (parallel)
Training 30 days (parallel)
Maintenance 65 days(parallel)
2.7.2 Preliminary Budget Estimate
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
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
11 | 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., computer-
based 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)
12 | 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 ([email protected])
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.
13 | 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.
14 | 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)
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. Modifications to software.
2. Purchase of 3rd party software.
3. Changes to contracted professional services (e.g. additional consulting visits).
4. Scope (includes modules, data conversion and migration, interfaces, etc.).
5. Milestone dates, including interim milestones and major go-lives.
6. Additional project spending (hardware, training, conferences, etc).
7. 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
16 | P a g e
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. Project Manager
2. Business Analyst
3. Software Developing Manager
4. Change Review Team members
17 | 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.
18 | 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,
19 | 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)
20 | 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)
21 | P a g e
6. Quality Management plan
6.1 Quality Standards
Project process/ Reports Quality Standards
Project Planning and Management
Project Plan
Configuration Management
Plan
Quality Assurance Plan
Project Status
Reports/ongoing Project
Management
Technology Assessment
Report
Feasibility Report
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.
IEEE 1058
Requirements Analysis Process
Prototypes and other
diagrams
Flowcharts
System Requirements
Specification Document
(SRS)
Functional Specifications
Document (FS)
Requirements Traceability
Matrix
Use Cases
Once the requirement analysis process is complete in that
case team members provide comprehensive documentation
covering all requirements gathered.
IEEE 830
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)
Transform the requirements into complete and detailed
system design specifications. Once the design is approved,
the Development Team begins the Development Phase.
IEEE 1016
22 | 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
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.
Testing
Unit and Integration Test
plan
Software Validation and
Verification Plan (SVVP)
Software Test
Documentation (STD)
The team will be test the system in the relevant
environment and fix the errors.
IEEE 1012
IEEE 829
Maintenance
Maintenance Manual
Maintenance and Support
Services From
Keeps the system up to date with environment changes and
changing user requirements.
IEEE1993
23 | 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
specifications with zero defects.
TQM creates a virtuous cycle of
continuous improvement that boosts
production, customer satisfaction
and profits.
Quality Assurance Analyst
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
24 | 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
Acquisition Plan
Installation Plan
Revised Project
Plan
ISA Process- (review
process and audit contents )
Software Design Functional Design
Document
Security Plan
Training Plan
System Test Plan
Acceptance Plan
Conf. Mgmt. Plan
Conversion Plan
Traceability
Matrix
Revised Project
Plan
ISA Process- (review
process and audit contents )
Trace design components to
requirements
Trace requirements to
design components
Programming and
Integration
Site Installation Plan,
System Documentation
Revised Project
Plan
ISA Process- (review
process and audit contents )
System Testing and
Acceptance
Test results, System
Documentation
Operational System
Revised Project
Plan
ISA Process- (review
process and audit contents )
25 | 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. Check that assumptions and criteria for the selection of data and the different factors
related to data are documented.
2. Check for transcription errors in data input and reference.
3. Check the integrity of database files.
4. Check for consistency in data.
5. Check that the movement of inventory data among processing steps is correct.
6. Check for uncertainties in data, database files etc.
7. Undertake review of internal documentation.
8. Check methodological and data changes resulting in recalculations.
9. Undertake completeness checks.
10. Compare results to previous results.
11. Defining and classifying the severity of defects.
12. Inspecting documents.
13. Inspecting code .(either manually or via automatic static code analysis)
14. Testing executable software. For example: module, unit, integration, system and
acceptance testing.
26 | P a g e
15. 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.
6.5.3 Measures of Software Quality
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.
Metric Formula Significance
Code defect
density
(in system test)
NDT/KLOC Indicates the quality of the code presented to the
system test group
Code defect
density
(in operation)
NDO/KLOC Indicates the quality of the code delivered to the
customer
Defect removal
efficiency
NDT/(NDT +
NDO)
Indicates the effectiveness of the test function in
removing defects from the delivered software product
27 | 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 and
Prioritization
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.
Risk Monitoring 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
28 | 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
29 | P a g e
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.
Preparing Resource Scope
Statements
Defines all project inputs that need to be analyzed as a
part of the risk analysis procedure and this includes
defining expected performance levels.
Risk Trigger Questions 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
Risk Lists 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
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
30 | 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
31 | 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
32 | P a g e
7.5 Risk Probability and Impact
Item Probability (P) Impact (I) Total Risk
Score(PxI)
Software & Hardware changes 0.8 8 6.4
Poor schedule estimation 0.6 7 4.2
Poor budget estimation and cost
overruns
0.6 7 4.2
High response time of the system 0.6 5 3.0
System breakdowns 0.5 10 5.0
High volume of traffic to the system 0.5 6 3.0
Insufficient resources 0.4 8 3.2
Lack of communication between team
members
0.3 6 1.8
Changing requirements & scope
expansions
0.3 7 2.1
Employee turnover 0.3 4 1.2
Lack of skills in selected team members 0.3 7 2.1
Conflict between team members and
university management
0.2 5 1.0
Conflicts between team members 0.2 5 1.0
Difficulties in training university staff
to the new system
0.2 3 0.6
Team member changes 0.1 3 0.3
University not satisfy about final
outcome
0.1 8 0.8
Unexpected sudden project closedown 0.1 9 0.9
Changes in University management 0.1 4 0.4
33 | 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 [email protected]
Harshani
Wickramaarac
hi
Quality Assurance
Analysis, Test
Manager, Database
Admin
+94717652239 [email protected]
Aloka Lakmali Communication
Specialist, Web
Developer, Help
Desk officers
+94774409754 alokaweerasooriya07@g
mail.com
Dasitha
Wijesundara
Business Analyst,
Database warehouse
Engineer
+94718774454 [email protected]
Shanika
Udeshini
HR Manager,
Software Developer,
Help Desk officers
+94776786279 [email protected]
Charaka
Hettiaarachchi
Accountant, Software
Development
Manager, Technical
Writer
+94714438974 [email protected]
NimalBandara Network Engineer +94784568454 [email protected]
Kumudu Lokuge Assistant Network
Engineer
+94778763944 [email protected]
Sadishani Rangika Network Operators +94714424587 [email protected]
Sunil de zoysa Security Specialist +94753546291 [email protected]
Nirmal Perera User Interface
Designer( LMS
expertise)
+94779752638 [email protected]
34 | P a g e
8.1.2 Organization Structure
(For detailed Resource Allocation Plan refer Appendix C)
35 | P a g e
8.1.3 Stakeholders
Information
Technology
Services
Priyantha
Galpaya
Waruna
Harshana
Dasitha Wijeysundara
Charaka Hettiaarachchi
Shanika Udeshinii
Aloka Lakmali
Harshani Wickramarachchi
Nimal Bandara
Kumudu Lokuge
Sadishani Rangika
Nirmal Perera
Sunil De Zoyza
Students,
Lecturers,
Administra
tive Staff
Thomas
Andrewson
ChandanaIru
galbandara
Dr. David
Gibson
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
(Pvt.) Ltd.
Exilesoft (Pvt.) Ltd. South East
Gippsland
University
Information
Technology
Services
Ruhunu
Legal
solutions pvt
ltd
South East
Gippsland
University
Contact
Information
priyantha197
m
vharshana
@gmail.com
[email protected] Itsdep.ymail
.com
chan24@ym
ail.co
davefast@ya
hoo.com
36 | P a g e
Unique Facts 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.
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
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
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.
Keep
informed
about
current
changes
and can get
feedback to
assist the
progress
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
37 | P a g e
8.2Resource Requirements
0
5
10
15
20
25M
ay Jun
Jul
Au
g
Sep
Oct
No
v
De
c
Jan
Feb
Mar
Ap
r
May Jun
Jul
Au
g
Sep
Oct
No
v
De
c
Jan
Feb
Mar
Ap
r
May Jun
Jul
Au
g
Sep
Oct
No
v
De
c
2013 2014
No
of
Emp
loye
es
year/Month
SW developer
CIO
SW development manager
Technical Writer
Security Specialist
Test Manager
Help Desk Officers
Web Developer
Data-Warehouse Eng:
Database Admin
Network Operator
Assistant Network Engineer
Network Engineer
Business Analyst
HR manager
Accountant
QA Analyst
System Admin2012
38 | P a g e
8.3 Resource Assignment
ID T
ask
Nam
e Sub Task 1 Sub Task 2
Waru
na H
ars
han
a
Hars
han
iWath
sala
Alo
kaL
ak
mali
Dasi
tha W
ijes
un
dara
Sh
an
ikaU
des
hin
i
Ch
ara
kaH
etti
ara
chi
Nim
alB
an
dara
Ku
mu
du
Lok
uge
Sad
ish
an
iRan
gik
a
Su
nil
de
zoysa
Nir
malP
erer
a
1 Project Initiation and
Planning
1.1 Start Project
1.2 Define Project Scope
1.3 Project Planning
1.3.1 Create task list
1.3.2 Create estimates
1.3.3 Create network diagram (PERT)
1.3.4 Create work breakdown structure (WBS)
1.3.5 Create schedule (GANTT)
1.3.6 Create milestone plan
1.3.7 Create organization plan
1.3.8 Allocate resources
1.3.9 Assign Roles and responsibilities
1.4 Establish Project Environment
1.4.1 Identify & acquire equipment and tools for the
project
1.4.2 Supporting Staff
39 | P a g e
1.4.3 Communication Procedure
1.4.4 Documentation Procedure
1.4.5 Workplace
1.5 Develop Project Charter
1.6 Project Charter Approved
2 Project Monitoring and Control
2.1 Manage Risk
2.1.1 Monitor risks
2.1.2 Specify responses
2.2 Manage Human Resources
2.2.1 Develop HR Plan
2.2.2 Form project team
2.2.3 Train project team
2.2.4 Adapt team
2.3 Manage scope / cost / schedule
2.3.1 Monitor product changes
2.3.2 Monitor project changes
2.3.3 Renegotiate scope / cost / schedule
commitments
2.4 Manage communications
2.4.1 Implement communications methods and
strategies
2.4.2 Distribute information
2.5 Documentation
2.5.1 Project team meetings
2.5.2 Retain records
2.5.3 Maintain project charter
40 | P a g e
2.5.4 document updates
2.6 Request for proposal submitted
2.7 Response from the client
2.8 Manage integration
2.8.1 Update project plan
2.8.2 Update communications plan
2.8.3 Update quality plan
2.8.4 Update risk management plan
2.8.5 Update HR plan
2.9 Manage user acceptance
2.10 Finalize the conformation
from the university
2.11 All project deliverables have been delivered
2.11.1 project closeout
3 Requirement Analysis and Specification
3.1 Requirement
Identification
3.1.1 Prepare research instruments
3.1.2 Interview users
3.1.3 Draft requirements document
Review requirements document
Finalize requirements document
3.2 Domain Analysis
3.2.1 Technical feasibility
Operational feasibility
Economic feasibility
Legal feasibility
41 | P a g e
3.3 Software Requirement Specification (SRS)
3.3.1 Identify general background of the project
3.3.2 Requirement analysis and elicitation
3.3.3 Requirement specification
3.4 All deliverables have been delivered
4 Quality Management
4.1 Develop Software Quality Management Plan
4.1.1 Define quality criteria
4.1.2 Define quality assessment methods
4.2 Monitor product quality
4.2.1 Analyze defects reported
4.2.2 Analyze change requests submitted
4.2.3 Analyze tests failed
4.2.4 Analyze requirements revised
4.4 Perform audits/ Quality Improvements
4.5 Evaluate project quality
5 Design
5.1 Architectural Design
5.1.1 Develop use cases
5.1.2 Create data architecture
5.1.3 Create hardware architecture
5.2 Purchase student management system
5.3 Design the Database
5.3.1 Design database for sub system
5.3.2 design central database system
5.3.3 Provide weekly updates
5.4 Interface Designing
42 | P a g e
5.4.1 Design user interfaces
5.4.2 Design software interfaces
5.4.3 Design additional plug-ins
5.5 Develop System Architecture
5.6 Create Software Design Specification (SDS)
6 Implementation
6.1 Develop Prototype with Purchased student management system
6.2 Wireless communication
6.2.1 Check the drawbacks of the wireless broadband
6.2.2 Implement wireless broadband hardware &
software
6.2.3 Integration it to the current university network
6.3 Develop System
6.3.1 Develop UI
6.3.2 Develop objects
6.3.3 Develop workflow
6.3.4 Develop rules
6.3.5 Develop middle tier
6.3.6 Develop database
6.3.7 Develop connections with other systems
6.3.8 Develop permissions
6.3.9 Develop migration scripts
6.3.10 Develop System Documentation
6.4 IT service help desk establish
6.5 Create User Documentation
6.6 Implementation Completed
43 | P a g e
7 Installation
7.1 Develop Installation Plan
7.2 Install Software
7.3 Database
7.3.1 Migrate data (previous)
7.3.2 Back up databases
7.4 Install Hardware components
7.5 Installation Completed
8 Testing
8.1 Develop Tests
8.1.1 Develop Unit Tests
8.1.2 Develop System Tests
8.1.3 Develop integration tests
8.1.4 Develop environment tests
8.1.5 Develop migration tests
8.2 Configure test environment
8.3 Select Testing tools
8.4 Execute tests
8.4.1 Execute manual tests
8.4.2 Execute automated tests
8.4.3 Execute beta test
8.4.4 Execute user acceptance test
8.5 Analyze test results
8.6 Compile test statistics
8.7 Version finalized
8.8 Version approved for deployment
8.9 Upload current data to the system
44 | P a g e
8.10 Testing Completed
9 Training
9.1 Form Staff
9.1.1 Identify project HR requirements
9.1.2 Select staff members
9.1.3 Recruit consultants
9.1.4 Hire new staff
9.2 Schedule training
9.3 Train Staff
9.3.1 Develop project training materials
9.3.2 Attend business orientation
9.3.3 Attend technical orientation
9.3.4 Attend internal class
9.3.5 Attend external class
9.4 Adapt team
9.4.1 Attend team-building activity
9.4.2 Support remote/virtual/telecommuting work
9.5 Training Completed
10 Maintenance
10.1 Perform impact analysis
10.2 Monitor user acceptance
10.3 Monitor performance
10.4 Monitor defects
10.5 Resolve training and support issues
10.6 Resolve technical problems
10.7 Analyze statistics
10.8 Gather requirements for enhancements
45 | P a g e
9. Communication plan
9.1 Stakeholder Analysis
Information
Technology
Services
Priyantha
Galpaya
Waruna
Kodituwakku
Dasitha Wijeysundara
Charaka Hettiaarachchi
Shanika Udeshinii
W.L.A.T.A.Lakmali
Harshani
Wickckramaarachchi
Nimal Bandara
Kumudu Lokuge
Sadishani Rangika
Nirmal Perera
Sunil De Zoyza
Students,
Lecturers,
Administrative
Staff
Thomas
Andrewson
ChandanaIrug
albandara
Dr. David
Gibson
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
Contact
Information
Priyantha1978
@gmail.com
vharshana
@gmail.com
itpm-group-
itsdep.ymail.c
om
chan24@ymai
l.co
davefast@yah
oo.com
Unique Facts Prefers use responsible for manages day to Need to have a clear reviews Interest about Ensure that
46 | 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
47 | 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
Bi-
weekly
Project Team Through e-
mail,
favourable and
adverse
mentioned
Project Manager
Earned
Value
Analysis
Previous
records,estimations,
proposed bugdet
Monthly Project Team Printed
copy,handed
individually
Project Manager
Schedule
Status
Tracking Gantt Chart Bi-
Weekly
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
Bi-
Weekly
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
Project Team
Stakeholders
Printed
document
Project Manager
48 | 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
design solutions for the project
As needed Project Technical staff 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.
49 | 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
Project Sponsor
Project Team
Key Stakeholders
Kickoff Meeting
Face to Face
Once
Project Manager
Project Team Project Team
Meetings
Face to Face
Conference Call
By Weekly Project Manager
Project Technical
Staff
Technical Design
Meetings
Face to Face As Needed Project Technical Lead
PMO(Project
Management
Office)
Monthly Project
Status Meetings
Face to Face
Conference Call
Monthly Project Manager
Project Sponsor
Project Team
Key Stakeholders
PMO
Project Status
Reports
Email Monthly Project Manager
