Ensure business owners understand they must be active
management
rather than passive participants to guarantee project success support
Overly
Review schedules for preset deadlines (without regard to
optimistic schedules reality) and suggest more appropriate timelines be applied for key tasks
Inappropriate
Assign proper resources for the task based on the job
project team/team responsibilities and ensure employee satisfaction through dynamic
improved human resource practices
Selecting the
Complete quantitative decision analysis for all major
wrong
vendor or technology decisions
vendor/technology
Mistake 4 — Not Identifying and Assessing Risks in a Standardized Fashion
As presented previously, there are four steps to implementing a risk management system: identify, assess, respond, and document.
Tracking System One popular method of tracking risks is to begin by having project team members submit their issues in a common centralized database. Although this may sound difficult to establish, one such database could be a simple Excel spreadsheet with various columns for the required information. Exhibit 2 contains sample fields that could be maintained in the database.
Exhibit 2. Critical Risk Information
Risk
Information
Management
Step
Identify
Risk description
Identify
Identified by
Identify
Identified when
Assess
Quantify Impact (funds allocated, project work hours, or project duration)
Assess
Quantify likelihood (e.g., likely = 85 percent, Probable = 60 percent, and Possible = 25 percent)
Assess
Calculate loss (impact * likelihood)
Assess
Quantify urgency (related to the need for timely action)
Respond
Proposed solution (could be prevention, mitigation, or acceptance strategy)
Respond
Person(s) assigned to complete solution
Respond
Date of expected resolution
Respond
Work hours expected to resolve risk
Respond
Approver that ensures the resolution properly met the risk
Respond
Contingency plan (plan to enact if proposed solution does not materialize)
Respond
Trigger event (event for which it is determined that contingency plan needs to be enacted)
Monitoring Once the risks have been identified, they should be monitored weekly (possibly even daily in critical times). The desired result of such analysis is to attempt to ensure 100 percent visibility into the project. One benchmark to follow is to ensure that the top three risks are analyzed on a weekly basis (even better if the top ten risks are analyzed). To assist the monitoring process, it is helpful to
segregate risks between those that relate to the project (which should mainly be reviewed by the project team with some oversight by business owners) and those to which only the business owners can respond.
REVIEW ASSESSMENT AND CONCLUSION
Given the top four mistakes that are made in maintaining a risk management system, the following questions can be arrived at, asked of the project team, and documented as to the responses to them. In addition to asking the questions, a walk-through should be performed to observe key risk management components.
The major questions are as follows:
§ Have the benefits of risk management been properly communicated to business owners?
§ Has adequate time been provided for a risk assessment phase of the project?
§ Has a specific individual been assigned to ensure that project risk management is completed?
§ Has project scope been finalized and documented through either a prototype or a JAD session?
§ Have project schedules been reviewed by an independent party for symptoms of schedule optimism (e.g., preset deadlines)?
§ Based on the tasks at hand in the project, have the appropriate personnel been assigned, both at the project manager level and at the project task level?
§ Have employee satisfaction techniques been employed, such as career counseling and acknowledgement programs?
§ Have major vendor and technology decisions been based on a quantitative, documented decision analysis?
§ Does a risk management tracking system exist?
§ If yes, does the system contain all of the critical risk tracking elements (see the table of key elements in Exhibit 2)?
§ Are risks segregated into those that can be resolved by the project team and those by the business owners?
§ How often are risks and their proposed solutions monitored?
Chapter 14: Evolution of a High-Quality
Development Process in an Existing
Software Project
Susan Phillips Dawson
OVERVIEW
The adoption of a high-quality software development process is a daunting task, even for people trained in the methods with a funded and supported project on which to apply the principles. It is especially difficult in an environment where the culture does not support disciplined software development, where most people have not been educated in the methods, and the project has been perpetuated for many years in an ad hoc environment. Even with the advent of total quality management, few business managers understand the application of quality principles to software.
Applying continuous improvement in software development is extremely difficult, but it is also paramount to the ongoing success of a heterogeneous, mission-critical project. This chapter describes the evolution of a disciplined process in a large, ongoing, mission-critical development project at Motorola Austin.
QUALITY INITIATIVE
The Paperless Integrated Manufacturing System (PIMS) is a project that arose from real and urgent needs in Motorola final manufacturing. Semiconductor final-manufacturing sites exhibit many problems indicative of a lack of integrated systems support. Five years ago, there were few automated systems to support manufacturing — a single Tandem computer at each site provided simple inventory tracking, and a variety of small, homegrown data collection systems were available.
The systems that existed were not integrated between factories or even within factories. High-quality production information was unavailable or, at best, held in isolated islands of automation within the factory.
Over and above the systems problems are severe logistics and coordination difficulties. Products from just one of the Motorola Austin divisions can be produced in any of ten assembly sites and six final test sites around the world. This leads to coordination problems (often the product owner is thousands of miles from the producer), as well as problems stemming from language and cultural differences.
All these difficulties led to multiple environments where paper has prevailed. Even today, 87 separate paper documents must be completed to have a product assembled in the Malaysia factory. This paperwork is time-consuming, difficult to track, often inaccurate, and wasteful.
The factories understood these problems only too well; unfortunately, there were few resources to help fix them. The traditional line of support — the IS organization —
was focused on legacy system maintenance and on solutions for accounting and financial needs. Consequently, in 1989, the Austin Final Manufacturing Group (FMG)
Computer Integrated Manufacturing (CIM) organization agreed to initiate a paperless shop order system, contracting Sterling Information Group as the primary project developer to Motorola.
The factory system needs were defined as:
§ Online access to factory information and data collection on the manufacturing process
§ A means to input the necessary data easily through interfaces usable by all operators in all factories
§ Current tracking and history of all production lots through the manufacturing process (e.g., where and how they were processed, lot splits, combines, bonuses)
§ Ease of querying and reporting of all production data
§ Online shop order creation and maintenance to control the process specification and the data collection
§ All these functions available in a general-purpose manner to support multiple, diverse factories throughout the world
This undertaking would form the central nervous system of a 24-hour-a-day, 7-day-a-week production facility — a true mission-critical system.
SOFTWARE QUALITY PROCESS: THE EARLY DAYS
When the development of PIMS began, few of the people involved with the project had formal computer science training. Most were manufacturing personnel or engineers who could help define production needs but did not yet recognize the need for a software development process specification analogous to a production process specification.
The corporate quality improvement effort at Motorola had been well under way for years, but was only rarely being applied to such soft activities as administrative functions, personnel management, and software. This meant that there were few if any accepted models for developing high-quality software systems. The Motorola Six Sigma Quality program — a statistical approach defining quality goals of fewer than 3.4 introduced errors per million opportunities — was being applied to software in only a few remote areas within Motorola.
Manufacturing improvement efforts undertaken at the time required massive amounts of production data to support measured Six Sigma improvements. Ironically, the subsequent drive for data often caused information systems to be developed rapidly and with little or no control, so that several poor-quality information systems were a legacy of production quality improvement efforts.
Because the full requirements of PIMS were not well understood by the factory users or the developers, the early process life cycle used was essentially a spiral model: the goal was to place some capability out onto the manufacturing floor, exercise it, find the problems, and determine the real requirements, and then reiterate to build
on each release. Methods were applied informally (e.g., the “back of the napkin”
approach). The development model in use meant that design occurred simultaneously with editing the code. This approach resulted in fast product turnaround and an increased understanding of user needs early in the project, but it also meant that little of the process was documented and plenty of mistakes made their way to the users.