PERCEPTIONS AND ROLES OF THE PROJECT PLAYERS
All the individuals involved in the PIMS project have had some effect on, and have been affected by, the changing development process. As in all far-reaching quality initiatives, changes affecting people are much harder than those relating to technology. All the players, especially managers, must perceive value in their role in process improvement or they will not accept and adapt to the change. This is especially true when each player’
s job is evolving along with the evolution of the
process.
Developers
The original manufacturing and contracted development group had little experience in formal methods. Most of the developers were at first reluctant to adopt a disciplined development approach because of the change to their jobs and because of the bureaucracy they associated with documenting and formalizing the methods. One person who felt inhibited by the process left the project. Overall, the developers recognize how the process improvements have helped, and most of them state that they would not consider undertaking the project without the formal process.
Support Personnel
The PIMS project support personnel consists of those Motorola employees who maintain online shop orders on the PIMS system, work with PIMS relational databases for custom and ad hoc reporting of production data, and provide impleme ntation support for the factory operations. These individuals have had to take a much more active role because of the enhanced development process. Their input to requirements definitions must be strict and well investigated. They perform the primary role in the now-formalized user testing. In addition, they provide disciplined tracking of problem and enhancement reports through the PIMS online database.
Managers
The PIMS team is fortunate because the manufacturing managers supporting the project actively promote a culture of continuous process improvement. Like many others, however, these managers have much to learn about software engineering and the systems development process. Every presentation of the PIMS project now contains reports on process improvement efforts and metrics to help shape the expectations of managers and other customers.
One interesting outcome of the formal methods is that the managers are sometimes bound by the process as much as others — they no longer have the ability to request quick enhancements to be done on the fly. Managers must support the process the same as all the other players for it to be successful.
Users
In general, the end users are not aware of all the process improvements that have taken place; however, they do see c lean releases. One release two years ago had dozens of medium to major bugs, and it took weeks for the system to be fully installed and running. The most recent PIMS release had only a handful of minor customer-found bugs. PIMS was running smoothly five minutes after the expected system downtime was over.
Software Quality Assurance Personnel
Much as in an effective manufacturing area, the quality of the process is everyone’
s
responsibility, not the purview of a specific quality expert. Consequently, there are no software QA personnel.
BENEFITS AND COSTS OF CONTINUOUS PROCESS
IMPROVEMENTS
There are many costs and benefits from process improvement. The metrics being tracked are expected to shed more light on the quantifiable effects of the process improvement efforts. Currently, the project team believes the benefits of the improvement efforts outweigh the costs. This is all the more significant because the improvements were made in an existing, ongoing project — not one in which the team could start with a clean slate. Among the benefits credited to the project:
§ A higher-quality software is produced, one that is more robust and solves user problems without creating new ones.
§ Less rework is required, so there is lower long-term product cost and shorter cycle time to a useful product.
§ More accurate project estimates are produced.
§ There are fewer fires to fight. Unforeseen emergencies for management to deal with are now less than one third of what they were two years ago.
§ There are much cleaner releases with far fewer problems seen by the users.
This in turn improves the credibility of the developers.
§ The process forces developers to take into account more general needs and to find more flexible solutions.
§ A common process, and the common knowledge base for the project, improves the project continuity, enhances communications, and makes the product more supportable.
§ There are also associated costs, among them:
§ Less responsiveness to enhancement requests: Every enhancement must go through the entire life cycle to a controlled release.
§ Increased cost of initial development.
§ Changed job descriptions: Everyone is responsible for the process, and not just hacking out code. This change in job descriptions has been a difficult and frustrating change for some.
FUTURE IMPROVEMENTS
Although significant advances have been made in the PIMS development project, systematic improvement is a continuous process. Improvements that are planned for the near future include:
§ The collection and tracking of more metrics, and the better use of metrics to help the team identify areas for improvement
§ The use of testing metrics to predict more effectively the time and effort necessary to achieve clean, yet efficient releases
§ Fully automating the integrated problem tracking and configuration management support system
§ Applying Delphi estimation techniques to achieve more accurate estimations for major enhancements
§ Involving the team in a formal SEI assessment to identify areas of highest leverage for improvement
§ Transferring the improvement lessons from PIMS to other projects, both in Motorola and in other Sterling projects
CONCLUSION
Without a doubt, PIMS is a higher-quality system than it was a few years ago. It forms the central nervous system of a number of factories and consists of hundreds of thousands of lines of code; yet recent major installations have been almost trouble free. Ongoing maintenance costs are one quarter of what they once were, and key metrics indicate that the project is close to a Six Sigma quality deployment effort. This success can be directly attributed to improvements in PIMS software development.
One of the major lessons learned is that the techniques and philosophies of continuous quality improvement are as important and as applicable to software development as they are in more traditional functions like manufacturing. Other beneficial lessons drawn from the PIMS experience can be applied to the continuous improvement program in general:
§ Systematic improvement requires dedicated support from developers and managers. It has taken many years of coordinated effort to achieve the improvements Motorola has made in the PIMS project, and the team is still far from satisfied. IS managers hoping for instant measurable improvement will almost certainly be disappointed.
§ It is harder to change culture — people’
s thoughts and habits — than it is to
change technology. The PIMS project team wrote its own defect- tracking tools in a few weeks, but convincing people to use the tools consistently to track their own errors was far more time-consuming.
§ A formal development process pays for itself in improved quality and efficiency. It is always painful to spend the time up-front to do the analysis and design thoroughly, but doing it right the first time is less costly than redoing work at coding, or even worse, after the product is released.
§ Metrics are the key to measuring, understanding, and controlling the development process. No gut feeling is worth the measurement of a 100
percent defect improvement rate.
§ Any project can benefit from formal management of the basic development process. These lessons have been transferred to other projects, large and small, old and new, thus proving that the techniques are valuable in all types of systems.
Chapter 15: Incorporating Six Sigma Concepts into Systems Analysis
Christine B. Tayntor
OVERVIEW
Six Sigma. Cynics may claim that it is nothing more than the program du jour; just another in a string of management fads, and that it will soon be supplanted by a different promise of improved productivity. Companies that have embraced Six Sigma’
s concepts say otherwise.
At its most fundamental, Six Sigma is a measurement of defects. A company that has reached the Six Sigma level will have only 3.4 defects per million opportunities.
In other words, it will have virtually defect-free operations. For those companies, Six Sigma is more than measurement. It is a way of doing business that reduces costs by focusing on customer requirements, by making decisions based on facts, and by improving processes. All of these result in reduced defects.
Some companies, particularly those in the service industry, shy away from Six Sigma because they view it as a program for engineers — one with too much rigidity.
Although emphasis has been placed on the statistical analysis tools that assist in the identification of opportunities for improvement, the value of Six Sigma is far more than statistical analysis, just as the program itself is more than a measurement of defects.
While becoming a Six Sigma company may mean a cultural change that some corporations are unwilling to undergo, it is not an all-or-nothing proposition.