Capacity Optimisation

A brief rant on my other blog about trains, hence Capacity Optimisation.

As cycling swells in popularity, some decisions and assumptions made about 10 years ago on the design of train carriages now have noticeable effects. This sort of effect happens all the time, and it's frustratingly hard to see emergent properties like this, let alone model them.

Birth of a System - London Cycle Hire

People in London can't have failed to notice the introduction of a new transport system lately - the Cycle Hire scheme. At the time of writing it's roughly a month into operations. For the uninitiated, there are roughly 400 docking stations around town, each housing up to 20-30 bikes. Registered users present their dongles, unhook a bike and pedal off. At the other end, the bike is re-docked, and, in a database somewhere, a small charge is incurred. (More intro, Guardian, July 2010)

Some things I've noticed, and some questions.:

It's obviously a multi-element system: Bikes, Docks, Terminals, Back End Data, Billing, Logistics. It's additionally part of TfL's great big system-of-systems. It's got the Mayor's Office paw prints on it, but clearly has been in the works for years. It couldn't have happened, without Paris and a few other prototypes. Expect to see more in big and small cities round the world soon.

There are sprawling requirements everywhere, not completely understood. Here, for example, is a story about an odd feature of the database that caused the owners to back-pedal on a particular function, the multi-key account. Is the development cycle capable of adapting to new, or recently clarified, requirements? My guess is that, oops, the database contract has been and gone, and this feature will sink, rather than be implemented properly.

The initial users are enthusiastic, communicative, and alive to the possibilities it offers. Has this resource been tapped into? The forumites all want to talk to TfL and Serco (for it is they) but I suspect the drawbridge is up.

Data! There are plenty of feeds that allow the growth of applications (and, of course, Apps) to entertain and inform the users. Here, for example, is Oliver O'Brien's visualisation of real-time Dock status. (Oliver is a GIS nerd at UCL, but I don't otherwise know him). Here's another of his, showing daily stats, for example. Note how system availalbility is about capacity of both Bikes and Docks at each end of the prospective journey. Unlike a little French town (Lyon? Paris?), London's scheme is being used a lot, in two daily peaks, by edge-to-centre commuters. Machines and Holes are both at a premium at critical times. Has all this been modelled?

The contractors and operators aren't saying much for now, other than "we are working on the best way to do things". Do they mean us?

Originally Posted at Systems Engineering on KTN _connect.

Issues and Risks : philosophy of Present and Future

In Project Management, the concept of a Risk is fairly well established.

"An event, which, if it occurs, will have an effect on the Project's Objectives".

So if it's a harmful future event, we would note its likelihood, impact, and causes, and seek to manage it. By doing so, we reach into the future and handle it so that it does not impact the present in a way we would not wish.

Whereas an Issue is defined, at least in the APMP syllabus (PRINCE2 and PMI may differ on this definition) as

"a threat to the project objectives that cannot be resolved by the project manager. ... issues have already occurred and are therefore not uncertain".

APM Body of Knowledge, 5th Edition.

In teaching this, we fall into a sideline. Students ask: what about future events that are nearly certain. Aren't they also Issues? or Risks with very high probability? or just issues? Since escalation at the proper time is a key result of the Issue Management process, we should have a clear answer. We can reply by saying that the cause of the event was in the past, whereas the manifestation of the problem could be in the future. That satisfies some people, but not entirely. Then I saw this:

"Modern Western culture has absorbed the threefold Greco-Roman concept of time as "past" (that which has gone before), "present" (that which is), and "future" (that which will be). It is easy to associate these concepts with the three Norns Urdhr, Verdhandi, and Skuld. It is also incorrect. The Germanic time-sense is not threefold, but twofold: time is divided into "that-which-is," a concept encompassing everything that has ever happened - not as a linear progression, but as a unity of interwoven layers; and, "that-which-is-becoming," the active changing of the present as it grows from the patterns set in that-which-is. That-which-is is the Germanic "world," a word literally cognate to the Norse ver-öld, "age of a man." One will notice that even in modern English, there is no true future tense; the future can only be formed through the use of modal auxiliaries. For the Teutonic mind, all that has been is still immediate and alive; the present only exists as it has been shaped by the great mass of what is, and the future only as the patterns of that which is becoming now should shape in turn."
- By Kveldulf Gundarsson, Tuetonic Magic, p. 24.

Seen in Cloud Hands, Mike Garofolo's blog about TaiJi.

I can see the same dichotomy of viewing the future/potential in the way Risks ("that which is becoming") and Issues ("that which is") are treated. To put them in the Graeco-Roman mould of Future and Present seems to create difficulties which are avoided, to my mind, if we instead follow the Teutonic pattern. Ja?

July Roundup

Organising for Work, by Henry Gantt

PMIBOK is NOT a Methodology

Education vs Training

Silicon Beach Training

Trading off Cost, Schedule, and Technical Performance is a Ponzi Scheme

The Lazy Project Manager

Ranking Risks: Rare to Certain, Negligible to Catastrophic

How To Estimate Better

Misison statements and all that

I quite liked this post from Signal v Noise about crappy mission statements. Are they a US disease?

Some of my colleagues seem to think so. Furthermore, such drivel causes as much distress for the inmates of such organisations as for their supposed customers.

Invention by Design, Petroski

Henry Petroski, Invention by Design
Harvard,1996

Henry Petroski has written a number of books that cluster around the craft and process of engineering. This one sets out to illustrate the inventive process of engineering design. I picked it up hoping to know more about innovation in other fields than my own.

In the ten or so case studies presented, the theme of the problem-as-impetus clearly emerges. Engineers, as critics of existing products, are driven to devise further inventive steps to reach toward a more excellent product. With some exceptions (the Boeing 777 case, which although probably the most contemporary, seemed to be lacking an undefinable quality of fidelity: does he really get what's going on there?), the cases revolve around the thoughts and craft of individuals. In some cases (the drinks can) their identities are obscure, whilst in others (the bridges of San Francisco) they spring from the pages dramatically. Exhibitions of patent documentation provides the bare bones, Henry P re-constructs the whole animal.

It's also clear that teams of engineers, or even distant collaborations, don't simply progress by cutting through an underlying bedrock of physical properties to get to the solution they seek. Rather, at each inventive stage, a higher order product, an improvement from the last, emerges from a mist. Thus we step from toggles to buttons, thence to what must have a been a nightmare of "automatic" clothes-tieing devices, to the zip as we know it. A series of hops then to the Ziplok bag, and yet another string of manoeuvres to Velcro.

But perversely, despite each invention begetting more invention, at the same time each enlargement of the scope and scale of the products seems to make it harder to analyse the next-generation design. Boeing's exponentially growing development budgets attests to this. Not all of the added complexity comes from within the product though, as there are network effects and social or legal changes concerning the use of the products that add further layers of requirement to each iteration.

The idea of resources as enablers, such as materials or tools, for certain types of design activity is also strongly exposed. He exemplifies this all through the book, pointing to CAD as a key technology for Boeing, standardisation for the Crystal Palace among many others. He seems to be too early to notice much use of computing in architecture though.

The chapter on buildings as systems shows how the problem complexity rises with each generation. Perhaps there is an inherent bias in these works, forgetting the industrialisation of innovation in mundane structures. The wonder of the local supermarket, reproduced thousands of times, as opposed to the award-seeking skyscrapers of the capital.

He uses terrorist attacks on the World Trade Center as an example of resilience of design. He refers of course to the 1993 bombs in the basement. What would he make of the later total failure of the designs in 2001, and was this indeed a failure of that particular building as a system, but a failure of a wider, un-designed system?

New Technology Disaster

Here's a story about waste from the streets of England. Generally speaking, the streets of the Kingdom are not strewn with rubbish, by international standards. The systems and infrastructure to support the removal of our wastes might not be the best possible, but they are pretty good.

It wasn't always. Go back a century or two, and you really would be looking at serious daily health hazards, not only in piles of discarded household waste, but also human wastes. Remember the Great Stink? Not many do, that's why I'm glad to plug UCL's Stinkfest.

But I digress. What happens when technologists look at systems for economically collecting waste, with the added requirement of wanting to incentivise waste reduction. This is a new requirement by the way. Back when you could throw everything away, you could run waste as a reactive service. Nowadays there is no "away", and the economist's response is to put a price on waste. From a local council's point of view, this makes sense. Bin-men cost money.

Enter technologists. Let's weigh the bins as we collect, and send you the bill for massive wastefulness. Sounds good, except even if it works in Germany or Shangri-La, it will need installing here. By "it" we mean weighing arms, identifiable bins or houses, recording systems, billing systems, training and all the rest of it. Not a light bulb then, but a complex system. You can expect databases to grind, for people to be standing in the wrong place, and for the odd bit of hardware to get broken. Worse than Terminal 5 on a good day, just like all perfectly normal field tests of things which looked fine in the lab.

Two stories from the press, following a halted trial, (not even a "pilot") in Norfolk:

Daily Mail (hates the government for messing with the bins, and god knows what else) "disaster, devastating blow for the scheme"

Guardian : "Schemes to go ahead"

Partly, these trials got media attention because of the RFID angle "they are spying on our bins, haven't they heard of the Magna Carta?". What most irritates me, aside from the axe-grinding of the Mail, is the complete lack of technological nous. It's obvious to me, admittedly now after years of exposure to the field, that the newer and bigger the tech the more carefully it will have to be prototyped and worked out locally before going live. So it's a "disaster" then? The local Tory MP cheerfully jumps on and pronounces left, right and centre, and tries to shake of the "government-imposed scheme" (the local council would have creamed off a good wodge of the Government grant for trying this out on their patch, and would have been in the front line for savings from a live scheme).

The Grauniad's report on the other hand isn't really looking at the technical risks at all, but sells it as political battle, showing the government's deafness to its critics. It's just as blind to the systems development issues.

The Mail could still be right, there could be serious system-level difficulties with this system, and they could be unique to the UK, or indeed South Norfolk. We just don't know reading these reports.

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.

Architectures and Organisation

In this post (and its predecessor) David J Anderson speculates (in his Agile Management blog) on how Lean ideas and product architecture play against each other.

It's pretty obvious I think, that when you have a team of organistions working on a product, some of the decisions about the architecture and interfaces of the product are determined by the organisational structure of the team, and that a different set of partners working on the same problem would develop a different architecture, for management rather than technical reasons. This is entirely legitimate by the way, and working out the best route is part of the function of all technical managers. Sometimes the organisation will be shaped by the product, and sometimes vice versa.

Anderson's thoughts are directed toward Lean, or Agile development, and how that imparts further gradients onto the decision space.

Irregularity

See that? Evidently Word can't cope with too much irregularity. Which is what this paper is going to be about: Extreme Projects, what they are, and how we might manage them.

Requirements resources

I'm becoming involved in Requirements Engineering (RE), as it is now known, on numerous fronts, including a module for our MSc in Systems Engineering Management. This relates in many ways to the front-end management issues that I've written about here previously. Consequently, I'm in knowledge acquisition mode.

Our requirements tutor, Anthony Hall, hopefully won't mind me mentioning that Ian Alaxander's site is packed with great book reviews including many on RE.

More requirements-tagged items: requirements

Tufte Forum

Why hadn't I seen this before?

Edward Tufte's forum on visualisation issues, including Project Management graphics and the terrible Gantt chart. I scoured the latter for inspiration on the strategic project visualisation idea – previous post. Lots of ideas but mainly too tactical.



Check out Sparklines "word-like display of data": nice example here at NASA Ozone Hole Watch (that sounds so much more urgent than Ozone Layer Survey). They say this is sparklines-inspired rather than the true in-text sparklines.



Here's a more on-message sparkline from a company called Bissantz, who do software to create Truetype fonts for this.



The latter also claim to implement yet another bright idea I had in the bath – audible data playback! Should we call it audioisation?

Several of the Tufte forums are going straight into the feedreader. For one thing, I'll know when his new book will be ready.

Strategic process models

Strategic thought about future projects needs to be accurate, but because of the innate uncertainties the area is resistant to usable models.

Why model strategically? I'm looking for some way of preparing thought at the stage of the business case (the full one not the bean counter's profit statement) or the research proposal. We need to know what's connected to what, and what gaps exist. We need exact knowledge of uncertainty. We don't want to commit to tasks and sequences yet, but we do want to shake out the structure of organisational relationships with the underlying technology.

The tactical level is well-trampled, principally by the Gantt chart. For discussion of some of its deficiencies and some possible alternatives, we'd better Ask Tufte. However, the strategic, beginning level of projects is airy fairy whiteboard stuff, the fuzzy front end.

Snagged from a somewhat random US army document about process modelling.

This is the commonly used ICOM model, a Lego brick of many process model formalisms. I'm trying to think how it could be used in a strategic-level project modelling system.

Inputs and Outputs of generic activities are obvious elements to model, but we don't want to imply that a task is done once. Rather like a diagram of body parts, we want to infer circulation and iteration of knowledge and materials between connected parts.

Instead of Mechanisms and Controls, we can use the vertical faces of an activity node to represent Resources and Constraints respectively. We can utilise this in a mapping scheme to show contributing organisations arrayed along the base of the diagram and customer/external organisations in the upper part.

Ideally I'd like to connect this to hard data (tables) about the connectedness and certainty of each of the elements. I'd like to take the drudgery away from the drawing aspect, and have the ability to do basic traceability and completeness analyses on the strategic model.

Sound good? Next week I'll draw a few.

New APM Body of Knowledge

After a long gestation, the APM have published an updated Body of Knowledge. It's much improved over the previous version, and contains helpful notes and references on a wide range of project management topics. Material on Strategic management of projects, Issue management, Technical/Technology management, Processes, Governance, Learning and Ethics have all been added now, and the majority of the rest upgraded and updated. In other words, it's useful. The only snag is how you get hold of it.

The APM Body of Knowledge 5th edition has been written by practising project managers for practising project managers. It is designed to support frontline practitioners, consultants, advisers, senior managers in project-driven organisations, trainers, students, researchers, authors, publishers, librarians, information specialists and knowledge managers. It is used by the APM as a foundation for its membership, professional development and knowledge services.

ISBN: 1-903494-13-3
APM Publishing Bookshop

You can have a taste of some of the underlying definitions on the main APM website (PDF here), but basically they are charging money for the main dish.

I personally think they should be propagating this quite freely, since their membership route is now linked to an examination of this knowledge. I suspect many training providers may amortize the cost of the publication into their fees!

(Disclosure: I work for an organisation providing APM-accredited training.)