I recently read an article on the Nesta blog “Fall in love with the solution, not the problem” which is a phrase to immediately get a system engineer’s interest.

I’ll immediately say that I’ve not worked in the development sector and so I’m not going to comment on the efficacy of the proposed approach in that context, but it did get me thinking (particularly the diagram ‘3 possible strategies for problem solving‘) about lifecycle models in general.

The first strategy, a problem focused approach, is what some might say Systems Engineering espouses. The traditional lifecycle model of choice in the SE world is the Vee model.  If you simply assume that the left hand side of the Vee is a linear process then it would indeed look like you spend a lot of time fully exploring the problem and then move on to creating a solution to solve the defined problem.

But the Vee model is just a model, and like all models it is an abstraction of reality. It is useful in providing some scaffolding around which systems engineers can communicate, but competent engineers will recognise that there are many subtle nuances that come to play in the real world. They will also recognise that this is not the only lifecycle model and will be able to blend lifecycle thinking and mix elements of different approaches as appropriate (e.g. based on development risk).

These models can also be useful education tools in that you have to get people on the first rung of the ladder of understanding before showing them the possible complexity in application. (If you want to read another author’s views on the Vee model then try The Design of Design by Frederick P. Brooks Jr. It should certainly get you thinking even if you don’t agree with all he says.)

If we consider the process of architecting within this stage of the lifecycle then authors such as Maier & Rechtin (The art of systems architecting.  CRC Press 2009) show a process model that includes parallel activities of problem structuring and solution structuring. And if we consider an approach such as the Seven Samurai of Systems Engineering (Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004) then we recognise that not only do we have to consider the ‘solution’ (system of interest) but how that solution is created, how it is supported and maintained, and how the solution will change the context into which it is deployed (which might create new problems to be solved).

This implies fully immersing yourself in the context where the problem/solution exists, and engaging with the wide range of stakeholders that are, or will be, concerned with the solution once deployed. A design on the bench is not the same as a design in the environment where it is meant to operate. It also means understanding what already exists and the benefits and challenges of those existing solutions.

When I think about it in these terms, then what I understand as good systems engineering starts to look more like the co-evolution approach (at least in the pictorial form) from the Nesta article.

As always, these thoughts are my own and thoughts can change with time and additional input. So please feel free to comment and add your own perspective.

UCL’s Mullard Space Science Laboratory (MSSL) has won a major 2 year contract to provide space systems engineering training to the next generation of systems engineers at the European Space Agency (ESA).

MSSL’s Technology Management Group will deliver the training at a venue close to ESA’s European Space Research and Technology Centre (ESTEC) in the Netherlands, with a team primarily consisting of Dr Michael Emes (Programme Manager), Ian Raper and Dr Doug Cowper.

Dr Emes said: “We are excited to be able to continue our relationship with ESA, following on from the successful project management training now in its 2^nd year. Winning this contract is a testimony to the quality of the training we offer, the strength of our staff in the subject area, and recognition of the strong space systems engineering heritage at MSSL.

The UCL Centre for Systems Engineering, hosted within MSSL, has been training systems engineers for over 17 years through its MSc programmes and directly to industry with clients in many sectors. We will be drawing on all of our experience in both teaching and space systems engineering, together with experts from ESA, in order to ensure that this development opportunity works in supporting the delivery of ESA Agenda 2015. “

The major part of the training will be aimed at ESA staff who are technical discipline engineers, space scientists and new appointed system engineers. We will also be delivering targeted training for space systems engineers with several years of experience looking for the latest trends and techniques in systems engineering.

The ESA Space Systems Engineering Training Course is being carried out under a programme of, and funded by, the European Space Agency. The view expressed herein are those of the UCL Centre for Systems Engineering and can in no way be taken to reflect the official opinion of the European Space Agency.

The recent issue with emissions testing has highlighted a few issues which are very important within the field of systems engineering, and indeed engineering in general.

The first is ethics, and is one that is considered important by the various professional bodies representing the engineering professions. For example, to quote from the Institute of Engineering and Technology (IET), “Being a professional engineer means that the wider public trust you to be competent and to adhere to certain ethical standards”.

We have to question therefore how the ‘cheat device’ software was able to be present in and used in operations of those vehicles. There is various speculation in the press about these matters and it is not the purpose of this article to comment on such media reporting. It can be presumed though that engineers either chose to, or were coerced into, making use of the functionality of the software designed to aid with factory testing beyond this design intent.

The second issue relates to the risk culture of the organisation. Did anyone in the organisation make the association between the inappropriate use of this software and the potential impact of it being discovered. In risk management terms this event would probably be hoped to have a very low likelihood (i.e. they hoped they wouldn’t be found out) but the consequence was always going to be huge ($billions wiped off market value, massive lost of trust in the brand). Was this assessment of the risk ever made, was it captured, and if so how far up the organisation did the risk review go?

Organisations are complex systems in their own right, and the culture of the organisation is an emergent property of the interactions of the various parts (management, departments, employees, suppliers, etc.). Culture can also be affected by a reinforcing feedback loop, i.e. behaviour begets the same kind of behaviour. So any review of the organisation needs to recognise these factors.

This is just a very brief highlight of the complexity of two of the issues that surround this situation. It will be interesting over the coming weeks, months and even years to see whether the true root causes are identified and addressed. It is a useful wake up call to all organisations that ethics are important and that appropriate risk management might help avoid making the worst decisions.

Within the world of projects there is a phrase that says “what gets measured gets managed” and whilst such one liners can be used as a lazy justification of poorly thought through management techniques, if we explore the meaning more deeply then I think it reveals some interesting points.

The first thing I’d observe is that the saying is broadly true. It’s like shining a torch beam on something, and when others can see the areas being highlighted then they will focus their attention there too. This can be both a good thing and a bad thing. Are we sure that we are shining our torch on the right areas, and are we confident that those areas left unilluminated aren’t adding unacceptable risk. Is there a monster growing in the shadows that will leap out and bite you further on in the project.

An important thing to think about now is what you are measuring. Projects are frequently driven by the achievement of milestones and this is taken as a measurement of progress. But I have seen many projects where the milestone is simply the delivery of a design artefact, e.g. “have we delivered the systems requirements specification”, and the milestone on its own tells us nothing about the quality of the deliverable. It is the quality of the deliverable that is the true measure of progress (i.e. the maturity of the design) and not the existence of the deliverable itself.

Significant design milestones of course tend not to be just the delivery of a document, but are also attended by an in-depth review. Provided the review is well conducted by staff competent in the area then poor quality in the design should be trapped and actioned for correction. But the risk is that we become reliant on the review to perform this function rather than building it in to the design process. And of course if we only detect poor quality at the review then we are already late. One way of ‘building it in’ can be through appropriate measurement.

So what is ‘appropriate measurement’ if it’s not just about delivering ‘things’? I believe it’s about thinking what the desired outcome of the ‘thing’ is and trying to develop measures that can monitor the progress towards that outcome. Measuring something of the quality of ‘things’ is much harder than measuring the existence of these ‘things’, but these are the only really meaningful measures.

So, an example may help. In a previous role I was responsible for delivering the Strategy and Process Improvement programme for our department and this required a rigorous approach to measurement (for which we happened to have selected the balanced score card approach,  but I won’t dwell on that in this post).

One area of improvement was in our relationship to our customer, for which we developed a series of training materials to develop the staff in this skill. The leader of improvement activity proposed measuring the delivery of the pack of materials and the number of staff who had been through the training. I argued that this would tell us nothing about our progress towards actually improving our relationship with the customer. This outcome of course is much harder to measure, and the data that is available (e.g. number of customer accolades) may be the result of a number of actions that the business has taken, but it is still this outcome that the business really cares about.

This example illustrates the tension between those who are responsible for delivering products, whether that is individual process products or the overall project, and who many want to measured on delivery of the thing and those who understand the responsibility of delivering the ‘thing’ that meets the stakeholders needs.

I will mention here as way of concluding this post that the International Council on Systems Engineering (INCOSE) has developed a product called the “SE Leading Indicators Guide” which has provided some possible ways of measuring the activities of a complex engineering project, and provides plenty of food for thought.

Yesterday I had another opportunity to deliver my course on Developing the Engineering Management Plan for Complex Systems Projects and, in discussion with the delegates, it has once again reinforced for me the importance of thinking in the early stages of projects.

It seems that my own experience is echoed by others that too often the detailed planning of the engineering activities consists of getting the plan for the last project off the shelf, updating it to reflect the new project and then putting it back on the shelf. Of course that is a very wide broom I’m using and I am aware that there are shades from no planning to very detailed planning that happen in industry.

When you consider that around 80% of the final project costs are committed in the first 20% of engineering activity you would expect that more effort would be put into planning how to make best use of those early activities.

The problem is that this means

• thinking through the entire lifecycle of the system you’re designing, from cradle to grave
• working out all the risks to success that might hit you along the way
• figure out what you need to do to reduce or remove those risks
• work out whether you can do those things given the constraints of your project, and if you can’t then figure out what residual risk your project carries
• understand what value each activity is adding to move you towards success, which means understanding the principle behind doing the activity
• understand how all the activities interrelate and how they sit in the wider business context (the project is a system too with functions and interfaces so needs to be understood in the same way)
• figuring out the methods and tools you’ll need to do the activity and the skills of the people required to deliver the desired outcomes
• and then working out how to measure progress, not in terms of deliverables (like the system requirements document) but in terms of real outcomes (such as the quality of the system requirements).
• and a bunch of other stuff too…

Which is a lot of thinking. But if you don’t do this then really you’re walking blindly into your project with wishful thinking that everything will be OK.

Then you need to re-evaluate and update the plan at least at every major review point. It’s like a navigation plan. Events will blow you off course and you need way-points to check whether you’re still on track or need to adjust your plan to reach your goal.

The development of the Engineering Management Plan is also a great opportunity to build a shared understanding of the project with the team. Used intelligently the plan should greatly ease the journey of design and development of complex systems.

We were recently invited to participate in a bid to provide consultancy to an organisation. They are looking for the work of consultants hoping to gain a step change in their own capabilities when confronted with their very difficult business challenges.

This call for proposals made me think, what are the necessary conditions for external consultants to be effective in their contribution to the management of an organisation and how do we understand their input in terms of the systemicity of the organisation?

Sometimes consultants are brought into organisations when they are faced with very difficult problems and feel surpassed by the situation or somehow unable to resolve it. I wonder if the idea of solving some difficult problems through consultants can be seen, under certain circumstances, as a ‘disturbance’ that shakes the organisation into new areas that take them to find better answers. I would argue this is a problem that can be partly understood as an optimisation problem when you are searching for the most appropriate variables and their most appropriate combination to find the optimum of a function. Here the problem is the most appropriate way to deliver a complex project  (for example) and the variables are the exact number and identity of the resources (with their capability) involved. The function to be optimised is the business performance metrics. Of course, the situation arises not only when we get to the point of bringing in consultants, sometimes organisations face difficult problems and embark on solving them themselves. But the question is still relevant, if the organisation is a system, is the consultant (or the ‘hero’ within the organisation) anti-systemic? are they part of the system even if their participation is sporadic and is not in keeping with the internal dynamics? Or are they perhaps just bringing to light dynamics (or parts) of the system that had not been identified? Finally, is there anything we can learn from the field of optimisation in maths and search algorithms (in numerical computing) that we can transfer to the management and design of complex systems, including organisations?

It will be nigh on impossible to transfer directly an organisational problem to a numerical optimisation problem because many of the variables at play are non-quantifiable, being of a human nature. Nevertheless I reckon making the analogy with numerical optimisation gives you a very good chance of understanding the underlying and overarching dynamics of the organisation.

Just systems thinking…

Although there are some that choose to study full-time, most MSc Systems Engineering Management (SEM) students are professional engineers in full-time work. It’s not an easy option – balancing work, study and your home life – so why do it? I’ve been asking myself this question a lot recently as I am also in the middle of a part-time programme – in my case an MBA with the OU. Having taken an eighteen-month pause when starting with UCLse, it’s now time to get on and complete it.

Even though I’m just over half way through I still had a lot to think about in deciding to get back to it. After all, half way means at least another eighteen months of studying after work and at weekends – more, if I pace out the modules a bit. I have to admit I don’t think I’ve found a killer argument for doing this, though I’ve discussed it with a lot of people. Often the horror of having to put yourself through more exams is mentioned and it’s true that’s not greatly appealing. What I’ve found harder is the discipline of continuously doing the extra study throughout the course. A 15-credit module is equivalent to around 150 study hours. With work and personal life going on, that implies quite a commitment every week, even before you throw in some family holidays and life’s little hiccups (obviously, just how much depends on the length of the course).

Despite this, I’ve still been motivated to continue as I’ve found that there’s so much you get out of it even as you go along. I was initially surprised how much the study could have an immediate impact on what I was doing work-wise – and of course this only builds as time goes by and you get more experience. Though I didn’t know it when I started, I think that’s now one of the key justifications for me, in addition to having the qualification when I finish.

What do you think about the part-time study experience?

For more information about the MSc Systems Engineering Management course and how we support our part-time students:
http://www.ucl.ac.uk/syseng/pg-taught/sem

This week will see the launch of Sentinel 1, a radar imaging satellite designed to deliver land and ocean monitoring services. If you would like to know more about the mission you can find that on ESA’s mission page https://earth.esa.int/web/guest/missions/esa-future-missions/sentinel-1

Before joining UCL I worked in the Earth Observation, Navigation and Science division of Astrium and I was heavily involved in the mission and systems engineering of Sentinel 1 in what is known as the Phase A-B1 studies. In ESA parlance Phase A is when the feasibility of a mission is studied. This primarily involves finalising the statement of need and proposing candidate solutions to meet the needs. Phase B is then the stage of coming up with a preliminary definition of the mission checking that the proposed solution will be able to meet technical requirements and that this can be done within schedule and budget. Phase B1 specifically delivers the system requirements that can be carried forward in the project.

One of the most important activities within these stages was the development of the Mission Operations Concept. This involves thinking through all of the periods of operation, so that is launch and early operations, nominal operations, non-nominal operations and eventually disposal. Thinking about how the mission is expected to operate in each of the periods really helps to define the mission architecture, i.e. the way the spacecraft, the launcher and all of the systems on ground that communicate with the spacecraft work together, and then helps ensure all the necessary requirements to enable the operations are captured.

The operations concept also proves to be a very useful communication tool between the many stakeholders involved in the project including the various technical experts from the customer, the industrial space segment team and the industrial ground segment team. By talking about how it is envisaged to operate the mission the various different viewpoints (e.g. the best way to do it from a spacecraft point of view and the best way to do it from a ground segment point of view) can be discussed and traded-off eventually leading to a decision that should work for everyone and delivers the mission objectives.

So for me the operations concept document is one of the most important systems engineering products and should be started at the earliest possible opportunity in a complex system project. It aids architectural definition and requirements capture but perhaps most importantly it facilitates better communication amongst the people designing and developing the system which should lead to a better outcome.

Our MSc in Systems Engineering Management has been running for nearly 15 years with great success.  Throughout this time the course has evolved to meet the requirements of our students for a course that incorporates up to date material and is relevant to their careers.

One piece of feedback from current students, which we have recently acted on, was that if the course were accredited by the IET (Institution of Engineering and Technology) then it would help them achieve CEng registration.  In addition, some potential students have told us that they would be more likely to enrol if the course were accredited.

So over a year ago we embarked on a project to seek accreditation for the course.  It has been hard work, especially through the summer when we had to prepare all the evidence required and submit it to the IET.  Also, during this process we identified ways we could improve the course, which we have now implemented.

In November 2013, after reviewing our submission, a panel from the IET visited us to meet our staff and students and ask us lots of questions.  The panel “found it to be an excellent programme highly valued by the students, some of whom had senior positions in industry and found the material very relevant and useful” and “the programme is also highly valued by industry”.

We had a small number of requirements that needed to be addressed, which we responded to in an action plan, before we were told that our application had been successful.

As a course team, we are delighted to have achieved IET accreditation, as we hope will be the many past, present and future students who will benefit.

This blog is owned by the UCL Centre for Systems Engineering (www.ucl.ac.uk/syseng). UCLse is a centre of excellence for Systems Engineering and the Management of Technology Projects. We balance the practical application of systems engineering in research and development projects with investigations into how to advance the practice.

This blog will contain posts from our staff on matters of interest to the world of systems engineering and technology management. We’re likely to cover thought pieces, basic principles and understanding, commentary on events in the world around us and matters related to education.

We are also active on twitter , LinkedIn and Facebook