Girls guiding cats in herds

Here are two more PM/systems blogs.

A Girl's Guide to Managing Projects
Herding Cats

Very observant readers may also note that I've migrated my blogroll from Bloglines to Google reader. It was fairly easy. It's slightly less neat, but it's actually the reader that I use and update now.

SEM surveys

In the UCLse MSc in Systems Engineering Management, of which I am the course tutor, many of the students wish to gather current data about Systems Engineering practices as an integral part of their dissertation research. Here are links to their online surveys, and results where available. Your participation in these surveys is welcomed and valued.

Why should you participate in these surveys?

1. You will help advance knowledge in systems engineering.
   
2. The topics are interesting facets of engineering or scientific work. There will normally be a link to the summary results of the research or an opportunity to be contacted about the research topic in due course.
   
3. Surveys should only take between 10 and 15 minutes of your time.
   

• 29 June 07 : Lawrence Latif is looking at the use of tools and their selection processes. Please take the survey. [SURVEY CLOSED]

All UCLse surveys and research methods conform to relevant ethical practices, including anonymity and confidentiality, and associated data use is governed by the the (UK) Data Protection Act 1998. The use to which data will be put will be described in the introductory text of the survey.

This posting will be updated as more surveys become available. Thank you.

Philosophy of Engineering Design

To the Royal Academy of Engineering for a mini-conference on the Philosophy of Engineering Design.

You what?

Well, apart from the great, good and grey nodding sagely at society's lack of wisdom in taking more notice of engineers, it was a nice little exploration into the essence of design. Creativity came up a lot, but since this is engineering and not art or science, so did usefulness.

What's the use of a philosophy of design? Well, for me, it's as a step ladder off the flatland of business as usual, where we waste energy by using yesterday's processes against today's problems. The activity of philosophy is hard work, but real life should be easy by comparison. Philosophical, or let's just call them abstract, investigations into the nature of engineering processes should tell us why they are working and allow us to guess (it will only be a guess) what the better processes, for tomorrow's problems might look like.

Maarten Franssen showed us, as his comedy slot, the 16th century musket drill (take your fuse...). Taylorism in the military. Not for the first time I bet, it reminded my of Chinese martial arts forms. And Nelson had a gun drill too. The point of this training is to allow the actual work to go more quickly, without thought. The modern military strategist uses drills too, to close the OODA loop and to tailor processes rapidly.

ISS safety/threat analysis

A small wobbly hut 200 miles from anywhere, with a hazardous environment behind every door, wouldn't be my favourite place for a lab. But you know, those in the BAS or in submarines just have to put up with it. Technical strategies and management plans to deal with risks and hazards have emerged in these fields over time.

Here's another wobbly hut, far from anywhere, which sometimes acts a research station but is these days probably best regarded as a demonstrator for plans to go and set up huts even further away, like on Mars.
The owners have just released a summary of a safety investigation and risk analysis for the station. Very interesting reading - 4 MB PDF. For the impatient, they are worried about what we worry about: dust and bugs.

Scanning the horizon

Back from a short break in not-quite-as-hot Cornwall, after a blazing week in which there was a substantial UCL/MSSL stand at the sweaty Farnborough Air Show. Some of this featured the newly established Photonics Knowledge Transfer Network, some of it the activities of MSSL in general, and some of it the activities of our Technology Management Group and the UCL Centre for Systems Engineering. Here's the UCLse poster on the left (I'm quite proud of the background photo):



The value of this activity to us comes from being visible to the community (we were placed in the International Space Pavilion), and at the same time as being in a good position to look closely at other activities and possible partners for future collaborations. To catch fish, you have to go fishing.

On my routine trawl through news items, I saw that Sarah Bell's MSc in Environmental Systems Engineering made it to UCL News. Disclosure: this MSc is linked to our MSc in Systems Engineering Management. The second photo above is from the launch event for the MSc.

The spin this time was the association with tribewanted, and how students on the MSc would get involved in studying enviromental problems on this island community. Sounds like a set of extreme projects as well. It would be good to see how groups of people – presumably untrained in PM skills – organise themselves in that situation, and to write about it from a formal PM perspective.

Sarah also admits to having a blog, Cyborg Engineers, which despite being rather dormant looking, brings us the zeitgeisty concept of "Dilbertian frustration with management". She doesn't specify whether as subject or object of the verb!

When do you use a proper diagram?

It's like I keep saying, it depends. If you want to tell people about something, and don't want no argument, you should probably draw it up neatly in a language they understand.

Visual grammars are somewhat mysterious though, as the following example will I hope show.

If you want to work something out visually, a modeller is going to want to use a live, computer-based representation of their problem. The richer the better as far as a modeller is concerned. They are happy to learn the details and spend days playing with the configuration of the diagram. Being a proud sort, they will bring it to the meeting and say look at this, play with it. I've seen instances of this where the above-average-intelligence audience have been interested in the problem, wanting to contribute, but have been struck dumb by the strangeness of the notation. Uh dunno, you do it mate report back when it's finished. Next Agenda item please.

Tragic. The investment in learning visual language is never made properly.

That's why I like stealthy visual grammars, that emulate the anything goes world of the flip chart and sticky note. They are much more amenable to debate and contribution.

If you want to involve people in a group, you need a visual language that's approachable by them. You can't just say "oh it's UML, get with it", you have to make allowances.

Take a look at Nick Duffill's these two diagrams from the Beyond Crayons blog (also refers to Patrick Mayfield's little article on visual mapping in Systems Thinking).

See how in Nick's comparison, the second diagram looks more rigid, and less likely to be argued with. He also makes the point that the tree-like diagram obviously goes somewhere (the Outcome) rather than its wiggly predecessor.

Incidentally, he calls these Open Systems and Closed Systems but I don't think that nomenclature is quite right. He's referring to whether the system state evolves as a whole or whether things keep going forever. Essentially one diagram shows forces, and no state, and the other shows some forces, and a big change of state. Different objects, as well as a different grammar.

Very often these models are faulty on first presentation, but somehow the apparently finished state - signalled by the neat lines - is off-putting. The reaction could be "that's a bad model take it away" rather than "you missed this bit out HERE let me fix it".

The J Curve: The Dichotomy of Design and Evolution

Fascinating post on fundamentals to do with Design as we know it vs. emergent paradigms such as GA-driven problem solving.

The J Curve: The Dichotomy of Design and Evolution

Steve Jurvetson is mostly taking about how to do it, how to get a big system off the ground using parts that are designed and parts that are brewed. The interfaces, aargh the interfaces. Every surgeon knows that evolution gives you beautiful functionality but messy interfaces.

Steve presents these two as divergent paths, but I think I'm more hopeful for success in integration of the two styles of technology. I'm not sure why, but I think Layers and Architectures are significant and helpful.

We could add to this another dimension of systems engineering - the Verification/Validation stage. Many of the patterns that have been establisehd in systems engineering rely on transparency of design. Given an evolved system, or even a designed system containing an evolved system, how do you verify the integrity of the system if you can't inspect the drawing or the code?

Or what if the system itself evolves in use, such as an automonous array of communications routers, or a fleet of spacecraft? How can the safety of the users be assured?

We need to look at tending gardens, using animals and employing people for models of how organisations use evolved resources in systems. Track record and training will be as important for machines as it is for people and organisations.