Two of the biggest project failures I have seen had also produced the most documentation I have seen. I don't think it was a coincidence.  I'm not arguing for a direct causal link between project failure and volume of documentation, but I am arguing that a mindset that focuses on recording everything to the nth degree is not a mindset that is focused on achieving business outcomes.  In this article I want to suggest how to strike the right balance between artifacts and outcomes. Both projects mentioned above (I saved one and closed down the other) had expended more effort producing artifacts than usable deliverables.  One of the projects was genuinely business critical, so there were consequences over and above wasted money and time.  The project leadership was out of its depth and had resorted to micro-management and reporting as a way of creating a facade of useful progress.  The other project was an expensive folly that should not have been allowed to happen.  Follies always lack true customer demand and can do a lot of expensive meandering before the game is up.  Producing large volumes of documentation is a make-work activity often used to hide the truth, but it can only work for so long.

By comparison with the failures mentioned above, two of the biggest and most successful transformation initiatives that I worked on (the rescue of Lloyds of London and the automation of trading at the London International Financial Futures and Options Exchange) produced the fewest project artifacts relative to the scope of their change (which by definition was significant and market wide).  Again, I don’t think this was a coincidence.  What was noticeable about those initiatives was the overwhelming need for change, the clarity of thinking about the change, and a strong focus on results (as opposed to a strong focus on process and reporting).  The pressing internal and external demands meant that we didn't have time to be recording what everyone was doing at a sub-atomic level - and who would have cared about that stuff anyway if we had failed to deliver the required outcome?  Leadership and delivery was achieved through many to many communication, rather than by compiling reports from the bottom up and re-cascading that information back down. I am not arguing against producing some documentation.  Of course not.

What I am arguing for is only producing documentation that helps to achieve the outcome and reduces the risk of failure. 

Useful documents include anything that defines and communicates goals, objectives, approach, deliverables, timescales, organisation, cost, and resources; a simple business case where evidence (not just opinions) is presented for the benefits that will be accrued and the costs that will be incurred; and a high level project plan - even if delivery is to be advanced through iterative agile approaches.  Some form of progress reporting is usually helpful, but it shouldn’t require a PMO the size of Belgium to produce it.  One person (preferably the leader) should be able to write a report on the overall progress of any project (no matter how big) on a Friday afternoon that tells people what they really need to know right now. Nobody has time to read anything longer than a page anyway so who are you trying to impress by producing a 50 page slide-deck?  With agile methods such as Scrum it is the arrival of the ‘potentially shippable product’ at the end of each sprint that is the true progress report.  If the product doesn't appear then progress is less than planned and changes need to be made.  The ability to touch and feel real progress rather than view proxies for progress is one of the outstanding advantages of agile methods. As well as overblown progress reports, other documentation that should be treated with suspicion and subjected to the acid test includes multi-page Gantt charts written at very low levels of detail; task lists that are not needed by the people doing the real work; spreadsheets breaking low level tasks down to actual costs that are cheaper than a visit to Starbucks (other coffee shops are available...). That doesn’t mean these documents should never be used, but my experience shows that you should question the motives of people producing such documentation.  If that is their only job then their motives are not necessarily aligned with those of the customer.  Bottom up aggregation of low level information produced by multiple projects in a large programme is another growing make-work industry.  Programmes - like projects - can and should always be reported from the top down.  Not only is it much cheaper to do that, but it also forces a focus on what really matters - outcomes. Personally, I avoid producing unnecessary documentation by doing all of my projects and programmes in a top-down manner. Taking this approach, I start with the required outcome (putting a lot of effort into making sure that it is fully defined, understood and agreed), and then work out the shortest possible route and smallest amount of effort to get there.  Wherever possible I produce usable interim deliverables along the way (a good way of reducing risk by flushing out misunderstandings). I always try to avoid task level planning as far as possible - preferring to let teams define their outputs at the work package level and leaving them to work out their own tasks if it helps them to do so.  As long as teams and individuals have a firm grasp on the required output, defining tasks is usually unnecessary. If you have hired the right people with the right skills, they should not need a project manager to give them a task list.  It's the difference between a competent artist and painting by numbers.  You don't need a team full of Picasso's (a whole different set of problems), but you do need people who know how to produce a usable set of graphics. Some documents are true deliverables so don’t stop producing them after reading this article!  They include anything needed to analyse problems and produce designs and solutions; anything needed by operations teams to run and maintain the new service; product documentation; contracts with suppliers etc.

To conclude...

In summary, documentation for documentation's sake is a feature of bad projects. Producing high quality deliverables and outcomes with the minimum of extraneous effort and documentation is a feature of good projects.  Agile methods like Scrum were invented to avoid these problems, but even they can be smothered by unnecessary artifacts if they are not operated by people who truly buy into agile principles.  And finally, the biggest change that is required is not a change of process, it is a change of mindset.  Once you start from the point of only doing stuff that genuinely delivers outcomes you will be amazed how little documentation is required.  I am always happy to help if you get in touch.

  • To visit Cliff Moyce’s new website , please click here

Image Source: Thanks to for the original image.


If you’re seeking advice on outsourcing and implementing systems development staff for your organisation please contact Jenrick IT on 01932 245 500.