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.

Running as an analogy for software developers

Mail arrives from an old friend in Silicon Valley:

“So just as we get back from the show to recover, rebuild relationships with our wives and kids (since we've been working constantly for 3 weeks prior) they want us to drop everything again”

Meanwhile, a different friend tells me that he doesn’t know when his project deadline is.  He’s got his burn down chart that shows when he thinks he’ll finish but this doesn’t seem to matter to anyone just now.

So, what do these two, apparently opposite situations have in common?

Well, it makes me think that developing software is a lot like running a race.  I’m know I’m not the first to think of running as metaphor, after all SCRUM actually has development sprints but not every development is a sprint.

It all comes down to distance.  First of all, you need to know how far you are going to run, you need to know were the finishing line is.  We might start projects with only a vague idea of the deadline: next November should; and even if we do know it might get changed.  The thing is, when your deadline is makes a difference.

Unfortunately the deadline is all too often the finishing point.  Personally I like to pace myself so my work is finished before I get to the deadline.  There are two problems here.  First: all too often we’re asked to do more work than is actually possible in the time allowed.  We try and put a quart into a pint jug.  Gung-ho management can actually make this sound like a good thing.  However, if management don’t prioritize and give guidance on what to do they are really abdicating their responsibilities to developers.  They are saying:

“We want to you to do all this work, this is a challenge to you.  We don’t want to know if you can’t fit it all in, just make it fit somehow.”

So, either they have to extend the deadline, or they get a selection of requested work chosen by the developers.

The second reason why my approach fails is the tendency for people to say “Arh you’ve finished, in that case you’ve got time to do this as well…” and increase my load.

Still, back to the race analogy.

If I’m running a sprint I know I need to run just as fast as I can.  I know it will soon be over and I can recover.  I know that if I have a chance to pass someone I have to take it, there may be risk but there probably won’t be a second chance.  In a sprint the start and end are clearly defined and its a straight run.

Thats different to a 400m, you still have to run damn fast but there is an element of pacing.  You will get second chances to overtake someone but you won’t get many – so the risk equation changes.

An 800m changes things again, its much more about pacing yourself, and the risks are different again.

Normally developing software is something like a 800m.  You have near deadline but its not so close that you drop everything.  Sometimes when you have a 100m deadline you drop everything else in your life.  I did once port a piece of software overnight.  Six of us: Roy and me coding (porting) like nothing else mattered, two more developers riding shotgun, and two managers ordering take-away food and biting their finger nails.  We took risks and worked in a way we would never have done if we had another day, let alone another week or a month.

And on a long run, like a marathon, things change again.  Its all about pacing yourself, you need to know when to run fast, when to hold back.  You need to stay on the course, often you find it is not well sign posted so you need milestones and navigators to help you.  Although your competing with the others in the race your also co-operating in a way.

Or maybe development is more like a relay-race, you have to work as a team.  Or maybe its like hurdling, someone puts obstacles in the way.

So what does this analogy teach us?

I think it emphasizes the importance of pacing yourself.  You might be able to run 100m fast but running 800m is not the same as running eight 100m races back to back.  Everyone knows this about running so why don’t they see it in development?

 

Don’t bring me your problems, or Appreciative Inquiry to the rescue

Do you ever find out about something and ask yourself “How didn’t I know about that before?” For the last week or so I’ve been reading about the theory and practise of Appreciate Inquiry. It makes a lot of sense to me and I can see myself applying it. In fact, it makes so much sense it seems to underpin a lot of what I’ve been believing for the last few years, so I’m asking myself: how did I pick this up without knowing the name of it?

Actually the idea of Appreciative Inquiry (AI for short) is quite simple: appreciate what is good, inquire into what is good, and harness the positive energy for change.

This is diametrically opposed to many ideas of change that start from the assumption: something is wrong, something has failed or something is a problem, therefore, we must use this failure to fix the problem.

The problem with the problem approach is simple: it is a mind trap, you start looking for problems, you get negative, you focus on what is wrong. Your language becomes full of negative things - “Sales were down”, “Software was buggy”, “Delivery was late” - you loose sight of the miracle that you just shipped a 1,000,000 application, or you sold $1m of product. And when you become negative you mindset becomes negative. And when people become negative they become defensive, change actually becomes more difficult.

So AI takes the other approach: look what is good here, what did we do well? What should we do more of? And with your positive mindset you’ll look for opportunities to improve. According to the stories I’ve been reading (and yes, AI does seem to overlap with story telling) once you get the positive mindset you unleash lots of energy.

I suspect one problem with the AI approach is when you have create a sense or urgency or explain the need for change in a 5 minute PowerPoint to senior management it is always quicker and easier to cry wolf than it is to paint a picture of the new Nirvana.

Now, what about learning? Regular readers will know my proposition that Change <=> Learning. Well, the good news it that this is entirely compatible. We learn best when we want to learn, when we are enthused and focused on learning something - anyone else ever done more education than the law demanded? - If we are positive, and have plenty of energy then learning is going to be easier. If we are learning because we are enjoying ourselves then we learn more and better.

The problem tends to come when we can’t follow through on our learning; we learn how to create better software but we can’t do it (we can’t change our processes) and we get frustrated and negative. We criticize others and see failure and problems.

Before I answered the question I set at the beginning let me give you some references - this thing is worth knowing more about!

The original AI paper is by Cooperrider and Srivastva . Its pretty heavy going, very academic, mainly talks about Action Research (another fascinating topic) and contrast Logical Empiricism with Socio-rationalists. Its heavy but good, I’ve got a few other good ideas from here.

If you want something shorter try this short piece on the Harvard website. Bushe has a good piece on AI with teams here and more stuff here that I’ve not looked at yet.

Finally, for references, I read this piece by about AI at GTE. If your scratching your head saying “I kind of remember GTE” so was I, this is the old name for Verizon. Actually, a bit of Googling on appreciative inquiry and GTE brings quite a few references so may be a well researched case.

The website http://appreciativeinquiry.case.edu has a lot more too.

So, to return to my earlier question: how have I missed appreciative inquiry?

Well, on the one hand I haven’t missed it. I found a brief note in my MBA lecture notes about it and a note to myself “Read more about this”. So, I was aware of it four years ago.

Second, I think many of the authors I’ve been reading in the past couple of years had a similar philosophical bent to Cooperrider and Srivastva so, even if they hadn’t be directly exposed to appreciative inquiry, they were leaning towards these theories and I’ve picked some of it up from them.

And third, and this is the big one: I think I’ve had some of my AI bent washed from me in the last year to 18 months. Ever since I became a Product Manager people have been asking me to “Identify the problem you are trying to solve” add to this my own emphasis on some Lean/Agile techniques which ask you to “Fix the biggest problem first” then “do it again”.

So, I think I’ve become Problem Focused. This has had two effects: first it has subjected me to the “we have a problem” approach, I’ve been caught up in the language and thinking of problems and this has had a negative effect on me and my own thinking. Second, the problem approach has hidden my AI bent.

When I think back I didn’t convert my employers to Agile Software Development because we had a problem, I converted them because I saw an opportunity. What’s wrong with that? The developers who bought into the ideas of Agile and Lean did not do so because they were trying to fix a problem, they did it because it seemed like a good idea.

Long live the Opportunity! Appreciate the good! To hell with problems!

Why isn’t the obvious obvious to others?

One of the reoccurring themes in my work is the need for those who are involved with a problem to find their own solution and to implement that solution. I can get quite passionate about the need for action and the demotivating effects of having someone else work out the solution and simple pass it on for you to execute.

Still there may be occasions were an outsider’s view can be helpful. I’m sure we’ve all been in situation were we are powerless to effect a decision, it could be events in our office, our company’s strategy, or Government policy, perhaps its a football team selection. What is obvious to us, and often obvious to our drinking partners too, somehow isn’t obvious to those charged with making the decisions: our manager, the prime minister, the team manager. Why is the obvious not so obvious?

One reason might simply be that we (who think we see an obvious answer) lack information. Sure doing X is obvious, and sure the people in charge have considered it but doing X will effect Y. That Y exists and is a potential problem might not be common knowledge, or it could be something that we are simply ignorant of.

This explanation also works in reverse, particular were knowledge is needed. For example, as someone with lots of experience in IT I have a lot of knowledge, this allows me to see obvious solutions to many IT problems. So, its obvious to me that bid Government IT projects will go wrong but that never seems clear to those who authorise them.

A second reason is that what we consider obvious simply isn’t obvious to those making the decision. Perhaps they see a lot of related issues so can’t see the wood for the trees; perhaps they have some personal stake that makes it hard for them to do X; or perhaps it simply isn’t obvious. In such cases it can be possible to be too close to the problem.

I noticed this the other week. I was having problems sorting out some problems of my own when a friend called looking for advice for her problems. After hearing her problems I made some suggestions, the solutions seemed straight forward, at the end of the conversation she said something like “Yes, they are good ideas I’ll try them.” While I was able to solve someone else’s problems I couldn’t solve my own.

So, sometimes you can’t solve your own problems even when there is an “obvious” solution. You need help to see the problem. How can we reconcile this with my opening point about the need for people to find their own solutions and act on them? Well, I think the trick is two fold: first know when you need an outsiders opinion, and two, if you are that outsider, try and give the solution in such a way that the person asking takes the solution as their own.

Blog so quiet

I’ve not blogged much lately. That’s because I’ve been busy with other stuff: stuff at work, stuff at home, other writing and taking some time off. O, and if you haven’t heard I’m getting married and these things don’t just organize themselves.

Still, when you’ve blogged as frequently as I have done sometimes in the past you feel your missing something.

So I was very interested in this piece in the Financial Times this week, Valley voices find their value. It appears I’m not the only blogger to find it hard to find the time to blog. Actually the FT piece is mainly about bloggers who because of their blog have either found a viable business based on the blog or their blog has given them a profile that results in them having less time to blog.

Perhaps one day my blog will grow into that... I can hope. For every Robert Scobie there are a million bloggers with no readers, and probably another million who write one entry and then never blog again.

Arh, maybe I’m a sceptic, maybe I lack ambition, its just, I tend to think the existing world exerts a big pull and such cases are still quiet rear - that’s why they are worth an FT article.