Gilb Papers Help

Downloads: Papers written by Gilb.
Multiple select
  T Filename Name Description Created / Uploaded Last Modified Invert Sort Uploaded by Hits Other Sorts
Actions application/pdf Stakeholder Power paper.pdf Stakeholder Power: The Key to Project Failure or Success a short paper with 10 principles about stakeholder analysis. Wed 10 of Feb., 2016 Wed 10 of Feb., 2016 Tom Gilb13 points  215 Information
Actions application/pdf Gilb on Value Engineering for Quality Days.pdf Value Delivery in Systems Engineering Value Delivery in Systems Engineering
in support of my Talk at Quality Days, Vienna, January 18, 2016

"Engineering Quality into Software: Quantifying All Qualities in Requirements, Architecture and Project Management"
Tom Gilb

a PDF as use in the conference internal publication

This is a modification and update of an older INCOSE paper
Tue 19 of Jan., 2016 Tue 19 of Jan., 2016 Tom Gilb13 points  87 Information
Actions application/pdf Confronting Wicked Problems MASTER Jan11 2015.pdf CONFRONTING WICKED PROBLEMS: and some Planguage Tools to deal with them. A paper where I forced myself to look at the so called Wicked Problem characteristics, and analyze them in the light of my own Planguage and Evo methods.

Hopefully of some use for people interested in mastering large and complicated systems.

It is also an introduction to Value Planning and Competitive Engineering book content, from the Wicked Problem point of view.
Mon 11 of Jan., 2016 Mon 11 of Jan., 2016 Tom Gilb13 points  622 Information
Actions application/pdf Beyond Scaling: Scale-free Principles for Agile Value Delivery - Agile Engineeri Beyond Scaling: Scale-free Principles for Agile Value Delivery - Agile Engineering 40 practical Engineering ideas for any scale agile development successfully all the time.

a very short pdf paper, supported by references to necessary detail. Not least the new LeanPub.com/ValuePlanning book
Fri 08 of Jan., 2016 Fri 08 of Jan., 2016 Tom Gilb13 points  837 Information
Actions application/pdf Design Logic Oct 14 2015.pdf The Logic of Design: Design Process Principles. A short paper I just had to write today. I find myself referring to the logic of design when I teach. So I wanted to be more explicit.

I wonder if anyone can find a corresponding line of thought?
Wed 14 of Oct., 2015 Wed 14 of Oct., 2015 Tom Gilb13 points  614 Information
Actions application/pdf Making Complexity Simple 300915 Paper 2015.pdf Making Complications Simple: using Planguage Making Complications Simple: using Planguage

Version 30 Sept 2015, 1st Draft

© By tom@Gilb.com

If a system increases in ‘complexity’, more parts and more connections, then it might appear to be more ‘complicated’ for us to understand it.

But, this depends not only on the system complexity, but on
our personal intellectual capability (experience, knowledge, intelligence), and
the ‘tools’ we choose to apply to analyzing the system.

A very short pdf paper


Ten Principles of Simplification: ‘Making Complexity Uncomplicated’


Planguage Tools for Simplification
Wed 30 of Sep., 2015 Wed 30 of Sep., 2015 Tom Gilb13 points  577 Information
Actions application/msword Planguage paper 2014 Oct 18.docx ‘Planguage: an 'engineering' language and process for real software and Systems engineering - not 'programming' Originally Invited Book Chapter: for “Software Engineering in the Systems Context” Edited by Bud Lawson and Ivar Jacobson

But, we have replaced it with a paper on Requirements. So this has not been published, and if you want to publish it let me know.

26 Page, MS Word paper. This can be used as an overview description of Planguage. Written Oct 18 2014 By Tom Gilb
Sun 19 of Oct., 2014 Thu 28 of May, 2015 Tom Gilb13 points  2333 Information
Actions application/pdf 8.6 CP ICL- Intro to Quality Metrics.pdf ICL - Group Quality INTRODUCTION TO QUALITY METRICS (Issue 2) This is a digital copy of a corporate brochure, issued by International Computers Limited (then about 20,000 people) in UK. It was largely written by Tom Gilb, and is based on Planguage. It is an instance or Corporate adoption of Planguage. It is from about 1984.
I am making it available now, as I reference it in my new book manuscript 'Competitive Planning' (working title, 2014 manuscript).

It contains a lot of good practical advice even today, although our understanding and articulation of Planguage has matured through the consequent years. It has remained fairly stable.

The advice is certainly far in advance of what most people have learned and practiced to date. Most people hardly quantify most qualities, particularly in software engineering, and IT, today. Much of the basis for this was laid in my 1976 Book Software Metrics, and earlier and later books.
Wed 27 of Aug., 2014 Wed 27 of Aug., 2014 Tom Gilb13 points  998 Information
Actions application/pdf 2 Unity Method of Decomposition 2011.pdf.pdf The Unity Method of Decomposition Gilb's Mythodology in Agile Record, paper number 2 Mon 21 of July, 2014 Mon 21 of July, 2014 Tom Gilb13 points  1082 Information
Actions application/msword PLanguage Philosophy Architecture updated from 1995 in 2005.docx Planguage [Philosophy]: Background depth for teachers, consultants and the curious This is a draft of a companion book, NOT complete, showing the use of Planguage to design Planguage. It was drafted in 1995 (under the banner, the CONTROL method, later changed to 'Planguage. it is hopefully of interest to students and teachers of Planguage and 'Evo'.
The outcome of this is mainly in the Competitive Engineering book published in 2005, which defines Planguage in the form of a Standards Handbook.

There are other design details such as the design of the Iconic Language, where I tried to describe planguage concepts using pictorial icons. This work is not published or on any website yet. But I'll make it available to interested people. Maybe here on Gilb.com.
Thu 26 of June, 2014 Thu 26 of June, 2014 Tom Gilb13 points  987 Information
Actions application/pdf Advanced Product Owner FINAL AgileRecord_17_Gilb.pdf.pdf ADVANCED PRODUCT OWNER GILBS MYTHODOLOGY COLUMN Agile Record 18 Feb 2014
We are going to argue that the normally defined role of Product Owner (PO) is inadequate for projects that have serious multiple quality requirements, and consequent architecture processes, to deliver the necessary levels of performance and quality.
Thu 20 of Feb., 2014 Thu 20 of Feb., 2014 Tom Gilb13 points  2624 Information
Actions application/pdf Gilb Col 6 Top 10 Critical Requirements.pdf The Top 10 Critical Requirements are the Most Agile Way to Run Agile Projects August 2012 issue 11 Gilb‘s Mythodology Column www.agilerecord.com Tue 04 of Feb., 2014 Tue 04 of Feb., 2014 Tom Gilb13 points  2809 Information
Actions application/pdf Gilb Column 1 Nov 2013 Agile Architecture.pdf Agile Architecture Engineering: Dynamic Incremental Design Selection and Validation Gilb's Mythodology Column 10. in Agilerecord.com November 1st 2013 issue 16 Fri 01 of Nov., 2013 Fri 01 of Nov., 2013 Tom Gilb13 points  2331 Information
Actions application/pdf Agile_Record_No_15_Gilb No Cure No Pay.pdf Agile Contracting for Results The Next Level of Agile Project Management: Gilb's Mythodology Column Agilerecord August 2013 We need to acknowledge the complex systems and the complex environment we all work in by taking another step in the agile direction: agile contracting for results. Wed 21 of Aug., 2013 Wed 18 of Sep., 2013 Tom Gilb13 points  2097 Information
Actions application/vnd.openxmlformats-officedocument.wordprocessingml.document Glossary PLANGUAGE MASTER.docx A Conceptual Glossary for Systems Engineering: Define the Concept, don’t quibble about the terms. PAPER. Abstract.
We seem to spend a lot of our time defining terms, arguing over terms, standardizing
terms, and misunderstanding terms. In connection with my development of a planning
language, and its basic textbook I had to make a decision regarding my glossary. One of
the formal design requirements I had set for myself was that the planning language, and
its textbooks were easy to translate into other international languages. It was primarily in
order to satisfy that requirement that I came up with the concept of a concept-centered
glossary, rather than the conventional term-focused glossary (like a conventional
The basic idea is that we focus on defining a concept, no matter how many
synonyms it might have, or how many different opinions there are about what the concept
should be called.

Wed 03 of May, 2006 Wed 19 of June, 2013 Tom Gilb13 points  7878 Information
Actions application/pdf Green Week atConfirmit as Published ar_14_gilb.pdf The Green Week: engineering the technical debt reduction in the Evo Agile Environment by Confirmit Our Gilbs Mythodology column published May 2013 in Agilerecord.com Thu 23 of May, 2013 Sat 01 of June, 2013 Admin (Kai) 1539 Information
Actions application/pdf Agile Project Startup agilerecord_13_gilb.pdf An Agile Project Startup Week: ‘Evo Start’ Our Column in AgileRecord.com, as published 7 March 2013 Sat 16 of Mar., 2013 Sat 16 of Mar., 2013 Tom Gilb13 points  2269 Information
Actions application/vnd.openxmlformats-officedocument.wordprocessingml.document The Evo Standard 12 Jan 2013.docx The Evo Project Management Standard This is my current standard for managing the Evo process, the grandfather of later Agile processes..

It was described in my 1988 Book, Principles of Software Engineering Management, and much earlier elsewhere (ACM SEN particularly)

It is documented in detail in Competitive Engineering (2005)
Chapter 10 and all other supporting chapters

It is open source and anybody can use it and modify it to taste. Nice if you credit origin (© Gilb.com, 2013)
Sat 12 of Jan., 2013 Sat 12 of Jan., 2013 Tom Gilb13 points  2198 Information
Actions application/vnd.openxmlformats-officedocument.wordprocessingml.document ’Evo’ Project Initiation Syllabus.docx Evo Project Start’, Syllabus This is a detailed standard for conducting an 'Evo' (Evolutionary Project Management, Gilb's Agile Method) as described in my book Competitive Engineering, Chapter 10

This is a 5 (sometimes 4) day project startup process, which I have used for decades.

There is a corresponding Evo process standard not yet on this site, but I will put it here, remind me!

The slides
increments of value delivery. (10 min slides)
[http://www.gilb.com/tiki-download_file.php?fileId=451] give a case study view of using this method for DoD.

I wrote a paper in Jan 2013 for agile record.com about this , the Gilb's Mythodology Column

Sat 12 of Jan., 2013 Sat 12 of Jan., 2013 Tom Gilb13 points  2106 Information
Actions application/pdf Ch (15) Deeper perspectives on Evolutionary Delivery from GILB POSEM 1988 MASTER Deeper Perspectives on Evolutionary Delivery This is a survey of sources of insights both from software field, and above all from many other fields, into the nature of Iterative and incremental planning and management.

This is Chapter 14 of Principles-Software-Engineering-Management-Gilb 1988

This file contains an addition where comments from Agile Gurus, such as Kent Beck, credit this book for early insights and inspiration about Iteratona and IncrementalProject management (eg Agile)

14 Printings since 1988 - what does that tell you?

Chapter 15 on Productivity is also at this site
Tue 20 of Nov., 2012 Tue 20 of Nov., 2012 Tom Gilb13 points  3206 Information
Actions application/pdf Ch14 Productivity POSEM.pdf (Software Engineering) Productivity: a multidimensional measurable viewpoint 1988 as published in my (Tom Gilb) 'Principles of Software Engineering Management' now in 14th Printing from 1988, so you can still buy it!

Book was acknowledged basis for Agile Iteration etc by Beck and many others.
see chapter on "Deeper Perspectives on Evolutionary Delivery" Chapter 15 and the rest of the book

(which I will put up on this site today)
Tue 20 of Nov., 2012 Tue 20 of Nov., 2012 Tom Gilb13 points  2123 Information
Actions application/pdf Eternal Principles(Grace) 2012 edit.pdf THE ETERNAL PRINCIPLES OF SYSTEMS ENGINEERING Tom's 1989 (1989!) paper a for Grace Murray Hoppe Lecture on The Future at West Bank University, London.I declined to predict (difficult, especially about the future). But suggested instead principles to deal with the future! Thu 28 of June, 2012 Thu 28 of June, 2012 Tom Gilb13 points  1917 Information
Actions application/pdf MindEdge 2012 Q&A: Tom Gilb on Quantifying Project Objectives « Project Managem Q&A: Tom Gilb on Quantifying Project Objectives http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/

MIndEdge Interview 20 March 2012
Wed 18 of Apr., 2012 Wed 18 of Apr., 2012 Tom Gilb13 points  2219 Information
Actions application/octet-stream tom_gilb Agile Principles in The Developer March 2012pdf New Agile Principles: with focus on value delivered to stakeholders Paper in The Developer (Norway) March 2012 Number 1
A Major Edit of similar ideas published in Agile Record
Mon 05 of Mar., 2012 Mon 05 of Mar., 2012 Tom Gilb13 points  2674 Information
Actions application/pdf Lean Startup Myth 4 2012.pdf “Lean Startup” – The Most Extreme Agile Method by Far Gilb’s Mythodology Column 4 in http://www.agilerecord.com/agilerecord_09.pdf Wed 01 of Feb., 2012 Wed 01 of Feb., 2012 Tom Gilb13 points  4086 Information
Actions application/pdf agilerecord_08_gilb DONE as published Agile Record .pdf Done should mean value delivered to stakeholders paper in 4 Oct 2011 Issue of free www.agilerecord.com
Gilb's Mythodology column
Tue 04 of Oct., 2011 Tue 04 of Oct., 2011 1028781 points  2337 Information
Actions application/pdf Quantifying Management TGilb_core3.pdf Quantifying Management Bullshit Quantifying Management Bullshit: forcing IT Stakeholders to reveal the value they really want from your IT Project. Core Magazine April 18 2011 First and oroignal appearance of this paper.
Mon 18 of Apr., 2011 Mon 18 of Apr., 2011 1028781 points  4124 Information
Actions application/pdf User Stories agile_record_06_tom_and_kai_gilb.pdf .pdf User Stories: A Skeptical View By Tom and Kai Gilb, in March 2011 Agilerecord.com. Gilbs' Mythodology Column The Skeptical View
We agree with the ideals of user stories, in the ‘Myths’ [1, Denning
& Cohn] discussed below, but do not agree at all to Myth
arguments given, that user stories are a good, sufficient or even
best way to achieve the ideals. We are going to argue that we
need to improve user stories for serious and large projects. It is
possible for trivial projects that user stories are sufficient tools.
Tue 12 of Apr., 2011 Tue 12 of Apr., 2011 1028781 points  5356 Information
Actions application/pdf estimation-a-paradigm-shift-toward-dynamic-design-to-cost-and-radical-management Estimation: A Paradigm Shift Toward Dynamic Design-to-Cost and Radical Management Paper published in SQP Journal March 2011 Author Tom Gilb

Accurate estimation is impossible for complex
technical projects, but keeping to
agreed budgets and deadlines is achievable
by using feedback and change. In other
words, rather than trying to improve the
initial project estimates, the budgets and
deadlines must be set based on the value
of delivery (not the cost), and then iterative
re-engineering of product and process must
be used to stay within acceptable resource
bounds. Or, at least iteration must be used
to get most of the expected value delivered,
within the acceptable budgets and deadlines.
This article explains the background to this
approach and discusses its use, providing
several examples.
Key words
estimation, evolutionary project
management, Planguage
Fri 08 of Apr., 2011 Fri 08 of Apr., 2011 1028781 points  6160 Information
Actions application/pdf quantify quality icsoft march 26 2008 00100027.pdf How to Quantify Quality PAPER: How to Quantify Quality: Finding Scales of Measure
by Tom Gilb

‘Scales of measure’ are fundamental to a specification method we have developed called Planguage. They are central to the definition of all scalar attributes; that is, to all the performance (especially quality attributes) and resource attributes.
You can learn the art of developing your own tailored scales of measure for the performance and resource attributes, which are important to your organization or system. You cannot rely on being 'given the answer' about how to quantify. You will lose control over your current vital system performance concerns if you cannot or do not quantify the critical attributes.

This was published as a paper at INCOSE.org conference Washington DC 2003.
June 14 2007 INCOSE says they will make all previous incose conference papers available on the web, so that includes this one.

There is of course a set of slides for this and other papers, on request from the author.
Thu 14 of June, 2007 Tue 29 of Mar., 2011 Tom Gilb13 points  9199 Information
Actions application/pdf Agile Planguage agilerecord05_Gilb_Brodie.pdf AGILE ASPECTS OF PLANGUAGE: For Cost-Effective Engineering PAPER. • Planguage is a comprehensive, but not exhaustive, set of tools for systems engineering. Planguage encompasses language constructs to model engineering products, and to model processes. Planguage also includes well-defined processes for some of the engineering processes, principally requirements, design, quality control, and project management.
• I designed Planguage to be agile. I specified a set of agile Planguage requirements, and evolved the design to meet these requirements. Much of the agility has evolved, as a result of the practical use of the language, and by us making immediate experiments, during client work, in adapting Planguage to needs and opportunities.
Wed 03 of May, 2006 Fri 07 of Jan., 2011 Tom Gilb13 points  9245 Information
Actions application/pdf Productivity tom gilb core ENG Oct 2010 as Published.pdf Engineering Productivity: PAPER: Engineering Productivity:
Some ways to measure it and manage it.

1 MB, pdf, 15 page paper. Nov 4 2007 Version
Abstract. There are often too few qualified engineers. I am mostly referring to product design engineers – software engineers and systems engineers. One reason we have too few is that we misuse their time so badly – we waste at least 50% of it. But when we can longer desire or afford to solve the problem by hiring or off-shoring to get more warm-bodies, we need to consider getting more productivity from the engineers we already have. There is one great advantage from that tactic – they already have plenty of experience in our company! There are several tactics to improve productivity. They can take many years to come to full effect, but a steady long term improvement, and dramatic short term improvement, should be possible. The key idea in this paper is that we can define our own productivity quantitatively – and manage the improvement of it quite systematically. Your own definition of productivity demands several simultaneous dimensions of productivity. The definition of productivity also requires substantial tailoring to your organization, and to its current environment. I am going to assert that the best short term measure of engineering productivity is agreed value (requirements) delivered; and the best long term measure of engineering productivity is stakeholder benefits actually delivered.
Sun 04 of Nov., 2007 Thu 25 of Nov., 2010 Tom Gilb13 points  8754 Information
Actions application/pdf Agile Values Paper Published agilerecord_04_Gilb_Brodie.pdf Value for Value Part 2 of 2 Gilb's Revised Agile principles and Values
as published in Agilerecord.com Number 4 2010
Thu 04 of Nov., 2010 Thu 04 of Nov., 2010 Tom Gilb13 points  8112 Information
Actions application/pdf Gilb What is Wrong with Requirements JSEA20100900001_25626313.pdf What’s Wrong with Requirements Specification? Journal of Sw Eng & Appl Sept 2010 J. Software Engineering & Applications, 2010, 3, 827-838
doi:10.4236/jsea.2010.39096 Published Online September 2010 (http://www.SciRP.org/journal/jsea)
Copyright © 2010 SciRes. JSEA
What’s Wrong with Requirements Specification?
An Analysis of the Fundamental Failings of
Conventional Thinking about Software
Requirements, and Some Suggestions for
Getting it Right
Tom Gilb
Result Planning Limited, Norway and UK.
Email: Tom@Gilb.com
We know many of our IT projects fail and disappoint. The poor state of requirements methods and practice is frequently
stated as a factor for IT project failure. In this paper, I discuss what I believe is the fundamental cause: we think like
programmers, not engineers and managers. We do not concentrate on value delivery, but instead on functions, on
use-cases and on code delivery. Further, management is not taking its responsibility to make things better. In this paper,
ten practical key principles are proposed, which aim to improve the quality of requirements specification.
Tue 19 of Oct., 2010 Tue 19 of Oct., 2010 Tom Gilb13 points  10854 Information
Actions application/pdf Verdifokus i prosjektstyring-Kai Gilb-ProjectPlace.pdf Verdifokus i prosjektstyring PAPER: in Norwegian.
Value Management: En enkel og smidig verdifokusert utviklingsprosess
Value Management blir brukt til å lede smidige utviklingsgrupper og andre typer utviklings- og ingeniørgrupper slik at de prioriterer og fokuserer all utvikling mot leveranse av kritiske forretningsverdier, interessentverdier og produktverdier. I denne artikkelen vil du få et innblikk i hvordan dette gjøres og hvordan du kan gjøre det samme.
Wed 15 of Sep., 2010 Fri 24 of Sep., 2010 Kai Thomas Gilb323 points  3245 Information
Actions application/pdf Flyer-artikkel-v7Norwegian.pdf mini paper in Norwegian on Value Pro Management with course info FLYER/PAPER: a short paper in Norwegian with 5 values of Value Management and Wrong Focus (of Agile and traditional project management methods).
Thu 29 of Oct., 2009 Fri 24 of Sep., 2010 Kai Thomas Gilb323 points  3712 Information
Actions application/pdf Firm-FromWaterfallToEvo-Paper.pdf FIRM: From Waterfall to Evolutionary Development (Evo). Paper. PAPER. How we rapidly created faster, more user-friendly, and more productive software products for a competitive multi-national market.

Evolutionary development (Evo) focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper describes from a project manager’s viewpoint, the positive experiences that one organization rapidly achieved on switching from using the Waterfall method to Evo. Major benefit came from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality.

Authors: Trond Johansen - FIRM, Tom Gilb, Kai Gilb
Wed 03 of May, 2006 Thu 23 of Sep., 2010 Tom Gilb13 points  10862 Information
Actions application/pdf The 100 Planguage Principles from CE MASTER.pdf Gilb's Planguage Principles in CE Book - with some friends too 8 MB pdf. I have primarily extracted all 100 principles from the Competitive Engineering book principles. So they are readily available.
I have added all additional principles by myself and others that occur in the book. A number of links to more detail are provided.
Feel free to Twitter!
Fri 02 of Oct., 2009 Thu 23 of Sep., 2010 Tom Gilb13 points  6131 Information
Actions application/vnd.openxmlformats-officedocument.wordprocessingml.document collection of Architecture PLanguage Concepts.docx Planguage Definition of Architecture Concepts Set of Planguage concepts related to the architecture notion.

I have long been uncomfortable with traditional 'architecture' definitions. And I've been downright disgusted with the books, papers and practices in the 'software architecture' area.

My main gripe is that they never even hint that multiple qualities and costs might be interesting! Slight oversight.

These are extracted from my private Planguage Glossary
a copy of which is at

(version April 25 2009)

and a strongly edited version of it is in the Competitive Engineering book glossary (not all concepts are there).

Should a reader wish to suggest improvements, I 'd be happy to listen.
Wed 27 of May, 2009 Thu 23 of Sep., 2010 Tom Gilb13 points  7211 Information
Actions application/pdf Agile Values Part 2 Paper for Agile Record.pdf © Gilb, Values for Value, Part 2 15/08/2010 00:07 Value-Driven Development
Principles and Values – Agility
is the Tool, Not the Master.
Part 2
“Values for Value”
Sun 15 of Aug., 2010 Sun 15 of Aug., 2010 Tom Gilb13 points  6459 Information
Actions application/pdf Gilbs Laws Gilb.com draft edition 2010.pdf Gilb’s Laws: Uncommon Sense for Planners and Decision-Makers This unchanged draft from 2006 is put on my website (Gilb.com) August 2010, so as to see interest and receive feedback (tomsgilb@gmail.com). In some parts there is no detail, only a sketch of the content. After 4 years I decided it was better to put it on the website than to keep it hidden. I often write draft manuscripts that are not published, and I also can spend 13 years between published books – trying to get the right quality. My last book (Competitive Engineering 2005) was intentionally a voluminous handbook. Now I am struggling to find a way to convey my ideas in a brief and accessible form, for many purposes. I have about 6 prototypes like this one! As Churchill noted, it is more difficult to be brief. Thu 12 of Aug., 2010 Thu 12 of Aug., 2010 Tom Gilb13 points  4139 Information
Actions application/pdf GILB whats wrong with RQTS Keynote MASTER Sep2010.pdf What's Wrong with Requirements Methods? 2nd International Workshop on Requirements Analysis GILB whats wrong with RQTS Keynote MASTER Sep2010.docx
31 pages. Basis for Slides and Keynote presentation.
Tue 27 of July, 2010 Tue 27 of July, 2010 Tom Gilb13 points  4156 Information
Actions application/pdf Gilb Agile Principles 2010 agilerecord03_Gilb.pdf Gilb’s Ten Key Agile Principles Value-Driven Development Principles and Values – Agility is the Tool, Not the Master

Part 1 of 2:
Gilb’s Ten Key Agile Principles

0.5 MB

see Values part 2 next issue
Tue 20 of July, 2010 Sun 25 of July, 2010 Tom Gilb13 points  10528 Information
Actions application/pdf Estimation or Control 2010 MASTER.pdf Estimation or Control? • A Paradigm Shift in Agile and Lean Directions. “Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets, and deadlines is possible, using feedback and change.”

So, rather than trying to improve project estimates initially, we suggest that budgets and deadlines are set based on value of delivery, and then iterative re-engineering of product and process are used to stay within acceptable bounds, or at least to get most of the expected value delivered by the acceptable deadlines and budgets.

New draft paper July 25 2010, SQP has asked for a copy.
Sun 25 of July, 2010 Sun 25 of July, 2010 Tom Gilb13 points  6150 Information
Actions application/pdf Real_QA_Polish translation.pdf Real QA Manifesto, Prawdziwe QA: Zapewnienie “Jakości i wartości” Polish Translation in C0re 2010 Sat 19 of June, 2010 Sat 19 of June, 2010 Tom Gilb13 points  3233 Information
Actions application/pdf Lever-Verdi-v1.pdf Verdifokus i Prosjektstyring PAPER: in Norwegian. Verdifokus i Prosjektstyring - Konkurranse Prinsipp, 5 Prosjektstyrings Verdier! Confirmit: en erfaringsrapport fra ett norskt firma, Bring webportal, For dere som følger de Smidige Verdier, Value Pro Management: 
En enkel Smidig Verdifokusert utviklingsprosess. Mon 02 of Nov., 2009 Mon 02 of Nov., 2009 Kai Thomas Gilb323 points  3875 Information
Actions application/pdf QUALITY MANIFESTO testingexperience01_08_Gilb.pdf A Quality Manifesto (as Published) Published in Testing Experience 01/08 March 15, 2008

This is a glossy version of the Word doc at this site

I'd be happy to have some people arrange to have this as a signed document on a website.

We have put The Real QA Manifesto - serving the aim of moving test to real QA on this site 27 May 2009. This paper takes aim at the more general Software Engineering and Systems Engineering problem of Quality. It is Not focussed on QC or QA
Thu 28 of May, 2009 Thu 28 of May, 2009 Tom Gilb13 points  5610 Information
Actions application/msword Real QA 1000 words 2009 Opinion Piece for Mike Smith.doc Real QA: Assuring the ‘Quality and Value’ Up Front, and minimizing testing effort. What should we do instead of conventional testing?
100 word paper originated for Mike Smith

see also Real QA Manifesto… http://www.gilb.com/tiki-download_file.php?fileId=285
Tue 26 of May, 2009 Tue 26 of May, 2009 Tom Gilb13 points  4848 Information
Actions application/pdf Gilb Agile Spec QC 2009 in Testing Experience March 2009.pdf Agile Specification Quality Control "Agile Specification Quality Control"
by Tom Gilb
This includes 3 case studies and detailed data collection forms and process descriptions.

initially presented at INCOSE Conference, and now edited and published in Testing Experience March 2009.
With the last issue we did have till this morning (March 13) 207,556 downloads. It is amazing.
Here is the link for you: http://www.testingexperience.com/testingexperience01_09.pdf
Fri 13 of Mar., 2009 Fri 13 of Mar., 2009 Tom Gilb13 points  4204 Information
Actions application/pdf testingexperience02_08_Gilb CORRECT VERSION.pdf Rule-Based Reviews as Published in Testing Experience
May 2008

by Tom Gilb
Thu 12 of June, 2008 Thu 12 of June, 2008 Tom Gilb13 points  4036 Information
Actions application/msword Undergraduate Basics MASTER June 19 07.doc Undergraduate Basics for Systems Engineering (SE) PAPER (Published 2007 INCOSE Conference Paper and Cutter). Updated May 5 2008 Strachey Quote.
There are some very basic things that systems engineers should be taught. These things are both fundamental and classic. They are fundamental because we can reuse them in a very wide variety of SE situations. They are classic in the sense that they have a very long usefulness half-life. They are probably useful for at least a career lifetime. When I was in my Twenties, I decided to collect, to learn and to develop these SE Basics. Now, in my Sixties, I am more than ever convinced that these fundamentals should be share with students. The fundamentals are: Principles (heuristics, laws), Measures (ways to quantify critical factors), Concepts (really useful definitions of fundamental SE ideas), and Processes (really useful SE processes). I have published these in several books and papers already. I would like to argue here why they need teaching in undergraduate systems engineering. I believe that their usefulness and longevity are demonstrated in my own work, are acknowledged by many professional colleagues and some academics, and are self-evident upon examination. Hopefully this paper can stimulate others to adopt at least the general idea, if not my exact artefacts.

Some Principles of Useful Knowledge
• UNIVERSALITY: 1. Knowledge is more useful when it applies to more circumstances
• ETERNALITY: 2. Knowledge is more worth learning if it can be applied for a long time after learning it
• VALUE: 3. Knowledge is more useful if there is a high value from applying it
• SHARING: 4. Knowledge is more useful if it can easily be shared with others
• PROOF: 5. Knowledge is useful when early feedback can prove its usefulness in practice
• SYNCHRONOUS: 6. Knowledge is more useful when it can be used together with a larger body of knowledge
• MEASURABIILITY: 7. Knowledge is more useful when the results of its application can be measured
• ACCEPTANCE: 8. Knowledge is more useful when it is widely accepted in your culture.
• COST: 9. Knowledge is more useful when the cost of applying it is low.
• GENERATION: 10. Knowledge is more useful when is can be used to generate even more useful knowledge.

2.9 MB Word

A set of Powerpoint slides is available on request.
Tue 10 of Oct., 2006 Mon 05 of May, 2008 Tom Gilb13 points  5537 Information
Actions application/pdf Decomposition April 4 2008.pdf Decomposition of Projects - How to design small incremental result steps PAPER. Abstract MAJOR EDIT UPGRADE 5 APRIL 2008
• The basic premise of iterative, incremental and evolutionary project management [Larman 03 MG] is that a project is divided into early, frequent and short duration delivery steps.
• One basic premise of these methods is that each step will attempt to deliver some real value to stakeholders.
• It is not difficult to envisage steps of construction for a system; the difficulty is when a step has to deliver something of value to stakeholders, in particular to end users.
• This paper will give some teachable guidelines, policies and principles for decomposition. It will also give short examples from practical experience.
Wed 03 of May, 2006 Sat 05 of Apr., 2008 Tom Gilb13 points  7057 Information
Actions application/pdf Gilb and Brodie QFD AND IE NOV 22 07 Neutral MASTER.pdf QFD What's Wrong PAPER2nd MAJOR UPDATE November 22 2007:
How problems with Quality Function Deployment's (QFD's) House of Quality (HoQ) can be addressed by applying some concepts of Impact Estimation (IE)

By Gilb and Brodie

This version goes much deeper than previous versions.

Quality Function Deployment (QFD) is widely taught as a method for analyzing the relationship between designs and related qualities. I admit that the structure of analysis – multiple design correlated to multiple quality and performance requirements – is a very healthy and necessary analysis process. My problem with QFD is that there are too many permitted specification notations, that are badly defined, subjective, and coarse. The result is that the potential value of such a many-design to many-requirements analysis is in severe danger of failing to perform its primary function – giving us a useful understanding of the power of design to satisfy a set of requirements.
Sat 09 of Dec, 2006 Thu 22 of Nov., 2007 Tom Gilb13 points  7606 Information
Actions application/msword Why July 26 Gilb.com version.doc Why? (Manager Book) BOOK: Why?
is an experimental book I am writing. I am trying to find a way of writing about my practiced management methods, for non-technical managers (CTO, CIO, CEO, Programme Managers, possibly Project Managers). This is the 6th parallel experiment!
For the moment (26 July 07) there is a Chapter 1 and an outline of the rest. I'd appreciate feedback on it this summer.
Thu 26 of July, 2007 Mon 05 of Nov., 2007 Tom Gilb13 points  4353 Information
Actions application/pdf Quality Manifesto for Systems Engineering 2008 MASTER.pdf Quality Manifesto PAPER: Quality Manifesto:
Software Quality is a Systems Engineering Job

PAPER: 16 Pages. Major rewrite of core paper I had on this site since Summer 2007.

The main idea with this paper is to wake up software engineers, and maybe some systems engineers, about quality. The software engineers (sorry, ‘softcrafters’) seem to think there is only one type of quality (lack of bugs), and only one place where bugs are found (in programs). My main point here is that the quality question is much broader in scope. The only way to get total necessary quality in software, is to treat the problem like a mature systems engineer. That means to recognize all critically interesting types of quality for your system. It means to take an architecture and engineering approach to delivering necessary quality. It means to stop being so computer program-centric, and to realize that even in the software world, there a lot more design domains than programs. And the software world is intimately entwined with the people and hardware world, and cannot simply try to solve their quality problems in splendid isolation. I offer some principles to bring out these points.

Tue 30 of Oct., 2007 Mon 05 of Nov., 2007 Tom Gilb13 points  4519 Information
Actions application/pdf Engineering the Review Process MASTER.pdf Engineer Your Review Process PAPER: Engineer Your Review Process:
Some guidelines for engineering your engineering review processes for maximum efficiency

15 Page paper. Completed Nov 2 2007

You can tailor your various review processes so as to maximize effectiveness for purpose, at minimum costs. I call this review efficiency. This presumes you are willing and able to state a set of clear objectives for your various reviews. Then we can design review strategies to try to meet those objectives. In addition to corporate level review design, you need to design-in the freedom locally, at the project level, and the individual review level, to dynamically adjust or optimize the review process for local conditions and local requirements.
Fri 02 of Nov., 2007 Mon 05 of Nov., 2007 Tom Gilb13 points  8942 Information
Actions application/pdf Making Metrics Practical - INCOSE.pdf Making Metrics Practical PAPER: Completed 28 Oct 2007, about 17 pages, pdf

Making Metrics More Practical in Systems Engineering: Fundamental Principles for Failure and for Success.

Quantification is the essence of real engineering. Engineering is good at quantifying many traditional aspects of systems. But there are weak points. For example in quantification of emerging ‘soft’ aspects of systems like usability and security, and within the emerging sub-disciplines of software and data. We need to use the quantification tool in all critical aspects of of our systems, not just in traditional sectors. This paper will explore the extension and strengthening for the metrics discipline in the weakest areas of systems engineering.
Sun 28 of Oct., 2007 Mon 05 of Nov., 2007 Tom Gilb13 points  7794 Information
Actions application/pdf Maintainability in Software Engineering.pdf Designing Maintainability in Software Engineering PAPER: Designing Maintainability in Software Engineering:
a Quantified Approach.
Tom Gilb
Software system maintenance costs are a substantial part of the life cycle costs. They can easily steal all available effort away from new development. I believe that this is because maintainability is as good as never systematically engineered into the software. Our so-called software architects bear a primary responsibility for this, but they do not engineer to targets. They just throw in customs and habits that seem appropriate. We need to define our maintainability requirements quantitatively, set investment targets that will pay off, pursue long-term engineered improvement of the systems, and then ‘architect’ and ‘engineer’ the resulting system. Other disciplines within systems engineering may already in principle understand this discipline, some may not understand it, some may simply not apply the engineering understanding that is out there
Fri 26 of Oct., 2007 Fri 26 of Oct., 2007 Tom Gilb13 points  25611 Information
Actions application/pdf Value Delivery in Systems Engineering.pdf Value Delivery in Systems Engineering PAPER (new 25 Oct 07) 16 Pages. 1.5 MB
"Value Delivery in Systems Engineering"
By Tom Gilb

Sponsors who order and pay for systems engineering projects, must justify their money spent based on the expected consequential effects (hereafter called ‘value’) of the systems. At one extreme if a system met all technical requirements, but was never deployed in practice – it might have no possibility of delivering the value expected. This paper will argue that the definition of the expected value should form an integral part of the high level requirements of the system. It will argue that we need specific design and implementation planning to improve the probability that the value will be delivered and will be maintained.
Thu 25 of Oct., 2007 Thu 25 of Oct., 2007 Tom Gilb13 points  7686 Information
Actions application/pdf Requirement Relationships.pdf Requirement Relationships PAPER: Requirement Relationships: A Theory, some Principles, and a Practical Approach.

Drafted initially Sunday, 1 October 2006. © Tom@Gilb.com, 2006

This paper will argue that the ‘conventional ideas’ [NASA 97, INCOSE01, Raytheon06] of how requirements relate to other entities is unnecessarily weak in relation to the complex demands placed on a systems engineering task. We will argue that it would improve systems engineering requirements practice if we were to invest substantially more in effort to determine, and to specify, at least a dozen or two useful relationships for each requirement. We will argue that the nature or variety of these relationships should but relatively unlimited (by a standard or tool), and should be whatever is useful to the engineering work. In addition, we need to keep the requirement relationship specifications, together with the core requirement itself, in a reusable requirement ‘object’ (a mini database about each discrete requirement, which is tool independent). Systematic rules and conventions, like those illustrated, will enable more-automated use (analysis, presentation, consistency checking, reuse) of requirements, even with simple text string searching.
Sun 01 of Oct., 2006 Fri 24 of Aug., 2007 Tom Gilb13 points  9075 Information
Actions application/pdf STSC CrossTalk - The 10 Most Powerful Principles for Quality in Software and Sof The 10 Most Powerful Principles for Quality in PAPER: The 10 Most Powerful Principles for Quality in Software and Software Organizations.

The software industry knows it has a problem: The industry's maturity level with
respect to "numbers" is known to be poor. While solutions abound, knowing which solutions
work is the big question. What are the most fundamental underlying principles in successful
projects? What can be done right now? The first step is to recognize that all your quality
requirements can and should be specified numerically. This does not mean "counting bugs."
It means quantifying qualities such as security, portability, adaptability, maintainability,
robustness, usability, reliability, and performance. This article presents 10 powerful principles
to improve quality that are not widely taught or appreciated. They are based on ideas of
measurement, quantification, and feedback.

Published in

See corresponding set of slides at this website.
Tue 08 of May, 2007 Tue 08 of May, 2007 Tom Gilb13 points  9189 Information
Actions application/msword 1Virtual Team MASTER.doc Virtual Team Communication: PAPER, UNPUBLISHED.
Principles of Virtual Team Communication:
Manage By Results, Not Effort and Tasks
Quantify Key Results
Evolve Delivery of Key Results, Early and Frequently
Measure Real Progress towards Key Results
Architecture Constraints but Design Freedom
Measurable Specification Quality Control
Reward Team for Results
Avoid Unrealistic Models and Tools
Write Everything, Forget Oral Communication
Learn Rapidly, Change Rapidly, Delivery Value Rapidly
Version 1.1 2 small typos corrected 12 Dec 2006
Mon 06 of Nov., 2006 Tue 12 of Dec, 2006 Tom Gilb13 points  4392 Information
Actions application/msword Requirements for Outsourcing MASTER.doc Requirements for Outsourcing PAPER (Unpublished)
Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.
I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.

Outsourcing Requirements Principles.

Here is a set of principles for Requirements for Outsourcing:

1. If anything can be misunderstood, it probably will be.
2. Writers Are Responsible for Readers Wrong Renditions
3. Assume Nothing, Specify Everything
4. Too Much is Safer than Too Little
5. If They ask a question, document and integrate the answer
6. Quality Control before sending
7. Evolve Requirement Delivery
8. Quantify Quality
9. Constrain explicitly
10. Connect relationships
Thu 12 of Oct., 2006 Thu 12 of Oct., 2006 Tom Gilb13 points  5434 Information
Actions application/msword The Ten Most Powerful Systems Engineering Heuristics.doc 10 Powerful Systems Engineering Heuristics PAPER (Unpublished)
I would like to suggest some fundamental heuristics that characterize the essential spirit of systems engineering. Heuristics that can be used to teach essential engineering tactics.

The heuristics:

1. All designs are valid if they deliver the performance within the constraints.

2. System Level Architecture optimizes the specialist disciplines, and constrains them.

3. We don’t really know what works until we try it.

4. System Models cannot be relied on, and their only justification is when there is no more realistic way to economically represent the future system.

5. Systems need to be built to tolerate change and expansion beyond current stakeholder needs.

6. System Stakeholders are one more than you know about; and known stakeholders have at least one more need than you know about now.

7. You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term, over current systems.

8. The most critical requirements and critical designs are probably soft, not hard. And most ‘engineers’ are not social engineers.

9. Don’t ever try to build it all at once – evolve the system based on highest value early, and rapid learning about realities.

10. Manage the details through focus on high-level measurable objectives, not through bureaucracy.

11. Contractors will deliver better value for money, if paid only for value delivered, not for work completed.

12. Risks are impossible to detail completely and correctly, but can be controlled by frequent and early numeric feedback and change – as well as creating openness for necessary change in architecture, contracts, and relationships.
Drafted 8 Oct 2006
Sun 08 of Oct., 2006 Sun 08 of Oct., 2006 Tom Gilb13 points  11679 Information
Actions application/pdf Design Principles INCOSE 2006 GILB MASTER.pdf Ten Design Principles: Some implications for multidimensional quantification of design impacts on requirements PAPER.

By Tom Gilb

See corresponding ppt slides from INCOSE July 2006 here.

Abstract. Designs have multiple impacts on requirements, and can only be fully understood in terms of their impact on requirements. In other words, the contributions of designs towards the set of performance and resource requirements must be considered, when evaluating designs, in addition to their contributions to the function requirements.
This paper sets out ten principles, and outlines their various implications for design. These are basic ideas about designs, which we should explicitly acknowledge, teach and use in practice. I would be surprised to find any serious disagreement about these principles, but I would be surprised to find serious conscious practice and teaching of them today!
Wed 03 of May, 2006 Tue 11 of July, 2006 Tom Gilb13 points  4930 Information
Actions application/pdf How Good Is a Process BY GILB.pdf How Good Is A Process? Evaluating Engineering Processes’ Efficiency PAPER. By Tom Gilb

(see corresponding PPT Slides here)

Abstract. What is ‘best practice’ for an engineering process? How good is your current set of development, maintenance and service processes? How can we decide exactly which processes
we are going to adopt in our organization, for example in a CMMI implementation?
It is the assertion of this paper that such questions are often dealt with without explicit and
quantified regard to the full set of real, and well-defined business needs, as well as often not
taking into consideration the current processes and the issues of changing them. We too often
carry out and change processes because we are told to, not because there is a clearly defined need
to do so.

A rational evaluation process would continuously match our continuously evolving set of
business, technical and engineering objectives to a set of engineering processes. It would do so
on a multi-dimensional and numeric basis:
• We would quantify our engineering process objectives.
• We would estimate the impacts we can expect from new and changed engineering
• We would measure in practice the impact of new processes.
• We would decide which processes are good and which are bad, based entirely on how
they worked in our particular environment.

I am sure the reader agrees with the desirability of numeric principles, even if they are in
doubt about how to practice them. However, how many people can show that their organization
operates on this rational principle? What is often missing is the ability to articulate engineering
organizational objectives as quantified goals. My observation of a large number of multinational
engineering organizations convinces me that even the best and most senior managers are not
trained in how to do this. The good news is that given a little help and some examples, they are
willing to define their needs quantitatively. The aim of this paper is to outline how to quantify
such objectives and to outline how to use such quantification to achieve better processes.
Wed 03 of May, 2006 Tue 11 of July, 2006 Tom Gilb13 points  4739 Information
Actions application/pdf Competitive Systems Engineering .pdf Competitive Product Engineering: 10 Powerful Principles for winning product leadership, through advanced systems engineering PAPER. • Abstract:
Some product developers are still trapped thinking
narrowly about their technology – they do not have enough
customer focus, and they do not get good enough feedback
from the customer and support team ‘real world’. These
principles will help refocus them.
Wed 03 of May, 2006 Mon 29 of May, 2006 Tom Gilb13 points  6404 Information
Actions application/msword Software Contracting ideas Initial and Operational Decisions.doc Software Outsourcing Contracting: What should be in the contract and what should not. PAPER:
New 26 May 2006.
Prepared initially for Norwegian Computer Society lecture 12 June 2006 Oslo.

• This paper takes the point of view of the customer. But I hope the suppliers will be interested in some more competitive and satisfactory ways to offer services to their customers and prospects.

• The major problem for both parties to the contract is how to define things clearly, in spite of the fact that there are many future unknowns.

• The major problem is that far too many outsource relationships are outright failures, or are partial failures.
• So, the major premise of this paper is how to avoid total failure, how to reduce failure, or at least detect failures early, and stop the bleeding.

• The major premise is that we need to define the results we are expecting in quantified and testable ways.

• The second major premise is that we cannot actually do this in the contract. The contract must however serve as a framework for such decisions and agreements, as the work progresses.

• I assume that any contract format, or contract standard, can be used for these ideas. They are a supplement, rather than a change to the contract templates. But, that some of the ideas could be more explicitly treated in public contracting templates.

Note: this paper can be viewed in the light of my earlier No Cure No Pay paper and slides. It preaches the same quantified results and Evo message, but is focussed on the contractual relationship possibilities themselves.
Fri 26 of May, 2006 Fri 26 of May, 2006 Tom Gilb13 points  4156 Information
Actions application/msword Nasscom Keynote MASTER.doc Competitive Engineering:12 Powerful Practices for winning more profitable business for Indian Corporations PAPER and SLIDES URL

Here is the paper and you can get the slides from the NASSCOM site below. (about 12 MB)

[PPT] Slide 1 Competitive Engineering: 12 Powerful Practices for winning ...
File Format: Microsoft Powerpoint - View as HTML
No Cure No Pay: How to contract for Software Services on a No Cure No Pay basis ... and give a tutorial at the NASSCOM conference (August 2005, Bangalore). ...


Wed 24 of May, 2006 Wed 24 of May, 2006 Tom Gilb13 points  4102 Information
Actions application/pdf No Cure No Pay.pdf No Cure No Pay:How to Contract for Software Services PAPER. Abstract. 50% of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid!
My suggestion is simple. Pay only when defined results are provably delivered. This requires several things:
• Contracts that release payment only for meaningful results;
• The ability to define those results, particularly qualitative ones, and particularly the organizational ones;
• The ability to deliver those results incrementally, thus proving capability at early stages and continuously.
Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.

http://roots.dnd.no/repository/05_Gilb_Tom_No_Cure_No_Pay.pdf contains the slides

and (about 12 MB ppt download)
advice for Indian Organizations.
Wed 03 of May, 2006 Wed 24 of May, 2006 Tom Gilb13 points  11236 Information
Actions application/pdf 12 TOUGH QUESTIONS May06.pdf 12 Tough Questions PAPER. Managers don't ask tough enough questions about written material. I know because I have spent decades watching them fail to ask the questions which would have exposed the proposals as dangerous or not well thought out. I have to conclude that managers need training to ask these questions. But I forgive any reader who thinks that asking such questions is just good common sense. It is. The questions all refer to a larger method I teach; "Requirements Driven Management" and documentation in my past ("Principles of Software Engineering Management") and future books (RDM, Evo, Requirements Engineering (all working titles). But these books exceed 400 pages, the courses take several days. The patience of top managers for such detail is necessarily limited in a high pressure world. So this paper is offered as a simplification and an appetizer. If you want more substance and detail, it exists. If this alone is useful, be happy! Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  5728 Information
Actions application/pdf IEEESWAr.pdf Software Inspections are not for quality, PAPER. Software Inspections were developed at IBM and published in 1974-76 [1] more than a quarter century has passed and it is time to reassess them. Most literature on the subject is rooted in the initial IBM practices. Most professionals have an incomplete understanding of the traditional inspection and why it succeeded at IBM and elsewhere. But time and experience have led to many new practices which make Inspection more economic and useful than originally envisaged. The bottom line is that I believe that it is more relevant to view Inspection as a way to control the economic aspects of software engineering, rather than a way to get 'quality' by early defect removal. Quality needs to be multidimensional, specified in quantified requirements and architected, engineered and designed into software products. Inspection needs to be used to monitor the entire software engineering process. Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  6176 Information
Actions application/pdf 10MostPo.pdf The Ten Most Powerful Principles for Quality PAPER. Software knows it has a problem. Solutions abound. But which solutions work? What are the most fundamental underlying principles we can observe behind those successful solutions? Can these principles guide us to select successful solutions and avoid time wasters? One hint: in Observing successful software organizations in the US, the dominant principle seems to be feedback and control. Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  3934 Information
Actions application/pdf Risk.pdf Risk Management: A practical toolkit for identifying, analyzing and coping with project risks. PAPER. Risk management must be fully integrated into all the development and maintenance processes for systems. It involves more than applying risk assessment methods to identify and evaluate system risks. To explain this broad approach to risk management, this paper discusses the way in which Competitive Engineering and Planguage methods contribute to handling risks. Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  5335 Information
Actions application/msword PRACTICAL CREATIVITY MASTER.doc Practical Purposeful Creativity PAPER. This paper was invited, written, and published by a special issue of a Psychological Journal . It is attempting to break with conventional academic thinking about the subject .
This paper is written as an invited contribution to a book “Creativity, Innovation and Cooperation” (Springer) and a special issue of “AI & Society: the Journal of Human-Centred Systems and machine Intelligence”. The editor is Robert C. Muller (Fax +44-491-579750). Published around 1992.
Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  6634 Information
Actions application/pdf Crosstalk Impact Est Art DEC98.pdf Impact Estimation Tables:Understanding Complex Technology Quantitatively PAPER. How good is your design suggestion? Does anybody else really understand why you think the technology you suggest is such a great idea? Would you like to know how to shoot down those dumb ideas that your colleagues and those consultants manage to entice your managers with? Would you like a killer approach to prove your technical expertise to the world? We may have it right here! Impact Estimation (IE) Tables will allow you to analyze any technical or organizational idea in relation to requirements and costs. It's a method, I've developed over the last twenty years and it works! To give one example, shortly after we taught the idea to a manufacturing group, they declared it was worth a million dollars! Using IE for the first time, they presented a bid for project money to management and got the full budget they requested; $1 million more than they had expected!
Crosstalk Dec 1998 Version
Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  5975 Information
Actions application/pdf Real Requirements INCOSE Final.pdf Real Requirements: How to find out what the requirements really are. PAPER. This paper focusses on how to determine and specify the stakeholders real requirments (like Security Levels), as opposed to the ones they might tell you they have (like a password design).

Author: Tom Gilb, 2005, INCOSE Rochester NY Oral Paper
Mon 10 of Apr., 2006 Sun 07 of May, 2006 Tom Gilb13 points  7592 Information
Actions application/pdf Quantifying Stakeholder Values INCOSE06.pdf Quantifying Stakeholder Values PAPER. This paper focusses on how to determine project stakeholder needs/requirements/values. It shows how to use Planguage to specify them quantitatively. This is the basis for deriving corresponding and supporting product qualities.

Abstract: Here are some questions we need to ask about stakeholder value. How can we determine the overall value of a system? How is this value related to the performance characteristics of the system? How can we engineer the value to meet stakeholder expectations? How can we test and measure the real value? Can we contract for system payment by value, or do we have to restrict ourselves to payment for performance levels? Is there any way to quantify the overall value of a system as a function of a set of system attributes?
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  9750 Information
Actions application/pdf Plicons A Graphic Language for Systems Engineering.pdf Plicons: A Graphic Planning Language for Systems Engineering PAPER. Abstract:
• A Pictorial language (Planguage Icons = Plicons) for representing systems engineering problems (requirements) and solutions (designs) has been developed, and continues development, by the author. It differs from most all other published software engineering and systems engineering languages in several key respects.
• The main, but not only, differentiating characteristic is that it allows us to model quantified system performance properties and resources graphically; whereas most all other graphic languages are limited to things like functions, logic flow, use cases; and invariably avoid any representation at all for quantifiable qualities and costs.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5570 Information
Actions application/pdf Quantifying Security.pdf Quantifying Security: How to specify security requirements in a quantified way PAPER. Introduction.
• Security is a system quality. It can be dealt with in the same way that all other critical system qualities need to be dealt with – quantitatively, and systematically. We suggest that the planning language, Planguage, as defined in Competitive Engineering [Gilb05] is a strong and innovative framework for dealing with security in a systematic way. In fact even those who are not just interested in security, but in the larger set of system qualities, may be interested in this paper as an example of what one can do with other qualities.
• The theme of this paper is summarized by the following:
o Security is a complex quality: that means it needs to be defined by a set of measures, not a single measure.
o A single elementary measure of quality will need to be applied to a wide variety of conditions regarding when, where and for which events, in order to be made intelligible for various levels of analytical benchmarks, for constraint levels and target levels of security.
o The security designs, to meet security requirement levels, must all be evaluated by both quantitative estimate and direct measure, to see if they help meet the security target levels. In addition they must not harm other performance or quality target levels, other constraints, and they must fit within the resource budgets.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5901 Information
Actions application/pdf Choice and Priority using Planguage.pdf Choice and Priority Using Planguage: A wide variety of specification devices and analytical tools. PAPER. Abstract:
• Planguage (the Planning language defined in Competitive
Engineering [CE]) has a variety of methods and tools to help us
identify and choose candidates for solving a defined problem.
• There is no single method or tactic for making a ‘best’ choice.
• There is no concept of finding a ‘perfect choice’ either.
• By rational application of a suitable set of methods, within the
time and resources available, a candidate solution can be found,
which is probably one of the most satisfactory available. It is
probably satisfactory enough. And, we will be able to say
something about the solution’s risks, uncertainties, issues,
dependencies, and side effects.
• We can substantially improve the probability of successful
choices. Only in some unreal world, if we had infinite time,
infinite knowledge, and static circumstances, could we hope to
make a ‘perfect’ choice.
• In the competitive world, the necessity is making very good
choices rapidly, under conditions of uncertainty, and risk of
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  6911 Information
Actions application/pdf Decision Rationale.pdf Decision Rationale: A Quantified Decision-Making Basis Using Planguage PAPER. Abstract:
• Decision rationale are widely discussed in the literature for design
decisions [example Burge]. To a far lesser degree for requirements
decisions [example Ramesh95]. And practically not at all for
justification of Evolutionary project steps or iterative cycle selection
[exceptions see Evo in Larman03].
• It is my contention that all software engineering, systems
engineering, and management planning specifications can benefit
from a variety of forms of rationale. Even specification types not
mentioned above, such as source code and test plans can benefit.
• At one extreme all plan specifications, and even source code and
test cases, can all be viewed as types of ‘design’. So what applies to
any type of design applies to them; even though they be, from
another viewpoint, classified as something else.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  6294 Information
Actions application/pdf Rich Requirement Specs.pdf Rich Requirement Specs:The use of Planguage to clarify requirements. PAPER. Abstract:
I believe that most requirements specifications in practice are very poor in clarity, and in
content. I believe that in addition to tackling the clarity problem by a variety of rich
specification devices, we need to make a requirement specification ‘work harder’ to
satisfy a large number of needs by adding ‘background’ to the requirement. The needs I
am referring to include: prioritization, risk management, change management,
presentation, justification, testability, integration, quality control, and other purposes. To
do this I have, over the years developed a requirement specification language, as a subset
of my Planning Language (Planguage). This is has been developed by practical need in
international industry over decades, and supplemented with some recent ideas. The more
detailed version of the Requirements Language is documented in my book Competitive
Engineering, which is a handbook defining concepts rigorously. This paper will give an
overview of the conceptual basis and some detail as a sample. By ‘rich’ I mean
substantially more detail for each requirement than is usual. By ‘background’ I mean
information related to the requirement that is not the requirement itself.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  6329 Information
Actions application/pdf Rule Based Design Reviews.pdf Rule-Based Design Reviews:Objective Design Reviews and Using Evolutionary Project Methods PAPER. Abstract. Design reviews would benefit from the support of formal rules. By the use of relevant
rules, it should be possible to ensure prior to a review that all the relevant information for a
review is present in the design specifications, and that all the minimum review criteria are met.
This will ensure management time is not wasted and aid better decision-making. This paper
recommends that the Specification Quality Control (SQC) method be used to do this additional
quality control.
In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the
design review process.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5223 Information
Actions application/pdf Architecture a view.pdf Systems Architecture:A View Based on Multiple PAPER. Abstract. In order to properly support the systems engineering process, the systems engineering
profession needs to consciously adopt a more productive view of systems architecture. Many
existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’
The focus needs to be shifted to the impact on requirements.
What is ‘Architecture?’ OK, we know what conventional ‘Architecture’ is in the context of the
structure of buildings. So, the question is, ‘What is ‘Systems Architecture’ in the systems
engineering context?’ There are many different opinions, and many standard definitions. But I
want to argue that most of these are missing some essential truths about systems architecture.
They seem to universally miss the point that architecture is addressing system requirements:
especially the aim to achieve the required performance and resource levels (a set of defined
targets and constraints). Instead, they get hung up on the nature of the solutions (and narrow
ideas of those solutions, such as ‘structures’).
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  9230 Information
Current agile methods could benefit from using a more quantified approach across the entire
implementation process (that is, throughout development, production and delivery). The main
benefits of adopting such an approach include improved communication of the requirements and,
better support for feedback and progress tracking.
This chapter first discusses the benefits of quantification, then outlines a proposed approach
(Planguage) and, finally describes an example of its successful use (a case study of the
‘Confirmit’ product within a Norwegian organization, ‘FIRM’).
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  6194 Information
Actions application/pdf Interview--Tom Gilb-2 INDIA 2006.pdf GREAT CHANGE WITH EVOLUTION PAPER - INTERVIEW WITH TOM GILB.
India April 2006

There are very few IT consultants who are known across all continents. Tom Gilb is one of
those who have an enviable reputation as a management and software guru. In an exclusive
interview with ‘i.t.’ magazine’s Malovika Rao, Gilb spoke at length, sharing his success mantra
for IT projects.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  4097 Information
Actions application/pdf Why isn\'t Software Trustworthy IT Cutter 2006.pdf Why Aren’t Software Systems Trustworthy? PAPER. IT Cutter Journal Paper 2006

Shortened Version of full paper

System Trustworthiness: defined:
A defined system is ‘trustworthy’ from the point of view of a defined
stakeholder or user. The same system states may be evaluated as
‘untrustworthy’ from some points of view, and ‘trustworthy’ by others.

Trustworthiness is a relative point of view, not a system state independent
of such points of view. The ‘Trustworthiness View’ is subjective. That is,
any given observer is at liberty to define a set of system states they
consider trustworthy or untrustworthy. We cannot prevent them from having
those perceptions.
We can identify their perceptions, make formal agreements about
their perceptions, and attempt to engineer and operate a system to be
trustworthy in accordance with those stakeholders we care to serve. We
can also choose to ignore, or give lower priority to, the perceptions of
stakeholders that we do not care to serve, to prioritize, or who are
uneconomic; or who have requirements outside of the state of the art.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5036 Information
Actions application/pdf CAI tomgilbinterview1.pdf What are Evolutionary (EVO) Development Methods? PAPER - INTERVIEW. CAI Interview with Tom Gilb
21 Feb 2006 See CAI newsletter Gilb Evo Interview


Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  3543 Information
Actions application/pdf Agile Spec QC INCOSE Final.pdf Agile Specification Quality Control: Shifting emphasis from cleanup to sampling defects PAPER Abstract. Traditional Inspection is often uneconomic and ties up valuable staff resources.
Shifting the emphasis from cleanup (that is, from identifying defects and then removing them), to
merely sampling the defect level of specifications, produces significant benefits. It enables the
quality level of specifications to be determined more rapidly. Consequently, the QC can be
carried out more frequently. Systems and software engineers rapidly learn, through SQC
feedback, to take standards seriously, which in turn reduces defect injection. Further, by
analyzing where/how the defects occur continuous process improvement can be supported.

Copyright © 2005 by Tom Gilb. Published and used by INCOSE with permission.
Presented at INCOSE 2005 Rochester NY
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5655 Information
Actions application/pdf Design Evaluation INCOSE Final.pdf Design Evaluation: Estimating Multiple Critical Performance and Cost Impacts of Designs PAPER. Abstract: How should we evaluate someone’s design suggestion? Is gut feel and experience
enough for most cases? Is anything more substantial and systematic possible? This paper outlines
a process for design evaluation, which assesses the impacts of designs towards meeting
quantified requirements. The design evaluation process is viewed as consisting of a series of
design filters.

Copyright © 2005 by Tom Gilb. Published and used by INCOSE with permission.
Presented at INCOSE 2005 Rochester NY
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  4352 Information
Actions application/pdf Evo Principles.pdf Fundamental Principles of Evolutionary Project Management PAPER. Abstract: The Evolutionary Project Management method – abbreviated Evo – is arguably the
best systems engineering project management method (Larman and Basili 2003). However, it is
also probably the least known and the least discussed, so the aim of this paper is to shed some
light on it. Evo is particularly good at dealing with large, complex, and innovative systems – it
does so by breaking down the project into a series of numerous small incremental steps. Each
Evo step is both an opportunity to deliver some useful results to the stakeholders, and an
opportunity to learn more about the system.
Let’s discuss Evo by outlining its ten basic principles. They are as follows:
E1: Decompose by performance results and stakeholders;
E2: Do high-risk steps early, learn how ‘unknowns’ really perform;
E3: Focus on improving your most valuable performance objectives first;
E4: Base your early evolution on existing frameworks and stakeholders;
E5: Design to cost dynamically;
E6: Design to performance dynamically;
E7: Invest in an open-ended architecture early on;
E8: Motivate your team by rewarding results;
E9: Prioritize changes by value, not place in queue;
E10: Learn fast, change fast, adapt to reality fast.

Presented at INCOSE 2005 Rochester NY
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  9069 Information
Actions application/pdf Managing Priorities May 16 2234.pdf Managing Priorities: A Key to Systematic Decision-Making PAPER. By Tom Gilb and Mark Maier

Abstract. A central concern of systems engineering is selecting the most preferred alternatives
for implementation from among competing options. The selection process is sometimes called
tradeoff analysis, and is often built on the methods of decision analysis and utility theory. The
process can be loosely divided into two parts, a first part in which one determines the relative
priority of various requirements, and a second part, a design selection phase, in which
alternatives are compared, and the preferred alternatives chosen.
This paper discusses the means of determining the priority order for implementing system
changes. It also outlines the implications on the selection process of evolutionary systems

Tom Gilb
Mark W. Maier

Copyright © 2005 Tom Gilb and Mark Maier. Used by Permission of the authors by INCOSE.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  8930 Information
Actions application/pdf Project Failure Prevention.pdf Project Failure Prevention: 10 Principles for Project Control PAPER. Abstract: It is now well-known and well-documented that far too many projects fail totally or
partially, both in engineering generally (Morris 1998) and software engineering (Neill and
Laplante 2003). I think everybody has some opinions about this. I do too, and in this paper I
offer some of my opinions, and I hope to lend some originality to the discussion. As an
international consultant for decades, involved in a wide range of projects, and involved in saving
many ‘almost failed’ projects, my basic premises in this paper are as follows:
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  5596 Information

Key words: evolutionary project
management, peer review, quality
control of specifications, review,
review standards

It is known that most projects are a partial or total failure, and
few are totally successful (Morris 1994; Taylor 2001; Johnson
2001). A key reason for this lack of success is the failure of
design reviews. In other words, designs must have been
approved that were in some way inappropriate.
Based on reading the literature and participating in numer-
ous requirement and design inspections in many different
industries internationally, I fear that most design reviews are
carried out:
• On poorly written design specifications (in the sense
that the design specifications lack sufficient detail for
them to be safely evaluated)
• Using highly polluted requirement specifications
(requirements being the basis for evaluating any
I find it unacceptable that design reviewers are given no
quantified knowledgeof the quality of the design specification,
or of the estimated ability of the design(s) to impact on the
requirements (that is, the system performance and costs). A
common underlying problem is that specification of design is
carried out on the basis of inadequate design standards. I sug-
gest the following remedies:
• A high, defined standard of requirements should be met
before entry to the design process itself is permitted.
• Design specification should initially pass quality control
against design specification rules to ensure the designs
are clearly and fully described.
• Designs should be specified in enough detail to accu-
rately estimate their dominant performance and cost
• A set of designs should be seen to credibly and numeri-
cally contribute to meeting the requirements (the set
of performance targets within the resource budgets).
• The design review process should work in the context
of evolutionary cycles of design (for example, in
50 steps), and not operate on a large monolithic total
initial design set.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  7460 Information
Actions application/pdf Adding Stakeholder Metrics to IT Projects citj0704TG.pdf The Agile Evo Method: Adding Stakeholder Metrics to Agile Projects PAPER. In this article, I present a
simple, updated “agile,” evolutionary project management
process called 'Evo', and explain
the benefits of a more focused,
quantified approach.

Published in Cutter IT Journal Vol. 17 NO. 1
July 2004
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  4990 Information
Actions application/pdf Agile SQC CutterVol 18 No1 2005.pdf Agile Specification Quality Control PAPER (5 Page version, Cutter IT Journal , January 2005)

If we do specification inspections
able for some: about one hour of
effort, per page checked, per engi-
neer. The harvest, if we are skilled,
is between
defects identified. The rest are not
found yet, but they will be found
inthe final product, in testing, or
released products.
defects earlier than the test stage is
beneficial and may even pay off.
But there is a better way, which will
appeal to many organizations that
have not been able to stomach the
high costs, and low effectiveness,
of conventional inspection.
The main concept is to shift
emphasis from finding and fi
defects early (in engineering specs
before using them for construction)
to estimating the specification
defect density and using this infor-
mation to motivate engineers to
learn to avoid defect injection in
thefirst place. This shift permits a
dramatic cost savings. We can sam-
ple rather than check 100
specs when our purpose is meas-
urement rather than
The main purpose of Agile
is to motivate individuals to reduce
major specification defect inser-
tion. Secondary S
To prevent uneconomic major-
defect density specs from
escaping downstream
thus to avoid consequent
delays and quality problems.
The major tactic here is an
specification process e
rier, such as
majors per page.
To teach and reinforce current
specification standards.
Wed 03 of May, 2006 Sun 07 of May, 2006 Tom Gilb13 points  11659 Information