Project Management Processes
A systematic project management methodology was used derived from the Project Management Institute's
Guide to the Project management Body of Knowledge ("PMBOK")[1].
These included attention to:
- Integration management
- Scope management
- Time & cost management
- Quality management
- Contract management
- Communications management
- Risk management
These will briefly be discussed as follows.
Integration Management
A project plan was developed, communicated to key project stakeholders and approved.
Scope Management
The SP approached the Client before the project was even thought of, and recommended that an upgrade be done to the software. The Client asked the SP to compile a business case and feasibility study document. This took six weeks to produce and it looked at issues with the current system, how they would be addressed by the "new" system and additional functionality that would be provided.
The SP showed the document to the Client and was invited to present the concept at the Client's annual planning conference. The idea was enthusiastically received. A concept document was circulated and approved by the Client. The project was then given the go-ahead in principle. The SP then visited a number of key user sites to discuss the impact of the upgrade on their respective parts of the business. Comments were noted and incorporated into the project definition document.
The SP then called a session for all the key user stakeholders at which all the deliverables were explained. The project definition document was subsequently reviewed by a group of twelve users during a two-day workshop and the end of which the document was signed off.
Time Management
A simple high-level project schedule was developed as shown in Figure 1. Appropriate resources were allocated to tasks.
Figure 1: High-level schedule
Cost Management
There were different categories of billing rates and this was used to calculate the overall cost of the project.
Contract Management
It was agreed that this would be a fixed-cost project. The Client had signed a five-year license agreement with the SP one month before and there was no "exit clause". The signing of this agreement indicated the Client's commitment to the SP and the software. The upgrade project ensured that the Client had the latest version of the software. Every week each project team member completed a timesheet and this data was captured into the project schedule using MS Project. In this way the project manager was able to track the progress of each task and produce an overall progress report.
Quality Management
The deliverables were broken down into smaller "packages". A design specification was produced for each one and work did not continue until the users signed off on it. Once this was done, the SP produced a technical specification for internal use. These were approved by at least two independent reviewers. After the programmer had written and tested a program, members of a testing team tested it to ensure that the code was sound. The system was finally put through four complete system cycle tests.
Communications Management
A weekly project management committee meeting was held from the start of the development
phase of the project. Permanent attendees from the user side included the User Project
Manager and the User Technical Consultant (see Figure
2 below). The SP Project Manager chaired the meeting and invited members
of the project team and other personnel where appropriate. The purpose of the meetings
was to cover the status of the project to ensure that everyone knew what had been
done and what was being planned. The meetings gave the opportunity to raise issues
such as unavailability of a resource or dissatisfaction with work that had been done.
Risk Management
"Risks" was an item on the agenda of all the weekly project meetings. A risk log was continually updated, where the risks were identified in terms of something affecting the project's "Go Live" as per the project plan. A matrix was used to rate risks in terms of probability of occurrence and impact on the project. Someone was assigned responsibility for each risk. Its potential affect on the project's success was discussed and a description of the status was updated weekly. Risks that became "issues" were put onto an issues log.
1. A Guide to the Project Management Body of Knowledge (PMBOK®
Guide) 2000 Edition, Project Management Institute, PA, 2000
|
Part
1: The Project
