A paper originally presented to the PMSA Global Knowledge Conference,
Monday May 10, 2004,
Midrand, South Africa.
Published here January 2005.

Introduction | The Project | Project Management Processes | Progress
Things Start to Go Wrong | Workshop Outcome | Next Steps | What Went Wrong?
The Purchase Process and Buyer's Remorse | Suggestions to Avoid Similar Situations
Commentary | Issues for Discussion

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
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.

Part 1: The Project  Part 1: The Project

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition, Project Management Institute, PA, 2000
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page