About Me

I have been running IT projects and programmes for more than twenty-five years. Sometimes as an employee, more often brought in from outside, for somewhere over fifteen companies, in most parts of the world that run tenders.

Somewhere along the way I stopped being surprised.

The same mistakes kept turning up. Different countries, different industries, wildly different budgets, the same mistakes. Not exotic ones either. Ordinary, repeated, expensive mistakes that most people in the room had seen before and nobody stopped.

So I started writing them down. There are currently about 150 of them.

Why “how not to”

There are thousands of books explaining how to run a project properly. There are considerably fewer that name the specific thing you are about to do wrong.

Each entry here takes one mistake, gives it a name, and explains why it is a mistake. That last part is the work, because almost none of these look like mistakes at the time. They look like good practice. They look like common sense. Most often they look like the way things are done here.

Nobody sits down intending to approve a budget with no money against the risks, or to appoint a project manager for the wrong reasons, or to hit a date by quietly removing a third of the scope. It happens anyway, everywhere, constantly.

Who it is for

Project managers a few years into the job, who still have time to learn which mistakes are coming.

And Steering Committee members and sponsors, who are very often the ones making them, usually without realizing it. If you recognize yourself in one of these entries, that is the intention rather than an accident. It is meant as a mirror, not an accusation.

About the tone

The entries are sarcastic. The sarcasm is there to make a point land, not to complain.

Anybody can write that meetings are pointless and middle management is useless. That is a genre, and it is a different one. Every entry here is about a specific named mistake, why it happens, and what would have prevented it.

Underneath all of them is one idea, which is that project management is mostly about influencing the future.

Issues are the past. Risks are the future. Actuals are the past. Forecast is the future. A great deal of what goes wrong on projects goes wrong because the people in charge are looking backwards, at the things that have already happened and can already be audited, rather than at the things that have not happened yet and still can be changed.

How this is made

The topics, issues and recommendations come entirely from my own experience. I draft the content myself and then use AI tools interactively, through several iterations, to find the right wording.

Nothing is being sold here. There is no framework at the end of it, no maturity model, and nothing to download.

If something in here is useful, take it to your next Steering Committee.