Book review: Learning for Action (SSM)

I’ve just finished reading Learning for Action by Peter Checkland and John Poulter (2006).  The book is an introduction to Soft Systems Methodology, or SSM for short.  Now I’ve read the book I have an understanding of what SSM is, how it might be used and why it would be useful.  I’m not about to run out and do any SSM but I now know when I might find it useful.

The book is well written and short – always a positive feature, although a little on the expensive side.  It is intended more for students than the casual readers but this doesn’t get in the way.  I think I made the right choice by starting with this SSM book rather than any other.

So, why did I read it?  Two reasons really.  First I’ve been talking about “Systems thinking” with some people and was wondering “How do you do it?” so I wanted to know more.  SSM is itself a form of systems thinking.  Second, I’d come across references to SSM on several occasions in the past and always meant to go back and read up on it so this was my chance.

Normally I run a mile from anything that claims to be a Big-M Methodology but on this occasion I’m quite impressed.  I think this is because SSM is very self-aware and the authors know the dangers of Methodology.  The roots of SSM are in Systems Engineering and related fields like Operational Research, the authors respect these fields but it was through recognising the limits on these techniques that SSM came to be.

So, despite my fear of Methodology I think this methodology looks useful in helping people step outside their normal environment and consider that environment from outside.  As such SSM facilitates and triggers learning – hence the title of the book.  It turns out that SSM is also a form of Action Research which is also from where Appreciative Inquiry began.  Once you know this several things fall into place, for example, SSM does not addresses “problems” but “problematic situations.”

Having read this I hope to have the opportunity to get involved with an SSM exercise in the not too distant future.

 

Business Patterns update

Back in July I took my latest work on Business Patterns – or Strategy Design Patterns for Technology Companies to give us a more descriptive title – to the EuroPLoP 2006 conference.  I got lots of good feedback on the work and I’ve finally had the time to finish updating the papers and post the revised versions on my website.

There are two papers:

I’ve now collected quite a few business patterns and added some theory to support them – all available on my website.

What I should do now is compile all these papers into one PDF for easy access – and to cut out some of the boiler plate duplication that ends up in each paper.  That would also help me with the administration of these papers, I’ve run out of titles so I’m introducing a numbering system!

I had thought EuroPLoP 2006 would mark an end to the development of this series.  Instead I’m thinking about a few more patterns for next year.  There has been a little external interest in these patterns this year so maybe things will start to move.

 

Compare and contrast: Terminal 5 and Wembley Stadium

If you can get a copy of today’s FT do so, there is a full page on the Heathrow Terminal 5 project – you can read it online but you need a subscription.  I’ve written about T5 before, and in truth there is little new in the FT piece that hasn’t been reported elsewhere.  Still, it is good to have an update and know it is still on schedule to open at 4am on 30 March 2008.

The thing that makes T5 so interesting is the approach taken by BAA (the owners of Heathrow) to the project.  Rather than take the traditional construction approach of asking “Who can do this cheapest?”  and load the contract with penalty clauses for the sub-contractor BAA has taken the approach that it needs the terminal to open on time so it has assumed responsibility for the risk and is managing it with innovative contracts.

One of the consequences is that BAA has adopted a number of techniques from the Lean production world.  Consequently the project is on time, on schedule and has a superior safety record than most construction projects.

What is especially striking is when you look a few miles up the road: 20 minutes from my house in one direction and I can be at Heathrow in South West London;  20 minutes in a different direction and I’m at Wembley stadium in North West London.  This project is nothing short of a scheduling disaster.

The British football association (who owned the old Wembley and commissioned the new one) took the traditional approach.  They sub-contracted the whole project to an Australian company called Multiplex – who, I believe, have a reputation for suing people.  This project is over budget, late, getting later and drove Multiplex to the edge of bankruptcy.

Of course the FA are OK, they signed a fixed price deal so what does it matter to them?  Well, it does matter, they don’t have a stadium yet and it was a stadium they wanted not financial compensation.  Wembley has been plagued by missed milestones, strikes, sub contractor problems and everything else we’ve come to expect from big construction projects.

Some people, like the former Government Minister David Mellor, seem to think this is quite reasonable:

The former chairman of the government’s football task force, David Mellor, agreed, saying: “It’s late, but tell me a building project that isn’t late.  This is a major project, and I just think that the fact that it may be a few weeks late finishing, in the great order of things… doesn’t matter tuppence.” (BBC, 21 February 2006)

Well, Wembley is more than a few weeks late now.  Its currently about a year late and has yet to open.  I don’t know is David Mellor has commented on Wembley more recently, or if he is aware of T5 but I’d really like know if he stands by his comment.

So, why make this contrast in a blog that is normally about software?

As I said before, T5 is built on risk sharing and lean principles, that does matter.  Terminal 5 shows that large engineering projects can be undertaken using these techniques and that they work.  And more importantly it shows that these principles transfer from car building to other areas.

 

Book review: Software Ecosystems

Software Ecosystem by Messerschmitt and Szyperski (2003) is a book that was recommended to me about a year ago, a book I bought about 9 months ago, and one I started reading about four months ago.  I’m sorry to say I’ve only made it as far page 77 and I’m putting it on the shelf.

The book is interesting, the book is useful, the book does offer some insights into the software industry, the business of software and how software effects our business.  Yes I have learned things from this book.  The trouble is, the insights and learning don’t come along fast enough.  I feel as though I should read this book, it talks about business, software and the business of software but it idn’t a gripping read.

That I feel this is probably as much of a comment on me than it is on the book.  I’ve been around the IT industry in professionally for 15 years now and I’ve already learned much of what the book has to say.  Unfortunately, I think that is probably true for most of people who have been around the industry for half the time I have.  Certainly, if you’ve spent a few years in ITC and spent some time studying or thinking about the business you won’t find much new in this book.

Which begs the question: who is this book for?

Certainly the book has an academic style, the research style, it doesn’t present new research or long literature reviews, and it isn’t overdosed with references in the way academic research usually is.  So, my first thought is that this is a book for people studying the ITC industry – and software in particular.  It could almost be a text book for a course.

Yet something about the book doesn’t seem aimed at students.  While thinking about the audience I looked at the back cover were one commentor suggests “Marketers, programmers, consultants and lawyers all…” while another says “required reading for any student of the computer industry”.  I think the reviewers are right.

This is a book for people who don’t really understand the software industry and want to.  For such people this is a good book for bridging the divide between the business world they know and the strange world of software.

So, if you are a student who has this book on a course list then read it – or at least dip into it, its probably too long to read in one semester.  If you are a lawyer or a marketer who find they need to work with software people and understand the industry then read it.  But if your have an IT background, and you think about your industry, then there are better books to read.

All change

As some of you may have noticed I’ve been blogging a bit more in the last month.  There are two reasons for this.  First, I’ve started using BlogJet – more on this some other time, and second, I’ve got more time on my hands, my employer has downsized and I’m an ex-employee as of today.  This is a blog that returns again and again to the subject of change and here it is again.  My ex-employer has decided on some changes and those changes effect me. 

On the whole I’m skeptical about the power of corporate management to actually change a company, it always seems to me that the guy sitting at the top wearing the CEO hat has little power to change what the guy on the production line 6 layers below actually does.  I’m not saying you can’t, I’m just more of a believer in bottom-up strategy and change than top-down.  However, you can lay people off from the top and that effects everyone all the way down.

Lay-offs are a very blunt tool for this, sure they are a fast way of creating change but they are also a bit like rolling the dice and seeing what happens next.  You can probably have a fair idea what will happen when you axe an entire department or product line but when you pick people from all over the organization what happens next?  Sure you bottom line improves, but how does the organization fill those gaps?  Perhaps more importantly, how do you ensure that some gaps don’t get filled, say, you have decided to stop doing X, you can get rid of the people doing X but how do you make sure the people doing Y don’t try to cover for the loss?

This isn’t to say you shouldn’t downsize.  If improving the finances is the top priority do it.  Neither is it to say you shouldn’t do change this way, rolling the dice, shaking things up will produce change, as long as you have good people in place things should work out for the best.

Actually, I think a lot of change initiatives come down to rolling the dice.  When you introduce a change you can never be quite sure how things will turn out.  If you have a work force that is empowered, act under their own autonomy and are used to having freedom in their work then you never really know how they will react.  Conversely, if you have a work force that just does what is told and lives in fear of management you may well get unexpected behaviour as you ratchet up the pressure and fear.

So what can you do?  How do you weight the dice for a better outcome?

Well, in my model of the world management is like steering a boat.  You have a tiller and you constantly adjust it, so, as a manager you constantly communicate with your workers, you make it clear were you are trying to go and you are constantly applying minor changes to the tiller, a little left, a little right, a gentle touch to keep you going in the right direction – nothing too drastic.

Then you have the oars, one on the left, on the right.  These can complement or contradict the tiller – assuming you have both.  One oar is marked Leadership and the other is marked Authority, sometimes you give it a little leadership and sometimes you apply a little authority.  Hopefully you are going with the current so you can leave the oars out of the water most of the time and just use the tiller.  And thats the other part of the trick, to find the route that allows you to naturally go in the right direction.

Enough of company change, what about me?  How am I facing up to change?

First thing here is that I’ve just been through the British redundancy process.  I’ve seen people made redundant in Britain before and in the US.  The British process used to be a lot more like the US process: “Get your things, leave now” – short and sharp.  Now Britain is more “European” so it involves drawn out consultations.

The consultation process is supposed to be reasonable and fair.  I’m sure it works well if you are a car company and your closing and entire factory with unionised workers.  However, for a small, high-tech company with non-unionised workers its a pain for both managers and workers.

Managers naturally want to get the redundancies over and get the company back to normal.  Workers want certainty – both those staying and those going – but the British process drags it out.  Management are supposed to go into the process with an “open mind” (and can be prosecuted if they don’t) but workers don’t really believe this, they see game play and politics, they see managers stepping through a legal process because they have to with little hope of changing the outcome.

I’m sure some management groups do go into the process with a closed mind and set script but I’m also a believer in Occam’s Razor and I don’t think management start off with some script, stage directions and a pre-determined ending.

(I should make one thing clear, I have absolutely no idea at all how much of an open or closed mind my ex-employers had when they started their process.  I’m optimisitic and think they did have some openness but I have no idea how much.  My comments here are made in general from limited knowledge and experience.)

Anyway, now I’m unemployed and I need to get myself into gear for finding work – or at least earning money.  I suppose I should be spending all my time doing that.  Instead I’m spending a lot of time finalising the arrangements for my wedding next Saturday, on top of that I’m finishing off some writing projects and reflecting a bit on what has just happened – hence this blog entry.

And what next?

Well, I’d like to help companies build great software, and through building great software build great companies.  Both these objectives lead to one thing: building people.

Question is: how should I do this?

Well, I might just go and get myself another job as a Product Manager, a Project Manager, a Business Analyst, a Software Development Manager or something like this.  If you know of such a job call me!

Or, I might set up shop on my own and sell my consultancy services on these topics.

Sometimes it seems like I’ve done everything in software, I’ve been a developer, team leader, product manager, change agent, programmer, analyst, a system administrator, I’ve had a couple of entrepreneurial dabbles and a bunch of other stuff too.

So, if you know of any company that would like a few days advice on how to improve their software development process, practices and strategy let me know I’m available right now.

More stories for knowledge management

I went to the a lecture by Karl-Erik Sveiby – actually it was the UK launch of his new book Treading Lightly.  Karl-Erik is a professor of Knowledge Management at Hanken Business School in Helsinki and his new book discusses the use of stories by Australian aboriginal tribes to communicate knowledge over 60,000 years.

The story of how the Nhunggabarra tribe passed knowledge from generation to generation through the stories is also the story of how they kept their tribal law and the basis of their whole society.  At first I thought this form of story telling would be similar to that discussed by Stephen Denning in The Springboard and other books but it turns out there are differences.

For Denning stories are a way of communicating knowledge and creating change.  To this end the stories are designed so the listener can imagine themselves in the story and draw lessons quickly.  In contrast, the stories Sveiby talks about are used to communicate continuity and law, the stories are deeper and it takes months or years for the listener understand the full meaning of the stories.

While Sveiby and Denning seem to outline different types and stories and different uses for them I don’t think the two forms are mutually exclusive.  For Sveiby the stories are about passing on a culture, storing knowledge and ensuring sustainability.  For Denning stores are about creating change and refocusing knowledge.  Sveiby’s stories are thousands of years old while Denning’s are new.  It just comes down to how you design your stories and what you are trying to achieve.

The important point is that people communicate and manage their knowledge through stories and these stories can be used for a variety of purposes.

There is a link to Patterns here.  In The Timeless Way of Building Christopher Alexander suggests that patterns for building are handed down from generation to generation – something that was largely a verbal tradition.  He also suggest that, particularly in the twentieth century, some patterns have been lost.  Therefore, to capture patterns for the future we need to document and formalize our patterns so we can communicate the designs.

I have been suggesting for a while that Patterns are a form of story.  In making this suggestion I have drawn on the work of Denning.  Now it seems that Sveiby’s description of stories also fit – Patterns are a means by which a culture can capture and pass on knowledge to future generations.  Which all goes to add support to the theory that Design Patterns are a form of story that contains knowledge.