<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="Tiki CMS/Groupware via FeedCreator 1.7.2.1" -->
<?xml-stylesheet href="http://gilb.com/lib/rss/rss-style.css" type="text/css"?>
<rss version="0.91">
    <channel>
        <title>Tiki RSS feed for the file gallery: Gilb Papers</title>
        <description><![CDATA[Downloads: Papers written by Gilb.]]></description>
        <link>http://gilb.com/tiki-file_gallery_rss.php?galleryId=15</link>
        <lastBuildDate>Tue, 07 Sep 2010 11:18:08 +0100</lastBuildDate>
        <generator>Tiki CMS/Groupware via FeedCreator 1.7.2.1</generator>
        <image>
            <url>http://gilb.com/img/tiki.jpg</url>
            <title>Tom Gilb &amp; Kai Gilb</title>
            <link>http://gilb.com/Site+Content+Overview</link>
            <description><![CDATA[Feed provided by Tom Gilb & Kai Gilb. Click to visit.]]></description>
        </image>
        <language>en-us</language>
        <managingEditor>Kai@Gilb.com</managingEditor>
        <webMaster>Kai@Gilb.com</webMaster>
        <item>
            <title>collection of Architecture PLanguage Concepts.docx</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=287</link>
            <description><![CDATA[ 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.]]></description>
        </item>
        <item>
            <title>The 100 Planguage Principles from CE MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=352</link>
            <description><![CDATA[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!]]></description>
        </item>
        <item>
            <title>Flyer-artikkel-v7Norwegian.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=355</link>
            <description><![CDATA[FLYER/PAPER: a short paper in Norwegian with 5 values of Value Management and Wrong Focus (of Agile and traditional project management methods).
]]></description>
        </item>
        <item>
            <title>Agile Values Part 2 Paper for Agile Record.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=436</link>
            <description><![CDATA[Value-Driven Development
Principles and Values – Agility
is the Tool, Not the Master.              
Part 2
“Values for Value”
]]></description>
        </item>
        <item>
            <title>Gilbs Laws Gilb.com draft edition 2010.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=435</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>GILB whats wrong with RQTS Keynote MASTER Sep2010.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=434</link>
            <description><![CDATA[2nd International Workshop on Requirements Analysis GILB whats wrong with RQTS Keynote MASTER Sep2010.docx
31 pages. Basis for Slides and Keynote presentation.]]></description>
        </item>
        <item>
            <title>Gilb Agile Principles 2010 agilerecord03_Gilb.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=431</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Estimation or Control 2010 MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=433</link>
            <description><![CDATA[	“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.]]></description>
        </item>
        <item>
            <title>Real_QA_Polish translation.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=393</link>
            <description><![CDATA[Polish Translation in C0re 2010]]></description>
        </item>
        <item>
            <title>Lever-Verdi-v1.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=360</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>QUALITY MANIFESTO testingexperience01_08_Gilb.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=288</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Real QA 1000 words 2009 Opinion Piece for Mike Smith.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=286</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Gilb Agile Spec QC 2009 in Testing Experience March 2009.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=264</link>
            <description><![CDATA["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
]]></description>
        </item>
        <item>
            <title>Vision Engineering paper aug18 INITIAL WEB VERSION.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=237</link>
            <description><![CDATA[Top Management Planning audience.
31 pages

How to convert nice-sounding corporate core ideology (core purpose and core values) into clear, detailed, measurable, trackable and quality controlled plans.

This is 'Planguage' and 'Competitive Engineering' for Business Managers

1st Draft (soliciting feedback from you!) 18august08]]></description>
        </item>
        <item>
            <title>testingexperience02_08_Gilb CORRECT VERSION.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=192</link>
            <description><![CDATA[as Published in Testing Experience 
May 2008

by Tom Gilb]]></description>
        </item>
        <item>
            <title>Undergraduate Basics MASTER June 19 07.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=98</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Decomposition April 4 2008.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=41</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Gilb and Brodie QFD AND IE NOV 22 07 Neutral MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=119</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Quantification of Quality MASTER.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=124</link>
            <description><![CDATA[PAPER: How to Quantify Quality: Finding Scales of Measure
by Tom Gilb
Tom@Gilb.com

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.
]]></description>
        </item>
        <item>
            <title>Why July 26 Gilb.com version.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=127</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>Quality Manifesto for Systems Engineering 2008 MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=142</link>
            <description><![CDATA[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.

]]></description>
        </item>
        <item>
            <title>Engineering the  Review Process MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=143</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Engineering Productivity NOV4 07.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=144</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Making Metrics Practical - INCOSE.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=140</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Maintainability in Software Engineering.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=138</link>
            <description><![CDATA[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
]]></description>
        </item>
        <item>
            <title>Value Delivery in Systems Engineering.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=137</link>
            <description><![CDATA[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.  
]]></description>
        </item>
        <item>
            <title>Requirement Relationships.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=96</link>
            <description><![CDATA[PAPER:  Requirement Relationships: A Theory, some Principles, and a Practical Approach.

Drafted initially Sunday, 1 October 2006.                    © Tom@Gilb.com, 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.
]]></description>
        </item>
        <item>
            <title>STSC CrossTalk - The 10 Most Powerful Principles for Quality in Software and Sof</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=123</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>1Virtual  Team MASTER.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=112</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Requirements for Outsourcing MASTER.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=100</link>
            <description><![CDATA[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
]]></description>
        </item>
        <item>
            <title>The Ten Most Powerful Systems Engineering Heuristics.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=97</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Design Principles  INCOSE 2006 GILB  MASTER.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=42</link>
            <description><![CDATA[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!
]]></description>
        </item>
        <item>
            <title>How Good Is a Process BY GILB.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=51</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Competitive Systems Engineering .pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=49</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Software Contracting ideas Initial and Operational Decisions.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=74</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Nasscom Keynote MASTER.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=72</link>
            <description><![CDATA[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

]]></description>
        </item>
        <item>
            <title>No Cure No Pay.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=38</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>12 TOUGH QUESTIONS May06.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=24</link>
            <description><![CDATA[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! 	]]></description>
        </item>
        <item>
            <title>IEEESWAr.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=17</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>10MostPo.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=19</link>
            <description><![CDATA[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. ]]></description>
        </item>
        <item>
            <title>Risk.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=20</link>
            <description><![CDATA[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. ]]></description>
        </item>
        <item>
            <title>PRACTICAL CREATIVITY MASTER.doc</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=22</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>Crosstalk Impact Est Art DEC98.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=23</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Real Requirements INCOSE Final.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=28</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Firm-FromWaterfallToEvo-Paper.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=32</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Quantifying Stakeholder Values INCOSE06.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=36</link>
            <description><![CDATA[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? ]]></description>
        </item>
        <item>
            <title>Plicons A Graphic Language for Systems Engineering.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=37</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>AGILE  PLANGUAGE.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=39</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Quantifying Security.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=40</link>
            <description><![CDATA[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.
]]></description>
        </item>
        <item>
            <title>Choice and Priority using Planguage.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=48</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Decision Rationale.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=43</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Rich Requirement Specs.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=44</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Rule Based Design Reviews.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=45</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>A Conceptual Glossary.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=46</link>
            <description><![CDATA[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 
]]></description>
        </item>
        <item>
            <title>Architecture a view.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=47</link>
            <description><![CDATA[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’).  
]]></description>
        </item>
        <item>
            <title>What Is  Wrong With Agile Methods.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=50</link>
            <description><![CDATA[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’).  
]]></description>
        </item>
        <item>
            <title>Interview--Tom Gilb-2 INDIA 2006.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=52</link>
            <description><![CDATA[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.]]></description>
        </item>
        <item>
            <title>Why isn\'t Software Trustworthy IT Cutter 2006.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=53</link>
            <description><![CDATA[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. ]]></description>
        </item>
        <item>
            <title>CAI tomgilbinterview1.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=55</link>
            <description><![CDATA[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

 
]]></description>
        </item>
        <item>
            <title>Agile Spec QC INCOSE Final.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=57</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Design Evaluation INCOSE Final.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=58</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Evo Principles.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=59</link>
            <description><![CDATA[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
]]></description>
        </item>
        <item>
            <title>Managing Priorities May 16 2234.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=60</link>
            <description><![CDATA[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 
Tom@Gilb.com 
Mark W. Maier 
Mark.w.maier@aero.org 
 
Copyright © 2005 Tom Gilb and Mark Maier. Used by Permission of the authors by INCOSE. 
]]></description>
        </item>
        <item>
            <title>Project Failure Prevention.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=61</link>
            <description><![CDATA[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: 
]]></description>
        </item>
        <item>
            <title>DESIGN REVIEWS BEST  GILB RULE BASED REVIEWS SQPv7i1Gilb.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=62</link>
            <description><![CDATA[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. 
]]></description>
        </item>
        <item>
            <title>Adding Stakeholder Metrics to IT Projects citj0704TG.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=63</link>
            <description><![CDATA[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]]></description>
        </item>
        <item>
            <title>Agile SQC CutterVol 18 No1 2005.pdf</title>
            <link>http://gilb.com/tiki-download_file.php?fileId=64</link>
            <description><![CDATA[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. ]]></description>
        </item>
    </channel>
</rss>
