Keep It Simple…

“Nothing is particularly hard if you divide it into small jobs.” – Henry Ford

In the foreword to my first book, I described an interview in Houston that led me to a significant challenge in terms of executing a new project, with the punchline from my soon-to-be new boss: “You need to tell me if you can’t do it in a year. You seem like a really good guy, and I’d hate to have to fire you.” It seemed, at first sight, to be an impossibly short timescale, but I realised that the project could be delivered on time if I simply created the right process by applying all the lessons learned during my decades of delivering innovation. Things turned out well – we delivered the working prototype in eleven months, not the challenged twelve, leading to an important commercial success for the organisation. One key contributor to the velocity with which we were able to deliver was the process we used. And I’ve always believed that the process should be kept as simple as possible.

A couple of decades ago, I was responsible for the project management function for a large multinational company involved in engineering, procurement, construction, and installation (EPCI). Part of my role was teaching the basics of project management to new graduates as they came through the company as part of their structured training program. I’m not a big fan of dry PowerPoint presentations, so I used to open the training sessions by talking about the 2000 movie Gone in Sixty Seconds which had just been in cinemas at the time, and which was fresh in everybody’s mind. The movie told the story of an experienced car thief, played by Nicolas Cage, who was engaged by a British gangster (Christopher Ecclestone) to steal fifty cars within seventy-two hours. Using the plot of the movie as the background to our discussions, we were able to discuss how this could essentially be thought of as a project with a defined scope (customer need – in this case stolen cars) and a deadline for completion. It showed how a project team was built by Cage’s character to provide him with all the specialised skills (capabilities) that he would need. And for good measure, the brother of the character played by Cage was held hostage by the gang under the threat of being killed if the cars were not delivered on time. So, the movie even introduced the concept of an interested stakeholder who was not directly involved! My aim in using the movie was twofold. Firstly, to make the discussion more entertaining and memorable. But secondly, to show that many things can be thought of as projects and that project management does not have to be scary, complex, or inaccessible.

Now, I think one of the reasons my training classes worked was because they looked at project management at a high level and kept things very simple. For many of the projects you undertake, you can use equally simple principles and techniques to manage the project; I just think that simple things are easier to understand and therefore much more likely to succeed.

However, for some projects – including the EPCI projects for which I was responsible at the time and for other “megaprojects” such as large infrastructure projects – a simple approach will not really work, on the face of it, and surely you are forced to get into a lot of detail? Not necessarily, and in fact I’ll be controversial here and suggest that large, complex plans can be counterproductive. Unfortunately, as relayed in a 2021 article by Bent Flyvbjerg, those large projects are often associated with failure, at least in part because of external events that can impact them during the (inevitably long) duration of the project schedule. My first book went into some detail about how to manage, or at least mitigate, uncertainty about the future but Flyvbjerg described another, elegant and effective, solution: simply to make your projects modular. Break them down into small pieces. He suggested aiming to apply known solutions in modular ways and learning on the hoof, improving project performance “with every iteration”. The image at the top of this post shows the Madrid Metro, which Flyvberg gave as an example of a modular project – suggesting that if a project as bespoke as this could be made modular, then so could pretty much any other project, and he implored the reader to “keep it short”. Modular and iterative is a great philosophy as described below.

In my second book I highlight what I think are the most important principles you need to follow when developing new products or services and give you my basic recipe for success – which you can build on and customise to ensure your own.

One example: when I was challenged with delivering that new product in Houston, I could have sat down and written a detailed project plan – but I didn’t. I could have implemented and used a “waterfall”, or “stage-gate”, process with a set of well-defined linear activities – but I didn’t. I didn’t use such a technique because it is only good if you have a well-defined, fixed scope and if, as a direct result of the fixed (and inflexible) scope, you are able to accept what will inevitably be a variable time and budget. I had the opposite. I had a firmly fixed, non-negotiable timescale and the scope was still poorly defined.

So, I divided the project into blocks of one month at a time. For the duration of each block, I focused on what had to be achieved during whatever the current month happened to be – while of course keeping an eye on the long-term goals of the project as they evolved and having an idea of roughly how much had to be achieved per month to hit that twelve-month target. As a team, we never worried too much about what was going to happen in subsequent blocks, we just made sure that we always hit our immediate monthly targets. For example, in the first month we needed to gather customer input to inform our specification, we needed to make some basic design decisions and we needed to recruit and form the team. Nothing else had to be done during the first month but we realised that if we did not achieve those three things, we would not finish the project on time (and I would be out of a job). Of course, those three things represent requirements, ideation, and team/culture building – all of which are covered in different chapters of the new book. While we were focused on those three things, we didn’t really need to know what the rest of the project would look like. That could come later. In addition, our understanding of requirements was not fully formed by the end of the first month. It continued to change as the year went by. This meant that our response had to be flexible, and this approach required a very different way of thinking from the conventional “waterfall” project management that many of us are taught.

Some readers might recognise elements of what I described above as borrowing from the Agile process that is often used for software development (Project Management Institute, 2017). I like Agile, because it is much more effective than more traditional processes for development of new products and services whenever there is uncertainty about the future or shifting and changing requirements (which is effectively always). It can be a particularly useful tool for smaller companies and new entrants to use to introduce disruptive technologies and can allow much more rapid and nimble responses to changes in market conditions than is allowed by the waterfall processes used by many established companies.

There’s a lot more in my latest book about waterfall and Agile, and what they mean – but in case you’re in any doubt about how not to manage projects, a quick word on how not to do it. In 1944, towards the end of the Second World War, the United States Office of Strategic Services (the forerunner of the Central Intelligence Agency) published a booklet suggesting ways for civilians to sabotage economic activity in enemy countries. Now declassified, it is available in the United States Homeland Security Digital Library. It suggests how to sabotage industrial activities, transportation systems, buildings and so on but has an interesting section on “organisations and conferences”. Among the suggestions therein:

  • “Never permit short-cuts to be taken”
  • “Refer all matters… for further study and consideration”
  • “Advocate caution… and urge [your colleagues] to avoid haste which might result in embarrassments or difficulties later on”
  • “Question whether [any proposed action] is within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon”.

Remember, these were activities specifically designed to interfere with the workings of a targeted foreign economy. How many of them do you recognise from the processes employed by organisations you have worked in – or perhaps still do? Any behaviours like these – advocating caution, questioning authority of the group to make its own decisions – will usually tend to slow down innovation and act in the interests of your competitors.

Keep it simple, don’t worry too much about the detail that lies ahead – and avoid being over-cautious. If you’re going to succeed at innovation you will need to develop a tolerance for controlled risk and you will need to be able to celebrate failure – of which more in a future post.

Want to Know More?

The second volume of my book: Strategy and Innovation for a Changing World – Part 2: Sustainability Through Velocity covers these topics in much more detail in Chapter 6: “Getting it Done: Doing Things Right (and Quickly). I hope this excerpt has left you interested in reading more!

References and Further Reading

Project Management Institute. (2017). Agile Practice Guide. Newtown Square: Project Management Institute, Inc.

Flyvbjerg, B. (2021, December 15). How to Slash Megaprojects Cost While Boosting Delivery Speed.

IMDb. (n.d.). Gone in Sixty Seconds (2000).

United States Office of Strategic Services. (1944, January 17). Simple Sabotage Field Manual.


© 2022 J M Clegg Ltd

Image © JackF –