§ Make certain that all people involved in the project, both on the publishing side and on the development side, understand the process and methods used to baseline requirements and to affect change to the baselined requirements.
The requirements list baseline is established following the customer review meeting and should be given a unique identifier at that time. It must be distributed to all participants as the only requirements list to be used as design work commences. The identifier should have provisions for indicating the version or edition or release. If an approved change is made to the requirements list, the identifier must be updated and the revised requirements list distributed to all participants.
Controlling the Change of Requirements
For example, say that as the design of the Graphical User Interface (GUI) gets underway, the designer realizes that there is no requirement for the GUI to provide transportation to the query subsystem, a function the designer thinks will be essential to the user. Using the requirements control process, the designer does not add the function (which would creep the requirements). Instead, the designer prepares an incident/problem report that notes the fact that there is not a requirement for the GUI to query transportation and notifies the keeper of the requirements list, who may be the quality assurance manager, the engineering manager, the project manager, or someone in configuration management.
The information provided by the designer is assessed for project impact and disposed of in one of the following ways:
1. The change is approved as a necessary component of the current system development effort. In this case, the schedule and budget will be assessed for impact. If the schedule must be maintained, a management decision will need to be made regarding adding a resource to do the programming, increasing hours for one or more existing programmers, or contracting out that piece of work. If the budget is already at bare bones and the schedule must be met, then the increased hours most likely will be included in the nonpaid exempt employee overtime category, but management must realize that they are increasing the pro ject risk.
2. The change is approved as a modification to the current system to be implemented in the first software release subsequent to the initial delivery of the system. A work-around may or may not need to be developed for the initial implementation. The point is to make sure that there is agreement with the customer as to who is going to develop the work-around should it be needed. The other critical point to be made here is that the change control records and the process for using them must be implemented so that items such as this do not fall through the cracks as development for the next release gets underway.
3. The change is approved as a potential future enhancement to the current system without a specific schedule for implementation. Similar to the change approved as a modification, the change control records must be precise to ensure that the decision specific to this change is not lost. Because this
change will not become part of the next release, it will go back to wish list status and be carried through the entire requirements process. The reason for this is to make certain that the development of this enhancement is scheduled for work and delivery within the context of all other existing work.
4. The change is rejected. This closes out the incident report. No work is scheduled now or for the future. There may be many reasons for this type of a response. Whatever the reason, the rejection action and the reason for rejection should be recorded within the change control process. A record of all closed changes is maintained to ensure accurate project history and to provide the rationale on why the change was rejected.
Whenever any software is released to the customer, the release should follow a defined release management process that includes the specific identification of all of the components that are included in the software release as well as the components that are assumed to be present (i.e., system software). This identification also should include the specific incident/problem reports that were corrected by the release and any work-arounds that were developed for the known problems that exist in the software.
Section II: Critical Factors for Project Quality
Chapter List
Chapter 10: Using Project Management to Become ISO 9000 Certified Chapter 11: SEI CMM or ISO 9000: Which is Right for Your Organization Chapter 12: An Almost Perfect Software Project: Using SEI Core Measurements
Chapter 13: Does Your Project Risk Management System Do the Job?
Chapter 14: Evolution of a High-Quality Development Process in an Existing Software Project
Chapter 15: Incorporating Six Sigma Concepts into Systems Analysis Chapter 16: Solving the Software Quality Management Problem
Chapter 10: Using Project Management to
Become ISO 9000 Certified
Ralph L. Kliem
OVERVIEW
The information systems (IS) community has always had a concern about quality.
The pressure for delivering systems of high quality has never been greater. Time -to-market of products is accelerating; customers want the product faster and better.
Offshore programming and outsourcing agreements threaten to produce systems not only cheaper but better. Software solutions can arise that can make the existing state-of-the-art obsolete virtually overnight.
The IS community is also going through rigorous self-analysis. The Software Engineering Institute’
s (SEI) Capability Maturity Model (CMM) is raising questions
about the way IS shops build and deliver quality system.
Self-analysis is being forced from somewhere distant and is growing in popularity.
The pressure is for IS organizations to seriously consider becoming ISO 9000
certified. As companies, in general, and computing, in particular, become more global in nature, the IS community will increasingly face pressure to comply with the ISO 9000 series.
Project management plays an important role for becoming ISO 9000 certified.
According to a study of ISO 9000 certified firms in Colorado, project management would have made their certification easier and more efficient. The Colorado firms cited teamwork and project management as the two most important lessons learned; the former is really project management, too. The firms also emphasized the need for training, greater appreciation of time required, and better project management.
Arguably, the first and second items are project management-related, too.[1]
[1 ] Quality Progress, October 1995, pp. 71–72.
BASICS OF ISO 9000
The ISO 9000 series, developed by the International Organization for Standardization (ISO), are standards that provide a framework for developing quality systems. Currently, five standards exist:
Standard
Subject
9000
Guidelines on using standards
9001
Design, manufacture, install, and service of systems
9002
Production and installation
Standard
Subject
9003
Final inspection and testing
9004
Quality management
In 1991, the ISO developed ISO 9000-3 for software development. It identifies quality controls (QC) for developing, supplying, and maintaining software; focuses on conforming to requirements throughout the life cycle of software; calls for defining, documenting, and communicating policies and objectives on quality; and requires reviews, inspections, defined responsibilities, version control, and other QC-related disciplines being in place. These QC disciplines and others should be documented in a quality plan.
Putting such QC disciplines in place is, however, not enough. The standards require the companies to be certified, too, via a registrar who audits for compliance with the standards. If it passes the review, the firm becomes ISO 9000 certified, subject to periodic recertifications.
The ISO 9000 series is gaining recognition in the IS community. Firms like Sybase and Hewlett–Packard have already embraced ISO certification.
PROJECT MANAGEMENT AND ISO 9000
A business endeavor must meet three criteria to be a project. It must have a fixed duration, require performing a sequence of tasks, and produce something once the tasks are complete.
Becoming ISO certified satisfies all three criterions. Becoming certified typically takes up to one-and-a-half years: a series of tasks must occur (e.g., conducting pre-audits) and “deliverables” (e.g., quality control policy) and a final product (e.g., ISO 9000
certification) are produced.
Being classified a project is an academic exercise. What is really important is that the ISO project c ompletes successfully. Project management is the way to obtain that result.
Project management is the systematic application of concepts, techniques, and tools to plan, organize, control, and lead a project. Plan, organize, control, and lead are the four basic functions of project management. Planning is deciding in advance what the project will achieve, determining the steps to execute, and identifying when to start and stop. Organizing is orchestrating resources cost-effectively to execute the project plan. Controlling is assessing how well the project manager uses the plans and organization to meet project goals and objectives. Leading is influencing people to achieve the goals and objectives of the project.
PLANNING
Planning consists of seven basic elements:
1. Statement of work (SOW)
2. Work breakdown structure (WBS)
3. Estimating
4. Scheduling
5. Resource allocation
6. Budgeting
7. Risk control
Statement of Work
The SOW is a contract between the person performing the tasks and the internal or external customer of the product. From an ISO 9000 perspective, the customer is frequently an internal one (such as the manager of an IS department) and the people performing the tasks (e.g., ISO 9000 implementation team members).