Tom Gilb

Value Re-
quirements

Figure Cover, Source: “To Catch a Butterfly: Epistimic Miracles of Serendipity. The.xel.io

http://te.xel.io/posts/2018-03-04-to-catch-a-butterfly-epistemic-miracles-of-serendipity.html

Page 1 of 291 Value Requirements Copyright [email protected] 2019

Introduction
This book will help you analyze and specify the most important re-
quirements for your project, how to quantify success ‘values’, so you
can manage them, and how to structure them, so as to reflect your
complex reality.

This book will help you with the following work processes: stakeholder
analysis, value requirement specification, requirement quality control,
requirement prioritization, risk management, clear communication, and
systems-level thinking.

It will help you set the stage for design, estimation, contracting, and
project management.

The method is based on our advanced planning language, ‘Planguage’,

which specializes in values, qualities and costs like no other alternative
requirements method.

Simply the best, for those who must succeed, and cannot afford to fail
to deliver real value.

Page 2 of 291 Value Requirements Copyright [email protected] 2019

Introduction 2

Chapter 1. What are `Value Requirements` ? (VR) 9

What other kinds of requirements do we need to consider? 10
Part of the reason we are not treating these non-value requirements in detail
here is: 13
What kinds of ‘requirements’ are NOT on our ‘Value Requirements’ agenda ?
13
Can User Stories be used? 14

Chapter 2. More detail on the nature of Value Require-

ments (VR) 16
Chapter 3. The Scale In more detail. 19
3.1 The essence of a ‘Scale specification’. And a ‘motivation’ to use it. 19
3.2 Minimal Scales. 24
3.4 Developing a Scale from an Ambition Level. 28
3.5 Scale Parameters 32
3.6 Defining Other Terms in a Scale 38
3.7 Scale Libraries 40
3.8 Multiple simultaneous Value Requirements 45
3.9 Here is an example of a single complete Value Requirement Specifica-
tion, with all the extra supporting detail we will discuss below. 46
3.10 Details of a Scale (Air Quality example), with Scale Parameter Definition.
48
3.11 More on Multiple Value Requirements 49
3.12 Knowing when to decompose a value into sub-values, using sub-scales.
51
3.13 Good Scales and bad Scales. 53

Chapter 4. The ‘Meter’ Parameter 55

4.1 The ‘Meter’ specification is a defined process for measuring the numeric
value level, on a Scale. 56
4.2 The Meter as a high-level test process: why this is useful. 58

Page 3 of 291 Value Requirements Copyright [email protected] 2019

4.3 The multiple quality and cost attributes of a Meter 60
4.4 Sufficient Meter Accuracy for Purpose 62

Chapter 5. Benchmarks 64
5.1 The purpose of ‘Benchmarks’ In a Value Requirement Specification. 64
5.2 ‘Past’ as a Benchmark 66
5.3 ‘Status’-level Benchmark: real time value delivery tracking. 69
5.4 Record Benchmark 70
5.5 ‘Ideal-level’ Benchmark 72
5.6 ‘Trend-level’ Benchmark 74

6. Scalar Constraint levels. 75

6.1 ‘Tolerable-level’ Constraint. 75
6.3 Constraints are a Dynamic Prioritization Tool 78
6.4. Several different Tolerable levels might be appropriate for different cir-
cumstances. 80
6.5 There are other types of ‘Scalar Constraints’ Defined 81

Chapter 7. Scalar Target-levels. 82

7.1 Wish-level Target 82
7.2 Goal-level Target 90
7.3 Comment on the Multiple Goal Example Above (Fig. 1.43). 92
7.4 Stretch-level Target 95

Chapter 8. Background Specifications. 97

8.1 The General Purposes of Background Specifications. 100
8.2 Risk Management with Background Specs 102
8.3 Prioritization using background specs 106
8.4 Responsibility and Motivation with Background specs 111

Chapter 9. Making Use of the Value Specification 114

9.1 Dialogue with Stakeholders 114
9.2 Negotiating Priorities for Values 118

Page 4 of 291 Value Requirements Copyright [email protected] 2019

http://news.mit.edu/2018/natural-resource-negotiations-for-mutual-gains-
bruno-verdini-0621 119
9.3 Determining the higher-level value of value increments 120
Figure 1.56 : Gee I think I’ll change my mind about the Solar Panels, and the
Tennis Court 122
We need to use this kind of thinking about stakeholder value increments. Will
it pay off? 122
Or ‘don’t even think about it!’ 122
https://www.thesun.co.uk/money/7178628/home-renovations-affect-house-
price/ 122
9.4 Contracting and Proposals 123
9.5 Handover to architecture and design engineering. 125
9.6 Handover to testing and measurement, with Value requirements. 128
9.7 Presentation and approval for steering committees, based on Value Re-
quirements. 131
9.8 Quality Control: of value requirements. 133
9.9 Defect Level Measurement and Exit Control 136
9.10 Management Reviews, in a Value Driven culture. 138
9.11 Estimation of resources to deliver Value levels 140
9.12 The ‘Design to Value’, and ’Design to Cost’. 142

Chapter 10. Presentation of Value Specifications 144

10.1 Presentation to Stakeholders 145
10.2 Value Requirements: Presentation To Project Managers 148
10.3 Value Presentation to Steering Committees 152
10.4 Value Presentation to Spec QC Teams 152
10.5 Value Presentation to Architecture 155
10.6 Value Presentation to Legal Team 157
10.7 Value Presentation to Sub-suppliers 159

Chapter 11. Levels of Value Specifications 160

11.1 Vision Levels, Vision Engineering 161
11.2 Fundamental Value Requirements 164

Page 5 of 291 Value Requirements Copyright [email protected] 2019

Chapter 12. Resource Requirements Specification 166
12.1 The need to understand the incremental costs of value requirements be-
fore approving them. 166
12.2 Some basic categories of Resource Requirements 168
12.3 The difficulty of estimation of costs up front (ref. F) 171
12.4 The possibility of getting control over real costs by design to cost 172
12.5 The possibility of getting control of some costs by smart ‘Dynamic Archi-
tecture’ and design 175
12.6 The possibility of getting control of the value-to-cost ratio by decompo-
sition; and then by prioritization of high-efficiency designs. 178
12.7 The possibility of getting control over costs, by negotiated reduction of
initial Value level, and initial date ambitions 180
12.7 The possibility of getting control over costs by Subcontracting 185

Chapter 13. Change Control of Value Specifications. 187

13.1 The concept of a specification Owner. 187
13.2 Annotation of change source, and time stamps 190
13.3 Ways of controlling the whole of the specification 194

Chapter 14. A Review of Requirement Methods Compared

to Planguage 196
14.1 General observations of methods for specifying Value Requirements 196
14.2 A Checklist for understanding capabilities of value requirement Specifi-
cations 197
Chapter 15. SOME COMMENTS ON SPECIFIC METHODS 199
15.1 User Stories (ref. H, a) 199
15.2 Use Cases 201
15.3 Earned Value Management (EVM) 205
15.4 Functional Requirements and Non-functional Requirements 206
15.5 Balanced Scorecard 209
15.6 Quality Function Deployment (ref. I) 214
15.7 Togaf 216

Page 6 of 291 Value Requirements Copyright [email protected] 2019

15.8 Zachmann Framework 219
15.9 UML: Unified Modeling Language 220
15.10 Design Sprints (ref. g) 221
15.11 The ’Evo’ Project Startup Week (ref. K) : Values Driven Start 222
15.12 OKR (K) Objectives and Key Results. 224
15.13 MoSCoW: Prioritization Method. 226
15.14 CMM: CMMI, Capability Maturity Model 229

Chapter 16. A Briefing on Use of Value Specifications for

Design and Architecture 230
16.1 Architecture Engineering: disciplined and logical architecture. 233
16.2 Design Engineering: specialist areas with clear consideration and bal-
ance for all other values and constraints. 236
16.3 The Value Table for overview and synchronization 240
16.4 Design-attribute feedback incrementally, and adjustment of value levels,
timings, and resource budgets, in mid-project. 241
16.5 The Evo Value Cycle 243

Chapter 17. Formal Standards for Value Specifications 244

17.1 Competitive Engineering as Planguage Standard. 245
17.2 ValPlan as a tool containing standards 246
17.3 Rules 248
17.4 Processes 249
17.5 Exit and Entry Processes 250
17.6 ‘Concept’ Standards: several levels 252
17.7 Teaching and enforcing standards using Spec QC and Exit levels 254

Chapter 18. ValPlan: and apps for Value Specifications 255

18.1 Brief history of Planguage tools. 255
18.2 ValPlan the app. 258
18.3 Open Endedness for Tool Builders. 260
18.4 GraphMetrix 261

Page 7 of 291 Value Requirements Copyright [email protected] 2019

Chapter 19. Stakeholders and the planning environment
263
19.1 Determining your planning environment (ref. L) 265
19.2 Determining your stakeholders 269
19.3 Eliciting stakeholder needs and converting them into Requirements. 272
19.4 Understanding stakeholder priority, power, competence and motivation.
273
Chapter 20. Summary of Value Requirements 274

Appendix 21 Book References 275

Appendix 22. Papers References, with Free URL Links 277
Appendix 23. Slides and Talk Video References, with Free
URL Links 280
Appendix 24. Concept Glossary 282
Appendix 99. Notes on editing the book and Versions. 289

Page 8 of 291 Value Requirements Copyright [email protected] 2019

Chapter 1. What are `Value Requirements` ?
(VR)
Value Requirements are the most important requirements for any
project. They are the main purpose, and main justification, for a
project. They are the stakeholder’s values.

Value requirements start life as value ‘attributes’ needed by ‘stake-

holders’. No project can deliver all ‘needed’ values, by a deadline.
No project will find all stakeholder values to be worth delivering.

So all value requirements start life by being acknowledged as pos-

sible delivery candidates. But VRs need to go through an evalua-
tion process to determine that we can prioritize them for real de-
livery.

FUNCTION VALUE

Figure 1.1 : A Value is a variable level of performance for a function. Represented graphically as an
arrow emanating from a Function symbol. This is a simplified model, with a single value arrow. Reali-
ty is always that multiple values are needed concurrently.

Page 9 of 291 Value Requirements Copyright [email protected] 2019

What other kinds of requirements do we need
to consider?
There are several other ‘requirement types’ which you will need to
consider, but we will not treat these in detail here. They are treated
elsewhere (Competitive Engineering, CE ).

Here is a list of other (not ‘value’) requirement types.

Function Requirements: WHAT the system must DO.

The Function ‘keyed icon’ is: (any oval keyboard symbol) ‘O’

FUNCTION OVAL

Figure 1.2 : a system function, represented as an oval shape in Planguage icons.

Planguage icons are a formally defined set of symbols, like music

notes, or maths symbols, which represent systems engineering
concepts1. And which are independent of human spoken lan-
guages.

1 http://www.gilb.com/DL386, Full Planguage Concept Glossary. Including Icons.

Page 10 of 291 Value Requirements Copyright [email protected] 2019

 🎶 ♥ ♾ 🏴☠

Resource Requirements: limitations on any kind of resources

(people, time, money).

RESOURCE FUNCTION OVAL

Figure 1.3 : a single resource arrow giving a function the potential of some values.

The ‘Resource’ ‘keyed icon’ is: ->O

Page 11 of 291 Value Requirements Copyright [email protected] 2019

Binary Constraints: legal constraints, design constraints, anything
that must either be done, or not done.

FUNCTION VALUE

Figure 1.4 : A constraint (the rectangular shape) which the system must be ‘within’.

Another type of constraint a ‘Scalar Constraint’ will be dealt with in

this book. It is a numeric limit (not too hot, not too cold) on a Value
Scale (at least 99.99% Availability) or a Resource Scale (finished
absolutely latest ny end of year, no matter what).

Page 12 of 291 Value Requirements Copyright [email protected] 2019

Part of the reason we are not treating these
non-value requirements in detail here is:
1. They are fairly well understood.

2. They are comparatively simple, compared to Value Require-

ments.

3. We want to focus on the less-understood, but extremely-deci-

sive, Value Requirements. The main point of all projects.

What kinds of ‘requirements’ are NOT on our

‘Value Requirements’ agenda ?
1. User Stories (see Chapter 15.1)

2. Use Cases (See Chapter 15.2)

3. Simple written text (like ‘better safety’)

4. Designs claiming to be Requirements

Page 13 of 291 Value Requirements Copyright [email protected] 2019

Can User Stories be used?
User stories do not contain enough information to serve as value
requirements. But you can add on the sort of information we
present in this book, to make them serve as value requirements
(ref.

A, US)

User Stories have a useful structure:

1. A stakeholder (narrowly called ’user’)

2. A ‘story’, which functions as a sort of requirement. But is not de-

tailed enough for serious purposes.

3. A justification for the story, which is good practice. But can be

improved upon.

My initial advice for people who have to deal with User Stories is to
write them up as a Planguage statement, and then proceed to de-
rive more-useful detail from it.

For example:

Usability:

Type: Value Requirement.

Page 14 of 291 Value Requirements Copyright [email protected] 2019

User Story: As an expert user I want shortcuts to save me time. <-
US030719.

Scale: Average cycle time in minutes for a [Task] by a [User].

Pro Level: Wish: 6 minutes, Deadline = End Next Year, Task = Ex-
pert Complex Tasks, User = Expert.

Comment: in translating the user story we have carefully avoided

the ‘shortcuts’ which is an amateur ‘design’ suggestion. We have
focused on the stakeholder value of saving time, and left the de-
tailed design, to achieve that end, to a professional UX designer.

Specification example 1A: the user story is cited, then translated into a value requirement (Scale and
Wish statements). The ‘scale parameters’ [Task] and [User] are used to make a more general ‘Usabili-
ty’ specification than the ‘expert user’ in the user story, and to specify a wider range of tasks than
the unspecified tasks in the user story. The result is that we can specify a wide variety of Usability
value requirements.

We can for example add a statement to the Usability specification

above like:

Beginner Requirement: Wish: 10 minutes, Deadline = Beginning

Next Year, Task = Beginner Frequent Tasks, User = Beginner.

Specification example 1B: We added a second ‘Wish’ value requirement, to the Usability specifica-
tion above. This has several advantages. We can now prioritize one of them, based on value and
cost, and deliver the value early; without waiting for the other Wish to be completed.

Page 15 of 291 Value Requirements Copyright [email protected] 2019

Chapter 2. More detail on the nature of Value
Requirements (VR)
• VRs are often qualities, ‘-ilities’ like reliability, security, usability:
‘How Well’ the function performs. Often called ‘performance at-
tributes’.

VALUE SPECIFICATION TYPES

Specifica-
tions

Require-
ments: Fu-
ture Needs

Value Re-
quire-
ments:
How Good

Qualities:
How Well

Other
Values:
How Much

Functions

Constraints

Figure 1.5 Value Specification Types.

• VRs are, in systems engineering, classed as Performance attrib-

utes. ‘How good’ the function is. ‘How Good’ includes: ‘how

Page 16 of 291 Value Requirements Copyright [email protected] 2019

 well’ (Qualities): but also ‘how much’. For example speed, vol-
ume, frequency, sales, market share and savings. Values which
we would not call ‘qualities’

• VRs are always a ‘degree of system performance’ which is ‘actu-

ally valued by some stakeholder’. If not valued, then by defini-
tion, it is of no worth to any stakeholder.

• VRs are always defined as a desired ‘numeric range’ or a ‘point’,

on a ‘scale of measure’, which means the value is a numeric val-
ue.

• In addition to a value requirement being a numeric level, that

level must also be achieved by defined times and conditions,
for the total requirement to be fulfilled.

FUNC- B———C———T

Figure 1.6 : on the Value Scale (Red Arrow symbol) a value requirement might be expressed by nu-
meric constraints (C) and by numeric Targets (T). In addition a Benchmark level (B) might be added
to a requirement specification to inform us of past and current levels of performance, for comparison
with the required levels.

Page 17 of 291 Value Requirements Copyright [email protected] 2019

In our planning language, Planguage, this might be expressed like
this.

Security:

Scale: % probability of detecting a hacker within 5 seconds.

Status: 10% last year. (Benchmark level)

Tolerable: 80% by End this year. (Constraint Level)

Wish: 98% by End Next Year. (Target Level)

Example 1C: a value specification.

Security is the reference tag for the entire specification.

Scale is a parameter in Planguage for defining a value variable, such as Security, so that the various
levels of Security can be expressed numerically.

Status gives us the moving current change of status in the level.

Tolerable gives us the bare minimum level which is acceptable.

Wish is the stakeholder-desired, or stakeholder -needed, level of Security, on that Scale.

Page 18 of 291 Value Requirements Copyright [email protected] 2019

Chapter 3. The Scale In more detail.

3.1 The essence of a ‘Scale specification’. And a

‘motivation’ to use it.
The most powerful, and useful, requirements method-detail that
this book can inform you about is the ‘Scale’.

This is because your ‘Scale specification’ moves you away from in-
formal and fuzzy requirement specifications, and over to clear, log-
ical, quantified methods of thinking about problems.

A Scale specification means you are moving your entire approach

to projects from primitive and failure-prone communication with
others, over to ‘engineering’ and ‘science’: over to a fact-based cul-
ture, to an evidence-based culture.

This takes a little more effort than, ‘being lazy, and failing in your
projects’, but I assume you are reading this book because you want
the skills to improve your capability and success, in your profes-
sion.

Another thing about the skill of ‘defining values in terms of a Scale’,

is that you can use this skill for the rest of your life; on any kind of
problem solving, and any kind of project. It is very good job securi-
ty, in changing times.

Everything this book teaches is like that: it is based on universal

ideas, which are quite independent of current technology, and in-
dependent of any profession you might undertake. I know from 60

Page 19 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.8 : Good value Requirements help us avoid project failure. All 5 of these failure causes are ac-
tually related to good ‘value requirements’.

Source: http://mobile.baselinemag.com/project-management/slideshows/why-some-companies-have-
more-successful-projects.html

years of professional experience, where I am still on top of my

game; and able to impress top international professionals with
these skills.

But this applies not only to me personally: thousands of profes-

sionals in major corporations have recognized the benefits of this
skill, and chosen it.

Page 20 of 291 Value Requirements Copyright [email protected] 2019

One example is the over 21,000 Intel engineers, over about a 20
year period, who have voluntarily taken a 2-day training course in
this way of specifying product values, and practiced their skills.

One simple measured result was 233% overall productivity in-

crease (ref. Terzakis) (ref. A, Intel).

Figure 1.7 Intel

The good news for you personally is that, of the 100% of people
who would benefit from these methods, there are probably less
than 1% of them actually using them today. You will be more com-
petent than the 99%, and hopefully you can help spread this cul-
ture of clear thinking?

Scale definition is the foundation, the core, of this quantified ap-

proach to value delivery.

This is true, as many of you are aware, in all sciences, and engi-
neering disciplines. But somehow the business, politics, and plan-
ning disciplines have avoided quantification of many values and
qualities, and just used ‘nice-sounding words’.

We need to stop these immature practices, for serious projects, in

order to improve our success rates.

The ‘Scale’ parameter specification is used to define success, and

to define failure, so that we will know how far we are from success,

Page 21 of 291 Value Requirements Copyright [email protected] 2019

and how near we are to failure, at all times. And we can take real-
time action to succeed, and to avoid failure.

The ‘Scale’ parameter is not only a clear definition of success and

failure, but it is a tool to help us, as teams and groups of people, to
communicate success and failure, so that all parties understand
these ideas exactly the same; misunderstanding and misinterpreta-
tion should be near impossible.

This is important when projects are widespread, geographically,

culturally and legally. And when change is the only assured con-
stant.

The ‘Scale’ specification, is about an idea of variability: an idea for

quantification: a platform for ‘putting numbers on values’, so as to
express ideas of ‘degree, of goodness’ or ’badness’, or ’improve-
ment’, or ’comparison’.

Scale is NOT an idea of ‘measurement’ (how to determine where

you are now on that scale). We leave specification of measurement
ideas to another parameter, the ‘Meter’, as in speedometer and
voltmeter.

Once a Scale is defined, we reuse it for a very wide variety of pur-

poses.

In addition, we can use more than one different measurement

process (defined by Meter specs) for a single Scale. Quick and
dirty, or more accurate and credible measurements, for example.

Page 22 of 291 Value Requirements Copyright [email protected] 2019

Our graphical symbol for a Scale is an arrow. Value Scales emerge
from a system’s function, and resource Scales point into the func-
tion - supplying a system with resources to drive the values to
emerge.

Resource Scale Functions Value Scale

Figure 1.9: Functions (what a system ‘does’) need a supply of resources (like people, time, money) to
produce values.

These resources are the prices we pay to develop and maintain

‘values’, and the ‘value levels’ we need, when we need them.

Initially, functions have no particular values associated with them.

Functions are independent of any particular values.

But for a function to be of use in a real world, it needs some value

levels, of things like ‘availability’, ‘usability’, and ‘work capacity’. If
these values are zero or low, then the functionality would not be
visible, or useful, in the real world.

Page 23 of 291 Value Requirements Copyright [email protected] 2019

If we improve value levels, for your product or service, to certain
currently useful levels, we become ‘competitive’.

If we improve value levels significantly beyond others in our mar-

ket, then we can offer superior value to stakeholders, which might
command their willingness to choose us, rather than competitors.

Competi- Market

Figure 1.10 : for the same function, the basic market or business, like banking, or plumbing, or Yoga
Training, you can plan to deliver a better level of one-or-more values (Market leading levels), to win
the business against the competitors.

But this must be a clear idea, well-delivered in practice, and with-

out sufficient immediate competitive response from your best
competitors! This is a process for winners only: having clear and
useful scales of measure, is a basic minimum tool, for this competi-
tive action. ‘Nice words and intentions only’, are for losers.

3.2 Minimal Scales.

Here are the minimum attributes of a Scale parameter specifica-
tion:

Page 24 of 291 Value Requirements Copyright [email protected] 2019

• Must allow scale numbers to have a ‘useful meaning’, when asso-
ciated with the scale,

• Should not be so short a Scale-specification as to leave critical

concepts undefined, or ambiguous to any reader.

Here are some desired attributes of any Scale specification:

• It should be intelligible to domain specialists,

• Should be a good reflection of the value, as perceived by the

domain specialists, and other relevant stakeholders.

Page 25 of 291 Value Requirements Copyright [email protected] 2019

So here are some reasonable, and simple examples: (prefaced
by a tag (‘Usability’, etc.), to give some context)

Usability:

Scale: % of users who can master the basics within first day of use.

Impressiveness:

Scale: % of people who took a test ride, who then joined a waiting
list within a week.

Example 1D

I am not saying these are as good as we can make them, but they
are ok for many purposes. They are not good enough for complex,
large, critical systems. But they beat most non-quantified value re-
quirement statements, like ‘very impressive’, or ‘highly user-
friendly’.

And here are some not so good examples:

Security:

Scale: Number of hacks.

Example 1E

Page 26 of 291 Value Requirements Copyright [email protected] 2019

Why? There is a failure to say more about ‘who’ did the hacking,
what ‘type’ of hacks, the ’time period’, the ‘object hacked’. Just too
many unspecified things.

Co-operativeness:

Scale: % of acceptances to join.

Example 1F

Why? Too many related conditions not defined here, like ‘join
what?’, What kind of Invitation? Over which time period?

Page 27 of 291 Value Requirements Copyright [email protected] 2019

3.4 Developing a Scale from an Ambition Level.
An Ambition Level is an informal statement of a requirement,
about one sentence long. It often comes from an ‘official’, at-
tributed source. The problem is that it is filled with ambiguous
terms, and does not lend itself to quantification. So it becomes our
job to clarify and quantify ‘His Masters Voice’.

We could of course complain that the source (our boss?) is sloppy.

But that would be unnecessarily undiplomatic.

Instead we should joyfully accept the challenge of articulating what

the power that be, said. After all, as I say:

He who taps the keyboard holds the real power.

Note that this Ambition translation process is essentially the same

as the design of a Scale from a User Story, as explained above in
‘Can User Stories be used?’

Here is an example of an ambition level:

Ambition: “before performance, Tesla prefers to focus on safety

first’ <- Elon Musk. 140319

Example 1G

And here is a Scale we can derive from that:

Page 28 of 291 Value Requirements Copyright [email protected] 2019

Scale: % average passenger safety rating by Euro NCAP

Example 1H. https://www.euroncap.com/en/results/tesla/model-3/37573

To derive that Scale we had to think:

• What kind of safety ratings give useful objective proof of safety?

• What units of measure are used in them (stars, % survival) ?

• Which units of measure, if there are several, serves our purposes

in this project?

• Some searching on the the internet (Tesla, Safety Ratings) might

give specific options of ideas.?

• Would the power-that-be (Musk) think this is a good scale of

measure for his purposes?

• Is our suggestion broad enough for purpose, or is it unnecessari-

ly narrow?

• Does it cover all market areas?

• Does it cover all types of the value (safety)?

Page 29 of 291 Value Requirements Copyright [email protected] 2019

The ‘level’ is missing!

There is a specification element missing in the Scale spec, which is

‘exactly where on the Scale we are targeting for the future’, our
Ambition Level.

We have (Scale) derived a definition of the Safety value, suitable

for applying (safety level) numbers. But we have not yet derived
the required levels themselves. So we have only done the first half
of the job of interpreting the Ambition Level. Let’s say we did the
‘Ambition definition’ part (the Scale); and now we have to turn to
specify interesting levels on that Scale.

We could add such a Level specification, and possibly derive it

from the Ambition quotation. This is a subject we will look at be-
low. But it might look something like this:

Goal 98% [Within 2 years, for Adult Occupants].

Example 1I

There are several weaknesses with the Scale I suggested above.

And I will discuss improvements below. But I wanted to make the
point about ‘deriving a scale from an Ambition Level’ .

This derivation practice can be done in a much more detailed way,

when the Ambition level is richer with various concepts (about
when, where, who, what). We can return to that after the next sec-
tion on Scale Parameters.

Page 30 of 291 Value Requirements Copyright [email protected] 2019

Page 31 of 291 Value Requirements Copyright [email protected] 2019
Figure 1.11 : Tesla-3 %-ratings from euroncap.com (URL op cit). We note they use a % scale.

3.5 Scale Parameters

If we want:

• Accurate modeling of large and complex systems

• The possibility of separating critical value-deliveries from less-

critical ones, which permits us to ‘do critical stuff early’.

• The possibility of much better definitions, so nobody can possi-

bly misunderstand (like contractors and suppliers, and even
managers).

Page 32 of 291 Value Requirements Copyright [email protected] 2019

Then you will want to improve the ‘resolution’ of the Scale tool.

Figure 1.12 : Each Value Scale is one of many dimensions of the system’s Value Set. Each Value spec
can have several [Scale Parameters]. Each [Scale Parameter] can have several attributes which are
used as requirement specification’conditions. I might call this Three-Dimensional Value Modeling.
Example from May 2019 Master Class, Warsaw planning exercise. Graphic Design Source:
[email protected], 2019

This need for improved ‘resolution’, using Scale Parameters as a

tool, is so common that I find I have to use it on almost every value
Scale, on every project, even seemingly small projects.

Page 33 of 291 Value Requirements Copyright [email protected] 2019

Here is an example: derived from https://www.euroncap.com/en/
results/tesla/model-3/37573

Vehicle Safety:

Scale: Star Rating number for [Person Type] and [Car Specs] for
[Safety Equipment] with [Alternative Model Validity] for a [Publica-
tion Date] by a [Rating Agency].

Example 1J

Perhaps you can imagine roughly what is happening with this

specification. It is intentionally quite readable for a domain special-
ist (car freak).

The terms in square brackets ( [Car Specs] ) are:

• Formally defined terms: The Capital Letters signal that they are
defined, somewhere

• General Concepts: defined with a specific set of elements, which

as a set, define the general concept.

• For example: People = {Babies, Children, Adults, Aged}. We are

going to sometimes use the set ‘{...}’ parenthesis, to list a set of
things. But sometimes this is not necessary for clarity, so we
drop it, for clarity.

Page 34 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.13 : a clip from euroncap.com safety report, URL cited above, which shows the actual struc-
ture of the ‘Safety Equipment’ concept in reality.

Here is an example of making use of the [Scale parameter] struc-

ture to articulate a target level requirement.

Wish: 5 Stars, by Next Year, Person Type = All, Car Specs= {Tesla 3,
RWD, 4 Door, 2019}, Safety Equipment= {Front Airbag, Belt Preten-
sioner, Belt Load Limiter, Knee Airbag, Side Head Airbag, ...}, Alter-
native Model Validity=Dual Motor AWD Model 3, Publication
Date=2019, Rating Agency= All.

Page 35 of 291 Value Requirements Copyright [email protected] 2019

Example 1K. A ‘Wish’ level is a stakeholder value target, which is not yet accepted by a project as
prioritized, feasible and economic (that is called a ‘Goal’ level commitment).

Read it slowly, and parse it, decompose it. Or see an edit below.

Here is a more-structured format

Wish:

5 Stars,

by Next Year,

Person Type = All,

Car Specs= {Tesla 3, RWD, 4 Door, 2019},

Safety Equipment= {Front Airbag, Belt Pretensioner, Belt Load

Limiter, Knee Airbag, Side Head Airbags, ...},

Alternative Model Validity=Dual Motor AWD Model 3,

Publication Date=2019,

Rating Agency= All.

Example 1L. Same as Ex. 1K, just spread out for readability.

We can specify any useful number of such statements, with any

useful valid combination of Scale parameter dimensions we want.

Page 36 of 291 Value Requirements Copyright [email protected] 2019

We can home-in on the most critical subsets of Scale parameter
dimensions, so that we can focus our energy on, and prioritize, ex-
actly the ones that have the highest value for us, especially in the
near term.

This might seem ‘complicated’ at first sight.

But it is in fact a way of simplifying very complex overall problems,

by allowing us to carefully extract something simple that we can
work on, and deliver some value improvements early, for critical
subsets.

Early partial value delivery is about ‘learning about complex reali-

ties’, before we commit to scaling up.

Page 37 of 291 Value Requirements Copyright [email protected] 2019

3.6 Defining Other Terms in a Scale
A Scale specification, will use the Scale Parameters, to give pretty
sufficient definition of the Scale Parameter terms.

For example (a definition of a Scale Parameter, in terms of a set of

things):

Person Type = Adult Occupant, Child Occupant, Vulnerable Road

Users, Safety Assist for Driver

Example 1M: The set of things that make up ‘Person Type’, serves as a definition.

But there may be other terms in a Scale specification which require

formal definition in our specification, to avoid ambiguity, misinter-
pretation (intentional, or not), and consequent problems, delays
and costs. But are not defined in terms of a set of things.

It is a necessary defensive practice, a risk-mitigation practice, to

formally define these terms somewhere. In the specification, or in
project-related glossaries.

The Planguage-agreed signal for formally-defined terms is, as is

also the case with Scale Parameters, that we use Capital Letters in
the words of the term, as a signal that a formal definition is avail-
able, or should be at some point. When tool support is used, such
words will appear as hot link words, one click away from the formal
definition.

Page 38 of 291 Value Requirements Copyright [email protected] 2019

Example:

Child Occupant: a person under 16 years of age.

Example 1N: Defining a ‘Defined Term’ with a straight definition; not using a set of things to define
it.

My personal practice, when someone asks ‘what does that word

mean?’ is to immediately and always, create a formal definition.

At least to Capitalize the term to indicate my intent to define later.

Merely answering orally is a poor practice, for obvious reasons.

Page 39 of 291 Value Requirements Copyright [email protected] 2019

3.7 Scale Libraries
The best scales of measure will be highly tailored to the local
project environment.

It can however help you, to begin the tailoring process, from pre-
vious examples.

These Scale definition examples are stored in several ways.

1. Previous projects in the same environment are potentially rich

with useful examples of Scales, and the experience of using
them in practice (think of the 21,000 Intel engineers and the
environment of chip architecture).

2. Some very common Scales of measure (examples Usability, Se-

curity, Maintainability) are published in books like my Competi-
tive Engineering book: see examples Chapter 5 at http://con-
cepts.gilb.com/Free+Download+Competitive+Engineering+-
+Chapter+5.

3. Some of these are digitalized in tools, like ValPlan.net

Page 40 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.14 : a list of ready-made Scales of measure (ValPlan.net tool). The ‘Maintainability’ scale of
measure was selected from the library of measures 2, and copied into the ‘Scale’ specification.

It can be modified if desired at this point. But at the least, with it’s 3 [Parameters] it is quite general
and can be applied for many detailed dimensions, which are up to us to define in detail. You can
continue to add to this Scale library with your own Scales, for reuse later.

Figure 1.15: The [Scale Parameters] from the Scale Library Template can be defined as you wish and
need. For example as above.

2 This set of Scales was directly derived from Competitive Engineering Chapter 5. http://www.gilb.com/

DL26

Page 41 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.16: In this ValPlan tool example, a Value specification, tagged ‘User Error Frequency’ need-
ed a Scale of measure.

We looked in the ValPlan library (copied from the Competitive Engineering book) and found a simi-
lar value called ‘Usability.User Error Rate’.

The Scale looked good enough, so we Inserted it into the User Error Frequency specification win-
dow. (Left background, in the Scale).

We are now free to modify it to taste. For example by making ‘User’ a Scale Parameter [User] and
then defining classes of User, like {Novice, Advanced, Coach}.

Page 42 of 291 Value Requirements Copyright [email protected] 2019

The Internet Library of Scales of Measure.

The internet has a huge collection of defined Scales of measure,

for almost anything you can imagine.

Search your favorite Value + the word ‘metrics’

Example ‘ice cream taste metrics’

Here is what I found: the first hit,

Figure 1.17 : Quality of Ice Cream Metric

Page 43 of 291 Value Requirements Copyright [email protected] 2019

So, before you say

• There is no quantification

• It cannot be quantified

• It is a ‘soft’ value

• I do not know how to write a Scale for this

Search the web for a pretty-good starting-point Scale.

There are always lots of options out there, and you can tailor them
for your use.

No excuses. All critical values can be quantified, with a defined

Scale, easily.

Try your interesting value (+ ‘metrics’) on your phone browser now.

Lots of professionals and academics have struggled with quantifi-

cation of the same values as you are interested in, and put their
experience on the internet. Use it for inspiration.

Page 44 of 291 Value Requirements Copyright [email protected] 2019

3.8 Multiple simultaneous Value Requirements
Real problems are not nice to you, they are not simple to under-
stand.

You cannot just focus on a single Value metric and forget about
any others.

You are going to have to normally ‘juggle’ ten or more value met-
rics at the same time.

If they all have well-defined Scales of measure: you stand a chance

of success.

If they are all in the fuzzy ‘Ambition Level’ condition: failure is guar-
anteed, in a stormy sea of confusion.

I recommend that you select a set of the top-ten most-critical val-

ue-requirements, to focus-on delivering, initially.

Keep all others, lower-priority values, on hold, until you have deliv-
ered the first group. (Reference B)

Page 45 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.18 : Example of Top 11 Values.

Source BCS Exercise Sept 2017, ‘London Congestion for Air Quality’. Notice that this is also a definition of
‘Project Value’ using the 11 decomposed different values, as the definition-by-subset.

3.9 Here is an example of a single complete

Value Requirement Specification, with all the
extra supporting detail we will discuss below.
Advance peek a real and complex example: to be explained in this
book detail by detail.

Page 46 of 291 Value Requirements Copyright [email protected] 2019

Figure. 1.19 : One of the 11 Values above (Fig, 1.18), Air Quality.

A Summary specification of 1-liners for each parameter. Using Planguage, and the ValPlan.net tool.

There are a few parameters in this example, which are not yet explained in the book. But they will be
explained.

But you can guess, look them up in the book glossary, and read them with some understanding.

Page 47 of 291 Value Requirements Copyright [email protected] 2019

3.10 Details of a Scale (Air Quality example),
with Scale Parameter Definition.

Figure
1.20 : Here is a view of the ‘Air Quality’ value spec with detail of the Scale. You can see that the Scale
parameters are defined as a set of attributes.

The ‘Area’ Scale parameter was previously defined, and reused here. The colored ‘Area’ is a hot link
to the glossary definition of ‘Area’.

Page 48 of 291 Value Requirements Copyright [email protected] 2019

3.11 More on Multiple Value Requirements
You might be worried about the advice to put aside, for the mo-
ment, some of the critical values, in excess of about 10 of them.

They will not be not forgotten! They are usually specified at some
level of detail in the overall planning. They are just intentionally de-
layed in time, so that we have a better chance to actually deliver
some higher priority values first.

If we try to do everything at once, then nothing will be delivered

early, and we increase the risk of total failure, by running out of re-
sources, political or organizational change, or by failing to learn
hidden lessons from the earlier deliveries.

Page 49 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.21: I took this photo June 2019 of a Western Norway River. Value delivery needs to be an
early and continuous stream of measurable value improvement. Quantifying our values is a neces-
sary first step.

We are not even going to deliver the ‘top ten’ values, all at once.
We are going to collect enough background information (like
stakeholders, risks) on them, to further prioritize some of them.

We are going in the direction of decomposition of both ‘values’,

and decomposition of their technical ‘solutions’, needed to deliver
those values, so that we end up with very early, and frequent, small
(2% of project resources at a time) value delivery steps. A ‘value
stream’ to stakeholders.

We are in a hurry to deliver critical real stakeholder value very ear-

ly, as a continuous stream of stakeholder value results.

We also want learn about the complex environment we are work-

ing in, so that we can apply those lessons forward; and to build up
our credibility, with the powers that be, for real value-delivery,.

Page 50 of 291 Value Requirements Copyright [email protected] 2019

3.12 Knowing when to decompose a value into
sub-values, using sub-scales.
Many of your attempts to find quantified value Scales, might be
delayed by the fact that your value concept is in reality a set of
quite different values scales, which have something in common’
Love is a many-splendored thing, as the song goes (ref. b)

There is an engineering heuristic that says ‘decompose the value

you want to quantify until ‘quantification is obvious’. This works
well.

Sometimes there just seems to be no quantification available, be-

cause you are at ‘too high’ a level of abstraction.

Earlier we showed that the concept of ‘value’ needed to be de-

composed, into many sub-values. Each with their own quite differ-
ent scale-of-measure.

This is often true the next level down: some of those 10 values are
going to need decomposition, before we can make sense of them
quantitatively.

It is very common to need decomposition.

We seem to think in terms of complex value ideas: like ‘love’ or

‘beauty’.

Page 51 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.22 : Examples of decomposition of higher level values into different-Scale sub-values.

Detailed examples of potential Scales of measure for these sub-values are given in the CE book. (1)

Some ‘values’ are simply ‘umbrella titles’ for a set of different values.

Sometimes, you have an option to decompose into sub-values, or to use Scale parameters to com-
bine the value ideas into one generic scale. Sometimes that is just a matter of taste or convenience.
The result might be the same

Page 52 of 291 Value Requirements Copyright [email protected] 2019

3.13 Good Scales and bad Scales.
Just because you found a way to quantify a value, with a scale,
does not mean you have a good-enough, and useful scale.

It means you have ‘quantified clarity’, and that the clarity may even
help you understand that is is clearly a ‘bad’ scale!

Good and ‘useful’ Scales of measure:

• Are strongly related to the ‘values of the stakeholders’ who care

most about that value.

• Might be more difficult to measure in practice, but you should

never choose a Scale because it is ‘easier to measure’. You must
first choose a relevant Scale, then try to reduce costs of mea-
surement. Cheap measures of the wrong scale are a waste of
time.

• Will be highly tied to the real environment, with plenty of neces-

sary [Scale parameters] to specify realistic and critical dimen-
sions of the value’s application or environment.

Once a client of mine chose ‘bugs’ counts as their primary quality

measure, because they were easy to measure: rather than system
(software) availability for the phone system they were building:
which they knew was far more critical (‘but we do not know how to
measure it’ they said). This was part of the reason they were 2 years
late to market. Micromanaging the wrong value. They got sorted
out in time to reduce delay to only 6 months.

Page 53 of 291 Value Requirements Copyright [email protected] 2019

By the way, if you have clearly defined a relevant Scale, it will nor-
mally not be too difficult to design a reasonable measurement
process to suit it. A ‘Meter’

The right Scales will feel good and relevant to real stakeholders
and domain specialists. Work with stakeholders until they are hap-
py with the Scales.

This is all related to the management interest in ‘alignment’ of your

plans with their values and objectives, at a higher level. Your values
must align with the next level above you. Clear real alignment is
the test of relevant value specifications. More later.

Figure 1.23 : alignment levels and related concerns.

Page 54 of 291 Value Requirements Copyright [email protected] 2019

Chapter 4. The ‘Meter’ Parameter

Figure 1.24 : Meters are sort of like this Weather Forecasting Stone. They tell it like it is.

With permission David Bishop (with beard), Photo, Tor Gilb, Hvitsten, Norway, 2019

Page 55 of 291 Value Requirements Copyright [email protected] 2019

4.1 The ‘Meter’ specification is a defined
process for measuring the numeric value level,
on a Scale.
A Meter Specification is not normally a ‘requirement3’ it is a way of
measuring the delivery level of the requirement in a project.

The Meter is very directly connected to the defined ‘Scale’ of mea-

sure. The Meter must measure exactly what the Scale defines. That
includes all its [Scale Parameters].

The ‘Meter’ question is not merely ‘was the value level required fi-
nally delivered’?

The really useful Meter will give us incremental progress reports on

the emerging value levels. It will be designed to give sufficient ac-
curacy at a low-cost, consistent with frequent use.

There is not merely one single test process for a value. There may
well be several for different purposes, with different qualities and
costs.

3 a customer, in a contract, can require defined test or measurement processes. In that case they are re -

quired.

Page 56 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.25 : the Meter is a direct reflection of the Scale. It measures along that exact scale.

The Meter has to deliver measurement of all aspects, including all

defined [Scale Parameters] of a complex Scale, at a reasonable
cost.

A Meter has to have necessary qualities such as acceptable levels

of automation, accuracy, credibility, repeatability, setup costs, and
legality.

At this ‘requirements’ level of specification, we might simply out-

line some major ideas of how to measure, and leave the final deci-
sion and detail to a professional test planner.

The most critical aspect of a requirement is the Scale and the fu-
ture required levels.

It is not strictly necessary to define Meters immediately, unless

they are contractually required. The measurement process can be
worked out later when we need to measure the value created. But
it is useful to sketch a reasonable possible process.

Page 57 of 291 Value Requirements Copyright [email protected] 2019

4.2 The Meter as a high-level test process: why
this is useful.
I do not practice detailed test planning in the Meter specification.
The details should be worked out by professional test planners. In
fact they should be able to improve upon, and override a Meter
specification.

The purpose of a Meter specification at this early, requirements

stage is:

• To suggest that reasonable measurement methods exist at all for

this value

• To suggest the possible accuracy, credibility and costs that the

measurement process would give us

• To make it clear that we are seriously intending to measure the

values delivered

• To give detailed test planners something to start with

• To make it clear if there are any mandatory constraints in the test

as part of the system requirements

• Privacy concerns

• Contractual requirements regarding measurement for payment

Page 58 of 291 Value Requirements Copyright [email protected] 2019

FIGURE 1.26: METERS.

Page 59 of 291 Value Requirements Copyright [email protected] 2019

4.3 The multiple quality and cost attributes of a
Meter
A Meter, like any test process, has a number of interesting quality
and cost dimensions.

The qualities must be sufficient for purpose, and the costs should
be as low as possible, for a defined set of required Meter qualities.

In a sufficiently advanced project culture it might be useful to

quantitatively state the Meter Value-Requirements (like ‘accuracy’),
and to design a Meter to be within them.

At least, there is always the possibility of designing the tests to use

the least possible resources: for example by using sampling, or au-
tomation.

Here are some of the quality Aspects of a Meter:

• Accuracy (is it close enough to the truth?)

• Relevance to its Scale

• Repeatability (same results each time)

• Sensitivity (to disturbing factors)

• Credibility (will people believe it and buy in)

• Legality (will it break laws, customs, standards, contracts?)

Page 60 of 291 Value Requirements Copyright [email protected] 2019

• Automate-ability

• Privacy (permission to snoop?).

Here are some of the cost aspects of a Meter:

• Detailed Planning costs

• Execution Costs

• Result analysis costs

• Presentation Costs

• Permissions costs

• Travel costs

Page 61 of 291 Value Requirements Copyright [email protected] 2019

4.4 Sufficient Meter Accuracy for Purpose
In early incremental stages of value delivery, high quality mea-
surement is not generally required.

It is sufficient to be pretty sure things are moving towards the re-

quired levels of the value, at a reasonable pace. At the extreme, 1-
digit accuracy of the % value-improvement might suffice.

One client of mine dropped measurement of weekly increments,

and left it to the very-experienced intuition of the system develop-
ers. At an earlier stage the same client decided to use no more than
30 minutes per weekly increment, to measure value delivery. For
Usability factors they even got lucky when Microsoft Usability Labs
offered to measure weekly, overnight, for free. (Ref. C,D). They did
take release quarterly of product upgrades far more seriously for
measurements.

Page 62 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.27 : Accuracy and other Meter concepts.

Page 63 of 291 Value Requirements Copyright [email protected] 2019

Chapter 5. Benchmarks

5.1 The purpose of ‘Benchmarks’ In a Value Re-

quirement Specification.
A ‘Benchmark’ level of value, on a Scale of measure, is background
information about a requirement level. It helps us decide if we
have set the real requirement levels appropriately.

This is traditionally something a Business Analyst should look at, as

a prelude to setting requirements.

But in Planguage, I decided that it was better to integrate Bench-

mark data with the requirements data.

• in order to make it possible for all reviewers and creators of a re-

quirement object, to decide for themselves if the requirement
levels are in reasonable proportion to the benchmarks

• To make it even clearer if the Benchmarks data is missing, or not

particularly credible, or up to date.

• To support incremental delivery, where Benchmarks need to be

updated, at each increment, not just in an initial Waterfall analysis
phase.

Page 64 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.28 Types of Benchmarking.

Page 65 of 291 Value Requirements Copyright [email protected] 2019

Figure
1.29 : 2 different ‘Status’, which is a type of benchmarking. Benchmarks are ‘background’ informa-
tion embedded in a requirement.

5.2 ‘Past’ as a Benchmark

A Past level statement is a fixed result at a fixed date. History of a
level which happened.

You can insert as many Past statements as are potentially useful, at

any time in the process. As new data occur for example.

Using Past level information we can better decide if our require-

ment levels are appropriate.

• are we planning to be good enough in relation to our own Past

levels ?

Page 66 of 291 Value Requirements Copyright [email protected] 2019

• And those of competitors ?

• Is updated Past level information sufficient to force us to recon-

sider planned requirement level specifications ?

Figure 1.30 : The Past data here for Greater London and Nitrogen Dioxide, are directly comparable in
the 2 Scale parameters, and the units of measure on the Scale. The requirement is for a 2x reduction
over a 5 year period. As it is now 2019, we need to ask if the Past data is up to date (at least 2018)
and if any progress has been made as a result of our project deliveries, if any. It is time to introduce a
Status specification to track progress.

Note: I am using examples using the ValPlan.net tool. But this tool is NOT a prerequisite for using
this method or Planguage. A Word Processor works fine (1, CE). Just more work.

Page 67 of 291 Value Requirements Copyright [email protected] 2019

‘Past’-level data is not necessarily from our own systems. It can be
from any system that might be useful to compare us with. Competi-
tors, and other industries using similar methods or architectures.

Page 68 of 291 Value Requirements Copyright [email protected] 2019

5.3 ‘Status’-level Benchmark: real time value
delivery tracking.
The ‘Status’ benchmark level is intended for use in incremental
value delivery, to track our own project progress, or lack of it, to-
wards required levels.

It can be used initially as a departure point, for tracking progress

on your very own system: an incremental baseline in the continu-
ous learning and re-planning process.

We can keep track of a series of Status, in the basic value require-

ment. But we can also track status as a graph line, based on feed-
back in increments after a value delivery for our system. Or both.

Figure 1.31 : here is Status used as an initial planning data, ‘where our system is before we start de-
livering value increments’. It is followed by 2 different Wish levels, which have slightly different
Scale parameter attributes, and different delivery dates. So the Wish levels are not completely com-
parable to the Status information. A signal that Status information might possibly be updated, to be
comparable, for those Wish conditions, if possible.

Page 69 of 291 Value Requirements Copyright [email protected] 2019

5.4 Record Benchmark
A ‘Record’ benchmark is information about some extreme level of
a value, good or bad.

It can be a Record level for us, or for others, like competitors.

The purpose is to stimulate us to be competitive with the best,

both of our competitors, and with those in other domains using
similar technology.

It is the sign of an expert that they know the Record Levels in their
domain.

Keep in mind that Record setters do not stand still, but are proba-
bly trying to improve on their record. It is not sufficient to beat the
old Record, you win by beating the new Record in the future.

We sometimes try to guess that using the ‘Trend’ parameter spec.

(See Ch. 5.6 below)

Page 70 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.32 : We added a Record, comparable, but for ‘Area = Oslo’, and it shows that it is possible
for a waterside city to get to a value level of 3. Well Oslo is not London, but what are they doing that
we might learn from, and are our desired value levels ambitious enough?

The ‘Record’ levels can be particularly useful, because if you ana-

lyze the technology used to reach the Record level, and the costs
incurred, you might come away with very useful insights.

Page 71 of 291 Value Requirements Copyright [email protected] 2019

5.5 ‘Ideal-level’ Benchmark
The ‘Ideal’ benchmark is rarely specified, since it is rarely attain-
able. Perfection tends toward infinite costs. If ever attainable.

So I use this mainly in oral discussion to point out unrealistic ambi-

tions. Unrealistic requirements.

Dangerous if they end up in a contract, as one of my Oslo Tech

business clients CEO found out to their horror. They had contract-
ed for 99.9999999% uptime for an airplane phone system with a
big international supplier. The CTO when I asked, said no-one in
the mother corporation had even done that, or knew how. So we
had to ‘adjust’ the contract, or go bankrupt. They succeeded with
the 100 person, 1 year, $20 million project after that adjustment.
Actually it was the first time they made a profit in several years. The
marketing chief had had no problems saying yes to the customer’s
‘Ideal’ . Salespeople get tempted to promise ‘Ideals’ which are un-
attainable. I assume they negotiated a more realistic availability
level (like 99.98%).

Case 1N.

People are regularly specifying things like ‘24/7’. Which sounds like
100% availability to me.

Engineers know they can’t do 100%. 99.998% is fine!

If necessary, specify Ideals formally, to erase all doubt.

Page 72 of 291 Value Requirements Copyright [email protected] 2019

Ideal: ZERO Pollution of any kind in London, ever and forever. Not
planned yet!

Example 1O.

Page 73 of 291 Value Requirements Copyright [email protected] 2019

5.6 ‘Trend-level’ Benchmark
The ‘Trend-level’ benchmark is an attempt to stop looking in the
rear-view mirror, and look out at the road traffic, coming up, ahead
of us.4

This is especially important in environments which experience high

rates of unpredictable change, from competitors, enemies, nature,
economics, technology, and politics. That is just about all of us to-
day, I guess.

Figure 1.33 : The 10 year Trend, if we do not act, is

50% worse pollution. Useful to remind people of the alternative to funding and supporting your
project. Don’t assume people know such things. Research it and spell it out explicitly.

4 Kai Gilb invented ‘Trend’, in connection with Ericsson assignments. Looking ahead is very important is

fast-moving competition.

Page 74 of 291 Value Requirements Copyright [email protected] 2019

6. Scalar Constraint levels.

6.1 ‘Tolerable-level’ Constraint.

Formal Planguage definition:

http://concepts.gilb.com/definition-Tolerable-Limit

The ‘most critical’ value requirement level is the ‘Tolerable’ level.

It defines the borderline between failure (below Tolerable, Intoler-

able ) and not-failure (Tolerable).

Figure 1.34 : the Tol-

erable Level, or Tolerable Range is just above the ‘Intolerable level, and is a range extending until a
‘success level’ is defined. It is possible to have Intolerable levels and ranges at both extremes of a
value scale, as in too hot and too cold.

Setting such constraints is mainly subjective. There is only rarely a

‘cliff edge’ at that point. But it is better to have clearly-defined fail/
not-fail borders, than to leave your team in confusion about the
borders.

Page 75 of 291 Value Requirements Copyright [email protected] 2019

This can easily have contractual implications, and you don’t want to
pay legal staff to argue in court about the meaning of ‘sufficient’
just because you did not make up your mind in the first place, in
the requirement.

People would be wrongly motivated if they focused on just getting

barely to the Tolerable level, at the edge of the border. Their main
motivation should be:

• To get well clear of the Intolerable area, quickly, immediately.

• To create a safety margin by being well-above the borderline.

• To relax further efforts here, this particular value, until all other
critical values, were also well clear of Intolerable dangers.

• Then to march on, towards target levels, like Goal, which define
success.

Page 76 of 291 Value Requirements Copyright [email protected] 2019

 1st Priority 2nd Priority

Figure 1.35 : Getting out of Intolerable levels of a critical value, is our first step. Then incrementing
the value until we reach all success target levels (like a Goal). If any resources remain, we can choose
to use them to increment values to more than ‘just barely’ success. Perhaps towards Stretch levels, or
to longer term, and special conditions, success levels.

Because our top-level critical values are ‘critical’, meaning ‘critical

for the entire system, product or service’, then as a rule, if even only
one single top-level value requirement, fails to reach the Tolerable
level, this probably implies failure of the entire system.

As a simple example, if all other top-level critical values are Tolera-

ble or better, and the availability of the system is below the Tolera-
ble level, say nearer 0%, then by definition none of the system
functionality is available, most of the time. And none of the other
value attributes, such as work capacity, usability, and security, are
available. So this describes total system failure.

The determination of the Tolerable Level is a matter for the rele-

vant stakeholders, and their practical needs and experience. At

Page 77 of 291 Value Requirements Copyright [email protected] 2019

what point do they throw up their hands and say “I give up”, and
use alternative ways to satisfy their needs?

The Tolerable Level might also be set by other stakeholder needs

such as legality, conformance to standards, economic profitability,
or a first rough guess at the right level.

6.3 Constraints are a Dynamic Prioritization Tool

Another insight into applications of the Tolerable Level is that it is a
powerful tool in helping us manage priority dynamically, that is,
managing ‘step by step as we deliver value’.

Once we have reached a single Tolerable level, we need to ask

ourselves (project management) if we should ease off on deliver-
ing more value, just yet, to this particular value.

We need instead to ask if any other critical values are still under
their own Tolerable levels, and divert resources immediately to the
task of getting all critical value requirements to at least Tolerable
levels.

We need to get the system into ‘Tolerable conditions’ with respect

to all critical values, before we plunge forward to satisfying Target
levels for the critical values.

Page 78 of 291 Value Requirements Copyright [email protected] 2019

 Fig-
ure
1.36
:
Sail-
ing
re-

quires
dynamic prioritization. Source: “To Catch a Butterfly: Epistimic Miracles of Serendipity. The.xel.io

http://te.xel.io/posts/2018-03-04-to-catch-a-butterfly-epistemic-miracles-of-serendipity.html

Page 79 of 291 Value Requirements Copyright [email protected] 2019

6.4. Several different Tolerable levels might be
appropriate for different circumstances.
One single value might well need to specify a variety of different
Tolerable levels for different circumstances.

This avoids over-generalization of requirements, with consequent

unnecessary costs for some circumstances.

And it supports our need to focus on particularly critical circum-

stances early, delivering value to those circumstances early.

Page 80 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.37: example with 2 Tolerable levels, with different deadlines.

6.5 There are other types of ‘Scalar Constraints’

Defined
In my books, (VP, CE) but this one is sufficient for most purposes.

Page 81 of 291 Value Requirements Copyright [email protected] 2019

Chapter 7. Scalar Target-levels.

Figure 1.38 : a target level is a value level we positively aim to achieve. There are varying degrees of
hitting the target. And there is such a thing as not hitting the target at all.

7.1 Wish-level Target

A ‘Wish’ specification is an expression of a stakeholder desire,
based on their needs and values. It is a ‘stakeholder target’, but not
yet qualified as a ‘project target’.

Page 82 of 291 Value Requirements Copyright [email protected] 2019

‘Wish’ belongs to systems analysis: what should this project con-
sider delivering? What would be valued most by the important
stakeholders?

There can be serious problems with Wish statements, which

means we cannot simply accept them as serious project require-
ments.

‘The customer is always right’, but they might not know state-of-
the-art limitations or have infinite time and money.

Stakeholders are allowed to dream and be ambitious, but not

every Wish is realistic, or is not consistent with other stakeholder
needs of higher priority.

• They might be unrealistic, technically and economically.

• They might steal resources from other more-worthy require-

ments and stakeholders.

• They are usually expressed without the stakeholder having any

overview of all other Wishes and constraints.

Wish statements are our formal acknowledgement that we have

analyzed the stakeholder needs, and recorded their desires.

But they cannot simply be considered serious project require-

ments.

Page 83 of 291 Value Requirements Copyright [email protected] 2019

They need to be analyzed, for technical feasibility and economics.

Then they need to be prioritized together with all other Wishes

(and Goal commitments), as part of the overall system, overall
economics, and overall priorities.

When ‘Wishes’ pass all necessary tests, feasibility, economics, pri-

orities - they can be converted to seriously committed require-
ments. Like ‘Goal’ specs.

To commit immediately to ‘User Stories’, and Customer Require-

ments, just because we want to respect them, is not wise.

It can lead to broken promises and hurt feelings, and even at the
extreme, total project failure. That is not true respect. We have to
be realistic, and we have to prioritize: always.

Once I
wished

Goal
Wow

Figure 1.39 : “Santa, I want a real Tesla X for Christmas, not a toy.”

The Wish must be a clear and detailed enough.

Page 84 of 291 Value Requirements Copyright [email protected] 2019

It is not good enough that the wish is almost always ‘Wishy washy’,
highly ambiguous, like a typical Ambition-level statement, or a
User Story. (see Ch. 15.1)

This is because you then, cannot really understand what is being

asked for, and therefore whether it is possible, economic, and what
its priority is.

So the Ambition Level still has to be translated into a numeric and

well-structured Scale, as discussed above.

And that is not all. You have to decide exactly which Scale parame-
ter attributes (who, what, where, and when) need exactly ‘how
much value level’. If not you still have a fuzzy question, and you are
not going to get unrealistic answers.

For example: if the Stakeholder says:

Ambition: I want the best security, to fight hackers, and protect my

customers and company.

Example 1P

Or

User Story: As a User I want good security, to fight bad guys.

Example 1Q

Page 85 of 291 Value Requirements Copyright [email protected] 2019

These are simply unacceptable statements:

Their possible range of value, and consequent technology inter-

pretations, is far too wide. The cost range is roughly zero to infinity.

Figure 1.40 : in this case I took the Ambition Level statement (“I want the best security to fight hack-
ers and protect my customers and company”) , and created a Scale for Security with appropriate
Scale Parameters (‘Attack Results’, etc.).

Page 86 of 291 Value Requirements Copyright [email protected] 2019

I then defined all 5 Scale parameters (Fig. 1.40) with a reasonable
set of attributes. Anything forgotten can easily be added later, as
we go.

Can you begin to see the need for detail in this Security problem?

The ‘Ambition Level’ hides all of it.

Page 87 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.41 : after defining the Scale, I
drafted my first Wish level. (Built on Fig. 1.40)

Note that it is a very small subset of all the Security Scale possibili-
ties.

That is good. I can focus on this slice of the action, if it is high prior-
ity and critical.

I have a fair chance to understand it, and find security options and
cost them.

Page 88 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.42 : So now I have my Wish specification. But I cannot possibly commit to a Goal (a ‘firm
committed promised value delivery from a funded project’) because I have not identified and costed
the necessary technology for delivering the Wish Level (42%) on time, 6 July 2022.

But at least the ‘Wish’ problem is much clearer.

We can understand, and discuss with our stakeholders on a much

more realistic basis, than with the Ambition Level.

Page 89 of 291 Value Requirements Copyright [email protected] 2019

7.2 Goal-level Target
We have, in Planguage, defined a ‘Goal’ specification as a project
level commitment to deliver that Goal value level, together with all
concurrent project Goal levels, by their individual deadlines, with
the currently allocated resources (money, time, equipment, etc.).

This is a specialized use of the term Goal, and not at all the same
as the many loose uses of ‘goal’ in other situations.

Having well-defined concept terminology is important for clear

and consistent thinking. One reason we write Goal with a Capital
letter, is to signal that it is a defined-concept term.

You are not at liberty, using Planguage, to use it with an entirely dif-
ferent meaning. That would introduce confusion, and lead to fail-
ures. At least then, don’t Capitalize it ! “We scored a goal”. “My
manager said he wants to have a meeting about his goals”.

As with all other defined levels on a Scale, you can specify as many
different Goal levels as is useful.

You can also add to the Goal specifications gradually, incremental-

ly, as you get experience and insight.

Our Planguage culture is ‘Evolutionary Incremental Value Delivery’.

Things do not have to be specified all up front.

That does not work well.

Too much, gets badly done.

Page 90 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.43 : Multiple Goal statements (tagged A, B and C).

Page 91 of 291 Value Requirements Copyright [email protected] 2019

7.3 Comment on the Multiple Goal Example
Above (Fig. 1.43).
• I tagged both the Wish, and a corresponding Goal, with a tag ’A’,
to make it more visible that they were related.

• And by ‘Tagging’ any Planguage statement, I can more easily re-

fer to it when presenting, or writing an analysis of the plans.

• Bullet points don’t ‘make the cut’ (work well). Nor do ‘yellow
stickies’ (kid stuff) in my world. Not even for early informal draft-
ing of plans. We live in a complex integrated world and digital
plans are the only reasonable tool for modeling it. Even just a
Text editor!

• It looks like we cannot achieve the A.Wish on time, but only a

level of 35%. (A.Goal)

• The good news is Goal ‘C’ (with exactly same Scale parameter at-
tributes as A) we can achieve a higher than Wished for level of
55%, later, in 2027

• And Goal B, the ultimate ‘All, All, All, All, All attributes’ Goal, all
security problems which are included in the Scale parameter de-
finitions (see above Scale detail), can be achieved in the year
2030. With current funding! If you want earlier results, you can
cross my palm with silver.

• The implication for all Goal statements is that we have done the
necessary ‘homework’. That means we have found a suitable ar-

Page 92 of 291 Value Requirements Copyright [email protected] 2019

 chitecture or design, that will give the stated Goal level, by the
stated deadline for the particular Goal level.

• We have in addition found that the ‘technology solution costs’

are within our ‘resource budgets’ (see later in the book, Chap-
ter 12), when regard is paid to all other Goal commitments in
the same time frame, or project. We know that because other-
wise we cannot commit a Goal.

Figure 1.44 Simple example of a 100x better Wish level than the Status benchmark.

• B.Goal is presented here in a detail window, so we can see

more detail.

• The others are summarized in a one-liner format. Except C.Goal

which has also been selected for display in fuller detail, in the

Page 93 of 291 Value Requirements Copyright [email protected] 2019

 ‘graphic summary arrow’ at the top. Which summarizes all de-
fined levels on the value Scale.

Page 94 of 291 Value Requirements Copyright [email protected] 2019

7.4 Stretch-level Target
A ‘Stretch’ parameter specification is an even greater level-of-suc-
cess than we dared to commit (in a Goal = commit) to initially.

We are not sure if we have the resources, or even technology, to

actually get to Stretch levels. But, Stretch means that some stake-
holder, sees some specific value, in getting to that level, sooner
rather than later.

So ‘Stretch’ is the 3rd Priority (1 = Survive (Tolerable), 2 = Succeed

(Goal), 3 = Surpass (Stretch level).

When all top-level critical factors have reached initial Goals, for this
point in time, you have formal permission to choose a Stretch level
of that value (or another value), and see if you can reach it, before
money, or time, run out.

Stretch can be treated as a sort of ‘Stakeholder Wish’, that we can-

not commit to (a ‘Goal’) in the current time frame. But we might just
get lucky! Exceed formal planned expectations.

Page 95 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.45 : Adding a Stretch level for the ‘A’ value conditions.

Page 96 of 291 Value Requirements Copyright [email protected] 2019

Chapter 8. Background Specifications.
‘Background’ Planguage specifications are added to the core re-
quirement (the ‘really required’ stuff), and intermixed with those
‘core’ requirements (Scale, Tolerable, Goal).

Background specs are part of a Planguage culture which believes

that rich ‘written specs’ beat ‘human memory’. Digital written in-
formation persists better, and allows ‘smarter’ apps.

This is true, as projects scale up, and become geographically de-

centralized. Simple ‘local group’ methods do not work any more,
like ‘stand up retrospectives’.

People have to find project information, and share their own

project-information wherever they are, and whenever they are
ready to do so.

The written info, and especially digital info is the right direction.

Specifications are not simply drafted, they accumulate, over time,

from many sources, and much feedback and learning. We need to
deal with the dynamics of this.

At the same time, even in the largest of projects there is a right

time for video face-to-face meetings, to build trust, motivate, and
ferret out project info, that needs writing down, to share with
everybody, sooner or later, if useful.

One data-detail can be the difference between project or value

failure and success.

Page 97 of 291 Value Requirements Copyright [email protected] 2019

 Capturing digitally is cheap, compared to forgetting a critical de-
tail.

I think it is important to distinguish between old-fashioned written

cultures (paper, copies, issued infrequently, available to few), and a
digital written culture (internet, app based, continuously updat-
ed, from anywhere on the planet, structured for automated analy-
sis, connected to intelligible data sets).

Some of the prejudices against written bureaucratic cultures (and

quite right these negative reactions were) were based on the
1990s pre-internet experiences. ‘Written’ is not what it was then.

Our Planguage requirements ideas grew up, digitally, but before

the internet, but by looking at the capability and potential of the
ValPlan.net app, we can see a powerful current capability, and also
a potential, for well-structured, well-defined requirements (and
other project specifications).

We detest unnecessary bureaucracy! But some degree of ‘bureau-

cracies’ payoff, and we have to know the difference.

Page 98 of 291 Value Requirements Copyright [email protected] 2019

 Figure 1.46 A Comparison of Written and Oral
Communication Attributes.

Source: (This source is worth looking at for

more detail).https://thebusinesscommunica-
tion.com/difference-between-oral-and-writ-
ten-communication/

I excuse the poor grammar and spelling! It is a

full set of ideas. And it makes the point that
the written/oral comparison has many factors
to consider. Even before we look at digitiza-
tion.

Most of the ‘Basis’ attributes could do with a

Scale definition. And then we could numerical-
ly evaluate the modes of communication (after
they too were better-defined and technologi-
cally updated).

Page 99 of 291 Value Requirements Copyright [email protected] 2019

8.1 The General Purposes of Background Speci-
fications.
The ‘Background Spec’ purpose is to enrich the requirement
spec with information, that

• Might never otherwise get specified

• Might be ‘lost’ in earlier or later documents, like slide presenta-

tions and Business Analysis

• Might not get used seriously unless they are ‘in your face’ in the
spec.

• Might be difficult to retrieve from other documents, or from hu-

man memory

• Might be well-known to some, but unknown to others

• Might be correct and updated for some people, but incorrectly

remembered and not updated for others.

• Is needed for ongoing, real time, incremental steps, of value de-

livery decision-making

• Is needed for risk management, prioritization, taking responsibili-

ty, motivation, reviewing efficiently: and any other purposes on
the path to successful value delivery, without being delayed by
poor decisions, based on lack of correct information.

Page 100 of 291 Value Requirements Copyright [email protected] 2019

• Is needed to enable automation of certain aspects of require-
ments, such as Quality Control, prioritization, presentation, and
risk detection. Yes AI. A complete Specification ‘Object’.

• Help to manage the updating and changes to the spec.

• Help us to follow our adopted defined Rules (specification stan-

dards for requirements)

Page 101 of 291 Value Requirements Copyright [email protected] 2019

 Core Figure 1.47 : Core Value specification, sur-
rounded by supporting requirement informa-
Value Background tion (background).
Value Spec

We have already encountered some Background Planguage specs

earlier in this book. For example Ambition, Type, Tag, Stakeholders,
Status, Level, Past.

User Stories have two kinds of background, built in to their struc-

ture: who is the stakeholder, and why do we need this requirement
(Justification, or Rationale). Good, but not nearly enough (Ref. A,
US). Simple, but ‘too simple’ for serious purposes.

8.2 Risk Management with Background Specs

Risk management means, reducing the losses in your scope of
work, due to any causes which might somehow be dealt with by
better planning, and by better plan specification.

Ericsson of Sweden had a deep insight when in their Quality Policy

(see quote in VP Book) they declared that risk management is the
job of every engineer, at all times.

I also believe that in the area of requirements, every little detail of

specification has a potential of unleashing, or ignoring, risks.

Page 102 of 291 Value Requirements Copyright [email protected] 2019

Risks which are very much larger in consequence, than any cost as-
sociated with reducing the risks. We do this risk management by
having more-solid requirements craft-capability. Attention to detail.

Let me be more direct. I believe that every detail in this book,

about Planguage Value Requirements, are potential tools for re-
ducing risks, systematically.

This is not a co-incidence. I am by nature a very risk-adverse per-

son, so I designed Planguage to deal with requirements-and-sys-
tems risks.

Let me use as an example: the major idea in this book.

Quantification of the Value requirements.

• If a Value Requirement is not quantified,

• you immediately incur a huge and unnecessary risk. I. E.;

• Nobody can understand the requirement, in the same way.

• People will waste time and money working towards their pri-
vate interpretation of the requirement (‘better security’).

• At worst, the entire project can fail for this one thing alone
(plenty of projects fail now)

Page 103 of 291 Value Requirements Copyright [email protected] 2019

Some other scattered examples of Background spec details,
related to Risks

• If the requirement is not tagged, giving it clear-long term identi-

fication, then it might be missed in test planning, and be deliv-
ered in failed condition.

• Too many value requirements are just bullet points on a slide

• Tagging a spec means we can reuse it, and avoid the risk of dif-
ferent copies or versions of the same spec.

• If we do not give the Source of a requirement, then quality con-

trol of its current validity, is less likely, and bad requirements
might get implemented.

• If we do not capture the Ambition Level and its source, then we

risk losing alignment with higher-priority objectives, and their
possible changes, like from new management.

• If we do not assign a Specification Owner to each single re-

quirement, there is a high risk that no one will be qualified and
motivated, to keep the spec properly updated, and to keep it
high quality. An ‘orphan’ specification, without an Owner.

Page 104 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.48 : some Background Specifications have been added to the Security specification. Owner,
Assumption, Issue, Dependencies, Risk, Rationale

Hopefully you can guess how such specs help us to see and man-
age risks

Page 105 of 291 Value Requirements Copyright [email protected] 2019

8.3 Prioritization using background specs
In my ‘Evolutionary Value Delivery’ culture5, all Value requirements
are not equal. We are going to start a stream of value improvement
deliveries. So we have to figure out which Value deliveries are
smartest to deliver early.

There is no simple method to help us decide what to do first or

next, which will be realistic, and give the most satisfactory results.
There are far too many different dynamically-changing factors,
which influence a prioritization decision.

So, our best suggested approach today is to collect prioritization-

information, directly in the requirement specification. This informa-
tion can be used to help you decide which Value levels to priori-
tize.

A simple example might be that Value X has 3 Stakeholders inter-

ested, one of whom is the Government, and Value Y has has 2
stakeholders interested, one of whom is your boss.

You cannot deliver both, in the coming time period, you must
choose one. What would your boss advise?

Wait, it is never so simple! Value X delivery has an estimated return

of 300% annually, and Value Y has only 120%.

5 The project management process known as Evo. See CE book Chapter 10: Evolutionary Project Man-

agement: http://www.gilb.com/DL77

Page 106 of 291 Value Requirements Copyright [email protected] 2019

The bad news is that there are many more factors to consider in
this case.

You can always simplify, and ignore those factors. But sooner or
later, somebody is going to ask why Factor XYZ was not consid-
ered (‘Sales with Potentially large new customers’, for example).

Prioritization can be complex6.

6Managing Priorities, A Key to Systematic Decision-making. With Mark Maier, 2005 (paper)

http://www.gilb.com/DL60

Page 107 of 291 Value Requirements Copyright [email protected] 2019

Automatic Value Delivery Prioritization

Right now we have enough digital data specification parameters in

Planguage and ValPlan, to automate a ‘delivery sequence prioriti-
zation’ based on:

• a set of many required values - total value effect

• A set of budgeted resource costs, money-time-people, one

time, recurrent

• The level of uncertainty of our estimates,

• This is after we have done a level of design, so we have real im-

plementable action steps for the values.

• And we have really today automated the priority sequence

choice, in our app. Anyone can do this on a spreadsheet too. You
just need the clear, digital, value-data.

This does show the potential for automated prioritization calcula-

tion (AI). But this calculation does leave out a large number of fac-
tors, that should be used to influence prioritization

At the moment, these other factors can be considered, manually, if

they are made visible and clear in the Background information of
the requirement specification. We do this now, with an eye to fur-
ther enhancing the information specified, to the point where it can
be used to make even better automated prioritization decisions for
us. (See Ref. E) My Deeper Priority Writings

Page 108 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.49 : an automated sort, best option at left, for delivering the greatest set of values, at the
lowest set of costs, with regard to risks and uncertainty.

Source: Masterclass, Katowice, exercise on spreading knowledge nationally. 2018. This chart uses data in
the Value Specification, along with a lot of other factors to optimize the flow of value for money.

Page 109 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.50 : we added 4 examples of background Parameters to the User Error Frequency Value
spec. Hopefully you can see that each one might contribute to a prioritization decision.

See: Stakeholders, Cost Impact, Value Impact, and Rationale

Page 110 of 291 Value Requirements Copyright [email protected] 2019

8.4 Responsibility and Motivation with Back-
ground specs

Figure 1.51 : This is a detailed window for the above Stakeholders spec, for the ‘User Error Frequen-
cy’ value spec, summarized above.

Page 111 of 291 Value Requirements Copyright [email protected] 2019

We now can see some more information about the roles and pow-
er of the stakeholders involved for this one value.

Figure 1.52 : the relationship between stakeholders and values is digital, so we can display it graph-
ically (automatic thick lines to show relationships). Useful when things get voluminous and compli-
cated.

That information is even more useful than just knowing the names
of the stakeholders.

There is already enough digital information in the ‘Roles’ cate-

gories to help us prioritize this value better automatically, when we
decide to write the code to use that data. We are moving in that di-
rection, as you see.

Would you prioritize Funders over Authorities?

Here, below, is a set of Planguage parameters added to the User

Error Frequency value requirements spec. These Background Value
Spec Parameters clarify and assign formal responsibility for differ-
ent aspects of the value requirement.

It is worth pointing out that we now have a practical tool for decen-
tralizing authority, for delegating authority, to people and groups
who are interested in having it, who have or will make the time to
do things properly, and are specialist in this area.

Page 112 of 291 Value Requirements Copyright [email protected] 2019

I have observed that the moment you put someone’s name on a
responsibility voluntarily, it gets taken quite seriously. It is their
baby and their honor! (See the Owner spec. Below)

Figure 1.53 : adding specific responsibilities, as Background statements, to a Value requirement.

Page 113 of 291 Value Requirements Copyright [email protected] 2019

Chapter 9. Making Use of the Value Specifica-
tion
The Value Requirement Spec is a set of data about the require-
ment, which can be exploited in many useful ways.

These are usually detailed in most of my other books and papers

(ref. VP, CE).

So I will briefly point out the connection below, and refer you to
other sources for detail (www.Gilb.com, VP)

9.1 Dialogue with Stakeholders

It is normal that more than a single stakeholder is interested in a
particular Value Requirement. It is normal that they have different
views of what is important about that requirement, such as delivery
date and level.

There is an apparent ‘conflict of interest’ here. And we need to re-

solve matters so that one stakeholder is not accidentally harming
the interests of another.

A good start here is that each Value systematically lists, as back-

ground information, all critical stakeholders for the value. Then we
can see explicitly who is interested, and consult with them to avoid
unnecessary conflict of interests.

Page 114 of 291 Value Requirements Copyright [email protected] 2019

In general, the more interested stakeholders are, for one Value, the
more political and funding support for delivering that value early,
and getting to some useful Value level.

Figure 1.54 : 3 different stakeholders might want different levels of a value. The solution might lie in
understanding more about each stakeholder’s rationale. But the outlines of compromise lie in the
fact that all stakeholders would welcome some increase in the value early.

Page 115 of 291 Value Requirements Copyright [email protected] 2019

As we all have experienced, people do not always know what val-
ue levels they will really need. They need more experience to know
for sure, and potentially surprising future changes, to their envi-
ronment, will force them to adjust their Wish levels.

So, we need to be flexible with regard to stakeholder real needs

for the lifetime of the system. The beauty with numeric, and digital
specification is that:

• It is easy to see exactly what was proposed and agree earlier

• It is easy to re-specify a change to the numbers, delivery dates,

and Scale Parameter conditions

• It is easy, by comparing numbers and specified conditions, to

see that something has changed

• Numbers do not lock you in to their digits, but they are the best
way to understand value changes, and their cost consequences.

There is an implication here, that the Value Requirements are not

simply a project plan, but are a process planning-and-change tool.

Probably useful as a living map of your system, for its entire life-
time. All the more reason to digitalize it, quality control it, and keep
it updated.

The Value Specification becomes the visible marketplace for all the
stakeholders to meet, and negotiate values and costs, for the sys-
tem lifetime.

Page 116 of 291 Value Requirements Copyright [email protected] 2019

Page 117 of 291 Value Requirements Copyright [email protected] 2019
9.2 Negotiating Priorities for Values
As discussed above, the more we know about a stakeholder, and
their reasons for Wishing for value levels, the better we can deter-
mine priorities: who gets how much first.

But it might happen that a stakeholder is not happy with a project

decision. Here are some options for you in that case.

• ask or analyze the stakeholder for more information about why

they need more value or value earlier, or in specific conditions
(who, where, doing what). Document your findings in the Value
spec Background statements, as detailed above.

• If the changed information deserves it, you can change priorities

on that basis.

• but you might like to inform other competing stakeholders, and

give them a fair chance to update their own arguments for value
and fast service, in the specification.

• At the very least you need to inform them of why they got re-pri-
oritized.

• Sometimes you need to point out to the stakeholder the means

by which they can up their priority: special funding, powerful
sponsorship, more active participation, better estimates of return
on investment, etc.

Page 118 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.55: negotiation with conflicting stakeholder interests is always a tricky business. But there
are a number of systematic tools that can help you: and thorough specification of the values and the
stakeholders, as suggested in this book, is a useful starting point.

http://news.mit.edu/2018/natural-resource-negotiations-for-mutual-gains-bruno-verdini-0621

Page 119 of 291 Value Requirements Copyright [email protected] 2019

9.3 Determining the higher-level value of value
increments
Let us assume a stakeholder wants an increment of a value, any
value, from 90% to 95% on any Scale.

We need to know two basic things about the increment, in order to

understand if it is a reasonable idea, for implementation sometime.

• what is the lifetime economic-value range, preferably in money:

but possibly in other dimensions like ‘lives saved’, ‘months
saved’, and ’reputation improved’. ?

• Then in addition: what is it going to cost? The upper and lower

range of lifetime costs (capital costs and operational costs).

This information will enable you to see if it is potentially worth-

while, ‘values for costs’, and how competitive it is with other op-
tions on your table.

There should be a clear advantage, even with lower range of val-

ues and higher range of costs.

If not, you need to refocus on more-promising options.

You can challenge proponent stakeholders to do another round of

thinking about values and costs, and come back with improved
numbers.

Page 120 of 291 Value Requirements Copyright [email protected] 2019

But you need to establish a clear policy of ‘deciding by numbers’,
about the profitability, or the efficiency, of value improvement
ideas.

Remind people that 100% perfect values will tend to cost infinity,
and never be worth it.

So we are looking for the best ‘deal’, the best return on invest-
ment, both in private and government sectors.

This might seem obvious to you. But I am constantly confronted by

managers and plans, that decide what to do, without any sort of in-
cremental value analysis, and without any lifetime cost analysis at
all.

They are of course usually ‘spending someone else’s money’.

But they are not really qualified to do so, without a little bit of
common sense, or better education, or better top management, or
whatever is lacking.

I refer back to the causes of failed Projects (Figure 1.8). Bad value
requirements communication.

Something is very wrong here, and this lack of efficiency-estima-

tion is part of it.

Page 121 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.56 : Gee I think I’ll change my mind about
the Solar Panels, and the Tennis Court

We need to use this kind of thinking about stakeholder value increments. Will it pay off?

Or ‘don’t even think about it!’

https://www.thesun.co.uk/money/7178628/home-renovations-affect-house-price/

Page 122 of 291 Value Requirements Copyright [email protected] 2019

9.4 Contracting and Proposals
A well-specified Value Requirement is absolutely mandatory when
soliciting proposals and estimates. No contractor can possibly es-
timate the cost of ‘high Security’. They need more detail to begin
to, even roughly (3X, 10X), estimate costs.

In fact if they make an estimate, and fail to ask you for more infor-
mation about your exact value specifications, then you are in dan-
ger of severe failure.

• They are either incompetent, they do not understand the rela-

tion between value levels and costs, or

• They are intentionally avoiding this, to get your business, but

plan to charge you much more when you reveal, after their first
botched delivery, what your hidden quantified value require-
ments actually were.

So put that clearly-specified requirement in your proposal. In their

face, up front. And make sure they understand that this is a legal
condition for their estimates, for acceptable delivery, and for pay-
ment.

Page 123 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.57 : Imagine if you provide something like this, in your request for a bid? Or maybe your
top ten critical values ? All attributes (for example above, ‘Evil People’, ‘Steal Money’) need defini-
tion.

Imagine if you were to make a contract for this with 100% payment
dependent of Goal level reached before the deadline.

Otherwise, ‘proportional payment’ applies.

For example, if 50% of increased value delivered in practice, then

50% of total payment for Security, is released to the supplier.

Page 124 of 291 Value Requirements Copyright [email protected] 2019

9.5 Handover to architecture and design engi-
neering.
Requirements, as you know well, are the basic input, the problem
formulation, for any process of design, or architecture, or design
engineering.

Unfortunately there are several ‘disciplines’ that do not have ‘clear

quantified value requirements’ as an input. These informal design
disciplines I encounter in management planning (only time and
money thinking), IT (we code, we found bugs, and have deadlines,
not value). And in IT Enterprise Architecture.

More worryingly, I found a complete absence of quantification for

the most important Artificial Intelligence International Standards,
led by top professionals and academics (c, XAI). The good news is
some of my friends there decided to listen!

Figure 1.58 : even IEEE manages to publish and accept vague fuzzy Values for deadly-serious sub-
jects.

Page 125 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.59 : here extracted from an Obama White House paper on AI is a classical example of total-
ly failing to define Values quantitatively.

I quantified them in anger (ref. c) using methods in this book.7

So there are too many planning cultures that are not mature
enough to understand, when they need clear quantified Value re-
quirements. You deal with them at your peril!

What can we do in practice?

You cannot hope to actually change immature planning cultures.

You can lead, for your own sake, and demand that critical values
are quantified.

7 Another example is my 2019 ‘Sustainability Planning’ book, based on bad goal statements for the UN

Sustainability Goals. See gilb.com books. ‘End Poverty’ is Goal 1.

Page 126 of 291 Value Requirements Copyright [email protected] 2019

And demand that they are used in your planning and supply chain.
If not, you lose.

Just observe.

Page 127 of 291 Value Requirements Copyright [email protected] 2019

9.6 Handover to testing and measurement, with
Value requirements.
Quantified and Scale-structured requirements should be a test
planners dream. Finally they are getting a clearer idea of what to
test.

But testing a variable Value will be new to some cultures of testers,

like IT, where it is mainly ‘test for presence or absence of functions’.

They might need to get some training and coaching.

In many cases a particular Value might be capable of having auto-

mated data collection for measurement, either from outside
sources (official statistics) or by internal system measurements
(user errors and response times for example). The more test au-
tomation the better.

You are invariably testing, or rather measuring, your system at a

higher level of concern than technical design: the critical value
levels.

There are fewer things to test (like 10 to 25 Values), and they effec-
tively summarize all design component impacts.

The system you are improving values for, is usually a living system
interacting with its environment.

Page 128 of 291 Value Requirements Copyright [email protected] 2019

In IT testing, if a function is there, it remains there mostly. So that
kind of testing is relatively simple. Testing variable values is more
challenging.

Figure 1.60 Value aspects.

In Value Testing these is a need for continuous life cycle monitor-

ing of the critical Values. Over the course of years.

Page 129 of 291 Value Requirements Copyright [email protected] 2019

Generally, value levels are getting better all the time, but they can
be disturbed by factors like load size, new stakeholders, new laws,
and new management ambitions.

Page 130 of 291 Value Requirements Copyright [email protected] 2019

9.7 Presentation and approval for steering
committees, based on Value Requirements.
No matter how detailed the basic Value requirement data is, there
are a variety of ways of extracting the significant core ideas, for
steering-committee decision-making, while holding open the door
for ‘drilling down’ to get more supporting detail, meaning more
background, when desired.

The digital requirement data can provide summarized graphics.

The requirement background data can provide a basis for recom-

mendations as to priority.

To a degree today we can do some quality control, on the re-

quirements specs, automatically, and more when we can afford to
use effort to program more controls, like ValPlan.

We can easily print lists of all outstanding risks, issues, dependen-

cies and assumptions, so they can be reviewed and dealt with. ‘Au-
tomated risk ledgers’ some would call it.

Steering committees can be supported when asking questions

like:

• what problems are outstanding?

Page 131 of 291 Value Requirements Copyright [email protected] 2019

• What is the ‘quality level’8 of our requirements documentation? Is
it good enough to exit to the next processes yet? (Like architec-
ture, estimation, test planning).

• Where are we overambitious in relation to our resources and

needs?

• What can we expect of Value level improvements in the short

term?

• Which stakeholders are giving us problems ?

Figure 1.61 : a steering committee needs data to see the whole picture,
all requirements and their consequences, to make better decisions.

8 often measured in Defects per page, Defect = standards violation.

Page 132 of 291 Value Requirements Copyright [email protected] 2019

9.8 Quality Control: of value requirements.
Quality Control (QC) means checking a specification against our
standards for best practices.

Figure 1.62 : the picture at the top of this book is from a

real Egyptian wall. Thebes. It shows QC in relation to a
standard. An ancient practice as you can see.

What Rules for Value requirement specification do you use? Many

have been taught to you already, in this book (for example ‘Define
a Scale’. Many are available in other books (CE). Many are built in
to the ValPlan app.

Page 133 of 291 Value Requirements Copyright [email protected] 2019

The most fundamental Rules for Value Requirements are:

1. They should be clear enough to test.

2. They should be unambiguous to the intended readership.

3. Value Requirements should be quantified.

4. Value Requirements should not contain solutions to achieving

the value.

When checking requirements (doing QC) for compliance with your

Rules, we call any violation of the Rules a ‘Specification Defect’.

We now have a simple way of measuring Value Requirements qual-

ity levels: ‘Defects Per Page’, where a page is normalized to 300
words. In a planning tool we could use Average Defects per Plan-
ning Object, where a requirement is a Planning Object.

It turns out that defects in requirements will cause delays and bad
specifications, and the problem gets 10x to 100x worse as time
goes on (Capers Jones, namcook.com). So it pays off a lot to avoid
them in the requirements phase. Remember the project failure ta-
ble at the beginning of this book (Fig. 1.8). All the problems were
requirements related.

Page 134 of 291 Value Requirements Copyright [email protected] 2019

By using Spec QC9 (VP, SI, CE books), a process we designed; and
measuring the Defect Density of requirements, we have a chance
to hold the problem under control. If we do not measure the de-
fect density, the problem will be wildly out of control (100 to 300
defects per page).

Most organizations have no idea about this, and that is one reason
why so many projects fail. The uncontrolled pollution of require-
ments, destroys or delays the entire project, when people en-
counter, and are forced to deal with the spec defects conse-
quences downstream, at high costs.

9 Specification Quality Control. ‘Agile Specification Quality Control,

Shifting Emphasis from Cleanup to Sampling Defects’, http://www.gilb.com/DL264, Paper in Text Experi-
ence.

Page 135 of 291 Value Requirements Copyright [email protected] 2019

9.9 Defect Level Measurement and Exit Control
How many defects is OK?

The answer varies depending on how high quality your products

and services are.

A bank client of ours, had 82 Defects Per Page (DPP), and brought it
down to 10 DPP within 6 months, thereafter aiming to get down to
about 1 or 2 depending on what paid off. There can be a lot of
money wasted, for a small defect, in a banking system.

The level you should be at (Defects Per Page) before you agree to
exit downstream, next process, is an economic question. What
pays off?

NASA and Intel have levels 10x better than 1 or 2 DPP at the bank.
They have a standard of maximum 0.10 defects per 300 words.
Mars landings, and Intel chips, have a lot of complexity and costs
in common.

The main reason we measure defects, is not to correct them.

It is to motivate requirements writers to do their job right (almost

no defects) in the first place.

This requires management leadership by insisting that these mea-

sures, and these exit levels, be taken seriously.

If management doesn’t get serious, they are incompetent to man-

age, in my view. They are allowing chaos, and waste, to flourish.

Page 136 of 291 Value Requirements Copyright [email protected] 2019

Of course part of the problem is that people are not trained and
informed about these things.

Page 137 of 291 Value Requirements Copyright [email protected] 2019

9.10 Management Reviews, in a Value Driven
culture.
The Spec QC process assures us that the basics of requirement
specification are ‘in order’. Intelligibility, consistency, and purity of
purpose (requirements, not ‘design which is falsely called re-
quirements’, which is a common malpractice)

We could say that Spec QC is one type of review. And that it

should be a basic requirement to pass this test, before moving on
the a more sophisticated type of review, at a management level.

For example a Steering Committee review, or a review for presen-

tation to a Steering Committee, or to management level.

Real World Review

A ‘Real World’ Review will be analyzing a fairly full set of specifica-

tion, for example all of the critical top level Value requirements at
once. And perhaps early stages of incremental delivery of those
value levels, week by week.

We should be able to assume that a management review specifica-

tion is not polluted with Rule violation defects, such as lack of clari-
ty to the reviewers. We need Spec QC and Exit at low levels of De-
fects, before management tries to review.

Real World Reviewers have as their highest purposes:

Page 138 of 291 Value Requirements Copyright [email protected] 2019

• to buy in to, approve the requirements as officially sanctioned for
further process, and progress

• To make sure all necessary elements are in the plan, so it has

completeness. All critical stakeholders, all critical values, all criti-
cal constraints. All risks, assumptions, issues, dependencies doc-
umented.

Page 139 of 291 Value Requirements Copyright [email protected] 2019

9.11 Estimation of resources to deliver Value
levels
There is a need for early estimation, and finally continuous re-esti-
mation of resources needs (time, people, money).

There is a need for estimation of the value impacts, at a high level

of planning, of the Values we plan to achieve.

For example what is the National Economic Effect of Saving Lives

in Accidents ?

The clearer and more-detailed our requirements are, the better

chance we have of making useful estimates.

But even then there are other factors, outside the Value require-
ments, that will determine the real resources needed.

We may still be wrong, about costs, by 3X or 10X, rather than

100X.

One initial factor, outside the direct control of the requirements, is

the design process (architecture, engineering design).

This is a topic of many of my writings (CE, VP) and I am avoiding it

here. But lets just say there is a thing called ‘Design To Cost’ and it
means that a really smart designer/engineer/architect can reduce
costs by 10X or more, just by coming up with a low cost solution!

Page 140 of 291 Value Requirements Copyright [email protected] 2019

So, you certainly cannot estimate real cost levels based on the Val-
ue Requirements alone. You can only begin to roughly get a pic-
ture of the costs.

Both design, and costing of specific designs, is necessary.10

Followed up by Dynamic Design to Cost, see Ch. 9.12 (Evo, IBM

Cleanroom, see VP CE, and below and (reference d)) to gradually
fine-tune real costs, and real value levels in the right directions.

10 See ’Value Design’, 2019. Gilb.com

Page 141 of 291 Value Requirements Copyright [email protected] 2019

9.12 The ‘Design to Value’, and ’Design to Cost’.
If value levels are unambitious, and resources are plenty, then any
fool can run a project without failing. But that is not why you are
reading this book.

In everybody's real world, the ambition level for high values is

pressuring us to go as high as possible, at the lowest use of re-
sources.

The only method I know about, which really copes with this suc-
cessfully is ‘Dynamic Design To Cost’. (See ref. (d) IBM Cleanroom
Method.)

That means you try to get off to a pretty good start, as outlined ear-
lier in this book. But then you have to decompose your long term
efforts into 50 or more Value Delivery Steps. I call this Evo.

At each step, we try to deliver a value improvement to the real

world, your customers, the taxpayers, a potential market. Then we
need to measure the value and cost results at each step. And com-
pare them to our numeric estimates, our expectations.

If they are about the same, all OK, keep delivering more value
steps. But, if there is a serious bad deviation in a value or cost, then
we have to analyze and fix the problem immediately. Before we
scale up, and compound the error.

This is one other place it is vital to have quantified and measurable

Value Requirements to navigate by.

Page 142 of 291 Value Requirements Copyright [email protected] 2019

This process is very much like any navigation process, such as sail-
ing the Seven Seas in 1492 or thereabouts. No GPS to help! Plenty
of navigation readings and course corrections. But it worked.

‘Get me to a nice place’ is not a good enough Value requirement

specification.

Figure 1.63: Egyptian navigator on sail ship. National Geographic.

Page 143 of 291 Value Requirements Copyright [email protected] 2019

Chapter 10. Presentation of Value Specifications
Value requirements need good presentation in different ways to
different stakeholders.

One reason is that many professional cultures are not at all accus-
tomed to Value Requirements, done so systematically, and mea-
surably, as we are teaching here.

They are accustomed to the fuzzy requirements (‘competitive agili-

ty’, ‘superior ease of maintenance’).

You are probably going to be a pioneer in this area.

Page 144 of 291 Value Requirements Copyright [email protected] 2019

10.1 Presentation to Stakeholders
Stakeholders need to feel they are listened to, and understood
correctly. They need to feel that we are really correctly analyzing
the most critical sets of Scale Parameter attributes (who, where,
when, what): the value sub-sets they need action on, in the short
term.

One presentation method is to start with the Ambition Level, and

its source or authority. Then show that the Scale is helping to clarify
and structure that Ambition Level, quite directly. Listened to!

Figure 1.64 : the lines connect the original Ambition Level statement, with the specific Scale Parame-
ters, and the Level

Page 145 of 291 Value Requirements Copyright [email protected] 2019

If you do involve some stakeholders directly, try some of the fol-
lowing:

• Ask if they would like to be the Owner of the specification.

• Ask if the required numeric level is good enough, by the speci-

fied date.

• Ask if the Scale Parameter attributes are a complete and useful

set. Are we missing any critical Scale Parameter attributes?

• Are there specification terms which could do with a formal defin-

ition, because they could be misunderstood by some readers?
what does ‘Useful’ really mean?

In other words, involve them to take ownership, at least by partici-

pation. Show genuine interest in their ideas: you are lucky to get

Page 146 of 291 Value Requirements Copyright [email protected] 2019

their ideas now!

Figure 1.65 : notice how rich the stakeholder picture is just for ‘5G’? Oh yes, even ‘users’ are there!

Page 147 of 291 Value Requirements Copyright [email protected] 2019

10.2 Value Requirements: Presentation To
Project Managers
The Value requirements should be presented to project managers
as their primary focus. The main criteria upon which they will be
judged, as project manager.

This might seem seem strange the first time they hear it.

Traditionally they have another focus.

In simple terms, get a set of tasks done and finish by the deadline.

But if you build the functionality (the ‘building’), and your actual
value levels are weak (security and safety are bad, and the eleva-
tors do not work), then you are in failure mode. The project is a
failure.

Building the functionality is very basic, you have to have it. But de-
livering the levels of values we planned (Tolerable, Goal) is the dif-
ference between success (All Goals met on time) and failure (any
Value is under Tolerable level).

This implies that the project manager needs to have regular mea-
surement, of the value delivery levels, and take action when they
are not on track.

Somebody has to break the news to Old Guard project managers.

Page 148 of 291 Value Requirements Copyright [email protected] 2019

From now on they will be judged by their Value Delivery rate, not
the ‘speed of doing tasks’.

Their client or manager has to take a clear position on this, and ask
if the project manager is up for the challenge. Manage Value.

Fig-
ure

1.66
:
This
is a
chart from conventional Earned Value Management. (See Ch. 15.3)

I do not recommend it, because it is using a very artificial idea of value. EVM is a method that does
not seem to understand how to define and quantify values, like ‘Security’, directly as we are teaching
here. Direct measurement of ‘Security’ itself.

However we can use this graph example if we edit the words slightly.

Actual Cost: I would replace with Resource Budgets Consumed.

I would include all resource notions (people, time, money, etc.)
and would especially budget and track future annual resource

Page 149 of 291 Value Requirements Copyright [email protected] 2019

consumption. Such as maintenance costs, and license costs. This
gives a much more realistic picture of the economics of the real fu-
ture system.

Planned Value: I would replace with Planned Values. Meaning a

summary of the set of Values (Security, Usability, Market Image,
and Employee Motivation, etc.). The sum of the stream of actual
numeric individual value improvements. This gives more direct
control over the critical values we want.

Earned Value: I would replace with Delivered Values, this would

be the measured increase in various values, as a set. One method
we use to give an overall single figure for this is to normalize all
Values, on a Scale from 0% (Baseline, status, no increment) to
100% (Goal level reached on time).

When the Project Manager, who we might rather call the Value
Manager, discovers negative differences in Values and Resources,
they can call in the ‘fixer’.

Like Robert Quinnan, Chief Architect in IBM Cleanroom method

(see ref. d, Cleanroom). Who will perform ‘Dynamic Design to
Cost’, and try to get the project back on track to delivering value
within resource budgets. This actually works remarkably well, even
on government projects, where EVM has a weak reputation, by
comparison.

I just got an email from one of my professional students today

(090719). Sad story. A Water Board project was determined to lie
and falsify project progress reports. Rather than actually deliver a

Page 150 of 291 Value Requirements Copyright [email protected] 2019

good project. They asked my friend to do so, falsify progress. He re-
fused and left them. A few years later, since the project never deliv-
ered the value that would have prevented it, the water got seriously
mixed with ‘bad other stuff’. And they were publicly fined £127 mil-
lion in penalties. I wonder if even that fine would wake up such a
corrupt management culture?

Page 151 of 291 Value Requirements Copyright [email protected] 2019

10.3 Value Presentation to Steering Committees
Steering Committees need the same Delivered Values / Resource
Budget information, as the Project Manager needs to keep track of.

In addition they need to consider decisions to get back on track,

when the Architecture’s intervention is not working well enough.

That could be a matter of

• better architect

• More resources

• Trade offs of some values for others more critical

10.4 Value Presentation to Spec QC Teams

The Specification Quality Control team is usually the same level of
people who are writing the requirement specification.

They do not need to take a position on the actual Value levels, or

costs. Their job is to check that they are following reasonable best
practice Rules, when writing specs. Clear, Consistent, Complete,
etc. Intelligibility for others to read the specs. Good technical writ-
ing.

So they need to understand that their job is fearless self criticism,

and to avoid exiting a spec, that will cause trouble, and embar-
rassment for them, downstream.

Page 152 of 291 Value Requirements Copyright [email protected] 2019

It is not actually so much a matter of fixing sloppy specs. It is more
a matter of letting the measurements motivate requirement speci-
fies to do incredibly much better work.

Fig-
ure

1.67
: Source (A, Terzakis). An industrial example of Spec QC used on Planguage Value Requirements, at
Intel.

In this example, a small Intel requirements team, using pretty much

the basic ideas in this book (Scale etc.) measured their own devia-
tion from their Requirement Specification Rules.

They started at a remarkably good 10 defects per page (600 words

= page, I recall) and are refused exit to next process.

Finally on 6th attempt, they produce requirements of the extreme

quality needed by Intel, and are allowed to exit. 50X better than

Page 153 of 291 Value Requirements Copyright [email protected] 2019

the initial submission. Overall project productivity improvement
233%.

Page 154 of 291 Value Requirements Copyright [email protected] 2019

10.5 Value Presentation to Architecture
Let us define the Systems Architect as whoever makes the technol-
ogy selection, all the stuff needed to deliver the Values, within Re-
source Budgets. And other constraints.

Here is the brief to them: (See ‘Value Design’, 2019, gilb.com)

• find a set of designs (the ‘architecture’) which arguably will deliv-

er the planned Value Levels, within the resources budgeted.

• document your ideas with estimates and evidence, on an Impact

Estimation Table (CE, VP) also called Value Decision Table.

Figure 1.68 : An Impact Estimation Table: Architect keeping track of value. The colored bars in the
middle are the estimated impact % of designs for value (lightbulbs) on the Value Requirements.

Page 155 of 291 Value Requirements Copyright [email protected] 2019

• Decompose the best options into independently implementable
designs, and sequence them into small increments, which deliv-
er real measurable value.

• Be available during the value delivery process, to adjust your de-

signs, so they really do deliver value as needed, at resource lev-
els we can afford. Like Quinnan IBM (reference d)

• Be responsible for maximizing values for resources, by design.

Page 156 of 291 Value Requirements Copyright [email protected] 2019

10.6 Value Presentation to Legal Team
Some of the Value specifications enter legal territory, when they
are the basis for a bid, or a contract. As they should be.

Figure 1.69: Legal Metrics.

Here is your message to your legal advisors.

• the Value numbers, and associated definitions (like Scale) are

necessary clarification of what we are asking for

• The legal team should be clear that they expect, and insist on,
such clarity for the critical Value aspects of the project.

Page 157 of 291 Value Requirements Copyright [email protected] 2019

• The legal team should point out (document it as a Risk in the
Spec), whenever anything is specified, which might potentially
cause legal trouble, in the event of a lawsuit.

• The legal teams interests should be indirectly represented by a

set of Rules for specification, which direct the requirements writ-
ers to do, what is legally smart.

• Aside from clarity, I would expect a legal advisor to be interested

in stakeholders, sources, and justifications.

Figure 1.70. Legalese

Page 158 of 291 Value Requirements Copyright [email protected] 2019

10.7 Value Presentation to Sub-suppliers
Sub-suppliers need to be made aware of your priorities for getting
the values delivered.

By connecting their payments to the progress of Value delivery,

you can be sure of their attention and motivation.

50% of Value delivered should get 50% of agreed payment.

With a ‘no cure, no pay’ agreement, the sub-supplier, who is tal-

ented at delivering real measurable value, should be able to earn
more, faster than any other method. If they cannot, earn more,
maybe you need a better sub-supplier.

When evaluating competing sub-suppliers, a little contest to see

who can really deliver measurable values, will sort out the winners
from the losers.

In One case involving Accenture and a Nordic Government, Accen-

ture earned so incredibly much, from a value-based contract that
the government was forced to beg to renegotiate the terms.

No need to over-motivate!

Figure 1.71 No Cure.

Page 159 of 291 Value Requirements Copyright [email protected] 2019

Chapter 11. Levels of Value Specifications
A Value requirement is directly related to a particular defined level
of a system. In general that means there are Values above it’s level,
to which it might contribute. There are Value levels below it’s level,
which might contribute to it’s own value degree.

It is very useful to be conscious of these levels, and to document

their relationships. It clarifies who is responsible for what.

This means taking responsibility for levels of value; for a specialist,

a sub-supplier, a stakeholder, or a manager.

Figure 1.72 : some examples of levels of responsibility.

Page 160 of 291 Value Requirements Copyright [email protected] 2019

11.1 Vision Levels, Vision Engineering11
Visions are the territory of top politicians and business , or society
leaders. Think Musk, Kennedy, Martin Luther King.

We can certainly categorize visions as the top level of Value re-

quirements. Everything which contributes to vision achievement is
related to them.

You could, at one extreme, say that everything below that vision
level is some kind of ‘design’ (or architecture, or solution) for
achieving that vision.

At least that is true for the Visionary, they have value requirements,
and everything that helps to achieve their vision, is clearly a solu-
tion to meeting those requirements.

However, just below the visionary is a hierarchy of vision-produc-

tion stakeholders. Each one of them has a set of their own level of
requirements, their own value requirements.

Each one of them has their own set of solutions to reach their re-
quirements. And some of those solutions, are in fact perceived as
‘requirements’ by the next level below them, in the value chain.

Let me try to summarize and generalize.

11 Value Planning: Top Level Vision Engineering” How to communicate critical visions and values quantita-

tively. Using The Planning Language. http://concepts.gilb.com/dl926. A 64 Page pdf book. Aimed at
demonstrating with examples how top management can communicate their ‘visions’ far more clearly.

Page 161 of 291 Value Requirements Copyright [email protected] 2019

One stakeholder’s requirements, are probably derived from the
stakeholder level above them, in the value chain. These same next-
level-down requirements are viewed as their solution, to fulfilling
their level’s vision (objectives, values) by the level above.

So, a planning specification, cannot really be categorized, once

and for all, as either ‘requirement’ or ‘design’. It is probably both at
once. It simply depends on the point of reference. Whose re-
quirement? Whose Solution?

Ends

Ends

Ends

Ends

Means =>

Page 162 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.73 : ‘One mans meat is another man’s poison’. Each level of concern, needs to find their
means to their ends. And typically that ‘means’ becomes the ‘ends’ (requirements) for the support-
ing level.

Page 163 of 291 Value Requirements Copyright [email protected] 2019

 My client
FUNDAMEN-
TAL
ME
STRATEGIC
Level

Supporting
my level
MEANS

Ends

Means =>

11.2 Fundamental Value Requirements

Page 164 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.74 : Ralph Keeney’s12 Levels Hierarchy.

Upstream from you, are your Fundamental-level demands. They

become your Strategic requirements, your own level of require-
ments.

There is the real danger that the Fundamental Means, your re-
quirements, are badly thought out, badly formulated. What should
you do? Blind obedience, or constructive change, with your help?

Downstream of your responsibility is the ‘Means Objective’ of

someone. Your helper’s task. If they reach it, that means your solu-
tion (their means objective) is ‘in the box’. Your value requirement
levels will be met.

12 Keeney, Ralph L. 1992. Value-focused Thinking: A Path to Creative Decision-making. Cambridge, MA

and London: Harvard University Press. ISBN 0-674-93197-1.

.
http://www.fuqua.duke.edu/faculty/alpha/keeney.htm/ The diagram is my interpretation of his ideas of
levels of concern.

Page 165 of 291 Value Requirements Copyright [email protected] 2019

Chapter 12. Resource Requirements Specifica-
tion

12.1 The need to understand the incremental

costs of value requirements before approving
them.
You cannot accept or approve a Value requirement, just because a
client asks for it.

Nor can you accept it, just because it can be achieved technically.

The Value requirement level must also be within your economic

constraints.

And it must be consistent with all concurrent other Value commit-

ments you have made, with the same total-project budgeted re-
sources.

So, as difficult as it is, and as untraditional as it is, we need to esti-

mate the ‘resource use consequences’ of any specified Value re-
quirement level. What will it cost in time, money, people? What will
be its recurrent maintenance costs?

Most people today skip this Value-level cost-estimation entirely,

and irresponsibly. But this explains why we have budget and dead-
line overruns as ‘normal’. Surprise! Shall we grow up yet?

As we shall see below, Value requirement estimation is quite diffi-

cult to do, accurately. But total lack of trying to understand such

Page 166 of 291 Value Requirements Copyright [email protected] 2019

costs, is not a responsible option. And, there are some reasonable
solutions, for responsible planners, which we shall discuss.

If you have no idea what the costs of a Value Level are going to be,
then maybe you need to make this clear to your client, up-front
(that you are incompetent and irresponsible).

For example:

“ We have no idea what your requested Value level will cost. We

are not even going to try to estimate it. With really bad luck it will
far exceed all existing budgets, and threaten your job, and cause a
public scandal. We can try to cover up, and blame someone else,
as usual. But we thought we’d let you know. We do have some in-
teresting less-risky options, like delivering value in smaller incre-
ments, and deciding to continue when the real costs emerge.”

Example 1R

I do like Confucius’ observation, that real wisdom

is knowing what you do not know.

Figure 1.75 : By Wu Daozi, 685-758. Tang Dynasty

https://i.pinimg.com/originals/77/95/19/7795198c-
c338e4642d2ce7ac965458b2.jpg

Page 167 of 291 Value Requirements Copyright [email protected] 2019

12.2 Some basic categories of Resource Re-
quirements
Resources are needed to pay for the future Value improvements.

Limited resources need to be budgeted, and we need to make

sure we do not plan to use more resource than we are allocated.

And that we do not use more resources than would ‘pay off’, be
profitable, be a good and prioritized use of scarce, limited, re-
sources. Those same resources are needed by other value re-
quirements, other stakeholders, and other projects.

Here are some interesting resource categories:

Up Front Costs: before producing Value

• Capital Costs Money

• Calendar Time

• Work Hours

Lifecycle Costs

• Money for recurrent lifetime operational costs

• System Maintenance, bug fix, port to new platforms

• Software Licenses

Page 168 of 291 Value Requirements Copyright [email protected] 2019

 • Premises and Hardware rental

• Training Costs

• Internet Costs

Design 1

Figure 1.76 : Example of 4 different resources being estimated, and then computing an overall ‘Sum
of Development Resources’. Each of the 5 columns is a different design, being considered. Source:
Technoscopes book, 47.

There are more resource types than listed above. The point is that
the higher our ambition level for value, the more likely we are to
drive up these costs for the system. So we have to keep track of
them. The purse is not bottomless.

The correct place to keep track of resources is during the design

phase, where the ’costs of designs’ needs to be estimated (see
above Figure), and designs with ‘low and controllable’ costs need
to be prioritized.

Page 169 of 291 Value Requirements Copyright [email protected] 2019

The design you choose contains, like it or not, a set of immediate
and lifecycle costs. We cannot remain totally unaware of cost con-
sequences of our designs and strategies; until it is too late and we
are irreversibly committed to expenditure, by contract or other de-
cisions.

Figure 1.77 : there are many dimensions to understanding cost impacts of your Value requirements.

Page 170 of 291 Value Requirements Copyright [email protected] 2019

12.3 The difficulty of estimation of costs up
front (ref. F)
If the availability level of a system goes up from 99.90% to 99.98%,
a mere 00.08% increase: how might that impact the building costs?
If I added, that it was for a ‘large national telephone switching sys-
tem’ (AT&T Electronic Switching System) ? The answer was 8 years
project duration, with between 2 to 3,000 people.

If you have no experience at that level, with that type of system, it is

quite difficult to make accurate estimates. But you have been
warned!

Fig-
ure 1.78 : The AT&T Case. Sources: Communications of ACM, and Former employees. PS 99.998% is
State of the Art nowadays the people involved tell me.

The interesting thing is that as we approach 100% availability, the

costs approach infinity, as all good engineers know.

Page 171 of 291 Value Requirements Copyright [email protected] 2019

In Barry Boehm’s COCOMO cost estimation method, there were
about 60 factors which were shown to be software project ‘cost
drivers’. This one, Availability, was only 1 of the 60. How many of
the 60 do you have historical data, for the cost levels of them?

12.4 The possibility of getting control over real

costs by design to cost
So for large, complex, hi-tech projects, the simple answer is, no-
body has a good answer for estimating it all in advance. If they
think they do, they have a secret they should share with the rest of
us.

More likely they are ignorant of the estimation difficulty, especially

when Value level requirements, in competitive environments, in
arms races, and beyond the state-of-the-art, are concerned. The
safe estimate is ‘near infinity’. Or very much more than you can
imagine.13

There is however one alternative approach, which is more likely to

be good management, and safe politics for you. It is the engineer-
ing paradigm ‘Design To Cost’.

That means we do not specify a system, and afterwards ask for a

cost estimate (‘near infinity’, is not an acceptable estimate).

13 Volume 13 Issue 2 of SQP journal - the March 2011 version.

http://www.gilb.com/DL460 ‘Estimation: A Paradigm Shift Toward Dynamic Design-to Cost and Radical
Management’

Page 172 of 291 Value Requirements Copyright [email protected] 2019

We need to get a very smart architect/engineer/designer who can
figure out how to bring the critical cost elements to ‘within your
acceptable budgets’: by choosing cost-effective designs.

Figure 1.79 : ‘Design To Cost’, as one possible process in cost management. All 5 processes are a
form of Design to Cost. Source https://jakamo.net/cutting-costs-driving-value-creation/

This can be as simple as ‘contracting outside’ at a really fixed price.

But it can also be done by reusing existing systems, rather than re-
inventing the wheel; or done by using radically cheaper new tech-
nologies, and there are quite a lot of other cost-effective options.

The purpose of estimation, asking for a cost estimate, is to try to

keep within ‘economically acceptable’ cost boundaries.

Design-to-cost will do that same job, better.

It is surprising:

Page 173 of 291 Value Requirements Copyright [email protected] 2019

• how many planning processes do not consider costs, or all types
of costs, at all (see Chapter 16 for examples)

• How many cost processes do not think about design-to-cost at

all. They do not assume that smart designers have great control
over various costs, and assign the designers to do the cost re-
duction task.

Figure 1.80 : More practical examples of tools to manage costs. Including ‘Design for Manufactur-
ing’. Source JP Romieu

Page 174 of 291 Value Requirements Copyright [email protected] 2019

12.5 The possibility of getting control of some
costs by smart ‘Dynamic Architecture’ and de-
sign
The best single cost management method I know about is the
Cleanroom Method at IBM Federal Systems Division (ref. d). Which
is, in terms of iterative learning, the same as my own ‘Evo’ method
(ref. Books CE, VP).

This was applied to military and space Software projects.

But I think you will find that it is the same as Elon Musk uses pro-
ducing Teslas, where he releases to production, about 20 changes
a week, half hardware.14 Half uploadable to my car at home.

The result at IBM was radically improved costs management from

previous methods. Instead of being always late, and over fixed-
price budgets, IBM was always on time and under budget, for
years on end, for named real space and military projects.

Basically IBM were using ‘design to cost’, except it was not ‘once off
at the beginning’. I call that ‘Dynamic Design to Cost’. It was regu-
larly at every increment, for 50 or more increments. In Tesla’s case, I
assume, weekly.15

14 as quoted from him in a biography. Ashlee Vance, Elon Musk: Tesla, SpaceX, and the Quest for a Fantas-

tic Future, Hardcover 2015, Paperback 2017.

15 Musk uses weekly increments at the factory production level, but software release to car owners is

about monthly. For new hardware, I had to buy a new Model S. But it had about 50x20 hardware incre-
ments, like 4WD, and autopilot, and many smaller tweaks, like to the music interface.

Page 175 of 291 Value Requirements Copyright [email protected] 2019

At every, real system, increment, costs and values are measured, as
well as possible, in the short term. If there is negative deviation
from plans and expectations, the architect (If necessary, Musk and
team, at IBM the Architect Robert Quinnan) dives in and fixes
things immediately, whatever the root cause of the deviation.

As a 2nd time Tesla S owner, I can tell you - whatever they do, it
works, on the incremental quality of the car. Half software, half
hardware. Detroit never dared do things like that.

Figure 1.81 : From my detailed years-long study of Musk and Tesla, it is clear that there is both an
initial Design-to-Cost for the main architecture, followed by ‘weekly-in-production 20 changes’. With
value improvement tuning, and learning rapidly what works.

Page 176 of 291 Value Requirements Copyright [email protected] 2019

The Tesla is only ‘half software’. So I get my car updates over WiFi.
And I must have gotten about 1,000 hardware upgrades when I
traded in my old Tesla for a New One.

Value Requirements at Tesla?

• Safety

• Build Quality

• Performance

• Owner Maintenance Costs

• And several more! (Comfort, ease of driving, emissions, styling,

scaling up production, automatic driving)

Page 177 of 291 Value Requirements Copyright [email protected] 2019

12.6 The possibility of getting control of the
value-to-cost ratio by decomposition; and then
by prioritization of high-efficiency designs.
By decomposing values, functions, and design components into a
more-detailed set-of-things, we can select a small fraction of the
total product or system, to implement incrementally.

This will give us real ‘value delivery’ to some stakeholders, for some
value improvements. But, at least as important, it will give us mea-
surable feedback about a large number of factors, so we can better
see what we need to improve, before we scale up, when imple-
menting the rest of our agenda.

Figure 1.82 : various decomposition

methods, so that we can learn reality early, and credibly, before scaling-up size or volume.

Page 178 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.83 : real planning example of decomposition and values/costs estimation, of the decom-
posed design ideas.

Page 179 of 291 Value Requirements Copyright [email protected] 2019

12.7 The possibility of getting control over
costs, by negotiated reduction of initial Value
level, and initial date ambitions
Sometimes the best way to get a cost reduction is the reduce the
Value level itself.

This does not have to be a permanent arrangement. The deal can

be that you will be able to raise the level later:

• when additional resources are available

• When a real customer is willing to pay for it

• When new market entry demands it

• When cheaper technology makes it more cost-effective.

• And it will never, you can promise, be lower than the improved
level stated in a ‘Tolerable’ level requirement.

This is called an engineering trade off.

Page 180 of 291 Value Requirements Copyright [email protected] 2019

Page 181 of 291 Value Requirements Copyright [email protected] 2019
Figure 1.84 : a ‘space’ environment view of multiple Values, driving multiple de-
sign options with multiple constraints, to find satisfactory balance.

Page 182 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.85 : With very many values, and very many international stakeholders, the trade-off process
is in play, in a risk management context.

Page 183 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.86 : here is a simple flow chart showing an iterative design and trade-off process, until sat-
isfactory costs are reached.

Page 184 of 291 Value Requirements Copyright [email protected] 2019

12.7 The possibility of getting control over
costs by Subcontracting
In the diagrams above, the possibility of getting control over costs,
by evaluating cost-competitive suppliers is hinted at.

This can be done by direct bidding, contracting, competition, and

asking them to do design-to-cost.16

But, perhaps the most important tool to do this with subcontract-

ing, and really save costs is, to use most of the advice about numer-
ic value requirements in this book. To protect your project against
cost reduction by means of undesirable value reduction.

Anybody can cut costs, if they are not constrained by real mea-
sures of values and qualities expected.

In addition, this Value Delivery needs to be proven incrementally,

rather than ‘all at once at the bitter end’. Avoid big surprises.

Sub-contractor cost control:

• all quantified and specified Value Requirements are in the con-

tract

• Payment is released when Values are achieved

16 Agile Contracting for Results The Next Level of Agile Project Management: Gilb's Mythodology Column

Agilerecord August 2013. concepts.gilb.com/dl581

Page 185 of 291 Value Requirements Copyright [email protected] 2019

• Work is done incrementally, so there is early and continuous
proof of capability to deliver value for expected costs.

• Bonus for more-than-expected cost reductions.

Page 186 of 291 Value Requirements Copyright [email protected] 2019

Chapter 13. Change Control of Value Specifica-
tions.
Just because we quantify and structure Value requirements, does
not mean they are chiseled in stone.

Change is inevitable and necessary. And quantified structured Val-

ue requirements are ready for systematic controlled change.

Here are some methods of managing change to Value Require-

ments.

13.1 The concept of a specification Owner.

A ‘Specification Owner’, or more precisely a Specification Object
Owner is a person or group given sole power to change a specifi-
cation object, such as a single Value Requirement.

Page 187 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.87 : ‘Eugene’ is the designated spec object (the User Experience Aka Usability Value re-
quirement) Owner. ‘Source BCS April 2018, Waste Management’

The spec Owner should:

• have accepted the Owner role voluntarily

• Be more than usually knowledgeable in the specific requirement

• Be interested in making the spec the best possible, over time;

motivated.

The spec Owner is responsible for:

• receiving any hints from any sources, like stakeholders, of the

need for corrections, updates, and changes

• Being password-enabled to actually do, and publish, any change

• Informing all instances, documented in the specification object,

all relevant stakeholders, of the pending change, and the actual
change (according to corporate guidelines for changes)

• Quality controlling, and reviewing changes, personally, or using

others, and using Rules for specification best practices.

Notice what this means:

• we have decentralized change control to motivated people

Page 188 of 291 Value Requirements Copyright [email protected] 2019

• Control is no longer at a committee level, a level that does not
really have time or interest in the many individual planning speci-
fication objects.

• You can use this decentralized responsibility to activate many

people, including juniors and trainees, to grow in experience
and motivation, into the larger planning system.

Page 189 of 291 Value Requirements Copyright [email protected] 2019

13.2 Annotation of change source, and time
stamps
I am pretty clear that we need to annotate the ‘Source’ of each in-
dividual element of a plan. At the same time it is a good idea to
get a time stamp for exactly when changes are made.

There are two change sources:

• the Spec Owner, or whoever actually keys in the change

• The information Source: ‘who exactly said 64%?’, or ‘London?’

Figure 1.88: A detail window of the ‘Ambition’ parameter specification.

Sources and change details are there.

A simple way of noting the source of any statement, is to use the keyed Icon ‘<-‘

Page 190 of 291 Value Requirements Copyright [email protected] 2019

For example:

Wish: 99% <- Tom

Example 1S.

And then there is the question of exactly WHY a change was.

Made, its justification, or background.

This justification is important because:

• We need to make sure the change is really justified.

• We need to explain to other stakeholders why the change is be-

ing made.

• Other stakeholders need to be able to argue about that justifica-

tion.

A simple way of adding justification information can be:

Wish: 99% <- Tom

Rationale: this level is necessary to beat competitors.

Example 1T

Page 191 of 291 Value Requirements Copyright [email protected] 2019

Figure 1.89: I used the Comment, in the Wish window to explain why the 99% level was set. An app
can support and remind people to document ‘Source’ and ‘Justify’, in more detail

In this case the example is a Strawman, an initial draft subject for

discussion, and improvement. Clearly not to be locked in and tak-
en seriously, yet. Hopefully it is obvious to the reader why this is
important to know, and know in writing, near the specification.

These background information can be backed up by specification

Rules, like

1. The actual responsible Source of all critical specifications will be

noted by personal name, position, or a group name.

2. All critical specification details shall be connected directly and

locally to a justification, or Rationale, for why it is specified ex-
actly they way it is. Even if the answer is that there is no good
reason yet. It is a wild guess or strawman. Be explicit about that.

Page 192 of 291 Value Requirements Copyright [email protected] 2019

Example 1T

Page 193 of 291 Value Requirements Copyright [email protected] 2019

13.3 Ways of controlling the whole of the speci-
fication
How can we exercise control over the entire Value Require-
ments specification ?

There are a great many processes discussed here for ensuring the
overall quality of the total set of Value requirements. And each
component.

Examples of QC-Supporting Processes:

• Specifying ‘background’ things which allow us to verify and un-

derstand a specification (sources, stakeholders, justifications,
comments)

• Giving power and responsibility to people, with their name on it

(Owners, Sources)

• Leadership: showing that you really care to do things well, and

knowing when not to overdo it, so it seems like a silly bureaucra-
cy. A ‘balance’.

• Retrospectives, root cause analysis, DPP Defect Prevention

Process (ref. G) will all bring out reasons for problems. Hopefully
‘root causes’, including not yet taking the quality of requirements
specs seriously enough. These analysis are your potential ‘war
stories’ to remind people of the value. of ‘doing it right the first
time’.

Page 194 of 291 Value Requirements Copyright [email protected] 2019

• Motivation and culture change takes time, and leadership.

Page 195 of 291 Value Requirements Copyright [email protected] 2019

Chapter 14. A Review of Requirement Methods
Compared to Planguage

14.1 General observations of methods for spec-

ifying Value Requirements
I am quite disappointed in the prevailing culture of dealing with
Values, and Value requirements.

That is why I have had to invent my own way.

The current unhealthy requirements culture is very widespread,

and new bad methods seem to spring up quickly and spread wide-
ly.

But our projects continue to fail, and part of that is bad require-
ments.

My central criticism is that most methods do not quantify the Val-

ue requirements at all. And the few that do so, do not do it well.

The following material, is for people who would like more-specific

background.

They might have to attack some Holy Cows in their ‘Temple’, in or-
der to deal with these problems.

Page 196 of 291 Value Requirements Copyright [email protected] 2019

14.2 A Checklist for understanding capabilities
of value requirement Specifications
Here is a basic checklist, I do mentally, to compare any require-
ments method with Planguage.

1. Is the Value Quantified (or is it just nice words?). (“Highly effi-

cient”)

2. Is a re-usable Scale of measure defined well, or is an over-

simplified badly-defined scale only hinted at, together with the
numeric level (“35% agree”)

3. Is the requirement tagged in some way, or is it just a bullet

point, a sentence, or sub-clause?

4. Is there any systematic way used to define terms used in the

spec, or are we left guessing at clarity and ambiguity?

5. Is there any structure in the Scale similar to our Scale Parame-

ters? How is this variation and definitions of (whom when, why,
where) dealt with?

6. Is there any way to annotate of capture the justification for a

requirement?

7. How do they capture sources of requirements ideas?

8. Is there any set of Rules for requirement specification which

could be the basic for Spec Quality Control: the defect level?

Page 197 of 291 Value Requirements Copyright [email protected] 2019

9. Is there any concept of measured Defect Density, which could
give a basis for Exit from the requirements process?

10. Does the process simply capture a raw ambition level require-
ment, and leave it at that, or is there an attempt to analyze it and
come up with a better clearer requirement.

11.Does the requirements process actually permit ‘designs’ to

sneak in as requirements, when the real requirement is un-
stated, implied, or badly formulated? (‘We want a password for
Security’)

12. Is there any concept of stakeholders for the requirements?

13. How good it the capture of background information, to help

understand quality, risks, relations, priorities?

14. Are Benchmark levels systematically captured (Past, Status,

Record, Trend)

15. Are the requirements suitable for digital automation? Can you
program visual presentations, and analyze the specs?

16. Is there a well defined classification and definition of re-

quirements types? (Function, Resource, Value, Mandatory De-
sign, Constraint, Scalar Constraint, Scalar Target).

17. There is more, but this list should separate strong Value spec
methods from weaker methods.

Page 198 of 291 Value Requirements Copyright [email protected] 2019

Chapter 15. SOME COMMENTS ON SPECIFIC
METHODS
Not all these following methods below are ‘requirements’ meth-
ods, as such. But they are related to Value Requirements in interest-
ing ways, and I want to share my observations with the reader, so
that they themselves in turn, can argue with others better about
the methods.

In some cases I have written a special paper in more depth about

the method, and I shall refer to it for detail, and just give the ‘high-
lights’ here.

15.1 User Stories (ref. H, a)

I commented early in this book about User Stories. They are at the
level of an Ambition Level, and we can use User Stories to start the
process of deeper understanding of the implied Value require-
ment. But User Stories do not pretend to go into depth them-
selves.

My good friend Mike Cohn (Mr. User Stories) specifically referred

to our Planguage methods, when asked on his website what to do
about qualities and quantification.

As I said, I like the fact that the User Story does not merely have a
‘requirement’ idea, but that it specifically includes information
about the ‘stakeholder’ (ok, ‘User’ only), and the justification (be-
cause)

Page 199 of 291 Value Requirements Copyright [email protected] 2019

As a method for ‘generating ideas about requirements’, and possi-
ble values and qualities, for small and less-critical systems (no state
of the art competition levels, no huge national health systems) user
stories are quite OK.

My problem is, that I see user stories being used way beyond their
‘level of competence’, and I think user stories, as a primary re-
quirements culture, are probably one initial cause of project fail-
ure.

Success and failure are not defined by user stories; they are more
of a detail. But as we have pointed out earlier, the Value level ‘Tol-
erable level’ defines a failure border, and Goal level defines suc-
cess.

User stories just do not deal with values and qualities, so we need
something more, operating at at a higher level of controlling the
system stakeholder results, values, and qualities.

My advice, if you are committed to using them, is to use them as an

Ambition Level, a simplified departure point, and then analyze
what the real, but implied-only, ‘value level’ has to be (derive a
Scale and a Wish for example).

Page 200 of 291 Value Requirements Copyright [email protected] 2019

15.2 Use Cases

Figure 15.2.1: Use Case

Diagram. Notice the ‘Actors’ (Admin etc) which we would prefer to make more general as ‘Stake-
holders’

Use cases are of course not complete requirements, nor Value re-
quirements.

They are in fact very close, but not identical to, what I call ‘Scale Pa-
rameter Attributes’.

Page 201 of 291 Value Requirements Copyright [email protected] 2019

 Space Cases

Page 202 of 291 Value Requirements Copyright [email protected] 2019

Figure 15.2.2: Compare this directly to the Use Case figure above. The 3 arrows point to Scale Para-
meters, each of which has ‘Space Cases’.

So we can now more clearly see what Use Cases are. They are es-
sentially Scale Parameter attributes, or for fun ’Space Cases’.

So my ‘Space Cases’ (a term I just invented to express the broader

scope than mere Use cases) are digitally integrated into the Re-
quirement Spec., and can cover a broader space category.

For example we could add such Scale Parameters as:

• Places (where, city, country, area, groups like EU, NATO)

• Situations (War and Peace, Recession, Brexit, Natural Catastro-

phe)

• Experience and education levels of stakeholders

• Event Conditions (ordered, confirmed, attempted delivered, de-

livered, for example)

• And any other dimension spaces you need to express as condi-

tions, for a requirement.

So my preference would be to not use the Use Case method, but

instead to integrate the basic idea of Use Cases into Planguage
with broader ‘Use’ Cases. In other words by using ‘[Scale Parame-
ters]’. :)

Page 203 of 291 Value Requirements Copyright [email protected] 2019

Page 204 of 291 Value Requirements Copyright [email protected] 2019
15.3 Earned Value Management (EVM)
I recommend this EVM overview

https://en.m.wikipedia.org/wiki/Earned_value_management

I would have hoped that EVM would deliver exactly what the name
implies. But it does not.

It does not deal with a set of critical Value requirements, at all.

It does assume Big Bang waterfall model pretty much, and ‘value’
is really just ‘work done’, or ‘tasks’, sometimes simply ‘% of budget
spent’ !

I recommend the blogs of a professional friend who spends his

time fighting for non-corrupted, honest versions of EVM in US
Government Projects, https://www.pb-ev.com. Paul Solomon, who
has written a book on the subject with another friend that I have
worked on several US Government Projects with, RalphYoung.

These guys are honest idealists, so you can trust what they say
about EVM.

Of course when a desperate Government, dictates EVM, in an at-

tempt to control greedy, and technically incompetent subcontrac-
tors, it gets used, and abused.

There is little EVM interest outside of those circles.

Page 205 of 291 Value Requirements Copyright [email protected] 2019

15.4 Functional Requirements and Non-func-
tional Requirements
My definition of ‘Function’, and ‘Functional Requirements’ (which I
call ‘Function Requirements’) is ‘what a system does’.

Similar to the Use Case Actor actions. What they do.

But I observe that there is little agreed discipline in using the Func-
tion term. It can easily cover any type of requirements. And as of-
ten as not, ‘function’ can be applied to what really are ‘design’. So
the situation is messy.

A ‘Function’ can be programmed by a programmer. So can some

designs. Both, functions and designs, are binary, present or absent.
Nothing in between. Both are testable, for presence or absence.
Both are in some sense, therefore, simple. 1:0.

People outside of IT do not seem to have a problem here.

When programmers were reminded that there were some qualities

they were not good at, like Usability, they observed that this was
‘not a function’ or design they could program. So, they solved their
dim understanding (of a Value) by calling it a ‘non-functional’ re-
quirement or attribute.

I have seen what they then do with this requirement category.

They specify it as ‘TBD’, to be determined, someday, when we fig-
ure out what it is.

Page 206 of 291 Value Requirements Copyright [email protected] 2019

One problem is that although people mean ‘qualities’ (and Values)
when they say ‘non-functional’: things are not so simple.

There are very many other requirement attributes to consider.

Figure 15.4.1: Planguage requirement concepts. From the ‘Competitive Engineering’ book. There is
Function, then Quality, and all the others which are not functions!

From this ‘Value Requirements’ book point of view, we are inter-

ested in all those system attributes which stakeholders value.

That is pretty much everything, including Functions. That is why

they are called requirements, I guess.

But this book has chosen to focus on the more-complicated value

requirement, because it is variable, and people have a problem
with variables. They don’t stand still.

Page 207 of 291 Value Requirements Copyright [email protected] 2019

PS the use of the term ‘non-functional’ is a dead give-away that
people have no real understanding of requirements.

Page 208 of 291 Value Requirements Copyright [email protected] 2019

15.5 Balanced Scorecard

Figure 15.5.1: a BSC with emphasis on Key Performance Indicators (KPI). This is the best of a lot of
bad examples. It does try to quantify, and has benchmarks and targets.

Source: Datapine.com

The original Harvard Business School, ‘Balanced Scorecard’ failed

in my opinion because it

• recognized there was an imbalance between financials quantifi-

cation, and non-financials

• But it failed to quantify the non-financials (as a norm, not an ex-

ception)

Later efforts have tried to be better at quantifying the non-finan-

cials, such as the example above.

Page 209 of 291 Value Requirements Copyright [email protected] 2019

But (BSC improvement efforts):

• they still fail at tackling the really critical values

• They admittedly prioritize things, which they find easy to quantify

(still ‘unbalanced’)

• They do not depart from the ‘really critical values’, and find a way
to quantify them

• Notice in the example above, the total lack of qualities, or any-

thing ending in in ‘-ility’ ?

• They are avoiding the issue, because they do not know how to
deal with it.

• Notice there are absolutely no product or service qualities in the

example at all.

• Notice there are no well-developed Scales of measure at all, just

highly-ambiguous ones. “Sustain Customer Retention”. OK as an
Ambition Level, but not as a well-defined Scale of measure.

• Some points for having both a Benchmark and a Target level. But
notice no constraint, worst-acceptable-case level (Tolerable). No
dates set on obtaining the target levels

• And notice a mystical “Likelihood of Reaching Target”, done

how? By whom? Any validation that it works?

Page 210 of 291 Value Requirements Copyright [email protected] 2019

Figure 15.5.2: example of someone’s idea of bank metrics in a BSC context. At this level they are just
name Tags. I wonder what real Scales of Measure would look like?

Figure 15.5.3: This example is getting closer to specified Scales of Measure.

Page 211 of 291 Value Requirements Copyright [email protected] 2019

Big US Government Bank Case (e)

I consulted with a large US bank, one that was key in the recession
of 2008. The top management were trying to use Balanced Score-
card.

They were tearing their hair out in frustration to try to make it work. I
saw their problem, and helped them solve it.

They were trying to communicate about a lot of ‘soft’ management

objectives, that were not defined well, no scales, and so everybody
had to ‘make up a definition’ in their own mind.

Their relief when I showed them how to do that, was immense.

The details are in the reference (ref. e). But it is the old story, no
knowledge or teachings yet, of how to define a concept with a
scale.

This is not merely a BSC problem. It is a widespread cultural prob-

lem.

In this case it was at Harvard Business School that BSC was devel-
oped and published. But, I find that no business schools, which I
can identify, teach managers the skills of this book: how to define
any Value Scale.

Yet if we do as advised earlier, just search the internet for things

like “Bank Employee Efficiency METRICS”

Page 212 of 291 Value Requirements Copyright [email protected] 2019

We get far more interesting metrics and insights than the BSC
above. https://www.clearpointstrategy.com/bank-kpis/amp/

Page 213 of 291 Value Requirements Copyright [email protected] 2019

15.6 Quality Function Deployment (ref. I)

Figure15.6.1 : typical QFD and House of Quality example from www.

Just about everything is wrong with this method. I used to joke in

my classes and lectures that QFD is so bad that it must be Ja-
panese Fake News to destroy western industry. The fact that Toyota
really did that intentionally, fake news to fool Western Industry,
was revealed to me in 2018 (ref. f).

The above visual example is filled with badly-defined values, and

subjective judgements. See the references (I, f) for details, and see
the checklist above. But it looks so systematic!

Page 214 of 291 Value Requirements Copyright [email protected] 2019

The shocking thing from my point of view is that this is taught at
universities, without any critical points against it being made.

The mentality, is, ‘well they used it at Toyota, and Toyota make
good cars, so it must be a good method’.

I’m told Toyota workers eat once a day at least, so that must be a
good method for success too.

Page 215 of 291 Value Requirements Copyright [email protected] 2019

15.7 Togaf

Figure 15.7.1: Requirements are, formally, central in the Togaf Architecture Method.

There is much talk in Togaf of quantification, stakeholders, assump-

tions, constraints, KPIs, and Success definitions. But it is difficult to
find any detail, of what this means in practice.

Page 216 of 291 Value Requirements Copyright [email protected] 2019

 Fig-
ure 15.7.2 : Here is the best concrete example I could find, on the internet, of Togaf requirements
practice. Just above this example, is text about ‘quantified requirements’ being mandatory. Do you
see any quantification?

I see some kind of an ‘Ambition Level’ (“Consistent Behavior”,

“...Capability”) buried in the name tags.

I also see the usual combination of a sort of requirement (“Digital

Customer Management Capability”) together with a suggested
technical architecture (“the data acquisition and data analysis ca-
pability”). Bad combination: vague ends and suggested vague
means!

I have also seen Togaf practice amongst my clients, and my Archi-

tecture Engineering course students. I was never impressed. Just
disappointed in the practice.

My conclusion regarding requirements for Togaf is that the quanti-

fied practice they recommend, and I agree with, is simply not
taught or practiced.

Page 217 of 291 Value Requirements Copyright [email protected] 2019

When architecture rests on such a bad ‘requirements foundation’,
the result must be disappointing.

Togaf people are of course welcome to adopt the ideas in this

book. These would conform with many of their stated ideals. No
extra charge, just credit your sources.

Page 218 of 291 Value Requirements Copyright [email protected] 2019

15.8 Zachmann Framework

Figure 15.8 : Zachmann framework mapped to US DoD Products.

I confess to a weakness for Zachmann. His framework covers a lot

of bases, a lot of the system.

As this figure reminds us, we cannot expect much detail of a

framework. It is up to the user of the framework to fill the intersec-
tions with specific methodology.

The Capability Maturity Model, level 4, was explicitly (Ron Radice

IBM) based on my Software Metrics (1976) book, quantification of
qualities and values. So that is an example of these Value Require-
ments ideas in this book, put in any framework (CMM, Ch. 15.14),
you like.

Page 219 of 291 Value Requirements Copyright [email protected] 2019

15.9 UML: Unified Modeling Language
Fig-

ure
15.9: a set of UML modeling diagrams.

UML models a lot of things, but values, costs and qualities are not
amongst them.

From my point of view this makes UML, and many others like it,
quite inadequate for modeling the real world, and some of its
most important aspects (Values, qualities, and costs).

I believe this is due to the built-in in narrow-mindedness of a com-

puter-programming culture, where the program can be construct-
ed without reference to costs and qualities.

Page 220 of 291 Value Requirements Copyright [email protected] 2019

15.10 Design Sprints (ref. g)

Figure 15.10.1 : Design Sprint 3.0

Design Sprints (1.0, 2.0, 3.0) are getting better, but they do not
have any concept of quantification of Values as requirements. It is
still a yellow-sticky culture, where the emphasis is on finding an
app or web design, rather than departing from a clear set of multi-
ple Value and constraint requirements. Maybe good for simpler
problems: but I have looked and not found any studies comparing
Design Sprints to anything else, for example in terms of project
success, productivity, value for time spent.

Planguage offers a similar better startup week idea: The Project

Startup Week (ref. K). It has been applied to large banking, aero-
space, and defense projects successfully for decades.

Page 221 of 291 Value Requirements Copyright [email protected] 2019

15.11 The ’Evo’ Project Startup Week (ref. K) :
Values Driven Start
The Project Startup Week is fully compatible with the Value Re-
quirements ideas in this book.

Day 1: Top 10 Critical Project Requirements Quantified

Day 2: top 10 architecture (design) options on the table

Day 3: Estimation of all designs impacts, on all Values and costs

Day 4: Decomposition of big designs into smaller ones, and selec-

tion of a high value-to-cost design-increment to implement in a‘
sprint’ next week.

Repeat every week, Step 4, to increment towards the Value Goals.

Fig-
ure 15.11.1 : The Evo Startup Week focuses on quick stakeholder value production, measurably.

Page 222 of 291 Value Requirements Copyright [email protected] 2019

This startup is primarily driven by a set of quantified critical stake-
holder values.

It does not try to get a mock-up, or prototype, working in the first

week. It tries to get real measurable results, a value stream, with
currently existing products, services and systems.

It tries to learn by stakeholder feedback, and incremental mea-

sured results, what works, and what does not.

Figure 15.11.2 : The best 5, of 25, measurable Value improvements in 1st release, 12 weeks of in-
crements, from. Start of using the Evo Incremental Value process, after a startup week to quantify the
25 Values most critical. Source, Confirmit.

Page 223 of 291 Value Requirements Copyright [email protected] 2019

15.12 OKR (K) Objectives and Key Results.

Figure 15.12.1 : an example of OKR planning. Notice the objectives are not quantified and clear
(“Create an engaging newsletter”). The ‘Key Results’ are not business results, they are individual
tasks (Interview 3 people”), which the individual assumes (hopes?) will produce the vague objective.
Good luck!

I have no problem with OKR as a way to make individuals and

small groups plan their weekly work tasks. Maybe it is a good
thing?

But I have had problems finding any studies of OKR, and even
good case studies, which illuminate the values we get for the costs.
What was the result at Intel? Do they still use OKR?17

OKR is in no way a replacement for Value Requirements, which op-

erate on larger systems (products, organizations, services) and

17 From Erik Simmons, July 2019: “During my tenure, OKRs were still used, but many teams had shifted to

(or added) Landing Zones, which had elements of Planguage (and our training recommended using full
Planguage behind each LZ row for clarity). Some teams still used OKRs to drive time-based behavior at the
quarterly or yearly level, perhaps out of cultural inertia (though that was relatively low at Intel overall).”

Page 224 of 291 Value Requirements Copyright [email protected] 2019

guides us to find ways to create measurable value in the short and
long term.

For clarity, I do not think that our Value Requirements methods are
appropriate for this level of individual task planning.18

I would like to think that these same individuals, are all part of
some larger projects, and that they are interested in, and commit-
ted to, improving Value requirement levels.

Values
Project

OKR OKR
Angela Alan

Figure 15.12.2: Individuals and small teams need to be well aligned to a higher ‘project’ level set of
quantified Value requirements. OKR might help individuals with tasks, but it has not been designed
and practiced to directly align with a higher purpose. This could well be because the higher purpose
(Value Requirements) was never well-defined at all: as most of the methods in this part of the book
fail to do.

18 our tool ValPlan.net does support task planning.

Page 225 of 291 Value Requirements Copyright [email protected] 2019

15.13 MoSCoW: Prioritization Method.

Fig-
ure
15.13: a presentation of the MoSCoW prioritization method, which tries to bring in financial and
market factors in the decision-making.

Prioritization of actions is necessary when resources are limited, as

they always are.

I am not impressed with most well-known prioritization methods,

this one included, and especially fixed-weighting methods, as are
found in for example Balanced Scorecard, and Quality Function
Deployment (see above BSC, QFD).

But I’ll admit that bad prioritization methods are better than none.

Page 226 of 291 Value Requirements Copyright [email protected] 2019

Here are some points about prioritization (ref. E)

Methods for simple short-term prioritization might need improve-

ment for large, complex, critical projects

There are a variety of different resources that might be considered

in priority decisions (time, staff, capital cost, reputation, hardware
capacity, and many more). Even combinations of resources might
be considered.

We need to be clear about what is being prioritized. Most methods

seem to assume it is features, functions or User Stories: all of which
are a bad idea.

I think if stakeholder critical values are the main point of all

projects, then we need to prioritize getting to the Value require-
ments, and stop when we get to one. Then re-allocate resources to
reach other value target levels which are not yet satisfied.

I think asking a single stakeholder, or a Product Owner to choose a

priority is a bad idea (but better than none) because they do not
have an overview of the rest of the stakeholders needs, and the re-
source situation in the future for the project.

In short I think priority needs to be computed logically, with deliv-

ery-step by delivery-step, based on an overview of the critical de-
cision factors.

MoSCoW is for projects that do not understand or plan critical val-

ues quantitatively. It is not for large or complex projects.

Page 227 of 291 Value Requirements Copyright [email protected] 2019

It is path to failure I would guess.

Page 228 of 291 Value Requirements Copyright [email protected] 2019

15.14 CMM: CMMI, Capability Maturity Model

Figure 15.14: CMM is a tool for assessing the maturity of an organization and its working processes.
19

PS Good suppliers should get well paid for value delivery,

incrementally.

Forget ‘Maturity Levels’, for organizations.

Focus on Value, performance now, let organizations figure

out what to do themselves (their cost-effective processes) to
get paid: The Free Market of Competence, I’d call it.

19 The CMM level 4, ‘quantitatively managed’ is mainly based on my 1976 Software Metrics book ideas,

according to Ron Radice, who invented it at IBM. But I think the focus on development processes, rather
than stakeholder value, is a mistake. We need stakeholder value first, and process cost-effectiveness sec-
ond.

Page 229 of 291 Value Requirements Copyright [email protected] 2019

Chapter 16. A Briefing on Use of Value Specifi-
cations for Design and Architecture
Value requirements are obviously just the initial step in a process of
value delivery to stakeholders.

The next step is to exploit the Value Requirements in order to find

out exactly how we are going to deliver the values at acceptable
costs.

This process is known by a variety of names: design, engineering,

architecture, strategic planning, problem solving, and many more.

But the design process attempts to answer the question: what can
we do in practice, to deliver the Values required?

An approved set of critical clear complete Value requirements, sets

the stage, for a dramatically better way of doing the design
process.

Value requirements allow us to take a very systematic quantified

approach to the design process: something which is logically im-
possible without the Value (and costs) quantification as the base,
the foundation stone.

Put another way, we can now ask and answer the question:

“exactly how good is a design, for meeting all Values, within

all costs?”

Page 230 of 291 Value Requirements Copyright [email protected] 2019

Designers are not accustomed to this situation, because they are
not accustomed to quantifying all critical values, and costs, up
front.

If you can get such multi-dimensional estimates of ‘how good

a design is’, then you open the door to the following:

• You can look at the entire problem at once, all values, costs and
designs.

• You can prioritize project actions, based on a view of all stake-

holder priorities, and all consequent requirements.

• We can include, consideration of uncertainties, risks, and credi-

bility of estimates, in our overall considerations and choices.

• You get well-documented traceability of the decisions made.

• You have the set of data needed to automate decisions such as

‘what is the most cost-effective thing to do next?’ in the project.

Page 231 of 291 Value Requirements Copyright [email protected] 2019

Figure 16.1 : overview of all top level factors in the system architecture. Stakeholders, Costs, Values,
and Strategies (designs).

Page 232 of 291 Value Requirements Copyright [email protected] 2019

16.1 Architecture Engineering: disciplined and
logical architecture.
Architecture, systems architecture, the architecture of any type of
‘system’ can be done in a variety of ways.

From the way we do our summer cabin, project by project, as we

can afford it (the 8 new fjordview windows exchanged for the 1931
versions) , or when the water-well pump breaks down. To the way
our neighbor Sven did recently by tearing down the 1931 cabin
and commissioning a proper architect to design a rather modern
building.

So incrementally, or all at once. You are still making value and cost
judgements to satisfy a range of stakeholders.

As some of the methods comments above indicate (Togaf, Zach-

mann, QFD and more) I have been dissatisfied with the unserious
way some systems architecture has been done, particularly in the
software and IT systems field.

And then I find similar problems in management planning, every-

where there, but the Balanced Scorecard and Business School
teachings give evidence as to how bad management education is.

My core dissatisfaction in ‘enterprise architecture’ was complete

lack of requirements discipline. Talking about quantified require-
ments, not actually doing it.

Page 233 of 291 Value Requirements Copyright [email protected] 2019

But my second related area of dissatisfaction is the almost com-
plete lack of systematic (quantitative, all Values, all costs, all risks)
evaluation of the subject matter itself, evaluation of the ‘Architec-
ture’ (by whatever synonym for the means to the ends).

So for quite a few years, in Oslo and London I have offered a free
course of 2 (practical exercises) and 3 days (theory lectures, case
studies): called ‘Architecture Engineering’. Aimed directly at the
IT Enterprise Architect group, many of whom have learned Togaf,
Zachmann and similar methods. Maybe a book I will write soon,
will have that title20. And this book is Volume I, the foundation, for
the ‘how do we evaluate the actual architecture ideas?’ methods.

Figure 16.2 : Architecture Engineering is a very systematic quantified discipline, which relies on
quantification of Value Requirements (topic of this book) as an input.

20 I did write ‘Value Design’ in 2019 after Value Requirements.

Page 234 of 291 Value Requirements Copyright [email protected] 2019

Architecture processes give feedback to the Values specifications
(‘no architecture available for this..’).

Then architecture specification processes get feedback from their

implementation project (‘the strategy/design doesn’t work’).

Page 235 of 291 Value Requirements Copyright [email protected] 2019

16.2 Design Engineering: specialist areas with
clear consideration and balance for all other
values and constraints.
In large complex systems, in systems engineering, there is naturally
a set of specialist disciplines, contributing to the whole system.

This is good and necessary from the point of view of getting exper-
tise into the system development.

But it always raises some problems:

• The specialist is not fully aware of all other concurrent specialists,

nor of all stakeholders: not to mention future changes in both
those areas

• the specialist can inadvertently make decisions which conflict

with other equally-prioritized things, other values, other costs,
other stakeholder feelings.

So, somehow we need to connect the many design-specialist deci-

sions, and tentative decisions, with the rest of the systems effort.

This synchronization of specialist engineers, is in principle, the ter-

ritory of architecture. But the architecture I see in practice, is totally
incompetent to deal with these conflicts. They have not got the
methods technology to deal with it. They do not deal with it.

So, something new has to be made applied.

Page 236 of 291 Value Requirements Copyright [email protected] 2019

Here are the conditions that a co-ordinated Design Engineer-
ing discipline needs to deal with, or fulfill.

• every budgeted resource aspect of a design specification, needs

to be transmitted to the Project Engineering Model (PEM ?)

• This includes capital expenditure, operational expenditure, cal-

endar time, Human Resources, technical debt, maintenance
costs, and all such limited budgeted resources.

• if the resource consequences of one specialist-designer’s de-

sign, potentially threatens the available resources of all the
others, then feedback needs to be sent to that causing-designer
immediately. (“You have eaten more then your fair share of our
budget. Can you reduce maintenance costs by at least 2X by re-
design?”)

• If any design has a side-effect (for example ‘if Security Design

hurts Usability design’) on any other’s Values territory, especially
if the effect is negative, it needs to immediately21 be reported to
the responsible design specialist affected, and the Chief Systems
Architect; so that it can be resolved.

• The specialist designers agree and understand their responsibili-

ty to estimate, and measure the side effects of their designs, with
regard to uncertainty and risk.

21 after being estimated, or later when actually measured.

Page 237 of 291 Value Requirements Copyright [email protected] 2019

 Architect

Security Usability

Effects

Effects

Page 238 of 291 Value Requirements Copyright [email protected] 2019

Figure 16.3 : Concurrent Value Engineering. Specialist design engineers must estimate and measure
their side effects, and report and resolve them with affected parties.

Page 239 of 291 Value Requirements Copyright [email protected] 2019

16.3 The Value Table for overview and synchro-
nization

Figure 16.4 : We have developed a Value Table22 to enable us to both estimate, and track delivery
values and costs. It can also collect risk data such as evidence, credibility, and uncertainty - for each
individual estimate.

The Table can use any digital table or spreadsheet, and is here
shown in the version contained in our tool ValPlan.net.

The Table can model any set of ends and means, including multi-
ple levels of Values (Fundamental, Strategic, Means). It can model
from a top-level overview and be decomposed, level by level, to
any interesting level of decomposition and detail.

The Value Table enables genuine concurrent engineering

22 Also called Impact Estimation Table, IET, and Value Decision Ta-
ble, VDT

Page 240 of 291 Value Requirements Copyright [email protected] 2019

16.4 Design-attribute feedback incrementally,
and adjustment of value levels, timings, and re-
source budgets, in mid-project.

The IBM Cleanroom method (ref. d) and our own Evo method (ref.
Books CE, VP) have been mentioned in passing earlier.

Figure 16.5 : the Gilb Evo Value Cycle. Measure,

Compare, Learn, and if necessary re-design.

The Architect, or a specialist Design Engineer, needs to keep mea-

surably tracking their design-ideas effects, when designs are in-
crementally implemented.

Page 241 of 291 Value Requirements Copyright [email protected] 2019

When necessary to reach planned Value levels, engineers or plan-
ners need to act and improve their designs.

Page 242 of 291 Value Requirements Copyright [email protected] 2019

16.5 The Evo Value Cycle

Figure 16.6 : The Evolutionary Value Optimization cycle. Evo, or EVO.

Our Evo Cycle is driven by the Value Requirements. It is essentially a Shewhart-Deming Plan Do
Study Act cycle, with a few additional details, like Stakeholder needs analysis, Decompose Solu-
tions, and Measure effects of solution delivery.

The core idea is that every part of the cycle is dealing with the Value Requirements.

Deming told me once that the PDSA cycle is eternal, as long as you have competition. Good insight.
Projects have become processes.

You can also begin anywhere if the cycle is short.

Page 243 of 291 Value Requirements Copyright [email protected] 2019

Chapter 17. Formal Standards for Value Specifi-
cations

Figure 17.1 : Planguage Standards categories. Provide us with specified best practices.

Many of these have been discussed earlier in this book. The rest
are detailed in Competitive Engineering (CE).

Page 244 of 291 Value Requirements Copyright [email protected] 2019

17.1 Competitive Engineering as Planguage
Standard.
https://www.gilb.com/competitive-engineering

Use the above link for a free digital copy and signup on our website.

Paper copies available from:

https://www.amazon.com/Competitive-Engineering-Handbook-Re-
quirements-Planguage/dp/0750665076

Figure 17.2 CE Cover.

Competitive Engineering, the book, is the formal set of standards

defining Planguage, as well as associated processes.

Anybody can freely adopt these standards, or can modify them to

suit their purposes. They are freeware.

Page 245 of 291 Value Requirements Copyright [email protected] 2019

17.2 ValPlan as a tool containing standards
www.valplan.net

ValPlan is an app based on Planguage and on the Competitive En-

gineering book.

Figure 17.3 : Some of the processes and rules from CE book which are made available in the ValPlan
tool.

A wide range of the Planguage/CE standards are built in to Val-

Plan.

Page 246 of 291 Value Requirements Copyright [email protected] 2019

In addition to rendering standards, such as the Glossary, Scales,
Processes, and Rules, ValPlan is programmed to understand all the
essential rules of Planguage, for example:

• all scalar level specs (Past, Wish, Tolerable etc.) belong to the
one Scale defined in their local specification object ( a require-
ment)

• [Scale Parameters] in a Scale demand definition, and these defin-

itions can be used in scalar level specs (like Wish)

• Tags are essentially Unique, and allow reuse of, and reference to,
the tagged spec.

• A specified benchmark and requirement level pair (like Past and

Tolerable) are equal to the 0% impact level of a design, and the
100% level of a design, within the requirement level deadline.
The App knows this and computes it.

Page 247 of 291 Value Requirements Copyright [email protected] 2019

17.3 Rules
Planguage Rules for Writing define good practice, and by defini-
tion, if not followed, Rules define ‘bad practice’ ie ‘specification de-
fects’ in Spec Quality Control.

The Rules are divided into two main categories:

Generic Rules which apply to a broad range of different types of

specs (like all requirements, or all designs): and Specific Rules
which apply to a narrower range of specs such as Function Re-
quirements, or Value Requirements.

The Generic Rules can be reused and learned better.

The Specific Rules can home in on details specific to a narrow class

of specification, such as a Scale of Measure.

Page 248 of 291 Value Requirements Copyright [email protected] 2019

17.4 Processes
Process descriptions advise how to do something, and a recom-
mended sequence of actions to do it.

Figure 17.4 : A process map. The Planguage drawn

icon for a process is a rectangle, with an upwards (clockwise) arrow on the left side.

The Planguage convention is that inputs (documentation, stan-

dards) enter from the top-side. And process outputs exit from the
bottom-side.

Upstream (previous) processes enter from the left-side, and exit to

the downstream, or next process is from the right side.

Page 249 of 291 Value Requirements Copyright [email protected] 2019

17.5 Exit and Entry Processes
Entry processes are designed to protect the next, and larger, main
process from being wasted, or from giving false results (avoid
Garbage In Garbage Out: GIGO).

Entry processes check a list of one or more Entry Process Condi-

tions (in themselves standards, for process entry).

These Entry Condition questions are trying to make sure that:

• the input documentation is itself of sufficiently high, trustworthy,

defect-free quality (it has met the Exit level defect density stan-
dard from the previous process)

• That all related documentation is available in practice, updated

and (approved, exited defect-level)

• That all related standards are made available, and will be used,
including checklists and less-formal standards, templates, guide-
lines and tools.

• That people, especially process leaders, are trained and quali-

fied for the main task (procedure) itself.

Figure 17.5 : Entry

Process and 3 Entry
Process Conditions.

Page 250 of 291 Value Requirements Copyright [email protected] 2019

If any single Entry Condition fails, then the standard is that we are
not allowed to enter the following process. If we do, under pres-
sure, we should be personally held responsible for any consequent
delay or damage.

The problem there, is that the damage might only show up far
downstream, and the Short-Cut Cheaters will not really be blamed.

So process management (designers of the process and Entry con-

ditions) needs to make sure these Entry conditions are really
worthwhile. And local project management needs to be account-
able for people following the Entry process conditions, on faith!

Exit Process conditions are trying to make sure we did a good

enough job on the process: complete, correct, following process
standards, and specification rules. The most critical Exit process
condition is usually that the Defect Density, as measured by a quick
sample and Spec QC process, is acceptably low; meaning it pays
off to exit, and to proceed downstream.

Figure 17.6 : 3 exit conditions from Spec QC process.

Page 251 of 291 Value Requirements Copyright [email protected] 2019

17.6 ‘Concept’ Standards: several levels
Planguage has a basic Glossary of several hundred concepts, like
Scale, Goal, Design Idea, Function. See short Glossary at end of this
book.

An organization is free to modify this in any useful way, for their

needs. As all of my clients do in practice.

Figure 17.7 : in Planguage the ‘Concept Itself’ is central. Quite different from a dictionary. Figure
source CE Glossary, Text from part 26 of Technoscopes book (2018)

We can refer to the concept, by any useful pointers, including ‘log-

ical implication in context’. For example if I use a Goal specification,
I am then unconditionally pointing to the defined Scale in the
same Requirement Specification Object, for the correct interpreta-
tion of the level number in the Goal statement.

Page 252 of 291 Value Requirements Copyright [email protected] 2019

There is a need for allowing synonyms to point to concept defini-
tions. So the concept itself is stable, and well-defined. But useful
synonyms are specified. We need to make sure they are not dupli-
cated (i.e. same term does NOT point to 2 or more concepts).

There is are other levels of concept definition, which are used lo-
cally in a specification. For example:

Figure 17.8: Four Levels of definition types:

‘Scale’ is a normal Planguage-defined term. ‘Pollutant’ is defined right here locally in the ’Air Quality
Index’ specification object. ‘Area’ was defined in a Project Glossary, and reused here. The Project
Glossary could have been raised to the level of an Organization-Wide Glossary; available to all
projects. That would be a 5th level of definition spaces.

Page 253 of 291 Value Requirements Copyright [email protected] 2019

17.7 Teaching and enforcing standards using
Spec QC and Exit levels
My experience is clear. It is not enough to define good practices.
We need to continuously measure that they are carried out. We
need to set high exit-level standards, with respect to clear effective
Rules of practice (standards for writing, planning). Management
must clearly enforce these standards: because they understand
that the economics for doing so are overwhelming.

Figure 17.9 : Spec

QC (called ‘Inspection’ then) together with Exit levels is a dramatic way to really change large-scale
organizational culture, to follow improved practices on an everyday basis.

We saw this effect earlier in this book at Intel (Terzakis, ref. A). My
experience at two Aircraft Factories was a clear two-orders-of-
magnitude (!) measurable improvement in weeks and months.

Page 254 of 291 Value Requirements Copyright [email protected] 2019

Chapter 18. ValPlan: and apps for Value Speci-
fications

18.1 Brief history of Planguage tools.

Planguage was designed with a view towards automation.

Aspect Engine

In the late 70s Lech Krzanik, spent Summers in Norway, and built
the Aspect Engine. Which he used for his PhD.

Page 255 of 291 Value Requirements Copyright [email protected] 2019

Figure 18.1 : The Aspect Engine. Written in ‘Forth’, on my Apple II. About 1979. Source ‘Principles of
Software Engineering Management” (1988)

The Aspect Engine had two Phases, the Ambition Level Value Re-
quirements (like ‘much higher Security’) were automatically con-
verted to a suitable Scale of measure (for Security), and a Goal lev-
el (the ‘much higher’ part).

These quantified Value Requirements were then fed into a data-

base of known technologies (like passwords, encryption), with
known attributes, and selected for best match to the numeric re-
quirement.

Our database was small, symbolic, but we demonstrated that it

worked. An early ‘AI’ system for automated requirements and de-
sign.

Kai Gilb’s Spreadsheet Tool

From the mid 1990s until about 2015 Kai Gilb built a tool using Ex-
cel spreadsheets. It worked pretty well for real projects and for
training courses. But there are limits to what you can program with
Excel.

Page 256 of 291 Value Requirements Copyright [email protected] 2019

Confirmit.

Figure 18.2 : simple spread-

sheet automation of Planguage, 2003. By 2005 they had invested in a more sophisticated design.

This simple tool gave Confirmit weekly numeric feedback on 25

Value Requirements, for 4 teams. The teams were free to use the
feedback to do ‘Dynamic Design to Cost and Value’ (discussed in
this book earlier).

They delivered amazing (1500% improvements, is that amazing?)

multiple quality improvements to their market on a quarterly basis,
and defeated their international competitors because of the quali-
ty differences. Smart engineers + good method.

Page 257 of 291 Value Requirements Copyright [email protected] 2019

18.2 ValPlan the app.
We have seen many examples of ValPlan throughout this book.

This is the brainchild of Richard Smith in UK (http://rsbatechnolo-

gy.co.uk/blog:8) who built it on the side of his freelance consultant
work in London.

Richard went on our training courses at Citigroup in 2003, and

successfully practiced Planguage, and Evo after training at Citi.

Figure 18.3 : June 2019 at British Museum. Gilb International presents Richard Smith with a Maestro
Award for extraordinary achievement using Planguage, with his app. P.S. yes that is USC Professor
Dr. Barry Bohem, applauding in the white shirt.

Richard spent about 4 years of hard and brilliant work building the
tool. We used the name ‘NeedsandMeans.com’

Page 258 of 291 Value Requirements Copyright [email protected] 2019

It was in detail, based on the Competitive Engineering book’s
Planguage standards.

We Beta tested it with clients and classes.

Finally 2019 Gilb International took over the Marketing rights. And
we re-christened it ValPlan.net

Page 259 of 291 Value Requirements Copyright [email protected] 2019

18.3 Open Endedness for Tool Builders.
We (Gilb International AS) are quite happy for any tool builder to
make use of Planguage ideas, without license or permission, in
part or whole. This is the purpose of publication, and training cour-
ses, to share the ideas for any good human purposes.

It is nice if we are credited, and we won’t sue you if you ‘forget’.

We would love for you to share your ideas and experiences on the
internet with us, and to give us a heads up that you are doing it.
We may be able to connect you with other people and ideas.

We believe in open competition to bring out the best ideas for us

all.

Right now we are a very small group working to change a world-

wide planning culture which does not really focus on ‘Value First’.

We hope you are interested in joining forces with us: for both your
own personal benefit, and we hope you are like us Idealistic and
want to help others get better Value, ‘

just because it makes your life more ‘Valuable’.

Make the world a more valuable place

Page 260 of 291 Value Requirements Copyright [email protected] 2019

18.4 GraphMetrix
In late 2015, Frederick C. Gibson, of the large building corporation
Bechtel, contacted me. He is an architect, a proper one. He said he
had read Competitive Engineering three times, and was using it as
a framework for advanced building-planning tools at Bechtel.

What he had published and demonstrated to me was impressive.

Not too much later, he is running a startup, to further the ideas

Http://graphmetrix.com/web/

We are involved.

Page 261 of 291 Value Requirements Copyright [email protected] 2019

FIGURE 18.4 : FROM GRAPHMETRIX WEBSITE

The tool is at an advanced state of development. Funding is in

place. And the advanced ambition levels (AI and all that) are in
place.

I’d tell you more, but they are keeping it under wraps for competi-
tive reasons. Keep an eye on the website, or ours, for develop-
ments. I’ll update here when I can.

Page 262 of 291 Value Requirements Copyright [email protected] 2019

Chapter 19. Stakeholders and the planning en-
vironment

Figure 19.1 : Stakeholders, or ‘Requirement Sources’, which might be a more general description,
are the Value Sources, the entities that need, demand, command, and desire.

Stakeholder Attributes

Stakeholders have a set of attributes, which determine their influ-

ence, power and priority of delivering their Values.

• Financial Power

• Legal Power

• Knowledge Power

• Network Influence

Page 263 of 291 Value Requirements Copyright [email protected] 2019

• Approval Power

• Political Power

• Persuasive Power

• Respectedness

• Veto Power

• Cultural Respect

Stakeholders are behind all our Value Requirements, whether we

recognize the fact or not.

The better we get to know our stakeholders, the better we can de-
termine our Value Requirements.

The more likely our projects are to succeed; and to avoid failure.

Page 264 of 291 Value Requirements Copyright [email protected] 2019

19.1 Determining your planning environment
(ref. L)
Before we can determine which stakeholders are critical, and have
got some ‘critical requirements’ for us, we need to define our sys-
tems environment.

As Pawel Nowak’s ideas make clear (ref. L) there is no perfectly

clear line we can draw around our environment. There will always
be things outside of it, which just might be critical.

The best we can do, is to improve the probability that we identify

most critical stakeholders, and capture most of their critical re-
quirements, initially.

There will always be a learning process, where we realize that our

environment is larger than we thought it was, when we realize
there are critical stakeholders we did not see - or which recently

Page 265 of 291 Value Requirements Copyright [email protected] 2019

emerged, and where critical requirements get recognized un-
pleasantly late.

It will probably be more cost-effective to draft a good starting

analysis to the environment, the stakeholders and their require-
ments: but to have a fairly-humble, but effective process of picking
up additional candidates (stakeholders and values), as we incre-
mentally delivery value, and get feedback from doing so.

Here is a guess at a principle:

Your interesting systems environment

contains all critical stakeholders.

Another useful tool is a good definition of ‘stakeholders’, which

contains the non-human stakeholders (laws, plans, policies), and
which also recognizes that not all stakeholders are nice, and cer-
tainly that not all stakeholders are users and customers.

One effective checklist, is this generic stakeholder set (figure be-

low). It indirectly reminds us that all these types of stakeholders
are part of our Systems Environment. By using those insights we
might be able to identify even more of our real and critical stake-
holders.

Page 266 of 291 Value Requirements Copyright [email protected] 2019

Figure 19.2: Note
the seven major categories of stakeholder. Source: Tom Gilb’s Stakeholder Analysis in ValPlan
2019.23

Then note the handful of examples for each major category. These
help you map your environment. This is not your systems list. This is
just a general checklist to help you find your own systems list of
stakeholders. Analyze and tailor to your particular environment, for
best effect.

23 ‘Antagonist’ category suggested by Petter Abrahamsen.

Page 267 of 291 Value Requirements Copyright [email protected] 2019

The costs, the value attributes, and the strategies at the right side
of the above diagram, might also be additional ways of defining
your particular environment in more depth.

For example a strategy like ‘Responsibility’ should trigger you to

think of environments, and stakeholders associated with it, like au-
thority, culture, measurement.

Page 268 of 291 Value Requirements Copyright [email protected] 2019

19.2 Determining your stakeholders
The most important reason we analyze environments, is to discover
critical stakeholders. The reason we are interested in critical stake-
holders is because they, by definition, have critical requirements.
The reason we are interested in critical requirements is that they
determine our success or failure.

Notice that concept critical?

Critical means, that it can probably alone decide whether your en-
tire effort fails or succeeds.

Critical is a prioritization tool. You have to deal with all the critical
stuff before you can spend any effort on the non-critical, or less
critical stuff.

When you have identified a possibly, or probably, critical stake-

holder, you can begin to analyze and identify, and perhaps detail
their requirements.

Only when you have detailed a requirement can you actually de-
cide that it is critical.

You cannot just say ‘Security’ is critical. You have to know the level
of security (1%, 42%, 99.98% ?), the value of the security level (kills
the business, can lose a small sale), the many Scale Parameter
conditions (User Type, Task, External Conditions, Geographical
Area) before you can say for sure “it is critical”. That detailed Value
requirement definition is the core of this book.

Page 269 of 291 Value Requirements Copyright [email protected] 2019

At some early point keep 2 lists: one for Stakeholders, one for Val-
ue Requirements, with 10 items (critical top 10) at the top of the
list, and everything else below the line. Then in the bottom section:
“PROBABLY NOT CRITICAL” Use yellow stickies if you must! (ref. B)

It does not hurt to make as complete lists as you can, note every-
thing, forget them not. Some items will move up or down the lists
as new items emerge, and new voices argue the case.

I would personally do this digitally, like in ValPlan. There is a facility

there, exactly for keeping track of the critical top ten.

Figure 19.3 : one simple digital way to keep track of anything into Critical/Less-Critical Categories is
to show the Less Critical as a separate hierarchy. It documents that they are considered at all.

But at this early stage of brainstorming, paper and writing instru-

ments are fine.

Page 270 of 291 Value Requirements Copyright [email protected] 2019

Figure 19.4 : Three of the requirements were Labeled ‘Critical’ and so we are able to
keep track of them on this special Critical report.

Page 271 of 291 Value Requirements Copyright [email protected] 2019

19.3 Eliciting stakeholder needs and converting
them into Requirements.
How do we identify potentially critical needs of a stakeholder?

This is traditional Business Analyst territory.

I often start by a meeting, and brainstorming, to get a basic list of

‘critical improvements’.

When people suggest specific technology or strategies, as op-

posed to actual value improvement ideas, then we need to politely
elicit the value itself (not some amateur’s idea of a solution).

Encryption? So you mean we have to improve security? What type

of security and how much better?

The logical reason for this is that no one can decide on a design,
without clear understanding of the requirements. Requirements
(clear) first. Then design.

However for many people the design is a very concrete artifact,

and values seem abstract. So they will name the solutions, the de-
sign, the technology. Your job is to identify the Values which they
are actually referring to, and put them on the table first.

You do not need to initially aim at the full requirement specifica-

tion, as discussed earlier in this book. It is enough to get rough
ideas. Polish them outside of the meeting, and go back later with a
set of more-refined ideas (Scale etc).

Page 272 of 291 Value Requirements Copyright [email protected] 2019

19.4 Understanding stakeholder priority, pow-
er, competence and motivation.
See the Stakeholder Attribute list (Fig. 19.2) a few pages above.

Figure 19.5 : Many of the Values and many of the Costs can be used to understand the
relative cost-effectiveness of a stakeholder. But you need to quantify them all.

For example: what is their Influence, and Visibility, and what are the
costs of dealing with them, like Training costs, Influencing costs.

Rough ideas here, but a starting point for understanding stake-

holder value and costs of dealing with them.

Page 273 of 291 Value Requirements Copyright [email protected] 2019

Chapter 20. Summary of Value Requirements
Value Requirements are the main reasons for projects.

Other requirements are just useful and necessary details, to be

taken into consideration.

We need to clarify and quantify the Value requirements just to have

a fair chance of success in delivering them.

Then you have to consider many ‘conflicting’ Value Requirements

at the same time. Finding reasonable balance. Extremes destroy
the whole.

Then you have to consider all other types of requirements, like the
functions, legal constraints and resource budgets.

This is getting kind of complex, isn’t it?

But you have to do it professionally, or you will fail too early and
too often in delivering the success factors: the improved Value
Levels.

Figure: Values are many, and complex to co-ordinate. But Values must
also consider all other types of simultaneous requirements.

Val- Clarity of specification is the first line of attack on this problem.

ue Oth-
er

Page 274 of 291 Value Requirements Copyright [email protected] 2019

Appendix 21 Book References
(1) CE: Competitive Engineering, 2005, Tom Gilb

Get a free e-copy of ‘Competitive Engineering’ book.

https://www.gilb.com/p/competitive-engineering

https://www.amazon.com/Competitive-Engineering-Handbook-Requirements-Planguage/dp/
0750665076

(2) SM 1976. Software Metrics. ISBN-13 978-0862380342. Library

or used copies only.

(3) VP 2016. Value Planning. Tom Gilb,

“Value Planning. Practical Tools for Clearer Management Communication”

Digital Only Book. 2016-2019, 893 pages, €10
https://www.gilb.com/store/2W2zCX6z

This book is aimed at management planning. It is based on the Planguage standards in

‘Competitive Engineering’ (2005). It contains detailed practical case studies and examples,
as well as over 100 basic planning principles.

(4) VE 2017. Vision Engineering.

“Value Planning: Top Level Vision Engineering”

How to communicate critical visions and values quantitatively. Using The Planning Lan-
guage.

http://concepts.gilb.com/dl926

A 64 Page pdf book. Aimed at demonstrating with examples how top management can
communicate their ‘visions’ far more clearly.
This is the core front end of the Value Planning book (3).

(5) LD. 2018. Life Design. - eBook https://www.gilb.com/offers/

JHHzGSER/checkout

(6) CC 2018. Clear Communication. https://www.gilb.com/offers/

Y36JRL6g/checkout

Page 275 of 291 Value Requirements Copyright [email protected] 2019

(7) IC 2018. Innovative Creativity. https://www.gilb.com/offers/
FnExtaw9/checkout

(8) PPP 2018. 100 Project Planning Principles. https://www.gilb.-

com/offers/Shju4Zqn/checkout

(9) Technoscopes 2018. https://www.gilb.com/offers/YYAMFQBH/

checkout

(10) PoSEM 1988. Principles of Software Engineering Manage-

ment. https://www.amazon.com/Principles-Software-Engineer-
ing-Management-Gilb/dp/0201192462. $46

(11) SI. 1993. Gilb & Graham. Software Inspection. https://

www.amazon.com/Software-Inspection-Tom-Gilb/dp/
0201631814

(12) Value Design, 2019. See www.gilb.com.

(13) Value Management, 2019. See www.gilb.com.

(14) Sustainability Planning , 2019. See www.gilb.com.

(15) Value Agile, 2019. See www.gilb.com.

Page 276 of 291 Value Requirements Copyright [email protected] 2019

Appendix 22. Papers References, with Free URL
Links
(A) Intel Cases. Simmons, Terzakis

J. Terzakis,
"The impact of requirements on software quality across three product generations,"
2013 21st IEEE International Requirements Engineering Conference (RE), Rio de Janeiro,
2013, pp. 284-289. I think you have the full paper, but let me know if not and I can resend.
There’s a lot of good background there.
https://www.thinkmind.org/download.php?articleid=iccgi_2013_3_10_10012

FREE LINK:
(with Gilb Annotations) https://www.dropbox.com/sh/cs9hke3uvgg4gp3/AACadHeI95lZpHz-
VqGKXSXDra?dl=0

PAID LINK 2013 RIO PAPER

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6636731&url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttp%2Fiee-
explore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6636731
Paper link requires purchase and signin

(B) The Top 10 Critical Requirements are the Most Agile Way to
Run Agile Projects

http://www.gilb.com/dl554

(C) Confirmit Test. Try to get John Watkins analysis of them, a free paper not his book

https://www.cambridge.org/core/books/testing-it/confirmit/
275AE17A5603289AB1F129A418572E1C

(D)

Confirmit Paper Gilb and Johansson

From Waterfall to Evo

http://concepts.gilb.com/dl32

(E) My Deeper Priority Writings

Page 277 of 291 Value Requirements Copyright [email protected] 2019

1. Managing Priorities, A Key to Systematic Decision-making. With Mark Maier, 2005
(paper)
http://www.gilb.com/DL60

2. ‘Choice and Priority Using Planguage:

A wide variety of specification devices and analytical tools’. (paper)
http://www.gilb.com/DL48

3. VP Book, Chapter 6 Prioritization

https://www.dropbox.com/sh/34llx1a7ckyagxl/AAA0pDzSxN5WmoP9lOKR0Mpca?dl=0

(F) Gilb ‘Estimation or Control’ paper

SQP Magazine, USA
http://www.gilb.com/DL460

Slides made for BCS SPA June 1 2011

'Estimation, a Waste of Time'
http://www.gilb.com/DL70

(G)
Defect Prevention Process
Mays and Jones IBM SJ paper on Experiences
http://agileconsortium.pbworks.com/w/file/fetch/1527643/Mays1990ExperiencesDefectPre-
ventionIBMSysJ.pdf

See also 2 DPP Chapters in Gilb & Graham

Software Inspection, 1993

(H) “User Stories: A Skeptical View”

http://www.gilb.com/DL461
User Stories paper by Tom and Kai Gilb
In Gilbs' Mythodology Column, Agilerecord.com March 2011
www.agilerecord.com/agilerecord_06.pdf (whole issue)

(I)Gilb and Brodie, ‘How problems with Quality Function Deployment's

(QFD's) House of Quality (HoQ) can be addressed by
applying some concepts of Impact Estimation (IE)’
http://www.gilb.com/DL119

(J) OKR Objectives and Key Results: what’s wrong and how to fix it.
http://concepts.gilb.com/dl879

Paper 2 Feb 2017

(K) Project Startup Week

Agile Project Startup Week Paper in
Gilb’s Mythodologies series
gilb.com/dl568

Page 278 of 291 Value Requirements Copyright [email protected] 2019

And

‘An Agile Project Startup Week’

91 slides pdf
Talk slides pdf from ACCU Conference April 9 2014
90 minutes talk
Includes Startup Planning for Business Startups, Confirmit, US DoD case, 2 Bank cases,
Detailed Startup week outlines and links to sources.
Bristol ACCU Conference
http://www.gilb.com/dl812

(L) Principles of Systems Environments

http://concepts.gilb.com/dl961
Gilb slides based on Pawel Nowak paper at GilbFest 260619

Based on Pawel Nowak, NOWY, “Context - between model and reality. My attempts to catch the elusive
notion”. Talk at GilbFest, London, June 26 2019

(M).

Page 279 of 291 Value Requirements Copyright [email protected] 2019

Appendix 23. Slides and Talk Video References,
with Free URL Links
(a) US: User Stories as value requirements. Slides NEED TO MAKE ONE OR IN BOOK

User Stories with Value Metrics 20Feb17.pdf http://concepts.gilb.com/dl883

Slides Based on Kai Gilb’s Experiments

Mike Cohn commented he liked this.
See also reference to paper (H).

(b)
tinyurl.com/GilbTedx
link tested Sept 2017
Quantify the un-quantifiable

(c)
XAI: Explaining AI
Lecture Slides
http://concepts.gilb.com/dl958

A Serious ‘Multi-dimensional Metrics Attack’ on

Poor AI ‘Academic and Standards’ Thinking & Planning.
An analysis of published Principles for Managing and Standardizing AI, where about
10 AI Qualities like Safety and Transparency are shown to be quantifiable. This is pre-
lude to rational thinking about the entire subject.
GilbFest Talk June 25 2019

(d) IBM Cleanroom Method.

MIlls and Quinnan Slides
http://concepts.gilb.com/dl896

Mills, H. 1980. The management of software engineering: part 1: principles of soft-

ware engineering. IBM Systems Journal 19, issue 4 (Dec.):414-420.
Direct Copy
http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1004&context=utk_harlan

Includes Mills, O’Niell, Linger, Dyer,Quinnan p- 466

(e) What is Wrong with Balanced Scorecard, slides

http://concepts.gilb.com/dl135

(f)“The Ohno Conspiracy” with

Page 280 of 291 Value Requirements Copyright [email protected] 2019

Quality Function Deployment (QFD) detailed method analysis of method weakness-
es.
http://concepts.gilb.com/dl954

(g) ‘Design Sprint

A Critical Analysis
and a Constructive Alternative’
3 Analytical Slides on 'Design Sprint'. 2 Critical Analysis and 1 with my alternative Startup
Planning Week.
http://concepts.gilb.com/dl945

Page 281 of 291 Value Requirements Copyright [email protected] 2019

Appendix 24. Concept Glossary24
Ambition Level: an initial informal statement, from a stakeholder
about the degree of a value improvement. Needs to be translated
into clear and structured Value Requirement specifications.

Attribute: a characteristic of something. A quality, a cost, a func-

tion, anything which can describe and distinguish one artifact from
another.

Background: planning specification which is not the core set of

ideas, but is intended to give additional context for the ultimate
purpose of prioritization, risk management, quality control, and
presentation.

Benchmark: a class of reference level on a Scale of measure. It in-

cludes Past, Status, Ideal, Trend. It is used as Background specifica-
tion to allow us to compare with Targets and Constraints.

Budget: a constraint level for a resource requirement.

Constraint: a requirement intended to restrict, to stop, to hinder

us with regard to other requirements, possible designs, and any
actions.

Defect: a Specification Defect is a violation of official specification

Rules. It is poor practice and can lead to problems of using the
specification correctly, and timely.

24 This Glossary should be consistent with any other Planguage Glossary. But in the interests of simplicity

and freshness I have simply defined things in a simple sentence or so.

Page 282 of 291 Value Requirements Copyright [email protected] 2019

Design Idea: (noun): any specification which is intended to help
satisfy a higher level of Value, Cost and constraints.

Design (verb): the process of identifying and evaluating Design

Ideas, for the purpose of satisfying stakeholder values within con-
straints imposed.

Design Constraint: A requirement specification, that demands or

forbids something regarding a design.

Downstream, Upstream: downstream refers to a process to be

carried out at a later stage. Upstream, a previous process.

Entry Process: a simple short QC process proceeding any main

process, where Entry Conditions, of any useful kind, are checked as
a prerequisite for proceeding to the main process. The intent is to
make sure we do not waste time or encounter failure in the main
process. The cost of the Entry Process should be very small com-
pared to the average results if we did not use it. Above all we use
to to motivate people to take the Entry Conditions seriously.

Environment: implicit, the critical design requirement stakeholder

environment. An areas or scope where can can and must expect to
find critical design requirements, if we study the stakeholders
there and their needs. + (added 270719)

Exit Process: a Quality Control (QC) process after any Main

Process to try to make sure that it is well done and the outputs are
good enough for downstream use. A number of tailored-for-

Page 283 of 291 Value Requirements Copyright [email protected] 2019

process Exit Conditions are checked and if all are satisfied, Exit is
permitted. If any one Condition fails, no exit is permitted.

Function: an action, do something, a description of what any sys-

tem does. It contains no hint of information about the other attrib-
utes of that function, or its container system. Nor any hint of the
designs used to create those attributes for the function, or the sys-
tem.

Icon (Plicon): a graphic symbol which is assigned a Planguage

concept. There are two topics, a drawn icon, and a keyed icon. The
purpose of icons is to create a human-language independent
symbol like music notation, or electrical notation.

Ideal: a perfect level on a Scale, such as 100% availability. Usually

not attainable in practice, or without infinite costs.

Meter: a parameter which sketches major elements of a mea-

surement process, for a particular Scalar Value or Cost.

Owner: a Specification Owner, parameter name shortened to

Owner, has the exclusive right and responsibility for updating a
given Specification Object, such as a requirement.

Parameter: a Planguage-defined Term, which announces the spec-

ification of its defined type of information, about a Specification
Object, such as a Value Requirement.

Page 284 of 291 Value Requirements Copyright [email protected] 2019

Past:a Scale level which is historic. We can usually document in the
Past statement, when, where, who etc. Any useful set of Scale Pa-
rameter attributes.

Performance: a systems engineering classification for the set of

Value attributes. They include all qualities, speeds, work capacity,
savings and any other positive attributes valued by stakeholders.

Planguage: a Planning Language invented, developed over

decades, published in many books (from 1976 Software Metrics,
Data Engineering, perhaps earlier books), and papers, by Tom
Gilb, with feedback, maintenance, and creative improvements from
Kai Gilb and many other professional collaborators. It is a systems
engineering language, with focus on Values and Costs as primary
drivers.

Prioritize: to decide sequence of activation.

Procedure: a specified sequence of activities for a defined pur-

pose.

Process: a continuous, repetitive procedure with a possible end-

ing when complete.

Quality: How Well a function functions. Often ending in ‘-ility’

Requirement: a stakeholder-desired future system state, which

can be tested for presence, or measured for degree: but which
might be impossible to deliver in practice.

Page 285 of 291 Value Requirements Copyright [email protected] 2019

Resource: any attribute which might be consumed, might be lim-
ited, and might be needed to build or maintain a system. Money,
time, people, dominate but many other resource concepts are po-
tentially useful such as image, qualities, functionality, space.

Rules: a standard in Planguage which specified the recommended

way to do, or not do, a specification of any kind. Failure to follow a
rules is classified as a specification defect.

Scale (of Measure): a Parameter which defines a Value or Cost

scale of measure, for reuse and reference when specifying Bench-
marks, Scalar Constraints, and Targets. It does NOT specify a mea-
surement process, that is for the Meter or Test parameter

Scale Parameter: a dimension, announced in [Square Brackets] in

the middle of a Scale specification. It is defined using a {set of
Conditions}. This device permits quite detailed Modeling of a sys-
tem, and allows decomposition of problems so that critical Condi-
tions can be prioritized. Example: [Sex]

Scale Parameter Conditions: a set of named conditions which be-

long to a defined Scale Parameter. Example [Sex] = {Male, Female,
Other, Unspecified, Unknown, Multiple}.

Source: the named origin: a person, group, stakeholder, docu-

ment, or URL of some immediately-previous specifications in a Pa-
rameter Specification. The purpose is to enable QC, give credibili-
ty, lend authority.

Page 286 of 291 Value Requirements Copyright [email protected] 2019

Spec, Specification: a written planning item in Planguage: Re-
quirements, Designs, Analysis, Project Plans, presentations.

Specification Object: a set of Planguage Parameter statements,

comprising a meaningful unit of informations, typically a require-
ment, a design, or sets of these.

Stakeholder: an entity; human, organizational, or document, from

which we can derive needs, demands, resource limits, constraints,
and any form of information, which can be acknowledged as our
potential project requirements, and specified formally and clearly
as a requirement. A ‘requirement source’.

Status: a numeric update of the incremental progress of a Scale

Level as we incremental deliver a system design components and
measure progress towards our requirement levels.

Standards: best accepted practices for developing and maintain-

ing systems. These include, Rules, Procedures, Exit Levels, Concept
Definitions, Templates, Scales of measures, and even App conven-
tions.

Target: a level of Value that we are aiming to reach. It includes

Wish, Goal, Stretch.

Trend: a Background Benchmark level, which estimates the future

of that level. Useful for pointing our Value degradation, or poten-
tial competitor future levels of Performance.

Page 287 of 291 Value Requirements Copyright [email protected] 2019

Use Case: a written graphic description of how a system element
might be used in practice. In Planguage it can be covered by using
an appropriate Scale Parameter. Example: [Uses] : {Register,
Delete, Update}.

User: a person who personally and physically interacts with a sys-

tem.

User Story: a requirement statement in the format: Stakeholder +

Requirement + Justification. This is roughly at the level of an Am-
bition Level, and can replace Ambition Level as a starting point for
formulating a more detailed Planguage requirement.

ValPlan: ValPlan.net is the URL of an App released for sale May

2019 by Gilb International AS. It is based on Planguage and the
Competitive Engineering book.

Value: value is perceived stakeholder benefit.

Page 288 of 291 Value Requirements Copyright [email protected] 2019

Appendix 99. Notes on editing the book and
Versions.
Started about 3 July 2019.

22July2019. First complete version ready. At Cabin

Last page.

EDIT 5AUG 2019

FAULT TO RECTIFY PAGE 195

Note 5 aug2019 I do not know where this fig-

ure is or what it is.

I PUT IN A CYCLE W IET ON 29 SEPT 2019

Figure: Architecture Engineering is a very systematic quantified discipline, which relies on quantifi-
cation of Value Requirements (topic of this book) as an input.

August 14 2019

Moved TOC to front and put ship picture on cover, and edited risk defy x 2

240919: added 4 Gilb Summer books 2019 to references

Noted need edit. page 188 missing 2 figures (THE 2 FIGURES PUT BACK IN SEPT 29 2019) 203 the
word constraints under figure needs edit, also page 208 missing fig., and see over page 195

Page 289 of 291 Value Requirements Copyright [email protected] 2019

September 29 2018 edit of missing illustrations

Putting in Ill and example numbers

To do

( ) Go to older copies and fix the 1.13? Tesla ill which is missing, get it from a backup copy

( ) Fig 1.14 ValPlan examples missing

Put in the word Chapter in every chapter, and numbered the sub chapters.

September 30 2019

1 Oct. 2019; full text edit of whole book. Clarifications and corrections .

I have not yet made this public either at twitter linkedin or gilb.com.

Page 290 of 291 Value Requirements Copyright [email protected] 2019

I have also received no feedback about the book. But I did send a version to selected GilbFest
friends.

Full text edit whole book

1 oct lost diagram found around 15.2 use cases

————————————

Page 291 of 291 Value Requirements Copyright [email protected] 2019