Pin Me

The Case for KISS: Keeping It Simple in a Complex Environment

written by: Ray Ahern • edited by: Michele McDonough • updated: 5/29/2013

It's so easy for project managers to fall into the trap of over-complicating their planning and structures and losing sight of some basic fundamentals. Whilst it may seem counter-intuitive, the bigger the project, the simpler you should keep the planning and controls!

  • slide 1 of 7

    Galloping Bureaucracy, the Fastest Moving Thing in a Large Organization!

    Buried Alive I’ve watched several large organizations struggle with delivering complex projects and every time they have a failure, they seem to determine that more information was needed; that people obviously didn’t get how complex the job was! This is particularly true in government agencies and large private enterprises where cultures of fear and blame tend to dominate the management landscape.

    I would like to present a counter argument. I argue that most often these complex projects fail because they forgot the very simple things, not because they couldn’t deal with complexity.

    Time and time again I’ve seen complex, sophisticated projects where no one could even state the cost, timelines or key quality expectations. I see projects where it is impossible to tell who is in charge, who holds the change authority and even who is paying.

    These sound like gross failures, but they are indeed understandable. I will argue that these projects become so absorbed in the detail that they simply forget to manage the simple stuff. Yet, it is almost invariably these basics that destroy projects.

    Instead of applying this logic, what we see from organizations in damage control mode, is the creation of even more complex sets of plans, a more complex approval process and greater reporting requirements. Less trust, more control and less imagination are the inevitable consequences, teamed with further failure. This leads to a further search for the missing plan, the one that would have saved us, and inevitably led to even greater failure. I once described this phenomenon in a Senate Inquiry as Planacea – a search for that one ultimate plan that will solve all our problems and save us from having to think.

  • slide 2 of 7

    The Money Myth

    Money Let’s take a look at some basic figures. They say 78.2% of statistics are made up on the spot, and I’m about to do exactly that. I’d hazard a guess that most, probably 99% or more, project managers will have been in charge of projects no greater than say $20 million. I suspect you could add to this that most project managers probably earn less than $200,000 per year. That’s certainly true in Australia and I would think also the case in the US from my perusal of the market.

    So it shouldn’t be a surprise that the average bunny can’t even begin to comprehend what a billion dollars is. As project managers, our first reaction is likely, "Wow, you’d need really sophisticated plans for that project!’ Executives often have similar responses and, seeing the wall of money in front of them, they try to cover their butts with the above described Planacea.

    In any case there is always this assumption that if we're spending more money, we need more pages of documents. This logic is fundamentally flawed and will itself lead to disaster more times than not.

  • slide 3 of 7

    The 20 Pounder Syndrome

    Armstrong 20 Pounder Now, let me be clear, I'm not calling you stupid if you've fallen for this trap; my first reaction was exactly the same when I consulted on a project of that value. I can’t name the project because of client confidentiality, national security and all that stuff unfortunately, but it suffices to say it was a complex, defense-related project.

    It turned out to be completely the opposite of the truth. The project was suffering from what I like to call “20 pounder syndrome." This is based on the premise that few sane people will ever read 20 pounds of documents (by weight) in a year, let alone in the few days leading up to project approval. Yet this is what was expected of stakeholders to "gain an adequate understanding."

    The summary documents alone that were presented to the project board topped two "Lever Arch" files and had numerous hyperlinks available for more detail.

  • slide 4 of 7

    Wading on in There

    As a consultant, my first job was to find out why all the stakeholders seemed to be on different planets, let alone different pages. So, I quizzed ten key stakeholders about a few key questions of the project. What it was doing, how much it would cost, how long it would take and what the key risks were. Again it suffices to say that no two answers matched! At this stage of my investigations, I didn’t care what the technical truth was; I wanted to know if the stakeholders had common views.

    A stranger thing happened next though – I worked to extract those details from the project manager and the document set that existed. Not only did this exercise take quite a long time, it turned out the answers were different from any of those given to me by the stakeholders.

  • slide 5 of 7

    Staggering Simplicity at Work

    Over the following few weeks on that project, I worked with the project manager and some key stakeholders to produce something much simpler but in many ways harder to produce – a project plan that had to be less than 15 pages. That plan had to include:

    • A one-sentence statement of objectives
    • A "dot-point" scope statement
    • The dot-point desired end-state of the project
    • A summary of the schedule showing no more than 4 milestones per year
    • A single paragraph summary of the technical solution (which we hyperlinked to the remaining 50 pounds of documents!)
    • A list of the top three risks
    • A list of constraints and assumptions
    • A page listing the 30 most important products that would be created by the project, when they would start production and when they would be ready.

    Then of course, we did need a project schedule. This is where I insisted on doing something different. Rather than a complex but flawed and meaningless Gantt chart printed on several enormous pieces of paper (as the previous attempt had been), the project manager and I created a genuine “back-of-the-envelope" diagram of the schedule. Yes, by pure accident there was no clean paper on hand, so I picked up a large, used envelope and we started drawing. A photocopy of this diagram in rough form was copied for all board members, just to give them the flavor that it was "for discussion."

    The project manager verbally conveyed this to the project board using only a whiteboard and the effect was astounding! The enthusiasm levels in the room were through the roof and, whilst there were only a few changes to the original, the schedule was agreed and base-lined on the spot. Such was the clarity of the presentation and the ensuing problems the project faced, that 'back-of-the-envelope plan" became a favorite saying of one of the executives who was on the board.

  • slide 6 of 7

    Don't Encourage Him!

    After the immediate success of this little experiment, we got truly carried away. The previous attempts at a business case had been very muddled affairs that mixed up a range of options with technical gobbledygook and waffle, so we created a "Final Business Case" that I insisted should be less than four pages. The business case had a very simple outline:

    • Strategic imperative (how this project fits with corporate objectives)
    • A paragraph on background
    • A list of the five main benefits of the project
    • A summary of the anticipated costs associated with the project and their spread
    • A list of the top 5 risks to achieving the business case
    • An "Investment Summary" which summarized whether the project was worth doing

    As well as this we created a two page Communications Plan and a five page First Stage Plan which has a slightly deeper look at what would be happening in the first five months or so.

    I know there was more that we could do, but we were keen to make a point of how slim the documents could be. This really hit the spot with the project and highlighted that the project as planned could not be done within the existing budget. A compromise was reached, further approval sought and suddenly we had a realistic budget to scope ratio.

  • slide 7 of 7

    Queueing up for the Credit

    As time went past the stakeholders came to understand that, at its core, this project was actually a fairly simple project. Sure there was a heap of rocket science going on in the background, but essentially it was delivering and supporting some pieces of equipment. The trick is that we left the rocket science to the rocket scientists and spent our time being managers instead.

    The project for all its complexity was delivered on time and close to on budget, a rarity for defense projects anywhere. The project manager is now the ultimate KISS zealot and has gone on to have a very successful career.

    Of course, people lined up from far and wide to claim the success including, ironically, one person who had just written some more complex engineering procedures who claimed it in their newsletter as a "win for engineering excellence." Well perhaps it was that the project manager wasn't trying to be the engineer, but I would claim otherwise. Oh well, you can't convince everyone of every thing!


  • Money Image:
  • OGC (Office of Government Commerce) (2009). Managing Successful Projects with PRINCE2 (2009 ed.). TSO (The Stationery Office) -ISBN 9780113310593
  • Armstrong 20 Pounder Image: Wikimedia Commons under public domain license.
  • PMI (Project Management Institute) (2008). A Guide to the Project Management Body of Knowledge (Fourth Edition). PMI - ISBN 9781933890517
  • Buried Alive Image: