Wednesday’s Financial Times carried the monthly technology review. A couple of pieces caught my eye, both individually and when put together.

First this report In an e-world, IT controls the customer experience (subscription required) makes the point that if your business is conducted online then your customer experience is an electronic customer experience which in turn means the customer experience is decided by the IT department. This is a point I’ve made myself in the past – although I’ve never came up with such a compact phase to describe it.

In posts in January 2006 and December 2006 I sounded off against poor travel company web sites. My customer experience is poor because the web sites are poor. It doesn’t have to be this way but unless the IT department think about the customer experience, or the people responsible for the product involve themselves with IT this is what happens. Unfortunately IT departments have spent years refining their image as uncooperative.

Given the increased use of e-commerce by all businesses – not just those like Amazon which only exist on the web but everyday companies like the travel companies I dislike – then any business that does any e-retailing has this issue. The online brand can damage the off-line brand.

The second piece that caught my attention was this one Can HR handle IT recruitment? According to this article human resource departments do not have the skills and experience required to hire IT people. The story rings true from my own experiences and from many anecdotes I’ve heard over the years.

Although these stories all ring true I’ve also known several good HR people. People who have their heads screwed on and want the best for the business. Plus I’ve read a fair few HR text books and articles and I know HR people aren’t really as bad as IT people make out. So what’s going on?

Well I have some possible explanations.

Theory 1: Many companies have bad HR departments. There are some good HR departments out there but possibly most of them are not worth the salaries we pay them.

Theory 2: Everyone has these problems with HR, it isn’t just IT. HR is just badly understood by the rest of the business.

Notice that these explanations are not incompatible. Neither are they incompatible with the FT article. Which raises the questions: What are HR actually doing? Why aren’t HR departments getting to grips with IT and trying to rectify the problem? After all, strictly speaking, it is the HR departments job to hire people so it is they who have the problem. They can’t blame IT for this problem.

Put all these theories together and you get: HR is important, HR doesn’t understand IT, many HR departments are poor, many HR departments fail to hire the right people. As a result many IT companies do not hire the best staff. And because good IT depends on good people few companies will have good IT.

Proof for this theory comes from Google and Microsoft. Both of these companies have built hiring machine. They both need a lot of IT staff and they have made sure HR can do the job properly.

So the lesson is: If you want good IT you start by fixing your HR department.

Finally, put those two articles together.

IT controls the customer experience but HR do not know how to hire the people IT needs. In other words: HR departments do not know how to hire people who create the customer experience. Am I the only one who sees this as a serious problem here?

A student at Fullerton University in California e-mailed a lot of people on the Lean Software Development mailing list with some questions for his masters thesis.  Since I had a little time on my hands I wrote him some lengthy answers.  Having done that I though I would share them here.  I’ve removed a few questions because I don’t think the question or answer are particularly interesting.

1.      How would you define lean development?

The strictest definition of Lean Development would be to say it is a methodology proposed by the Poppendiecks (Lean Software Development)based on lean manufacturing and product development.  This definition is useful for deciding who is doing lean and who is not but is probably too strict.

Another definition of Lean (Software) Development is that it is the application of the principles of Lean Manufacturing ( The Machine That Changed the World, Womack, Jones & Roo ) and “Knowledge Based Product Development” (Product Development for the Lean Enterprise, Kennedy).

Personally my definition is:

• Lean Software Development is one application of the principles of Organizational Learning to the software development environment. 
• Learning Organizations may come up with a different development way of thinking but I am not aware of any others.
• Agile Software Development is a further refinement from principles of Lean to practices.
• The various Agile development methodologies are further refinements of these with further practises.
• Underlying everything is the idea of a Learning Organization (Senge, Argyris, etc.)

So you can create a pyramid, more general at the bottom, more specific at the top: 

– XP –	->	Specific practices
— Agile —	->	General practices
—- Lean —-	->	Ways of thinking
Learning Organization	->	Concepts

To put it another way:

• XP (or SCRUM, or DSDM, etc) are a specific set of practices for doing Agile software development
• Agile software development is set of principles and a specific set of lean practices
• Lean is a set of principles and a specific set of learning practices
• Organizational Learning is a set of principles to which some authors have added some practices

Note that you can, in theory, adopt an Agile methodology with very little learning. You could simply adopt, say, SCRUM practices and through focus and authority make people use these.  You probably would see some benefits however the team would not be learning and future change would not come naturally.

I examined Software Development as Organizational Learning for my own Masters dissertation

2.      What percentage of developers do you think are using Lean Development approach?

Very difficult to say, I think some ( less than 10%) will have picked a few practices, I think few will be working in a Poppendieck or Kennedy like way –  maybe less than 1% on this definition.

On the other hand, I think many are undertaking some organizational learning and using some agile practises but progress is very slow.

3.      How has the usage increased from previous years?

Slowly.

4.      Why do you think the usage has increased?

Various:

• The term is now commonplace thanks to Poppendiecks and others.
• Lean (and Agile) tell a very good story, developers want to work like this.  Managers see the parallels with lean manufacturing so also hear a good story.  It is an aspiration change.
• Natural selection: those who “get it” will out compete competitors.

5.      How do you expect the usage to be in the next five years?

Slowly.  I see an Agile backlash building, I hope lean will not be caught in it too but I think it will.

6.      Have you found resistance or pessimistic thinking towards Lean usage?

Yes – “Idealistic”, “Will not work here”

7.      What kind of unintended results have you seen by using Lean?

Lean relies on exposing problems so they can be fixed.  (Removing “camouflage” to use Argyris term and rolling back what Senge would call “shifting the burden.”)

As such it looks like things are getting worse to start with.  Problems that were hidden are now apparent, problems that could be ignored before need fixing now.  Therefore, Lean looks like it is making things worse before things get better.

When developers or junior managers get it but senior managers don’t there is a mismatch.  Junior managers pay a heavy emotional toll and sometimes pay with their jobs.

8.      What suggestions do you have for a shop considering Lean?

• Emphasis the learning. 
• Take it from both ends: senior managers down and shop floor up.
• Get help, specifically coaching.

10.     Can Lean development be applied to non-Agile (i.e. waterfall) methodologies?

You could make a waterfall leaner but I doubt we would ever call it lean.
In suggesting a lean waterfall you are saying: “We want to improve X but we don’t want to change Y”.  You have put boundaries on the problem.  In doing so you are putting some things out of bounds.  This means you can’t engage in Systems Thinking properly and are likely to come up with sub-optimal processes.

11.     How difficult is for a team become Agile and Lean after being non-Agile?

Very difficult.  You can start in a small way but you need to break with the past.

13.     What are the key indicators to tell if a team will succeed in becoming Lean?

The presence of a learning culture:

• Is the team holding retrospectives?
• Is the team changing their process?
• Is the team improving?

14.     Is it better to be Lean and then Agile or Agile and then Lean?

Given my definition above this question does not make sense.  There is no temporal relationship.

If you are Agile then you are (to some degree) Lean.  If you are Lean then you are Agile.

15.     What did I forget to ask you about lean?  Is there something about lean that you consider very important that we did not discuss?

The “change question”.  We know how to be Lean and Agile but how so you change the organization?

Then, when you have become Lean how do you carry on changing?

Organizational change is more important than the practices.  The practices support learning and change but change is not a rational thing.  You don’t do a value stream map and solve everything. 

OK, I promise this is the last entry on the Nurnberg funnel, after this I’ve worked it through my system…

In my entry on Nurnberg funnel and system development I wondered is system documentation actually works. Well I missed one piece of evidence that it does work. Go into your local bookstore, Waterstones, Borders, even Amazon online and look at the books on computing. Specifically look at the technical books that describe things like programming languages, operating systems, APIs and the like. If system documentation does not work how do we explain the existence of all these books?

After all, publishers are in the business of making money. If these books did not work – i.e. did not help learning and transfer knowledge – then presumably nobody would buy them, there would be no profit in publishing them and consequently they wouldn’t be taking up real-estate space in the book store.

So how do we explain these books if technical documentation doesn’t work?

I don’t have any figures on what is happening but here is my guess.

Firstly a whole load of this documentation does not work. Many books get bought despite being bad. Many more books are bad and simply don’t get bought, publishers swallow the loss and pulp the books. I would guess this category covers many many books. Lets take a stab and say 40% of all technical books.

A second category of books do work and they work for exactly the reasons Carroll outlined in the Nurnberg funnel. They are written along the lines of minimalism. My guess it that a lot of those “For Dummies” and similar books fall into this category. Still, this type of book represents a small percentage of all books. Lets say 5% – probably an overstatement but it keeps the numbers easy.

OK, I still have 55% to account for – and I’m deliberately not saying if these are percentage of books sold or books published.

Next up I think there are some books which do not directly take on board the minimalist ideas but have a similar approach and work for similar reasons. I’m specifically thinking here of patterns books like Design patterns and Pattern Languages of Program Design 5 (to which I was a contributor).

In part patterns are popular and accessible because they start with a problem and describe a solution. This is a little like the task orientation that Carroll advocates. I’m sure patterns books are not alone here but there aren’t very many books in this category so lets just say another 5%.

This also starts to hint at another explanation and one which must account for many of the remaining 50% of books. Simply minimalism is but one technique for creating documentation, it works particularly well in one field – user manuals – but it is not the only one.

For example I know of one other method, story telling. This is usually advocated as a management or knowledge management activity to be conducted verbally. (See books like The Springboard and Storytelling in Organizations). However there are technical books out there that take the same track.

For example, I found the original version of Inside Windows NT quite story like. Although perhaps this is a sign of how techno-geeky I was in the mid-late 1990’s. Somehow the second edition of the book never had the same plot or interest for me.

Less technical books about technical subjects are better examples of story telling. Take The Soul of a New Machine for example. This is a must read, I left it far too long before I read it but its right up there with The Mythical Man Month, Peopleware and The Psychology of Computer Programming if you want to know how software (and hardware) really get created. But Soul of a New Machine is also a story, it can even be bedtime reading.

Books like these are more the exception than the rule so they are few and far between. Lets say 1% are story books.

Another category is reference books like Charles Petzold’s “Programming Windows”. I defy anyone to actually read this books cover to cover, you delve into when you have a specific problem or need to know some specific detail. But reference books probably constitute a lot of the books written, say 20%.

That takes me to 71%. I still can’t account for 29% of books. I give up.

The important thing is that people read books for different reasons. Our motivation for reading one of these books will be different to the motivation for reading another. That will change the way we approach buying and reading books.

Which in a strange way brings us back to minimalism. People use Petzold’s books when they have a task to accomplish. People pick them up under certain circumstances and like a Dummies book expect to get something specific from them. But that doesn’t mean all books should be written in the minimalist style. Minimalism is just one of many styles.

So actually, we’ve come back to one of the re-occurring themes of this blog: know your customers, service their needs with a product that is designed to meet those needs.

Products development doesn’t end when the code is written, compiled and burnt onto a CD. It has to include the documentation, service and support that is supplied with the products. It also means ensuring that future product development can continue, whether through just-in-case documentation or just-in-time networks of people who know.

Unfortunately obvious solutions – like big thick manuals – are not necessarily the best solutions. We need to be on the look out for new solutions and new ideas.

And we need to understand the costs and benefits of all this. This is difficult bit because so often we don’t know the numbers and we can only speculate on what they are. But somehow we need to put all of that together.

After reading Minimalism beyond the Nurnberg Funnel I have been thinking what implication these theories could have for software development itself.

First for system design. Minimalist documentation aims at being task oriented. The idea is that the readers (users) are trying to do something and need to solve a problem – how do I? – so they turn to the documentation. What if we apply these ideas to system design?

Well I think we would come up with simplified systems that allowed users to perform tasks. The software would treat users as problem solvers and allow them to combine the tasks in what ever way they like to solve their wider problem. Now this starts to sound like Naked Objects.

Second: what if we turn our attention from user documentation to system documentation? Usually the documentation software developers write to describe the insides of the computer system is based on the Nurnberg funnel principle. We assume that is a software designer writes down everything they think they know about the software then someone who reads it will know the same information – open programmer’s head, insert Nurnberg funnel, pour documentation…. programmer can now understand software!

Obviously this isn’t going to work. This isn’t only true about existing software it is also true about systems we are going to write. Traditional software design (specifically the waterfall model) mandates that Architects and Designers – who in the traditional model are different to Programmers – should “design” a system, document the design and hand the design over to the Programmers so they will know how to turn the design into code.

Again, this is the Nurnberg funnel model and it isn’t going to work. When we follow this model we are lying to ourselves. So what are we to do?

Minimalism probably isn’t an answer in this case. Firstly the potential audience is so small it will be impossible to justify the extra cost. Secondly minimalism relies on describing the tasks people will want to perform. In general we don’t know the tasks that future system developers might want to undertake on our software. Yes we can guess what they might want to do but this really is little more than a guess. I have designed and built systems in the past with specific extension points for future developers – just add a new object here. But these are simple changes. The majority of the changes I’ve done to software involve expanding it in a way that wasn’t thought of in advance.

So while the thinking behind documentation minimalism can show the failings of traditional documentation it cannot provide a solution. We need to look elsewhere. I’m not sure I know the solution but I’ll make one suggestion.

The problem of making software developers familiar with a new code base is not a problem of documentation. Rather it is a problem of knowledge management and specifically knowledge transfer. Documentation is one tool in this arena but not the only one. Traditional documentation relies on a just-in-case model. Managers who are worried about risk have developers document the system just in case something needs to be done. This looks like a strategy to mitigate risk because we have “captured the knowledge” but in fact the risk still exists because the documentation is not very useful.

The alternative model is just-in-time knowledge management. Here we ensure that should a new developer need to know about an existing system they can ask someone who knows when they need to. The knowledge transfer then takes place directly from one developer to another.

Instead of the solution being based on something you have it is based on someone you know. On the face of this it this model looks costly. In order to get the knowledge we need a one-to-one relationship rather than the one-to-many relationship documentation provides. But since documentation does not work this argument does not hold.

In fact, writing documentation that might not be read, and if it is will not be understood represents waste. It is a waste of the developer’s time to write the documentation, it is a waste of paper to print the documentation, it is a waste of space to store the documentation and it is a waste of time to read the documentation. The only purpose it serves it to allow a box to be ticked on a risk form.

Using the just in time model all this waste is eliminated. If, and only if, the knowledge is needed then the cost of knowledge transfer will be incurred. And since the cost will be incurred in the future it is cheaper today. (I probably don’t need to spell this out but just in case: this model matches the ideas of Lean manufacturing, product development and software development.)

However, we are still left with the problem of mitigating the risk. To do this we need to keep track of the programmers who developed the system and have made changes since. This potentially changes the nature of the software development model but in today’s Internet connected world should not be insurmountable.

The problem then is that people, even developers, do forget over time. Still, forgetfulness might not be that much of a problem reality.

There are two types of system: those that are used and those that are not. The ones that are used tend to need changes over time; because these systems are living people think of new features and they need to be changed as the environment changes (think Y2K.)

Then there are the systems that don’t get used. Well if these systems are not used it is unlikely they need to be changed. Obviously for those systems that are being changed there are people who know how they work. For those that don’t change there might not be anyone who knows how they work but neither is there anyone who needs to know.

Of course there will always be the odd exception, a program that runs for 10 years without a change and then needs updating; but how many systems are there like this? Does the existence of a few systems that require very occasional changes justify writing all that documentation for all those systems were is isn’t needed, won’t be read and won’t be understood if it is?

I am still thinking through the implication of Minimalism Beyond the Nurnberg Funnel. One of these ideas concerns the benefits to the software producer of supplying minimalist documentation. One of these is the idea of documentation as a product strategy. This is covered by Karl L. Smart in an essay in the book.

Software companies all too often view the production of documentation as a cost, not an opportunity. Documentation is seen as a necessary evil since supplying software without documentation is not acceptable but writing it will push up costs. So companies produce documentation but try to limit the costs and miss the opportunity.

In my experience this usually means that too few technical authors are employed, those that are over worked and their activity is something of an after thought. They are not integrated into the software development regime; they get the product late and are expected to document everything they can. To cap it all technical authors are often among the first to be laid off when a company needs to make redundancies.

(Of course they assume that the role of technical author is even recognised, many producers do not see technical author as a role in its own right. Such companies make developers, managers and particularly testers write documentation in addition to their main job.)

Overall technical documentation is a lose-lose. Companies don’t see the benefits of providing it, users demand it but do not have high expectations and when they do turn to the documentation it is pretty useless.

I have seen a variation on this theme a couple of times, this is the highly complicated product. There is no way the user can learn the product from the documentation so they need training courses. Training courses can be a nice revenue earner for the supplier but they don’t normally don’t manage training very well so don’t make money from it. To the buyer training is yet another hidden cost. To the user there is not enough training, it is not good enough and it is another cost that can’t get signed off. Meanwhile the software continues to get complicated and everyone hopes the training and documentation will act as a sticking plaster.

Smart argues that providing quality documentation is actually a win-win for supplier and customer. Minimalism provides the road to useful quality documentation which benefits the product in a number of ways:

• Good documentation differentiates the product from its competitors
• Good documentation is more useful to users who in turn use the product more – and exercise the features – so they extract more value from the product so they are more likely to buy more product.
• Good documentation means users are more likely to solve their own problems than call the technical support line. Therefore the supplier can save money on technical support.
• Not only the supplier saves on tech support but so does the customer. Research shows that for every $1 of direct technical support costs a user needs they use $3 of informal support when they ask colleagues to help them.
• Minimalist manuals are usually shorter than traditional one so they are cheaper to manufacture. Although now documentation is usually supplied in electronic format this argument is reduced.

Producing minimalist documentation might cost more because it requires more time and analysis from writers but this is offset against savings suppliers can increase profits by producing minimalist documentation. (A word of warning: minimalist documentation does not mean producing less of the same documentation, there is more to minimalism in documentation than simply doing less. It means doing things differently.)

Because better documentation makes the product a better product it enhances the sale-ability of the product and therefore improving documentation is a strategic move on the part of the supplier.

This also means that documentation should be an issue for product managers. In addition to specifying features and requirements of the software product managers need to RTFM and find a way of improving the manuals.

I can’t remember where I came across Minimalism Beyond the Nurnberg Funnel but I’m glad I did. Still I think I may have read the wrong book, a better starting place for this subject would of been the authors first book on the subject The Nurnberg Funnel. Both books discuss the same concept, namely minimalism in technical documentation. However the newer book (Beyond) is not so much an introduction to the subject but a review of how the ideas had developed in 8 years. So I think the earlier book may have been a better starting position. Now, 9 years after the second book I assume things have moved on again.

The authors’ (Carroll is the editor of the new book but wrote the original one) concern is how people learn, and specifically how they learn from documentation. To this end the books are about technical communication. I think the ideas suggested would be interesting to user interface designers to look at too. The reference to the Nurnberg funnel comes from mythology.

Apparently – and I’ve not come across this myth elsewhere – the funnel was a device that allowed knowledge to be poured into someone’s mind. Imagine knowledge as some kind of liquid, insert the funnel into the head then pour the liquid into the head. Thats it! You know have the knowledge! This sounds like a great device.

Although I’ve never actually seen such a funnel they must exist because I know plenty of people and corporations who behave as if such a funnel exists. So it must just be that I’ve been unlucky.

Anyway, get back to the book… The originator of minimalism in documentation, John Carroll, suggests that traditional technical documentation is written on this principle. The authors working on a technical product (most of his examples come from word processors) fill the manual with everything they can think of. And over time the manuals grow as new features are added. For the users of the product the manual can be worse than nothing.

Research by Carroll and others shows that users just don’t absorb everything in the manual through Nurnberg like reading. Users find it difficult to find things and when they do they don’t want pages of explanation and technical details, they simply want to be told what to do. Indeed there is a paradox: people don’t sit down and read manuals. They want to accomplish tasks so they just get on with using the software. When they get stuck then they turn to the manual but they still do not want to read the manual, they want to do their task.

At this point a manual that explains technical details and system philosophy is exactly the wrong thing. Users will get frustrated and skip parts of the manual until they find the bit they want – that is, the bit that tells them what to do.

Actually I’m glad to hear this. This is the way I use manuals, I always suspected that other people used them “properly” but now I know: everyone else does the same as me.

The minimalist solution proposed by Carroll is to make the manuals task oriented. Work out what the tasks the users will want to perform and explain how to do these tasks. In the process recognise that different users will require different tasks so document them as such. Manuals should be organized so users can find these tasks rather than by technical logic.

There is more to minimalism than this but I’m not a technical author so I won’t go into detail. The upshot of it all is: users learn how to use the software more quickly, are more satisfied, are more productive and the manuals are often smaller than the non-minimalist equivalents. But what I do recognise here is that a lot of these ideas overlap with the user interface ideas proposed by Alan Cooper in his book The Inmates Are Running the Asylum . And the same idea populates good product management or business analysis:

Identify your customers, understand what they want to do, really understand what they want to do, then cater for that need specifically.

Whether this is in the product you build, the user interface you design or the documentation you provide it all boils down the same thing: understand and be specific. Don’t provide technology, provide the means to do something.

(Interesting I was talking to Tom Gilb at XTC on Tuesday. In his opinion one of the main reason projects fail is that they are not specific enough about what they are doing. There is a big conversation to have around the idea but not here, not today.)

Getting back to the book itself. If you are involved in technical authoring then I think it would be well worth reading either The Nurnberg Funnel or Minimalism Beyond the Nurnberg Funnel. If you are not technical writer then its not very clear if you would benefit from reading the book. If you want to know more about how people learn, or you are a product manager looking for ways to improve your products then it is worth familiarising yourself with these ideas.

I didn’t read all of this book, I read enough to understand the key ideas and understand what advantages they brought. This book is quite academic in style so it might be worth seeking out other books on minimalist documentation unfortunately I don’t know any so I can’t recommend any. There are more implications of this work than I have covered here. I hope to come back to these at some later date.

The last couple of weeks – if not months – have been depressing. I’ve been hearing far too many stories about IT failures. Not the kind of failures that bring everything crashing down, rather the kind of failures which stop people from being productive and keep people working far harder than they need to on projects that will not live up to their potential benefit.

These are what I call Low Level Failures. Things keep working but they make people’s lives miserable and cost us money.

At the risk of depressing you too here’s what I’ve been hearing:

• A major international bank that hires new developers and leaves them for two weeks without a PC. No e-mail, no intranet access, no tool to work with. Pure waste.
• A major international ISP which is developing some new software in-house. The team leader has been complaining about internal customers who won’t come and look at the software his team are developing. Now he’s found out that the company managers want the users kept away from the software. What chance have they of delivering the right thing?
• Yet another major international bank (there are a lot of them in London) where the project manager is preventing the team doing the right thing. The code is a mess too but she doesn’t want them taking any risks. The project manager knows that if the developers leave the project is lost. What she doesn’t know is that the developers see her as the problem and if it wasn’t for one of them taking the lead nothing would happen. And if it wasn’t for this one developer encouraging the others they would have gone by now. Somebody need to help her.
• An investment house in the City were the internal customers who will use a new IT system don’t think it important enough to turn up to meetings about the new system. Why bother developing it then?
• Another international bank were the project is a mess. The manager in charge got drunk one night and confessed he knows they are in trouble but doesn’t know what to do. Good he knows there is a problem but shouldn’t he ask for help when he is sober too?
• One of the banks mentioned above work to such internal procedures that there is nothing for the developers to do. I’m coming to the conclusion that the reason companies have internal procedure and process standards is not so much to make sure work gets done but to insure that people can’t do too much damage. Won’t it be cheaper to just not hire them?
• An information supplier that decided to launch a new project. Hired an offshore development team and hired people in London for the project then had second thoughts. People started work on the project only to be told there was nothing for them to do and then get laid off. Shouldn’t they have thought this through a bit more?
• One of the banks already mentioned have a lengthy interviewing process to ensure they get good people. But it hasn’t stopped them giving a job to one of the worst developers I have ever met. This person will hold the team back, they will make more work for their colleagues. Anything they do create will be a nightmare to maintain. I can only imagine they were hired to fill head count or because the person doing the interview was incompetent. Fortunately the bank procedures will probably stop them doing any damage.

Thing is, although I’ve heard all these stories in the last few months they aren’t really new. Back in 1998 I worked for a company in the City were it took two weeks to get me a PC. When they did it was massively under powered. The support department had better PC in stock but held them in reserve in case another broke.

My point is not that failures happen in IT but that we live with so many low level failure every day. This failure saps our energy, our enthusiasm, it makes work dull and boring. In each case the situation can continue because it doesn’t cause anything to really break. No crunch moment occurs. Things are just generally bad.

These examples are mostly taken from the financial markets. There are two explanations for that. The obvious one: I live in London and talk to people who work in the financial sector but I’m sure low level failures happen everywhere.

Second, the financial markets are booming just now, banks are throwing money at projects. Consequently it is easy for a project to burn money without showing a return. And because there are so many projects there is a shortage of developers so the really bad ones get hired. Not only do they get hired but they make things worse.

There is a third explanation which is quite scary but may contain an element of truth. The people I know in IT are in general good. Perhaps they are not just good but are outstandingly good. The things we see as problems are what others see as normal. Could it be that outside of my bubble the rest of the world is used to massively inferior service and IT? I hope I am wrong here.

Its easy to say “Huh, what do I care?” but actually these companies are spending your money. One of the banks not named above may be home to your cheque account, your pension, your savings. You may be a customer of that ISP, or your pension might contain their stocks. Their waste hits you.

Am I the only one to see this? Can’t other people see these problems? What are the managers at these companies doing?

It is a double loss: the people on these project have a miserable time and we all lose money.

What now?

One, I feel better having shared the idea of low level failure with you. I will sleep better tonight having got that off my chest.

Two, there is a link between my last post about agile and these projects. Some of these projects were agile but not all of them. I will return to this subject soon.

I’m not a big TV watcher. Some nights the TV doesn’t go on in our house at all. However for the last three nights I’ve been gripped by a short series on BBC 2 called “Can Gerry Robinson Fix The NHS?”

In this program Gerry Robinson (who you might describe as a celebrity business man, guru, turn-around specialist or something similar) spent six months helping an NHS hospital. His goal was apply some business management ideas to improve the hospital. Perhaps surprisingly it made for gripping TV and was highly education. (Note to aspiring managers: don’t bother doing an MBA, beg, borrow, steal copies of this series.)

What made it so fascinating? Well many things, basically you have management on one side who are trying to, well, manage, and you have a bunch of technical specialist on the other side (doctors, nurses, etc.) and there is a great divide between the two groups. Add in a history of top-down solutions which means nobody feels empowered and you have a recipe for Do Nothing.

More than once I found myself watching thinking: this is just like IT. The medical staff are just like programmers/testers/project managers and the management are just like, well, managers.

Robinson wasn’t given any money to improve the hospital – although he did manage to get some additional money spent. Instead his tools were those of inquiry, empowerment and using his legitimacy to get people to talk to each other.

Time and time again he found people who knew how to improve something but felt nothing could be done. They felt somebody would block any change or that nobody was interested in changing. And even if they did want to change things they could not get the right people to talk together or agree to actual action. About the half way mark this seemed to get Robinson really down.

But then it turned around and things started moving. People started to feel empowered, they started to feel things could change and they did start to change them. And consequently Robinson got much happier!

Of course its difficult to tell how much this chorology actually happened and how much was constructed through judicious editing to make a good story. Either way it certainly seems that people started to feel they could change things and this led to improvements.

I found myself agreeing again and again with Robinson when he said things like “Management isn’t a mystery” and “People doing the work know the answers”. It is all about getting the people who work to actually take power and make things happen. Unfortunately management can become a block to change rather than a catalyst.

There are so many barriers to change. The first barriers are in peoples own minds. They think things can’t be changed, or others won’t agree to them. Several times in the TV series people said “Mr X won’t agree to that” only to find that Mr. X and everyone else did agree.

The next barriers are the problems other people see. They jump to assumptions and see reasons why things won’t work or why you can’t do that. Sometimes there are real reasons and sometimes imagined. Either way these blocks can kill an idea dead. When they are imagined it is a case of checking reality, maybe by asking someone else. When the problem is real it is a trigger to work around the problem, to find an alternative answer or a different way of working.

Barriers of communication existed too. People didn’t talk to each other; they assumed what they thought to be the case was. Managers didn’t talk about problems, they preferred “strategic solutions” (shuffling paper, making plans and changing structures.) Technical people sometimes wanted to do their technical thing rather than engage in conversation and tended to see anything management did as a problem.

There never seemed to be a barrier with authority, only assumed authority. Neither were resources ever a real barriers. Once or twice lots of money or construction was needed so ideas were dropped but usually that was just led to a new idea that achieved much the same success.

In most cases all that was needed was someone to show an interest, someone to lend legitimacy to the improvement ideas, someone to ask for it to be done, someone to inject a sense of urgency and occasionally someone to bang heads together and get people talking to each other. And most of all: someone to appreciate what people had done, someone to say “Thank you.”

Robinson wondered around the hospital spotting opportunities and applying this (his) philosophy to the situation. It wasn’t genius but it got results. The rest of the time he seemed to spend his time trying to persuade the hospital chief executive to do the same thing. This guy was a “big thinker” who wanted “strategic plans” (my terms not his, this is the way he appeared to me.) As a result he was out of touch with what was happening. Staff felt he was remote and nobody (except Robinson) was walking around making people feel useful and conferring legitimacy to change.

I think Robinson’s greatest success was finally persuading the chief executive to try this approach. At first the exec was sceptical (“Why do they need me?”) but once he had one win under his belt the exec was converted and saw the point and was converted. His real power lay not in making plans, re-organizing structures or signing checks but in simply asking people to do what they wanted to do.

At the end of the day it wasn’t a big plan that was required, it wasn’t a new strategy, nor was it more money and resources. It was simply a thousand little improvements and a constant attention to further improvement.

As I said at the top, a very good programme. If there was more TV like this I’d watch TV more often. I’d love to buy the DVD of this series – if anyone out there knows where I can get it let me know.

I’ve already mentioned this book in a blog entry a couple of weeks ago in this blog so it should come as no surprise that I’m recommending Strategy Bites Back.

If you have an interest in business strategy then this is an interesting book to read.  And if you know nothing about business strategy but think you should then probably this is the best book you could buy.  The book will come as no surprise to anyone familiar with The Rise and Fall of Strategic Planning– also by Henry Mintzberg – many of the same themes emerge.

In fact this might be the most enjoyable book I’ve ever read on business strategy – and yes, I have read quite a few.  The book takes a light hearted, serious and intelligent look at strategy and some of the contradictions and absurdities firms and strategy makers wrap themselves in.  Early on the authors admit they are trying to add some humour and fun to what can be a boring and all too serious subject.  There reasoning is: strategy needs to be fun, it needs to be fun so we enjoy doing it, if you don’t enjoy it then you probably won’t make any use of your strategy.

Another nice thing about the book is that it is structured as a series of short essays – or bites and bytes as the authors call them.  Some bites are just a page long, others run to several pages but none of them get overly academic.  I found quite a few of the bites offering really useful insights, either supporting something I already suspected or giving me a new idea to think about.  Two of the later bites in particular stood out.

One, from Harvey Schachter finally lays to rest the debate about whether strategy comes from the top of an organization down (lots of big brains sitting in a board room directing company activity) or whether strategy comes from the bottom up (lots of individual decisions and initiatives made by people who actually do the work and later adopted as strategy).  Actually says Schachter companies do both.  Yes the big brains in the board room have a role to play but so do the little people at the coal-face.

The book contains no less than three pieces from Jeanne Liedtka and while her “Strategy as a little black dress” may have the best title of any strategy article (ever) its her third contribution, “Strategy as the art of seduction” that really caught my attention.  She argues that for a company strategy to be effective it has to appeal to everyone in the organization, the strategy has to make them want to change and implement the strategy.  Thus, the importance of the strategy is not so much whether it is a “good strategy” or not but rather whether it motivates people.  That is: does the strategy seduce you and make you want to be part of it?

Liedtka’s argument is also an argument for involving everyone in the organization in strategy formation – something I’ve been know to argue myself in this blog.  And if your going to involve everyone in formation and execution then naturally your going to want to make strategy fun, which neatly brings us back to were this book came in.

Anyone who read my last blog entry might be wondering what it was that I found so interesting in the Sloan Management Review, well, it was this piece Generating Premium Returns on Your IT Investments which got my attention.

I’ve been running across the term IT Portfolio Management for a while now and wondering what it was all about.  You can always make an educated guess from such a term but then you risk getting it wrong or missing the important points.  Quite often IT Portfolio Management was associated with the term IT Governance which is something else I thought I should know more about.  Well, this piece on IT investment did three things: it set me straight about what is IT Portfolio Management, it inspired me to read more about IT Governance (I’ll write something about this soon) and it provided some interesting statistics about IT success.

So, what is IT Portfolio Management?  Basically it is the idea that organizations should know what IT projects they are undertaking and should review them as a whole rather than just a one at a time basis.  The idea is that while you might have four big IT projects on the go, all of which make sense in their own right, when you look at them collectively you see that two of them are doing the same thing.

Now this is one of those things that sounds obvious.  How could any reasonable company not know it was funding overlapping or even competing projects?  Yet this happens, its quite possible large companies don’t know every project that is happening, in a geographically dispersed company things get more difficult still.  Add in the way many companies distribute IT projects to business units and its quite clear that the investment group in Australia might be doing a project that looks a lot like the new business group in Sweden.

So the first step in IT Portfolio Management is simply to catalogue all your IT projects.  The next step is to review them all and then… well this is were the SMR piece is really focused.  This suggests that companies should categorise each project as: Strategic, Informational, Transactional or Infrastructure.  Each company should also decide what percentage of the IT budget to allocate to each of these types of project and use that as a management tool for managing the whole protfolio.

Well that’s the idea in a nutshell, I won’t go on about it any more.  The interesting thing that arises from this research is that the authors identify two types of company: those that are IT savvy – i.e. those that understand IT and can exploit IT – and the then those who are not IT savvy.

Those companies that are IT savvy can have higher profits the year after doing an IT project, typically $247 extra profit for every $1 invested in IT.  So for these companies doing IT project makes a lot of sense.

For the other companies, the non-IT savvy companies, the reverse is true.  Doing IT projects reduces subsequent profits, typically they make $909 profit less profit for each $1 spent on IT the year before.  In other words: these companies would be better off not doing IT projects.  (Which is worrying from a long term point of view.)

What occurs to me is that we can link all of this back to Nicholas Carr’s arguement IT Doesn’t Matter.  Carr argued that IT was no longer strategic and companies should concentrate on commodity IT.  Of course many people (including myself) took exception to this and argued the contrary.  Now perhaps we have an answer to the discussion, and its answer using one of those re-occurring business ideas: segmentation.

Carr is right, for some companies IT is not important, for those companies who are not IT savvy, they should get away from IT and find some other way to improve their business.  For other companies, namely the IT savvy ones, IT is important and can produce real benefits.

So the answer to the question: “Is IT important?” is simply; “it depends.”

Before finishing there is one more points that struck me in the Sloan piece.  One of the recommendations is: Companies should learn from post-implementation reviews and formal training.  This gives two action points.

Firstly, companies do not invest enough in IT training – typically less than 2% of the IT budget.  They optimistically think that giving someone new software is enough.  It isn’t, you need to train people in it.  I’ve lost count of how many times I’ve seen this done.  Being on the development side I hear about companies who buy software but don’t buy the training, or users who see the software as too complicated (it usually is) but can’t get any more training; or, perhaps the worst of all, the manager who believes his staff can learn a new package (or even programming language) by reading the manual.

People are great learners, they will find a way of learning new software and even complex languages so the manager are right, why spend the money?  Simply: providing the training will help it happen much, much faster.  You want your project sooner?  You want your product delivered quicker?  Want to see an improved ROI?  Then spend the money on the training, don’t leave it to trial and error and manuals.

Second point; post-implementation and in-process review help companies realise the benefits of IT projects, motivate the staff and improve organizational learning thus making the company more IT.  In other words, Retrospectives make a difference.

Too many companies talk about doing retrospectives but very very few companies actually do them.  The reasons for not doing them vary, and often when they are done they are done badly so fail to maximise the learning and change.  When they do happen and are done right they make a massive difference.

Now the question is: do you want your company to be IT savvy?  If so, start doing the retrospectives and giving people the training.  If not, then I suggest you save your money and get out of IT altogether.