Tom Gilb & Kai Gilb - Helping you deliver Value to your Stakeholders

Filename	Name	Description	Created / Uploaded	Last modified	Uploaded by	Hits
evo vs Waterfall 1985 ANGLE corrected direction.pdf	Evolutionary Delivery Vs Waterfall Model ACM SEN 1985 Historical Agile	This is not my earliest Evo (Agile) paper or book, but it is well put and valid appeal for Agile as it should be (Value Delivery) even today. Fun written on a Mac.	Fri 25 of Sep, 2020	Fri 25 of Sep, 2020	Tom Gilb	226
Conceptual Glossary paper 2007 PDF.pdf	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 dictionary). 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. Introduction	Wed 03 of May, 2006	Thu 23 of Jul, 2020	Tom Gilb	9732
A CRITICAL REVIEW OF DEFINITION OF GOALS in Prosjektledelse 2020.pdf	A CRITICAL REVIEW OF DEFINITION OF GOALS In Prosjektledelse 2020		Mon 11 of May, 2020	Mon 11 of May, 2020	Tom Gilb	422
A General Theory of Design PDF COPY NOT FINISHED 100619.pdf	A General Theory Of Design PDF COPY NOT FINISHED 100619	This is an attempt to make a claim, and document the claim systematically, that Planguage/Evo/SQC is a candidate for a Grand General Theory of Design. Apparently nobody else has laid claim. So I hereby lay that claim ,and challenge anyone else to argue in writring in public, that they have an equal or better alternative. Pretty cheeky, but I thought it was good fun to lay in the claim and see what happens.	Tue 11 of Jun, 2019	Tue 11 of Jun, 2019	Tom Gilb	1397
Principles of Project Failure pdf for Gilb com 100619.pdf	Principles Of Project Failure Pdf For Gilb Com 100619	This paper was written for a June 4 2019 Gilb.com Blog. It ws announced on Twitter and Linkedin pointing to the Blog site. There a a small (- 'my') correction here. It is a sarcastic discussion of the IT Failure rate causes.	Mon 10 of Jun, 2019	Mon 10 of Jun, 2019	Tom Gilb	456
Beyond Scaling: 310519 Scale-free Prin...- Agile Engineering Master Version.pdf	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 31 of May, 2019	Tom Gilb	4980
Principles of Professional Planguage Proliferation For advisory….pdf	Principles Of Professional Planguage Proliferation For Advisory…	10 Steps in a management meeting process of about half a day, in order to introduce Plante concepts to manager and planners in a relevant to them way.	Wed 29 of May, 2019	Wed 29 of May, 2019	Tom Gilb	442
Basic Principles of Security Engineering. [email protected]	Basic Principles Of Security Engineering. [email protected]	A response to the https://blog.threatpress.com/security-design-principles-owasp/ principles as cited in a Meetup Oslo 20 May 2019 by VA	Tue 21 of May, 2019	Tue 21 of May, 2019	Tom Gilb	360
Gilb opinion on Domain Driven Design 2019.docx	Gilb Opinion On Domain Driven Design 2019	DDD is 'popular' but I fail to see documentation (cases, facts, measures) for what it does for us, and how it does it. But my IT friends are forever adopting methods of no documented merit, and failing massively in their IT systems development. Tell me please that DDD provably reduces our 50% total failure rate to zero?	Wed 15 of May, 2019	Wed 15 of May, 2019	Tom Gilb	851
Evo’ Project Initiation Syllabus MASTER 120519.docx	Evo’ Project Initiation Syllabus MASTER 120519	A Detailed ,one page per day of the startup week, description or standard for the Agile or Evo Startup Week. See also http://www.gilb.com/dl812 Agile Project Startup Week paper Gilb’s Mythodology gilb.com/dl568 see also example 111111 DOD Persinscom slides http://www.gilb.com/DL451	Sun 12 of May, 2019	Sun 12 of May, 2019	Tom Gilb	510
PAPER ON TEACHING USEFUL KNOWLEDGE Inspire Gilb.pdf	PAPER ON TEACHING USEFUL KNOWLEDGE Inspire Gilb	The paper is 2 subchapters of my Value Planning book (see Gilb.com) which are directed at the Academic community. They were the supplementary paper for my Talk 16April 2019 at the BCS Inspire Conference, Invited Keynote, at Solent University, Southampton. The many references are mainly downloads found in the Value Planning book itself.	Tue 16 of Apr, 2019	Tue 16 of Apr, 2019	Tom Gilb	399
IET for Dummies 2018_Katowice best q pdf.pdf	IET For Dummies 2018 Katowice Best Q Pdf		Mon 28 of Jan, 2019	Mon 28 of Jan, 2019	Tom Gilb	540
AGILE MANIFESTO ALIGNMENT tom gilb SyEN 2018 Paper.pdf	MANIFESTO VALUES AND PRINCIPLES VERSUS PLANGUAGE AND EVO 2018		Thu 04 of Jan, 2018	Thu 01 of Mar, 2018	Tom Gilb	2198
Everyday Superpowers MASTER Version 070218 2.pdf	Everyday Superpowers MASTER Version 020118	10 practical Superpowers described in 1 page each. With many downloads including free books and papers and slides.	Tue 02 of Jan, 2018	Thu 08 of Feb, 2018	Tom Gilb	1175
VF Manifesto toms edit Version Jan 7 2018 2112 BST.pdf	The Value Manifesto: Manifestos Simplified	I am tired of a stream of consciousness recommendations of agile and lean and other 'pop1' ideas. This manifesto has a single statement: VALUE Everything else needs to be justified as necessarily contributing to the value or to the value for 'money'	Thu 16 of Mar, 2017	Sun 07 of Jan, 2018	Tom Gilb	2427
Value Juggling.pdf	Value Juggling Website Version 26 April 2017	The basic essentials of juggling dozen critical value and cost factors simultaneously, and succeeding in projects.	Wed 26 of Apr, 2017	Wed 26 of Apr, 2017	Tom Gilb	1357
FEAR OF NUMBERS master.pdf	FEAR OF NUMBERS Master	Many people are afraid of quantifying values and qualities, because they either do not know how to; or they are afraid that the numbers will be misused. This paper tries to address that fear.	Tue 25 of Apr, 2017	Tue 25 of Apr, 2017	Tom Gilb	1203
Too Simple 240318.pdf	Too Simple 240318	We are witness to a flood of IT methods ideas. But our failure rates are still rediculous. Sometimes the human need to simplify results in adoption of 'too simple' methods: they fail. So we need to find just the right quantity of method to succeed. Paper written March 2017	Fri 24 of Mar, 2017	Fri 24 of Mar, 2017	Tom Gilb	1509
Quantification Versus Measurement MASTER 2.pdf	Quantification Versus Measurement MASTER	Now, just because we prioritize the value quantification, in our teaching and our planning process; that does not mean we do not care about sufficiently good measurement at a later stage. We do. But our course participant explicitly stated, as many other think and do, that he would consciously choose a scale of measure for a stakeholder critical requirement, ‘because it was easy to measure’. This remark caused us to take ‘violent’ exception to that idea. Never! The ‘Scale of measure’, is primarily a ‘definition’. But it is a special class of definition. Scale is a definition of a variable value or resource. Scale is a tool that guarantees that we can use numbers to communicate ideas about that value’s specifications (what is the required level), and in time, about that value’s current status (have we actually reached the required level of this value?).	Fri 10 of Mar, 2017	Fri 10 of Mar, 2017	Tom Gilb	2025
Stakeholder Power paper.pdf	Stakeholder Power Paper	This paper contains my Planguage definition of Stakeholder, and 10 stakeholder principles. It was written Feb 2016. THIS IS IDENTICAL TO THE PAPER ON THIS SITE FEB 2016. THIS DUPLICATE WAS PUT UP BY ACCIDENT BUT ILL KEEP IT HERE AS IT WAS ANNOUNCED.	Sat 18 of Feb, 2017	Sat 18 of Feb, 2017	Tom Gilb	1865
OKR Whats wrong and fixing it.pdf	OKR Whats Wrong And Fixing It	OKR Objectives and Key Results: what’s wrong and how to fix it. A short paper to help tune OKR so that it is much better at clarity of the objectives: quantified. And more.	Thu 02 of Feb, 2017	Thu 02 of Feb, 2017	Tom Gilb	5669
Lean Value Planning MASTER Gilb.pdf	Lean Value Planning MASTER Gilb	Our 'Value Planning' book, about the Planguage planning language, contains methods that are very 'Lean'. So this paper explains how our many methods help you to be lean: upstream, preventative etc. Written June 2016	Wed 25 of Jan, 2017	Wed 25 of Jan, 2017	Tom Gilb	1431
Why 20 tough questions icloud copy 25Nov2016.pdf	20 Tough Technical Questions INTEL 2016.pdf	A Variation of 12 Tough Questions (for managers) but specifically for a more technical engineering environment. Specialized into 10 questions about requirements and 10 about design or architecture. Used in a Keynote for Intel Portland April 2016	Wed 25 of Jan, 2017	Wed 25 of Jan, 2017	Tom Gilb	1325
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 'Value Planning' Leanpub.com/ValuePlanning 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	Mon 15 of Feb, 2016	Tom Gilb	2014
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. UPDATE FEB 2016: I have completed 2 years work on Value Planning (700 pages) leanpub.com/valueplanning and I am planning to write a very short management book in 2016.	Thu 26 of Jul, 2007	Mon 15 of Feb, 2016	Tom Gilb	4991
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 Gilb	1469
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 [email protected] 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 Gilb	750
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 Gilb	3481
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 Gilb	1755
Making Complexity Simple 300915 Paper 2015.pdf	Making Complications Simple: using Planguage	Making Complications Simple: using Planguage Version 30 Sept 2015, 1st Draft © By [email protected] Abstract: 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 Including Ten Principles of Simplification: ‘Making Complexity Uncomplicated’ and Planguage Tools for Simplification	Wed 30 of Sep, 2015	Wed 30 of Sep, 2015	Tom Gilb	1866
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 Gilb	5277
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 Jul, 2014	Mon 21 of Jul, 2014	Tom Gilb	2309
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 Jun, 2014	Thu 26 of Jun, 2014	Tom Gilb	1521
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 Gilb	3345
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 Gilb	3767
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 Gilb	3447
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 Gilb	2921
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 Jun, 2013	Admin (Kai)	2843
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 Gilb	4815
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 [http://www.gilb.com//tiki-download_file.php?fileId=77] 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 Gilb	2987
’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 [http://www.gilb.com//tiki-download_file.php?fileId=77] 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 Gilb	2689
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) [http://www.amazon.co.uk/Principles-Software-Engineering-Management-Gilb/dp/0201192462] 14 Printings since 1988 - what does that tell you? Chapter 15 on Productivity is also at this site [http://www.gilb.com/dl560]	Tue 20 of Nov, 2012	Tue 20 of Nov, 2012	Tom Gilb	6532
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 Gilb	2915
Gilb Col 6 Gilb‘s Mythodology Column The Top 10 Critical Requirements are the	The Top 10 Critical Requirements are the Most Agile Way to Run Agile Projects	Gilb‘s Mythodology Column Agilerecord.com ISSN 2191-1320 August 2012 issue 11	Thu 11 of Oct, 2012	Thu 11 of Oct, 2012	Tom Gilb	3236
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 Jun, 2012	Thu 28 of Jun, 2012	Tom Gilb	2361
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 Gilb	5189
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 Gilb	3758
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 Gilb	6166
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	102878	3663
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. http://www.coremag.eu/fileadmin/Papers/Quantifying_Management_TGilb_core3.pdf	Mon 18 of Apr, 2011	Mon 18 of Apr, 2011	102878	6058
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	102878	8491
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	102878	8677
quantify quality icsoft march 26 2008 00100027.pdf	How to Quantify Quality	PAPER: How to Quantify Quality: Finding Scales of Measure by Tom Gilb [email protected] Abstract. ‘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 Jun, 2007	Tue 29 of Mar, 2011	Tom Gilb	11937
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 Gilb	11388
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 Gilb	9169
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 Gilb	9600
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 827 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: [email protected] ABSTRACT 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 Gilb	13043
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 Gilb	3979
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 Gilb	4111
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 Gilb	14551
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 Gilb	8647
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 http://www.gilb.com/tiki-download_file.php?fileId=25 (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 Gilb	8575
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 Gilb	7442
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 ([email protected]). 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 Gilb	5765
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 Jul, 2010	Tue 27 of Jul, 2010	Tom Gilb	4846
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 Jul, 2010	Sun 25 of Jul, 2010	Tom Gilb	13560
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 Jul, 2010	Sun 25 of Jul, 2010	Tom Gilb	8853
Real_QA_Polish translation.pdf	Real QA Manifesto, Prawdziwe QA: Zapewnienie “Jakości i wartości”	Polish Translation in C0re 2010	Sat 19 of Jun, 2010	Sat 19 of Jun, 2010	Tom Gilb	3670
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 Gilb	4693
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 [http://www.gilb.com/tiki-download_file.php?fileId=142] 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 Gilb	6763
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 Gilb	5566
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 Gilb	5035
testingexperience02_08_Gilb CORRECT VERSION.pdf	Rule-Based Reviews	as Published in Testing Experience May 2008 by Tom Gilb	Thu 12 of Jun, 2008	Thu 12 of Jun, 2008	Tom Gilb	4555
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. Abstract. 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. Principles 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 Gilb	6490
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 Gilb	8383
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. Introduction 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 Gilb	10737
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. Abstract. 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 Gilb	4904
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 Abstract. 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 Gilb	10854
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. Abstract. 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 Gilb	12198
Maintainability in Software Engineering.pdf	Designing Maintainability in Software Engineering	PAPER: Designing Maintainability in Software Engineering: a Quantified Approach. Tom Gilb 15 PAGES, 1MB Abstract. 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 Gilb	33233
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 Abstract. 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 Gilb	9993
Requirement Relationships.pdf	Requirement Relationships	PAPER: Requirement Relationships: A Theory, some Principles, and a Practical Approach. Drafted initially Sunday, 1 October 2006. © [email protected], 2006 Introduction: 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 Gilb	9538
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 http://www.stsc.hill.af.mil/crosstalk/2002/11/gilb.html See corresponding set of slides at this website.	Tue 08 of May, 2007	Tue 08 of May, 2007	Tom Gilb	10090
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 Gilb	4793
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 Gilb	6619
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 Gilb	21793
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 Jul, 2006	Tom Gilb	6865
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. Introduction 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 processes. • 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 Jul, 2006	Tom Gilb	5332
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 Gilb	8402
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 Gilb	4638
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). ... www.nasscom.org/download/Tom_Gilb-.ppt	Wed 24 of May, 2006	Wed 24 of May, 2006	Tom Gilb	4732
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) www.nasscom.org/download/Tom_Gilb-.ppt advice for Indian Organizations.	Wed 03 of May, 2006	Wed 24 of May, 2006	Tom Gilb	14655
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 Gilb	8666
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 Gilb	9600
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 Gilb	4690
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 Gilb	6381
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 Gilb	7930
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 Gilb	12612
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 Gilb	10200
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 Gilb	11644
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 Gilb	6837
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 Gilb	7506
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 change.	Wed 03 of May, 2006	Sun 07 of May, 2006	Tom Gilb	9034
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 Gilb	7845
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 Gilb	12159
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 Gilb	6783
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. Introduction 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 Gilb	10366
What Is Wrong With Agile Methods.pdf	WHAT’S WRONG WITH AGILE METHODS? SOME PRINCIPLES AND VALUES TO ENCOURAGE QUANTIFICATION	PAPER. Abstract: 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 Gilb	7732
Interview--Tom Gilb-2 INDIA 2006.pdf	GREAT CHANGE WITH EVOLUTION	PAPER - INTERVIEW WITH TOM GILB. www.itmagz.com 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 Gilb	4675
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 Gilb	5818
CAI tomgilbinterview1.pdf	What are Evolutionary (EVO) Development Methods?	PAPER - INTERVIEW. CAI Interview with Tom Gilb at 21 Feb 2006 See CAI newsletter Gilb Evo Interview http://www.itmpi.org/default.aspx?pageid=230	Wed 03 of May, 2006	Sun 07 of May, 2006	Tom Gilb	3931
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 Gilb	6577
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 Gilb	5375
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. INTRODUCTION 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 Gilb	20826
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 development. Tom Gilb [email protected] Mark W. Maier [email protected] 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 Gilb	13155
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 Gilb	6159
DESIGN REVIEWS BEST GILB RULE BASED REVIEWS SQPv7i1Gilb.pdf	Rule-Based Design Reviews	PAPER. VERSION PUBLISHED IN SOFTWARE QUALITY PROFESSIONAL 2004 Key words: evolutionary project management, peer review, quality control of specifications, review, review standards INTRODUCTION 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 design). 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 characteristics. • 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 Gilb	8386
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 Gilb	5677
Agile SQC CutterVol 18 No1 2005.pdf	Agile Specification Quality Control	PAPER (5 Page version, Cutter IT Journal , January 2005) INTRODUCTION If we do specification inspections properly 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 Specification 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 S 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 Gilb	12548

Gilb Papers

Concept Search