‘Despite more than 50 years of history and countless methodologies, advice and books,’ noted the global research firm Gartner in 2015, ‘IT projects keep failing’. I really enjoyed this report because although it talked about the things we haven’t done to improve the profession in the past 50 years (something many commentaries do), it especially drew attention to the fact that organisations continue to make it hard for themselves.

This is something I talk about a lot when speaking to corporates. The reason organisations are burdened with 150-page business cases and endless layers of documentation is because they put them there — no one forces them to do it. They put them there because someone went on a ‘best practice’ course and decided that’s what needed to be done to provide consistency. Some put them there because they think, as a government department, it’s necessary to justify the spend. I worked in government for eight years and met regularly with auditors and regulators, who just wanted to see sound justification and be sure that sensible approaches had been adopted in delivering projects successfully, not that there were 150 pages of documentation.

In his book Agile Project Management, Jim Highsmith comments, ‘Many project management practices and project managers are focussed on compliance activities not delivery value’. Of course, the statistics prove that implementing complex processes as a means of gaining consistency of delivery doesn’t work (and never has), and that only through great people and great cultures can you achieve consistently good results. Despite this, millions of dollars continue to be wasted every year on process maturity assessments, which tell you how great the processes are that people aren’t using.

The key to a successful framework is, of course, to keep it simple and to scale it for each project.

In a 2011 blog post on Oracle’s ‘Unified Method’, Tom Spitz made three interesting observations:

• ‘Too much method can be as risky as too little.’
• ‘Don’t serve the method, make it serve you.’
• ‘The output of a task needn’t be a document.’

Inflexible methods are a thing of the past. Every project demands a unique approach. Think about what absolutely needs to be done to deliver the project successfully. Do you need a 30-page business case or can you do it more succinctly?

The same goes for your project plan. Does it need to be in a document or can you put its components on a wall (and I don’t mean a Gantt chart!) to make it visual? Do you need monthly rather than weekly meetings? Would 20-minute stand-up meetings work? If your organisation has a program management office (PMO), the greatest value it can add is in helping you create a unique and scaled approach for your project.

The methods we use to deliver our projects are a guide. You can’t shortcut the justification for a project or the need for a plan and project controls. You can, however, scale these approaches so you only ever produce what Matthew Lyon calls ‘Minimum Viable Documentation’.