Do we learn from our mistakes?

This is the time of the year when a lot of us spend a little time reviewing how well we did last year and what we plan to do this year. As you may have noticed, I’m making my plans a little more obvious this year. Before we get too committed to the planning process we should ask ourselves:
Do we learn from our mistakes?
Because if we don’t, or at least if we don’t try to learn from our mistakes, then the activity is essentially futile and we would be better doing something else instead.
I think that the IT industry is particularly bad at this. We have very little sense of history. We claim to be making progress – but are we?
Here is one person’s attempt to write down an outline of that history. I can’t say I agree with it entirely. In fact I haven’t really tested it critically. But do think that it is a worthwhile effort to present one view of that history.

Why do I think the IT industry is bad at learning from it’s mistakes?

Why do I think the IT industry is bad at learning from its mistakes? Basically, I think this because I frequently get a feeling that “I’ve seen this before”. Now there is no doubt that a lot of progress has been made. A lot of that progress is down to “Moore’s Law” which has enabled whole industries to sprout, bloom and flourish.
The reducing cost of hardware in general and processing power, storage and communications has enabled things to happen which while they were conceivable, were hardly practical just a few years ago. This blog and the thousands like it are an example of that.
But, if you look at various internet forums as I do, you will find recurring themes which I am going to share with you here and I may pick up as topics at some time in the future. The thing is that many of these meta-topics have been running for donkey’s years!
  • How do we write “requirements” so they are understood by the people who want the system and also by the people who are going to build the system?
  • How do we create things so that people get what they are expecting?
  • How do we estimate how long it is going to take us to do (practically anything)?
  • How do we manage a project so that it comes in “to specification, on time and on budget”?
  • How do we prevent “silly little bugs” creeping into the system?
Maybe you have some ideas for other topics in the same area, or maybe you have some solutions to some of these conundrums.

Wheels within wheels, plans within plans, but we do need action!

A week ago I shared the front page of the strategic plan for my business with you. Plans are all very well but what we really need is action, but of course we need controlled action which is moving us towards the objective.

With this in mind, I created what I’ve described as a “Tactical Plan” which I’m going to share with you. The tactical plan sets out an objective and some projects I am going to be working on for the first 3 months of 2015. I’ve included a redacted plan below. I first heard the word “redacted” in association with US Government documents. I think I would probably use the word “censored” instead. By-the way the Russian word for “editor” is “redactor” (редактор). I’m not sure if that is one of the little tricks laguages play on us, or whether it tells me anything about the Russian attitude to editing.

That really is all there is to the Tactical Plan. It is pinned to the wall in my office and it reminds me what I am achieving at the moment. It helps me to focus and keeps me from getting distracted. Of course, there are more detailed plans as well.

As you can see from the redacted plan, I have an objective, an end date and three projects. The three projects are addressing areas which I know need work: Product and Marketing are hardy perennials and in this case I felt it was time to do a bit of spring-cleaning in the thing I use for the detailed plans and tracking. I may show you that some time in the future.