Why do projects fail?

… and how easy is project recovery? Project failure facts and figures are in the eye of the beholder unless the statistics are granulated into a level that explains the exact science behind the numbers. Failure percentages vary from 40 to 80 percent and are, logically and primarily, based on qualitative information gathered through interviews. This percent of failed projects, whether it be 40 or 80, is a tragedy and is an indication that the project management profession as a whole has a lot of work to do in the times to come! But which are the main reasons why projects fail? Through studies of three similar analyses conducted within

When Scrum fails

David Andersen used his Meetup talk i Oslo last week to describe a start-up’s journey from Scrum to a more Kanban based way of doing things. I seldom work with start-ups, but David’s talk resonated with my experiences in contexts that have little do do with start-ups. I summarized the insight in a tweet: “The Meetup with @agilemanager yesterday reinforced my belief that Scrum works best when you are in a state that you should avoid being in” I freely admit that as tweets go, this one is pretty cryptic. A lot of people did not understand what I meant. Others stumbled into false logic and thought I was implying

Failure demand in software

A lot of people seem to like John Seddon’s concept of failure demand. Me too. But Seddon mostly talks about service delivery in areas such as call centers and housing repairs. I tend to work with software development organizations. When Seddon mentions IT, it is in the context of how the workflow systems we create end up reducing the quality of service delivery in call centers and housing repairs. After having used a number of different workflow systems over the years I too have come to the conclusion that most of them are counterproductive. But what about software development itself? Can the idea of failure demand be applied to software

Are estimates worthless?

If you take a picture while on vacation, is that picture yours? You are probably thinking: “What a stupid question. Of course it is mine!” But what if a stranger had asked you to take a picture of her with her camera? Is the picture still yours?

The second death of agile

The 10 year anniversary of the agile manifesto has just passed. As part of some kind of distributed retrospective, there has been a lot of discussion about what will happen with agile now. I think that agile will be dead in ten years – I just hope it will be a good death. This will actually be the second death of agile, but I need to set some other things in context before describing the first one.

Standardized work versus checklists

Atul Gawande has written a fascinating book called The Checklist Manifesto. The core message in this book is that many professions have advanced to an unprecedented level of sophistication and complexity. The main obstacle in getting optimal results is increasingly the practitioners ability to remember which things to do and when to do them. Atul proposes a simple but effective tool to alleviate this problem: checklists. The idea is of course not new, people have been writing checklists for ages. What makes the book interesting is Atul’s journey through a number of professions in search of insights into how to create useful checklists. The difference between a good checklist and

Three perspectives on better software

The agile perspective When the agile manifesto was published a decade ago I welcomed it. I had been building applications for a decade pretty much according to the principles in the manifesto. During this period I had watched in horror as RUP quickly became a de-facto standard. It was such a derailment of the agile ideas that had started to get momentum in the early nineties. For me the agile manifesto was primarily a wake-up call to developers to get them back to the roots of how you build software systems in an optimal way.