Using project management to drive a quality system

Introduction

This paper describes the evolution of a certified quality system within Compaq Multivendor Services Engineering (MSE) software development function. It outlines how a participative approach was used to develop an ISO9001 certified quality system. It details how that system was significantly enriched through selective use of best practice project management methods and tools. It highlights the features and benefits of the present system.

Problem History

The Multivendor Services Engineering Availability and Optimization (MSE A&O) group in Compaq develops proactive system management tools that help to guarantee continuous performance for critical customers. This group consists of approximately 30 software development engineers. There are three main streams of work in the group with project releases every three to six months within each stream. The majority of the developers are located in Ireland but some are in the United States.

Exhibit 1

Exhibit 1

In 1995, the group had grown very rapidly from a five- to six-person operation with one development project, to a group of 25–30 software development engineers working on a number of concurrent projects. The rapid growth had left the group working in an ad hoc manner, with no defined processes in place. This resulted in schedule delays, test problems, difficulty in working with other disciplines such as production and documentation groups, system administration problems as the network became overloaded, and so forth.

Quality Management System (QMS)

To remedy some of the problems outlined above, the engineering manager in the group decided to implement some process improvement. The intent was to get some repeatability and predictability in place. This it was felt would increase the satisfac tion of the investors, and increase the job satisfaction of the employees by making it easier to work in a rapidly changing environment. Rather than just implementing process improvement in a random way it was decided to aim for ISO9001. This gave a benchmark to aim for, a structured process to follow while getting there, and an objective measure at the end. The “Framework for Success,” 1994, and the TickIT Guide, 1987, were used as the guides for the implementation. In 1996, the group was certified by SGS Yarsley to ISO9001. Exhibit 1 gives an overview of the quality management system, all of which including records and project documentation was available on the group's internal website.

Exhibit 2

Exhibit 2

All of the developers were involved in defining the quality system. This meant that there was an extensive understanding and acceptance of the process. It also cut down on training. Defined roles and procedures made it easier to work on projects. The process was more repeatable. Yet, despite the accredited system and no corrective actions from our external auditors, it became evident that project management practices within the group could be significantly improved.

Problems with scheduling, project slippage, inconsistency in project management techniques across projects, and poor knowledge management in terms of feedback from one project to the next, and among different project managers remained. The QMS didn't identify project management problems and their root cause. Also at this time the group underwent a period of high staff turnover and the QMS did not allow for this or for the transfer of knowledge of the QMS among new developers and project managers.

Proposed Solution: Project Management

In 1997, the group undertook to address the project management issues that still remained. It was decided to take all of the project managers, product managers, engineering manager and the operations/quality manager and train them in project management. This was done in conjunction with a local training company called ETP who base their methodology on “The Silver Bullet,” (O'Connell 1994). There was also extensive use made of Booch's “Managing OO projects.”

The advantage of everyone participating in the same workshop gave consistency in the approach to project management, and completing a workshop rather than a course allowed the current processes to be worked into the new methodology. Despite best efforts to avoid it, an extra set of procedures was introduced (see Exhibit 2). These were procedures that needed to be followed along with the existing quality procedures.

The net result was two sets of procedures, some of which overlapped. Although the project management of the work improved, the disadvantage of operating with two overlapping processes was that:

• It was not clearly visible how one process affected another, therefore the system was difficult to update, maintain, and improve.

• It was difficult for developers to clearly understand the parts of the system that concerned them specifically.

• It was difficult for new employees to become familiar with the system, especially new project managers.

• The system was difficult to explain to subcontractors and customers.

• It was difficult to map a subcontractor's quality process to the MSE A&O group's system.

• The procedures were difficult to represent on the web.

• Two sets of processes meant more overhead.

Exhibit 3

Exhibit 3

Exhibit 4

Exhibit 4

Feedback From Implementation

As the management processes were being used, there were repeated requests from the developers and the project managers to have one defined process and to do some type of visual representation of this process in order that they could easily understand the following:

• How the process worked

• What roles were required within each project

• What part of the process was each role in the project required to perform

• What documentation was required for each project

• Who was responsible for writing each document and who approves it

• What records were kept throughout a project

• What constituted the official start of a project

• What were the milestones and decision points throughout the project

• How were late requirements dealt with

• What waivers could be written

• When was a project finished.

Therefore in 1998, work started on merging the quality system and the project management process into one overall process.

Combining the QMS and the PM Methodology

The merging of the processes took about a year to complete. The quality/operations managers for the group with the assistance of a documentation person interviewed the project team members to understand in detail the way they worked. Once this was completed, the differences in approach used by different teams, despite the common training in project management, could be seen. For example, one of the project managers listed all of the documents required during the project in their development plan. This idea was expanded and adopted as the best practice. Another project manager used a project status report to communicate his project status on a weekly basis. Again, this was agreed to be the best practice and adopted by everyone and included in the process.

It took time and patience to define each step but once consensus was reached, the first draft of the quality process overview in poster form was put in place. This was distributed to the project managers for review. The type of feedback resulting from the first review included things like:

• The pre-work section of the process needed more detail and clarification.

• The positioning of decision points, such as at what point the requirements document should be signed off, needed more definition.

• It was necessary to state from what point a change management procedure should be used.

The poster was edited and the next draft of the process was piloted on two of the projects running at that time.

The pilot was over a period of three months. After the pilot the feedback was again incorporated into the poster, changes were made and a third draft was issued. This draft was given wider distribution. Some of the developers used it to highlight the work they needed to do within the project. Tick boxes on the poster allowed them to do this. Feedback from this group was very positive. The advantage of this poster became evident as people within the projects used it. Feedback involved creating space on the poster for the name of the project team members and their roles. More detail was requested on the individual process boxes so that all of the information for each step was included in one place. A final A2 version of the poster was produced in December 1998.

The final version of the Quality Process Overview consists of an A2 size poster. It will be presented at the seminar. This can be folded in half. On the front A3 fold there is a summary of the process. This opens to an A2 size detailed poster (see Exhibit 3).

Explanation of the Process

The result is a quality system driven by a project management methodology. There is now one key process called a Quality Process Overview.This process is clearly defined. It includes the steps required by the ISO9001 standard for software development as well as the steps required in the project management approach used by the group. All of the information defined in the Quality Process Overview is represented on one flowchart, drawn on a poster. See Exhibit 3.

The content of the Quality Process Overview poster, with hyperlinks to related documents was put on the groups intranet website. The web-based nature of the system has significant value, particularly in a distributed development. It allows easy communication between developers in different countries. It also allows managers in different countries to easily drill down to detailed information on all projects.

However the most useful result of mapping both systems is the production of one key process in poster format. This poster gives a clear picture in flow chart form of all the steps required to manage a software development project. It describes the records needed for each step in the process. It describes who is responsible for preparing each record and points to the templates and related documents that should be considered during each step. It indicates which documents are continually updated during the project lifecycle. It has “for my attention” and “tick” boxes so that team members can highlight the work they need to do during the project and tick it off when completed. It has space for the project name and the name of the team member associated with each role within the project. See Exhibit 4.

Everyone in the SE A&O group uses the poster. For example: the project managers and members of the project team use it as a checklist of work they have to complete. External and internal auditors use it for audit purposes. It is used in induction to train new members to the group. The quality focus person in the group uses it when updating and continuously improving the quality system. It is used when working with subcontractors in order to map their quality process to that of the A&O group.

Results

The information relating to the Revision and Configuration Management (RCM) project, shown in Exhibit 5, was taken from the group's internal website. It is interesting to note that the level of documentation has been improving since the first release of the project in December 1997. The December 2000 release had its full quota of required documents.

The original expected release date was taken from the start up mails for each release. The start up template on which the start up mail is based contains this information. The earlier releases were less predictable than the latest releases indicating an improvement in the process we are using.

The most interesting information was obtained from the post parti.Some of the problems encountered throughout the project were documented in the December 1998 post partum minutes. These are given below. They are quotes from the team members. They include:

Exhibit 5

Exhibit 5

“We encountered problems with requirements”

“The schedule was playing catch-up to what was really happening”

“New tasks were added to the schedule every week”

“We seem to have two project leaders”

“Testing time is inadequate.”

The majority of the issues at that time were project management related. This is in great contrast to the last three post parti. Each of these stated: “The overall consensus was that this was the smoothest release of RCM to date.” There are little or no project management related issues in these latter post parti. The issues are those of delays caused by dependency on other software products that RCM uses. These products are produced in other development groups and are frequently delayed thus impacting the RCM project.

Conclusion

In conclusion, the process that has emerged means that project management techniques are now being used to successfully manage and enhance the work we do. This Compaq group has evolved a quality system driven by a project management methodology. There is now one key process called a Quality Process Overview. All of the information defined in the Quality Process Overview is represented on one flowchart. It includes the steps required by the ISO9001 standard as well as those specified in our project management process. The use of a poster as a visual means of representation has been very successful.

The use of the internal Website as a means of representing all of the documentation has proved invaluable for distributed development and remote management. It allows everyone to easily get a hierarchical drill-down on project related information. The use of organizational status reports gives constant feedback on the status of the work being done. The use of post parti at the end of each project emphasizes the 360-degree nature of the present system as all of the issues raised are assigned to people in the group to be fixed so that they will not re-occur in other projects.

Soliciting feedback from so many members of the project team was slow but it made us successful in getting cooperation for the project. We got valuable input from the project team members and with such a wide involvement we got everyone educated in the process. The common project management methodology that resulted makes benchmarking among the project managers very easy. This facilitates and encourages continuous improvement.

National center for Software Engineering. 1992. Framework for Success.

Department for Trade and Industry and The British Computer Society. 1992. Guide to Software Quality Management Systems Construction and Management using EN29001Issue2.0.

Fergus O'Connell. 1996. How to run Successful Projects 11 The Silver Bullet. Prentice Hall.

Grady Booch. 1995. Object Solutions, Managing the Object Orientated Project. Addison-Wesley Publishing Company, Inc.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.