Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
1 December 2009

The perils of PowerPoint

By Andrew Clifford

A compelling PowerPoint presentation is no substitute for proper systems design and project plans.

In theory, there are two ways to run a systems development project.

In traditional waterfall methods, you create formal documents at stages in the project to record the analysis and design, and get them signed off.

In more modern agile methods, you do away with much of the formal documentation. In its place, you collaborate closely with users and deliver working code frequently.

In practice, it is not like that.

Waterfall methods break. The rigid methods and documents are too cumbersome, they take too long, and are abandoned. Except in some organisations, where the methods are followed so rigorously that the whole process gets clogged up and everything is late.

Agile methods go wrong too. The user collaboration and frequent delivery does not happen. The agile mindset has not really taken hold. People just try delivering systems in a rush without proper process and controls.

Either way, the design process breaks. But there is still a need to get management to agree to the design to continue funding the work.

This is where PowerPoint steps in so dangerously. (I am not Microsoft-bashing. I use Impress, and the same applies.)

PowerPoint is an excellent tool for gaining agreement. With PowerPoint you do not need to show the detail — just a few references to strategic imperatives, some nice graphics, a few charts. With a bit of clever PowerPoint, you can get management to agree, and the project can continue.

But the problem with this is that the project has not had a proper design review or sign off, because you have not got a proper design. You have convinced someone to give you money, but not on the basis of any substance.

The thing we forget is that waterfall method documents and agile method processes are primarily about design, not about agreement.

The same happens in project management. A convincing PowerPoint is no substitute for realistic planning and project management engagement.

So, if you are using PowerPoint, do not ask yourself, "Will they agree?". They probably will.

Instead, ask yourself, "Can I back this up?" Have you carried out and documented the detailed design? Have you got working code and happy users? Is your plan realistic and have you got the project management organised?

Because if you get agreement, but have not got the substance to back it up, it will come back to bite you. The remainder of the project will be full of misery as you try to bridge the gap between reality and the unrealistic expectations that you set.

And if you are shown a PowerPoint presentation, ask for the detailed documents and plans that back it up. If the presenter does not have any, or they are "still working on it", they will not have thought through the design and plans, and you should not believe a word of what they say. If you agree solely on the basis of the PowerPoint, you will be deeply disappointed with the result.

Of course this is hard. It has to be. IT is hard. But the sooner we wean ourselves off "IT as presentation" to "IT as substance", the better.

Next: Rigorous testing


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more