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:

• Situating Business Patterns – a paper about pattern theory and how it relates to business patterns.
• Patterns for Technology Companies – two more patterns in the series.

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.

Progress on Open Source CMS

Picking up my discussions about Content Management Systems… two things stand out: first “content management” is a broad topic and needs sub-dividing, second there seem to be thousands, if not millions of Open Source CMS systems out there.

Well, good news, bad news, good news.

Good news: there is a white paper from Seth Gottlielb at Optaros (January 2006) which is very useful in getting a grips with the Open Source problem and giving some hints on the sib-division problem – “Content Management Problems and Open Source Solutions.”

Bad news: I know some of the sub-divisions of CMS, things like “Document Management System”, “Web Content Management System” and “Enterprise Content Management System” but so far I haven’t found a good list of definitions.  How many sub-divisions are their?  When is a CMS “Enterprise” and when is it not?

Good news: I installed Joomla CMS this week – its a spin-off from Mambo – on WAMP (Windows, Apache, MySQL and PHP).  The install was actually quite painless, apart from a few problems getting PHP to work on Windows with Apache everything went well.

Anyway, thats it for now, just wanted to capture these thoughts, so much going on, lots of blog entries to come!

Bad role models make for poor management

I have read too many theories and ideas on management style for my own good.  Most of these theories suggest things like: listen to your people, work out what motivates them, give them good work, don’t order them around and so on.  Truth is: I agree with all of this, it makes sense to me to treat people with respect, assume they are cleaver and work with them rather than ordering them about.

Some people will say I’m just an idealist.  They may say that that kind of thinking is what separates books and ideas from the practical realities of life.  Some may go as far to say that because I believe all this “west coast” stuff I don’t understand how real management works.  And these people will point out to armies of managers and companies they have know who don’t take this advice.

Well, I can’t argue with the numbers.  I’m sure many managers and companies don’t take this kind of advice.  I’m sure an awful lot of them don’t even know about these ideas or even think about “management style” and what works. 

So what is the alternative?  The alternative, which I’ve taken to calling the “Hollywood style” or “Default management” (for reasons which will become clear in a moment) is all about Command and Control.  Its about telling people what you want them to do and just expecting them to do it.  As in a Hollywood film the manager always knows what is best, time is always pressing and the grunts on the ground just have to do it – if they don’t then just hold a gun to their head.  O, and everyone understands exactly what the manager wants. 

Managers who subscribe to this theory probably don’t know they even have a style.  They just do what they think a “manager” should do.  There are two sources for this theory.  

The first is Hollywood.  The all action hero, bursts onto the scene, tells people about the way it is, doesn’t explain how he is going to fix it but starts telling people what they should do: “secure the roof”, “get the women and children out the fire escape”, “stay low”, “cover me”.  He rushes off, beats the baddy and saves the day.  It is only him, the guy in charge who understands what needs to be done, everyone else falls in line, everyone does just what he asks and he saves them.

The second source is the way the military operates.  Or rather, the way us non-military types think the military operate.  Having seen a selection of old war films we think we know that the Generals at the top know everything, they tell the Colonels, who tell the Sergeants, who tell the men.  And then the guys on the ground just do it, they execute the plan – and its the plan that is all important.  In this model the CEO is the General, managers are Colonels and the guys on the guys at the code-face are the ones that get shot. 

For the record, I’ve read a little military history and I’ve known a couple of ex-military people, from what I can tell this isn’t necessarily how it happens but it is the model many people have in their head. 

So, getting back to managers.  It seems to me that many people get to be managers without actually discussing what it is a manager does.  They need to manage and they adopt the ideas and style they’ve seen in Hollywood films and what they think military commanders do.  Consequently this becomes the default management style for most people.

Tech companies, at least the software companies I’ve spent most of my life working for are particularly bad like this.  Software guys tend to get promoted because they are good technically, faced with the need to manage they use the default style.  Meanwhile, people who do think about this stuff are see as non-technical and consequently don’t get the chance to manage any other way. 

The more people who adopt the default style the more it seems like the style we should all follow – safety in numbers – while we deprive ourselves of role-models.

Unfortunately this means many people have bosses who have picked up everything they know about management from Hollywood films and out dated versions of military command and control.  Thus, these people never get to deliver their best which is a shame for them, their managers and the companies who employ them all.

 

Return to Content Mangement: 7 reasons for CMS

Regular readers of this blog may recall my on-off deliberations on Content Management Systems (CMS) – like this entry from last November.  Well, I’m at it again, this time I’m trying to come up with a simple solution for a better corporate intranet.  One thing I have learned is that talking of Content Management Systems this confusing, simply this is not a very useful name.  The problem they is content management covers such a wide field that when I say “content management” I mean one thing and when you say “content management” you mean to indifferent.

In fact we already have some widely used tools for content management, namely a hierarchical filing system (whether on our own PC or a shared network drive) and web-servers like Apache.  Given these the question becomes why do we want something more than these?

Well in the last few months I’ve thought of seven reasons why you might want to go beyond these basic tools.  And once you know why you want to go beyond these tools you can start to think about just what it is you want when you say "content management system".  So without further ado here are seven reasons why you might want a CMS.

1. CMS as a better Web server

In the same way that desktop publishing software represented a better form of word processor it seems CMS systems represent better web-servers.

2. CMS as a better filing system

Directories, folders, files and dryers are good but they are also complicated and it is easy to lose stuff.  Therefore having it “managed” is appealing.

3. Re-purpose content (re-purpose not re-use)

Sometimes we want to use the same content to different purposes.  For example technical authors write manuals and some of that content could be extracted and put into a help file, or online help system.  Similarly marketing literature may appear on the Internet, public website and in sales brochures.

4. Regulatory compliance

An increasing number of firms need to keep track of their documents and correspondence for audit purposes and to satisfy legal requirements.

5. Document life-cycle management

When is a document past its best?  When is a document to be replaced?  How do know that the latest version?  How do know document needs updating?

6. Version control documents

This follows on from the last two points but is worth calling out in its own right.  On a filing system (VAX and similar excepted) there is one document, if you want to version the document you have add a number to the file name and remember to update it.  This is laborious and complicates things especially then you need to track which version was in current at which time.

7. Document archive

Overtime all organizations collect more and more documents.  Many of these documents aren't needed on a day-to-day basis, in fact they are in a way day-to-day, but you need to keep them for reference purposes or because they might just contain some gem of knowledge that is useful sometime in the future.  (Again this tends be related to regulatory compliance but not always.)

So there are seven reasons why you might want a CMS.  It is not an exhaustive list by any means, in fact I’d welcome some more suggestions.

Public sector ITC

The Work Foundation (yes, odd name but it makes sense when you read their description of themselves) has released a report on public sector IT projects. 

Sometimes it seems hardly a week goes by in the UK without the media publicizing another failed Government IT project.  This report – and at 43 pages I haven’t read it all (yet) just executive summary and the conclusions – looks like a valuable and informed contribution to this debate.

The report is called How ICT? and is free.  (There is also a short summary in the FT – you might need a subscription.)  Interestingly this report has tried to look at technology projects from the point of view of the end-users, the workers on the front-line.  Its these people who use the system daily, these people who will see the immediate benefits or the immediate problems, and its the attempt to make these people more productive that the projects are all about.

(By the way, has anyone else noticed IT is no longer IT but ICT – Information and Communication Technology.  Thats another TLA to put next to IMS and IS and IM and …)

So what does the report say?

Well, ICT is about more than technology.  Its about changing the processes people use, its about the people involved in the processes and it is about the technology too.  Yes you have to manage the technology but its not the only problem, you need to carry the people with you and change the way they work to get the benefits.

The report also recommends: “Strong project management skills are vital” – it fills me full of thoughts of project managers with GANT charts – but then goes on to say “projects should be broken down into manageable chunks” which sound much more reasonable, then “a structure created for planning and monitoring progress” which seems entirely sensible.

Of course the report doesn’t say anything about how you should run your development effort but everything I’ve read so far suggests it is entirely possible to run it on Agile/Lean principles.

Although the report is about the public sector I think most private sector organizations could benefit from having a look at it.