Customer Reviews

Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage

5 star:		(12)
4 star:		(2)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Competitive Engineering (CE) presents an updated contribution from Tom Gilb to the topics of systems engineering, software engineering and agile project execution. As a handbook, this work does not require the reader to have read prior works, although one is frequently invited to visit his website for additional information. From the title page, the reader receives an open invitation to enter into dialogue with [...].

Tom writes from a long practical background and with confidence that the Planguage Methods really work - if one is willing to give them a chance. However, this is not a new tyranny of methodology, but rather a rich tool set that can be adopted and adapted by a team or an organization.

The essential elements of Planguage are requirements specification (Chapters 2-6); Impact Estimation (Chapter 9), a technique unsurpassed in its ability to track the progress of a project toward achieving critical objectives; and evolutionary project management (Chapter 10), first introduced by Gilb in 1988. Specification Quality Control (Chapter 8) builds upon his earlier work on Inspections, see Gilb and Graham 1993. Chapter 7 discusses the design engineering process with cautionary advice about avoiding the trap of letting design specifications masquerade as requirements.

The book comes with a "friendly warning" that the ideas are presented in a very compact style. To ease the assimilation process, Tom includes a list of top 10 principles in each chapter. These pages, along with the "Twelve Tough Questions" in section 1.2, are worth the price of the book - but you may still want to read the supporting material for concrete suggestions about how to implement these principles. The book is also rich in diagrams and summary tables.

The objection most often levied by doubting readers is the uncompromising emphasis on quantification. Those who persevere should experience the benefits illustrated by the case studies that are an integral part each chapter. The title page of each chapter lists the key concepts that follow. One quarter of the book is comprised of the Context Glossary, which provides contextual definitions for those who struggle with the proliferation and occasionally contradictory use of terms in other literature.

CE is for anyone SERIOUS about improving communications within their development environment and thereby reaping the benefits of Competitive Engineering.

My interest in the topic of competitive engineering (CE) was piqued several years ago when I heard very favorable comments about Tom Gilb's tutorial on that subject at the INCOSE 2002 Symposium in Las Vegas.

The book's subtitle is "A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage". The term "Planguage" is central to an understanding of the book. Planguage, which is derived from a union of "plan" and "language", is the methodology for implementing CE. Much of the book is devoted to describing the generalized processes, rules, and vocabulary of Planguage. Tom notes, "Planguage should be viewed as a powerful way to develop and implement strategies that will help your projects to deliver the required competitive results." Fundamentally, the book presents a new take on best practices in systems engineering and management.

The book is useful on several levels. For organizations without a formal or documented process, tailoring of Planguage would jump start the process at a high level of maturity. For organizations that have achieved CMMI level 3 status, Planguage by itself is not as useful. However, many of the ideas of CE-the Planguage methods-are worth considering for enhancement of existing organizational processes. Tom states that CE is "about technological management, risk control, and breakthrough improvement in complex business systems, projects, and processes." CE is a believable approach for delivering complex projects on time and within budget.

The book passed my value-added test, when I realized that I was photocopying several pages for future reference, to be part of my "toolkit" of helpful tips and techniques. I particularly enjoyed reading the 10 often witty, summary principles in each chapter. Two examples are:

* The Principle of `Storage of Wisdom': "If your people are not all experienced or geniuses, You need to store their hard-earned wisdom in your defined process. Capture wisdom for reuse, Fail to write it, that's abuse!"

* The Principle of `The early bird catches the worm': "Your customers will be happier with an early long-term stream of their priority improvements, than years of promises, culminating in late disaster."

About 30% of the book is the Planguage Concept Glossary, which Tom views as a central contribution of the book. I focused my attention on the other, more interesting, parts of the book, which describe the main CE/Planguage methods of Requirement Specification (RS), Design Engineering (DE), Impact Estimation (IE), Specification Quality Control (SQC), and Evolutionary Project Management (EVO, also known as Evo). RS describes an approach for identifying all types of requirements while avoiding ambiguity and also planning for change. Functional and performance requirements are distinguished. DE deals with identifying, choosing, and prioritizing the order in which design ideas are implemented and delivered. In conjunction with Evo, DE selects the design ideas most likely to provide a significant benefit for early delivery.

SQC is an eminently practical approach for evaluating the quality of any technical document via sampling measurements. An hour of SQC early in a project can save almost 10 hours of rework. SQC also provides a means to assess the success of process improvement efforts. IE provides a realistic method for evaluating-in quantitative terms-the effectiveness of designs in meeting both the requirements, especially critical performance attributes, and the resource budgets.

Evo focuses on early, frequent delivery of project results via a series of high-value, small evolutionary steps. An ideal Evo approach would divide the project into a series of cycles. Each cycle would consume 2-5% of the total financial budget and 2-5% of the total project time-while delivering some measurable, required results to the stakeholders. The next cycle is selected to deliver the best stakeholder value for its cost (highest ratio of value to cost, or highest ratio of performance to cost). Although an ideal approach can't always be realized, Tom provides some convincing examples to argue that there is always a solution to making a project evolutionary (small steps with critical deliveries first).

Perseverance pays off with Competitive Engineering. The book is not a quick read, which Tom acknowledges. You have to carefully study some of the pages to understand the concepts being presented. The reward occurs when you glean the nuggets of wisdom from the numerous practical examples, case studies, and Planguage examples. Tom's way of presenting the CE concepts makes the book a useful addition to the systems engineer's library.

A brilliant guide to complex systems development
Reviewer: Romilly Cocking from London, UK
This wonderful book explains how to deliver complex systems within time and budget, with a level of quality that will earn you a "wow!"

The book defines the five core processes of Competitive Engineering: Requirement Specification, Design Engineering, Specification Quality Control, Impact Estimation, and Evolutionary Project Management. It includes plenty of practical advice and lots of real-world examples. At the back you'll find a detailed glossary that contains precise definitions and detailed explanations of hundreds of the key concepts used in the book.

I loved the style, which is clear, practical and precise. I found it a demanding but very worthwhile read, not least because of the high density of ideas per chapter. There are things to think hard about on almost every page. Gilb's decades of practical experience in complex systems development are evident throughout the book.

Strongly recommended.

There are people who suggest approaches to project management and design that seem more sophisticated or more grounded in generally accepted theory than Tom Gilb's. Tom's edge is that his ideas just work.

Competitive Engineering covers a huge range of topics clearly and with many detailed, helpful examples to show exactly what the techniques look like in practice.

My particular favourite is the section on design ideas. So much writing on systems engineering discusses design as if you can somehow analyse your way to the final design. I've always found that ideas are needed so the section on generating and sifting ideas is true to life and helpful to me.

The more you learn about Tom's methods the easier it is to see where so many organisations are going wrong.

Most people realise that getting benefits from systems projects is important but "benefits management" tends to be too superficial and too late to do much good. In Competitive Engineering Tom starts with the benefits to stakeholders and just never lets go.

This is a collection of techniques that work, put together into an overall, cohesive approach based on Tom's decades of consulting and invention.

Tom has already written one classic - "Principles of Software Engineering Management". It's a nice easy reading book full of great ideas; I dip into it at random every so often and always find it inspiring.

This new book will one day be regarded as a classic too, but it is much harder to read. Tom says that he's been working on this book for the last decade and a half and it shows: it's packed full of fantastic ideas, observations and tips, but you do have to work to get them.

I work in "Agile" software development and, just like Agile, this book is hard work but it's worth it.

Tom Gilb's book, Competitive Engineering, is for those professionals serious about tackling the requirements specification effort in any real project. I am excited about it. He offers his Planguage for structuring the system engineering process and gets at issues of risk, success and failure criteria and evolutionary project development in a rational way. This book is a must read, re-read and study for students and practioners working in the murky area of mapping the problem domain to the solution domain. It provides suggested metrics, examples and ways of looking at problems. His "Twelve Tough Questions" listed on page 8 gets you focused and sets the stage for a well-written `how-to' book on separating user wants from their needs and setting the stage for potentially successful software projects. He makes failure part of the process on page 40. I loved his process diagram with the vertical right positioned arrow. It is a nice touch that reminds us that these processes are non-linear and contain feedback loops at every turn.
It is, as promised, a Handbook. Buy it, and you will use it. It will not collect dust on your bookshelf. This book is a wonderful contribution to our Software Engineering literature. It will be the basis for our CS 564 Requirements Engineering Course at Stevens Institute of Technology. Gilb shows us that software technology is maturing and his deep understanding of the field clearly emerges in his writing. So I urge you to click into your cart, now.

I have been waiting for this book for almost 2 years now. Every professional who is in serious competition should very carefully listen to what Tom Gilb has to say. After reading this book you will see the world through different eyes. I'm not exaggerating! Tom Gilbs view on quality and measurable quality requirements was like an eye opener to me. Also the numerous rules, procedures, and process descriptions are nearly invaluable. I'm working at Sun Microsystems in the StarOffice development and can acknowledge that the ideas of this book have deeply influenced the work at StarOffice. But be warned that this book is not for being quickly browsed. You have to read it carefully but the return is tremendous.

I was looking for a book on requirements development and found this book to be on topic, but not a bulls-eye. I would have liked more in-depth examples, as the provided ones just touched the surface. However, I did find the book thought provoking and thus a 4 star rating.

Specifically, I found the various requirement-development templates that were provided as a good means of collecting thoughts around requirement topics. In my attempts to apply the templates, they helped refine my thoughts as to the issues surrounding requirements development.

The book refers to the author's web site for further information and examples. I'd give that site a 2 ½ star rating, as the information there was rougher information than provided in the book.

I'd recommend this book for anyone contemplating requirement development. The reader is left to generate their own examples.

Planguage is a word and concept that combines Planning and LANGUAGE and is rooted in the author's experience since 1960. The core tenant of Competitive Engineering is that well structured specifications have a dramatic cost reduction over down-stream error correction. The defect prevention process (DPP) is used to clean up early stages specs, or preferably measure defects and motivate lower defect injection, in specifications and the attendant issues instead of relying solely on defect detection andcorrection once actual development has begun. Competitive Engineering provides focus and skills to dramatically increase how productive many of us have been in the past.

The centrality of quality specifications means significant gains for the broadest spectrum of stake-holders who stand to win with the System Of Interest (SOI). Take this specification as an example to clean up:

"The new system will use Foo language running on OS Bar and ensure top industry quality response time on web requests."

People in the field have seen specs like these. Hopefully you aren't writing them. There are what Gilb classifies as "Major defects" in this spec. Which web requests, the front page or all of them pulling from the various databases? Can the old system be incrementally upgraded instead of an entirely new development environment? Why use Foo and Bar if something else gets the job done better, faster, and with less resource utilization? Just how fast is "fast", anyway?

In Competitive Engineering you're told to get measureable quality requirements, record who requested that requirement, and exactly what "success" is defined as. That allows you to go back to the requester with notes such as "If we use OS Baz we'll get a 27% increase in CPU performance" and let them make a decision or escalate to the project funder. You're also encouraged to weed out "design constraints"; at least out of the mandatated and into the labelled area "Design Constraint". Wouldn't it be great if you got a specification that let you design the best you could without technical input from someone that can't use a web-browser?

See if you can understand my re-write of the above spec into Planguage.

Response Time on Front Page of Company Website.

Type: Performance Requirement
Version: 1.2
Status: Draft
Owner: F. Flintstone

Stakeholders: Marketing, Server Support, Corporate Intelligence, , <Current Advertisers/Business partners>

Ambition: The front page of the corporate website should respond fast enough to keep the viewer's attention.

Description: Marketing research indicates the typical business website viewer makes an opinion on the website, and thus the company, within 20 seconds. Our corporate site pulls data from three different databases and a sizeable image library, taking an average of 26.87 seconds on a home DSL/Cable modem equivalent network. Marketing advantage can be gained if we can grab viewer attention noticibly faster than our two nearest competitors who average 23.43 and 26.09 seconds, respectively.

Vision: Enough accurate information provided quickly enough to keep the customer on our site.

Scale: Time, in Seconds, to a complete front page load on the equivalent of a 250K network connection.

Past [Front page, 1 Apr 07]: 26.87 seconds

Goal [1 November 07]: 19 seconds <- Marketing Director: BR

Stretch: 15 seconds

Wish: 9 seconds

Design Constraint: Supportability <- Server Support Manager WF Must utilize <Currently supported OS/Hardware>.

Design Constraint: Security <- Corporate Intelligence BB Must meet <Current security guidelines>.

------------------------ end of spec example --------------------

Probably the only thing that might confuse you about that specification is the use of text within "<...>". Planguage uses that to denote a "fuzzy requirement"; something that is defined but not with the concreteness you'd like. In this example, however, it would be relatively simple to query B. Rubble for the specific guidelines her team seeks to enforce. The use of fuzzy requirements also allows for change over time; more OS versions may become supported while others are obsolete.

When I read part of an electronic copy of the text I had a problem. My antiquated home printer could not print it and if I used the work printer I view the output as a possession of my employer. The book is written as part instruction, part reference manual; I bought my own copy because I know I'm going to use it for the next few years and several employers.

In a period where the trend is to follow agile approaches with condensed guidance (see the 12 principles of the Agile Manifesto for instance), it could seem strange to publish a book on software development with more than 500 dense pages. You should however not be frightened by this book. Beneath the size and the structured form lies an approach based on practical experience that incorporates change and flexibility without abandoning the quest for precision and delivering value.

The main concept of Competitive Engineering is Planguage, a word created mixing plan and language. Communication is the basis for working together. This is why Tom Gilb emphasises first the creation of a common vocabulary. He states that his glossary could be considered as the best contribution of this book. Beneath the definition of a common language, for me the "hidden agenda" of the book is to help us to think... further. The common language is only a tool that helps us express our thoughts more precisely and completely.

Fortunately for us, Tom Gilb didn't only write a dictionary of system engineering. A large part of the book is devoted to the activities of system engineering and project management. Based on Planguage, Gilb gives us a framework to elicit clearer requirements. He emphasises a measurable vision ("bad numbers beat good words") and presents tools to achieve this objective. He also helps us separate requirements from design. He devotes an entire chapter to quality control. Finally, there is a presentation of the techniques of evolutionary project management that supports incremental development based on the priority and impact techniques described in previous parts of the book.

In every chapter you will find examples and case studies that help to visualise how the concepts translate into practice. There is also an "additional ideas" part that presents material for further thinking. Beneath the seriousness of the topic, Gilb also manage to place some lighter parts and you will find how to compare seriously apples with oranges.

At the end, your realise that you have a book where process is not opposed to people, structure is not opposed to flexibility, precision is not opposed to allowing change, documentation is not opposed to active refinement, Gilb's proposed solution is not opposed to customisation for your needs. It is just a book that gives you new inspiration to deliver better software solutions to your customer.

If you are interested in software process improvement, you can read this book from the beginning and find practical material to examine your current practices with a different vision. If you are a lonesome project manager or developer, you could begin by just using the index to get Gilb's view on your current activity or problem. Be cautious, because there are many chances that you will be tempted to read more material ;o)

After reading this book, I browsed again my old copy of "Principles of Software Engineering" that I bought when it was published in 1988. I saw that many ideas from "Competitive Engineering" were already presented in this book. Tom Gilb just applied to his ideas the same concepts he proposes for system engineering. He refined, expanded and structured them to get a better product. The printing industry has just prevented evolutionary delivery, but you can bet that he will find a way to include this in the future.