Newsletter of the Boston SPIN

Issue 1, January 95

CALENDAR

Jan 17 (Tue), 0630 pm Monthly SPIN meeting

May 22-25 (Mon-Thu) 1995 SEPG Workshop, Boston

NOTICES

Request for Critiques of a Paper on Information Microstructures.

Ed Lowry (508-263-3508, eslowry@mcimail.com) would appreciate critical evaluation of a several page "proof" that simple directed arc data objects (pointers) provide for the maximum simplicity of expression in formal languages. They are shown to be uniquely optimum for complex applications.

KUDOS

After a year of nontrivial footwork, phonework, and formwork, Charlie Ryan has completed the process of obtaining nonprofit status for Boston SPIN. Thank you Charlie! You may now resume having a life outside SPIN.

BOOK REVIEW:

Practical Software Metrics for Project Management and Process Improvement--Robert B. Grady--Prentice Hall 1992
by Rachel Silber

This book is a useful guide for any practitioner of software measurement. It assumes that you are ready and willing to measure critical aspects of your software engineering process, and that you have company support for doing so. (The predecessor to this book, "Software Metrics: Establishing a Company-Wide Program", by Robert Grady and Deborah Caswell, will help take care of these requirements.) Once you are there, "Practical Software Metrics" will help you determine which metrics to use, and how and when to apply them.

The text assumes that you have some basic knowledge of quality processes and graphical and statistical methods. It is not a comprehensive introduction to software metrics, although through its excellent glossary and suggested reading list it would be possible to explore the field on your own. Well done graphs and tables throughout the book summarize information and are a valuable resource if you need to educate other people about metrics. The book is structured to answer two basic questions. First, given particular goals, what is the best set of measurements to take? Second, given some data from metrics, how can that information be used to create process improvements?

A wide range of possible metrics, familiar and obscure, are considered. There are both engineering-oriented metrics, such as defects per K lines of code, and customer-oriented ones. In the latter category, Hewlett- Packard uses the FURPS+ measurement (Functionality, Usability, Reliability, Performance, Supportability, plus ...). As a comprehensive way of organizing customer needs and relating them to engineering priorities, presenting this metric is a major contribution.

Grady clarifies which factors are most appropriate to measure for different management goals. For each goal that a product team could have, he sets up a paradigmatic set of questions that would need to be answered to see whether the goal was met, and explains how to select a set of metrics directly applicable to the goals. The book is made very readable by the practical tone and by the many case histories. He emphasizes that not all metrics require high levels of abstraction to measure. Heuristics and the management ability to rapidly assess a project are also valuable.

Grady gives specific examples of using the results of measurement to improve the development process. Planning how to analyze the data becomes part of the overall metrics strategy. Although the topic is covered more extensively in the previous book, Grady covers the important territory of how not to use metrics information, such as to judge specific people. He suggests methods for getting accurate information without making people defensive about being measured.

Your manager will love this book, because Grady emphasizes measuring the ROI of changes to the software process before leaping ahead. There are extensive examples of cost-benefit analysis associated with different metrics. Continuing the company-wide aspect of the first book, Grady advocates tracking the health of your organization with a balanced set of metrics that track multiple aspects of performance. His selection of measurements would help most organizations keep a clearer focus. Here Grady does recommend a specific set of measurements and graphs to keep management informed about software process; this is at variance with his approach in most of the book of providing several alternatives for each situation. However, the selections are well justified and would benefit most organizations.

By bringing the author's long experience with metrics to bear, "Practical Software Metrics" helps the standard of software measurement to move ahead. I believe this book would be valuable to anyone whose work touches on software process improvement.

Rachel Silber helps support software process improvements at Ontos, Inc. in Burlingon. She is now reading "Multiplatform Code Management" by Kevin Jameson for a future review.

SOFTWARE METHODOLOGY vs PROJECT MANAGEMENT
by Bill Duncan

Thirty years ago, the typical software development project finished much later than planned, cost far more than was budgeted, and produced substantially less functionality than the user (or customer or client) needed. In the intervening decades, much has changed. We have traded the pain of spaghetti code for the joys of structure (mostly). We have given up the tedium of typing source code (on punched cards, no less) for the convenience of CASE tools and other development aids.

And today, the typical software development project is still behind schedule, over budget, and unlikely to deliver what the corporation needs.

Is it the nature of software development? Must we always struggle so? Other functions similar to software have made significant improvements. For example, designing a new car has much in common with developing a new software system -- it involves creativity, complex technical interfaces, and frequent changes to the requirements. In just the last ten years, the duration of the typical automotive design project has been cut by nearly two thirds, and the quality of the product is better than ever.

What prevents the software discipline from making similar progress? One major contributing factor is the failure to distinguish between "project management" and "software methodology".

SOFTWARE METHODOLOGY	PROJECT MANAGEMENT
Defines a framework for solving the technical challenge	Defines a framework for planning and managing the work
Specifices the technical attributes of the desired product	Specifies how to deliver the product on schedule and within budget
Describes and organizes the major deliverables	Describes and organizes the work needed to produce the deliverables
Defines what an individual must know	Defines how individuals will integrate their knowledge
Specifies technical roles and responsibilities	Specifies management roles and responsibilities
Measures progress against the technical requirements	Measures progress against the project plan

Understanding the Difference

The relationship between project management and software methodology is similar to that of marketing and sales. Software methodology is like marketing -- it is a strategic discipline concerned with "what" you must do to be successful:

What is the best way to identify user requirements?
What must be done to meet relevant quality standards?
What technology should be used to support each application?

Project management is like sales -- it is an operational discipline concerned with "how" to be successful:

How should the team be organized?
How long should the work take?
How can you tell if you are on schedule?

As with marketing and sales, skill in both disciplines is necessary for success. For example, most software methodologies identify customer involvement as a critical success factor (what to do). Project management then "delivers" customer involvement by determining which specific customers will be involved and when (how to do it).

Admittedly, there is some overlap between the two. Many methodologies provide some guidance on estimating and scheduling. Both disciplines place great emphasis on producing a quality product -- one that both conforms to the specification and is fit for use. Despite the overlaps, it is important to understand the differences between the two because poor practices in either area can result in a failed project.

Apples and Oranges

For example, I recently attended a presentation by a senior manager of a leading software engineering consulting firm. He noted that many companies were losing substantial chunks of market share to more nimble competitors because of their inability to develop mission-critical systems in a timely fashion.

The problem, he said, was that software developers needed a whole new approach to project management. But the problems he described were those of highly structured, traditional methodologies that equate the quantity of paper with the quality of the system and that mandates slavish adherence to detailed plans -- even when the plans are clearly outdated. This is the antithesis of modern project management.

By failing to make a clear distinction between software methodology and project management, he cut himself off from some simple truths that are readily available in the project management literature:

His clients' initial resource estimates were demonstrably "less than half" what was really needed (most software development projects actually have less than one chance in six of finishing within their approved budget).

His clients' schedule estimates had "less than one chance in a million" of being met (most software development projects are promised for a date that is six to eight standard deviations below the expected result).

A new, more efficient methodology might reduce software development costs, but without better project management his clients' methodology would simply overrun a somewhat smaller target.

A Case of Misidentification

In another example, I read an article that suggested using prototyping as a project management technique. The article was an analysis of the potential for prototyping to reduce project duration. The clear implication of the article was that a project management technique was anything that would reduce project duration. The author was mistaken. Project management's charter is to make the process predictable and repeatable. Good project management can often shorten project duration, but it does so by helping to anticipate and avoid problems that could cause delays.

In both examples, experienced software developers confused software methodologies with project management. In doing so, they cut themselves off from a significant body of knowledge that can help them respond to today's demanding environment. Modern project management affords:

Better scope definition to minimize last minute surprises.
More accurate estimates to allocate scarce resources to the most critical projects.
Improved progress measurement to support appropriate mid-course corrections.

Conclusion

Every software developer has a favorite horror story about a system or product that took months or even years longer than expected or one that was so full of bugs it was virtually unusable. Many of these problems were caused by poor project management; most were attributed to some other cause.

As long as software developers fail to perceive the difference between project management and software methodology, they limit their ability to identify and address a major cause of distress.

Bill Duncan is a partner in Duncan-Nevison (Lexington MA), Director of Standards for the Project Management Institute (PMI), a member of the Editorial Review Board for the "Project Management Journal", and primary author of PMI's "A Guide to the Project Management Body of Knowledge" which was used as the basis for ISO/CD 9004-6, "Quality in Project Management."

DEAR SPIN DOCTOR

Hello SPINners: A very healthy, happy and prosperous New Year! And yet another chance to start over and to make New Year's resolutions. As I sat and thought of all the resolutions I had made through the years, most of which I had not achieved, it occurred to me that this process of making and achieving resolutions closely parellels the process of making and achieving process improvement action plans.

Think about it for a minute. We look earnestly for ways to make improvements in our lives and the lives around us. On January 1, these resolutions sound wonderful and they are actually what we need to do. So what happens?

Let's look at an example: "I'm going to work out at the gym three times a week, lose twenty pounds, walk three miles a day, spend more time with my family, volunteer time to help others." The problem is that these are all HARD things to accomplish; they are ambitious, time-consuming, tiring, and, for the most part, they are tacked onto our normal daily duties. They often turn out to be too hard, too ambitious and too time- consuming for us to achieve them 100 percent. And in time we end up doing none of them, giving up, feeling poorly about ourselves. Similarly, we may largely abandon our process improvement efforts when they are too hard, too ambitious, and too time-consuming.

We need to plan for success in both cases by choosing actions that we can accomplish with the time and energy level that we have available to us. One of the things that can help us to do this is ideas and information from others. But getting others to focus on our own specific scenarios is not always easy.

To help YOU get the focused information you need to accomplish your process improvement goals, the SPIN Committee is hereby launching a "Dear SPIN Doctor" column. Send us your questions! As your SPIN Doctor, I will attempt to answer them through local resources and big- name mega-experts---including Bill Curtis, Ray Dion, Watts Humphrey, and Mark Paulk. Think of this column as your hot link to the vast resources of the collective process improvement consciousness.

You can submit your questions (or your comments on our answers to questions!) via email to me (brodman@tiac.net) or drop them in the feedback box after the SPIN meeting each month. You may sign your name, or use an alias if you prefer to be anonymous.

I look forward to the challenge of addressing your questions...

The SPIN Doctor

MASTHEAD

The Boston SPIN is a forum for the free and open exchange of software process improvement experiences and ideas. Meetings are held on third Tuesdays, September to June. Volunteers and sponsors are always welcome. For more information contact Maureen Harris, GTE Building 5, Dept 0440, 77 A St, Needham Heights MA 02194; Tel 617-455-3393; Fax 617-455-3377; Internet harris.maureen@mail.ndhm.gtegsc.com.

IN THE SPIN is published monthly September to June. Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors.

To subscribe send email address to rprice@ma.ultranet.com (Ron Price). IN THE SPIN is available only by email.

Send Spin Doctor questions to brodman@tiac.net (Judi Brodman).

Send letters-to-editor, notices (including job postings but not advertisements), calendar entries, article proposals, and general correspondence to sallie@world.std.com (Sallie Hoffman).

Return to Newsletter Index