Developing of Online Enrolment System

Published Date: 28 Feb 2018

Preface

This software project management plan is intended to act as an outline of the development of a new honours system for Buena Vista College Administration. This plan will provide the structure and basis of the development of the new system. This includes outlining the deliverables, providing a schedule and organisational structure, and producing the associated plans needed for development of this project. This plan is intended to be used by the project team, as a development guide, throughout the life of the project, and by management as a reference to the details of the design as well as the progress of the project.

1.0 Project Overview

The overview of the project provides a brief outline of the major details of the project, including identifying the project, stating what is expected form the project, and a summary of both schedule and budget.

1.1 Purpose, Scope & Objectives

The purpose of this project is to upgrade the existing enrolment system for Buena Vista College. The upgrade will consist of an added function, allowing administration staff to automatically compute students' eligibility for entrance into honours programs.

This new system will be integrated into the existing enrolment system. The project team will be restricted to adding the honours function only; fixing defects or adding other functionality is out of the scope of this project. The scope of the project does however include the implementation of any additional packaged software.

The objective of this project is to meet the university's business need of improving efficiencies, in order to lower operating costs and remain competitive. These needs are further defined below:

v Overall quicker processing of applications to honour programs. Current methods are manual, making them both time consuming and prone to error.

v A more effective handling of honors applications

v Develop a readily accessible assessment report of current applicants

v Develop a readily accessible honors entrance summary report

1.2 Assumption and Constraints

There are several assumptions and constraints relating to the project team developing an honours system for Buena Vista College. They can be found in table 1.1 (below).

Table 1.1: Assumptions, constraints and impacts

Assumptions

Impact on plan if false

The group size will remain at five members through-out the life of the project

The plan will need to be rescheduled to accommodate the change. Tasks will also have to be reallocated.

The client has not specified a due date.

The project will require heavy rescheduling, and possibly an outsourcing arrangement.

The university will approve financing the system.

The project will not go ahead.

Client will be able to be contacted at all times

May delay production, therefore extending the schedule.

Constraints

Impact on plan if false

Project team is constrained by design of current administration system

Project would be developed in a manner best suited to the project team. The plan would need to be recompiled, to conform to the new design.

1.3 Project Deliverables

The following list specifies the elements of the project to be formally completed as a deliverable. A full list of both deliverable and non-deliverable work products is included in section 7.3.

Table 1.2: Project Deliverables

Statement of User Requirements and Acceptance Criteria

Formally identifies the requirements of the system, specified by the client. This document needs to be reviewed and accepted cby the client.

Software Project Management Plan

Details the processes, tools and techniques that are to be used in the development of the project.

User Documentation

A manual for users clearly explaining system.

System (Software)

Formal hand over of new system to the client.

1.4 Schedule and Budget Summary

The schedule and budget for this project is based upon the waterfall Software Design Life Cycle (SDLC) being adopted for this project.

Table 1.3: Schedule and Budget Summary

Phase

Begun

Finished

Cost

Requirements

04/11/2002

08/11/2002

$1,642.67

Analysis

11/11/2002

25/11/2002

$5,923.44

Design

26/11/2002

13/12/2002

$6,608.00

Coding

16/12/2002

03/03/2003

$36,216.00

Testing and Implementation

04/04/2003

25/04/2003

$6,308.31

TOTALS

Project life is approx 125 days

$56,968.42

The worst-case and best-case scenarios deviate less than 10% from the above summary.

The full schedule and budget can be found in section 5.2.2 and 5.2.4 respectively, and in APPENDIX.

1.5 Evolution of the Project Plan

This plan will be completed when it passes two criteria:

v All elements of the Software Project Management Plan Template (Walden), are included in this document, and

v The document passes a quality review, outlined in the Quality Assurance Plan (Section 7.4).

At the completion of this document it will be labelled version 1.0 and shall be put under change control, whereby it may only be changed through the processes outlined in the Configuration Management Plan (Section 7.1).

This process shall be made available to all members of the project team, as well as any member of management who requests it.

Scheduled updates will be conducted at reviews undertaken at each milestone specified in the Project Reviews (Section 7.5). Unscheduled updates may be conducted at any stage during the development of the project, as long as the project manager approves changes. Regardless of whether the updates are scheduled or not, any change to this plan must comply with the change control plan outlined in the Configuration Management Plan (Section 7.1).

2.0 References

Buena Vista College (1997) Configuration Management Plan v2.0, Buena Vista College Press, LOCATION

Buena Vista College (2001) Quality Management Plan v3.1, Buena Vista College Press, LOCATION

Buena Vista College (1999) Verification and Validation Plan v1.2 Buena Vista College Press, LOCATION

Buena Vista College (2002) Work Product Plan v4.0 Buena Vista College Press, LOCATION

IEEE Computer Society (1999) Volume Two: Process Standards, IEEE Inc.: New York, U.S.A.

Walden, J. (1999) Software Project Management Plan Template v3.0, Department of Information Resources.

PMBOK

Rout & Hodgen (2002) - lec notes

ROUT CASE STUDY

SCHWALBE

ALAVI M 1999

RUDOPLH EBERHADT LEC NOTES ON ESTIMATING

ADD STANDARDS REFERED TO IN THE SUPPORTING PROCESS PLANS

ALPHABETISE REFERENCES.

3.0 Acronyms and Definitions

The table below shows all acronyms used and their definitions, in alphabetical order.

Table 3.1:Acronyms & Definitions (Alphabetical)

Acronyms

Definitions

BVC - CMP

Buena Vista College Configuration Management Plan

BVC - QMP

Buena Vista College Quality Management Plan

BVC - VVP

Buena Vista College Verification and Validation Plan

BVC - WPP

Buena Vista College Work Product Plan

Client

Buena Vista College Administration

COCOMO

Constructive Cost Model

COSMOS

Software Cost Modelling System

FPA

Function Point Analysis

IT Group

Buena Vista College Information Technology Group

PM

Project Manager

PPR

Post-project Review

Project Team

Members of the IT Group working on the system

QE

Quality Engineer

SDD

Software Design Description

SDLC

Software Design Life Cycle

SPMP

Software Project Management Plan

SRS

Software Requirements Specification

SURAC

Statement of User Requirements and Acceptance Criteria

System

Buena Vista College Administration honours system being developed by the project team

TD

Test Documentation

TP

Test Plan

UD

User Documentation

4.0 Project Organisation

Project organisation involves identifying the external and internal interfaces as well as the roles and responsibilities of each member of the project team.

4.1 External Interfaces

External interfaces summarise the relationship between the project team, the client, and any other entities associated with the project.

This project does not have a true external interface existing between two parties, as both the acquirer and developer are part of the same larger organisation. The project shall exist in an environment separated from non-university bodies.

The following table highlights the project team's organisational interactions and the interface/ liaison to each organisation.

Table 3: External interfaces

Organisation

Role/s

Interfaces with

Project Team

Develop of system

Client & IT Department

IT Department

Oversee project at highest level

Client & Project Team

Buena Vista College

Client; Managerial superior of IT dept and project team

Project Liaison interfaces with Project Team & IT Dep't

The Project Manager will be responsible for interfacing with anything outside of the project team. This includes the client liaison, the IT Director, and any other external body.

It is important to mention that the IT Director has strong personal interest in this project, as he wishes to prove to the university that the IT department is a capable body. We expect that he will impact heavily upon the interface between the client and the project.

Buena Vista College are both the client, and organisational superiors to all involved in the project.

4.2 Internal Structure

The internal structure of Buena Vista College outlines the managerial hierarchy of the project team, identifying whom each member is reportable to. The structure also distinguishes the other known elements of the organisation, and their relation to each other.

4.5 Roles and Responsibilities

The following table identifies the roles of each person in the team, and the subsequent responsibilities related to that role.

Table 4: Roles and responsibilities

Role

Responsibilities

Project Manager

* conflict resolution

* task allocation

* project monitoring and improvement

* project team leadership

* liaise with both client and superiors

Quality Engineer

* review all deliverables for quality

* produce quality plan

* system testing

System Analyst/ Designer

* analysis

* design

* testing

Programmers

* coding

* source code documentation

* testing

5.0 Managerial Process Plans

This section contains the managerial plans that shall be employed during this project. These plans are all subject to change and improvement. The plans have been created using both external knowledge, and personal judgement. External knowledge used includes IEEE standards and the PMBOK guide.

5.1 Start-Up Plan

The project's cost and schedule shall be determined by how much effort will be required for this project. In order to determine the effort, the system size must be estimated. This shall be done using function-point analysis (FPA), and Constructive Cost Model (COCOMO) analysis.

5.1.1 Measuring System Size

The FPA will yield an approximation to the system's size, which includes an estimate to the number of lines of code required. The FPA will be based upon the statement of user requirements; all data requirements, functions, and reports shall be approximated based upon the user's specifications. Please be aware that the FPA is executed after the user the requirements have been gathered, and that the project has already begun.

5.1.2 Measuring Effort Required and Determining Schedules

Measuring the amount of effort needed for this system can be measured in terms time required. Because the FPA provides an approximation to the size of the system, it can be used as the basis for measuring time required. Accordingly, the FPA results will be fed into a COCOMO analysis. Again, please be aware that this analysis is done once the project has begun, and does not include the effort required to gain, study, and synthesise the user requirements.

The COCOMO analysis shall provide an estimate on the amount of time required to complete the project. The time required shall be displayed in a three phase breakdown; design, programming, and integration and testing. These phases shall then be broken down into activities, which shall be further broken down into tasks. Effort/time required for activities will be guided by the estimate provided in the COCOMO analysis. These estimations will be based upon the outlines given in section 7.2 of the PMBOK (Cost Estimating). In turn, the effort/time required for tasks shall be based upon the estimate for the activity that the task is part of.

The COCOMO analysis has only been used to determine the effort required from schedule task 2.2 (Process Implementation), to schedule task 5.3 (Configuration Evaluation). To be more specific, the COCOMO product design phase includes section 2.2 to 3.2; the COCOMO programming phase includes all of section 4; and COCOMO integration and testing phase includes all of section 5. The schedule may be found in Appendix.

A diagrammatic mapping the breakdown of work, or Work Breakdown Structure (WBS), is included in APPENDIX. The WBS shall then be used to calculate the project schedule, shown in APPENDIX.

5.1.3 Measuring Project Cost

Cost is associated with three key indicators, size, quality, and productivity (Rudolph, 2002, p9). Unfortunately quality and productivity are too difficult to measure.

Because system size can be measured in terms of effort, which is measured in terms of time, the hours required to complete the effort tasks can be translated to money (As staff pay can be calculated hourly.). By looking at the schedule, a monetary value shall be assigned to each resource used, eg. staff, hardware, training, etc.

5.1.4 Tools Employed in Calculating Size, Effort &Cost

The tool (application) that shall be used to conduct this analysis is known as COSMOS, created by East Tennessee University's Computer Science Department. The output of this application, the FPA, COCOMO, and Rayleigh Information, is shown in APPENDIX.

The Rayleigh Information outputted by COSMOS shows how much time needs to be committed to the main building phase.

5.1.5 Staffing

Currently, five staff are available for this project; one Project Manager, one Systems Analyst/Designer, one Quality Engineer, and two programmers. Not all staff will be required to work on the project at once. In the initial phase, the Project Manager and System Analyst are expected to do most work.

As the project progresses more staffing shall be required. Programmers shall be employed during the intermediate phases, as well as a quality engineer. During this phase the project manager shall continue to manage and control the project, and the Analyst shall provide support, possibly in supporting areas such as process improvement. The Quality Engineer is likely to oversee the programmers, as well any processes that are subject to quality reviews.

As the final phase is entered, the programmers shall be laid off, and also other staff, once their roles are no longer required. The project manager shall then hand over the completed product to the client.

An approximation of the staff required through each phase is shown below. Detailed staffing schedules can be found in appendix.

Table 5.1: Staff number and details by phase

Phase

Staff required

Details

Initial phase:

Maximum 2 staff

Project Manager & Analyst

Intermediate phase:

Minimum 5 staff

All staff

Final phase:

1 or 2 staff

Project Manager (Minimum)

5.1.5.1 Staff Sources

The staff for this project will almost certainly come solely from the IT department. We doubt that contract personnel will be required for this project, as the IT group have more staff, which we expect to be free. If no additional internal staff available when the project requires extra staff, then contract personnel shall be considered. As all staff are familiar are with the development environment, we also doubt special expertise will be required.

In the unexpected case that contract personnel are required, we shall approach an appropriate agency and seek the right person immediately. Little technical or managerial training will be required, as any contract staff must be experienced in the technical fields needed. Should the position be a managerial position, then managerial experience will be a prerequisite for such a job.

5.1.5.2 Staff Training

All staff are currently familiar with the development environment so we do not expect that any technical training will be necessary. We do not know whether managerial training will be of benefit to the staff in this project, as such, no training will be provided. However, managerial process reviews shall be used in this project. These may uncover managerial weaknesses. Should this be the case, action shall be taken during the project, if feasible, otherwise, it shall be provided upon conclusion of the project.

5.1.6 Required Skills

The client has specified a fairly basic system that is to operate in a Windows environment. Furthermore, the client stated that the system is a stand-alone system to run on one PC. Therefore, basic technical skills will be required. Our technical staff are certainly competent in such environments.

Project management skills will also be required for this project, as well as knowledge in quality, and systems analysis and design.

5.1.7 Other Resources Required

We do not expect any resources not already discussed in this document to be used. No additional hardware, facilities, contracts, or software is expected to acquired, both on the client's side and on the develop team's side.

5.2 Work Plan

This section explains about work activities, schedule, resources, and budget details for the project. Some parts of the sub-section will refer to appendix or other sections.

5.2.3 Work Activities

Waterfall model has been used to satisfy the requirement of BVC. Work activities involved in the work breakdown structure are:

v Requirements

v Analysis

v Design

v Coding

v Testing

v Project Management

For a full description of their relationships and details, refer to section 6(technical plan) and appendix WBS.

The acceptance criteria for the project lists the necessary task that are to be completed for the client to accept the product. A copy of the Acceptance Criteria is attached in section 6.

Risk management processes relevant to these activities, including risk tracking, is included in section section 5.4

The relationship between a task and its predecessors and successors is illustrated in appendix msProject.

5.2.2 Schedule Allocation

After establishing WBS, the tasks were entered into Microsoft Projectâ 97, and the estimated schedule was created. This was completed by assigning a time period to each task. The schedule has been provided in the appendix msProject.

5.2.3 Resource Allocation

Resource allocation assigns resources, as in staff and tools provided, to control activities within the WBS. These resources for each task are listed in section 6.

5.2.4 Budget Allocation

Budget Allocation place a key role in any project. It estimates cost of resources and tools needed to conclude project activities. The budget for this project was calculated using Microsoft Projectâ 97, using resource allocation, and expected pay-rates. A copy of the budget is provided in msProject.

5.3 Control Plan

This section describes how the project will be monitored and controlled using the following plans.

5.3.1 Requirements Control Plan

Any changes to the product requirements will be managed through the configuration management change control process, summarised in section 7.1.

A requirements tracability matrix will be provided in all documents referencing the requirements, this will provide a direct link back to each requirement of the system.

Impact analysis and change approval processes are described in Configuration Management, section 7.1.

5.3.2 Schedule Control

Schedule control for this project will require inputs to control, control techniques, and outputs such as updates and corrections.

The schedule will be monitored using the following inputs.

v Project schedule: See Appendix for the project schedule. This will provide the basis for measuring and reporting schedule performance.

v Performance reports: These reports provide information on schedule performance, such as whether deadline dates are being met or not. They shall also help the team stick to schedules, and alert us issues that may cause future problems.

v Change requests: Schedule changes may be required to extend or shorten the project. Change requests for this project must exist formally as a document, and may originate internally or externally.

A schedule control system shall use the above the inputs to manage changes to schedule. When changes to occur, additional planning must be done for compensation. A MS Project file will be updated to accommodate these changes.

5.3.3 Budget Control

Budget control will be undertaken by the project manager, and include affecting any changes to the cost schedule, monitoring the cost baseline and determining any changes to the schedule and managing those changes.

Changes to the budget schedule shall be influenced as much as possible by the project manager, to create the least effect on the plan.

To monitor the budget, the project manager will receive periodic reports on the status budget, detailing what is under, over and on budget. Based on this information, Based on this information, the project manager will be able to assess any difference from the planned budget and determine if the variance is significant enough to require further investigation. If further action is required, then the type and extent is left to the project manager's discretion, based on the particular case.

Earned Value Management (EVM) will be used to monitor the budget compared to the amount of work completed. Through these techniques, the project manager will be able to determine if there are any changes to the schedule.

If the schedule has changed, the project manager will need to reassess the schedule, taking into account these new developments. The project manager will also have to ensure that the changes to the budget will not affect the scope of the project by having to leave out some tasks due to budget constraints.

Cost reporting of each task will be determined based on its size and budget. Large and expensive tasks will be reporting more frequently than small and cheap tasks. The period between reports is chosen by the project manager on a case-by-case basis.

5.3.4 Quality Control Plan

The details of the Quality Control Plan are outlined in the Quality Assurance Plan, (section 7.4). The Quality Assurance Plan describes the measuring and controlling mechanisms used to assure the quality of the work processes and products. These mechanisms include audits, joint reviews, process assessments, and quality assurance of the processes.

5.3.5 Reporting Plan

This plan highlights the reporting mechanisms, formats and frequencies of the reporting structure of the project.

These relationships are displayed in table 5.2, below.

Table 5.2: Reporting and Communication plan

Communication

From

To

Time Period

Action plans

Audits

Minutes of meetings

Risk Assessment

Schedule checks

Progress of assigned tasks

All group members

Project Manager

Weekly

5.3.6 Measurement Plan

All project measures, where not predetermined by either Buena Vista College, or any other external requirements, will be agreed upon by the project team based on the project's main issues. These details will be formally recorded in the Measurements Recording Form (Appendix #).

The metrics used in the measurement plan will be collected at two processes in the development lifecycle, at the verification and validation processes, and at the end of the project. These measures will be collected mainly through interviews and reports at each of these times. The collected data will then be validated and stored by the project manager.

5.4 Risk Management Plan

The risk management plan is designed for the development team to recognize any risk that may have a clashing affect to the project's schedule, budget and quality. The risk management covers the identification of risk factors, the assessment of the possible severity and likelihood of the risks, definition of management strategies for avoiding and containing risk, and the means for ongoing monitoring of the risk factors.

5.4.1 Risk Factors Identified

Risk factors that were identified early in the project are listed below. During the life of the project the PM may find more risk factors that may affect the schedule and budget of the project. The PM will record each new risk factor in a Risk Identification Form (Appendix #).

The risks presently identified are:

v Conflict with team members

v Staff skills and competence

v Functional Rise

v Conflicts with client/Customer

v Low quality

v Low productivity

v Consistent to standards

v Business Risks (absence caused by illness of accident of involved stakeholder.)

v Loss of client.

v New/Old technology conflicts.

v Client Acceptance

v Availability and use of Resources.

5.4.2 Risk Assessment

Each risk factor identified was assessed on the likelihood and severity of it becoming an issue. Each assessment gave a value of 1 to 10, where 1 was low and 10 was high, indicating its importance. The assessment for each risk factor gave the reasons for the risk, impact of the risk, monitoring of the risk, and the resolution of the risk. With this detailed assessment of the risk factors a top ten risks identification and report was created. Also a risk matrix was created of each risk's likelihood and severity.

The project risks can be founding APPENDIX.

5.4.3 Risk Management Strategy

Impacts of the risks on the project will be the cost, schedule and quality of the product. The PM must understand that risks are part of the day-to-day operations of the project.

As part of the risk management strategy, the PM must conduct weekly reviews on the status of the current top-ten risks, and continually be aware of the development of any new risks. Any new risks identified must be formally recorded in a Risk Identification Form (Appendix #). Once identified, if in the top-ten, a risk has a contingency plan developed in case it becomes an issue, and is continually monitored. If a risk eventuates and becomes an issue, it will be recorded, its contingency plan will be started, and a group member will be assigned to handle the issue. These procedures are outlined in Issue Management, section 7.6. The PM must also be able to produce a report on the current status of the risks to any stakeholder if required.

5.4.4 Top Ten Risks Identification

The top-ten risks identification highlights each risk and its details. It identifies each risk's probability of occurring, 1 - 10(high), its severity and exposure (probability of occurrence * severity), the problem resolution technique, who is responsible for monitoring the risk, and the time period of the risk.

Table 5.3: Top Ten Risks

ID

Item

Prob

Loss

Exp

Resolution

Who

Date

1

Conflicts with team members

6

8

48

Group Meeting

PM

Cont

2

Resource Availability

4

9

36

Reschedule

PM

Cont

3

Low Productivity

4

8

32

Inspection

PM

Cont

4

Consistent standards

5

6

30

Inspection

PM

Cont

5

Low Quality

4

7

28

Inspection

PM

Cont

6

Client Acceptance

4

7

28

Client meeting

PM

Hand -Over

Phase

7

Conflict with Client

4

7

28

Client meeting

PM

Cont

8

Staff skill and competence

3

9

27

Training

PM

Cont

9

Functional Rise

2

9

18

Reschedule

PM

Cont

10

Absence of a stakeholder

2

9

18

Reschedule

PM

N/A

Cont = Continuous (on -going)

Below is example report kept by the PM to monitor risks in the project. The PM must have a current copy of the report. He must be able to show the report when requested by a stakeholder.

Table 5.4: Risk Report

Item

Rank

Now

Last

Time

Time

List

Resolution

Conflicts with team members

1

New

0

Have a group meeting. Resolve differences among the team members

Resource Availability

2

New

0

Get more resources

Low Productivity

3

New

0

Use Software process improvement methods.

Consistent standards

4

New

0

Check QA plan.

Low Quality

5

New

0

Design a Quality Model to achieve software quality standards

Client Acceptance

6

New

0

Rework project until the client is satisfied.

Conflict with Client

7

New

0

Talk with client and resolve issue

Staff skill and competence

8

New

0

Train Staff

Functional Rise

9

New

0

Redo Schedule for project.

Absence of stakeholder

10

New

0

Redo Schedule for project.

5.4.5 Risk Matrix

The risk matrix identifies the top-ten risks in terms of their likelihood of occurrence and severity. Items towards the top-left of the matrix are both probable and severe, and should be monitored carefully. Items towards the bottom-right are improbable and have a negligible impact on the project.

Table 5.5: Risk Matrix

Likelihood of Occurrence
Severity
Probable

(10 -8)

Occasional

(7 - 5)

Remote

(5 -3)

Improbable

(2-1)

Catastrophe

(10 -8)

· Conflict with team members

· Staff skills & competence

· Resource Availability

· Functional Rise

Critical

(7-5)

· Conflicts with client

· Low quality

· Low productivity

· Client Acceptance

Marginal

(5-3)

· Consistent to standards

Negligible

(2-1)

· Technology conflicts

· Unexpected absence

· Life cycle model

· Lost of client

· Aggressive client

5.5 Closeout Plan

Upon finalization of this project the following closeout tasks will be required. Project staff will be re-assigned to their old jobs, or allocated to new projects. All project documentation will need to be stored in the IT Group's projects archive. Finally an analysis of the project's performance and success shall be performed, so that lessons may be learned.

5.5.1 Staff Reassignment

The staff involved within this project will either be re-allocated to their previous roles, or assigned to a new project. It must be pointed out that the future cannot be read, and that the case study (Rout, 2002) does not indicate the organisational structure of the IT Group. Staff members may have been working on other projects or fulfilling other roles, of which they would return upon completion of this project. Considering these facts, we can only speculate that the Project Manager will almost certainly be assigned a new project, and other staff member's future is not known (Project staff will remain employed, but in what roles or projects, we cannot know based our information.).

5.5.2 Archiving Completed Project

All materials and documents created during this project will be stored in electronic format in the IT Group's project system. With the correct authorization, the materials and documents can be retrieved from this system at any time over the university network. Copies of the entire project will be burnt to CD-ROM and delivered to the client, and also to the IT department manager as a backup.

5.1.3 Reflection: Success, Performance & Lessons Learned

Measuring the group's performance will allow the group to determine whether they feel they were successful or not. Most important it will provide lessons for the group. It is important to transfer this knowledge somehow, so that the organisation may remember it.

5.5.3.1 Knowledge Transfer Plan

As described by Rout & Hodgen (2002), a project is on temporary endeavour to produce a unique product or service. Projects are always unique, however there are many similarities between them (Which is the reason for existence of the PMBOK and project management standards.). Knowledge gained relating to project management techniques used within this project may be applied to future projects in order to save time and or money, and to avoid known problems. The main goal of this knowledge transfer plan is to reduce the learning curves of future projects: this will provide scale advantages against competitors (eg. Another university.).

We believe the best way to facilitate the transfer of project management knowledge is in the explicit form (Recorded in a prescriptive form.), as opposed to the tacit form (A reference to the person/thing holding the knowledge). This could be in the form of a knowledge database for project management.

Knowledge could also be transferred outside the project management domain, specifically, in the IT Group's key knowledge domain, software. The IT Group's majority of projects will involve the creation of software systems. A software principle or technique learnt in project could almost certainly be transferred to another project. To facilitate this process, we suggest a similar idea to the above: the creation of a software engineering knowledge database.

Creating the above two systems is outside the scope of this project, however, with their existence, project members have an invaluable tool to use during projects. Project members would use it to record improvements upon project management or software engineering methods, and most importantly, they could use to see how previous projects dealt with whatever they are dealing with. Essentially, such systems teach, or remind project members how to do things, and also allow the knowledge within them to be refined.

5.1.4 Maintenance and Future Developments

Upon the completion of this project, it is expected that maintenance system will be required. There are two possible types of maintenance that will be required, ongoing, or one-off. Should the need for ongoing maintenance be identified, this project team shall be reformed, so long as the members are still employed by Buena Vista.

Because a straight through SDLC has been adopted for this project, it may be difficult to make changes, in the least, we expect it to be more expensive.

6.0 Technical Process Plans

This section justifies the process plan of the system, which focuses on the life cycle model, which is being used as a model to implement the system. Methodologies and tools will also be addressed to define technical part of the project plan. Product delivery and operation are mentioned in the last section.

6.1 Process Model

The waterfall model is chosen for the system implementation for the reason that it is plainly ideal to the problem situation, as the functional requirements are well known.

The model involves 5 stages of processes, which are requirements, design, testing, and installation. Each project member is assigned some tasks for the duration of the project to engage and apply the model's process (Refer to ...).

Here are some justifications of the using of waterfall model:

v Requirements derived from SUR are clear.

v There will not be major changes in the requirements.

v The size of the system is considerably small.

v System implementation will be done in an internal area.

v There is no time constraint.

Table 6.1: The following table shows exit and entry criteria of each phase in waterfall model.

Phase

Description

Entry

Exit

1

Requirements

· Project initiation

· System User of Requirements.

· Validation of SUR.

2

Analysis

· Specification of User Requirements.

· Specification of life cycle model.

· Documented analysis of SUR.

3

Design

· Analysis of SUR.

· Knowledge of system modelling

· Implementation of system's life cycle model.

4

Coding

· Documented functional requirements

· Knowledge of system encoding

· Potential system.

5

Testing

· System coding

· Final product.

6

Installation

· Installation guide

· System operational

7

Maintenance

· User manual

· Organised product

8

Managerial

· Continuous activity from project initiation

· Termination of project.

From the preceding table, key milestones are found after exit criteria are met. By the date of :

v 8 November 2002, SUR document is established.

v 26 November 2002, document of SUR analysis will be designed.

v 13 December 2002, a life cycle model is chosen and the system design is done.

v 3 April 2002, a software is developed.

v 25 April 2002, a potential software is ready to be delivered after testing is done.

6.2 Methods, Tools, & Techniques

The table below lists methods, tools, and techniques used.

Table 6.2: Methods, tolls and techniques used.

Project Development Plan

Given to develop project plan for the new system.

Quality Assurance

Refer to …

Risk management

Managing risks that may occur during the making of the system.

System Analysis and Design

Carry out the analysis and design development of the system.

System User Requirements

Enclose functional requirements as a guide all along the development plan.

Scheduling

Used as a guide in order that process plan can be done in accordance to

Waterfall model

This software life cycle will be used as a representation of system development.

Some standards and policies will be used in applying the methods and techniques above.

v ISO/IEC 12207 Information Technology Software Life Cycle Processes, Work Breakdown Structure.

v ISO 9001 Quality Systems Model for Quality Assurance in Design/Development, Production, Installation and Servicing.

v IEEE 830 Software Requirements Specifications.

6.2.2. Tools

The following tools are to be used during this project

Microsoft Word

Document the system process.

Microsoft Project

Record activities of work breakdown structure and also apply function point analysis in the file. It also simplifies the creation of project chart and diagrams.

Microsoft Excel

Document activities and tasks of WBS.

Microsoft Access

Testing of new system can be made in Microsoft access.

COSMOS

Estimate project time schedule.

SQL (database)

Use as a tool to build the system.

PMBOK

A guide to manage a project.

6.3 Infrastructure Plans

The new system will run in an equal version of operating system within Buena Vista College.

v Windows® 1998, Windows® NT, or Windows® 2000.

v Microsoft Access® 97.

Please see section 4.2 for the project team infrastructure.

6.4 Acceptance Plan

Following the completion of each phase, reviews will be carried out by the person involved in the process. A project member who isn't involved in the phase development, but has a good knowledge of it may be able to review the process to provide a different point of view which can give the person involved, who's responsible with the phase development, a fresh idea. The completion of a phase will be reviewed against acceptance criteria (SUR).

Before the acceptance of the final product, each project member has the following tasks:

v Project Manager: Apart from having the responsibilities on planning the project, Project Manager will be involved in review all phases being done by project members.

v System Analyst: Review system requirements and acceptance criteria provided in the System User Requirements.

v Quality Manager: Review the standards of the whole project.

v Programmer: Review System Analyst's documentation and the coding of software.

For user acceptance criteria, refer to Appendix...

6.5 Deployment Plan

The system operation will be installed in the existing operating system. According to SUR, the new system will operate on a single IBM compatible computer running Windows® 98/NT/00. The college system must have Microsoft Access to run the software.

An installation guide will be given to users lest they had trouble shooting with the system execution. Also a user manual will be essentially handful to guide users in operating the system.

Prior to the use of the system, it is strongly suggested for users to be given some training in advance. Although the system is not complex, users who are not familiar to computer system environment will see it as a good idea.

Project delivery will be conducted by Project Manager, while the training can be performed by Programmer.

7.0 Supporting Process Plans

The supporting plans aid in the development of the product and are used extensively throughout the lifecycle of this project.

7.1 Configuration Management Plan

All project deliverables shall adhere to the standard Buena Vista College Configuration Management Plan based on IEEE Std 828-1998, Standard for Software Configuration Management Plans. This plan details the processes to be completed for the submission/ change of any of the deliverables. This plan outlines both software and document configuration processes.

After the formal quality review outlined in section 7.4, of each work product, and the product is finalised, it will then be labeled version 1.0 and put under change control. Any change thereafter will need to go through the change control process.

Any problems identified will be brought to the attention of the IT group through a problem identification form (Appendix …).

Any requests for change must be formally made through the change request form (Appendix …) which allows for the change/s to be reviewed by both the quality manager and the project manager. If approved, the item/s to be changed are released to the person in charge of the changes, then returned once completed. The details of who made the changes and the corresponding dates is kept in the configuration log (Appendix …).

After each document is finalised or changed, the baseline is updated and recorded on the baseline control form (Appendix …). This ensures anyone wishing to read or change a work product is able to find the current version.

7.2 Product Testing and Reviews Plan

All processes, techniques and tools used in the verification and validation of the work products and activities are outlined in the Buena Vista College Verification and Validation Plan. Several methods of review will be used in the verification and validation of the work products. Each work product, its type of review and the participants of that review are listed in the table below.

Table 7.1: Work products' reviews

Work Product

Review

Participants

SURAC

CL, PM

SPMP

PM, QE

TP

PM, QE

SRS

PM, QE, SAD

SDD

PM, QE, SAD

TD

PG, PM, QE, SAD

Product

CL, PM, QE

CL - Client; PG - Programmers; PM - Project Manager; QE - Quality Engineer; SAD - Systems Analyst/ Designer

Identify which work products will receive what types of peer reviews (such as inspection, walkthroughs, and technical reviews) and what roles will participate in such reviews.

Testing will also be undertaken throughout the duration of the lifecycle. Based on the testing activity, various methods of will be undertaken and different people will be involved in the plan, review, development and implementation of the test. These details are displayed in the table below.

Table 7.2: Work products' testing details

Responsibilities

Testing Type

Plan

Plan Review

Development

Testing

Test Review

Unit

Testing

SAD, QE

PM, QE

PG

PG

QE, SAD

Module Testing

SAD, QE

PM, QE

PG

PG

QE, SAD

Integration Testing

SAD, QE, PM

PM, SAD, QE

QE, SAD

QE, SAD

QE, SAD, PM

Acceptance Testing

CL, PM, QE

CL, PM, QE

CL, PM

CL, PM

CL, PM

CL - Client; PG - Programmers; PM - Project Manager; QE - Quality Engineer; SAD - Systems Analyst/ Designer

7.3 Documentation and Work Product Plan

The processes, tools and techniques used to generate both deliverable and non-deliverable products is identified in the Buena Vista College Work Product Plan.

The development of this product will include the following products.

v Statement of User Requirements and Acceptance Criteria (SURAC) -formally identifies the requirements of the system, specified by the client. This document needs to be reviewed and accepted by the client.

v Software Project Management Plan (SPMP) - details the processes, tools and techniques that are to be used in the development of the project.

v Test Plan (TP) - specifies the methods, tools and techniques used in the testing processes of the product development.

v Software Requirements Specification (SRS) - clearly details the technical aspects of the requirements expressed in the SURAC. These details specify the functionality, quality and interface characteristics of each function.

v Software Detailed Design (SDD) - formally specifies a detailed design of the system to be developed. This document aids in the coding of the system.

v Test Documentation (TD) - records all testing data created through the testing phase of the lifecycle model, as well as all the test cases used.

v User Documentation (UD) - provides a manual to the users clearly explaining the new system.

v Post Project Review (PPR) - reviews the development of the project, critically analysing the methods, tools and techniques used, as well as comparing actually resources spent to predicted resources needed.

Each of these products shall adhere to a standard and be prepared and reviewed by, and distributed to various people. Table 7.3 identifies these details.

Table 7.3: Work products' personnel details

Work Product

Relevant Template or Standard

Prepared By

Reviewed By

Distributed To

Configuration Management Plan

BVC - CMP

PM

PM, QE

ITG

Documentation and Work Product Plan

BVC - WPP

PM

PM, QE

ITG

Issue Management

Section 7.6

PM

PM, QE

ITG

Process Improvement Plan

PM

PM

ITG

Product

N/A

ITG

ITG

CL

Product Testing and Reviews Plan

BVC - VVP

QE

PM

ITG

Project Reviews

PM, QE

PM, QE

ITG

Quality Assurance Plan

BVC - QMP

QE

QE, PM

ITG

SDD

IEEE Std 12207

SAD

PM, SAD, QE

PG

SPMP

IEEE Std 1058

PM, QE

PM, QE

ITG

SRS

IEEE Std 830-1984

SAD

PM, SAD, QE

SAD

Subcontract Management Plan

PM

PM, QE

ITG

SURAC

IEEE Std 1233

PM

CL

CL, ITG

TD

IEEE Std 1012

ITG

ITG

ITG

TP

IEEE Std 1012

SAD

PM, QE

ITG

UD

N/A

SAD, PG

PM, SAD, QE

CL

CL - Client; ITG - IT Group; PG - Programmers; PM - Project Manager; QE - Quality Engineer; SAD - Systems Analyst/ Designer

These work products will adhere to all procedures specified in the Work Product Plan.

7.4 Quality Assurance Plan

To maintain a high standard of quality, all work products shall abide by the Buena Vista College Quality Management Plan based on IEEE Std 1490-1998, IEEE Guide - Adoption of PMI Standard - A Guide to the Project Management Body of Knowledge and IEEE Std 730-1998, IEEE Standard for Quality Assurance Plans.

This plan outlines the process for quality reviews, which will be conducted on all work products. These products will undergo a quality review at least a week before the due date. These quality reviews shall ensure that the deliverable is following the standard for that product, and that it addresses all necessary components expected. The quality review shall also ensure that the project is meeting the client's needs, and not becoming sidetracked.

To assist in these reviews, the quality engineer shall produce customised checklists for each work product. If a work product does not pass all the criteria of the checklist, then those problems must be fixed before it is considered completed.

There shall also be joint reviews, audits, and process assessments, as described in the Buena Vista College Quality Management Plan, at each milestone of the project. These shall ensure the project is running smoothly and is on track to meet the client's requirements.

7.5 Project Reviews

At a minimum, reviews will be conducted at the end of phases. Two types of phases exist in this project, the waterfall model phases, and the project management phases. These two phases will exist in parallel during the project.

Each waterfall phase will have one or more deliverables required. A deliverable will be a physical object, such as a document, prototype, final system, design, etc. At the end of each phase, the deliverable/s and the project performance to date will be reviewed.

Currently we do not know how regularly waterfall reviews will be needed, we expect this occur to weekly, or fortnightly. Reviews on project management processes are harder to define. Considering that the project will take 4 months, it would be good to review the processes at least once per month. In the initial month, additional reviews will be conducted to prevent a drawn out start to the project. The schedule does not accommodate such reviews, however, there are times when staff are free, and could do such tasks.

The reason for review at the end of each phase is twofold. Firstly, the project needs evaluation as to whether we should enter the next phase. It might be that the project is no longer feasible, for whatever reason. Secondly, project performance should be reviewed mainly to keep stakeholders informed on how resources are being used to meet project objectives. Performance reporting can also be a useful self-check tool.

The performance review process includes is described in sections 7.5.1 - 7.5.3. Techniques that shall be employed include earned value analysis, variance analysis, and trend analysis.

7.5.1 Status Reporting

Status reports shall be conducted weekly/fortnightly and also at the end of each phase. The project manager will create these reports, as s/he has the clearest view of the overall picture. The status report will show how the project stands at a specific point in time. It will address things such as the triple constraint of scope, time, and cost, and whether these are being controlled well enough. Questions such as “How much has been spent? How much time has been required?” and “Is the work being completed as planned?”. These reports shall be tailored to the stakeholders needs, and size of the project.

Earned Value Management, as described in Schwalbe (2002, p175), will be used as it integrates scope, time, and cost data. This will be compared against this project's baseline, once it is completed. Another technique that shall be used is variance analysis, which will show actual project results against predicted project results. This will help keep the project under control.

7.5.2 Progress Reporting

Instead of being conducted at the end of phase, progress reports will be conducted weekly, or fortnightly. This time interval for these reports will be known once the project has begun. Team members will be required to submit their reports at the end of each period. The project manager then will create a consolidated progress report.

7.5.3 Project Forecasting

Project forecasting, at minimum, will take place at the end of each phase. Past information on how the project has performed and trends shall be used to predict future project status. Earned Value Analysis shall be used here also. Questions such as “how much more money is needed to complete the task” shall be asked. Trend and variance analysis will be used here. Trends can be used to predict the future state of the project, based on the past states. Variance analysis will provide an indication, but will not be as useful as trend analysis in forecasting. The project manager will be responsible for this.

7.5.4 Status Review Meetings

Status meetings shall be held periodically to collate and share project information. Currently, three types of status meetings have been decided upon. The project team itself is to meet regularly, at the same frequency required for the progress reviews. In fact, the progress review could be formulated during this meeting. All project members will be expected to participate.

The second review meeting is to be between upper management, Tom Walters, and the project team. It shall be compulsory for the project manager to attend these meetings; other project staff may be at such meeting, should there be a need. This meeting is expected to occur less frequently than the project meetings, but how regularly, we do not know. We expect that upper management will be responsible for scheduling these meetings. During these meetings the project manager shall present the status, progress, and forecast reports to Tom Walters. The reports may require modification from Mr Walters before being presented to the client. Feedback from Mr Walters shall be given to the project manager.

The third meeting type is between the customer, College Administration, and the project team. These meetings may involve the presence of Tom Walters (Upper Management). Progress, status, and forecast reports shall be presented to the customer during these meetings, as well as any deliverables such as prototypes, user requirement documentation, etc. These meetings will be important to ensure that client is getting what they have specified. An iterative approach shall be undertaken, which will allow much confirmation of the client's needs. Any problems with the project shall be presented, and resolved.

7.6 Issue Management Plan

Issue management is necessary to the completion of a successful project by providing a way to handle all risks, identified or otherwise, when they become issues.

When any risk becomes an issue, an Issue Report Form (APPENDIX #) must be completed by the person/s who first noticed the issue. This form is then to be sighted and signed by the project manager, acknowledging the issue. The project manager is then to assign the responsibility of monitoring and implementing an issue minimization strategy to a member of the group. If no existing issue minimization strategy exists, a new strategy will be created and executed. The monitoring and controlling of the issue will be recorded in the Issue Monitoring Form (APPENDIX #), recording the status and impact of the issue, as well as the minimization strategy.

The Issue Monitoring Form is to be completed by the person responsible for monitoring and controlling the risk, on a weekly basis. This is to be done until the issue is handled and no longer relevant to the project.

7.7 Subcontract Management Plan

Two facts indicate that subcontracting will be an unlikely need in this project. Firstly, all staff are familiar the development environment required for this project. Secondly, the project is not a large project. Nevertheless, should subcontracting be required, a plan based upon the guidelines within the PMBOK shall be used. A brief description of processes of this plan is discussed below. It is worthy to mention that the following processes will overlap, both with each other, and other project management areas (communications, risk, etc.). The complete description of the following processes can be found in section 12 of the PMBOK.

7.7.1 Procurement Planning

During the progression of this project, situations may arise where the project team may needs goods or services from external sources. The first step that shall be taken is to carefully consider the advantages and disadvantages of outsourcing. After this we shall determine how to procure, what to procure, how much to procure, and when to procure. During this processes we may need to seek expert knowledge from bodies such as consultants. Two key outputs from the step shall be a procurement management plan, which describes how the following processes will be managed. The second output we shall make is a statement of work, which describes the goods or services that must be provided by the vendor.

7.7.2 Solicitation Planning

This processes creates the documents required to support the solicitation execution. These are defined in section 12.2 of the PMBOK.

7.7.3 Solicitation Execution

The process will involve obtaining and advertising quotes, bids, offers, etc. This is further defined in section 12.3 the PMBOK.

7.7.4 Source Selection

After receiving all offers, a vendor shall be selected. The decision on which vendor to choose will rest upon a complex set of criteria, including price, expertise offered (quality), the organization culture of the vendor (which may clash with Buena Vista), vendor stability, etc. Frameworks for selecting vendors can be found in many IS textbooks, which is what shall be done. A key output in this process is the contract with the vendor, which is legally binding.

7.7.5 Contract Administration

Once a vendor begins working on the project, things such as performance reporting, change control, payments, legal issues, etc will be dealt with. See section 12.5 of the PMBOK. In this processes, we shall ensure the vendor employs a quality assurance plan, a configuration management plan, verification and validation plan, review plan, problem resolution plans, and audit plans: we shall monitor the vendor's use of these plans.

7.7.5 Contract Closeout

Signing off with the vendor will include verification of what they provided, and formal administrative closure. This is further defined in section 12.6 of the PMBOK.

7.8 Process Improvement Plan

Competitive pressures continuously force organizations to improve upon their processes. Unfortunately, we feel that competitive forces at Buena Vista are not strong because universities don't compete as fiercely as private institutions. We expect that this weak competitive environment may cause the IT department to be lazier than its private equivalents, and lack the drive to improve itself. This may result in less efficient and or less effective development processes.

To counteract this threat, a process improvement plan has been developed, which will be implemented fairly aggressively. The plan must be implemented aggressively because if it is implemented casually, the easygoing culture of the IT department may render the purpose of process improvement effective.

The improvement plan will be based upon two management paradigms, total quality management, and knowledge management. Total quality management seeks continually remove the cause of problems from the bottom-up (In organizational terms.). Knowledge management, fundamentally, is concerned with sharing best practices, increasing efficiency, and supporting innovation within an organization.

7.8.1 Process Improvement Plan

At the start of the project, a seminar on process improvement and its importance to the IT Department shall be conducted. It is important that all project staff have the importance of process improvement drilled into them early in the project.

As the project progresses and improvements or problems are found, the staff member who made the discovery will complete a “Suggested improvement or problematic process” form, which is delivered to the Project Manager. The project manager then enters the improvement in to the knowledge database system mention in section 5.5.3.1.

The initiatives above will not be useful unless an innovative culture is fostered within the IT Department. Cultural change is a difficult goal to achieve. All project staff will need to be periodically reminded of process improvement. To further assist this mindset change, creativity needs to be fostered. This could be achieved in many ways, from brainstorming sessions, to a change in layout of office furnishings.

The process improvement plan is more of an ongoing process than a plan. It is detached from the project itself, and exists within the IT Department itself. It shall be adopted throughout all stages of the project, initiating, panning, executing, closing, and control; and in future projects also.

In terms of knowledge management, the project manager shall motivate staff to learn more about their fields, and the fields of other project staff. Methods that may be employed are the system mentioned in 5.5.3.1, as well sy