Arbutus Technical Consulting

More than eight years ago, I started work on a PhD at the University of Birmingham. My topic was ‘The Benefits of Adopting Systems Engineering Approaches on Rail Projects’. At the time, I was working at Atkins and trying to raise the capability of its rail business in the area of Systems Engineering (SE). There were two questions that colleagues asked me and that I knew that I could not answer properly:

• ‘If I apply SE to this project, will I see benefits that justify the cost?’
• ‘How should I adapt SE practices that have been developed in other sectors to make them work well on my project?’

Having failed to find anyone who could give me a satisfactory basis for answering these questions, I embarked upon this research in order to find some sorts of answers to these questions.

I passed my viva in August 2014 and submitted the final version of my thesis in September 2014.

If the questions above are of interest to you then please feel free to read my thesis. You can read an abridged (100 page) version here. The full (300 page) version will be made available by the University in December 2014 here. If you want to see the full version before the University makes it available, please contact me.

To help you decide whether to read the thesis, here is the abstract:

“Systems Engineering (SE) is being used increasingly in rail projects, with the aim of creating better systems in better ways, thus generating a return on the effort invested. However, it is not entirely clear what exactly that return will be or how to maximise it. This thesis contains the results of research into the relationship between the adoption of SE in rail projects and project outcomes.

The writer shows that determining the success of a project, and thus the impact of SE, by simply measuring its cost and duration and assessing the performance of the system that it delivers, is problematic. He argues that the adoption of an SE approach can lead to decisions to correct faults in the system design and make other desirable changes being taken earlier, which will improve the outcome in most cases. Theoretical reasons and practical experience lead him to believe that many of the benefits of applying SE on projects will be enjoyed as a consequence of reducing change latency, where change latency is defined to be the unnecessary delay in deciding to make a change. A tentative theory of how SE can reduce change latency is proposed and tested against data collected from nine rail projects. The data corroborate several proposed causal mechanisms in the tentative theory but also suggest that the reduction in change latency achieved depends upon other factors, particularly the contractual and quasi-contractual relationships between the parties to the project.

For practitioners considering whether to apply SE on a project, the research findings provide encouragement but also a warning that the full benefits of applying SE will only be enjoyed if other pre-requisites for sound decision making are in place. The findings also provide guidance on how to adapt SE practices when applying them to rail projects, in order to maximise the benefits enjoyed.

The writer argues that change latency is a valuable metric for both practitioners and researchers and that formulating and refining explicit theories about the manner in which SE delivers benefits can assist researchers investigating these benefits to build upon each other’s work.”

At the end of my research, I can offer the following answers to my two initial questions:

Question: ‘If I apply SE to this project, will I see benefits that justify the cost?’

Answer: ‘You will see benefits if the contractual and quasi-contractual relationships between the parties to the project, including separately-run departments within one organisation, are set up in a way that allows them to collaborate effectively towards common goals and take decisions quickly. The benefits may be lower on projects that construct simple, routine, new sections of railway and already adopt good project and contract management practice but, if your projects suffer from high change latency, the cost of focussed improvements in SE is likely to be justified by the benefits that they deliver.’

Question: ‘How should I adapt SE practices that have been developed in other sectors to make them work well on my project?’

Answer: ‘To maximise the benefits of SE practices on rail projects, you should maximise their ability to reduce change latency by focussing, at least initially, upon requirements engineering and upon modelling, simulation and analysis and by adapting good SE practice to suit the nature of rail projects, as recommended above’.

 

 

Like a lot of middle-aged men, I could do with losing a bit of weight. But, when I was a young man, I used to be in the unhealthily underweight category on the charts and I can remember being pleased when I put on enough weight to make it to the healthily normal category. The trouble is that over 25 years the gradual increase took me all the through the normal range and out the other side.

Safety management systems suffer from middle-aged spread as well. Over time they accumulate flab in the form of unnecessary process steps, unnecessary documents, unnecessary sections within documents and unnecessarily complex approval processes.

To some extent this happens in all aspects of business but it is worse in safety because of the belief that, if in doubt, it is safer to leave something in than to take it out. Now if we are talking about the safety of the people affected by the system being built, I don’t think that’s true for reasons that I will explain. But there is undoubtedly a personal risk to anyone suggesting taking something out of being accused of recklessness or of being blamed if something were subsequently to go wrong.

So, over time, our rational individual behaviour imposes a ‘ratchet’ on the evolution of safety management system. When we miss something out that should have been there we usually find the mistake later on and put it right. But, when we add something unnecessary, it tends to stay there. Elsewhere, I have argued that ISAs contribute to this ratchet but others contribute as well, for example:

• A safety engineer is producing a safety plan using the Yellow Book proforma. This has a section on ‘Validation and Verification of External Items’. This seems irrelevant to the project but writing “Not Applicable” might attract adverse comment so they find three paragraphs of anodyne but pointless text to include.
• As a result of an unfortunate error getting through all stages of project review, the organisation’s head of the relevant discipline decrees that all safety submissions should be sent to them for their review. They regret it almost instantly when their in tray fills up with more material than they can read but leave the instruction in place.
• A safety authority notices that there is a gap in the safety planning but rather than ask for the safety plan to be reissued, finds it convenient to ask for a separate paper on the topic. The project complies but now there are two overlapping planning documents instead of one.

Over time this gets expensive. We may not see the cost but that doesn’t mean it isn’t there. If our safety plan could have been 20 pages long but ends up being 40 pages long then it takes every new project member another hour to read it. And every update takes another day, including formulating and discussing changes to the unnecessary pages. So these unnecessary pages add a small fraction of a percentage point to the cost of the project. On its own, that cost might not be worth doing anything about but, if it is repeated across many documents then it starts to adds up.

I have kept a rough personal tally during my career of the ratio of the number of hours of technical effort expended on an engineering activity to the number of pages of reviewed technical output. For the majority of the projects that I have calculated this ratio for, it has fallen within a relatively small range. That is what I would expect – the effort of preparing and checking two different pages of technical data must surely be in the same order of magnitude.

Therefore, reducing the number of pages of output from a technical activity should reduce the cost. I won’t claim that reducing the number of pages by 20% will reduce the cost by the same fraction but I would expect a reduction of at least 10%. However there are two important warnings:

• Firstly, as soon as you use a metric to set targets it becomes distorted and ceases to be a reliable indicator. So if you ask your staff to produce fewer pages, don’t be surprised if you start to see a smaller font size.
• Secondly, we can expect to see a cost reduction no matter which pages we cut out. The trick, of course, is to cut out the ones we don’t need. More on that later.

As I have already suggested though, I think that this is about far more than money. I observe that:

• Unnecessary activities and outputs shift the focus for safety engineers away from working with the project delivery staff in order to control hazards towards creating documents and steering them through approval processes.
• Having multiple parties reviewing submissions introduces the danger that each party will rely on the other to look at some aspect of the submission. So this aspect gets reviewed less thoroughly than it would if there had been only one party reviewing it.
• Unnecessary activities and outputs increase the latency of the safety management process, that is, the delay between a design proposal being made and an assessment being available of how safe it is. The longer the latency, the harder it becomes to influence the design.

Therefore, I maintain that, all other things being equal, adding unnecessary activities and output to a safety management programme will make things less safe. I now think there is a fundamental missing from the Yellow Book along the following lines:

Elimination of waste

If your organisation is carrying out some safety management activities which cannot plausibly reduce risk, does not contribute to confidence in safety and it is not required for legal or business reasons, then you should stop doing it. If your organisation’s safety management documents have content which is not associated with reducing risk, does not contribute to confidence in safety and it is not required for legal or business reasons, then you should remove it.

In my opinion, the safety community needs to make sure that all its work is in accordance with this fundamental and it needs to do so urgently. Those of us working in Western economies know that we are in for an extended period of tight budgets. If we don’t cut out waste surgically ourselves, someone else is going to wield the axe indiscriminately.

Moreover, those of us who are working on project and programmes that have been running for some time almost certainly need to take a long, cool look at the structures which have grown around us, identify the parts that are unnecessary and cut them out.

Postscript

By now, some readers must be asking, “Am I talking about ‘Lean safety’ and, if so, why don’t I use the L word?”

I probably am talking about lean safety. I went on a brilliant course with “lean” in its title once, which opened my eyes to how much wasted effort there was around me and how much better things could be of that were eliminated. That surely must have influenced what I have written here.

However, I am wary of giving a name to something which seems to me to be broadly common sense. Once you have a name then, soon after, you have a project team, a steering group, newsletters and mugs. Perhaps that’s the right thing to do for you but it’s certainly not necessary. Some people swear by their patent dieting method but, if I were just to eat less and exercise more, I would lose weight. I could start doing that today if I wanted to without giving the process a name. In just the same way, you and I could just ask ourselves, “Do we need all of this?” the next time we wrote or reviewed a safety paper. I plan to do just that.

The SE orthodoxy holds that the only true answer to the question “I am not doing much SE on my project, should I do more?” is “Yes”. My heresy is to suggest that the answer should be, “It depends” or, perhaps more precisely, “Yes, but only if you make sure that you have got some other stuff straight first”.

What has led me this conclusion is carrying out some PhD research into the correlation between how much SE people do on projects and how well they turn out. A couple of the projects pursued a direction for a considerable period of time which it was known (by the systems engineers and, I dare say, a good many other people) did not lead to delivering what the customer needed at a price that they could afford. By the time that the project changed direction, a great deal of time and money had been wasted.

I have worked on projects like these. It feels like being a crew member on the RMS Titanic, with the klaxons screaming “iceberg ahead” while the ship steams consistently along its original course. The reasons this project ship can’t change course vary: perhaps the contracts make it too difficult or too slow; perhaps those taking the decisions are unable to admit that they have made an error or perhaps those taking the decisions are unable to reach an agreement among themselves. Whatever the reason, the rudder is effectively broken.

Now, it seems obvious to me that systems engineering is a supporting function on a project. Unlike a mechanical engineer, an installer or a technical author, there is no part of the delivered system that can point to and say, “I designed/installed/wrote that”. And systems engineers don’t take the final decisions on what gets built. Systems engineers may like to think that they do, particularly those who call themselves “systems architects”. After all, surely the architect of a building or a system is the “controlling mind”? Well maybe, but architects work for clients. They work within a brief that the client can change and the final decision rests with the client. On real projects, final decisions typically get taken by committees representing the client and other key stakeholders.

So, as I have pointed out before, systems engineers only affect the outcome indirectly, by helping the delivery functions delivery products that will work and by providing those that take decisions with accurate information and sound advice.

On the new state-of-the-art Titanic II, systems engineering is not the Captain, it’s a radar and navigation function that supports the Captain in plotting and following a safe and efficient route through the icebergs. If the radar is not working properly, the Captain would want to fix it. But if the rudder was broken too, the Captain would probably ask Engineering to fix that first.

And so it is on projects. The correct answer to the question “I am not doing much SE on my project, should I do more?” is “Yes, but only if you make sure that the decision-making apparatus on your project allows you to make timely and rational decision. Otherwise fix that first”.

I have just finished watching the recording of Wim Coenraad’s IET presentation “Understanding the ‘English Disease…”. As one of the authors of the Yellow Book, the billing could not help but catch my eye:

“In recent years a safety case seems to have become synonymous with long delays, caused by consultants, aka “brains on sticks” inventing solutions for problems, drawing out assessments and costs spiralling out of control. In some places this is seen as “Yellow Book fever”, or “the English disease”. UK practices seem to be exporting the Yellow Book Philosophy and by putting procedures before brains, through largely unmanaged, ISAs as well as processes, in a stifling (legal) framework, which is dominated by fear of litigation and indemnity claims. It is not risk based but risk averse and clearly unsustainable and therefore a threat to the rest of us!”

So I watched the presentation with some apprehension. Was the Yellow Book going to be likened to ‘Mad Cow Disease” and its authors to football hooligans? In fact, Mr Coenraad’s criticisms of the content of the Yellow Book are mostly concerned with the presentation of Safety Cases where he makes some sensible and cogent proposals which, if adopted, would leave the majority of the Yellow Book untouched.

Mr Coenraad’s main criticism is reserved for the way in which the Yellow Book is used and in particular for a promotion of text which is clearly advisory guidance to mandatory requirements and its application in circumstances where it is not appropriate. Now I know that this happens and it is clearly a bad thing so it doesn’t seem unreasonable to refer to it as a ‘disease’.

So for the purpose of this article, I hope I am not straying too far from Mr Coenraad’s presentation if I define the ‘English disease’ to be an unthinking application of inappropriate advisory safety guidance.

As to whether it’s a fair name, I don’t know. It’s certainly not restricted to England but the English do seem to be rather prone to it. Whatever its name, it is worth of study. Let’s call it ED for now.

Mr Coenraad offers his analysis of the cause and consequences and of ED and some suggestions for remedies. I’d like to develop these further.

Causes

Mr Coenraad suggests two causes:

• A legal environment that causes people to feel that they must follow authoritative guidance, whether they believe that it is appropriate or not because, if an accident were to occur, they might find themselves in court with a lawyer waving the Yellow Book (or whatever) at them asking them why they had not followed the guidance on page such-and-such.

• Assessors who find it easier to check project processes and products clause-by-clause against a publication like the Yellow Book than to form a judgement from first principles as to whether the processes and products are suitable for their purposes.

My personal suspicion is that the first cause drives the second and that assessor’s behaviour is driven more by the threat of finding themselves in court than by laziness. So it is the first caysethat interests me.

Here I suspect that the problem, in the UK at least, may be traced back to clause 3 (i) of the Health and Safety at Work etc Act 1974 which reads:

“It shall be the duty of every employer to conduct his undertaking in such a way as to ensure, so far as is reasonably practicable, that persons not in his employment who may be affected thereby are not thereby exposed to risks to their health or safety.”

For what it’s worth, I have always considered this to be a reasonable formulation of the duty of care which I believe that we owe to each other. However, the use of “reasonable practicability” as a test of legal guilt leads to a situation where it is extremely difficult to know whether one is breaking the law or not. That is a very uncomfortable position to find oneself in it and it is only human nature to try and remove this discomfort by finding some authoritative procedure to follow which one could then use as a defence in a court of law.

Consequences

Mr Coenraad suggests that the immediate consequences of ED are unnecessary activities and paperwork, leading to increased costs which divert resources from measures that would reduce risk and, he argues, threatening to making the railways economically unsustainable. I don’t have the knowledge to judge whether the consequences are quite as severe as this but, otherwise, I find the analysis logical and compelling.

But I think it is worse than that. As I have argued elsewhere, I think that having people carry out tasks in the name of safety which do not actually contribute to making anything safer is counter-productive in its own terms because:

• It breeds a cynicism which can in turn lead to passivity when faced with things that are not as they should be;
• It diverts a proportion of a limited pool of experienced, capable people’s time from other activities, some of which might have delivered increased safety; and
• It stifles people’s ingenuity.

If anything it is the last one that worries me most. A random transposition of vowels has contributed to a misunderstanding of engineering in the UK. People assume that “engineers” were originally people who mended engines and mix us up with technicians. “Engineer” is “ingenieur” in Dutch and German, “ingénieur” in French and “ingegnere” in Italian and, in all these languages, it is clearer that an engineer is someone who is paid to use their ingenuity. Railways are as safe as they are because of the accumulated consequences of any number of ingenious inventions. If we are going to replace that ingenuity with blind following of rules then that improvement is going to stop.

So I am convinced that, all other things being equal, the consequences of ED include rail travel that is less safe that it would otherwise have been.

Remedies

Mr Coenraad suggests resisting pressures to do things that you don’t believe contribute to safety. I agree with that but it does not seem to me to be a real cure. I think we need to try to attack some of the root causes.

Firstly, I do think that those who make and enforce health and safety law need to:

• Make sure that those who are subject to it can be sure in advance whether they are following it or not; and
• be quite clear that the law can be relied upon to distinguish between cutting corners and a principled, properly thought through and properly checked decision not to follow an established practice on the grounds that it is not appropriate to the circumstances at hand.

But the law changes slowly. In the meantime, I think that we need to look for other remedies. I was discussing this with a friend and ex-colleague Richard Tavendale. About 10 years ago, we wrote a paper together arguing that we should articulate the fundamental principles behind the Yellow Book. This idea was adopted and since issue 3 was published in 2000, the Yellow Book has been structured around a number of fundamentals.

Richard and I agree that the introduction of Yellow Book fundamentals was a step forward but neither of us thinks that this step has yet been fully exploited. Perhaps an injection of Yellow Book fundamentals might provide patients with some resistance to ED?

Yellow Book 4 contains the following text:

“If your organisation already has a systematic approach to managing safety, you should check that it puts all the fundamentals into practice. If you do not have a systematic approach yet, or if your approach does not yet put all the fundamentals into practice, you may find volume 2 useful. You do not have to use the approach described there and it is not the only effective approach, but it has been proven in practice.”

Mr Coenraad exhorts people to “engage their brains” before reading the book. Surely he must have something like this in mind.

I suggest a couple more remedies:

• Those of us who are doing Engineering Safety Management can turn down the corner of that page in the Yellow Book so that we can find it quickly the next time an assessor tells us that “you have to do this because it says so in the Yellow Book”.
• Those of use who are assessing others can bear this advice in mind as well. We can try to lift our assessment from checking the contents lists of Safety Plans to trying to judge whether or not the fundamentals are being effectively put into practice.

Then perhaps we can talk about the Yellow Book as a cure of ED rather than a means of infection.

People can sometimes be reluctant to criticise the safety management arrangements within projects. I suspect there are three main reasons for this:

• They worry that criticism may be interpreted as a sign that they are not committed to safety
• They feel unqualified to comment
• They are unsure what the best way of doing safety management actually is

The first is most easily dealt with. I have had the good fortune to be involved with the Yellow Book – the UK railway’s handbook of safety management – over a period of more than fifteen years, encompassing four major revisions. Constructive criticism is the lifeblood of the book – each issue has been subject to multiple rounds of rigorous criticism and emerged much the better for it. Cogent, reasoned, specific criticism of safety management arrangements is clear evidence of a deep commitment to safety. I should like to encourage a little more of it.

As to the second, I shall try to show that it is quite possible for the non-specialist to make reasoned criticisms of safety management arrangements from first principles. Actually, I think that the non-specialist is often better able to ‘see the wood for the trees’.

The last reason is knottier. The measure of successful safety management is the absence of incidents. Thankfully, we have been successful enough to date in most industries that incidents are very rare and consequently there is very little in the way of data to measure with and probably not enough to objectively compare competing methods. So it probably is the case that no-one is sure what the best way of doing safety management actually is.

But just because we may not know what best practice in safety management is does not mean that we cannot work from first principles to identify some symptoms of poor practice. The rest of this paper proposes a number of such symptoms.

The first set of symptoms arise from the observation that safety specialists only contribute to safety indirectly by helping those who have a direct hand in delivering the end product (designers, programmers, installers, testers, writers of manuals) to do their job better. So, effective safety management must hinge on good interaction between safety specialists and delivery people. The following are potential symptoms of deficiencies in this interaction.

Symptom 1: Safety specialists are not influencing the end product

You ask the safety specialists to explain how the end product has been changed to make it safer as a result of the safety management arrangements and see if they can list any examples. It is not a definitive diagnosis. One possible reason why you may not get any examples is that the informal interaction is so good that safety issues are designed out before anything is subject to formal analysis. But, on the whole, as absence of specific examples where safety management has improved the design is grounds for concern and for asking more questions.

Symptom 2: Delays and bottlenecks in the communications channels between safety and delivery people

So, for example, if the safety and delivery teams are in different buildings communicating mostly by email, you have to wonder how effective the feedback loop which connects the two teams really is.

Symptom 3: The safety specialists get involved too late

If the design is only subject to safety analysis after it has been finalised, the scope for using that analysis to improve the design is much reduced.

Symptom 4: The safety specialists give the delivery team more paperwork than they can read

I don’t know how to look at the volume of paperwork on a project and tell you objectively whether it is too much, too little or about right. But if the safety specialists are providing delivery personnel with more paperwork than the latter can read, something must be wrong: either they are being given stuff that they don’t need to read, or they are failing to read something that is important. In fact, both things are likely to be true.

The next symptoms are a little different.

Symptom 5: There is a gross mismatch between the effort given over to two risks and their relative magnitude

So risk A is clearly significantly bigger than risk B but the effort given to managing risk B is significantly more than that given to managing risk A. Common sense suggests that it should be possible to obtain greater risk reduction at no additional cost by shifting effort from risk B to risk A.

The power of this comparison is that you can use it in lots of different ways. As well as just comparing two risks on the same project, you can also compare system safety risks with occupational health and safety risks and risks on one project with risks on another.

Symptom 6: There is a significant apparent inefficiency in the safety management arrangements

For example, there is a document or an activity which does not seem to contribute to safety or there is a part of a document which does not seem to contribute to the document’s purpose. Or there is a failure to adopt a method of achieving a task which is known to be as effective but less expensive.

All other functions on a project are under continuing pressure to improve their efficiency but safety specialists seem to be at least partially exempt. I suspect this is because inefficiencies are seen as ‘right side failures’ (Railway jargon. A red signal that should be green is a ‘right side failure’ while a green signal that should be red is a ‘wrong side failure’.) So failures of efficiency in safety management‘just’ cost money and take second place to failures of effectiveness – wrong side failures – which might cost lives.

I am not sure that I agree with the ‘just’ above – it is my money as taxpayer and farepayer after all – but I’ll let that go because my real point is that I think that this analysis is over simplistic. All major engineering projects that I have ever worked on have passed through a phase where no amount of money could have speeded them up because they were limited by the time available from a small number of capable team members who knew the project well. In this phase, any effort that is spent on safety management activities has to be at the cost of something else and, some of the time, the losing activity will have been something that might have contributed to safety. Moreover unnecessary activities distract attention from what really matters and may contribute to a corrosive cynicism in the team.

So I think that major inefficiencies in safety management arrangements are actually ‘wrong side failures’ and that efforts to remove them will contribute to increased safety as well as decreased costs.

I hope you find the checklist above of use. You can use it when looking at specific projects to identify areas of poor practice. And if you can find any part of the Yellow Book which could be taken to encourage poor practice then you can the checklist them to support constructive criticism of the book (which you can submit here).

Please let me know if you have any suggestions for addition to the list.

The Yellow Book is the UK railway’s handbook on engineering safety management. I have had the privilege to be involved with it since its British Rail roots in 1993 and most recently I led the editorial committees that produced two small supplements to it:

• Application Note 7 The Yellow Book, Safety Management Systems and the ROGS Regulations
• Application Note 8, Safety Management and Standards

These appeared without much fanfare on the Yellow Book web-site a few weeks ago. If you have an interest in this area then I commend them to your attention.

One of the reasons that I think that they are important is that, in my mind at least, their publication marks the real end of the Yellow Book 4 project. The Foreword to Yellow Book 4 says:

“Most of the chapters in issue 4 will be relevant to all readers but there are some chapters where the guidance remains primarily relevant to those readers who need to carry out risk assessment. In the next issue of the Yellow Book we intend to provide guidance on how to put all fundamentals into practice in applications where risk is controlled through standards and procedures, including those that fall under the interoperability directives and ROGS regulations.”

(The ‘ROGS Regulations’ being the ‘Railways and Other Guided Transport Systems (Safety) Regulations 2006’, part of UK railway safety law).

This promise implicitly recognised that there were readers of the Yellow Book who were not served as well as they could be. Application Notes 7 and 8 provide “guidance on how to put all fundamentals into practice in applications where risk is controlled through standards and procedures, including those that fall under the interoperability directives and ROGS regulations” and go a long way towards delivering on the promise.

The other reason why I think that the Application Notes are important is that they help to dispel a number of myths about the Yellow Book that seem to have grown up. I listed seven of these myths in a paper a few years ago. The last entry in my list was:

• Myth 7: The Yellow Book is just for people who are doing something novel

I wrote then that “there is a great deal of value to railway professionals who control risk through the disciplined and skilful application of standards and procedures” and, while that was and is true, it was also true that there was limited help for such people in reconciling the use of these standards and procedures and the guidance in Yellow Book 4. Application Note 8 deals with that head-on.

If I was listing myths today, I would add a few more:

• Myth 8: The ROGS Regulations render the Yellow Book obsolete for those who must comply with them
• Myth 9: If you organisation has its own safety management system then the Yellow Book is of no use to it

Application Note 7 tackles these. It explains how you can put the Yellow Book to use if your organisation must comply with the ROGS Regulations and/or has its own safety management system. The Yellow Book doesn’t help with all parts of the ROGS Regulations or of a safety management system and Application Note 7 is frank about this: it lists aspects where the Yellow Book has little to say and provides pointers to other sources of guidance. But it does point out big areas where the Yellow Book provides a reservoir of relevant, proven good practice which it would be a shame to ignore.

So, if you do work in this area, do please take a look at the Application Notes on the Yellow Book web-site. If you have comments you can find details of how to feed them back to the Yellow Book Steering Group on the web site. I’d be interested as well.

Let me take Professor Philip M’Pherson’s second apparent anomaly about systems engineering (see Systems Engineering for Systems that are already in-service):

• Although systems engineers like to keep the word ‘engineering’ in the title of their discipline, most of the activities that they report that they perform would fall within the scope of what most people would call ‘management’.

Systems engineering and project management seem to be inextricably intertwined to the extent that it is impossible to separate them. One may be able to say that some things are definitely project
management activities while others are definitely systems engineering activities but one is always left with a residue of tasks that could be either. Of course, in any given project, the systems engineers and project manager or managers will have to split the work up between them but this is a negotiated boundary. Like the boundary between Libya and Chad it is just a line in the sand.

The reason for this became clearer to me when I heard two presentations on the activities of systems engineering teams working on a large Underground railway project. One was primarily concerned with the signalling systems, the other with modernizing the stations. Both were impressive presentations but the two teams seemed to be doing very different things. Could they both be right?

I think they were both right. Let me explain why.

If you go into a systems engineer’s office you are likely to find a big sheet of paper on the wall with lots of boxes connected by lines. The boxes will be parts of the system being built and the lines indicate that one part interacts with another – sends it data or power or something. The lines indicate ‘interfaces’ between the parts of the system and while other project members concentrate on getting the parts of the system right, the system engineer worries about the system as a whole and particularly the interfaces.

Now, if you go into a project manager’s office you are also likely to find a big sheet of paper on the wall with lots of boxes connected by lines. The boxes will be tasks that must be carried out in order to complete the project and the lines indicate that one task depends on another, for example, the output of one task is an input to another. The project manager would probably call the lines dependencies but we could also talk about ‘interfaces’, particularly when the two tasks connected are being done by different people. While other project members concentrate on completing their delegated tasks, the system engineer worries about the project as a whole and particularly the interfaces.

So, it is perfectly possible to see the project as a system, in which case the project manager must be doing some sort of systems engineering on it.

So, what?

Well, the point is that, if you have to get the interface between two parts of the system right, you can either:

• A: deal with the issue directly, by defining the interface between the parts of the system being built, or
• B: deal with it indirectly, by creating an interface between the tasks to design these two parts.

Take a passenger information display on a tube station as an example – the thing that tells you how long you will have to wait for your next train.

It has a cable going into it down which some computer system sends it the information that it should display. This is probably a reasonably complex interface. If everything is going to work when it is plugged together we need both sides to agree on the shape of the connectors, what each pin will be used for, the voltages to be used and a series of data messages that the computer system can use to tell the display what to show. The systems engineers would tackle this with method A and prepare a document defining all these things. They might call it an ‘interface control document’.

But the display also has a mechanical interface to fixings that go into the ceiling of the tunnel to hold it up. This is probably a much simpler interface – the people designing the fixings just need to know the weight of the display. Of course it is important to get it right but writing an ‘interface control document’ is overkill and worse, if the systems engineers did it they would probably have to err on the side of caution and we would end up with over-engineering. It makes more sense to use method B: tell whoever is designing or selecting the display that at such-and-such a point they must tell someone how heavy it is going to be.

When I reflected on the two presentations that I had heard it was clear that

• the signalling team was dealing with a relatively small number of complex interfaces and generally used method A, while
• the station team was dealing with a large number of relatively simple interfaces and generally used method B.

Once I saw that, I could see that, in principle they were doing the same thing in different circumstances.

Of course, at the outset, it can be very hard to know whether an interface should be dealt with by method A or method B or a mixture of the two and, indeed, it may prove necessary to change one’s approach as the project proceeds.

So, effective systems engineers have to get involved in management activities, at least to the extent of worrying about technical co-ordination between tasks.

And, I also think that effective project managers have to get involved in systems engineering, at least to some extent, but that’s a topic for another article.

At the INCOSE UK 2008 Autumn Assembly, Professor Philip M’Pherson discussed some interim findings from a survey of views on the value of systems engineering. He confronted the assembled systems engineers with two apparent anomalies;

• Although systems engineers like to keep the word ‘engineering’ in the title of their discipline, most of the activities that they report that they perform would fall within the scope of what most people would call ‘management’
• Although most of the papers in systems engineering journals and conferences discuss the creation of new systems, most systems engineers spend their time maintaining and changing existing ones

Both of these observations resonated with me and I’d like to return to the first point in a later article.

Let’s take the second point here. It struck a chord with me because I had been working in rail systems engineering and there is an extent to which, since Brunel and Stephenson, the rail industry has hardly ever created a brand new system. Almost all the time, even if we are building new trains or signalling systems, the hard part is to fit them into the existing railway system and, at this level, we are always changing and maintaining something that exists.

I had recently been attached, as a systems engineer, to a project concerned with replacing the points at the approach to a major UK railway station. It was perfectly obvious to me that hard problems in the project were systems problems. Let me give you an example.

Before the project a large number of cables had been threaded through the ‘ballast’ (the gravel that the rails are laid on). However, modern standards prohibited this and some other solution had to be used, such as putting the cables on a bridge over the tracks, putting them in a tunnel under the tracks or threading them through hollow sleepers. Considerations to be taken into account included:

• Making sure that any bridge would not interfere with drivers’ view of signals
• Making sure that it was possible to erect a crane near the site of any bridge in order to construct it
• Making sure that any tunnel would not interfere with the foundations of anything else
• Making sure that there was time in the very tight construction schedule to build any tunnel
• Making sure that there was time in the very tight construction schedule to test any equipment affected by moving the cables. The geometry of the solution would make a difference. If cables could be moved without cutting them, less time would be needed
• Making sure that any hollow sleepers would hold the rail at the right angle, which changes as one approaches points

All the individual parts of the design are reasonably straightforward; the problems are with how it all fits together. As I said, a true ‘systems problem’.

However I found it frustratingly hard to deliver value using traditional systems engineering methods, such as requirements engineering and architectural design. It felt a bit like trying to use a metric socket set on an old British car with imperial nuts and bolts – the tools were obviously designed for this sort of thing but they did not quite fit the problem to hand.

I formed the view that a large part of this was because the methods were intended for constructing new systems and the problem here was to change an existing system. For some while, I thought that this was a problem which was peculiarly acute in the rail sector but INCOSE members familiar with other sectors put me right. Changing military communications systems has all of the same problems. As another example, an aircraft carrier will stay in service for several decades and will be fitted, during the course of its life, with technology that was not conceived of when it was first built.

To cut a long story short, I had the privilege to lead a cross-sector INCOSE UK working group to investigate this problem further. We have recently delivered our report (which you can read here). We concluded that, while the principles underpinning SE remained the same whether one was building a new system or maintaining an old one, guidance on systems engineering of existing systems could be improved in six areas:

• Through-life Validation: Establishing whether the system and the user needs have drifted apart and some action is required.
• Domain Knowledge: Obtaining relevant facts about the environment of the system to be built.
• Architecture Design: How to change an systems architecture, rather than how to create one. And how to find out what the current architecture is if no-one has written it down
• Incremental Acquisition : Planning out a process which breaks the work down into small bits so that the system can be returned to service after each bit has been done
• Configuration Management (CM): Integrating project CM with system CM:
• Information Management: Maintaining accessibility and modification of information throughout the life of the system

We are fairly sure that each of the ‘gaps’ above is real but doubt that we have got them all. The working group will carry the work forward in 2009 but now with international involvement.

I think this work is important. If you want to be involved or to be kept informed, please let me know.