5 Lessons I learned writing a book about learning lessons

I recently published my book Learning Lessons from Projects: How it works, why it goes wrong, and how you can do it better.


My former colleague Andrew Fleming commented “Well done on the book. What lessons did you learn from writing it?”

As that’s a really good question, I thought I’d answer it properly in the form of this blog post.

So what did I learn? Here are my top five learning points.

1.     Do your homework

What kind of book do you want to write? Is it an opinion piece? A how-to guide? An academic, theoretical explainer? You need to decide what the overall premise of the book is, and the general tone. I wanted to write a book providing pragmatic pointers on things that people can do the day after reading the book to improve the way they learn lessons from projects. I wanted this to be based on a better understanding of how organisations learn from projects and how this can go wrong. I wanted the tone of voice to be conversational and friendly, so I decided to write it less like a stuffy textbook and more like the way I would speak to one of my peers.

Once you have decided that, you need to do some research to see if the book you want to write has already been written. This part of the process is very open-ended. Obviously it’s probably not possible to read all the other books in existence on your chosen subject, but it should be possible to establish how much competition there is in the area. You may need to buy a few books or get them out of the library to ascertain whether it is still worth writing your book.

I found a few that were similar to what I wanted to say. But they had been written some time ago and had less of an emphasis on the practical advice side, so there was still value in me writing my book.

2.     Structure your thoughts

I started by collecting together all the articles I had written on the subject of lessons learned (which turned out to be quite a few), and dumped them all into one large document, just to see what kind of size of book that would give me and how much work there would be to do! I was pleasantly surprised that there were about 20,000 words, which equates to about 100 pages at an A5 page size in 10 point text. So, I already had something that was the approximate size and shape of a book. Of course there was considerable overlap which all had to be removed, and the topics didn’t flow at all.

So how to approach it? I decided that I needed some sort of framework to “hang” my thoughts on. So I started thinking, and came up with a description of the organisational project lesson learning process based on my experience of working in both project delivery teams and leading an enterprise PMO.

Having devised my framework, I came across a model that had already been in existence for quite some time. Although it made perfect sense to me, that model looked nothing like mine. Was my framework wrong? No, that made perfect sense to me too, and described my experience very well. So what was going on? After a couple of weeks mental wrestling, it dawned on me that the difference was one of perspective. The existing model looked at project lessons from the perspective of an organisation learning lessons from multiple projects at one time (or “outside in”). My framework looked at the process of lessons being learned from a single project, and applied on another single project (or “inside out”). Both were correct, just looking at things in a different way.

Then I needed to think about how to package my advice. I knew I wanted to cover how it generally works and how it can go wrong, before imparting what I had learned and giving detailed instructions on how to build a few systems.

But even that includes options.

I could have large sections for How it works, How it goes wrong, and How to do it better, including in each of these a section for each stage, like this:

  • How it works
    • Stage 1
    • Stage 2
    • Stage 3
  • How it goes wrong
    • Stage 1
    • Stage 2
    • Stage 3
  • How we can do it better
    • Stage 1
    • Stage 2
    • Stage 3

Or I could have sections for each stage, including in each of these a section on How it works, How it goes wrong, and How to do it better, like this:

  • Stage 1
    • How it works
    • How it goes wrong
    • How we can do it better
  • Stage 2
    • How it works
    • How it goes wrong
    • How we can do it better
  • Stage 3
    • How it works
    • How it goes wrong
    • How we can do it better

And then I had some suggestions that hit several problems at once. And some detailed and lengthy instructions on how to build some of the Do-It-Yourself solutions. Where to put those?

In the end, I went with How it works as a section (containing brief explanations of each process stage), and then Where and why it goes wrong (and how we can fix it) with the stages inside it, and suggestions on how to improve things at each stage (while the problems of that stage are still fresh in the reader’s mind). I gave suggestions that hit several stages at once their own section Some practical suggestions on how to learn lessons from projects better, and moved detailed instructions on facilitation techniques and how to build your own lessons repository into their own appendices (to avoid the sections that otherwise would have contained them becoming disproportionately bloated).

3.     Writing a book takes serious focus

I think I already knew this, but it’s worth saying it anyway.

I didn’t want the process of writing to interfere with either work or family life, so I decided to do it during my daily rail commute – a period that would otherwise be spent reading a newspaper. I generally spend about half an hour on the train on the way in to work, and the same again on the way back. I had already been using my commuting time for writing blog posts and articles, but now I would use it for something bigger.

It took me about a year of commuting to get from the idea to pressing the “publish” button. I could have got bored or given up at any point during that period, but I stayed focused on my objective, and I’m glad I did.

4.     Polishing to perfection, or publishing pragmatism?

Once I had finished the first draft, I sent it to about ten of my suitably-qualified friends. Their comments improved the quality of the book considerably, but the review process took longer than I thought it would. Some of the comments directly contradicted each other, and addressing some of them would have taken more time and effort than I was able to devote to the book.

At first, it was possible to achieve significant improvement with relatively little effort, but as the review process went on, the ratio of effort to benefit worsened. It felt something like the Pareto principle: I resolved the first 80% of the comments with about 20% of the total effort; whilst achieving the remaining 20% of the benefits would have consumed the remaining 80% of the total effort (i.e. four times as much effort as it took to fix the first 20%). I like things to be right, so it was tempting to implement every change, no matter how onerous. But if I had done that with all of them, I would probably never have published a book.

So I faced a decision – how good is “good enough”?

Should I:

  • Continue polishing the book to perfection, knowing that I may never complete it, or
  • Publish what I had, knowing that it may still contain things that should be fixed, and make any necessary changes as I became aware of them?

In the end, I took the view having been through a fairly rigorous review process from a panel of expert practitioners, any problems remaining in the text were probably small enough to be tolerable, and I would fix them on the fly.

5.     The actual publishing process is fiddly but straightforward

I spoke to a publishing friend about approaching a publisher, and decided to go down a self-publishing route as I’m expecting only relatively modest sales volumes, and a publisher doesn’t actually help very much at that end of the market (so I’m told).

The process is actually fairly simple. You upload a word processor document (formatted to the publisher’s guidelines); this is the source material for both an e-reader and a paperback version. You choose from a range of options on royalties, distribution and pricing. You upload a cover design (I designed this myself in standard business presentation software using a photo I took on my phone). The publisher runs a few automated checks on everything you have uploaded, and then before you know it the book is live on their web store.

You can order proof copies to make sure everything looks OK in print. I did this and it was well worthwhile as some things looked quite different on paper from the way they had looked on the screen. My proof copy is covered in notes, and I made several small but significant changes as a result of reviewing it.

Once the book is live, you can change the price, change the contents or cover, or change the way the book is described on the site. I did this several times in the first few days as I spotted various problems. Each time you make a change, it takes effect within about 24 hours or so as the publisher does not keep any stock of printed copies, but instead prints each copy on demand as it is ordered.

Conclusion

I wrote my book with several aims in mind:

  1. To look at how organisations learn lessons from projects, unpick the process a bit, work out some reasons why it goes wrong currently, and offer to PM practitioners some practical tips and tools to help them do it better.
  2. To build my brand in my marketplace. I am a “one-man band” company. I work typically six month contracts with a client. If I do a good job, I may get my contract renewed a few times and then I have to find something new. So I need to constantly market myself and my company. When people Google “Ken Burrell Pragmatic PMO”, I want them to find: someone who takes his work seriously and cares about it enough to write a book about it, publish it himself, and do talks about it to people; someone who shares knowledge and experience with others; someone who is capable of stringing together quite a lot of sentences in good English, and has been verifiably doing all of the above for a number of years. In this sense, a book is like a really thick business card (that you can also buy on Amazon!).
  3. To scratch an itch, for a bit of fun, and to prove to myself I could do it. I enjoy writing and I’ve always fancied writing a book. When I had a spirited conversation with someone at PMO FlashMob about Lessons Learned, he said to me “You’ve clearly thought about this a lot – you should write a book!” I rose to the challenge and got stuck in.
  4. To tick an item off my (admittedly somewhat nerdy) bucket list. I’m not really into sailing oceans single-handedly, running up and down mountains, or jumping out of perfectly operational planes strapped to a oversized handkerchief, but so far I have:
    1. Had my own engineering research published in a journal (here and here)
    2. Been named as a co-inventor on a GB and European patent
    3. Given talks to the Institute of Brewing (on my engineering research work) and the Association of Project Management (on Lessons Learned)
    4. Performed on stage to an audience of ~1000 people (guitar, bass, vocals)
    5. Made an electric bass guitar and an electro-acoustic mandolin (pictures are in the book) from lumps of wood
    6. And now, written a book, published it and sold copies (probably some of them to people I don’t even know!)

I’m glad I wrote the book, and I feel richer in experience as a result. I believe I have achieved all the aims I had at the outset, learned a few things and made some new friends in the process.

I now have a spare time slot in my diary on my commute.

Hmmm.

What shall I write about next…?

Author: Ken Burrell

Ken Burrell is a Programme and Portfolio Office (PMO) Professional, who through his company Pragmatic PMO makes targeted improvements to PMO practices to add value to Projects, Programmes and Portfolios. He provides senior management with the analysis they need to make decisions, and gives project and programme managers the support they need to deliver solutions.

2 thoughts on “5 Lessons I learned writing a book about learning lessons”

  1. That was a very interesting insight into the background of your book. Thank you for your honest and inspiring words.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.