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.

 The MSc in Technology Management, recently introduced at UCL by the Technology Management Group at the Department of Space and Climate Physics, accepted its first intake in September. Matt Whyndham, the Programme Tutor, reflects on the start of the programme.

The last couple of months witnessed a concerted campaign of activity in TMG, as the new academic year got started with increased enrolments. This year, we are starting a new track in our academic programme: MSc Technology Management. Over the summer period, we had received a good number of applications for this new degree, and 15 new students eventually enrolled in September.

(more…)

Our social marketing droids were running dangerously hot this morning handling a raging Q&A session on twitter @UCLSe. Well, not that busy, but active enough. At the moment we don’t know how much better this is to putting out standard FAQ, so we are thinking about the next one. Here’s a summary of a couple of the more interesting questions, allowed to expand slightly over the 140 characters.

@AilsaPrise : what’s the difference between the established Systems Engineering Management MSc and the new MSc in Technology Management?

This is a good one as they are admittedly in a similar area, so it’s nice to clarify their distinctive features. The main difference in terms of content is in the research and coursework. The new MSc will include a group project in emerging technology (there’s no group project in SEM) – and it is expected that the individual dissertations will also have a different focus. Of course individual projects range quite a bit in topic in the MSc SEM already – but in the new MSc there’s not the need to remain so systems-focused, so it’ll be interesting to see how these research themes develop over time.

In terms of modules, those that are Core (i.e. must be completed during the programme) are different for both MScs, but otherwise students will initially study from the same Options menu – with the exception that there is the new Technology Strategy module in prep that is exclusive to the new MSc. In time we’ll be adding to this menu, but we expect that some modules will remain common to both programmes.

The biggest difference, however, is in terms of delivery. The MSc SEM is a modular/flexible programme and, though it can be studied in a full-time mode, it is designed to be completed part-time while working in industry. Typically students are required to have a few years industry experience in order to come on to the programme. However, MSc TM is full-time only and doesn’t require experience – it is designed to prepare students just starting their careers for employment.

@geoffpknott asked “what are you looking for in personal statements?”.

Marketing droid @whyndham_UCL, aka Matt, who supervises Admissions for our work unit, sees a lot of Personal Statements, and thinks there is a factory somewhere churning them out. So he tends to have strong views.

What he likes to see are some clear things that demonstrate that the applicant has read the prospectus and is applying to the right university (some applicants leave in the name of other institutions!), and has a career plan that looks like would benefit from the programme.

And then there’s an additional, difficult to define, perhaps ineffable factor. This certainly doesn’t come across in the boilerplate statements! It comes down to seeing a sense of commitment from the person making the application.