Established September, 1992
Newsletter of the Boston SPIN
Issue 1, January 95
Jan 17 (Tue), 0630 pm Monthly SPIN meeting
May 22-25 (Mon-Thu) 1995 SEPG Workshop, Boston
Request for Critiques of a Paper on Information Microstructures.
Ed Lowry (508-263-3508, email@example.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.
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.
Practical Software Metrics for Project Management and Process Improvement--Robert B. Grady--Prentice Hall 1992
|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|
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:
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.
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.
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:
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."
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 (firstname.lastname@example.org) 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
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 email@example.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 firstname.lastname@example.org (Ron Price). IN THE SPIN is available only by email.
Send Spin Doctor questions to email@example.com (Judi Brodman).
Send letters-to-editor, notices (including job postings but not advertisements), calendar entries, article proposals, and general correspondence to firstname.lastname@example.org (Sallie Hoffman).