101 Tips For Successful Engineering

101 tips for successful engineering
Dr Joe Silmon
Introduction
xyzabc
About the author
Copyright ©2022 Joseph Silmon. All rights reserved.
i
Contents
Introduction i
I Industry 1
1 Career routes 1
2 Types of engineering organisation 1
3 Funding models for large engineering programmes 6
4 Entry-level engineering roles 6
5 Accreditation 6
6 Common features of projects and project management 6
7 Types of engineering project 6
8 Characterising projects 6
9 Programmes, scheduling, and critical paths 6
10 Managing work packages 6
11 Bidding for work or funding 6
12 Estimating the costs of work 6
13 Pricing work 13
14 Assessing and managing commercial risk 15
15 Common features of business management 15
16 Margins, turnover, and utilisation 15
17 Basic accounting 15
II Delivering like a better engineer 16

18 Common features of standards for management systems 16
19 The many facets of quality assurance 16
20 Assuring people, processes, and tools 19
21 Assuring products 19
ii
22 Assurance-driven vs need-driven engineering 19
23 Dealing with stakeholders 22
24 Managing sets of requirements 22
25 Case study of a project overrun: electrification of a railway 26
26 Roles in a multi-disciplinary project 30
27 Cross-discipline engineering activities 30
28 Value engineering, option selection and tradeoffs 30
29 How single-discipline designers contribute to a whole solution 30
30 Interface management 30
31 Demonstrating an integrated solution 30
32 Reliability, maintainability and availability (RAM) 30
33 Analysis methods for RAM 30
34 Concepts of operation, use, and employment 30
35 Examples of design for maintenance 46
36 Managing entry into service 46
37 Delivering work safely 46
III Thinking like a better engineer 47

38 The importance of history to modern engineering 47
39 Why a systematic approach to engineering is critical: a case study from the 1990s 50
40 The bridge to nowhere 58
41 An introduction to engineering lifecycles 63
42 Reading behind the brief: distinguishing between requirements and solutions 68
43 Characterising a problem 72
44 Emergent behaviour and properties 79
45 Human-centred design 86
iii
IV Communicating like a better engineer 87
46 Drawing and writing by hand 87
47 How to avoid causing “death by Powerpoint” 93
48 Writing better documents 97
49 Typical methods for articulating requirements 103
50 Capturing requirements 103
51 Anatomy of a requirement 103
52 Writing effective text requirements 108
V Modelling like a better engineer 109

53 Fundamentals of models 109
54 Basics of information modelling 116
55 Modelling requirements 116
56 Describing interfaces clearly 116
57 How to plan a system architecture modelling activity 116
58 Modelling languages and frameworks 116
59 Modelling tools and data environments 116
60 Modelling the environment around your product 116
61 Types of interface 122
62 Modelling RAM and safety information 122
VI Behaving like a better engineer 123

63 The basics of sustainable development 123
64 Common features of codes of conduct 127
65 Why safety is always your job 133
66 Safety through the lifecycle 135
67 Common features of safety legislation 135
68 Defining a system for safety assessment 135
iv
69 Hazard identification (HAZID and HAZOP) 135
70 Reporting safety evidence 135
71 Working with environmental management systems 135
72 Personal conduct case studies 139
73 Corruption and bribery legislation 139
74 Cultural sensitivity 139
75 Dressing for the workplace 139
v
List of Figures
1 Engineering organisations throughout society . . . . . . . . . . . . . . . . . . . . . . 3
2 Extraction of iron ore at Dampier, Western Australia[1] . . . . . . . . . . . . . . . . . 4
3 Casting of tool steel ingots at Uddeholms AB, Hagfors, Sweden[2] . . . . . . . . . . 4
4 A stage in the manufacture of steel bolts[3] . . . . . . . . . . . . . . . . . . . . . . . 4
5 Car assembly line[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Sorted waste containers in Shanghai[5] . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7 Road and rail bridges over the river Elbe south of Lutherstadt Wittenberg, Germany 5
8 Wind turbines on the Thornton Bank, off the coast of Belgium [6] . . . . . . . . . . . 5
9 Telstar, the world’s first communications satellite[7] . . . . . . . . . . . . . . . . . . 5
10 Causal loop diagram showing the very basic principles of supply and demand . . . 14
11 Razor blades are commonly priced cheap when introduced, only to increase in price
once the customer base has locked themselves into the product . . . . . . . . . . . 14
13 Stereotypical quality assurance: visual examination of a finished machine part [8] . 17
12 Some typical specialist areas that contribute to overall product quality . . . . . . . . 23
14 Focus on requirements over the lifecycle - ideal (green) and typical (red) . . . . . . . 24
15 How to make best use of limited time to question and analyse requirements . . . . 25
16 Core content and naming of artefacts as per several standards [9][10] . . . . . . . . 31
17 A tent, a superyacht, an apartment block: the CONOPS for a home would apply
equally to all three, as long as they have facilities to support it . . . . . . . . . . . . 32
18 A toasting fork is only a suitable solution for a narrow range of operational environ-
ments where toast is to be made . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
19 A storyboard describing how a toaster is used . . . . . . . . . . . . . . . . . . . . . . 37
20 Scope of CONUSE and CONEMP related to standard lifecycle stages 30 . . . . . . . 39
21 The design of a complex product has a significant impact on the tooling needed to
manufacture it [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
22 Testing electronic hardware - here, only 40% of the cabinet is the device under test,
the rest is hardware designed to make the inputs and outputs more easy to measure
and monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
23 One of the HOPS (high-output production system) engineering trains developed for
the electrification of the Great Western Main Line in the UK [12] . . . . . . . . . . . . 41
24 A self-propelled rail grinder at work [13] . . . . . . . . . . . . . . . . . . . . . . . . . 43
25 A rocket artillery system needs a substantial logistics chain to remain in service.
Upper image - a launcher vehicle; lower image - the logistics vehicle carrying two
reloads. [public domain images] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
26 Nuclear fission requires extensive preparation of fuel and long-lasting solutions for
waste disposal, and the decommissioning of reactors at the end of their lives. Top
- storage of waste products from the fuel enrichment process; centre - low-level
radioactive waste buried in pits; bottom - the Sellafield complex in north-west Eng-
land [14], which reprocessed spent Magnox fuel from 1952 to 2022 and is still active
in nuclear decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
27 Balancing negative experience of the past with ambition and self-belief for the future 50
28 An ambulance of the London Ambulance Service (this example registered approxi-
mately 8 years after the incident in the case study) [15] . . . . . . . . . . . . . . . . . 50
29 The “Bridge to Nowhere”, Mangapurua valley, New Zealand . . . . . . . . . . . . . . 61
30 Stages of a typical engineering product lifecycle, according to ISO 15288 [16] . . . . . 63
31 Green line: committed cost; blue line: cost of change . . . . . . . . . . . . . . . . . . 64
vi
32 Need for a drink, expressed in three levels of abstraction . . . . . . . . . . . . . . . 68
34 A member of the United States armed forces traversing monkey bars [17] . . . . . . 72
33 Comparing a real-world communication problem with a simple mechanical analogy 73
35 The Cynefin framework [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
36 A premature declaration of “mission accomplished” after the first stage of the Iraq
War . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
37 First responders taking action after the September 11, 2001 attacks on New York [19] 77
38 Emergent properties of hydrogen at progressive scales . . . . . . . . . . . . . . . . 79
39 Surface tension as an emergent property of water . . . . . . . . . . . . . . . . . . . 80
40 Evolution of the models of atoms and fundamental particles . . . . . . . . . . . . . 80
41 Causal loop model of general practice waiting times, as perhaps seen by the UK
government of the early 2000s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
42 Causal loop model of general practice waiting times, taking more factors into ac-
count to indicate why the 48-hour target policy had unintended consequences . . . 85
43 One of the problems with computer drawing tools is that you can get dragged into
spending a lot of time making sure objects are perfectly aligned and sized, instead
of focusing on the content; drawing by hand frees you to be more creative and less
focused on precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
44 Drawing office of the Harland & Wolff shipyard in Belfast, Northern Ireland, early
20th century . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
46 Lovelace the cat enjoying her new climbing wall . . . . . . . . . . . . . . . . . . . . . 88
45 My hand-drawn design for adapting an old CD rack into a staircase for cats . . . . . 89
47 A Kanban board created with handwritten notes [20] . . . . . . . . . . . . . . . . . . 90
48 A teacher writing clearly on a blackboard so that children can read it [21] . . . . . . 91
49 The same information presented on a text-only slide and a slide with pictures . . . 93
50 A UML/SysML class diagram that describes an example set of stakeholders inter-
ested in an interface specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
51 A UML/SysML use case diagram that describes an example set of information needs
addressed by an interface specification . . . . . . . . . . . . . . . . . . . . . . . . . . 99
52 A UML/SysML class diagram that describes an example structure of an interface
specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
53 Relationships between concepts in architecture models (redrawn by the author) [22] 110
54 Relationships between modelling concepts, derived from ISO 42010 [22], then gen-
eralised to all types of model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
55 Top left: wind tunnel model [23]; top right: engineering drawing [24]; bottom left:
3-D CAD/rendering [25]; bottom right: text description . . . . . . . . . . . . . . . . . 112
56 Railway along the sea wall at Dawlish Warren, south-west England [26] . . . . . . . 117
57 A context diagram for a toaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
58 Information model of a context diagram . . . . . . . . . . . . . . . . . . . . . . . . . 121
59 The three pillars of sustainable development, related to each other . . . . . . . . . 123
60 Grenfell Tower burning, June 2017 [27] . . . . . . . . . . . . . . . . . . . . . . . . . . 133
61 Challenger space shuttle explosion, 1986 (public domain image) . . . . . . . . . . . 134
62 A summary of the main activities defined in ISO 14001 [28] . . . . . . . . . . . . . . . 136
63 British Army guards on parade[29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
64 High-heeled shoes[54] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
65 Safety footwear with metatarsal guards[55] . . . . . . . . . . . . . . . . . . . . . . . 142
vii
List of Tables
1 Calculating total costs of employing one individual over one year . . . . . . . . . . . 8
2 Calculating annual productive hours . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Essential parts of a requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4 Comparison of two energy generation methods against the three pillars of sustain-
ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
viii
PART
Industry I
1 Career routes
2 Types of engineering organisation

If you are thinking about or have already started a career in engineering, the
chances are you already have some idea in what kind of organisation you’d
like to work. However, engineers can be found making valuable contribu-
tions in some unlikely places. Are you aware of all of the options available
to you?
In this chapter, we will look at the different types of organisation that either
carry out engineering projects or employ engineers. The aim is to inspire
you to look beyond the stereotypical tech world for your career options.
2.1 My story
My motivation for this chapter is partly that I might have made different
choices in my own career if I had been more aware of the subtleties and
diversity of options available in the world of engineering.
As a teenager, I had a strong interest in joining the UK armed forces in a
technical role, but I moved away from this career goal because I wasn’t con-
vinced I would get the opportunity to do much real engineering as a military
officer1 .
After graduating, I joined a rail vehicle manufacturer and was unprepared
for the kind of work I was given to do. This was good in a way, because
it gave me an opportunity to become the engineer I am today, but if I had
known in advance what was in store, I might have chosen differently.
1
I was wrong about this: whilst it’s true that the roles I knew about at the time for such
officers were basically to command units of technicians who did the actual technical work
in the operational environment, this isn’t the only kind of job technically-qualified military
officers do. They can also find themselves supporting defence procurement by specifying
new systems, for example - this a directly technical task requiring fully-qualified engineers
who also know what the real military operational environment is like.
1
To put it simply, many jobs in the engineering industry bear little or no

resemblance to the kinds of tasks that student engineers carry out in
the traditional university education.
Finding out what engineers in an organisation do in advance of joining said

organisation is a bit of a challenge. Recruiters will tell you what they think you
want to hear (and the recruiters themselves are rarely technically qualified,
so they often don’t know themselves what the job entails).
2.2 Technology development - the stereotypical engineer-

ing organisation
Let’s start by considering the kind of organisation that first springs to mind
when we think of engineering. We probably imagine a private enterprise
that builds some kind of product. I deliberately use the word “build” here
because it applies equally to hardware and software. In many cases, prod-
ucts are a combination of both those things, but if we push our stereotype
to its limits, we could be talking about an entire engineering company that
produces nuts and bolts. Such organisations exist and are the roots of engi-
neering as a profession.
An organisation like this usually sells its products to multiple customers,
all of whom have similar needs. It competes with other organisations in
the market sector. It may be part of a supply chain for a larger product de-
veloped by another organisation (taking our example of the nut and bolt
manufacturer), or itself be an integrator of smaller products sourced from
elsewhere (say household appliances built from nuts, bolts and many other
smaller components).
2.3 Supply chains, infrastructure and support

Figure 1 illustrates some basic supply chain stages and some of the many
supporting factors needed to keep it functional. The stereotypical engineer-
ing organisation from the previous section probably sits at the top-right of
this diagram. Most likely, it draws upon many different supply chains, not
just one. Each can be mapped out showing how raw materials are extracted
or grown and processed into progressively more valuable products.
As I drew figure 1, I noticed a strong resemblance with some of my favourite
computer games. Transport simulations often require the player to create
supply chains by linking raw material industries with processing industries,
and then transport the finished products to consumers.
The middle “infrastructure” portion of the diagram represents items that are
necessary in order for the stages of the supply chain to be linked together
2
Figure 1: Engineering organisations throughout society
sustainably.
Underneath infrastructure sits a wide range of other types of organisation
that may also provide critical support for supply chains to successfully de-
liver products. The degree to which each organisation is relevant is highly
dependent on the product.
Most of these organisations both play a part in one or more supply chains,
whilst themselves using products that are delivered by supply chains -
sometimes even the same ones that they support.
Whilst a stereotypical product development organisation sits towards

the end of the supply chain, a great deal of engineering effort is re-
quired earlier in the supply chain, in the infrastructure, and in many
other supporting organisations in order to enable the supply chain to
function.
3
2.4 What each engineering organisation does

2.4.1 Resource extraction
Mining immediately comes to mind when we consider resource extraction,
but oil and gas drilling and agriculture are also examples of resource ex-
traction. These are all material flow processes that need to be designed and
maintained - as well as all the supporting equipment needed to realise them.
Often, the facilities for resource extraction also need to be designed by en-
gineers working with building architects.
2.4.2 Material manufacture Figure 2: Extraction of

iron ore at Dampier,
Conversion of raw resources into usable materials is also a material flow Western Australia[1]
process, sometimes dominated by mechanical factors (e.g. the sawing of
trees into timber) and sometimes by chemical factors (e.g. the fractional
distillation of crude oil into bitumen, tar, heavy oil, petrol and gases).
2.4.3 Component manufacture

Manufacture of components is a turning point in the supply chain, where
material flow is no longer the only consideration: now, the functionality and
fitness for purpose of the output product are also to be considered. En- Figure 3: Casting of
gineers at this stage of the supply often engage heavily with physics and tool steel ingots at Ud-
physical simulation tools in order to design, test, and optimise the product. deholms AB, Hagfors,
Sweden[2]
2.4.4 Product assembly

At this end of the supply chain, something is produced that meets the needs
of a user. My simple illustration of the supply chain shows only four stages.
In reality, a supply chain could have many stages of component manufac-
ture and product assembly. The identity of the “end user” may be flexible
depending on your viewpoint - that is, depending on where you are in the
Figure 4: A stage in the
supply chain. manufacture of steel
bolts[3]
In product assembly, alongside the engineering science used to develop the
components, systems engineering principles play a significant part in the
work of engineers in these organisations. Since the components themselves
are made elsewhere, engineers are focused on translating the customer’s
needs into specifications for the components, or demonstrating that the re-
ceived components can be assembled into a product that meets the cus-
tomer’s needs. Engineers in these organisations are often less involved in
the kind of physics-based design tasks that component suppliers need to
carry out, but they still need to understand the principles because they have Figure 5: Car assembly
to specify what the components need to do. line[4]
4
2.4.5 Infrastructure
No supply chain can exist without energy to drive the manufacturing

processes, logistics and communication to connect each stage in the
chain, and waste management to dispose of byproducts that have no
further value in the supply chain.
Figure 6: Sorted
Every supply chain relies not only on the links prior in the chain, but also on waste containers in
common infrastructure that isn’t necessarily part of the same organisation. Shanghai[5]
Examples of infrastructure are illustrated in figure 1. Where separate or-
ganisations exist to provide these infrastructure services, they employ large
numbers of engineers in a wide range of disciplines. Infrastructure engi-
neers design, develop and maintain the technology and processes needed
to deliver services, rather than material goods.
Figure 7: Road and rail
bridges over the river
2.4.6 Some more organisations that employ engineers Elbe south of Luther-
stadt Wittenberg, Ger-
The bottom section of figure 1 is a loose collection of themes not directly in- many
cluded in either supply chains or infrastructure, but that require engineers
in varying quantities. The fact that these are written smaller and without
cartoons shouldn’t be taken to suggest that they are less important or that
they employ proportionately fewer engineers. Take construction for exam-
ple - huge numbers of engineers (of many different disciplines) work for con-
struction firms, designing (amongst other things) the infrastructure and the
building facilities that are used by the supply chain industries.
Governments and governmental organisations also need many engineers in
order to function. Consider the technical aspects of healthcare, education,
and national security - all these areas keep engineers very busy.
2.5 Summary Figure 8: Wind tur-

bines on the Thornton
I may be treating universities unfairly in my suggestion that engineering de- Bank, off the coast of
grees are so focused on engineering science and not providing a broader Belgium [6]
oversight of skills and opportunities outside a traditional supply chain, but I
still think an important point needs to be made. Engineers are found in the
most unlikely of organisations and they make a vital contribution wherever
they work.
My message to you is: keep an open mind about where the ideal opportu-
nities for you might be as an engineer. Look over the whole spectrum of
organisations I illustrated and consider where you might be most interested
in working.
If that’s not challenging enough, try thinking about organisations that you Figure 9: Telstar, the
world’s first communi-
cations satellite[7]
5
think would benefit from engineering expertise, but that don’t currently em-
ploy engineers. That is, those organisations that don’t even realise what they
are missing. Will you be the one to change their minds? Good luck!
3 Funding models for large engineering programmes
4 Entry-level engineering roles
5 Accreditation
6 Common features of projects and project man-

agement
7 Types of engineering project
8 Characterising projects
9 Programmes, scheduling, and critical paths
10 Managing work packages
11 Bidding for work or funding
12 Estimating the costs of work

Nobody has the innate ability or the technology to see into the future with
perfect accuracy. Yet, somehow, that seems to be what is expected of us
when we are asked to estimate the cost of engineering work.
Let’s first be clear that there is a big difference between estimating (some-
times called “costing”) work and pricing it. The cost estimate is the true
amount of money we believe is needed to get the work done. The price
is the amount we are going to ask the customer to pay for that work.
Depending on what kind of industry sector you work in, you may or may not
need to get involved in pricing, but it’s very likely (if not certain) that you will
need to produce an estimate of costs at least once in your career.
6
Health warning
It is normal practice in engineering to keep the details of costs confi-

dential. This is because rivals can gain a competitive advantage if they
know what our costs are. Pricing, on the other hand, must be shown
to a customer. It may be kept from competitors but not necessarily.
I advise you to keep this in mind when communicating with customers!
In this section we will look at some of the basics of costing. Every organi-
sation differs in the details of how it carries out this task so to become an
active practitioner in this field, you’ll need to take specific training or gather
on-the-job experience.
Let us assume there are three main categories of cost, which we will consider
separately:
Time - the costs of human time spent doing work, including a factor for
expected supporting infrastructure such as offices;
Materials - the cost of physical and software elements used in the produc-
tion of deliverables, whether components for some product or special
materials needed in the production of intellectual work such as a non-
standard software package;
Expenses - other types of cost that don’t fit into the time or materials cate-
gories, such as travel by project staff, subcontracting of work outside
the organisation, administration fees by other bodies, and many more.
12.1 Costs of working time

On engineering projects we often refer to the time cost as “engineering hours”,
but on larger projects, the working time spent is not all pure engineering: the
team consists of engineers and other roles working together. The cost of all
of these roles must be considered. Leaving out relevant roles is a good way
to lose money!
It’s very important to realise that the cost to an organisation of one

hour of a person’s time can be several times greater than the amount
that person actually earns. This is why it is so important to avoid
wasted time on projects: wasted time drives the cost up more than
we might think.
I’m going to show you a simplified version of the method I was taught at
one company I worked for. This is certainly not the only way to develop an
estimate of staff costs, but it is fairly normal practice.
7
12.1.1 The “staff cost rate” method

If we start by looking at a made-up individual, we might build up their yearly
costs as follows, then generate an hourly cost rate by dividing by the ex-
pected number of worked hours in a year. If this represents the total indi-
Item Cost (EUR)

Annual gross salary 48,000
Employee benefit: rail season ticket 5,120
Employer pension contribution @ 4% 1,920
Employer health insurance contribution @ 12% 5760
Subtotal 60,800
Table 1: Calculating total costs of employing one individual over one year
vidual cost of the worker over one year, we should be able to calculate an
hourly figure called a Staff Cost Rate by dividing this amount over the total
hours expected to be worked in one year2 . We have to remember to factor
in allowances for annual leave and sick days, but at this stage we don’t worry
about whether the staff member is spending 100% of their time working on
our project - we just want an average cost for an hour of their productive
time. Now, we can calculate a basic “Staff Cost Rate” by dividing total annual
Weekdays in a year (365 × 5⁄7) 261

Public holidays -8
Annual leave -30
Sick days allowance -10
Total estimated days worked per year 212
Total worked hours @7.5 hours per day 1595
Table 2: Calculating annual productive hours
employment costs by the number of expected productive hours in a year:

€60800 ÷ 1595 hours = €38.11/hour
For comparison, the hourly rate that the employee receives is their gross
salary divided by the number of weekdays in a year and then by 7.5 for hours
worked in a day, which comes out at €24.52.
2
This is important: we need each worked hour to cover its own costs plus the costs of
hours not worked, such as holidays and sick days, otherwise the recovered cost of worked
hours will not by itself cover the yearly costs
8
12.1.2 Overheads using the “on-cost” method

So far we have only calculated the cost of this individual’s employment. Now,
we need to factor in all the other costs that are associated with them - their
individual portion of costs such as:
• Other staff in the company who cannot be billed to customers - top
management, human resources, IT, canteen workers, cleaners and so
on;
• Office space - rent, energy bills, furniture, supplies;
• Time spent by the employee on work that cannot be billed - training,
staff meetings, personal administration and so on;
• Computers, mobile phones and all other personal materials that the
employee generally needs.
The method we are using adds a percentage known as an “On-cost” to the
Staff Cost Rate to cover these sorts of costs. The higher the overheads, the
higher the percentage needs to be.
Deciding what on-cost to apply is a high-level commercial decision because
it has a big effect on profitability. Underestimating the on-cost means that
the billable employees never cover the total costs of the company. A lot of
factors need to be taken into account - more than we can cover here and well
outside my own knowledge. As an engineer, you would usually be told what
percentage to use when estimating. Let’s assume someone has decided the
on-cost is 80%. The hourly rate that we need to charge for our employee in
order to break even is therefore 180% of €38.11, or €68.59. This is nearly
three times the hourly rate that the employee actually earns.
The only disadvantage I can see of this method is that the on-cost scales
up the estimated costs based on how much the employee earns. A higher-
paid employee probably doesn’t bring in much more IT, HR and office costs,
but this method assumes that the overheads for such employees are sig-
nificantly higher. Hence, the on-cost rate needs to be adjusted so that it
averages out across the whole workforce, or the price becomes uncompeti-
tive.
12.2 Estimating the amount of time needed for work

So, now we have a method for estimating the cost of one hour of time for
one particular person. The more difficult bit is to now estimate how much
time from each role is needed to do a particular job.
9
In order to give a reasonably precise estimate for engineering hours,

you must have a strong mental model of the work to be done. For
very experienced engineers, their prior knowledge may be sufficient
that they can keep the estimate at a high level and specify the full-
time-equivalents for each staff member for the whole programme. A
more scientific approach would be to use some kind of project plan,
possibly with subordinate engineering plans, to detail precisely what
tasks must be done. Neither approach is foolproof.
I can’t offer you an easy solution for producing time estimates that will be
deliverable without causing yourself a nervous breakdown. Many engineer-
ing tasks are complex enough that it isn’t easy to stick a figure on how long
they will take. Others can be fairly straightforward and can be measured
from previous experience. For example, carrying out a design calculation
with known parameters is straightforward enough that there’s little risk in
allowing the same amount of time for it, unless there’s a risk that the input
data might change, triggering a need to repeat the calculation.
12.2.1 Agile projects

Agile project management methods move away from a situation where all
the effort for a project has to be estimated at the beginning in order to agree
on costs and price. This allows for a more pragmatic kind of estimating
where we predict how much work can be completed in a short, fixed pe-
riod. As more and more periods pass, prediction becomes more accurate
because we have learned more about how long it really takes to complete
work.
Agile relies on it being possible to break work down into small units, where
each of which can be delivered using more or less the same process. This
works well for software and systems engineering, which produces (funda-
mentally) information as output, but is less easy to do for physical engi-
neering tasks like construction, where the overall programme consists of
a diverse set of tasks that take different lengths of time, have diverse risks
affecting how long they take, and where they all have complex sequence
dependencies on each other.
12.2.2 Full-time-equivalent (FTE)

I mentioned full-time-equivalents above. This is very important for work
where multiple individuals are going to work as a team in the same role,
or where individuals are spreading their time across multiple projects.
Assuming a 40-hour working week, so that the numbers come out neater,
one full-time-equivalent or FTE means forty hours worked over a period of
10
one week. If two individuals each spend twenty hours, or four individuals
each spend ten hours over that week, then that also counts as one full-time-
equivalent. If one individual works twenty hours over the week, that counts
as 0.5 or 50% FTE.
Health warning
Remember that if you want to keep track of how much the work will
cost, you can only combine the FTE involvement of several people if
their hourly costs are the same, or if you can make an approximation
like an average SCR or (more conservatively) assuming that everyone’s
hours cost as much as the most expensive person on the team.
It makes sense to separate FTE estimates where multiple, diverse roles
are involved in the work, so you can see separately the involvement of
each role. For example, 2.0 FTE of regular engineers for two weeks to
produce a document, and 0.1 FTE of a senior supervisor over those two
weeks to review and approve it.
It’s useful if you are working on multiple projects to keep an eye on the
amount of effort you spend on each one every week. If you find the total
goes above 0.8 FTE, you need to be careful that you still have enough time
to do your personal administration, professional development, and allow
for a little breathing and thinking time. Above 1.0 FTE, I hope your contract
allows for paid overtime, but beware of burnout!
12.2.3 Tips for estimating working time

My tips for estimating the amount of time for a task would be:
• Work through the engineering plans to build up a work breakdown
structure (WBS) that itemises each individual task to be done;
• For a very precise “bottom-up” estimate, use the WBS as the basis for
time estimation, and estimate the hours needed for each item in the
WBS;
• For a less precise “top-down” estimate, use your overall understanding
of the work in the WBS to estimate the amount of full-time-equivalent
effort needed over a particular duration by each involved role;
• Expect your project manager or bid manager to reduce your estimate,
possibly without telling you: either allow for this in your estimate, or
insist that your original estimate be kept intact;
• Ask colleagues and draw on experience as much as possible so that
your estimates reflect existing knowledge;
11
• Give a degree of confidence with each estimate so that bid or project

managers can account for the risk that your estimate was inaccurate;
I hope by now it’s clear that estimating is quite difficult. Whatever you do,
don’t feel too bad if it turns out your estimates were well away from the
reality. The more complex the work, the less likely it is to be possible to
estimate accurately the time and other costs in advance.
12.3 Materials and expenses

Just as we may have a Work Breakdown Structure to detail the items of work
to be done, so an equivalent list or structure generally exists for the com-
ponents we need to build our product. Even if we are doing early-lifecycle
engineering work (design and analysis) we may need physical materials or
software. All these items should be listed on an artefact like a Component
Breakdown Structure or Bill of Materials (this last is used especially in con-
struction).
In order to generate some kind of cost estimate you will need to know prices
for all the items in the bill of materials. Large organisations will have cata-
logues of approved materials and products, with existing supply agreements
and attached prices. In a smaller organisation, you may need to look up
prices for each item yourself, selecting an appropriate supplier.
When doing the latter, you need to check what rules exist in your organisa-
tion. Some organisations will give you complete freedom to select whichever
supplier you wish; others will restrict your choice of suppliers or (especially
for items with a large cost) require you to obtain multiple price quotations
or even open the item up to bidding.
For items purchased in large quantities, keep an eye out for the “price break”
- a lower per-item cost if you order a larger quantity of items. If other projects
also need the same item, it can be advantageous overall to order more than
you need and keep the rest in stock.
The total material cost is the sum of all the items, once you have certainty
over what each of them costs. I’m sure I don’t need to tell you how to create
a spreadsheet to calculate that.
12.4 Optimism bias

Humans (and some animals) have an innate tendency to underestimate risk.
For various reasons, like wanting to appear agreeable and positive in front of
our peers, we have a tendency to underestimate the amount of work needed
to get a job done, and to assume that things will go well or perfectly rather
than adjust our estimate by a reasonable factor to account for likely risks.
12
Overall, this means that many (if not most) engineering effort estimates are
exceeded by the real work. This is a major risk to the project, because it
means extra time and extra costs are needed to complete the work. The
customer may not be willing to pay the extra money, or accept the delay.
They may abandon a project and go to another service provider or supplier,
or they may enact punitive clauses in the contract. It is not uncommon for
engineering companies to find themselves forced to work for nothing in or-
der to complete a piece of work, where the original price was exceeded by
the real costs.
You should always try to factor in some assessment of risk to your

estimate, or get assurance that your project manager is going to take
care of that for the whole project. Don’t just factor in the risks you
know might come to pass; expect the unexpected as well!
13 Pricing work
Many engineers become project managers and find themselves directly re-
sponsible for setting the price of work. Even if you don’t follow this route in
your career, it probably helps to understand a little about how pricing might
be done. We’ll look at cost-plus pricing and then at pricing that considers
competition and profitability.
13.1 Cost-plus pricing

The traditional method of pricing a product or service is to calculate its cost,
as we discussed in section 12, and then add either an absolute or propor-
tional margin to the cost.
Cost-plus pricing can be applied simply by taking the total estimated cost of
something and multiplying it by a number greater than 1. For example, to
earn a 5% margin, we multiply the total cost of a project by 5%. However,
this is a pretty unsubtle way to develop a price.
For projects that are dominated by engineering time, but with some ex-
penses such as travel for meetings, it is often the case that a margin is added
to the time costs but not to the expenses. This is considered fair because
an engineering consultancy, for example, adds value (and deserves a mar-
gin) through the assignment of its talented staff, but it doesn’t add any value
by purchasing rail tickets for those staff to travel. It’s seen as fairer to focus
the margin on those aspects of the work where value is being added by the
organisation offering the price.
In complex organisations where staff might be sourced from several depart-
13
ments, each with their own profit targets, it might be necessary to add a
tailored margin to different individual staff member costs separately.
Cost-plus pricing has the advantage that the offering organisation is guar-
anteed to profit from doing the work, unless the costs change without a
matching increase in funding. It has the disadvantage that it takes no notice
of competing prices from other offering organisations, which means that a
pure cost-plus approach is not always competitive in a bidding scenario.
13.2 Charging what the market will bear

The economics of supply and demand tend towards a situation that (in the- Figure 10: Causal loop
ory) regulates prices. Where demand is high and/or supply is short, prices diagram showing the
go up. Where demand is low and/or supply is plentiful, prices go down. Eco- very basic principles of
supply and demand
nomics is not my specialist subject, but I hope you can see, as I do, that this
is all very well in a very simple scenario, but that the real world has all sorts
of complications that mean we need to take this only as a rule of thumb. For
one thing, the price affects demand: demand goes down if consumers feel
the price is too high, and goes up if they feel it is a bargain.
Prices may be set dynamically according to demand. When introducing a
new consumer product, retailers often offer a heavy discount. As demand
develops, the price can then be raised until demand growth begins to slow
down. In this scenario, assuming pricing started either at or near break-
even (the price covered the costs) then the final price can yield large profits
for the retailers and suppliers. Maximising the profit is a typical strategy for Figure 11: Razor
private companies that need to return dividends to investors, but this is not blades are commonly
the case for all types of organisation. Public infrastructure pricing may be priced cheap when
set with a minimal working “surplus” to cover for future investment, in order introduced, only to
increase in price once
to maximise accessibility to the population.
the customer base
In more difficult times, prices may be driven down by competition between has locked themselves
into the product
suppliers. The driving factor is no longer the amount that the customers are
willing to pay, but the price that the competitors are offering. Prices may
even be set below the cost of a product or service. Whilst this is unsustain-
able in the long-term, there are a few reasons why a company might choose
to do this - and this is equally applicable to tangible products AND engineer-
ing services.
• A new company trying to win market share with attractive initial prices
that will then go up above cost over a time period;
• Especially in projects, a company bidding low to win a key project as
part of a wider strategy, perhaps valuing the prestige of the project
over the revenue;
• A company accepting a short to medium term loss in order to maintain
14
a workforce or tooling through a lean time in the hope that the market
becomes profitable in the future;
• A company trying to drive competitors out of business by accepting
losses until the competitors cannot participate in the market;
• A “loss leader” - a product or service sold at a loss in the hope that cus-
tomers will buy other, profitable products or services from the same
supplier.
The deliberate lowballing of a bid, especially for a major project, is a risk for
the supplier and for the customer. However, in competitive markets (and
most big-ticket products or services are opened up to competition, in most
countries of the world) the pressure to win a bid or market share is immense.
When estimating costs (which of course affect the “win price” for a bid), you
may come under pressure to reduce your estimates or adjust resourcing
so that cheaper resources can be used to do the work. Your professional
ethics code requires you to push back against that pressure if it affects the
quality or integrity of the work, just as your employment contract requires
you to act in the best interests of the company. This can be a tough balancing
act. Don’t be afraid to stand up to bid and project managers, or call on your
management chain or mentor for support.
14 Assessing and managing commercial risk
15 Common features of business management
16 Margins, turnover, and utilisation
17 Basic accounting
15
PART
Delivering like a better engineer II

18 Common features of standards for manage-
ment systems
19 The many facets of quality assurance

The word “assurance” is used frequently in engineering for a wide variety of
subtly different purposes. However, there is some fundamental common-
ality in all these different uses, and the potential exists to make engineer-
ing processes much more efficient by taking advantage of this commonality.
Let’s start by establishing a definition of assurance.
19.1 What is assurance?

The Oxford English Dictionary online definition of assurance [30] gives us
the following relevant definitions:
• A positive declaration intended to give confidence; a promise;
• Confidence or certainty in one’s own abilities;
• Certainty about something.
In engineering, there are many different types of assurance, but they all
share that same goal of giving some stakeholder confidence that the prod-
uct, service, or system in question has some aspect that meets an expecta-
tion.
In other words, engineering assurance could be defined as giving confi-
dence, through presenting evidence, that a requirement has been ful-
filled.
No matter who the stakeholder is, or what the requirement is, this definition
holds. Later, we’ll explore why the realities of delivering assurance can often
be more complicated.
19.2 Assurance and quality

Perhaps the most familiar use of the term “assurance” is within the phrase
“quality assurance”, which may conjure up an image of an inspector standing
at the end of a production line and adding a stamp or sticker to those prod-
16
ucts that meet the standard. You’ve probably seen those little “QA” stickers
on various consumer goods.
The ISO 9000 series of standards define a common set of aspects of a quality
management system. The definition of quality within this set of standards
[31] is:
Figure 13: Stereotypi-
The degree to which a set of inherent characteristics fulfils re- cal quality assurance:
quirements. visual examination of
a finished machine
part [8]
19.3 Can we be more specific about quality?
In reality, our white-coated inspector deals with just one aspect of quality –
the degree to which the end product matches the design. A product doesn’t
make it to the production line unless the manufacturer has confidence that
it will work and that it will turn a profit.
This implies that there needs to be some assurance well before we start
manufacturing a product.
The sketch in figure 12 illustrates some of the aspects of assurance that might
need to be provided for a product, service, or system. We don’t expect that
every single job would produce a single document for all these concerns –
but it is a good idea when developing a product to ask yourself some of the
questions you see below, even if your brief doesn’t mention them.
Although the questions in the sketch are a little more specific and certainly fit
into more specialist areas, they don’t represent measurable requirements.
However, the technical experts who manage these areas do generate re-
quirements through their specialist activities (even if that’s not what they
think they do).
For example, when we carry out a safety risk assessment on a proposed
product, we may identify additional safety features that are required, over
and above anything originally briefed. These requirements are then the
items we should check have been met in order to argue that the product
is safe.
Recognising requirements is a key skill. Finding them in documents

that aren’t ostensibly requirements specifications means you have un-
covered a risk to your project, and taken the first step to mitigating it.
Ask yourself if the content you’re looking at means the product or system
should be changed from what the design says, or what the client brief says.
If the answer is “yes”, you’re looking at a requirement.
17
19.4 Integrated requirements, integrated assurance

If all of these specialist areas do, in fact, produce requirements, then our
quality management system (QMS) should, in theory, support all those pro-
cesses and integrate them.
In practice, although many organisations boast ISO 9001 certification (that is,
they have passed a process audit that examined their QMS), the quality man-
agement system is not always this widespread and far-reaching. In a world
where people are necessarily highly specialised, the quality department of
an organisation may carry out its QMS activities in semi-isolation from the
rest of the engineering team. This can lead to a situation where the potential
of a QMS is reduced.
Separate standards govern many of the specialist strands of assurance. For
example, environmental assurance may be constrained by international or
national legislation, industry practice, local authority requirements and the
requirements of an environmental management system (EMS).
Note that this last, the EMS, also has an international standard series to sup-
port it, the ISO 14000 series. If you read both ISO 9001 and ISO 14001, you will
see the similarities. This is not an accident; it’s really important to recognise
that the management of a special area like the environment is just one part
of what should be managed centrally in the QMS.
Health warning
Some of the specialist aspects of quality are regulated by legislation

as well as by industry standards. The most obvious of these is safety,
but electromagnetic compatibility and environmental impact are also
examples.
Organisations that work in a “silo” mentality run the risk of failing to
comply with some of this legislation, if the individual specialists are
unable to influence the product enough.
It’s your responsibility as an engineer to assess the wider impact of
your products, from both a legal and ethical point of view. Never as-
sume that meeting the client brief will be enough to deliver a product
that is safe, legally compliant, or environmentally friendly.
19.5 Conclusions
• Our definition of assurance links strongly to concepts of quality;
• The standard definition of quality refers to requirements, which means
it is essential to identify and deal with requirements in order to achieve
quality;
18
• Quality has many subtypes, each of which may be managed by special-

ists;
• Assurance can be streamlined by supporting specialist areas of quality
with an effective QMS;
• Recognising the requirements among these quality types is key.
20 Assuring people, processes, and tools
21 Assuring products
22 Assurance-driven vs need-driven engineering

If there’s one common theme that crops up time and time again in my work,
it’s the old adage of “more haste, less speed”. Engineering projects have a
habit of running into difficulty late in the lifecycle, when we unexpectedly find
that the delivered product doesn’t integrate correctly, can’t pass its testing
regime or, in some cases, doesn’t actually fulfil the user’s needs.
In section II.19 we defined "assurance" as giving confidence, through evi-
dence, that a requirement has been fulfilled. It is much easier to provide
evidence that a solution fulfils the requirement, if the requirement was well-
understood and the design was carried out with that understanding of the
requirement in mind.
However, all too often, this statement is ignored, leading to the problems
mentioned in the first paragraph. These issues can be linked to the choice of
a project to take an assurance-driven, rather than requirements-driven ap-
proach. In this chapter, we’ll explore what these terms mean and explain
the consequences of choosing assurance-driven rather than requirements-
driven approaches.
22.1 Assurance-driven approach

It’s unusual to work on an engineering project where there is no urgency
in delivery, and you have as much time as you like to get things done. Far
more often, you’ll find that the programme of work, with deadlines and mile-
stones, starts to shape the technical quality of what you can produce in the
available time.
When time is tight, the project planners produce a programme by work-
ing backwards from the milestones to the present, scheduling in the tasks
needed to produce deliverables on the assurance checklists of each stage
gate.
19
The trouble with this approach is that projects end up focusing their atten-
tion more on the production of assurance evidence than on actually meet-
ing, or even understanding, the requirements that they are trying to de-
liver against. The timescales of some projects are tight enough that no time
remains to actually do the design work or think about the problem, because
from project kickoff onwards, the focus is on producing the deliverables re-
quired for the next milestone.
22.2 Consequences of an assurance-driven approach

When the programme is about nothing more than delivering assurance, en-
gineers are forced to rely on familiar solutions to rush the production of the
deliverables on the list in order to meet the programme, without first really
taking the time to understand the problem they are trying to solve. To pass
the gates, they then have to hurriedly make a justification of their design
choice against the requirements.
Sometimes, the lead-up to a stage gate is the first time the design engineers
actually see the requirements; by this time, it’s far too late for them to do any-
thing other than make a retrospective statement that attempts to persuade
the reviewer that they should accept the rushed design. If they’re lucky, their
pre-packed solution will meet the requirements; if they’re unlucky, the gate
will fail because the assurance is incomplete, and projects can be severely
delayed by wrangling over these issues.
It only takes one carefully targeted question by a reviewer to highlight this
systemic weakness in an assurance case. Such questioning might be con-
sidered fussy, but when some of the requirements cover safety, you should
expect to be scrutinised thoroughly.
22.3 How to take a requirements-driven approach

22.3.1 Making the business case
In an environment where programmes are tight, it can be extremely difficult
to persuade project managers and programme planners that they should
“delay” the production of the client’s required deliverables to focus on tasks
such as analysing the requirements.
It would be unreasonable to suggest that it is always worth taking time to
analyse requirements and develop a progressive, evidence-based design.
Sometimes, the problem is so well-understood and the solution so well-
established that it is entirely appropriate to simply reproduce what was done
last time and sign it - but that’s not really engineering.
The risks have to be balanced: on the one hand, doing the extra analysis
20
could delay delivery; on the other, failing to do the extra analysis could de-
lay delivery, cost more money, and damage reputations, not to mention the
safety implications of producing a solution without incorporating the appro-
priate level of safety analysis first.
It may not be possible to put numbers on your case. However, whether
qualitative or quantitative, you can look to demonstrate:
• That the time and cost spent on rework can be reduced by a greater
total amount than that spent carrying out early analysis
• That critical safety (and other performance) factors can only be covered
properly with early analysis
• That an evidence-based, model-driven, tracked and progressive design
approach will build its own assurance case, requiring minimal develop-
ment effort
22.3.2 Making requirements drive the design

So you’ve won the argument with your project manager, what now?
The approach to take depends heavily on your starting point and how much
time or resource you can use. You need to be pragmatic and address the
biggest risks first, because you may not be able to resolve all the problems
before the starting gun goes off and your focus switches to producing those
all-important deliverables.
The flowchart in figure 15 gives you some basic questions you can answer.
You can ask these questions for the whole of the project or only for particular
areas of interest. This means you can focus your effort on the areas of most
concern (that is, risk) and leave other areas alone - but ensure you note what
you have done and not done, so that at the end, you can have a good idea
of where the risks still lie.
Every ‘yes’ answer is a reduction of risk; every ‘no’ answer is a new risk that
was not previously identified. It is beneficial to projects both to reduce risk
and to identify unknown risks. This means a ‘win-win’ situation that you can
use to counter the argument “what if we spend all this effort and find that
everything is OK?”. Other chapters deal with some of the activities in figure
15 in more detail:
• Stakeholder identification: chapter II.23
• Gathering requirements: chapter IV.50
21
23 Dealing with stakeholders
24 Managing sets of requirements
22
Figure 12: Some typical specialist areas that contribute to overall product quality
23
Figure 14: Focus on requirements over the lifecycle - ideal (green) and typical
(red)
24
Figure 15: How to make best use of limited time to question and analyse requirements
25
25 Case study of a project overrun: electrifica-

tion of a railway
The electrification of the Great Western main line railway from London to
Bristol, Oxford, Cardiff and Swansea was a major undertaking that started in
2010. After major delivery problems, the project was scaled back, but despite
this it cost significantly more than initial estimates.
I have some first-hand experience from this project, but this chapter will
focus on the publicly-available findings of the UK National Audit Office report
[32], which was published in 2016, into the delivery problems.
25.1 Late delivery - and what does delivery truly mean?
Delays to the electrification programme will cost the Department [for

Transport] up to £330 million.
Finding 13, UK National Audit Office report on modernising the Great

Western Railway [32]
Some passengers in the north and west of England may have to wait
longer to see improvements in services
Finding 14, National Audit Office report on modernising the Great Western
Railway [32]
On a major engineering project, the impact of late delivery is felt throughout

the project team but also in the wider community. The end-users, be they
rail passengers, military personnel, consumers, researchers or healthcare
patients, will lose out, even if nobody on the project team loses their job.
Take a moment, though, to think about what delivery really means. Contrac-
tually, you’ll often find that your organisation is required to deliver design
artefacts, or installed works, on particular milestone dates. Is that really de-
livery, or is delivery the date on which the end-user can pick up your product
and start using it? Does the journey matter more than the destination?
If a project has too many interim milestones, and there emerges some dis-
crepancy with how they were predicted and modelled in the schedule, you
may encounter reluctance to change the programme to reflect the situa-
tion. Remember that a schedule (such as a Gantt chart) is only a model of
26
the project timeline, and models are always wrong3 , even if they are some-
times useful.
A belief that the schedule is sacrosanct is not helpful when reality disagrees
with what’s on paper. Your code of ethics requires you to advise your col-
leagues and clients as to what is realistic to achieve. Don’t be afraid to chal-
lenge the programme - the end-user delivery is more important than follow-
ing the schedule slavishly.
25.2 When there is fundamentally not enough time
The 2012 schedule for the infrastructure programme was unrealistic.

...The electrification timetable was not based on a bottom-up
understanding of what the works would involve.

Railway [32]
Large projects such as a railway electrification are planned by multiple in-

dividuals. Experienced senior engineers are expected to provide input to
the planning team as to the order, sequence, and dependency of tasks. The
planners, who may or may not be engineers themselves, have to coordinate
this into a single programme or schedule.
So, what happens when the full set of activities, when arranged to accom-
modate all the dependencies, results in a projected end date well beyond
the intended deadline for the project?
Planning teams sometimes have no choice but to make arbitrary adjust-
ments to the programme in order to bring the projected end date back into
line with the client’s expectations. This results in increased pressure on the
engineering teams to deliver quicker. If inter-discipline dependencies were
not known before the schedule was put together, then these will quickly be-
come blockers to progress, as one team waits for the output of another’s
activity. The tighter the compression, the bigger the impact of this kind of
delay.
Under time pressure, teams may have to work based on assumptions rather
than, say, hard survey data. Should these assumptions be proven false, the
resulting design has to be reworked. If that design is the basis for another
team’s work, then they also must rework. The time pressure hence creates
a pattern of knock-on delays that can cause the end delivery date to be later
than it would have been, had everyone just waited until the correct input
3
See also chapter V.53
27
data were received. One iteration of design is very likely to be cheaper than
two!
There is little an engineer can do to mitigate this problem, because it starts
with a deadline that may have been externally imposed and could be non-
negotiable. A few pointers to limit the damage could be:
• Notify your project manager of the threat to delivery as soon as you
identify it;
• Prepare an alternative plan of action for your work, if input information
is late - what will you assume, and how will you update your work when
the information arrives?;
• If you’re negotiating the deadline with your client, use a model of the
dependencies between activities to help them understand why they
can’t have the product on the day they want it; you may be able to
collaboratively identify some time-saving measures;
• Do not stay silent - your code of ethics requires you to speak up if you
think there’s a problem.
25.3 Managing the unpredictability of the real world
(Network Rail) failed to manage the technical challenges and risks of using
new technology, specifically a new design for the electrification equipment
and a new “factory train” for installing the equipment and its supporting
steel structures.
Network Rail did not conduct sufficiently detailed surveys...which meant
that some design work had to be repeated.
Railway [32]
It’s tempting to suggest that, with sufficient time, budget, and effort spent
on requirements gathering and other unfashionable but important activi-
ties, your project cannot fail. However, no matter how good your plans and
your starting position, it’s very unlikely that a complex project will commence
without at least some unknown factors. As time progresses, we discover the
answers to questions previously unanswered. This may invalidate the as-
sumptions we have made, forcing us to make changes to our designs and
plans.
For example, it’s not practical or economical to conduct a detailed ground
investigation for every site along a railway that needs a foundation for an
overhead line structure. Therefore, it’s almost inevitable that hard ground
28
will be encountered at some locations when attempting to install piled foun-

dations, as Network Rail did for the Great Western route. This can mean
a longer period taken to install the pile, or a revisit to the site with heavier
equipment.
When you create a programme of works, you must make a reasonable al-
lowance for unexpected setbacks. Otherwise, as soon as one thing goes
wrong, your programme collapses and becomes undeliverable.
If you have a fair understanding of the kind of setbacks that are possible
on your project, you can take action in advance to mitigate those risks. In
the case of the electrification programme, it could be argued from finding
12 above that the effort spent on surveys should have been increased to
sufficiently mitigate the risks.
Of course, you must balance the value of the risk mitigated against the ex-
tra cost to undertake the mitigating actions. These value judgements are
difficult to make, especially in a quantitative sense (because estimating the
probability of a setback is very difficult to do). This means that it is easy for
budget decisions to go against risk mitigation (you are asking your managers
to choose between the certain cost of your mitigation actions, and the un-
certain, and difficult to quantify, possibility of something going wrong).
Therefore, you should expect to be challenged by project managers on any
costly action you believe should be taken. Prepare a justification; reason it
out for them and communicate in terms that they understand: risk, impact,
programme delay, extra cost, safety implications. Project managers know
that all these things are threats to delivery - but you need to help them un-
derstand how they are caused and how your proposals will help.
25.4 Conclusions
There is always pressure to deliver quickly and at a low cost. As a profes-
sional engineer, your duty is to give accurate advice on the risks and con-
sequences of your colleagues’ and clients’ decisions. It’s unusual to have
sufficient influence to significantly delay a programme that is too short, but
here are some top tips on how to manage tight programmes and reduce the
risk:
• When scheduling tasks and dependencies, keep in mind that the only
deadline that truly matters is the delivery of value to the end user;
• It may be worth delaying the start of a task to await its late inputs,
rather than start early only to have to rework it later;
• Consider how to stage the delivery of a complex task, in order to allow
its successors to start work while you finish the final stages;
29
• Work on your confidence and assertiveness - you must be able to stand

up to project managers when the pressure is on to cut time out of the
programme;
• If you must cut out time, favour downstream tasks over upstream; it’s
hard to rush the “thinking time” element of work, but it’s comparatively
easy to speed up construction and testing, if more on-site teams are
available.
26 Roles in a multi-disciplinary project
27 Cross-discipline engineering activities
28 Value engineering, option selection and trade-

offs
29 How single-discipline designers contribute to

a whole solution
30 Interface management
31 Demonstrating an integrated solution
32 Reliability, maintainability and availability (RAM)
33 Analysis methods for RAM
34 Concepts of operation, use, and employment

If you’re lucky, you may already have heard of documents such as a concept
of operation (CONOPS for short) or operational concept. If you’re exception-
ally lucky you may also have heard of a concept of use (CONUSE) or concept
of employment (CONEMP), although these terms are less well-known.
These artefacts can be partitioned and titled in several ways, which can be
confusing, but they all serve one purpose: to provide background informa-
tion that informs the requirements that are set for a particular system of
interest.
Confusingly, many authorities disagree on the scope and naming of docu-
ments or artefacts in this subject area.
30
There are three main themes to consider and, depending on your source,
these can be included in a concept of operations or in another document
with a different name. Figure 16 illustrates some common naming conven-
tions. The magenta outlines are my own preferred conventions. What’s im-
portant is to figure out what your organisation does and doesn’t include in
its documentation.
However the documents or artefacts are structured and named, it is

essential for good system design that three concerns are addressed:
• what the users of the system need to accomplish;
• what the system needs to do for the users;
• how the system will be supported over its lifetime.
Figure 16: Core content and naming of artefacts as per several standards [9][10]
34.1 Concept of operations: what the users of the system

need to accomplish
If you take nothing else away from this section, at least remember this:
It is almost always worth making the effort to understand why your

customer is asking you to deliver a solution to them, because it can
help you define a solution that better meets their needs.
This first theme is one of the hardest to analyse in a pure sense, because
it is often very difficult to elicit pure needs from stakeholders without them
being in some way influenced by their ideas of what kind of system would
be a good or familiar solution. See chapter 42 for more detail about this.
31
One of the reasons for the confusion is that a concept of operations or

CONOPS is rarely created without a particular system in mind; that is, we
usually write a CONOPS after we have decided that we need to procure a
system.
Strictly speaking, though, the decision to procure a particular system
should be made based on the needs identified in the CONOPS, which
therefore needs to be considered first!
However, in organisations with well-documented processes for how they op-
erate, the core of a true CONOPS may already be available: the description
of the organisation’s structure and processes independent of technology, of-
ten referred to as business processes even if the organisation is not strictly a
business. I describe needs in this area as operational needs, where I really
mean “how the organisation operates” as opposed to “how users operate
the system”.
The reason for trying so hard to separate business-level needs from

technical requirements on the system is very simple: for any given set
of business needs, multiple system scopes may be possible - and the
optimal system scope needs to be selected before proceeding to de-
cide what that system must do. Figure 17: A tent,
a superyacht, an
apartment block: the
CONOPS for a home
34.1.1 Extracting the underlying needs would apply equally
to all three, as long as
As a solid example, let’s imagine we write a CONOPS for a toaster. We al- they have facilities to
ready have some kind of solution in mind, but want to identify the true needs support it
that underly why we are trying to procure that solution.
So, what do the users of a toaster need to accomplish? Of course, it depends
on the individual, but let’s list some likely candidates:
• Toast sliced bread
• Heat toaster pockets
• Toast sandwiches
• Warm croissants or rolls
Of course, it’s not enough to just know what the users need to do. We also
need to know the answers to many questions beginning with “how”, such as:
• How large are the items to be toasted?
• How many items are to be toasted at once?
• How often are items to be toasted?
32
Note that these needs can be met in several different ways. To de-
scribe the needs precisely, it is not necessary to dictate a particular
solution. The level of quality required will often exclude certain solu-
tions.
There is no single uniform way to ensure that you have asked enough of
these questions. You have to use your judgement to determine if your set
of needs is sufficiently complete for you to begin basing your system design
on it.
34.1.2 Placing the needs in their context

The fundamental needs we have identified now need to be placed in some
kind of environmental context in order to complete the picture that we present
in our CONOPS.
Where in the world are the intended activities going to take place? A com-
mercial kitchen is going to need a very different toasting solution from a
private kitchen.
The physical environment is only one aspect of the context; there are many
other possible sources of constraints that should also consider.
There are several different mnemonics for prompting the consideration of
different contextual themes. I prefer the PESTEL mnemonic:
Political - constraints arising from strategy, policy and doctrine of the user
organisation and/or applicable governments
Economic - constraints on costs, financing and benefits
Social - constraints arising from the interaction of people, including fairness
and anti-discrimination considerations
Technical/technological - constraints arising from the technology in the
environment, for example limitations on local construction capability
Environmental - constraints arising from the natural environment, that is
the geography - climate, terrain, wildlife and so on
Legal - constraints arising from applicable legislation and/or regulation
PESTEL is intended to take a very high-level view but it is reasonably appli-
cable to our family home example. Constraints such as local regulations,
availability of materials and labour for construction, the location where the
solution is to be used and the available budget all fit into these categories.
It’s not as important to categorise them precisely as it is to use PESTEL as a
prompt to help us identify the different issues that are in play.
33
34.1.3 Operational needs summary

However we package our documents, we need to attempt to understand and
describe the operational needs of our stakeholders: the things they need,
and the context in which those needs are to be addressed.
If we understand enough about why the stakeholders need the system, it
helps us make more informed design choices as engineers, and reduces the
risk that our solution fails to meet the needs of the stakeholders.
The operational needs should be used as a basis for validation of the solu-
tion. Validation is about giving evidence that a solution is fit for purpose.
The operational needs we have discussed in this section are a way to under-
stand and document that purpose.
34.2 Concept of use: how the users will use the system to
achieve their aims
34.2.1 Determining whether to have a system and what kind of system
to have
If we have established a good understanding about what the users need to
achieve, we can then begin to define a suitable system that will help them to
achieve it.
The fact that a customer has come to you asking for a solution means
that it is likely they believe they cannot achieve their goals without
some kind of assisting system. It is still worth questioning the system
scope to ensure it delivers the best value for the customer’s money.
There is usually more than one way to solve any problem expressed at the
operational level. The level of quality the users want to achieve/experience
will sometimes help exclude potential solutions.
The decision to procure a system and the definition of its scope is primarily
for the procurer (who may be the user) to do, but as an engineer with an en-
quiring mind, you are well-placed to assist them in their decision by helping
them eliminate systems and scopes that don’t meet their underlying needs.
A toasting fork might be an adequate solution for campers, or a family who
Figure 18: A toasting
are lucky enough to have an open fire (that they use often enough to coincide fork is only a suitable
with times when they want toast) and who are fit enough to stand over the solution for a narrow
fire holding the fork while the bread toasts, but this same solution is unlikely range of operational
to be fit for a user who has trouble with their joints and lives in an electrically- environments where
heated flat. toast is to be made
34
It’s essential to understand the full range of users for your solution
and consider a solution that accommodates most, if not all, of them.
Failure to do this can be embarrassing, costly, and possibly illegal.
Modern legislation in many countries requires producers of some items to

ensure that the items can be used or accessed by people with disabilities.
There are also plenty of cases where tools and equipment have been found
to be unsuitable for use by women, because the designers did not consider
that women might use them, and so sized them for male hands and bodies
rather than for the whole population’s size range.
Consider first legally-protected characteristics4 , but don’t stop there - hu-
mans are diverse in many ways.
This is one of the reasons why it can be very valuable to have a diverse team
of designers - they’re less likely to forget to consider the needs of groups they
belong to. Factors such as wealth, health, family situation, employment sta-
tus and culture have, in my opinion, very strong influences on user behaviour
and needs.
It’s impossible to fix your engineering team so that their own characteristics
"represent" all of society, but empathy is a skill anyone can learn, which is
why I can at least imagine what it’s like to be a parent struggling to get their
kids’ pram onto a bus, or an arthritis sufferer trying to send text messages
using a smartphone screen.
34.2.2 Capturing the necessary functionality and performance

Once we have some broad idea of the system scope (or, in other words, the
system boundary), we need to find out more detail about how the users will
use the system to achieve the goals we identified in the CONOPS.
There are several approaches to this task. Each has its own strengths and
weaknesses. Sometimes it can be helpful to combine more than one ap-
proach, depending on what works for a particular application. As always, be
suspicious of anyone who thinks there’s only one valid way to do it.
I prefer to take the goals from the CONOPS, go through them one by one,
and ask the users how they expect to use the system to achieve the goal.
This is a story- or scenario-based approach: a beginning, a flow of events,
and an end point where the goal has been reached.
Alternatively, a free-form brainstorming approach can be used to try to iden-
tify all the capabilities or functions of the system with all the goals simultane-
4
Such as ethnic origin, nationality, religion, gender, sexual orientation and physical or
mental disabilities
35
ously in mind. Since it is good design when a system provides functionality

that is used to support multiple goals, this approach can be effective despite
its comparative lack of structure.
Chapter 55 provides more detail of methods to record and represent the
needs that are captured through engagement with users. We don’t expect a
CONUSE to be pitched at the level of a contractual requirements document,
though; it’s sufficient to have an outline, described imprecisely, of the sce-
narios of the system’s use.
For example, the following serves as a guide for further detailing on the use
of the toaster to make a slice of toast:
When the user wants to toast a slice of bread, they:
• User plugs in the toaster to the power supply;
• User inserts a slice of bread into an appropriately-sized opening in the
body of the toaster;
• User sets the toaster’s controls to the desired time setting;
• User gives the toaster a command to begin toasting;
• Toaster heats the bread by radiation;
• When the time specified by the user has elapsed:
– toaster stops heating the bread;
– toaster gives a notification to the user that toasting is complete.
• User removes the slice of toast from the toaster without burning their
fingers;
• User may disconnect the toaster from the power supply or leave it
connected; if they leave it connected, the toaster maintains electrical
safety according to industry regulations.
This leaves a lot of questions open (that is, many design options are still to
be eliminated), but picks out the major points where value is needed from
the system and where inputs are needed from outside.
Consider now the storyboard in figure 19. This is a sketch of the same needs
(at least some of them) as we saw in the free text above, but perhaps this
form is a much more accessible way to engage stakeholders to express their
needs - and the overall story can be understood more quickly.
34.2.3 Human-machine interaction in the CONUSE

Of particular importance in the CONUSE is the identification of human-machine
interactions and the management of risks that arise from them. For complex
36
Figure 19: A storyboard describing how a toaster is used
37
user interfaces (hopefully not for toasters) issues such as the placement of
controls, the cognitive load of the set of stimuli that a user needs to handle,
and the risk of human errors are all significant and should be considered
when setting requirements on the system.
The CONUSE forces you to think through not only what is needed from
the system, but what is needed from the user and the environment in
order for the user’s intent to be satisfied. It is often overlooked that
successful engineering must ensure the requirements on the “other
side” of the system boundary must also be met and verified in order
for us to have confidence that the system will really be validated.
Human factors experts are trained to do the detailed assessment of such

issues, but you as an engineer need to involve them early enough in the
design approach, if they are to have a positive impact. Chapter 45 goes into
a little more detail on the topic of human factors.
Be wary of the temptation to make your products too “clever”.

You don’t want to put your customers in Dave Lister’s [33] position, driven to the point of
insanity by a talking toaster that just won’t take ‘no’ for an answer:
Talkie Toaster: Howdy doodly do! How’s it going? I’m Talkie, Talkie
Toaster, your chirpy breakfast companion! Talkie’s the name,
toasting’s the game. Anyone like any toast?
Lister: Look, I don’t want any toast, and he [gestures at Kryten]
doesn’t want any toast. In fact, no one around here wants any
toast. Not now, not ever. No toast.
Talkie Toaster: How about a muffin?
Lister: Or muffins! We don’t like muffins around here. We want
no muffins, no toast, no teacakes, no buns, baps, baguettes,
or bagels, no croissants, no crumpets, no pancakes, no potato
cakes and no hot cross buns. And definitely no smeggin’ flap-
jacks.
Talkie Toaster: Ah, so you’re a waffle man?
Perhaps you can think of other examples where overenthusiastic design did more harm than
good?
38
Figure 20: Scope of CONUSE and CONEMP related to standard lifecycle stages 30
34.3 Concept of employment: how the system will be man-

aged through its lifecycle
I have to be honest and admit that the term “concept of employment" is not
exactly common industry parlance. I learnt it working for a large company
active in transportation, space, defence and aviation. It’s a useful encapsu-
lation of all the concepts we need to know something about that are not
directly to do with using the system for its designed purpose.
An alternative document I have seen a few times is the “operations and main-
tenance" concept, where “operations" really means use as I defined in the
previous section, and “maintenance" covers a multitude of short- and long-
term tasks needed to keep the system in operation for its lifetime. Even here,
though, there is more to consider.
We have already covered design for usability in the CONUSE section, so we
will now focus on potential system needs we might uncover by considering:
Production - how the parts of the system will be fabricated, coded, built,
physically delivered, tested and handed over for use;
Support - how the capabilities of the system that the users need will be
sustained over the operating life of the system;
Retirement - how the system can be superseded, dismantled, removed,
made safe, and its components disposed of.
I hope you are beginning to get the feeling that the bulk of “requirements"
that we deal with as engineers are driven not by the basic functionality of
the system that we explored in the last section, but rather to sustain the
system’s capabilities safely and economically for the whole lifecycle. This is
not unusual, especially for fundamentally straightforward systems being de-
ployed in a highly regulated, critical environment such as combat, railways,
medicine, space or aviation.
39
There are two different types of need that might emerge from an analysis of
the system’s lifecycle:
• Constraints on the solution space (that is, factors that exclude certain
otherwise good solutions from the set of possible solutions);
• Extra features that are needed in order to ease or even enable the
system to be produced, maintained or disposed of.
34.3.1 Design for production

There’s a rather tired meme that’s done the rounds on sites like LinkedIn for
about as long as I’ve been working.
The story goes that the solid rocket boosters made for the NASA Space Shut-
tles were restricted in width by the need to transport them by rail from the
Thiokol factory to the launch site. The railway in question had a tunnel with
restrictive clearance; these clearances are somewhat related to the standard
gauge (distance between rails) of the railway itself, which is inherited from
the early horse-drawn tramways and, before that, from the ruts in old roads
that dated back to Roman times. Roman chariots were a standard size just
big enough to fit two horses side-by-side - and hence, so the tale goes, the
SRBs were constrained by the average size of a horse’s backside.
I don’t know if this tale is true or not (in reality, the railway’s track gauge
(distance between rails) does not hugely restrict the loading gauge (cross-
section of allowable vehicles)), but it is at least plausible and from that point
of view it is an excellent example of how considerations of the system’s life
before operation are very important.
You can create the most elegant design, but if it cannot be built, it will for-
ever remain just a twinkle in your eye or a sketch on your drawing-board.
However, as we just saw, we also need to think about sourcing materials
and transporting the product to the site where it is needed, as well as con-
struction itself.
Tooling is a common concern in the automotive industry because the costs Figure 21: The design
of a complex prod-
of retooling the production line are significant. A design that requires too
uct has a significant
much retooling might be rejected even if its functionality is superior to other impact on the tooling
options. needed to manufac-
ture it [11]
Looking at the toaster example, tooling might also be an issue - we would
expect to mass-produce parts and this would require a certain amount of
setup.
Materials are another question - not only whether there are certain materi-
als that can’t be sourced economically, but also whether the materials them-
selves, the manufacturing process, or the byproducts of manufacturing are
40
harmful to the environment. The switch to lead-free solder in electronic cir-

cuits, for example, had wide-reaching impacts on production facilities - sol-
dering equipment had to be replaced or modified, and any pre-tinned com-
ponents also now needed to be lead-free.
Then we have the matter of transport. Our systems need to be packaged
and delivered from the manufacture site to the place where they’ll be used.
How big are the packages going to need to be in order to protect our toaster
from damage during transport? How many packages can we fit on a stan-
dard pallet? It wouldn’t be beyond imagination to shrink the size of your
perfect toaster design by a few millimetres in order to fit an extra two or
three packages on that pallet and thereby save on delivery cost.
As a final thought (but there are definitely other aspects to consider - this is
just a taste), consider how the system will be tested and handed over. For
the toaster, this would happen before it’s packaged, but for systems that are
more tightly integrated into their environment (like an electrical installation
in a building), testing can only happen once the system has been built in
situ. Design for test is almost a discipline in its own right. Test specifications
require that certain quantities be measured while the system is running -
how do we ensure that testers can safely access those physical points in the
system in order to take measurements? Figure 22: Testing elec-
tronic hardware - here,
Sometimes a production system can be part of the system itself. The elec- only 40% of the cab-
trification programme for the Great Western Main Line between London, inet is the device un-
der test, the rest is
Bristol and Cardiff included not only the construction of the electrification
hardware designed to
infrastructure but also the procurement of a “high-output production sys- make the inputs and
tem", a fleet of engineering trains each fitted for a stage of the construction outputs more easy to
procedure. measure and monitor
Figure 23: One of the HOPS (high-output production system) engineering

trains developed for the electrification of the Great Western Main Line in
the UK [12]
41
34.3.2 Design for supportability

Supportability is a broad theme that really needs further decomposition.
When we talk about supportability we need to cover the following themes
as a minimum:
• How the system will be maintained over its life, both preventively (rou-
tine servicing) and correctively (repair);
• How the system will be moved from one place of work to another (if
applicable);
• How the system will be supplied with power and consumables;
• How waste products will be removed from the system;
• How the system will be updated or modified.
Our toaster example could be fairly straightforward. A typical consumer
toaster:
• has no user-serviceable parts and requires no preventative mainte-
nance;
• would usually (not always) be disposed of if it fails;
• might be warranted for a year or two after purchase so it could be re-
paired by the manufacturer (or simply exchanged for a new instance);
• is hand-portable and has no special requirements for being taken from
one home to the next;
• uses mains power from standardised outlets;
• needs a way to empty old crumbs that collect in the bottom;
• would not be updated or modified.
Preventive and corrective maintenance can sometimes dominate the

cost of running a system, especially if the system has a long lifespan, is dis-
tributed over a wide area (maintainers have to travel from site to site) or has
substantial hazards (maintainers have to be kept safe while working). Fail-
ing to consider the envisaged maintenance tasks means the system may not
readily support them, which can lead to higher maintenance costs, increased
risks to maintainers, and a lower level of quality of maintenance.
Railways have all of the complications I listed above. Given that many rail-
ways around the world were constructed 100-150 years ago or more, the ini-
tial cost of production is long since sunk, and is dwarfed by the tasks of mod-
ern maintenance, which (thankfully) have much higher standards of worker
42
safety. A few examples of necessary tasks follow - try and think of the tech-
nical implications on the design of the railway as a system.
• To maintain a safe wheel-rail interface, rail grinding is carried out reg-
ularly, in order to bring the rail cross-section back to specification after
it has worn through use;
Figure 24: A self-
• Trains and track must be regularly inspected to verify that their safety- propelled rail grinder
at work [13]
critical components are functioning as expected;
• Rolling stock must be kept clean and intact for a good customer expe-
rience, including the removal of graffiti and the repair of damage.
Over time, with a greater understanding of how much these tasks impact
the lifecycle cost of the system, more effort has been made to constrain or
guide the way parts of the railway are designed, so that they support these
tasks better.
• Rail grinding is carried out by dedicated self-propelled vehicles, one
stretch at a time, every night;
• Many on-board and trackside systems have automatic condition-monitoring
capabilities either built in or added, to reduce the amount of manual
inspection and diagnosis work needed;
• Materials on rolling stock are selected for ease of cleaning, resistance
to cleaning agents, and resistance to deliberate damage.
Supporting software-intensive systems can be considerably more com-

plicated. If we decided have a more intelligent toaster (for example, some
kind of internet-of-things solution that orders your bread when you run low,
or gives you advice on your morning commute) then we enter a world where
software complexity begins to dominate the overall proportion of complex-
ity in the system.
Software-intensive systems usually need to be updated - either because the
manufacturer likes to beta-test the software on paying customers5 or be-
cause functionality and data have shelf-lives (for example, virus protection
or map data that changes over time in order to maintain equivalent func-
tionality).
This would result in more demanding needs - we might require an Internet
connection, and as the manufacturer, we would need to support the product
for a reasonable period with software and data updates that keep the toaster
working.
5
Mentioning no names, because these days, they all do
43
Railway command, control and signalling systems have been based on elec-
tronics and software for the past 30 years or more. They have the peculiarity
that their service life (around 30 years) is much longer than the evolution cy-
cle of the technology on which they are based. Software upgrades on early
installations were designed to be carried out with the update on a floppy
disk, meaning a technician has to visit the site and manually transfer data.
These days, remote upgrades are possible, but may be ruled out in design
due to the network connection being vulnerable to security threats.
Material in- and outflows must be considered carefully so as not to ig-

nore something obvious. If we took a more complex household appliance
like a washing machine, we would now start to see more demanding require-
ments for material flows into and out of the system: washing water (with, of
course, a need to keep consumption down); detergents and fabric soften-
ers, plus other more exotic additives. We also need to ensure a waste water
connection is available. So the washing machine is more dependent on its
environment than the toaster is, in order to keep functioning.
Scaling up again, an artillery system is so dependent on the supply of am-
munition that the supply chain might often be engineered as part of the sys-
tem. With a system like this, the complexity of the logistic chain (containers, Figure 25: A rocket
handling equipment, trucks, aircraft etc.) starts to be a critical source of con- artillery system needs
straint on the overall performance of the solution, despite not being central a substantial logistics
chain to remain in ser-
to the basic functionality. The supply chain might even be more complicated
vice. Upper image
than the gun itself. - a launcher vehicle;
lower image - the lo-
Waste products, of course, can be a whole new can of worms. I need only
gistics vehicle carrying
mention uranium fission as a source of nuclear power for electricity gener- two reloads. [public
ation. Humans will be dealing with the consequences of design decisions domain images]
of the 1950s for centuries to come. Thorium fission might be an alternative
with lower levels of seriously harmful waste. Can you think why it hasn’t yet
been commercialised?
34.3.3 Design for retirement

I think that retirement (or disposal, scrapping, dismantling etc.) is the most
overlooked lifecycle phase in engineering. Creative and enthusiastic engi-
neers a) don’t want to spend a lot of time thinking about their ideas and
designs being broken up and replaced, and b) don’t always want to think
far enough into the future to consider such a remote occurrence. A finite
service life is not always even considered.
As environmental concerns have become more and more prominent in de-
sign, though, it becomes increasingly important to consider how to dispose
of the system we are designing when we’re finished - especially if it has a
short life and/or will be consumed in large numbers.
44
At the University of Birmingham, where I studied, there is a building called

the Muirhead Tower - a love-it-or-hate-it Brutalist concrete monolith from
the seventies. There was a rumour6 going around when I was a student that
the university wanted to demolish it and replace it with something easier on
the eye, but couldn’t because there was so much tension in the reinforced
concrete foundations that nobody could figure out how to take them apart
safely.
Although it’s a rumour I find it quite plausible that similar things can happen
in other instances. Consider the kind of expensive disposal work that en-
sues when an older building is being maintained or modified and asbestos
is discovered.
We must not design systems that cannot be unmade without undue

risk to health, safety or the environment.
We already mentioned harmful materials in the production section, but they

of course have a much bigger impact in disposal. In our toaster we’ll prob-
ably have some fairly common metals like iron, copper and aluminium, but Figure 26: Nuclear
fission requires exten-
also circuit boards, insulation, plastics and perhaps dyes, lacquers and pol- sive preparation of
ishes. fuel and long-lasting
solutions for waste
Under the WEEE (Waste Electrical and Electronic Equipment) directive [34] in disposal, and the
European Union law, distributors of electrical goods now have to take back decommissioning of
equivalent waste goods. Our toaster, at the end of its life, can be taken back reactors at the end of
to the shop where it was bought (or any equivalent shop) and they are now their lives. Top - stor-
age of waste products
responsible for handling and disposing of the waste safely. This is intended
from the fuel enrich-
to avoid such items being disposed of in household waste and ending in ment process; centre
landfill. - low-level radioactive
waste buried in pits;
You will note that the onus here is on the distributors, since they have the bottom - the Sellafield
direct contact with consumers. It seems fairly likely though that pressure complex in north-west
trickles back to manufacturers: distributors won’t want to buy products that England [14], which
will be expensive to dispose of, because they know in a few years they will reprocessed spent
Magnox fuel from
be the ones handling that waste.
1952 to 2022 and is
As a final thought let’s consider again uranium fission reactors - the spent still active in nuclear
decommissioning
fuel rods might be removed, but a nuclear reactor is a highly complex device
with many parts and material flows, some of which might be radioactive for
a long time after the reactor is shut down. Decommissioning a nuclear site
is definitely something you want the designers to have considered if you are
the one doing the dismantling.
6
and I never found any evidence to support it, so I certainly don’t claim it’s true
45
35 Examples of design for maintenance
36 Managing entry into service
37 Delivering work safely
46
PART
Thinking like a better engineer III

38 The importance of history to modern engi-
neering
How many of you are aware that museums like London’s Science Museum
are curated primarily by historians, rather than scientists or engineers? Yes,
the objects on display are technological, but the creation of the galleries and
the educational content developed is itself an academic discipline.
Modern museums don’t just set out a row of exhibits in glass cases, they
take the visitor on a journey and tell them a story that is designed to achieve
a learning outcome: just like a lesson in a school or a lecture in a university,
but delivered via a very different medium. Museum websites and YouTube
channels extend the story-telling into your home with photographs, sound,
and videos.
When I learnt about this I was fascinated by the potential: we can look at
an object like the replica of the Telstar communication satellite in the Sci-
ence Museum’s Information Age gallery7 and admire its physical structure,
its form and its technology, but what about the social context? What differ-
ence did this object make to the lives of people who used it? What makes it
important enough to be selected out of the thousands of historical objects
held in the Science Museum archives and put on display to the public?
Those of us who have been educated in science, technology and engineering
disciplines have a tendency to look down upon the arts (languages, history,
philosophy and so on) as being lesser or less relevant areas of study. This
kind of academic tribalism can get in the way of us learning from each other.
History is a valuable body of knowledge for engineers to use. It’s enormously
helpful to understand not just how things are, in a technical context, but why
they are so. I don’t mean here the physics, but rather the story behind the
object. As engineers, we should be interested in aspects such as:
• What factors influenced the decisions that were made leading up to
this object being developed/this situation emerging
7
London’s Science Museum in Kensington is free to enter and is highly recommended to
anyone visiting London. It’s one of my favourite places. See https://www.sciencemuseum.
org.uk/ for more details.
47
• What impact a technology had or has on society, users, or even engi-

neers themselves
• Why alternative technologies or approaches were not pursued
• What problems were encountered, and/or what mistakes were made,
in the development of a technology
Historical decisions often have a great impact on modern-day engineering.
The standard railway gauge of 1,435 mm (or, originally, 4’ 81⁄2”) became stan-
dard not because it was technically superior8 but, by the year when the de-
cision was made, had become so widespread in Great Britain that it was
considered more convenient to convert fewer route kilometres to 1,435 mm
than to convert more route kilometres to 7’, the other significant option.
Whilst writing this book and sometimes also at work, I find myself invoking
some of the skills I learnt studying history at high school - checking sources
for credibility and finding suitable material to back up claims I make. I tend
to use storytelling as a key part of how I argue for a particular choice. I refer
to relevant historical cases to support my arguments.
In the next subsections we’ll look at a couple of fallacies that hold us back
from doing the best engineering we can right now, and I’ll point out how
understanding the history can enable us to get back on track.
38.1 Fallacy 1: We tried that years ago, and it didn’t work,

so don’t bother now
As a junior engineer, brimming over with enthusiasm (I hope), you should
be sharing your ideas and suggestions to your colleagues whenever a prob-
lem presents itself without a solution. Unfortunately, your more senior and
jaded colleagues may well answer you with a variant of this section’s title.
Solutions are rejected all the time because someone thinks it has been tried
before and assumes that just because it didn’t work last time, it can’t work
ever. This is false for many reasons, such as:
• The idea might not have been implemented correctly last time;
• The conditions surrounding the idea/technology may have changed
since the last time it was tried;
• The enabling technologies may have improved;
• Our understanding of the scientific principles may have improved.
8
it wasn’t, when compared with the 7’ (approximately 2.1 m) of Brunel’s Great Western
Railway
48
The tilting train9 is a great example of a technology that came of age well
after it was first tried. British Rail first conceived the idea of an actively-tilting
train in the 1960s, but although its first prototype successfully demonstrated
the principle, the later prototypes that were employed in operational trials
were plagued by a range of technical and political problems until the entire
programme was halted in the mid-1980s.
However, the core tilting technologies were sold to the manufacturing com-
pany Fiat, which developed them and other ideas further into a successful
platform known as Pendolino. After finding customers throughout Europe
and beyond, Pendolino eventually entered service in the UK in 2002.
It would have been easy to dismiss an active-tilt train as being impossible
given the evidence of the failure in the 1980s, but if the general engineering
principles still show some benefit10 then it is still reasonable to keep trying
an idea with new approaches and execution until success is achieved.
38.2 Fallacy 2: We know better than the engineers of the

past, so we’ll ignore what they did
At the start of an engineering project, team members are often excited and
enthusiastic and want to press on with progress as fast as possible. It’s good
to be confident of one’s own abilities, but it’s also important not to ignore
lessons from the past that might be relevant to our work.
Taking again the British Advanced Passenger Train (APT) as an example, the
team that was assembled to develop this new tilting train was not a tradi-
tional set of railway rolling-stock engineers; many of its members came from
the aerospace industry or academia. The APT did not simply fail because the
tilting technology didn’t work; the train had many other features that were
novel to the railways and that also were quite immature.
The lack of experienced input from engineers who had worked on previous
trains was a factor in the decision to adopt some of these novel technologies.
Not only that, but a lack of understanding about what kind of operational
and physical environment the trains would experience is also evident in the
solution. We talk about this in more detail in section 60.
49
Figure 27: Balancing negative experience of the past with ambition and self-
belief for the future
38.3 Conclusions
When we undertake a new piece of development, we need to balance ex-
perience from the past with self-belief and a willingness to try an idea in a
new way. An acceptance that not all of these attempts will succeed is also
important, otherwise fear of failure keeps us from truly innovating.
Learning about the history of development is the cure to both the fallacies
of “it didn’t work last time so it can’t work” and “the dinosaurs don’t know
what they’re talking about so let’s ignore them”. By asking questions such
as those I proposed in the introduction to this section, we can find out what
went wrong last time and propose better approaches for the future.
39 Why a systematic approach to engineering is

critical: a case study from the 1990s
Figure 28: An ambu-
lance of the London
It’s a sad fact that our collective thinking only seems to evolve when we’ve
Ambulance Service
experienced a major failure of our conventional approach. You can see the (this example regis-
evidence for this in the way safety features are often linked to specific his- tered approximately
toric accidents; they’re designed to mitigate the consequences of an event 8 years after the
we didn’t even anticipate before it occurred. incident in the case
study) [15]
However, sometimes it’s worse than that – something terrible happens and
9
I refer here to a train that employs “active tilt” mechanisms to lean into curves, rather
than the less complex “pendular tilt” that was implemented from the 1920s
10
A tilting train reduces the lateral forces felt by passengers when a train goes around a
curve; this is of particular benefit if you want to run high-speed passenger trains on older
tracks that have lots of tight curves, but less so for more modern high-speed railways with
shallower curves
50
we don’t learn from it. I wrote this case study (with heavy reference to to the
report of the official enquiry [35]) a few years ago for a seminar on systems
engineering in the railways. It’s painfully relatable to my own experience,
which only started twelve years after this incident.
Think about the recent projects you’ve worked on, or those you’ve read about
in the news. Has the engineering community really learnt these lessons
from over 30 years ago?
39.1 Background: introducing an automated dispatch sys-

tem to an ambulance service
In 1991, the London Ambulance Service (LAS) invited tenders for a Computer-
Aided Dispatch (CAD) system. The features of the specified system were:
• Efficient call taking with paperless data input and an automatic triage
system to prioritise cases;
• Automatic vehicle location and optimal allocation of calls to vehicles;
• Automatic mobilisation through electronic transmissions to ambulance
stations or vehicle data terminals;
• Collection of performance information for management ;
• Pan-London management and allocation of ambulance resources.
This was LAS’ second attempt to computerise its command and control sys-
tem, having previously aborted one project after spending £7.5 million. The
first system had been abandoned after load testing, where it was discovered
that it was not capable of coping with the demands that would be placed
upon it. It should be noted that the features listed above made the system
extremely novel, since this arrangement had not been tried before.
The winning bidder was a consortium of a relatively large computer hard-
ware company and a small software house, which would be providing the
CAD software. The consortium bid was worth £937,463; the next-lowest bid
being some £700,000 more expensive. The timetable was very tight and the
inquiry report suggests that cost and timescale took a higher priority in the
awarding of the contract than factors such as capability to deliver the re-
quired functionality. The experience of the bidders in delivering similar sys-
tems was not considered.
39.2 Implementation
On the 26th October 1992, after a lengthy period in which the system had
been installed (in an ad-hoc phased migration), the new CAD system was im-
plemented fully. The report [35] states that neither the system nor its users
51
were ready for this on that date. Amongst the problems still outstanding
were:
• CAD software was not complete, properly tuned or tested;
• The backup file server hadn’t been tested;
• The vehicle-based equipment (data terminals and vehicle tracking) suf-
fered from data transmission and accuracy problems;
• Staff had inadequate training and poor confidence in the new system.
In particular, the allocation system was highly dependent on accurate posi-
tion reports from ambulance crews. When vehicle positions were not known
or incorrect, the system started to make mistakes in its automatic alloca-
tion of calls. These poor allocations made the situation worse, as the sys-
tem rapidly lost the correct location and status of more vehicles. The effects
slowed the entire system, even making it slower for staff to respond to each
call.
In a technical sense, the allocation system did not fail – it performed accord-
ing to how it had been designed, but the trouble was that it had been de-
signed with some fatal flaws which meant that in the real world, it was never
going to be able to function correctly.
This is where we must recognise the difference between verification (check-
ing the system works as designed) and validation (checking that the system
actually delivers the benefits it was meant to, when in its environment and
used by the true end-users). We’ll be examining both verification and valida-
tion in detail in later chapters.
39.3 Total system failure

On the 27th October 1992, following the difficulties experienced on the first
day of implementation, the system for dispatching vehicles was rolled back
to a degraded mode where allocation was carried out by local ambulance
stations, but some of the computerised features were used.
However, in the early hours of 4th November, the system locked up. Staff
had to listen to recordings to ensure that all calls were being dealt with. Even-
tually, they reverted to the traditional paper-based dispatch system.
This failure was found to be caused by a minor programming error, where
a programmer had inadvertently left some code in the program which used
memory without releasing it. Eventually the server ran out of memory and
crashed. There was no backup server ready to take on the load.
52
39.4 Observations
Although the media at the time were quick to link deaths to the delays suf-
fered by LAS due to the difficulties with the new system, no inquest came
to that conclusion. However, even if nobody died because of the delays,
the increased times for calls to be answered and for ambulances to arrive
must have caused much anxiety and distress amongst the public, as well as
damaging LAS’ reputation and further affecting staff confidence. The chief
executive of LAS resigned following this débàcle.
39.5 Lessons to take away

According to the report, the following were the key problems with the sys-
tem:
• A need for near-perfect awareness of vehicle locations and crew status
– the automatic vehicle location system was found to be as good as any
other, but could still not guarantee perfect accuracy;
• The ambulance crews had difficulty correcting any mistakes they made
with the data terminals, when notifying their status;
• Radio bottlenecks at busy times such as shift changes, and a suscepti-
bility to lost communications due to radio dead spots;
• Handshaking faults between mobile data terminals and the despatch
system;
• Poor tolerance for realistic working practices, such as the occasional
situation where a crew took a different vehicle from the one originally
allocated to them;
• Slow performance of the CAD system, or locking of user interfaces, re-
sulting in reboots;
• Excessive generation of exception messages, which, in some cases, re-
sulted in the generation of yet more messages about the number of excep-
tions, making it very difficult for staff to clear the backlog.
To be blunt, the management of the project and the way in which the re-
quirements were defined were fundamentally flawed.
Staff, the most important component in the system, were not consulted, nor
were their working practices reviewed as part of the requirements gathering
process. In fact, the automation project was seen by management as a quick
fix to improve their industrial relations simply by virtue of its existence.
53
Before thinking about what system or product to procure, a good client

first has a look at what they want to achieve operationally – how many
staff do they want to employ, what are their job descriptions, and how
do their activities align with the organisation’s overall aims?
This is valuable background for when the engineers come on the
scene, and a great opportunity for consulting engineers with expertise
in concepts of operations to market their skills to client organisations.
In many projects, not only the users but other parties may be stakehold-
ers, and we need to consider their requirements too. In this instance, we
could consider the maintainers, managers, and the patients as stakeholders
to success or failure of this dispatch system.
Think about who is affected, positively or negatively, by the success,

failure, or just the operation of the system or product you’re develop-
ing.
Try drawing a context diagram with your system in the middle and the
stakeholders around the outside; link the stakeholders to the system
with a description of the interaction. We’ll do a later post on some
examples of this.
A better approach would have staged interviews, mock-ups and simulations

for ambulance crews and control centre staff, allowing the engineers to try
out their solutions with the buy-in of the people who would eventually have
to use them. This would have flagged up to the engineers that they would
need to design a system tolerant to the quirks of working practices, human
errors such as incorrect button presses, and ergonomic design of user in-
terfaces for the software. These issues come under the heading of Human
Factors or Ergonomics11 these days – and HF is a fundamental part of systems
engineering wherever a system must interact with a human. See chapter 45
for more on this subject.
Wherever there is a human user, there are Human Factors to take ac-
count of. Get to know your HF specialist and keep them in the loop
from the start, don’t make them chase after you. Model, mock-up,
and simulate your product or system. Get the users in to have a look.
Identify training needs early and help your client plan for them so that
the introduction of the new system isn’t a big culture shock.
The technical difficulties, which also included visibility issues and black spots
11
These two terms are not entirely the same, but opinions disagree over precisely how
they differ; in this book I use HF to cover all these themes indiscriminately
54
on the data terminals issued to vehicle crews, would have been noticed
much earlier if a rigorous requirements analysis process had been followed.
This is where stakeholder requirements are interpreted into a set of techni-
cal requirements. As this process examined the radio network, it would have
flagged up the question of whether the existing radio network was adequate
to carry the level of traffic required to support the new system. Additionally,
evaluation of the vehicle location system would have uncovered the fact that
it was not possible to achieve 100 % accuracy, and that therefore this would
have to be tolerated by the rest of the system without catastrophic failure.
Just because it’s technically possible doesn’t mean it’s practically fea-
sible in the environment of the end-user. Understand the deploy-
ment environment and make your system or product robust enough
to cope.
Choose the technology to fit the environment – rather than sticking
with a technological choice (perhaps it looks cool or is an elegant so-
lution) that won’t perform to meet the user’s needs.
Broadly speaking, the system as delivered was fairly close to what was spec-
ified – but the specification was flawed. There are plenty of techniques avail-
able that can help us develop good specifications.
If all requirements are known, and a rigorous engineering process is fol-
lowed correctly, the product cannot fail to meet the requirements; however,
this relies on full knowledge of the requirements at the outset.
In the real world, requirements change – and a robust change control

process is needed to account for this.
The LASCAD project did not manage change effectively. Software updates
for various subsystems arrived on an almost daily basis. In the run-up to
implementation, the system was not in a stable state because things were
changing all the time.
In chapter IV.51, we identify that the verification or validation criteria are a
key part of the requirement. As we develop the internal architecture of the
system, and understand more detail about external interfaces, we can de-
velop similar specifications for integration.
This leads to a logical progression for testing when the system is imple-
mented – first checking that the parts interact correctly with each other, then
that the whole system works correctly as a single entity. It seems that in
the LASCAD project, this rigorous testing regime did not take place. Unsup-
ported by change management, it was impossible to be confident whether
or not the system would work, especially given an ad hoc migration strategy
55
which left the system in an undesigned configuration for a long period of

time.
If we have a progressive and layered approach to developing require-

ments and test specifications, we can begin evaluating them even be-
fore we’ve built the system – by reviewing how well we think the design
fits the requirements, we can gain progressive assurance that we’re on
the right track.
This is of enormous value to clients, and gives a supplier the confi-
dence that they will achieve acceptance on schedule, thus ensuring a
timely payout of the contractual fee.
39.6 Conclusions
This is a case study I wrote up some time ago, and it highlights a number
of lessons to be taken away. We’ll be covering some of these in much more
detail elsewhere in the book, but the intention here is to get you to think
about your own work and ask yourself if some of these errors, which seem
pretty obvious in hindsight, crop up in your organisation. Here’s a list of key
questions you could ask yourself:
• Are we designing something that really meets the user’s needs?
• Have we identified all the stakeholders of our product/system, and cap-
tured their requirements?
• Does each requirement we’ve written or captured have an associated
verification or validation criterion?
• Are we making sure that our production/software development pro-
cesses aren’t leaving behind artefacts that might affect system perfor-
mance?
• Are we bidding for/winning/carrying out work that is within our capa-
bility as an organisation? Do we have enough of the right people, skills,
funding, materials?
• Do we have enough time to do the work safely and correctly?
• How confident are we that our design is robust enough to perform to
the required level in the target environment? Do we need to beef it up
a bit, model it or simulate it in advance?
Good engineering isn’t just about doing the work right, it’s also about
demonstrating that you did it right.
56
The biggest question of all I want you to think about is this:

If the worst happened tomorrow and there was a fatal incident involv-
ing my work, could I stand up in court and defend, successfully and
honestly, my engineering judgement in the face of cross-examination,
in front of national media and the families of the deceased?
If the answer to that is “no”, you need to think about changing something in
your organisation, or, ultimately, looking for a new job.
57
40 The bridge to nowhere

40.1 The valley and the well (a contrived parable)
40.1.1 How it usually happens
A civil engineer gets a call one day from a new client, an elderly man who
lives in a remote location.
“Good morning”, the client says, “I was wondering if you could come out here
and build a bridge for me. My old one collapsed in a flood and now I can’t
get to my well.”
“I’m sure we can help”, says the engineer. “I’ve designed dozens of bridges
and they are performing well throughout the world. You’ve definitely come
to the right people to deliver your bridge. We have a range of standard de-
signs for you to choose from, or we can develop your own bespoke bridge
to your specific requirements.”
The engineer packs up her surveying equipment and drives out to the client’s
remote house. The collapsed remains of the bridge sit in a deep ravine
where a recent flash flood washed away the ageing wooden foundations.
The well sits, in good condition, on the other side of the ravine.
“I see your problem”, she says. “Those piles are rotten; they should have
been mounted on something rather than dug straight into the ground. Good
job you asked me to come over here. I can design you a great new concrete
bridge. I do need to know a few technical specifications, though – I never
start a job without a clear brief! What’s the loading?”
“My weight, plus that of a bucket of water. I used the bridge to get over to
my well – you can see it on the other side of the ravine.”
“No problem, sir. I have a standard design that will do fine for this job. My
team will be on site next week and your bridge will be ready in a month.
That’ll be £10,000 – my invoice will be in the post.”
Being a competent project manager, the civil engineer soon organises sur-
veyors, builders, plant, equipment and all the necessary support to build the
bridge. The client is all smiles as he trots along his new bridge to fetch water
from his well, but on his way back, carrying a full bucket of water, he slips
and has a bad fall. He breaks his leg and, although it heals eventually, he
has to give up his independence because his limp means he can’t manage in
his remote home any more, and has to move to sheltered accommodation
in the city.
58
40.1.2 How it could have happened

A civil engineer gets a call one day from a new client.
“Good morning”, the client says, “I was wondering if you could come out here
and build a bridge for me. My old one collapsed in a flood and now I can’t
get to my well.”
The engineer takes a moment to think.
“So you say you can’t get to your well. Did you use the bridge for anything
else?”
“Oh goodness me, no – it’s all weeds and undergrowth over there. But I don’t
know what I’d do without that well – I’ve had it these past sixty years. I’ve
been having to have water delivered by van and the costs are extortionate!”
The engineer turns up at the site the next day and the client finds her nosing
around the house, measuring the roof dimensions.
“What’s all this? I thought you were here to build me a bridge. Shouldn’t you
be surveying the valley? And what’s this hole you’ve dug in my back yard, not
twelve feet from my kitchen door?”
The engineer rolls up her tape measure, makes a couple of notes, and smiles
kindly at the elderly gentleman. “Well, you said you wanted a bridge, but
what you actually need is six buckets of water a day. This trial pit is only four
feet deep and you can see it’s damp at the bottom. That suggests to me that
we could dig a well on this side of the ravine, if the water’s uncontaminated.
“If it turns out not to be clean, your roof is big enough that, assuming average
rainfall, you can collect, treat, and store enough water here on this side of
the ravine.
“In short, sir, you don’t actually need a bridge, and both alternatives would
cost less than a bridge. Your real problem was how to get water to your
house. Don’t you think your knees might feel better if you didn’t have to
carry that water all the way across the bridge?”
The look of relief on the client’s face is remarkable.
“Do you know, I’d never even thought of that? I guess I just got so used to
tromping across the bridge that I just thought the simple thing to do was get
another one built.”
Within a couple of days, the engineer has organised water sample tests and
confirmed the groundwater is safe to use. A mobile drilling rig sinks the new
well within a day. A couple of photovoltaic panels attached to the roof of the
house power a small pump that raises the water to a new header tank in the
house. The client lives another fifteen years in his remote house.
59
40.2 The lesson

You can be forgiven for feeling this story is contrived. I contrived it in order
to illustrate the single most important aspect of being an engineer.
We are here to solve problems that meet needs, not deploy solutions
that tick boxes.
In the first story, the engineer looked no further than her client’s initial brief,
taking it as read that this was a true and accurate representation of the prob-
lem. She delivered what was asked for, and she got paid, but the client didn’t
really benefit from paying out that money, because the solution wasn’t actu-
ally the optimal way to meet his underlying need. There was nothing wrong
with the bridge. Her team built the solution right, but they didn’t build the right
solution.
In the second story, the engineer took a moment to explore the initial brief by
asking “Why?” and investigating the intended use for the proposed bridge. In
a couple of questions, she was able to isolate the underlying need (a source
of water) and verify that the bridge was not being used for any other pur-
pose. By doing so, she was able to come to the fairly straightforward conclu-
sion that a bridge was not the best solution for supplying water to the house
on the other side of the ravine. A little ground investigation near the house
showed that water could be supplied locally, which actually made life easier
for the elderly client and enabled him to live in his home longer.
40.3 The bridge to nowhere - in real life
Engineers discussed the type of bridge suitable for the area, but no-one
questioned the need for a bridge at all. . . Although pleased with the
bridge, settlers presumed it was more to advance the long-promised
Taranaki-Waimarino road than to provide land access to the lower valley.
They themselves had little use for the bridge by the time it was finally
constructed.
Interpretation board at the site of the Bridge to Nowhere, Mangapurua

Valley, New Zealand
It turns out that my rather contrived made-up story has at least one real-life
manifestation: the so-called Bridge to Nowhere in New Zealand’s beautiful
Whanganui National Park. New Zealand’s government gave parcels of land
in the remote Mangapurua valley to soldiers returning from service in the
First World War. To access these plots, a road was built into the valley from
60
the Whanganui river, and eventually a reinforced concrete road bridge was
built, spanning the Mangapurua gorge. Despite these efforts, the remote-
Figure 29: The “Bridge to Nowhere”, Mangapurua valley, New Zealand
ness of the location defeated the efforts of settlers to successfully turn this
wilderness area into farmland, and the scheme was eventually abandoned,
leaving the bridge behind as a lasting reminder.
40.4 A familiar situation in YOUR industry?

This was a simple example, but it illustrates how often clients will come to
engineers with a brief that all but states the bill of materials for the parts
that they think we need to procure to get the job done.
We all want to please our clients, do a good job, and get paid. Sometimes,
though, pleasing the client and doing a good job do not mean simply obeying
every client instruction without question. Clients, especially those who aren’t
experienced in engineering or procurement, will often struggle to articulate
their true needs, or make assumptions about what it is they want rather than
opening up the discussion to alternatives.
The pressure of tight programmes and delivery schedules mean that project
managers will want us to simply deliver what’s asked for on the list. We know
what they want, now we need to kick off and start delivering, right?
61
By taking time to explore the brief and the underlying needs, we can of-
ten uncover opportunities to optimise the client’s operational environment,
eliminate unnecessary effort, and deliver a more intelligent solution.
40.5 Key skills for getting to the heart of the problem

These skills and thought processes should help you be a better engineer by
taking that moment to think before ploughing on with a stock solution.
• Ask “why?” – where a decision seems arbitrary or a solution seems con-
strained, find out the rationale for it; it may be perfectly reasonable, in
which case you must record the constraint, or it may be possible to
change
• Take time to understand the operational concept the client has in mind,
consisting of three major parts:
– What they need to do (i.e. how their organisation behaves) to
meet their stakeholders’ needs
– What they need your solution to do to help them achieve the above
– How they envisage introducing, using, maintaining, and disposing
of your solution
• Be open to the possibility that a seemingly obvious solution may not
be the right one, once you’ve thought about it
• Use system architectural modelling to have a thorough representation
of what your stock solution can do and can’t do, so that you can easily
match its functionality to the needs you’ve identified
• Elicit information not only from your client but also from their stake-
holders, and marry it up to the constraints you are aware of from your
experience, standards, legislation and the site conditions
62
41 An introduction to engineering lifecycles
Figure 30: Stages of a typical engineering product lifecycle, according to ISO

15288 [16]
We are used to considering natural organisms in terms of their lifecycle - we

even label ourselves according to the position we occupy in our own lifecycle
- “baby”, “toddler”, “teenager”, “middle-aged”, “elderly”. It’s essential for en-
gineers to understand that our products also have a lifecycle, and that good
engineering at each stage of the lifecycle is what determines the success or
failure of the product.
The sketch in figure 30 illustrates the six lifecycle stages defined in ISO 15288 [16],
along with some keywords indicating the kind of activities engineers might
focus on at each of these stages. In this chapter, we’ll explore each stage in
a little more detail.
What’s nice about 15288 is that it makes a clear distinction between lifecycle
stages and the processes we carry out in each one. This is useful because the
processes transcend several stages of the lifecycle, and we limit our thinking
if we make a one-to-one association between lifecycle stages and activities.
41.1 Why the early stages of the lifecycle matter

I remember, in my technology classes at school, that I was impatient with
the paper-based part of my lessons – I just wanted to get my hands on some
tools and materials, and build something.
The temptation to skip the thinking part, and proceed as quickly as possible
to the physical work, is a constant risk in engineering. This is because the cost
of correcting errors (the blue line on the above graph) or making changes
rises exponentially as the lifecycle of a product progresses. Consider how
much easier it is to change the position of a line on a CAD drawing, compared
63
Figure 31: Green line: committed cost; blue line: cost of change
with digging up a reinforced concrete foundation so that it can be rebuilt in

a new position.
Looking at it in a slightly different way, the decisions made early on in the
lifecycle have the greatest impact on the eventual cost of the project. This is
the green “committed cost” curve on the graph above.
Of course, it’s also important to ensure that conceptual activities are bounded
sufficiently to enable decisions to be made in order for a project to progress
beyond a whiteboard. There is a balance to be struck between rushing off
without stopping to think, and spending too much time agonising over the
options.
41.2 The conception stage

Conception is where engineers identify needs and evaluate potential solu-
tions to those needs.
It’s not unusual for the solution to precede the need. We are engineers be-
cause we are creative, and when we come up with a new idea, it’s not always
64
because we’ve been considering the problems it could solve.

That’s why one of the essential aspects of the conception stage is matching
up needs to potential solutions and evaluating them for feasibility.
If the need came first, that means researching potential solutions and eval-
uating which is best. To do this, we need to define criteria that align with the
needs we’ve identified, and carry out a fair comparison.
If the solution came first, it means researching the market to identify po-
tential users who have needs that are met by the solution. The concept of
“a solution looking for a problem” is a completely viable way of developing
world-beating products. For example, the developers of the yellow sticky
note, found in offices everywhere, created the low-tack adhesive as a failed
attempt at a super-strong adhesive. According to Wikipedia [36], it was six
years before colleagues at 3M conceived the idea of using the adhesive for
sticking notes.
41.3 The development stage

This is the stage we would naturally associate with the word “design”, but in
reality the design has already progressed if we’ve identified the needs and
selected the basics of a solution.
Development, then, starts from a baseline of needs and assembles the com-
plete set of artefacts needed to implement the product. For complex prod-
ucts, this usually includes effort spent modelling the architecture of the prod-
uct and refining the needs into specific requirements that can be allocated
to separate elements in the architecture. We can also expect to produce a
range of artefacts such as:
• Drawings;
• Specification documents;
• Software models;
• Training materials & operating manuals;
• Maintenance procedures;
• Risk assessments and assurance evidence.
We might also carry out simulations and even build prototypes to assure
ourselves that our chosen design truly meets the needs before we commit
to it.
41.4 The production stage

At last, we can get our hands on some tools and build something!
65
Well, eventually – there’s more to production than the physical act of assem-
bling a product. Before we build, especially in constrained situations, we
need to consider:
• Procurement of supplies, parts, skilled technicians, and facilities;
• Planning of logistics and the sequencing of work;
• Safety, health, environmental and other risks;
• How the built product will be tested to demonstrate that the require-
ments have been met.
That last bullet point is probably the most important. Once our technicians
have assembled our system and carried out the tests, do we have confidence
that the client will approve the all-important payout?
The production phase includes all the activities needed to get our product
into the hands of the users. For regulated industries such as aerospace,
defence, and railways, this means a lengthy period of type-approval, testing,
and commissioning to put the product through its paces before the final
approval is given for use in service.
41.5 The utilisation stage

Once our product is in use, we might think the job of the engineer is over,
but that’s far from the reality.
Engineers are often on hand during the operation of complex systems, to
assist with resolving faults and to monitor the performance of the product
against the requirements. While a system is in operation, plans are made by
engineers for upgrades, renewals, replacements, and disposal of the prod-
uct at the end of its life.
Engineers also investigate faults and propose solutions and fixes to keep a
product operating optimally throughout its operational stage.
41.6 The support stage

A product like a railway can be in the support stage and the utilisation stage
at the same time, because maintenance is carried out regularly throughout
the period of time the railway is expected to operate.
However, support can take different forms. For example, a complex elec-
tronic system such as a highway management system might have a couple
of years of close on-site support from the supplier as part of the contract to
supply – but after that point, it might ramp down to the provision of essential
software bug fixes only.
66
The higher up in the value chain that an engineering organisation sits, the
more likely it is that engineers will be actively involved in the support part
of the lifecycle. Organisations that sell services rather than specific products
are responsible for utilisation and support to deliver against a service-level
agreement (SLA), rather than a scope of physical work.
41.7 The retirement stage

Nothing lasts forever, although we are surrounded by examples of engi-
neering products that have lasted well beyond the life their engineers could
have foreseen. The Victorian railways, bridges, canals, and sewer systems of
Britain are still very much in use today.
Conversely, modern cars can be accused of having been built with a limited
lifespan so that the manufacturers can sell you a new model in a few years’
time.
Whatever the eventual lifespan of a product, disposal of products that are no
longer to be used is a critical factor for consideration by engineers. Failure
to do so leads to issues such as the emission of CFCs into the atmosphere
by scrapped fridges, or the expensive incineration of train bodies because
of the asbestos used to insulate the roofs.
41.8 Considering the whole lifecycle

No matter where in the lifecycle you work as an engineer, the issues I’ve
picked out in this post mean that you always need to consider the subse-
quent stages of the lifecycle when making decisions.
We can’t know everything in advance, but we can ask sensible questions,
make informed assumptions, and record our thinking so that future engi-
neers have a basis on which to work when making further changes.
Although ISO 15288 is labelled as a systems engineering standard, the lifecy-
cle stages it identifies in appendix B are equally applicable to any discipline
of engineering, as are some of the processes defined in the main body of
the standard.
When planning an engineering task, or thinking of a new idea for a prod-
uct, I recommend you study this standard and use it to help you define a
framework for capturing everything you need to consider.
67
42 Reading behind the brief: distinguishing be-

tween requirements and solutions
If I’d asked my customers what they wanted, they’d have asked for faster
horses.
Apocryphal, variously (unprovably) attributed to early automobile

manufacturers Henry Ford, Gottlieb Daimler, Carl Benz etc.
This chapter focuses on identifying whether a statement we are given in a

client brief is truly a requirement, or something else.
42.1 Needs, preferences, and solutions
Figure 32: Need for a drink, expressed in three levels of abstraction
Consider the following statements:

1. I am thirsty.
2. I want a cold drink.
3. I will only accept 275 ml of *Brand X* lemonade served in a Collins glass
with ice and a slice of lime.
The first of these statements expresses nothing more than a basic need. The
second expresses a preference as to how that need might be met (that is,
with a drink that is perceived by the user as ‘cold’). The third statement pro-
68
vides a fairly precise definition of a particular solution to the general problem

of thirst.
42.2 Is the customer always right?

Each statement above provides progressively less scope for a hypothetical
bartender to assess their customer and, using the benefit of their experi-
ence, provide them with a refreshing beverage. If you’ve ever worked in a
bar, you may well have experienced customers who express their require-
ments in any of the three statements above. Good bartenders in reputable
establishments are trained to provide recommendations based on what the
customer says they like. Seriously good bartenders will challenge their cus-
tomers to try something new - which feels risky, but can be very rewarding.
Why all this talk about drink? I hope, by now, you are starting to see the
parallels with the problems faced by professional engineers when they pick
up a client brief. Just like our hypothetical bartender, we encounter clients
who express their requirements at different levels of abstraction. We are
under pressure to simply give the client what they first ask for, because, on
the face of it, that is what basic customer service is all about. However, as
we saw when we looked at the problem of the valley and the well in chapter
III.40, simply accepting the client’s brief without question is not always the
best way to achieve their satisfaction, nor to actually meet their needs.
It may not be an option to propose an entirely alternative solution to that
being asked for, but it’s still incumbent on us (in the UK, via the Consumer
Rights Act) to make the effort to understand the needs that underlie the
request, and satisfy ourselves that the solution is fit for purpose.
42.3 Why customers like to express solutions rather than

needs
In engineering, the same principles seem to apply as with customers in a
hypothetical bar, but with a heavy bias towards the very specific, solution-
oriented end of the spectrum. Here are a few reasons why this approach,
on the face of it, seems like a good idea:
• Clients think that, by doing this, they can make accurate cost predic-
tions to compare with the bids they receive;
• People are often comfortable with a familiar solution;
• The client may be unaware that there could be an alternative to their
pre-conceived solution;
• Novel ideas or solutions are sometimes viewed as risky, as compared
with “proven” products;
69
• The engineers or officials who write brief documents may not have the
training to examine the underlying need, because this is rarely a com-
ponent of an engineer’s education.
42.4 When might it be a good idea to simply ask for a so-

lution?
Whilst it can be risky to define a detailed solution when briefing a supplier,
it can also be risky to leave the definition too open. The risks of defining too
much or too little must be balanced against each other.
By simply specifying a solution, you are in fact carrying out a design exer-
cise. If you’ve understood all the needs, assessed the options, and selected
the solution based on some optimal measures against the needs, then it is
reasonable to constrain your supplier to the solution you have selected. It
is not reasonable, however, to ask that supplier to meet the original need
– you have already taken on the risk by doing a stage of design. In effect,
the supplier is not doing as much engineering for you, so your contractual
terms have to recognise that they bear less risk than you do, because you
have already made design decisions that they have no power to change.
Examples of where this approach might be reasonable are:
• When requesting replacement parts for a system that is already in
place;
• When you have already undertaken extensive stakeholder engagement
resulting in your solution being recognised as acceptable;
• When you have prototyped and tested the solution and found that it
meets your needs.
Always use caution when specifying a solution. You are taking respon-
sibility for the assertion that the solution meets the needs.
42.5 When to consider pushing back on the client’s require-

ments
If you are issued a client brief, you should be looking for a few key indicators
of solution definition, and challenging those where possible. There are some
telltales you should look for when reading a brief. They will indicate that
the client is trying to constrain the solution, and these should be carefully
explored. If, on challenge, there does not seem to be a reasonable rationale
for the constraint, then it should be rejected, because it can only add risk to
your project.
70
The following are a few examples, in the context of procuring a personal

vehicle for moving short distances.
42.5.1 Requirements expressed structurally instead of behaviourally

Look out for expressions such as “shall have”, “shall consist of”, “include”,
“comprised of”, etc.e.g. “The vehicle shall have four wheels”.
Do we need to have four wheels in order to move people short distances?
Perhaps we have a better solution that uses two, or three, or hovers on a
cushion of air.
42.5.2 Requirements that assume a physical architecture

This is easy to spot: the subject of the sentence is not the system, it’s a part
of the system that the writer has just assumed is there e.g. “WHEN the user
requests current location, the GPS unit shall display the vehicle’s current lo-
cation to the user”.
Does the vehicle need a GPS unit? What about LIDAR, inertial navigation, tag
scanners, odometry?
42.5.3 Requirements that express a constraint but with no justifica-

tion
It’s common to find many constraints in a client’s specification. In indus-
tries such as the railways, where it’s usual to procure one item that must
fit in to an established environment, we should expect to find many valid
constraints in a specification, because we are really delivering a subsystem
within a wider system.
However, if the justification for a constraint is not clear, it may be worth
challenging, e.g. “The vehicle’s body panels shall be constructed of glass-
reinforced plastic”. There could be all sorts of reasons why this is a good
idea (ease of decoration, light weight, special deal with a local supplier) but
without a rationale (see “Anatomy of a requirement”) you can’t know – so
query it.
42.6 Summary
In this chapter we’ve looked at how needs can be expressed at different lev-
els of detail, why clients do this, and how you can spot it.
Assessing a client’s brief is much more about language analysis than it is
about technical know-how, although you also need domain knowledge to
do a good job of it. This is a skill area that is not traditionally associated
with engineering. It takes practice to become proficient in this skill, but the
71
potential rewards are great – for every awkward question you ask, you may
save yourself, your clients, or your employers significant sums of money.
43 Characterising a problem
If I had an hour to save the world, I would spend 55 minutes thinking

about the problem, and 5 on the solution.
Apocryphal, commonly (unprovably) attributed to Albert Einstein
Arguably, an engineer’s most important skill might be the ability to examine

a real-world situation and judge which abstract principles or mechanisms
are in play. It’s important to recognise not only the structure of the problem
but also the level of complexity and the environment in which decisions must
be made.
43.1 The shape of a problem

Looking at a problem and identifying the structures and dynamics that are
at play is one of the critical parts of problem characterisation. I call this “see-
ing the shape of a problem”; not the geometric shape, necessarily, but an
abstract mental model of the dimensions of the problem’s complexity, and
how different factors need to interact to produce a solution. Let me give you
an example of what I mean. Some time ago, as a junior engineer working on
railway signalling, I was learning with colleagues about the way the European
Train Control System (ETCS) works. ETCS is highly configurable and in one
of its configurations it uses radio communication between the track and the
train to move safety-critical data in both directions (essentially, providing a
feedback loop for the control of the position of the train: the trackside “ra-
dio block centre” (RBC) decides how far the train may travel, and the train
observes this limit and transmits back the current estimated location of the
train).
The problem comes when the train approaches the boundary between two
areas controlled by different trackside units. Since the radio communication
is effectively like a mobile phone call, a train with only one radio communica-
tion unit has to “hang up” on the controller of the area it’s leaving, and then
call the controller of the area it’s approaching. This is why this configuration
is not normally used, and the train has two redundant radio communication
units, so that a call may be established to the next area whilst the call to the
existing control area is still under way.
On learning that the single-radio-unit configuration was valid and possible,
Figure 34: A member
72 of the United States
armed forces travers-
ing monkey bars [17]
Figure 33: Comparing a real-world communication problem with a simple

mechanical analogy
I said, without really thinking about it, “that’s like trying to traverse a set of
monkey bars with only one hand” (see figure 33). To me, it was obvious
that the shape of the problem was the same: a matter of tight timing be-
tween releasing one dependency on infrastructure and establishing a new
one, meaning that the weak point is if there is any failure to establish the
second dependency within sufficient time.
With the monkey bars, the person falls to the ground (hopefully, not too far);
with the train, the on-board safety system stops the train at the last known
movement limit because it has no knowledge of a safe route ahead. This is
safe (for a while) but not very useful for passengers!
This instinctive analogy amused my colleagues, but to me it was quite pro-
found to be able to see the parallels in the two problems. Trying to traverse
a set of monkey bars with only one hand is a pretty demanding feat; why
would you ever choose to do that if you could use both hands? I couldn’t
understand why we would allow a configuration on the train that was so
vulnerable to the possibility of failure if the single radio unit on the train
didn’t perform adequately (bearing in mind that radio communications can
be affected by weather, topography and other uncontrollable factors).
73
43.2 Complexity and decision-making constraints

Two further aspects of a problem’s character are the level of complexity and
the constraints on decision-making (in other words, how long you have to
think about it). The Cynefin12 framework was invented by Dave Snowden in
Figure 35: The Cynefin framework [18]
1999 to illustrate how problems can be categorised along the lines of these
aspects, and what kind of action plan we might want to take to respond to
the different types of problem. Figure 35 illustrates the framework with the
action sequences of each category13 .
12
“Cynefin” (pronounced “kuh-NEV-in”) is Welsh for “habitat”
13
For a more detailed illustration of Cynefin, I recommend the excellent picture on the
website of SketchingManiacs (https://sketchingmaniacs.com/decision-making-1)
74
It’s critical to categorise a problem correctly in the Cynefin framework

before we take action. If we fail to do so (usually by underestimating
complexity), we may follow an action plan that makes the problem
worse.
Cynefin proposes five “domains” or categories in which a problem might fall.
43.2.1 Disorder
The “disorder” area in the centre of figure 35 is the starting point before we
have categorised. It is important to escape this domain because when we are
not sure what kind of problem we are dealing with, we fall back on whatever
approach is our favourite.
You may well begin to observe amongst your colleagues that they do not all
like to work on problems the same way. Some love to deal with things at the
last minute in a sense of, if not panic, extreme urgency. Think of those class-
mates who pulled all-night study sessions in order to complete assignments,
or made up their answers as they went along when they were defending
their thesis.
Others like to take a great deal of time to debate even the simplest decision,
like which brand of toilet paper to buy in the supermarket.
If the solution approach doesn’t fit the problem, we are in trouble - so we
must begin by understanding what kind of problem we are dealing with.
43.2.2 Clear problems

The “clear” area (alternatively “simple” or “obvious”) is the area we feel most
comfortable in. The problem is known, analysed and solved in principle - all
that remains is to carry out best practice when actually doing the work.
A good example of a clear problem is making toast. We don’t have to think
too hard about how we make toast. We just go into the kitchen, get a piece
of bread out, stick it in the toaster and wait until it pops up. We even have
fall-back approaches should the toaster fail, or if we don’t have a toaster.
The action sequence for a clear problem is as follows:
Sense - simple information gathering (I am hungry);
Categorise - decide what I am going to do about it (I will make toast);
Respond - carry out a known solution to the categorised problem (I make
the toast).
75
43.2.3 Complicated problems

“Complicated” problems cannot be solved simply by a one-size-fits-all ap-
proach. However, there will exist good practices that support us in solving
them. Building a house is an example of a complicated problem. There are
many different considerations that we need to be aware of, but good prac-
tice tells us what they are (investigate the ground for the right type of foun-
dation, get planning consent, find out what the needs of the inhabitants are,
plan the work in a particular order that suits the way the house is designed,
and so on).
The action sequence for a complicated problem is as follows:
Sense - gather information about the factors that good practice says we
must consider;
Analyse - carry out good practices to make decisions about how to proceed
based on the incoming information;
Respond - implement a solution that is the result of the analysis we carried
out.
43.2.4 Complex problems Figure 36: A pre-

mature declaration
“Complex” problems are those where it is difficult to know how to analyse of “mission accom-
the factors and when the problem has been adequately solved. Some of the plished” after the first
dynamics may be hidden or unknown. Good practice analysis methods may stage of the Iraq War
fail to yield the answers we want or expect. Governing a society is an ex- When complex
ample of a complex problem. Structures and dynamics exist, but given that problems are
most of them are made up of quite unpredictable human beings, it is prob- miscategorised
ably not possible to predict in every case the consequences of a governance as complicated
change. or simple, we
can mistakenly
We don’t therefore assume we can completely solve a complex problem, but
believe we have
we can try to treat it as best we can. In order to do so, we have to make our
solved them,
methods up as we go along; this is labelled as “emergent practice”. Emer-
only for severe
gent practice has to be based on tentative experiments and trials that yield
consequences to
evidence that an approach might help solve the problem.
appear - some-
The action sequence for a complex problem is as follows: times months or
years later.
Probe - carry out trials, experiments, simulations to try and learn more about
how the environment will respond to a stimulus;
Sense - gather feedback on how the probing action has affected the envi-
ronment;
Respond - implement those solutions that yield or support the results we
are trying to achieve.
76
It is particularly important in this domain that we allow for the possibility

to revert back one or two steps if we find at any time that a solution is not
yielding hoped-for results. Initial results might look more positive than the
long-term results, and this would be a sign that the solution was dealing with
a symptom rather than the root cause of a problem - and therefore, further
probing is needed.
Change is not the enemy in the complex space. Ignorance is the enemy
- and as soon as we learn something new that changes how we want
to solve the problem, we must be prepared to act on this information.
43.2.5 Chaotic problems

Chaotic problems are where we do not want to end up as engineers. You
may hear the phrase “firefighting” used often to describe the way of work-
ing on projects that have gone wrong in some way. There is no longer any
time to probe or analyse; the imperative is to take action immediately based
on nothing more than instinct, because the situation is urgent. Actually, to
Figure 37: First responders taking action after the September 11, 2001 attacks
on New York [19]
compare a chaotic engineering project with firefighting is unfair to firefight-

ers, because, although they follow the same action sequence (act-sense-
respond), the choice of action is not instinctive but rather ingrained in their
training and experience. Emergency services have standard operating pro-
cedures that govern how to act. Crucially, though, standard operating proce-
dures do not provide a complete solution by themselves - they only govern
77
how the individual actions can be carried out. They may also be deviated
from if necessary to save life.
In contrast, engineers do not have standard operating procedures for deliv-
ering work on a chaotic project; we are educated to work in the “complicated”
space - to gather information and analyse before making decisions. Small
wonder, then, that projects in trouble often deteriorate further beyond the
point where they can first be considered chaotic.
The action sequence for a chaotic problem is as follows:
Act - do something immediately based on (best case) training or emergency
procedure or (worst case) instinct;
Sense - gather feedback on whether the action has improved the situation;
Respond - adjust, change or abort the action based on the feedback.
43.3 Summary
Problems are everywhere in our lives - not just at work but in society and our
private lives. The way we should solve the problem is dependent on what
kind of problem it is. The shape of a problem, and the level of complexity,
are insights that will help you select the right way to deal with something.
Now that you’re aware of these ideas, try categorising problems you read
about in the news or see in everyday life, as well as the problems you face
at work. Ask yourself:
• How often are you in a comfortable “clear” or “complicated” space?
• Is the action being taken in line with the category?
• How do you justify the categorisation?
Underestimating complexity (by assuming your problem is clear when

it’s complicated, or complicated when it’s complex) is fatal; as your so-
lution starts to crumble, you run the risk of pushing your problem into
the chaotic space, where you no longer have control. This really hap-
pens in industry, and is something to be avoided.
78
44 Emergent behaviour and properties
The whole is greater than the sum of its parts
Variously attributed axiom
Why, you may well wonder, am I devoting a chapter to a theme that, on the
face of it, is more about philosophy than engineering practice?
The answer is simple: because this phenomenon is something we can ob-
serve as engineers. We need to be aware of it so that we can anticipate risks
and mitigate them.
44.1 Why water is wet

This section is adapted from a presentation by Jon Elphick [37].
44.1.1 Hydrogen as a system

Let’s start with an analogy at the atomic level. We don’t usually engineer at
this level but the principles still hold: namely that we can know all there is to
know about individual parts in isolation, but that knowledge cannot by itself
always predict what will happen when we put the parts together.
Consider a single atom of hydrogen - a single proton orbited by a single elec-
tron (let’s leave quarks etc. out of it). When you begin to consider the physical
properties of this atom, there is little we can learn until we begin to consider
quantities of hydrogen greater than one single atom. We can think about
how we might split this atom and how much it weighs, let’s say.
Add another hydrogen atom and we can begin to think about how hydrogen
behaves in quantity (if you didn’t know, it’s a diatomic element, which means
under most familiar conditions, it likes to go around in pairs, that is, as H2
molecules). This is an emergent property that we can only observe when
we have more than one hydrogen atom - and we can only predict it when
we consider the possibility that one hydrogen atom might meet another.
If we want to understand properties like melting points, boiling points, and
the behaviour of gases, we are going to need more molecules, because we
need to understand how one molecule interacts with another. These are
emergent properties we can only observe when we have more than one hy-
Figure 38: Emergent
drogen molecule. The ideal gas equation P V = nRT is a model of the emer-
properties of hydro-
gent behaviour of a large number of identical gas molecules interacting with gen at progressive
each other under certain conditions. scales
79
44.1.2 Water as a system

Let’s burn our hydrogen in air and produce some water. Again, if we look at
only one water molecule, we cannot say very much about what water is or
what it will do. We need to look at how multiple water molecules interact.
What we find are properties like expansion during freezing (1 kg of ice14 takes
up more space than 1 kg of water because the molecules line up with each
other when the ice crystals form, and this takes up more room than the less
ordered liquid form) and surface tension. Water is wet because individual
water molecules interact with each other and attract each other, clinging to
a surface rather than falling straight off it. Surface tension is an emergent
property of a set of water molecules. This is why water is wet.
44.1.3 Practically everything is a system

The progressive advance of physics has constantly shown us that what we
previously thought of as indivisible items are in fact made up of smaller parts
interacting to produce the effects observed at the level above. Figure 39: Surface ten-
sion as an emergent
Dalton’s model of the atom assumed that it was a single mass; subsequently, property of water
we discovered electron orbits and a nucleus made up of protons and neu-
trons; then, we found that the protons and neutrons themselves were made
up of quarks, and so on, and so on.
To put it another way, a proton is a system of quarks put together in a certain
way so that the behaviour of a proton emerges. An atom is a system of
protons, neutrons, and electrons. A molecule is a system of atoms, and so
on.
When we look at the world this way (and remember, we are engineers -
fundamentally we should be looking at the world through a viewpoint of
physical effects and scientific understanding) we should quickly assume that
everything we can observe is probably a system. The only exception to
this is when we are examining the very lowest-level fundamental particles,
where we can only say that they may be indivisible, but equally, with further
advances in physics, we may determine that they too are systems exhibiting
emergent behaviour generated by even smaller component parts we haven’t
yet discovered.
For our practical purposes, everything is a system.
44.1.4 Why we need to understand emergent behaviour Figure 40: Evolution of

the models of atoms
This deep dive into the way we look at the world is not simply philosophical and fundamental par-
or academic. It’s deeply practical - because there are numerous examples of ticles
14
Regular ice, that is; there are some rarer types of solid water where this is not true
80
emergent behaviour that contradict the intentions of those who designed

systems, sometimes with disastrous consequences. This is sometimes re-
ferred to as “the law of unintended consequences”15 , although no such sci-
entific law exists; it is more of an idiom. As engineers it’s really important
we consider our whole system so that we can anticipate these emergent be-
haviours and ensure that we only get the ones we want, or, at least, we don’t
get the ones that act against our intentions.
The steam engine governor: Steam engine pioneer James Watt adapted
the centrifugal governor for use in regulating the speed of his engines. By
altering the leverage of the governor, its sensitivity can be increased. Watt
reasoned that the higher the sensitivity, the more precise would be the regu-
lation of engine speed. However, he found that, beyond a certain threshold,
the sensitivity became too high and the engine became unstable. The math-
ematics describing dynamic systems were not known at this time, so Watt
was forced to use trial and improvement to optimise the leverage of his gov-
ernor.
The instability of the system was an emergent behaviour of combining the
steam engine and governor in a certain way with certain parameters. It was
not foreseen by the creator of the system because there was simply no sci-
ence to predict it at the time.
Climate change: It is known, from evidence such as ice cores taken from
polar regions, that the Earth’s climate has changed, for hotter or for colder,
many times over its history. The causes of these changes are many and
varied. Climate change is an emergent behaviour of the climate system of
Earth, influenced by the Sun, water levels, human activity, and many other
factors that are so diverse and numerous that it is very hard for humans to
model the expected effects.
Waiting time targets for doctors’ appointments: In the early 2000s, the
UK government set a maximum waiting time of 48 hours for appointments at
doctors’ surgeries. This waiting time could only be measured from the time
the appointment was booked to the time the appointment took place. The
intention of the policy was to ensure that patients would not be kept waiting
an unreasonable amount of time before getting access to a doctor. Perhaps
the government hoped that this target would encourage doctors’ surgeries
to invest in greater capacity and employ more medical practitioners.
However, it was obvious to many doctors’ surgeries that this target could
easily be met if they simply refused to allow patients to book an appoint-
ment more than 48 hours in the future. The surgeries would typically re-
15
See http://en.wikipedia.org/wiki/unintended_consequences
81
quire patients to call at the start of the working day, where they would be
held in a telephone queuing system and would be allocated an appointment
based on the order in which they called and the seriousness (as assessed by
a non-medically-qualified receptionist) of the medical issue.
Since the target’s achievement was only based on the time between an ap-
pointment being agreed and the time it took place, it was easy for surgeries
to achieve the target without expanding their medical capacity, but at the
cost of great inconvenience and some distress to their patients.
The target was scrapped by the new government that took power in 2010,
despite the government that instigated it having been notified in a public
debate16 of its effects as far back as 2005. What is striking about this ex-
change is the astonishment shown by Tony Blair, the then Prime Minister, at
the unintended consequences of his government’s policy.
I could not understand at the time, as a young systems engineer, how it
had not been obvious that this would be the outcome, given human nature.
That a government could be making policy with such disregard for system
dynamics was (and still is) a source of worry for me as a citizen and voter!
44.2 Predicting emergent behaviour

In a purely physical system it is possible to predict emergent behaviour by
building a dynamic model and running scenarios of inputs and disturbances
to see what the system does. This results in quite accurate predictions, pro-
vided that
• We know all the physical laws applying to interactions between parts
of the system
• We have identified all the interacting parts of the system or demon-
strated that the effects of some can be overlooked
This kind of modelling is central to engineering study in many disciplines.
However, purely physical or mathematical modelling has limitations. All phys-
ical laws are models (approximations) of real behaviour, and are therefore
inaccurate to some degree. Not all non-idealities are known or can be quan-
tified. Further, we are rarely called on to deal with a system that is purely
governed by physics.
We develop solutions for our fellow humans to use - which means that we
must also consider how humans interact with our systems (or, to put it an-
16
This was a televised debate[38] between leaders of the three biggest UK political parties
of the time, shortly before the 2005 general election. It is worth watching at https://youtu.
be/nqieLSIKWx0?t=4648. The scenario described by the questioner here is one that I too
experienced and found very difficult to deal with.
82
other way, we must consider a wider system made up of one or more phys-
ical systems and the humans who operate it). We sometimes also need to
consider the interactions between human organisations, each using one or
more physical systems to help them achieve their goals. The ability of math-
ematical models to predict effects at this level is much reduced. Where a
physical system is stochastic (for example weather, or an artificial neural
network), even the behaviour of physical parts of our wider system becomes
hard to predict.
The best we can do is try to identify the components and their interactions,
and predict which of the interactions is likely to dominate the behaviour of
this wider system. In doing so, we can anticipate emergent effects that are
either positive (contribute to our goals) or negative (detract from our goals).
One method for doing this is the causal loop diagram17 . Causal models
work similarly to stock-and-flow models, except that we initially just label
the flows as being a negative or positive influence on the target node. That
is, the flows are causal relationships rather than material flows.
Causal loops are a simpler way to identify dynamic interactions compared to,
say, mathematical modelling of stocks and flows, or classical control system
modelling, but the technique follows similar principles and can be executed
as a simulation18 if you can quantify the interactions enough. It is useful
to approximate in this way because we can introduce to our model some
concepts that might be extremely difficult to quantify, for example the level
of motivation of a workforce. Such concepts can be very influential in the
emergent behaviour of our wider system, but almost impossible to capture
in traditional mathematical models.
Figure 41 illustrates the causal flow for the doctors’ surgery waiting time case
study in section 44.1.4, as it might appear to someone if they consider the
waiting time to simply be the time between agreeing an appointment and ac-
tually attending the appointment. If this is how you understand the problem,
then it follows that to reduce waiting time and increase patient satisfaction,
setting a target maximum waiting time would be a good thing.
However, as the questioners on the television show[38] made clear, the time
between the appointment being made and actually taking place does not
always necessarily need to be as short as possible; what’s more important is
to ensure that people who need to see their GP urgently are able to do so.
The level of medical need was not considered in the causal model of figure
41, nor was the time between that medical need emerging and the booking
17
I first encountered this modelling technique when reading “The fifth discipline” by Peter
Senge [39], which provides a good basic introduction to the technique. The Wikipedia page
on causal loop diagrams is also a nice introduction.
18
There are some tools available for this, or you could code it yourself if you have a math-
ematical modelling suite available.
83
of the appointment, which is important to the patient (they are suffering

during this time) but invisible to the measurement system because until the
patient makes an appointment there is no way to track, centrally, how many
patients need medical attention.
Figure 42 elaborates the earlier model to take some of these factors into
account; following the causal links in this model, it’s easy to see how the
unintended consequences occurred. Medical surgeries imposed a booking
window that reduced the number of available appointments by setting a
hard limit on how far into the future an appointment could happen.
As the surgery’s booking window is shortened, the workload of the surgery
reception increases because all the patients who currently need an appoint-
ment are now forced to call in within a very concentrated time period, to
access a quantity of available appointments that is artificially reduced by
the target. The only way to make more appointments available now is to in-
crease the surgery’s medical capacity by taking on more doctors and build-
ing more examination rooms, but since the target has now been met by the
surgery, there is no incentive to do so.
The result: the time between booking and appointment indeed reduces to
below 48 hours, as planned, but the time between the emergence of a pa-
tient’s need and a booking increases. The time between a patient’s need and
an appointment increases, which decreases patient satisfaction.
I created both these causal loop models to illustrate the principle of thinking
through the system dynamics of a problem. Doubtless they both have limita-
tions and weaknesses, because it’s usually necessary to oversimplify in order
to get any kind of result. There is an important “sweet spot” to reach when
creating these models: just enough detail to identify the major risks of unin-
tended consequences, but not so much detail that it’s impossible to analyse
and to determine which of the causal links has the strongest effects (unless
you are quantifying everything, you have to assess the strengths qualita-
tively, or relatively to each other, using your judgement).
Figure 41: Causal loop model of general practice waiting times, as perhaps
seen by the UK government of the early 2000s
84
Figure 42: Causal loop model of general practice waiting times, taking more
factors into account to indicate why the 48-hour target policy had unin-
tended consequences
44.3 Summary
This was a long section that touched on deeply tangible concepts like a steam
engine governor, as well as very abstract concepts like socio-economic in-
teractions in a healthcare system. The learning outcome I had in mind was
for you to begin to look around you and see how patterns of emergent be-
haviour can be seen in the world you observe. If you are starting to think a
bit more about the dynamics of your workplace, your family, your decision-
making: then you are on the road to becoming a more thorough and thought-
ful engineer.
Keep these points in mind as you open your eyes anew to the world:
• Virtually everything we observe is a system and/or part of a wider sys-
tem;
• Systems can behave in ways that we can’t expect or predict just by look-
ing at their parts in isolation;
• Analysing these emergent behaviours is a very important task for iden-
tifying and dealing with risks in the design of our products, no matter
how simple they may seem;
• System dynamics techniques such as causal loops can be a powerful
tool for understanding emergent behaviour, even in cases where we
cannot create a precise mathematical model.
85
45 Human-centred design
86
PART
Communicating like a better engi- IV

neer
46 Drawing and writing by hand
I was born with a pencil in my hand. I did lots of sketching
Karl Lagerfeld
If you’re anything like me, a major part of your childhood was spent with a
pencil and paper, doodling machines and designs for gadgets, or just sketch-
ing what you saw. I wouldn’t claim that I was born with a pencil in my hand,
but I certainly enjoyed my drawing. Karl Lagerfeld was a fashion designer,
not an engineer - but good engineers should be just as fiercely creative as a
man who led one of the great French fashion houses for over thirty years.
As an adult and a professional engineer there’s a danger that we lose touch
with our immediate sense of creativity, when we’re expected to produce out-
Figure 43: One of
put that is polished, made up of regular shapes, and where little flaws attract
the problems with
the attention of those with an eye for detail. When did you last draw some- computer drawing
thing by hand for your work, not just for fun? tools is that you can
get dragged into
I’ve deliberately chosen to create most of the illustrations in this book by spending a lot of time
hand, because I think it demonstrates an important point. Communication is making sure objects
about making sure that the person receiving the information can understand are perfectly aligned
the concepts more than it is about impressing them with how perfectly- and sized, instead
of focusing on the
presented the message is. content; drawing by
hand frees you to be
As a school pupil, I had neither the best drawing skills nor the best hand-
more creative and less
writing. Now, in the workplace, when we are busy collaborating with white- focused on precision
boards and markers, my colleagues compliment me on the neatness of my
writing and drawing. Since my handwriting and drawing skills are much the
same as they were thirty years ago, albeit a little more practised, I wonder
why my level of skill now stands out where before it was just average.
87
46.1 The “good old days”

Before computers took over the generation of two-dimensional construc-
tion drawings from three-dimensional models entered by humans, the 2-D
drawings were generated exclusively by hand - requiring extensive coordi-
nation and communication to ensure that the 2-D views of an object would
all match the intended 3-D reality, which had to be held in the minds of the
engineers working on the job.
Figure 44: Drawing
Every engineering organisation had a drawing office (not all of them as grand office of the Harland
as the one in figure 44) where the design drawings would be produced. As & Wolff shipyard in
today, the job of “draftsman”19 was a specialised one. Engineers would de- Belfast, Northern
Ireland, early 20th
cide on the design and the draftsmen would draw it. However, engineers
century
were expected to be able to mark up drawings by hand and to sketch their
modifications or additions clearly, so that the draftsmen could incorporate
them formally.
This division of labour still exists today, except that the draftsmen are now
known as CAD20 operators or “caddies” and instead of pencils and protrac-
tors, they operate high-end computers and draw in three dimensions, with
the computers creating the 2-D output.
46.2 Sometimes a hand sketch is enough

Let’s look at a practical example. I adopted a brother-sister pair of cats last
year, but I have a second-floor flat, so they needed the indoor environment
to be stimulating enough to partly make up for them being unable to go
outdoors. I also had an old set of CD shelves sitting empty in the corner
of my living room, since I’ve digitised all my music and stored the CDs else-
where. One day I realised that I could solve both these problems at once if
I dismantled the CD shelves and turned them into a pair of staircases that I
could mount on the stud wall of my living room.
Since I was going to do the work myself, the drawing only needed to be good
enough for me to remind myself where everything was going to go, and what
the dimensions would be. A simple hand sketch was sufficient to get the
basic concepts down and provide a space for deciding dimensions. The 3-D Figure 46: Lovelace the
model was in my head and that was fine, because nobody else needed to cat enjoying her new
climbing wall
know about it.
Figure 45 is my sketch - and it took only a few minutes to create. If I’d tried
to do this with CAD software or even just a sophisticated office drawing tool,
it would probably have taken much longer.
19
This is a gender-neutral term, like “human”
20
Computer-Aided Design
88
Figure 45: My hand-drawn design for adapting an old CD rack into a staircase
for cats
46.3 Neat handwriting pays dividends

It’s clear that we write much less by hand than the pre-computer genera-
tions. Why write out a note to a colleague by hand when I can send them an
e-mail in half the time?
Before computers were on every desk, if a professional wanted to write a
letter to a client, they would either write it out by hand or dictate it to some-
one who would encode the phonemes they heard using “shorthand”. Either
way, it would be for someone else to type the letter out and send it on its
way (“typist” was a specialised job - engineers would not necessarily do their
own typing). In this environment, everyone had to ensure that their writing
was clear enough that others could read it.
These days, that pressure is not really there any more - or is it? Modern busi-
ness management places more emphasis on worker-led decision-making,
ideas gathered through brainstorming workshops, and flexible planning meth-
ods - all of which are often carried out using low-tech media. A classic ex-
ample in figure 47 is a Kanban board created with sticky notes. If all team
89
members are creating ideas for a shared space like this, it’s really important
that everyone can read everyone else’s writing, so it’s worth taking time to
write more neatly!
Figure 47: A Kanban board created with handwritten notes [20]
46.4 Benefits of working on handwriting and drawing

It’s understandable to wonder why you should bother spending effort on this
skill when you could just pick up a computer drawing package and generate
whatever you need in much higher quality.
I might also ask you why some people like to listen to music reproduced
from vinyl disks instead of CDs. The sound reproduction is measurably more
accurate for a CD, but vinyl fans like the difference in sound made by the
imperfections, especially when played back on vintage equipment that adds
its own little distortions to the output.
Hand-drawn sketches with a little fallible humanity can engage your

audience more effectively than a very precise computer-generated di-
agram.
One of the latest trends in drawing tools is a “hand-drawn” mode that ar-
tificially introduces noise into the straight lines and regular boxes the user
inputs. There is definitely an appeal in looking at graphics that are a little bit
more human than perfectly straight lines and perfectly round curves.
Some of my favourite online lectures and presentations are illustrated by a
cartoonist whilst the presenter talks. The output looks fantastic, especially
when, at the end, the camera zooms out and you see a huge rich picture that
90
summarises everything you just heard in an engaging way21 .

Even if I can’t draw as well as these professionals, I do still get really posi-
tive feedback from my colleagues about the drawings I create. It’s a good
way to stand out among your peers (at least, until everyone’s read and been
convinced by this book).
You do not need to be able to draw like a professional cartoonist in or-

der to create useful and impressive drawings for your colleagues. Use
whatever shortcuts you need to in order to get your message across,
but there’s no excuse for not trying!
If I want to draw a couple of boxes linked by a line, I will usually be able to

do that more quickly if I just seize a piece of paper and a pencil. Loading up
a drawing tool is waiting time I don’t want to waste, when my creativity is
fizzing away into space. Then there’s the temptation to get distracted from
the concepts I wanted to draw and instead spend time looking for suitable
pictograms, shapes, colours or (for text) fonts. These latter things have their
place but not when the creative juices are flowing.
Secondly, with a pencil and paper, you are limited only by the size of the
paper (with many tablet/stylus drawing programs, even that is not a limit
any more) and your imagination. You don’t need to fight the tool to search
for just the right icon or symbol or shape you want - you just command your
hand directly. By the way, I am not suggesting engineers limit themselves
to physical pencils and real paper. I have been using stylus-enabled tablet
computers for about ten years and I find them a great way to get my ideas
down quickly, and then use the power of the computer to give me extra
leverage - actions like copying and pasting, deleting bits of a drawing, and so
on - these are all easier with a computer and stylus technology is now good
enough that it’s virtually impossible to tell the difference between a pencil
drawing and something created on a computer.
Instead of the usual typeset bullets, I’ve hand-written my top tips for hand
writing and drawing as an engineer below. Figure 48: A teacher
writing clearly on a
21
Have a look at this lecture by the Royal Society of Arts, Manufactures and Commerce: blackboard so that
https://www.thersa.org/video/animates/2010/04/rsa-animate---drive children can read it
[21]
91
92
47 How to avoid causing “death by Powerpoint”

How often have you sat through a lecture or presentation where you really
couldn’t feel engaged, or didn’t pick up the information properly, because
the Powerpoint22 slides were so poor?
There are countless blog posts, pages, books and opinions on how to write
good slides and how to give good presentations. I recommend you take a
look around and decide for yourself on a style that suits you, based on the
many different options out there. In this section, I’ll pick out several aspects
of my personal style that you might find different from that of other presen-
ters.
47.1 Writing the slides

47.1.1 Pictures, pictures, pictures
This is the most important part of my slide style. I get bored if I have to watch
a presentation that has too many slides with only text and no pictures, so I
expect my audience probably does too. Even if I have a really dry or abstract
subject, I want something on my slides that engages the eye better than yet
another bullet point of text in the same font as the rest of the slides. Take
a look at figure 49: which version do you find more engaging? With abstract
Figure 49: The same information presented on a text-only slide and a slide with pictures
subjects, it’s often useful anyway to include a real-world analogy in order to

help the audience understand (as we saw in chapter III.43, the “shape” of a
problem need not be as abstract as you think). Once you allude to something
22
Other slide deck creation programs are available, but let’s not pretend Powerpoint
doesn’t dominate this market.
93
in the real world, you open up an opportunity to drop a photo or two into
the slide.
Photos are also a great substrate for your own annotations - you can fill a
slide with a relevant photo and then draw or write or label over it the points
you are going to talk about. If you find that your file size gets excessive,
check the resolution of the pictures you’re using. You don’t need to import
all those megapixels if you’re going to shrink the photo down on one slide -
use a photo editing program to reduce the image size, or download a lower-
resolution version.
Health warning
It takes time to search out suitable photos with permission to repro-

duce, save, resample, document the sources etc. I consider it worth
the effort, but you’ll have to decide for yourself whether it’s a priority
in your work environment.
For really abstract subjects, even class diagrams that show the relationships
of concepts by drawing lines between boxes can be more engaging than a
list of bullets (and more effective too). See chapter V.54 for examples of how
this can be done.
Don’t be afraid to draw by hand (see chapter IV.46), if you have a suitable
tablet and stylus (or even if you don’t - with a little filtering, a scanned pencil
and paper drawing looks good enough). Once you’ve practised a little, your
hand drawing should be good enough that you don’t need to spend time
wrestling with computer graphics. Hand drawing is quick and engages your
audience a bit more personally than anonymous text boxes.
Finally, respect copyright! There are plenty of images available online23
that are licensed for you to use, often under the condition that you give a
fair attribution to the author and ensure that people seeing the image know
they also can use it (by linking to the relevant licence). It’s not OK to just
screen grab images and paste them into your presentation without doing
this background work. It takes longer the first time you use an image, but
re-use is pretty easy.
47.1.2 Readability
This may be a repetition of tips you’ve heard elsewhere. Perhaps this is a
good place for me to list all the things people do in their slides that drive me
mad. Either way, I hope you learn at least one new thing.
Text volume - too much text on the slide means the audience are busy
23
For example, Wikimedia Commons (http://commons.wikimedia.org)
94
reading and not listening to you; avoid full sentences, use a large font
and extra slides if you need to;
Text size - should it go without saying? Yes, it should, but apparently it
doesn’t - 24 point is a good default for regular slide text;
Diagrams - always make sure that the text and symbols on diagrams are of
a readable size on your slide - unless you’re about to zoom in to show
the relevant detailed part, but want to give an impression of the whole;
Consistency - just as with a document, ensure you consistently use the
same terms throughout, as well as a consistent graphical theme, colours,
fonts and so on;
Unnecessary decoration - a minimal approach to decoration is my pref-
erence - I want the content to speak for itself; emphasise only where
necessary, keep the background theme basic, and avoid the tempta-
tion to animate each bullet point!
47.1.3 Animation
Powerpoint can be used quite effectively to animate complex concepts, for
example illustrating the progress of a feature through an agile development
workflow. It can be tricky to get it working how you want it, but it is worth
the effort if your audience can understand something easier as they see it
move.
Animating all your bullets is probably something to be avoided; at most, us-
ing the "appear" and "disappear" animations is all you’ll need if you’re trying
to build up a point piece by piece.
Too much animation can interfere with the pace of your presentation, espe-
cially if, as you’re talking, you skip a point or click too fast and get two points
up at once. I find it better to just put the whole slide up and talk through it;
that way, I’m not distracted whilst trying to find the right words.
47.2 Giving the presentation

47.2.1 Structure
I still stick by the structure I learnt as a student for any kind of communi-
cation; this has only been reinforced by further training I’ve had in teaching
others:
Agenda, outline, intro etc. - “tell the audience what you’re going to say”
Body - “say what you’re going to say”
Summary - “tell the audience what you just said”
95
This works nicely for all but the tiniest one-slide presentations and gives you
the chance to fill any gaps if you miss something during your presentation.
It also ends with a nice reminder to your audience in case they want to ask
questions on an earlier part of your presentation.
47.2.2 Speaking
There are plenty of hints around on how to improve your public speaking.
What helps me is to consider myself a performer and to try and speak like
professional speakers such as journalists or voiceover actors.
In fact, weather presenters are a great example because, as is normal for
engineers, they have a limited amount of time to provide some scientific in-
formation at a level that non-scientists can understand. The way they break
down what they say into small chunks, and engage with the screen behind
them rather than stand still in one place, is something I try to emulate.
47.2.3 Interacting with the audience

My training always emphasised setting ground rules at the beginning of the
presentation for how you want to deal with questions. My experience is that
this doesn’t always work. Some audience members just can’t be bothered
to write their questions down in their notebook so that they can ask them at
the end - they want to interrupt your flow and ask straight away.
This can be particularly difficult when you are presenting to an audience that
has seniority over you, because asserting your need to complete what you’re
saying is at odds with their wishes.
I advise a flexible approach here: even if you want questions at the end, it
usually doesn’t work to ignore the question until later - the questioner will
stop listening and just be waiting to get a chance to speak. Equally, if the
interruption turns into a big debate with several people involved, you need
to take control back or you’ll run out of time. I find it’s usually enough to
mention the time constraints - most people will leave the subject alone until
a proper discussion time.
47.3 Summary
There aren’t many absolute rights and wrongs about giving presentations
with slides, and you need to adapt your approach to the subject matter and
audience. However, I feel quite strongly about some of the elements of my
style - I believe they help my audience understand better what I’m trying to
say:
• Take opportunities to illustrate your message with appropriately-attributed
pictures;
96
• Avoid crowding your slides with too much text or unreadable diagrams;
• Structure your presentations with an intro at the start and a summary
at the end;
• Model your speaking style on professionals you see speaking fluently
in the media.
48 Writing better documents

As a professional engineer, you can expect to spend a fair proportion of your
time writing, reading, or reviewing technical documentation. You’ll soon
come to realise that there is little correlation between good engineers and
good writers. I have seen signed-off documents that range in readability
from the excellent to the abysmal, and all points in between. I’d like to share
some simple tips with you that I find very helpful when writing.
48.1 Why it matters

The quality of your documents will influence the impression you make on
your peers and leaders, and (more importantly) the comfort of your readers!
Engineering places great stock in attention to detail. When applied to doc-
uments, this can mean that your audience gets distracted by trivial spelling
and style errors when you really want them to be concentrating on the con-
tent of your work.
Good writing demonstrates your attention to detail and engenders confi-
dence in your audience.
Conversely, poor writing damages confidence. More importantly, it means
you are communicating inefficiently, confusing your readers, and possibly
giving erroneous or superfluous information.
48.2 As always, start with the requirements

Before you download your corporate document template and get stuck in to
typing your masterpiece, I suggest you take a blank piece of paper and work
through two simple exercises.
The first of these is to identify the stakeholders to the document. Who will
use it? Who is reviewing or auditing it? Is it internal, for contractors, or client-
facing? How many different types of user are there? You can use a class dia-
gram (UML) to record this formally if you wish. Once you’re satisfied you’ve
identified your readers, consider what it is that each of them wants or needs
97
Figure 50: A UML/SysML class diagram that describes an example set of

stakeholders interested in an interface specification
to learn from your document. It may be worth taking a few minutes to give
them a call or sit with them to understand what they’re expecting, if you can.
A UML/SysML use case diagram is a great way to record this, because it is
designed to illustrate the relationships between stakeholders and require-
ments. You can also explore how different requirements are related. The
result is a set of objectives your document needs to deliver, from the points
of view of everyone who wants something.
48.3 A logical structure makes the document flow better

Once you’ve explored what your document needs to do, you have the in-
formation you need to define what the contents should be, and develop a
sensible structure.
Your standard templates may provide you with a suggested section struc-
ture, but you should consider carefully if it is fit for the purpose you’ve recorded
before you proceed with using it. I recommend tailoring such structures, or
developing your own, if you feel that is more appropriate than the standard
structure.
Professional engineers are able to judge when to adhere strictly to

guidelines and when to deviate from them in order to better achieve
their goals.
98
Figure 51: A UML/SysML use case diagram that describes an example set of
information needs addressed by an interface specification
If it’s possible to group the use cases you drew, these groups may be a sen-
sible top-level structure for the document. Grouping by the owning stake-
holder means that a particular stakeholder may only need to read the detail
of one section of the document; by structuring the document in this way,
you’re saving them time.
In general, I think it’s good practice to begin with more general information
that sets out the bigger picture, and move on into detail gradually. Those
stakeholders interested in the detail will encounter the bigger picture early
on, which is helpful, while those who need the bigger picture can stop read-
ing at the end of that section.
Try to keep the level of detail consistent within a section. If you need to
attach fine detail, but it doesn’t contribute to the overall flow of a section,
consider putting it in an appendix instead of in the section.
48.4 Identify key information clearly

If you’ve come up with a set of key messages that you want to convey, your
document will be more effective if you ensure that these messages are dis-
tinct from the body of the document.
One visually striking technique is to draw a box around such items (I’ve seen
99
Figure 52: A UML/SysML class diagram that describes an example structure

of an interface specification
this done in requirements documents, where those requirements consid-

ered to be mandatory are boxed). When doing this, you must be consis-
tent in the types of information highlighted – otherwise, your readers might
look at similar statements that are not highlighted and wonder whether you
missed something.
In this book, I’ve chosen this boxed format to highlight the most im-
portant messages I want to get across to you.
Partitioning such messages into specially-labelled subsections, tables, or even

just in a paragraph by themselves, would be a more subtle means of picking
out what you’re trying to convey.
In this book, I’ve chosen this format to highlight important quotations that
support the arguments I make in the text.
The author
100
48.5 Get the spelling and grammar right

It’s simply not acceptable for a professional to allow their deliverables to
contain mistakes in spelling or grammar. If you can’t get these simple things
right, why would you expect your client to trust you to produce highly com-
plex technical designs for them?
At the very minimum, you should always run the spellchecker before sub-
mitting a document. However, spellcheckers and even grammar checkers
don’t always pick up mistakes. Where you use a lot of industry-specific ab-
breviations, a typo swapping two letters around is unlikely to be flagged as
an error.
There really isn’t much of a substitute for the good old Mark I Eyeball. Once
you’ve spent hours or days writing a document, though, you will be so fa-
miliar with the contents that you actually won’t read every word in every
line when proofreading. This is where you are well-advised to ask your col-
leagues to look over your work, and do the same for them in return. A fresh
pair of eyes will pick out those minor errors, giving you a chance to correct
them before you put your work in front of the reviewers.
If you find you’re struggling with particular spellings, or with particular gram-
mar constructs, there’s any number of resources online and offline that you
can use to improve your language skills. I find the Cambridge Dictionaries
website helpful for spelling and grammar tips, and for checking when I’m
unsure of something.
48.6 Use the minimum necessary words to get the mes-

sage across
When you’re knowledgeable or enthusiastic about a subject, it’s easy to be
tempted to write more than is necessary. In engineering, though, the result
is a bulky document that every reader has to wade through in order to find
the bits of information they actually need.
There’s a balance to be struck between providing a reasonable amount of
introduction, background, and explanation, and filling a document with fluff
or waffle. Remember, it’s very rare that there is an expected minimum word
count. Students please note, this applies to your coursework too! I have
marked MSc theses that fill 130 pages with text, without addressing all the
necessary points to get a pass mark. That’s a lot of wasted effort.
The fewer pages you write, the less time you and your audience have
to spend. This is a very real saving of money. Effective communication
is profitable!
101
48.7 Choose effective and punchy presentation style

One way to make your writing easier to read is to consciously use fewer
words per sentence. It is easier to parse multiple statements than one long,
compound statement made up of many parts. Similarly, keeping your para-
graphs short (I recommend no more than three sentences) breaks up the
visual impact of your document and makes it feel as though the reader is
making progress.
Taking this further, you can look for opportunities to break up the text mass
by presenting information in tables, bulleted lists, or diagrams.
I tend to find that these devices, especially diagrams, are very underused
in many documents. Technical document writers sometimes go to great
lengths to describe in text something that could much more easily be ex-
plained using a simple sketch and a couple of comments.
Better still, why not use some views from your system architecture model?
Make things easy for yourself – and your readers. Choose the most
obvious way to convey the message and cut out the verbiage where
you can!
48.8 Summary
There are thousands of online resources around providing advice on how to
write and communicate effectively. I’m not trying to replace all of those, and
I recommend that you look around for different styles and opinions.
Instead, this post sets out a few of the key skills I think will help you to com-
municate more effectively in every document you write. It’s well worth a
couple of hours’ effort to sketch out the diagrams I suggested in order to
straighten out your understanding of what you’re trying to write.
Try to keep in mind these principles the next time you write a document:
• You can only communicate effectively if you understand who your au-
dience is and what they need to know;
• Defining the audience’s needs should come before any decisions on
format, medium, structure, or content;
• Once you understand the needs, look at how they naturally group to-
gether when considering the structure of your document;
• Ensure that your hard work is noticed by ensuring a visually accessible
presentation style, and by eliminating distracting minor errors such as
typos and grammatical mistakes.
102
49 Typical methods for articulating requirements
50 Capturing requirements
51 Anatomy of a requirement
A requirement is a statement of need. Writing good requirement text is a
skill that we’re going to look at it in some detail later. However, a well-written
statement of need is only one aspect of what makes a good requirement.
To aid the design process more fully, we can add some extra information
to the need statement that supports design and testing, as well as making it
easier for the requirements themselves to be managed through the lifecycle.
51.1 A typical requirement with its parts

Table 3 is an example of a well-formed requirement with its supporting infor-
mation. Presenting a requirement in this way is good practice. You should
think of a requirement like an entry in a database – with a unique identi-
fier and a number of fields that need to be populated. It is much easier to
work with the information if it is clearly structured. Achieving this structure
is most easily done by drafting the requirements and their supporting data
into a table, spreadsheet, or a requirements management tool.
Because requirements are often presented in a document, there is a temp-
tation to draft the requirements directly into a word processor. This makes
it very easy to mix up the information, especially if you are including back-
ground information in between requirements. Here’s a quick example, using
the same information as in the table above:
A number of options for engine starting were evaluated by
the customer engagement team but 75% of customers stated
they preferred the familiar key switch method of starting the en-
gine. Therefore, when the driver has inserted the correct ignition
key into the key switch AND WHEN the driver turns the key to
the IGNITION position, the car shall perform function START EN-
GINE. This requirement was ratified by the Engineering Commit-
tee on 23rd December 2015 as recorded in minutes of meeting
AUT/MoM/0034.
Note that the text is the same – but the actual statement of need is buried
between two items of background information that form the rationale. If you
are tasked with extracting the requirements from a document, this makes
more work for you, because you now have to carefully read the whole para-
graph, and then copy and paste only the middle sentence into your require-
103
Unique identifier (UID) REQ.001

Requirement title Car ignition function
Requirement text WHEN the driver has inserted the correct ignition key into the key
switch AND WHEN the driver turns the key to the IGNITION position,
the car shall perform function START ENGINE.
Rationale A number of options for engine starting were evaluated by the cus-
tomer engagement team but 75% of customers stated they pre-
ferred the familiar key switch method of starting the engine. This
requirement was ratified by the Engineering Committee on 23rd De-
cember 2015 as recorded in minutes of meeting AUT/MoM/0034.
Type keywords Mandatory, functional
Verification method Test
Verification criteria
• On turning the correct key in the ignition, the test technician hears
the engine start
• On turning the correct key in the ignition, the test technician ob-
serves the tachometer needle move from 0 to between 750 and
850 rpm
Table 3: Essential parts of a requirement
ment text field.
Put yourself in the place of your audience. Great engineers present

information clearly!
51.2 Defining the types of information to include

When working on a large project, especially one with a systems engineer-
ing team, there is usually a definition of the information a requirement may
contain – perhaps in the system engineering management plan (SEMP) or a
dedicated requirements management plan. On smaller projects and partic-
ularly when working as a client, there may be no such definition.
The information fields presented in this chapter are some of the most commonly-
used, but you should assess the needs of your project and tailor your re-
quirement structure accordingly.
104
51.2.1 Creating unique identifiers for requirements

Unique identifiers (UIDs) are extremely useful for requirements and other
types of information item. Even outside of a database or modelling tool en-
vironment (where UIDs are created by the tool), it is useful to number im-
portant items of information. For example, when reviewing requirements in
a meeting, the UID provides an easy and reliable way for the meeting atten-
dees to refer to each item.
Some tips for UID numbering systems follow. A requirements management
tool will handle most of this for you.
Human-readable: it can be tempting to encode a lot of information in a
numbering system, but this makes it difficult for humans to read - keep
it short and as close to a simple numeric series as possible;
Machine-readable: if you expect that the information will be imported to
a tool, even just a spreadsheet, you may wish to take measures like
making each UID the same length (by padding numbers with zeros as
seen in table 3, for example);
Headroom: whilst it is important to keep the length of a UID short (con-
stantly quoting UIDs that are eight digits long very quickly gets irri-
tating), ensure you have sufficient space to cope with the numbers
of items you expect to be recording: one extra padded zero does no
harm;
Sequencing: don’t panic if you are numbering requirements and realise you
have to add an extra one mid-way through the series. The worst thing
you can do is to revise the numbering of all the items in between – if
that reference is already being used, it will cause confusion. Instead,
create another UID at the end of the series. It doesn’t matter that the
numbers don’t scan sequentially, but it does matter that the numbers
are unique and that a UID stays with that item for its lifecycle.
51.2.2 Requirement titles

Requirement titles are desirable, but not essential. They tend to take a lot of
effort to write, so you should decide whether they are needed.
Titles are useful if your requirements are complex – as can be the case if you
are using a controlled natural language such as EARS [40]. The title should
be a handful of words (aim for around five as a maximum) that says what
the requirement is about. Resist the urge to rephrase or summarise the
requirement – that is what the requirement text is for.
If you only have a few requirements or the requirement text is simple, then
it’s probably better not to bother. You may wish to provide space to enter a
105
title for requirements that need one, but leave it blank for those that don’t.
51.2.3 Rationale
The rationale for a requirement means the reason or justification for its ex-
istence. Rationale is frequently missing from specifications but it has high
value. When managing a large set of requirements from different stakehold-
ers, there may be conflicts. Without a rationale to explain why the require-
ment exists, there is not enough information to make a tradeoff decision.
Going back to the stakeholders to discuss and revise the requirement takes
time and money.
At the user requirement level, rationale can be used to provide background
information provided by a user during an elicitation process (for example,
by including their explanations as noted during a workshop). During design,
rationale allows us to record the history of technical decisions made.
The rationale should include a brief summary of any such background infor-
mation, with references to any related documents, such as minutes of meet-
ings where decisions were made, project communications (such as Technical
Queries and responses).
Rationale may sometimes be mixed in with the text of a requirement, for
example
In order to supply the hospital building services, the power
supply shall be rated at 100 kVA.
This is poor practice because it can confuse the reader and make it harder
to demonstrate compliance.
A good example of rationale is shown in the table at the start of this post –
it explains the decision process behind the requirement and indicates that
it has been agreed on the basis of user input. It demonstrates that this de-
cision is not arbitrary.
51.2.4 Categorising requirements

Adding categories to requirements is helpful when sorting out which sets of
requirements to show to which audience, and for generally managing what
may be a large bulk of information (on a large job, it’s conceivable to be
managing thousands of requirements).
Some common ways to categorise requirements are listed below:
• Mandatory or a preference (or some sliding scale e.g. importance rated
on a scale of 1-5);
106
• Functional or non-functional; the latter are often sub-categorised, for

example
– Performance;
– Safety;
– Environment;
– Constraints;
– Human factors;
– ...
• Originating (i.e. directly from the client) or derived (written during de-
sign).
You should decide what is appropriate to your project and find a way to
record that categorisation. In the example earlier, we used a simple comma-
separated list of keywords. A requirements management tool or spread-
sheet will allow you to set up drop-down menus with custom values, which
may make it easier to search through large data sets.
Don’t spend too much time on categorisation - it’s less important than
other ways to understand how the requirements are related to each
other. A rough system of categorisation is usually enough.
51.2.5 Verification methods and criteria

There are four widely-recognised categorisations for verification methods;
these are inspection, analysis, demonstration and testing. More details on
these in another chapter. We use the term “verification criterion” below,
but these tips are equally applicable to validation criteria, which would be
set at a whole-system level rather than a part or component level. It is rare
that a requirement would need both these criteria – unless there is a lack of
clarity over whether the requirement applies to the whole system or only a
component. Check your system architecture model!
Whatever the method chosen, it is important to define the logical conditions
that the client and supplier agree will show the requirement has been com-
plied with. This leaves no room for argument later if the project atmosphere
deteriorates and one party is looking to make life difficult for the other.
Projects can be delayed for months and years over whether the products
are compliant with requirements. Just as with the text of the requirement, it
pays to leave as little room as possible for misinterpretation of a verification
criterion.
107
State the expected criteria in terms of what you expect to see, measure or
observe. It may be useful to refer back to the Concept of Operations (more
on this in another chapter) where there may be a present-tense description
of how the client wants to operate the system, for example “When the user
operates the power switch, the PC powers up and presents the start screen”
is something that could be found in a ConOps and used directly as a veri-
fication criterion. More technical criteria may involve the measurement of
observable values using specified methods, possibly even industry-standard
tests (for example EMC, where international standards define the tests for
emissions and immunity of equipment for some industries).
51.3 Summary
abc
52 Writing effective text requirements
108
PART
Modelling like a better engineer V

53 Fundamentals of models
From a bright idea in the mind of one individual, through a sketch on a
restaurant napkin or the now-legendary “back of a cigarette packet”, to a
fully-fledged building information model collating the complete 3-D physical
detail of a complex building through its complete lifecycle, I am convinced
of the following:
All engineering is model-based.
In this chapter, I will explain the reasoning behind this sweeping assertion
and, hopefully, convince you that it’s worth spending time understanding
what, how, and how much you need to model in order to support your en-
gineering work. We will start by interpreting some standard definitions.
53.1 Definitions
model a simple description of a system or process that can be used
in calculations or predictions of what might happen [41]
something such as an object, plan, or set of rules that is
used to show what something else is like or how it works[41]
architecture fundamental concepts or properties of a system in its en-
vironment embodied in its elements, relationships, and in
the principles of its design and evolution [22]
architecture work product expressing the architecture of a system from
view the perspective of specific system concerns [22]
architecture work product expressing the conventions for the construc-
viewpoint tion, interpretation and use of architecture views to frame
specific system concerns [22]
concern interest in a system relevant to one or more of its stake-
holders [22]
ISO 42010, the international standard for “architecture description”, gives a
beautifully consistent and systematic set of definitions that help us under-
stand the concepts of architecture modelling. The standard provides a dia-
gram (figure 53) illustrating how these concepts are related to each other (in
109
other words, an architectural model of architectural modelling concepts). It

is a short leap of imagination to add more possible aspects of a system to the
right-hand side of this diagram; aspects of a system other than its architec-
ture that might also be of interest to stakeholders and therefore might also
be worthy of modelling. In other words, we can generalise the right-hand
side of the diagram to that shown in figure 54.
Figure 53: Relationships between concepts in architecture models (redrawn

by the author) [22]
There are a few things we should note about what this “ontology”24 tells us.
• The object of interest is called a system because, depending on the
level of detail you use to examine something, everything is a system -
some naturally-occurring, some artificial;
• Since any model is a representation of one or more characteristics, we
may need more than one model to describe all the characteristics of a
system that we are interested in;
• The concept of stakeholders having concerns about a system is one
that holds true for all kinds of system and all kinds of characteristics,
not just architecture, which is the subject of ISO 42010.
24
A fancy name for a model of how several concepts relate to each other
110
Figure 54: Relationships between modelling concepts, derived from ISO

42010 [22], then generalised to all types of model
A model is created every time someone describes anything to another

person - in other words, models are fundamental to the way engineers
communicate with each other.
53.2 Familiar applications of models

Even for engineers who aren’t familiar with ISO 42010, the concept of a model
that describes the characteristics of a system should be almost second na-
ture. All of the mathematics and physics upon which engineering is based
is a model; the equations we have to learn that describe the behaviour of
springs, inductors, semiconductors, combustion, biochemistry and so many
more - these are all small models with limitations, assumptions and approx-
imations.
Where engineers seem less comfortable is in looking at the rest of the world
outside the lab/workshop with the same modeller’s eye. Everywhere you
look, in nature, society, the workplace, your own body - systems are at work;
systems that can be modelled to a greater or lesser degree of fidelity, and
therefore that can be understood to a greater or lesser degree.
This brings me on to the uses of models. In engineering we rarely build the
first thing that comes to mind; we might, amongst other things, create a
model in order to:
111
• Check we have understood a problem correctly;

• Work through design decisions;
• Overcome complexity by viewing a complex thing from limited view-
points without losing track of the whole;
• Carry out fair evaluations of several options for our solutions;
• Present our proposals to others;
• Share understanding;
• Demonstrate that our solutions can achieve a requirement.
In figure 55 are some examples of well-known types of model. Can you
match them to the applications above? Do they cover any point at all? Do
they cover more than one?
Figure 55: Top left:

wind tunnel model
[23]; top right: en-
gineering drawing
[24]; bottom left: 3-D
CAD/rendering [25];
bottom right: text
description
112
53.3 Benefits and risks of models
Essentially, all models are wrong, but some are useful. However, the
approximate nature of the model must always be borne in mind.
George Box [42]
53.3.1 Consistency and inconsistency

I already mentioned that we might have several concerns about a system,
which might mean we model a system in several different ways in order to
look at the different characteristics that the concerns show an interest in.
Typically on an engineering project, each work product (document, proto-
type, computer file, drawing, printout) contributes to an overall description
of a solution. How likely do you think it is that each of these artefacts (which
can easily number in the thousands, even for comparatively small projects)
is consistent with each other and with the original vision for the whole solu-
tion?
It is very important that each view of a model (or collection of models)

is consistent with the others.
Anyone who plays construction games on their computer will have noticed
that the game will stop you from placing a building in the space envelope of
an existing building, or whatever the game rules specify. Such rules can exist
in real-world engineering tools like computer-aided-design (CAD) packages,
but this does not guarantee that a complex model will have consistency.
On multi-disciplinary engineering teams it might be usual for each team to
have its own “layer” in the same model, and to work on them independently.
If spatial coordination is not enforced, the layers don’t fit when they are
brought together, resulting in pipework going through walls, columns be-
ing outside the corners of the roof, and so on. This really happens - and
leads to costly rework.
53.3.2 The right level of detail

When developing a model, especially of a complex system, it’s easy to lose
sight of the purpose of the model, and this is why it’s so important to under-
stand the stakeholder concerns and keep testing the model against them, so
that when the concerns are addressed, you know you’ve done enough and
can stop.
113
Getting carried away with the level of detail is a constant risk, especially
when modern modelling tools give so much flexibility, precision and accu-
racy. How much is enough? You need to decide this, or make sure you have
a clear instruction.
On the other hand, doing a little modelling might reveal some complexity
that was previously unknown. New concerns might arise from this discov-
ery - meaning new value that needs to be delivered by the model. Ignoring
such complexity is just as risky as spending too much effort modelling minor
details.
The level of detail of a model is critical - too much and you risk “analysis
paralysis”, too little and you risk missing important characteristics that
might lead to problems later.
53.4 Approaches for model-based engineering

In the beginning of this chapter, I asserted that all engineering is model-
based. I hope that you now see that I didn’t necessarily mean by that that
all engineering models are good, consistent, accurate, or demonstrate value
for money. Rather, that all engineering is based on a model, and the quality
of the model (consistency, accuracy, precision, degree to which concerns are
addressed) is a critical driver for the success of any engineering project.
A good engineering project can say the following about its model set:
1. Consistency is maintained between all views (that is, all work products);
2. Stakeholder concerns are understood and work products are config-
ured to address them;
3. The number of different models (for different characteristics) is the
minimum necessary to address all the concerns;
4. The level of detail for each view is set so that complexity is exposed
where necessary and hidden where irrelevant;
5. Views are either inputs to, or outputs from, documented process steps.
53.5 Summary
Engineers use many types of model for many different purposes in their
work. It’s important to realise that all models share some fundamental prin-
ciples, and the fewer models we use on a project, the lower the risk is that we
will have inconsistency. On the other hand, we must ensure that we model
enough characteristics at the right level of detail to address all the concerns
that stakeholders to our work might have.
114
We will look at some more detailed applications of architecture modelling,

which I think is somewhat underused by most engineers, in later chapters
in this part.
115
54 Basics of information modelling
55 Modelling requirements
56 Describing interfaces clearly
57 How to plan a system architecture modelling

activity
58 Modelling languages and frameworks
59 Modelling tools and data environments
60 Modelling the environment around your prod-

uct
One of the most common mistakes made in engineering design is a failure
to take proper notice of the environment in which the product is to be used.
This has resulted in some spectacular failures that make headlines for all the
wrong reasons.
There are at least two very important reasons for an engineer to take the
time to understand the environment around the system25 that is their scope
of supply:
• Understanding the nature of, and constraints on, intended interfaces
from the system to external objects like other systems or users;
• Foreseeing unintended or uncontrollable environmental interactions
that the system might need to be able to cope with.
It’s actually quite straightforward to carry out an exercise to get better un-
derstanding of the environment of your product. It simply requires an ap-
plication of system thinking, some imagination, a little research, and a bit of
time.
60.1 Unintended environmental consequences - Dawlish

Warren and the “Voyager” diesel train
Voyager is the brand name of the British diesel-electric railcar classes 220 and
221, which were introduced to operation in 2000. The fleet was purchased
25
Remember that everything is a system, even if that’s not what your project calls it!
116
for the operation of inter-city services on the British “cross-country” routes

between Scotland, the north-east of England, the Midlands, and the south-
west and south coast of England. Each vehicle is independently powered
by an underfloor Diesel engine and electric transmission26 . As with many
other classes of train, braking can be achieved not only with friction braking
via disks mounted on the wheels, but also by operating the traction motor
in a generating mode, converting the train’s kinetic energy back to electric-
ity. This electricity is then converted to heat by running the current through
“brake resistors”. On the Voyager, the brake resistors are mounted on the
roof of the train.
Figure 56: Railway
The routes served by Voyagers include the railway at Dawlish Warren, in De-
along the sea wall
von, south-west England, which runs along the top of the sea wall on the at Dawlish Warren,
western side of the estuary of the river Exe. This railway forms part of the south-west England
cross-country corridor between the English Midlands and destinations in the [26]
south-west such as Plymouth and Penzance. Because of the railway’s posi-
tion, it is very exposed to the weather. Occasionally, storms can cause waves
to break over the sea wall.
When Voyagers first ran on this route and were exposed to these breaking
waves27 , the brake resistors were inundated with water, and because this
scenario had not been foreseen by the train’s designers (although the Voy-
agers were designed to deal with rain and salt spray, as well as the usual
cleaning of the trains), the control software reacted by shutting the train en-
gines down, leaving the train stranded and requiring rescue.
A control software modification was designed and implemented quickly to
solve the problem, but not before thousands of railway passengers had been
inconvenienced and the reputation of the train operator and the vehicle
manufacturer had been damaged. The problem occurred because the de-
sign team had been unaware of this aspect of the application environment,
although it was foreseeable (the fleet of trains was purchased specifically
for use on a network of service routes that included Dawlish Warren at the
outset).
If a designer is unaware of a particular extreme condition that the product
might face, it’s unreasonable to expect them to make the product robust
to that extreme condition, or to complain about the quality of the product
when there was no corresponding stated requirement for the product to
withstand those conditions. This issue could have been avoided if either the
26
The Diesel engine drives an alternator that generates electricity; this electricity then
powers a traction motor that is linked by a flexible drive to the axles.
27
For an idea of what this looks like, this link is to a local news article about storm
damage to this stretch of line in 2018, and contains a photograph of a Voyager be-
ing hit by breaking waves: https://www.plymouthherald.co.uk/news/plymouth-news/
plymouth-trains-suspended-after-dawlish-1285959
117
purchaser had provided a comprehensive concept of operations, including a

description of the geography over which the train was to run, or if the man-
ufacturer had done its own research. Simply sending a few engineers to
ride the cross-country lines, taking notes and photographs, could have un-
covered this risk well before the embarassment and inconvenience of total
train failure.
60.2 Understanding the environment of your product

Unless your product is completely trivial or very highly isolated, you will need
to go through a creative or imaginative process to identify all the influencing
factors of the environment around it.
To stimulate your imagination, you could try one or more of the following to
help you really get a feel for the environment:
• Visiting the place or places where your system will be deployed;
• Looking at photos, videos or other descriptions of the environment of
your system;
• Reviewing the documentation of existing similar systems, if any.
Try to think about unusual combinations of events and conditions. Is there
some freakish weather that is highly unlikely but could really be a showstop-
per? How unlikely is it, really?28 What about incorrect user inputs? Electro-
magnetic interference? Shock and vibration? Moisture? Chemical exposure?
Radiation? Wildlife?
Not all the interactions you identify will be problematic. The key here is to
assess the risks of everything you identify and target your efforts on those in-
teractions that you think are most likely and/or most severe. You do not have
to make your product super-robust to deal with all possible conditions, but
it is very helpful if your system fails and you can say “we foresaw this risk but
chose not to mitigate it because it was not considered likely enough/severe
enough”.
For example, when questioned about train failures in February 1991, British
Rail’s operations director noted that the infrastructure and vehicles were not
designed to cope with the light, powdery snow currently occurring across
the country - because this type of snow was rare in the UK and therefore it
didn’t make economic sense to equip the infrastructure to deal with it. Un-
fortunately, lazy journalists lampooned this perfectly reasonable technical
28
Flooding events are described in terms of how many years are statistically expected to
go by between an event of a particular strength e.g. 1 in 10 years, 1 in 1000 years; however, in
recent years, the numbers haven’t represented the real frequency of flood events, which is
higher - perhaps because of climate change. 1 in 1000 year floods happen more frequently
than once in a thousand years.
118
explanation - coining the inaccurate headline “British Rail blames the wrong
type of snow”.
One important point to note here: it isn’t sufficient to trust the documenta-
tion and requirements that your customer has passed to you.
The customer is not always equipped or willing to research all the possible
environmental and operational conditions and specify for you which of them
should be dealt with. Use the customer’s documentation as a starting point,
but supplement it with the knowledge of your expert colleagues, interna-
tional standards, comparable systems and your own investigations.
If you can get to the site where your system will be used, then it’s a great
idea to carry out a survey of it and use that input to help you design a better
system. Sometimes you really do have to be there to understand29 .
60.3 The context diagram

I said at the beginning that it’s straightforward to begin understanding the
environment of your product. Now I’ll show you how.
Take a blank drawing area - a sheet of paper, whiteboard, electronic notepad
- whatever.
Draw a box representing your system in the centre.
Identify the interactions your system has with its environment by brainstorm-
ing, and add the external actors to the perimeter of your drawing, labelling
them and drawing lines back to your system.
When you have done this, you have a context diagram describing your sys-
tem’s external interfaces. This is just the start of a more involved process:
now you need to characterise each of these interfaces and find out how crit-
ical it is to your system’s functionality and reliability.
For many systems, the bulk of the requirements and constraints that
govern the way the system should be designed come not from the
basic functionality but from the context in which the system is to op-
erate; in other words, the context dominates the design and must be
thoroughly considered.
Notice that I have included on the context diagram not only those actors
that have a direct physical interface to the toaster, but also (in blue) some
29
Obviously this is not always physically possible - if you’re designing something for under-
water use, or space, or in a toxic chemical environment. Even if that’s not possible, you can
at least try to reconstruct the environment as best you can, and use all available knowledge
to exercise all those weird little possiblities that might trip up your system.
119
Figure 57: A context diagram for a toaster
less obvious interested parties. These are not strictly interfaces but rather
stakeholders (that is, individuals or organisations wiht an interest in the sys-
tem).
It can be interesting and useful to categorise stakeholders according to the
influence they have on the system of interest, and the influence that the
system designers have on the stakeholders. The stakeholders can be placed
around the system of interest in concentric circles that represent these cat-
egories, with the “closest” stakeholders in the inner circle and the “furthest”
stakeholders in the outer. One convention uses three circles around the sys-
tem of interest:
Wider system of interest - immediate surroundings, users, and technical
interfaces to other systems;
Environment - neighbouring organisations and systems-of-systems
Wider environment - the physical world and regulatory environment
This method is a nice link between the more technically-focused theme of
120
interface management and the more commercially-focused theme of stake-

holder management. Where a technical interface exists, there is usually a
stakeholder with whom it is necessary to agree the details of the interface.
So, the existence of an interface implies a stakeholder, but the reverse is not
always true: there are some stakeholders who do not interface directly with
the system, but rather have another kind of interest - like regulators.
If we abstract the contents of the context diagram I created, we get the class
diagram in figure 58. As a minimum, a context diagram should identify exter-
nal actors and the system of interest; the onion-model layering is optional.
Figure 58: Information model of a context diagram
60.4 When to consider context

As with many of the techniques I discuss in this book, context is something
that needs to be considered as early as possible in a system’s lifecycle -
preferably before much detailed work has been done on the design of the
system. Why? Because consideration of the context exposes new needs or
requirements as well as constraints and operating conditions that should in-
fluence the design. The earlier it is done, the less rework will be needed in
system design.
121
An ideal scenario would be to know everything about a system’s context be-

fore designing any of the internals. In reality, an iterative approach such
as agile can allow progress to be made whilst allowing that something new
might be learnt in future that would result in a need to change the system
design.
61 Types of interface
62 Modelling RAM and safety information
122
PART
Behaving like a better engineer VI

63 The basics of sustainable development
Figure 59: The three pillars of sustainable development, related to each

other
Given the way the phrase “sustainable development” is often used in our
industry, you’d be forgiven for thinking that only specialists in environmental
science or corporate social responsibility really need to think about it. In
this post, I want to show you that it’s a much wider issue, and demonstrate
that all your work as an engineer has an effect on the sustainability of our
development, in one way or another.
63.1 What does sustainable development really mean?

“Sustainable development” is a phrase that first became widespread after its
definition in the 1987 UN report “Our common future” [43]. In that report,
sustainable development is defined as
Development that meets the needs and aspirations of the present
without compromising the ability of future generations to meet
their own needs.
123
As engineers, we are the technical driving force behind the world’s develop-
ment, and we do our work to meet the needs of our customers. Any solution
we create has the potential to affect, for better or worse, the ability of future
generations to meet their needs.
Consider – our customer has their own set of needs, but is our cus-
tomer representative of society at large? Does our solution for our
customer actually compromise the needs of another subset of soci-
ety?
If we take that analysis too far, we could quickly conclude that the best thing
to do is nothing at all. That’s just as extreme a position as the situation where
we just press on with our task without considering the wider world at all. We
need to strike a balance: to understand enough about sustainability to be
able to identify the benefits and disadvantages of the solutions we propose,
not only in terms of what the customer said they needed, but in the wider
context of what it means for our world.
63.2 Pillars of sustainability

As the sketch at the beginning of the post indicates, we can model sus-
tainability using several dimensions. There are several variants of the basic
model in the sketch, but they all define three key dimensions of sustainabil-
ity:
• Social
• Environmental
• Economic
In particular, some models break out the “social” aspect into two distinct
parts, the “political” and the “cultural”. These are just different ways of look-
ing at the same aspects, however. I recommend visiting the website of Cir-
cles of Sustainability [44] for more details on the approach where social sus-
tainability is split in two.
For simplicity, we’ll lump “social” together as one dimension for the rest of
this chapter.
Given that these dimensions are observations or effects on the same real
world, we can expect them to interact – where we achieve benefits in one
dimension, we may create disadvantage in another. Let’s look at an example
where we assess (very roughly) the benefits and disadvantages of two energy
solutions:
124
Solution Environment Society Economy

Photovoltaic Energy source is renewable High-tech manufacture cre- Questionable as to whether
power genera- (positive), energy and materi- ates a few highly skilled jobs the cost of energy captured
tion als needed to build, land re- (positive); may create unem- during lifetime is greater or
quired for installation (nega- ployment in legacy energy in- less than the cost of man-
tive). dustries (negative). ufacture and installation
(negative/neutral)
Fossil fuel gen- Non-renewable energy Many jobs created in supply Cheaper than many alter-
eration source, pollution, impact of chain (positive), pollution has natives (positive), finite re-
fuel extraction (negative) public health impact (nega- source means prices must
tive) rise eventually (negative)
Table 4: Comparison of two energy generation methods against the three pillars of sustainability
63.3 Assessing sustainability in a holistic way

The example in the previous section illustrates that a decision that seems
like an open-and-shut case from one point of view may be more complex
when you look at sustainability as a whole. The benefits and disadvantages
also shift depending on how far you look ahead into the future.
A further difficulty is that it’s very hard to measure some of the positive or
negative impacts, especially in the environmental and social areas. Economy
seems easier at first glance, in that we can often put a price on impacts – but
the methods for quantifying and identifying benefits and costs are them-
selves an area for debate, so it’s not correct to assume that putting a mon-
etary value on an effect will lead to a reliable assessment. To look at this in
a bit more detail, I recommend reading Overman’s cost-benefit analysis of
the HS2 high-speed railway project [45]. You’ll notice that there is not a dis-
tinct boundary between economic and social benefits/costs – it all depends
on your point of view as to what should be counted, and what weight each
aspect should have when considered as a whole.
Cost and benefit analysis can be highly subjective, and highly sensitive
to the definition of the parameters to be assessed. Be sceptical if these
parameters and their values are not made clear!
It is possible to put a monetary value on environmental impacts (for exam-

ple, the costs of cleaning up pollution) or on social impacts (e.g. the cost of
providing social security benefits to people made unemployed by a new “de-
velopment”). Again, it’s difficult to identify all the impacts and even more dif-
ficult to put an accurate price on them. Nonetheless, methods do exist and
are being used – one example is the “triple bottom line”[46], an accounting-
based approach to quantifying the impacts across all three pillars.
125
63.4 Practical sustainability

These principles are all very well for heads of corporations, but what is a
regular engineer supposed to do about it?
Despite the difficulties in measuring sustainability, the pillars are becom-
ing more of a mainstream way to look at decision-making, as opposed to a
purely economic viewpoint. We’ll look at each of the areas below in more de-
tail in future chapters, but the subsections below should give you a starting
point. In each case, you may wish to check your organisation’s policies on
these areas to see if anything applies to the work you’re doing. These poli-
cies may support you in encouraging your project to go beyond the client
brief to do the “right thing” for the community or the environment.
63.4.1 Environment
The ISO 14000 series of standards supports organisations in developing sys-
tems for managing their environmental impact. Your organisation may have
an environmental management system (EMS). Artefacts from your EMS may
help to guide you when developing a new solution, to keep your work in line
with your organisation’s environmental policy. For example, when going on
site to carry out a ground survey, you may be required to record signs of
endangered species that would need to be moved before work can begin.
63.4.2 Social responsibility

Similarly, the ISO 26000 standard, which has been available since 2010, de-
fines voluntary guidelines for the social responsibility of organisations.
63.4.3 Economic/financial sustainability

As for economic sustainability, most organisations, whether profit-making
or not, simply can’t continue operating if they fail to ensure that they spend
less than their income. A quick look at your organisation’s latest Annual Re-
port should confirm that economic sustainability is the focus of most organ-
isations, with the balance sheet and profit-and-loss account being the core
way to assess performance. For you as an engineer developing solutions,
you not only need to consider your company’s operating costs but also the
whole-life cost of the product or service you’re developing.
63.5 Conclusion
Sustainability is difficult to assess but has a fairly simple definition, in terms
of the three pillars (albeit with myriad variations on the theme).
Whilst a regular engineer is set up to meet client or user needs, we all need
to be aware that the needs of the world or society as a whole, now and in the
126
future, can be affected by our technical decisions. Our organisations often

develop tools to help us do this, and we’ll look at those in more detail in
future chapters.
64 Common features of codes of conduct

64.1 What have codes of conduct got to do with me?
If you’re a professional engineer, or if you’re studying to become one, you
may be a member of an engineering institution or professional body. Per-
haps you only joined because you need to in order to become Chartered,
or perhaps you’re active in your engineering community. Whatever the rea-
son, did you know that when you signed up to your professional body, you
agreed to abide by its code of conduct? Have you read that document?
A code of conduct is one of the things that marks out a profession from other
types of job. By being a registered professional, we are adopting a common
standard of ethics, so that our customers feel more confident in trusting us
with their business. These rules line up very strongly with national legisla-
tion. That means if you break them, you may also be breaking the law and
risking some serious consequences.
If this is all news to you, don’t worry: as long as you’re honest and open in
your dealings, you’re unlikely to fall seriously foul of most codes of conduct.
A quick Google search suggests it’s very unusual for an engineer to be “struck
off” as a sanction for poor conduct. However, out in the grey areas of the real
world, there are a few situations where even junior engineers may need to
be careful – if only because codes of conduct are designed to help us stay
within the law of the land (i.e. keep us out of prison). We’ll look at a few of
those “what-if” scenarios in a future post. First, let’s break out some of the
most common values in codes of conduct around the world.
64.2 Ethical values in engineering

64.2.1 Honesty and openness
Members who are called upon to give an opinion in their professional

capacity shall, to the best of their ability, give an opinion that is objective
and based upon the best available knowledge and information, and shall
state clearly any limitations or qualifications to such opinion.
IET rules of conduct [47]
127
Without debating the philosophy of the meaning of truth, here are a few
highlights about honesty in engineering:
• When you give your opinion or make a declaration, you’re expected to
be objective, to have considered the issue to the best of your ability,
and to be able to support the claim with evidence;
• You must only lay claim to qualifications, titles or post-nominals to
which you are currently entitled; forget about lying on your CV, no mat-
ter how many other people you think are doing it;
• If you think something’s wrong, you’re duty-bound to say so; provide
fair and constructive feedback to your customer, employer, peers and
employees - this includes warning them of the risks they will be taking
if they do not take your professional advice.
64.2.2 Competence
Engineers shall perform services only in the areas of their competence.
NSPE code of ethics for engineers [48]
You may only carry out work that you are competent to carry out. This
doesn’t mean that you’re not allowed to work under supervision when you’re
learning – as long as the person supervising you is competent.
Competence, in this context doesn’t mean your innate ability to do some-
thing (that is, in this context it is not the opposite of incompetence). It means
something more like the following conditions are met:
• You have any prerequisite qualifications or education AND
• You have been trained adequately in the task by someone already recog-
nised as competent AND
• There is evidence (maybe a certificate) that you have been assessed as
being capable of carrying out the task to the prescribed requirements
When you’re starting out, you may well want to show your employer you’re
willing and keen to try new challenges and solve problems for them. Beware.
Trying to carry out jobs that you’re not competent to do could lead to a range
of very nasty outcomes, mostly for you personally. If something goes wrong,
you could hurt yourself or someone else, cause costly rework, or even end
up in court explaining your actions to a jury.
No employer should ever try to force you to do work you are not competent
to do. Even once you have attained competence, if you feel you need extra
128
skills, knowledge, or training, then you should ask for them – don’t try to
carry on without the support required to do the work properly.
This doesn’t mean you should refuse flat-out to do anything you don’t already
know how to do - it just means you should seek the proper support and supervi-
sion!
64.2.3 Continuing professional development
Members...shall maintain their professional knowledge and are to

maintain a record of continuing professional development.
IMechE code of conduct [49]
It’s simply not enough to study for a qualification at the start of your career,
gather some experience, attain Chartered or PE status (for example) and
then never again bother to learn or keep up to date with current develop-
ments in your field. Just as medical professionals are continually learning
new procedures, treatments and methods, so engineers must keep up-to-
date with developments in research and industrial practice. In fact, to be-
come a Chartered Engineer in the UK, you’ll need to produce evidence that
you have continued to learn since you graduated from education.
Any training provided by your employer may count towards your profes-
sional development, but you should also be aware of other opportunities
to learn as an engineer. Your professional body probably organises dozens
of local and national sessions each year. Have you visited their website re-
cently?
In the UK at least, out-of-work activities such as evening seminars and tech-
nical visits are often labelled with a value of CPD (continuing professional
development) hours that count towards any mandatory quota your profes-
sional body may impose. However, I want to encourage you to think beyond
counting hours to meet a quota. Try going to sessions that aren’t in your
day-job field (it feels less like work that way). Go above and beyond the
minimum requirements to get the maximum value. Here are some of the
potential benefits:
• You might learn a new method or technology that you can apply in your
day job;
• You might meet a potential new employer, mentor, or buddy;
• You might have opportunities to sell your organisation’s goods or ser-
vices.
129
Whether or not you can book your CPD hours as working time will depend
on the activity and your company’s local policy. It’s not usual to expect ev-
ery CPD hour to be paid working time. Remember that you’re not simply
developing in your current job role but building value that will keep paying
you back over your whole career. It’s reasonable that you should make an in-
vestment of your own time towards this goal, just as you did when attending
education.
64.2.4 Safety
Engineers shall hold paramount the safety, health, and welfare of the
public.
We’re going to look in detail later at some particular aspects of engineer-

ing safety, including how to assess and mitigate risks to your colleagues,
your users, and the general public. Your code of conduct isn’t meant to sup-
plant any national or international legislation on safety, but it is meant to re-
mind you that safety is every engineer’s job. Never assume that just because
there’s a safety specialist writing the safety case, that everything’s going to
be fine. Take an active role and think safety throughout the lifecycle of your
products and services.
If you need to understand just how bad things can get when engineering
safety is ignored, try Googling for “Bhopal gas leak” or “Challenger space
shuttle crash”.
If you have concerns about the way your organisation operates, your code
of conduct requires you to act. Gather your evidence (get those facts right
first) and get it in front of someone who can take the right action. Compa-
nies nowadays are starting to implement whistleblowing policies that war-
rant fair treatment, and no retaliation, towards employees who raise these
concerns. In theory at least, you should not be threatened with any sanc-
tions for speaking out. In practice, I wouldn’t count on that – but personally,
I’d rather lose my job and save some lives than keep it and watch as a disas-
ter unfolds. Remember, your professional body is there to back you if you
have to blow the whistle on unsafe practices.
130
64.2.5 Sustainability
We will...practise engineering to foster the health, safety, and wellbeing of

the community and the environment
Engineers Australia code of ethics [50]
No matter what you’re working on, be it wind turbines or the latest V8-powered
SUV, your code of conduct holds you responsible for doing what you can to
safeguard the environment and social wellbeing.
If you work for a large organisation, it may well have policies for all these ar-
eas. You should familiarise yourself with their contents, assess how they
affect how you do your job, and ask yourself whether you think they go
far enough to safeguard sustainability. If you’re at the start of your career,
there’s a lot of years before you retire – what kind of world do you want to
retire into? It’s in your hands to influence it.
64.2.6 Integrity
Engineers...shall conduct themselves honourably, responsibly, ethically,

and lawfully so as to enhance the honour, reputation, and usefulness of
the profession.
Integrity is a term that covers a multitude of diverse issues in engineering.

It’s a mysterious quality that all professionals are supposed to have. I read
it as a list of things you shouldn’t do. In this area in particular, your code of
conduct only steers you towards what you probably must do by law anyway,
especially with raised awareness and new laws [6] in recent times around
bribery and corruption.
• It’s not acceptable to accept money or other inducements in return for
favourable treatment such as awarding contracts or special prices (this
is bribery; it’s illegal in most countries!);
• Generally, you’re supposed to only accept paid work from your em-
ployer, although they might consent to you accepting other work. Em-
ployment contracts often stipulate this anyway, although, depending
on local laws, that doesn’t mean it’s necessarily enforceable;
• Don’t sign off unless you believe something’s right; you may be under
pressure from deadlines, managers and workers keen to get on with
131
the job, but you must not bow to that pressure if the work is not correct;
• Be impartial in your assessments and your treatment of other individ-
uals and organisations; your judgements must be evidence-based;
• You must protect any confidential information you hold on behalf of
your employer or clients; when moving from one company to another,
you are expected to leave behind any work you’ve done - if you need an
artefact to include in your CPD portfolio, make sure you ask permission
first;
• If you have a conflict of interest, you must be open about it; for exam-
ple, as an engineering consultant, it would be unlikely to be acceptable
for you to provide your services to two companies who are in compe-
tition to win the same contract from a client;
The value of integrity is probably the hardest to maintain in day-to-day work,
especially when deadlines are tight and the pressure is high. There are grey
areas in these rules and it’s difficult to know what choice to make; even
harder when your seniors and peers are doing something routinely that you
may not feel comfortable with.
Organisations often set rules around corruption that make some provision
for suppliers to engage socially with clients to build a relationship. For ex-
ample, it may be acceptable for you to accept a drink in the bar, or a meal,
from a supplier in return for their opportunity to ask you about your require-
ments and for them to try to sell their product. But you should be starting
to ask questions if they offer you obviously expensive gifts such as watches
or foreign trips. If you’re in doubt, speak to your colleagues, managers and
mentor or, if none of them can satisfy your worries, your professional body,
who often provide free legal advice.
64.3 Conclusions
Whether or not you’re a member of an engineering institution, the rules of
conduct specified by these institutions are there to help you comply with the
law and achieve a level of respectability that is very valuable to have. Follow-
ing these rules should give you a personal feeling of pride and satisfaction.
You should be familiar with your code of conduct and take every step nec-
essary to not just abide by the letter of it, but the spirit. If you have concerns
about what’s going on in your organisation, speak out to your peers, man-
agers and mentor, or your institution. Whistle-blowing is still risky but more
and more support is emerging for those who raise concerns in that way, not
only within companies but in legislation and in institutional support.
132
65 Why safety is always your job
There was compelling evidence that the external walls of the building
failed to comply with Requirement B4(1) of Schedule 1 to the Building
Regulations 2010, in that they did not adequately resist the spread of fire
having regard to the height, use and position of the building. On the
contrary, they actively promoted it. It will be necessary in Phase 2 to
examine why those who were responsible for the design of the
refurbishment considered that the tower would meet that essential
requirement.”
Extract from the phase 1 inquiry report into the fire at Grenfell Tower [51]
In this chapter, I want to make you aware of why and how you should con-
Figure 60: Grenfell
sider safety in your engineering work. Even if you’re not a safety specialist, I Tower burning, June
hope you’ll be persuaded by the end of this chapter to be pro-active in man- 2017 [27]
aging the safety of your designs and products.
65.1 But there’s a safety specialist in my company!

When working in large organisations, we often find that there are specialists
covering every facet of engineering work - from human factors through to
product line reusability. I mentioned in chapter 19 that there can be a danger
of these specialists having insufficient influence over the design to ensure
that the concerns of their speciality are properly met.
Sometimes, the costs of these oversights are hidden (for example, it’s un-
likely that someone is counting the number of days taken off sick by an of-
fice worker and linking it up with the poor design of their workstation). At
other times, though, the costs are all too obvious. When the safety of a de-
sign is compromised and an unsafe event occurs, the consequences can be
disastrous.
65.2 What’s it to me?

If you’re responsible for a design that causes harm to people30 , you are kid-
ding yourself if you think your conscience would be clear simply because you
know that a safety specialist approved your design. Whilst the term "corpo-
rate manslaughter" has been mentioned in connection with the disaster, you
30
Working in the defence industry is an interesting case; on the one hand, weapons are
clearly designed with the express purpose of causing harm to humans; on the other hand,
you may believe that these weapons will be used against forces threatening to destroy hu-
man lives. It would be a good idea to square this with your conscience before you get too
committed.
133
should be aware that, in the UK at least, there is also a crime called "gross
negligence manslaughter" which, unlike the corporate version, can be ap-
plied to individuals. This means that if you are found responsible for an un-
safe piece of engineering, you could find yourself facing a prison sentence.
It wouldn’t be the company directors in the dock, it would be you.
Figure 61: Challenger

65.3 Aren’t we doing this already? space shuttle explo-
It should be obvious that every engineer needs to take an active role in en- sion, 1986 (public
domain image)
suring the safety of anything they design, but I have seen first-hand just how In 1986 the Challenger
difficult it can be to keep safety on the agenda in a meaningful way. Worse, space shuttle ex-
throughout my thirteen years in the industry, I have witnessed a great deal ploded shortly after
of effort being poured into safety analysis and assessment, but to little or no lift-off. This disaster
benefit because of the disorganised way in which it was done. was seen live on
television around
the world. The crew
As an engineer it’s your job to create solutions to problems. The prob- of the shuttle were
lem isn’t solved until it’s solved safely. killed. The issue that
caused the explosion
was known about
In fact, when we consider all the other aspects of quality, such as security, before the launch, but
environmental impact and so on, the same principle applies. engineers’ concerns
had been overruled.
You can read more
65.4 Use your safety expert wisely about this on NASA’s
website:
What, then, is the purpose of a safety expert? I think they should be seen as https://www.nasa.
consultants, analysts, and advisors, rather than being the person expected gov/centers/
to lead the safety effort. If safety is driven by the engineering team as a mat- langley/news/
researchernews/
ter of culture, then the safety expert is free to spend more of their time doing
rn_Colloquium1012.
the detailed analysis and evaluation that only they can do. If, on the other html
hand, they have to spend a lot of time badgering reluctant and uninformed
engineers to look at safety, because it is not incorporated in the project plan,
then they will have less time to spot things that might be important.
65.5 Speaking the language of safety

There’s definitely a problem here: in our university education and our early
training, engineers (in the UK at least) rarely pick up the language of safety.
I have attended HAZID (hazard identification) sessions where senior engi-
neers of 20-30 years’ experience clearly did not understand the meaning of
basic safety terminology. I have picked up hazard logs full of confusing and
repeated information because the engineers who recorded them did not
understand what they were doing.
One of the difficulties is that not everyone agrees on the definition of com-
mon terms such as “hazard”, “risk”, “consequence”, “cause” etc. They may
134
vary from project to project or between different experts.
65.6 Some key points to remember

• You might be individually accountable for the safety of the products
you work on;
• Always ask yourself if you could defend your design decisions in a crim-
inal or civil court;
• Knowing that someone else approved your design will not help you
sleep at night if the work you do is involved in an accident;
• Safety experts are supposed to be there to assist in safety approval,
not drag the engineering team along – so take the lead in safety and
use your expert as a resource;
• Learn the language of safety – and if the definitions are unclear, resolve
it, don’t leave it to others.
66 Safety through the lifecycle
67 Common features of safety legislation
68 Defining a system for safety assessment
69 Hazard identification (HAZID and HAZOP)
70 Reporting safety evidence
71 Working with environmental management sys-

tems
71.1 What is an EMS?
An environmental management system (EMS) is a collection of people, pro-
cesses, and tools that is intended to manage the environmental risks in-
volved with an organisation’s continued operation. The international stan-
dard ISO 14001 provides a framework for EMSs. Organisations that develop
an EMS compliant with these requirements can attain certification, which
may be a selling point with clients. According to the ISO website [52], there
are over 300,000 organisations worldwide with ISO 14001 certification.
135
Figure 62: A summary of the main activities defined in ISO 14001 [28]
Like other similar management systems, the 14001 EMS is structured as a

Plan-Do-Check-Act lifecycle.
71.2 Why do organisations need an EMS?

Understanding the relationship between environmental sustainability and
general sustainability is important when operating an EMS.
If your organisation prioritises the EMS with no consideration for the in-
crease in costs, then it could go out of business. If, on the other hand, it
prioritises cost-cutting with no consideration for environmental impact, it
could end up non-compliant with legislation, or face a clean-up bill for any
environmental impacts it causes.
As an example of the scale of economic damage an organisation can face, in
the aftermath of the Deepwater Horizon oil rig incident, the oil company paid
USD20.8 billion to the United States government (according to The Guardian
[53]) and faced a further class action for compensation by a group from Mex-
ico as of December 2015.
136
71.3 What does an EMS mean to the average engineer?

Taking a look through the activities in the sketch at the top of this post, you
may be forgiven for thinking, at face value, that this is mostly the domain of
an environmental specialist. However, most of these activities have a direct
impact on the way your organisation does its work.
71.4 Planning the EMS

Whilst environmental policy and the scope of an EMS are likely to be defined
at the top level of your organisation, the people who are responsible for set-
ting up the EMS would be negligent if they didn’t familiarise themselves with
the day-to-day operations of the organisation before setting up a system for
managing environmental impact.
You could therefore be asked to
• Help identify the environmental impacts (referred to by the standard
as “aspects”) of your work;
• Determine or review procedures for managing those impacts;
• Work to meet objectives or targets.
71.5 Operating the EMS

As an operational member of your organisation, your day-to-day work is
likely to be influenced by your organisation’s environmental management
system. Here are some simple examples:
• When on site, supervising works that create dust, you may have to en-
sure that the workers involved in that activity damp down their work
site to reduce the drifting of dust to neighbouring areas;
• In a manufacturing environment, you could be tasked to investigate
ways of reducing material waste by improving efficiency of processes;
• In the office, you could be responsible for reducing paper use by re-
defining the design workflow with a lessened need for printing.
Much of the time, these measures not only manage an environmental im-
pact but also improve your organisation’s reputation, which contributes to-
wards economic sustainability, as we discussed in a previous post.
Most importantly, you may need to get expert assistance to assess your tech-
nical proposals for their environmental impacts. This may result in new re-
quirements, arising not from the client but from your environmental spe-
cialist, in order to mitigate those impacts. These should be incorporated in
the design at the outset.
137
71.6 Checking the EMS

There are two parts to this area of an EMS. The first is the measurement of
the organisation’s environmental performance; the second is the continuous
improvement of the EMS itself.
Within your project or work package, you may find yourself:
• Analysing or measuring the environmental performance of your solu-
tions, services, team, or activities
• Reporting to auditors on your day-to-day activities so that they can
check you’re following the EMS
Working with auditors can feel a little like being put on trial. Remember that
their purpose is to improve the organisation, so it should be in everyone’s
interests to honestly explain if something isn’t going quite right. A problem
can’t be solved if nobody knows about it.
71.7 Improving the EMS

For the most part, the Act part of the cycle is about improving the EMS based
on any outcomes of audits, performance measurements, or other assess-
ments. Where you may come in, as a regular engineer, is in the develop-
ment and execution of corrective actions. These could be adjustments to
your existing work instructions, or they could be a bigger change.
For example, if your factory site’s chimney stack becomes non-compliant fol-
lowing a change to emissions legislation, you could find there’s a preventa-
tive action (that is, an action determined to prevent your organisation from
becoming non-compliant) to install new filtration equipment in the stack.
You could also find yourself asked to give feedback on the effectiveness of
the EMS within your organisation. If you aren’t even aware there is one, it’s a
sign that your organisation may need to do more to communicate the EMS,
which is part of the “do” sector of the cycle.
71.8 Conclusions
An EMS could be a standalone system or just one part of a larger business
management system that addresses other aspects of sustainability.
138
• As an engineer, your work probably has an environmental impact

of some kind;
• Your EMS is there to support you in managing that impact so that
the environment is cared for;
• Consider how the procedures and impacts identified in the EMS
might impact your day job;
• Be prepared to answer audits on your activities with respect to an
EMS, and to propose improvements.
72 Personal conduct case studies
73 Corruption and bribery legislation
74 Cultural sensitivity
75 Dressing for the workplace

In this section, I want to share some thoughts with you that you might wish
to take into account when deciding how to dress for your workplace. As with
many personal choices, our decisions have effects on others than ourselves.
That doesn’t mean we should necessarily sacrifice our own needs to satisfy
others’, but I believe it does mean we could benefit from taking a moment
to think about what those needs might be.
The core message of this section is that deciding what to wear is a balance
between your own needs and those of others in your work environment.
Society has some very toxic ways to police what people wear, often focused
on particular identities such as the sex, race or social class of the wearer. This
section isn’t intended to replicate those mechanisms, but to try and give a
positive light to considering an optimal choice of clothing for work.
75.1 A brief analysis of requirements for a work outfit

As with any problem, a good solution meets a range of requirements so it’s
helpful to start by thinking about what those requirements might be.
For a moment, let’s consider that the only person who matters is the wearer
of the clothes. I think we can safely assert that the wearer generally needs
the following:
• To express themself - their personality, identity, taste or interests
139
• To feel good about themself - to have self-confidence and consider that

they look good in what they are wearing
• To work efficiently in the workplace - let’s assume everyone cares about
doing a good and efficient job (if you don’t, you’re probably not reading
this section anyway)
• To feel physically comfortable - not too hot or cold, staying dry if it’s
wet, not too tight or itchy
• To stay safe in the workplace and on the commute - avoiding accidents
and damage to health
Now, let’s add in the colleagues and customers to our consideration. What
we wear has an effect on them, so we should take a moment to think about
what they need:
• To work efficiently in the workplace - this means being able to focus on
work without getting too distracted, and carry out tasks without being
obstructed by inappropriate workwear
• To have confidence in the wearer - given the wide range of insecurities
and prejudices that “everyone else” has, to still be able to respect the
wearer’s work contributions, take them seriously, and believe in the
quality of their work
• To feel good about themself
We can note immediately that two out of the three points here are shared
with the individual wearer of the clothes: the need to work efficiently, and
the need to feel good about oneself. These points should be triggering ques-
tions or warnings in your mind. How are you, the wearer, supposed to know
what will or will not distract your coworkers? How can you predict the way
your clothes will invoke prejudices or insecurities in others? And above all,
how far should you compromise your own needs to meet what you think
others need? Finally, if you work for an organisation, especially a large
one, it’s likely there is some kind of corporate identity which may or may
not encompass the appearance of a worker. The most obvious example is a
uniform. If you choose to work for an organisation that has a uniform, you
have to accept that your own individual self-expression will be quite limited
- especially in organisations like the military, where uniformity itself is part Figure 63: British Army
of the corporate identity. guards on parade[29]
75.2 Working efficiently

From the wearer’s point of view, working efficiently means getting the job at
hand done with the lowest practical use of energy. From the point of view
140
of colleagues, working efficiently means getting the job done without being
distracted or hindered by what someone else in the team is wearing.
75.2.1 Energy use

The idea of getting a job done with minimal energy use is elegant and at-
tractive to most engineers. There can be situations or workplaces where
our choice of clothing can actually make the work physically harder.
If we are doing manual labour or if we need to do a lot of physical move-
ment (say, performing an inspection on a plant - climbing ladders, crawling
through hatches, or just a lot of lifting and carrying) then we probably want
to be in loose-fitting, hard-wearing clothes that give us plenty of freedom of
movement.
A pencil skirt and stockings or a tailored Savile Row three-piece suit are
hardly appropriate choices for that physical environment - even if we miracu-
lously avoid ruining the clothes, they restrict our movement, requiring more
energy to perform the same task than someone wearing a T-shirt and cargo
pants.
Not all engineers do manual work, but lifting and carrying, fetching items
from shelves and cupboards, and reaching across surfaces are all things that
can happen in an office environment. It might be worth selecting something
that gives freedom of movement even in that environment.
75.2.2 Distraction
Perhaps the most obvious example of someone’s clothing being distracting
is if the observer is attracted to people like the wearer and the choice of
clothing makes the wearer’s body more visible or enhances its looks. In case
anyone is wondering, I think this could equally apply across all sexes and
genders - I am not suggesting that this is something that only happens one
way around in the workplace.
Beyond this, though, we could find ourselves distracted by another’s clothing
if:
• The clothing doesn’t fit well;
• The clothing is dirty or damaged;
• The clothing has a very distinct colour or style that stands out among
the workforce;
• The clothing is being worn by someone for whom (according to the
perceived identity of the wearer and the prejudice of the observer) it
is not intended or “permitted”;
141
• Corollary to being attracted to the wearer, if the observer finds the

wearer’s clothing looks bad, they may also be distracted;
• The clothing displays a controversial or divisive slogan or statement.
The wearer can, of course, reasonably expect that an observer exercises
some self-control in overcoming their distraction. If a co-worker comes to
the office wearing something that distracts attention for any reason, it’s on
us to concentrate back on work.
However, we can also look at this from the other point of view: if we know
or suspect that a particular clothing choice is likely to cause a lot of distrac-
tion, is that something we want to consciously choose, knowing the likely
consequences?
Let’s be clear that we have to separate distraction due to what someone
wears from distraction due to how someone’s body looks. The latter is not
something that can be affected by clothing choices, unless one chooses de-
liberately to wear clothing that hides or disguises a physical feature that at-
tracts attention. When we get to this end of the spectrum we are likely to fail
to meet some of the other needs we identified.
It is a hard tradeoff to make between self-expression and a wish to avoid
standing out unduly or distracting others. There is no single right answer,
in my opinion. Everyone must think for themselves and consider the factors
mentioned.
75.3 Physical comfort and safety

I wish I didn’t have to write anything here, but I have seen people wearing
clothing at work that actually poses a risk to their health and safety. I’ve also
worn uncomfortable clothing myself, out of a need to conform to a dress
code.
The degree to which a wearer can prioritise their comfort over conformance
to dress codes is highly variable. Sometimes, comfort comes with better Figure 64: High-heeled
shoes[54]
health and safety consequences; sometimes, it conflicts. For example, steel-
capped boots don’t often fit my feet as well as my other boots, but if I need
to wear them because of the environment I’m in, I don’t have a lot of choice
if I want to keep my job. Here, safety comes before comfort.
Another example: I can only imagine how it would feel to wear stiletto heels
to the office, but I’m almost certain it would be less comfortable than my
worn-in walking boots, and it is well-established in medical literature that Figure 65: Safety
high-heeled shoes do damage to the wearers over the long term. Here, the footwear with
metatarsal guards[55]
comfortable option is also the safer/more healthy, but that would need to
142
be traded against factors such as self-confidence and self-image31 .
75.4 Conclusions
Nobody who lives in a society with other people has unlimited rights to do
whatever they like. The degree to which self-expression needs to be limited
by the needs of others around you will be very dependent on your circum-
stances. Striking the “right” balance is up to you.
There are some who will argue that nobody should be restricted in what
they can wear to the workplace. It’s true that older, more biased norms are
gradually giving way to more modern outlooks, but unless you work on your
own in an entirely danger-free environment, you’ll also need to consider your
safety and comfort as well as the needs of your colleagues when you decide
what to wear.
31
and possibly against dress codes, although the author hopes that workplace dress
codes that impose stiletto heels are vanishing rapidly from the world
143
References
[1] Nachoman-au. https://commons.
“Dampier, Western Australia iron ore stockyard.”
wikimedia.org/wiki/File:Dampier_Iron_Ore,_Western_Australia.jpg, 2005. Accessed:
2023-07-05; licenced under Creative Commons Attribution Share-Alike 3.0 Unported licence,
see https://creativecommons.org/licenses/by-sa/3.0/deed.en.
[2] Uddeholms AB. “Casting of tool steel ingots at Uddeholms AB, Hagfors, Sweden.” https://
commons.wikimedia.org/wiki/File:Ingot_Casting.jpg, 2011. Accessed: 2023-07-05; public
domain image.
[3] United States of America Department of Defense. “Bolt pointing machine in plant of Republic
Iron & Steel Company, Muncie, Indiana.” https://commons.wikimedia.org/wiki/File:
Industries_of_War_-_Metals_-_Steel_-_Republic_Steel_Company_-_Bolt_Pointing_
Machine_in_plant_of_Republic_Iron_%26_Steel_Company,_Muncie,_Indiana_doing_
war_work_-_NARA_-_45487724.jpg, 1918. Accessed: 2023-07-05; public domain image.
[4] Ślusarczyk, M. “Car factory production line. Opel Astra J manufactured in General Motors
manufacturing plant in Gliwice, Poland.” https://commons.wikimedia.org/wiki/File:002_
Production_line_-_car_assembly_line_in_General_Motors_Manufacturing_Poland_-_
Gliwice,_Poland.jpg, 2015. Accessed: 2023-07-13; licenced under Creative Commons
Attribution 3.0 Unported, see https://creativecommons.org/licenses/by/3.0/deed.en.
[5] SSYoung. “Sorted waste containers in Shanghai.” https://commons.wikimedia.org/
wiki/File:Sorted_waste_containers_in_Shanghai.jpg, 2019. Accessed: 2023-07-13; li-
cenced under Creative Commons Attribution-Share Alike 4.0 International, see https://
creativecommons.org/licenses/by-sa/4.0/deed.en.
[6] Hans Hillewaert. “Wind turbines on the Thornton Bank, off the coast of Belgium.” https:
//commons.wikimedia.org/wiki/File:Windmills_D1-D4_(Thornton_Bank).jpg, 2008. Ac-
cessed: 2023-07-13; licenced under Creative Commons Attribution-Share Alike 4.0 Interna-
tional, see https://creativecommons.org/licenses/by-sa/4.0/.
[7] National Aeronautics & Space Administration (USA). “Telstar communications satellite.”
https://commons.wikimedia.org/wiki/File:Telstar.jpg, 1962. Accessed: 2023-07-13;
public domain image.
[8] Danishdanmomin. “Qualityors.jpg.” https://commons.wikimedia.org/wiki/Category:
Inspectors_at_work#/media/File:QualityORS.jpg, 2013. Accessed 2022-06-11; licensed
under Creative Commons Attribution-Share Alike 4.0 International licence (https://
creativecommons.org/licenses/by-sa/4.0/deed.en).
[9] C/S2ESC - Software and Systems Engineering Standards Committee. IEEE Guide for Information
Technology - System Definition - Concept of Operations (ConOps) Document. IEEE, 1998.
[10] ISO/IEC Joint technical committee 1/SC 7. ISO 29148 Systems and software engineering - Lifecycle
processes - Requirements engineering. International Standards Organisation, 2018.
[11] Steve Jurvetson. “Tesla Robot Dance.” https://commons.wikimedia.org/wiki/File:Tesla_
Robot_Dance_(7408451314).jpg, 2012. Accessed 2023-01-29; licensed under Creative Com-
mons Attribution 2.0 Generic (https://creativecommons.org/licenses/by/2.0/deed.en).
144
[12] Geof Sheppard. “Creech St Michael - HOPS DR76922.” https://commons.wikimedia.
org/wiki/File:Creech_St_Michael_-_HOPS_DR76922.JPG, 2016. Accessed 2022-12-20; li-
censed under Creative Commons Attribution-Share Alike 4.0 International (https://
creativecommons.org/licenses/by-sa/4.0/deed.en).
[13] Miroslav Volek. “Rail milling train SchweerBau, Červenka - Moravičany.” https:
//commons.wikimedia.org/wiki/File:18.07.2015,_Rail_milling_train_SchweerBau,
_%C4%8Cervenka_-_Moravi%C4%8Dany_(22195917715).jpg, 2015. Accessed 2023-01-29; li-
censed under Creative Commons Attribution 2.0 Generic (https://creativecommons.org/
licenses/by/2.0/deed.en).
[14] Simon Ledingham. “Sellafield aerial view in 2005.” https://commons.wikimedia.org/wiki/
Category:Sellafield#/media/File:Aerial_view_Sellafield,_Cumbria_-_geograph.
org.uk_-_50827.jpg, 2005. Accessed 2022-12-23; licensed under Creative Commons
Attribution-Share Alike 2.0 International (https://creativecommons.org/licenses/by-sa/
2.0).
[15] oxyman. “London ambulance on Hamilton Terrace.” https://commons.wikimedia.
org/wiki/File:London_Ambulance_on_Hamilton_Terrace.jpg, 2007. Accessed: 2022-06-
06; licenced under Creative Commons Attribution Share-Alike 3.0 licence, see https://
[16] ISO/IEC Joint Technical Committee 1. ISO/IEC/IEEE 15288 Systems and software engineering –
System life cycle processes. International Standards Organisation, 2015.
[17] USA Department of Defense. American Forces Information Service. Defense Visual In-
formation Center. “US Air Force (USAF) STAFF Sergeant (SSGT) Kaluha Crow swings
through the monkey bars during the obstacle course portion of Tiger Challenge 2004.”
https://commons.wikimedia.org/wiki/File:US_Air_Force_(USAF)_STAFF_Sergeant_
(SSGT)_Kaluha_Crow,_Tactical_Air_Control_and_Command_(TACC)_Technician,_607th_
Air_Support_Operations_Squadron_(ASOS),_Camp_Red_Cloud,_Korea_(ROK),_-_DPLA_-_
a9753e37fa88e09426eebf56082b3a0e.jpeg, 2004. Accessed 2022-06-12; public domain image
in the USA, reproduced here with attribution.
[18] Snowden, D.J. and Boone, M.E. “A leader’s framework for decision-making.” Har-
vard Business Review, 2007. Accessed online 2022-06-12, URL: https://hbr.org/2007/11/
a-leaders-framework-for-decision-making.
[19] Courtesy of the Prints and Photographs Division. Library of Congress. “Unattributed pho-
tographs showing the aftermath of the terrorist attacks on New York, September 11, 2001.”
http://lcweb.loc.gov/rr/print/res/297_unat.html, 2001. Accessed 2022-06-12.
[20] Jeff.Iasovski. “A Scrum board suggesting to use Kanban.” https://commons.wikimedia.org/
wiki/File:Simple-kanban-board-.jpg, 2011. Accessed 2022-08-14; licensed under Creative
Commons Attribution-Share Alike 3.0 International licence (https://creativecommons.org/
licenses/by-sa/3.0/deed.en).
[21] Marius140%. “A mission-station teacher teaches English to young Zulu and Afrikaans chil-
dren.” https://commons.wikimedia.org/wiki/File:Kaleidoscope_for_young_minds.jpg,
2009. Accessed 2022-08-21; licensed under Creative Commons Attribution-Share Alike 4.0 In-
ternational licence (https://creativecommons.org/licenses/by-sa/4.0/deed.en).
145
[22] ISO/IEC Joint Technical Committee 1. ISO/IEC/IEEE 42010 Systems and software engineering –
Architecture description. International Standards Organisation, 2011.
[23] RadioFan. “Wind tunnel model of the space shuttle.” https://commons.wikimedia.
org/wiki/File:NTF_STS_wind_tunnel_model.jpg, 2011. Accessed: 2022-05-24; licenced
under Creative Commons Attribution Share-Alike 3.0 Unported licence, see https://
[24] Wood, W.W. The Westinghouse E-T Air Brake Instruction Pocket Book. The Norman W. Henley
Publishing Co., New York, NY., USA, 1909.
[25] Sheehampster. “3D model of the entire robot.” https://commons.wikimedia.org/wiki/
File:Final_Robot.jpg, 2013. Accessed: 2022-05-24; licenced under Creative Commons At-
tribution Share-Alike 3.0 Unported licence, see https://creativecommons.org/licenses/
by-sa/3.0/deed.en.
[26] “43170 at Dawlish.”
[27] Oxford, N. “Grenfell Tower on fire.” https://commons.wikimedia.org/wiki/File:Grenfell_
Tower_fire_(wider_view).jpg, 2017. Accessed: 2022-05-04; licenced under Creative Com-
mons Attribution 4.0 International licence, see https://creativecommons.org/licenses/
by/4.0/deed.en.
[28] ISO Technical Committee 207. ISO 14001 Environmental management systems – Requirements
with guidance for use. International Standards Organisation, 2015.
[29] Sgt. Adrian Harlen. “British Army guards on parade.” https://commons.wikimedia.
org/wiki/File:Guardsmen_on_Parade_MOD_45155722.jpg, 2013. Accessed: 2023-07-15; Li-
cenced under UK Open Government Licence, see http://www.nationalarchives.gov.uk/
doc/open-government-licence/version/2/.
[30] “Oxford english dictionary online - definition of “assurance”.” URL https://www.lexico.com/
definition/assurance. Accessed: 2022-06-06.
[31] ISO Technical Committee 176. ISO 9001 Quality management systems – requirements. Interna-
tional Standards Organisation, 2015.
[32] Morse, A. Modernising the Great Western railway. UK National Audit Of-
fice, 2016. Accessed 2022-06-06 online (URL: https://www.nao.org.uk/report/
modernising-the-great-western-railway/).
[33] Grant, R. and Naylor, D. “White Hole (Red Dwarf series 4 episode 4).” BBC Television, 1991.
[34] European Commission. “Directive 2012/19/EU of the European Parliament and of the Coun-
cil of 4 July 2012 on waste electrical and electronic equipment (WEEE) (recast).” https://
eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012L0019-20180704, 2012. Ac-
cessed 2022-12-21.
[35] Page, D. Report of the Inquiry Into The London Ambulance Service. South West Thames Regional
Health Authority, 1993.
[36] “Wikipedia page on the Post-It note.” URL https://en.wikipedia.org/wiki/Post-it_Note.
Accessed: 2022-06-05.
[37] Elphick, J. “Railway systems engineering: why is water wet?” In IET professional development
course on railway signalling and control systems, pp. 250–270. 2010. doi:10.1049/ic.2010.0104.
146
[38] “BBC Question Time Leaders’ Special.”, 2005. URL https://youtu.be/nqieLSIKWx0?t=4648.
Date broadcast: 2005-04-28; date URL accessed: 2022-08-07.
[39] Senge, P.M. The fifth discipline: the art and practice of the learning organisation. Random House
Business Books, 20 Vauxhall Bridge Road, London SW1V 2SA, 2006.
[40] “EARS.” URL https://alistairmavin.com/ears/. Accessed: 2022-06-06.
[41] “Cambridge english dictionary online.” https://dictionary.cambridge.org/dictionary/
english/model, 2021. Accessed 2022-05-23.
[42] Shoesmith, E., Box, G.E.P. and Draper, N.R. “Empirical model-building and response surfaces.”
The Statistician, 37, 82–82, 1987.
[43] World Commission on Environment and Development. Our Common Future. Oxford Univer-
sity Press, 1987.
[44] “Circles of sustainability.” URL https://www.circlesofsustainability.com/. Accessed:
2022-06-06.
[45] Overman, H. “HS2: assessing the costs and benefits.” CentrePiece, 2011. Accessed 2022-06-06
online(URL: https://cep.lse.ac.uk/pubs/download/cp361.pdf).
[46] Slaper, T.F. and Hall, T.J. “The triple bottom line: What is it and how does it work?” Indiana
Business Review, 86, 2011. Accessed 2022-06-06 online (URL: http://www.ibrc.indiana.edu/
ibr/2011/spring/article2.html).
[47] Institution of Engineering and Technology. “IET rules of conduct.” https://www.theiet.org/
about/governance/rules-of-conduct/, 2019. Accessed: 2022-05-06.
[48] National Society of Professional Engineers. “NSPE code of ethics.” https://www.nspe.org/
resources/ethics/code-ethics, 2019. Accessed: 2022-05-06.
[49] Institution of Mechanical Engineers. “IMechE code of conduct.” https://www.imeche.org/
docs/default-source/1-oscar/About-us/governance/code_of_conduct_02_03_02.pdf?
sfvrsn=2, 2021. Accessed: 2022-05-06.
[50] Institution of Mechanical Engineers. “IMechE code of conduct.” https://www.
engineersaustralia.org.au/ethics, 2019. Accessed: 2022-05-06.
[51] Sir Martin Moore-Bick. “Grenfell Tower Inquiry: phase 1 report overview.” Technical Report
ISBN 978-1-5286-1620-1, Grenfell Tower Inquiry, 13 Bishop’s Bridge Road, London, W2 6BU, 2019.
[52] “ISO website on the 14000 series of environmental management standards.” URL https:
//www.iso.org/iso-14001-environmental-management.html. Accessed: 2022-06-06.
[53] Lakhani, N. “BP faces Mexican class action lawsuit over Deepwater Horizon oil spill.”
The Guardian, 2015. Accessed 2022-06-06 online (URL: https://www.theguardian.com/
environment/2015/dec/11/bp-gulf-oil-spill-mexico-lawsuit-deepwater-horizon).
[54] N509FZ. “Red point-toe high-heeled shoes on ground.” https://commons.wikimedia.
org/wiki/File:Red_point-toe_high-heeled_shoes_on_ground_(20220104173302).jpg,
2022. Accessed: 2023-07-15; Licenced under Creative Commons Attribution-Share Alike 4.0
International Licence, see https://creativecommons.org/licenses/by-sa/4.0/deed.en.
147
[55] Bruggemann, S. “Nitti safety footwear with removable metatarsal guards.” https://commons.
wikimedia.org/wiki/File:Nitti_MetatarsalGuard.jpg, 2011. Accessed: 2023-07-15; public
domain image - see https://creativecommons.org/publicdomain/zero/1.0/deed.en.
148

101 Tips For Successful Engineering

Uploaded by

Copyright:

Available Formats

You might also like

101 Tips For Successful Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

101 Tips For Successful Engineering

Uploaded by

Copyright:

Available Formats

101 tips for successful engineering

About the author

Copyright ©2022 Joseph Silmon. All rights reserved.

2 Types of engineering organisation 1

3 Funding models for large engineering programmes 6

4 Entry-level engineering roles 6

6 Common features of projects and project management 6

7 Types of engineering project 6

9 Programmes, scheduling, and critical paths 6

10 Managing work packages 6

11 Bidding for work or funding 6

12 Estimating the costs of work 6

14 Assessing and managing commercial risk 15

15 Common features of business management 15

16 Margins, turnover, and utilisation 15

II Delivering like a better engineer 16

19 The many facets of quality assurance 16

20 Assuring people, processes, and tools 19

23 Dealing with stakeholders 22

24 Managing sets of requirements 22

25 Case study of a project overrun: electriﬁcation of a railway 26

26 Roles in a multi-disciplinary project 30

27 Cross-discipline engineering activities 30

28 Value engineering, option selection and tradeoffs 30

29 How single-discipline designers contribute to a whole solution 30

31 Demonstrating an integrated solution 30

32 Reliability, maintainability and availability (RAM) 30

33 Analysis methods for RAM 30

34 Concepts of operation, use, and employment 30

35 Examples of design for maintenance 46

36 Managing entry into service 46

37 Delivering work safely 46

III Thinking like a better engineer 47

40 The bridge to nowhere 58

41 An introduction to engineering lifecycles 63

42 Reading behind the brief: distinguishing between requirements and solutions 68

44 Emergent behaviour and properties 79

47 How to avoid causing “death by Powerpoint” 93

48 Writing better documents 97

49 Typical methods for articulating requirements 103

50 Capturing requirements 103

51 Anatomy of a requirement 103

52 Writing effective text requirements 108

V Modelling like a better engineer 109

54 Basics of information modelling 116

55 Modelling requirements 116

56 Describing interfaces clearly 116

57 How to plan a system architecture modelling activity 116

58 Modelling languages and frameworks 116

59 Modelling tools and data environments 116

60 Modelling the environment around your product 116

61 Types of interface 122

62 Modelling RAM and safety information 122

VI Behaving like a better engineer 123

64 Common features of codes of conduct 127

65 Why safety is always your job 133

66 Safety through the lifecycle 135

67 Common features of safety legislation 135