Project Myopia: Why projects damage software #NoProjects

by Allan Kelly

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years.

Each project fails for its own reasons but they all share one thing in the Project Model.

Could it be the project model itself which creates failure?

In this tour de force Allan Kelly explains why the project model is a poor fit for managing software development. Working from industry recognized definitions of projects he describes how the model deviates from reality then goes on to

- Why focusing on time, scope, and cost damages software, creates goal displacement and reduces quality.
- How projects miss the bigger picture.
- Why maximizing value demands work across projects.
- When debt is good and how projects increase technical debt to the detriment of value delivery.
- The false projects and conflicts that arise when companies apply the language of projects to continuing work.

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Online Reviews

"If you are managing programmers, working with them directly or indirectly, or recently joined the profession, it is a must read. It explains how the maximise the value of the programmers work in the enterprise large or small, and how to avoid the trap of long-term planning in a world where the only constant is change."
Amazon Review - Bronek Kozicki

"The project model does not fit the reality of managing software development. In this bracingly short book Allan provides an eloquent critique, landing his points well without waffle.

Read this then the companion volume, Continuous Digital, which provides practical solutions to the problems uncovered here."
Amazon Review - Ewan Milne

"An excellent book which thoughtfully critiques the "project" construct that we have all been conditioned to accept as "normal". This book is thought provoking, explaining Allan's views and experiences on how and why projects are harming the development of software. This book links in to Allan's other book "Continuous Digital" (This book provides the critique and rationale, which I believe Continuous Digital builds on).

If you work on change projects the that involve, or are driven by, software.. then this book will be for you! It challenges thinking and provokes thought."
Amazon Review - Adrian Reed

"This book is an excellent exploration of the short-sightedness of the project model for software, and should be essential reading for anyone involved in managing software development, delivery, or operations."
Amazon Review - Matthew Skelton

"A short, but enjoyable read. Allan covers, categorically, the thinking behind moving away from projects (as per the #noprojects conversation): where it's appropriate, why it works, and what we can do to move away from it. He defines what he means by a project (or rather uses the definitions defined by PMI and PRINCE2), and categorically dismantles the reasons behind using them in most modern contexts. From arguments of quality to economy, you'll be left with a solid understanding of why you probably don't want to use projects, and move towards continuous digital delivery.

Well-structured, well-argued, and entertaining. A very worthwhile read."
Amazon review - Gary F

Genres: Management, Computers

136 pages, Paperback

Published March 3, 2021

About the author

Allan Kelly has held just about every job in the software world, from system admin to development manager by way of programmer and product manager. Today he works helping teams adopt and deepen Agile practices, and writing far too much. He specialises in working with software product companies and aligning products and processes with company strategy.

He is the author of three books: "Xanpan - reflections on agile and software development" (https://leanpub.com/xanpan), "Business Patterns for Software Developers" and “Changing Software Development: Learning to be Agile”; the originator of Retrospective Dialogue Sheets (http://www.dialoguesheets.com), a regular conference speaker and frequent contributor to journals.

More about Allan at http://www.allankelly.net and on Twitter as @allankellynet (http://twitter.com/allankellynet).

Reviews

[Yannick Grenzinger · Rating 4 out of 5]

An overall good short book about why you should stop using project management and associated terminology for software development.
However if you are already doing agile product dev, you will not really learn anything new except good citation and clarification.
If you think project management is the only way, this book will maybe change your point of view :)

[Jose M. Beas · Rating 2 out of 5]

Short book explaining the #NoProjects meme focused on the negative aspects of a project based management. Unfortunately all practical aspects are derived to a previous book “Requirements and User Stories” and an upcoming new book “Continuous Digital”. Nevertheless, even for someone with experience on management or with previous exposure to the idea of #NoProjects, this book brings some interesting ideas like trying to change the metaphor for technical debt.

[James Healy · Rating 3 out of 5]

I broadly agree with the premise of this book, but I found the writing style hard to get into. Lucky it's short: I pushed though and made myself finish it.

Worth a read if you find yourself in a company that writes software via a project-based structure, but I probably won't actively recommended it.

The bit I found most valuable was the discussion on technical debt, and the proposal to rename it "technical liabilities".

[Roel Trienekens · Rating 3 out of 5]

For those familiar with agility all of this is nothing new, so not really worth the read, although there are a few good quotes to be picked up.

In general this feels more like an advertisement for the followup book ‘Continuous Digital’ than a standalone book. It would’ve been better to combine both (haven’t read the followup) into one I think.

Good points: quite short and to the point with little added fluff, so reads quickly and some clever analogies I can use in my work

[Sicofonia · Rating 3 out of 5]

For its content I would refer to other reviews that summed up pretty nicely what this book is about. For me, there were a couple of interesting points. Such as "diseconomies of scale" and "technical debt" to be considered as "technical liabilities".
Considering I got this book for free, I have not complaints. It made an interesting read during a 2.5 hrs flight.

[Nathalie Karasek · Rating 3 out of 5]

Nice book if you happen to work in a rather traditional project management environment. This can help to explain people in such environments why and when agile might be worth trying and also the differences. If you are already working in an agile company there is maybe not so much new information for you.

[Wilson Gov · Rating 5 out of 5]

Read this if you want to understand why software projects fail?

This book explains really well the flaws of the project model and why it doesn't fit the software industry.
If you ever hear "Agile doesn't work here!" Look out if you are experiencing the project model effects .

[Alan · Rating 3 out of 5]

Some interesting ideas, but I'm not completely sold

[Michał Węgrzyn · Rating 3 out of 5]

Meh

[Claudio Noguera · Rating 5 out of 5]

Good book for a flight, less than two hours read.

[Carlo Martinello · Rating 3 out of 5]

I did not like the book.
I found it confusing and in some cases I didn't agree with some thesis.
However there are some good ideas so I saved to three stars

[Victor · Rating 4 out of 5]

This little book underlies the problems with the project model: the belief that successful products have an end date, encouraging large batches of work, putting a bigger emphasis on the iron triangle (deadline, budget and scope) than on customer value, discouraging learning that happens after the "start-date".

This book is only a critique. The author presents his solution in a different book: Continuous Digital: An agile alternative to projects

[Diego Pacheco · Rating 4 out of 5]

Good one

Good point of view on why projects are dangerous. Good samples and rationale behind it. Every engineer manager should read it.