I’m going to break the first rule of #NoProjects (again), to collect a few artefacts in one place, mostly for reference purposes.

I’ve been learning about the limitations of and dismantling what I would suggest is the abuse of the project vehicle in inappropriate contexts for a long time now. The turning point for me was possibly the point when I gained my PRINCE2 Practitioner certificate, a methodology that is really poorly-suited to complex environments (like software).

The first time I wrote about NoProjects was in a paper I started writing in 2005 about Ideation, Prioritisation and Portfolio Management. This contained what I would consider a lengthy “rant” about how the batch size of the typical projects was far too big a quantum for software development – that it was just the wrong vehicle for the job.

The second time you can find in the conclusion of the “Black Swan Farming using Cost of Delay” paper. This was originally scattered throughout, but our reviewer (Karen Greaves) kept insisting that we just stick to a very dry plot of what we did and what happened. I managed to squeeze some of what I’d written about before in toward the end though :). I wanted to call that section “#NoProjects” but that idea was rejected by my co-author, Özlem Yüce.

I did eventually get to use the #NoProjects hashtag much later, as a reply to Damien Schreurs who innocently mischaracterised the paper as being about using Cost of Delay to prioritise projects, rather than features…

This tweet, as they sometimes do, generated more response than any other stupid thing I’d previously said on Twitter. I meant what I said though…

Steve Smith replied “I’m in”. And then there were two! As Derek Sivers says, it is the 2nd follower that transforms a lone nut into a leader :)

We did spend some time wrestling with the limitations of the hashtag. I tried a bunch of alternatives, but nothing really resonated.

As I said in response to Gene Hughson, “Twitter’s quantum makes it fiendishly difficult to do much other than speak in slogans though. Where it gets annoying is when those bombastic slogan become religious in other settings, where we have the space and time to explore the nuances and trade-offs. I can’t stand that.”

After this, I have written a couple of articles specifically speaking to points that I felt hadn’t been adequately addressed elsewhere:

The problem with projects

The problem with Projects: Temporary Organisations

It’s fair to say though that pretty much everything I write has a #NoProjects angle in some way. This one for instance:

Systems Thinking and I.T. – Black Swan Farming

Steve Smith also contributed a couple of articles:

No Projects

Organisation Antipattern: Project Teams

Then, around the end of 2013 Allan Kelly joined the party and has been by far the most active contributor, with a whole collection of blog posts, and InfoQ article, videos and presentations – even a podcast! You can find all that here: NoProjects

Allan has probably spoken on the topic the most. I have only done one #NoProjects talk –at a Project Management conference in Copenhagen. (They actually liked it, which surprised me.) Allan’s is probably better.

Bob Marshall posted a wonderful letter that the late P.G. Rule wrote in 2011 (I think).

What’s Wrong with the Project Approach?

And a more recent treatise on the subject from Bob:

No Projects

More recently, Evan Leybourn joined in too, with a number of InfoQ articles, starting with this one:

If you need to run a project you’ve already failed

Here’s a video of Evan giving a talk on the topic…

What is #NoProjects proposing as an alternative then?

Good question. Let’s see if we can answer it in 140 characters:

Not quite, as Maria nicely points out below – I’ve left off the most obvious one #ContinuousDelivery, perhaps because it’s now accepted wisdom to the vast majority, even if they are still struggling to make it a reality.

#NoProjects is more focused on the upstream, while #ContinuousDelivery deals with the downstream. Overall, it’s not that the Project vehicle goes away as such, it’s more that it becomes so small as to no longer need all the extra stuff. Less stop-start, with large batches, more continuous flow of very small “projects” that are more like experiments. This is how I see it anyway. We tilt the playing field, by focusing on teams, developing products, with continuous flow end-to-end.

So that’s some of the history and some material you may find useful. I’ll try to keep this post updated as I spot any new stuff. In the meantime, feel free to share your views on Twitter and if you would like to ping me here!