Sunday, October 06, 2013

#NoProjects - why projects don't make sense

In the last few months Steve Smith, myself and others have been Tweeting a lot with the hash tag #NoProjects. We have independently come to believe Projects are a smell, they are bad for our industry (the technology industry). Steve set out his thinking and now it is my turn.

Right now this is little more than a bullet point list, I’m presenting to PROMS-G in February (“The End of Projects”) where I will present a more coherent argument. Until then here goes.
Lets start of by defining “A project”.

The Project Management Institute says:
what is a project? It’s a temporary group activity designed to produce a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. … The development of software for an improved business process, the construction of a building … — all are projects.
And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.”
PRINCE2 defines a project as
A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.
Actually, PRINCE2 has two definitions of a project:
“project management is the way of managing change. Everything from the Olympics to organising a wedding can be considered a project. It describes the activities that meet specific objectives and can be used to introduce or improve new or existing products and services.”
Bearing this in mind I suggest the project model does not fit software development:
  • Projects have end dates - successful software doesn’t end, it not temporary. Finished software is dead software, software that isn’t used and doesn’t change
  • Successful software is continually developed and improved, the team is not temporary, it continues to exist (although it might change composition and the imposition of the project may at times destaff it)
  • Resources change: sometimes the people decide to leave of their own accord, sometimes the wider organizations decided to remove people or add others
  • The project model implies we can define what needs doing before we begin and that it won’t change. Software development uncovers need as it proceeds.
  • Project thinking implies that the problem can be defined independently before the solution: in software development the creating of a (partial) solution can lead to a redefinition of the problem being addressed.
Those points might be enough to persuade you the project model is not a good fit for software development. I go further, I think the project metaphor actively damages software development and destroys business value:
  • Project success criteria are “On time, On budget, On scope” and not business value. These criteria become a distraction and a barrier to hide behind - a “social defence” to use the jargon. Work should be value seeking and judged by the value/capability/benefit/[whatever you want] rather than arbitrary criteria which seemed good one day in the past.
  • Corporate Psychopathy: why disband a performing team just because a project has ended? Why start a project by pulling together a new team who have never played before?
  • Destroying team destroys knowledge - knowledge has value, knowledge exists in heads not documents
  • Project thinking induces short-termism - around quality, around productivity and around teams especially. Project thinking builds pre-fab houses when it should be building to last
  • Large batch size: projects lump lots of work together and attempt to manage it all as one large unit. This is inefficient (software has dis-economies of scale), breaks flow and delays delivery which delays value realisation
  • Project thinking makes BAU a dirty word; BAU is not a dirty work, BAU is where the action is: if it is worth doing it is worth doing more of, if it is not worth doing then close it down. Use portfolio management rather than pre-defined cut-offs. (BAU = Business As Usual, a common corporate term)
  • Projects inflict change on people (employees): why not seek their involvement? They own the work, they are BAU, the work stream should be seeking to improve itself as part of its daily work
  • Continuous improvement is continuous. Projects stop continuity, projects break flow and reduce effectiveness. Continuous improvement should be part of the fabric of everyday work, supported if need be by technologists.
  • Project thinking create scheduling projects: “Project B after Project A has finished, but if A is late….” - define work streams and feed them work
  • Projects confine change to projects and freeze change elsewhere
  • Start-up costs: bureaucracy, administration, etc. of starting a project mean the project model is expensive and slow at taking action. Project setup costs detract from value and the time it takes to “launch” a project detract from responsiveness. On a small work effort the costs of creating a project may be disproportionally high which may detract from attractiveness of doing the work. Similarly the time it takes to get a project scoped, a team assembled, everything kicked-off, performing and delivering creates a barrier to seizing value.
I recognise that a lot of what is called “a project” isn’t, it doesn’t fit the definitions at above. That simply makes things worse. Calling something a project when it isn’t is at best sloppy thinking, at worst it imports the problems listed into work that would otherwise be free of them.

Then there is scaling: so much of the “scaling agile” debate revolves around projects. If instead you accept standing teams dedicated to improving business as usual many of the scaling issues simply go away.

Projects are accounting codes to bill work back to. Projects are for accountants. Leave them at that.

Ask not “When will it be done?” ask instead “When will it start delivering value?”


  1. Clousure is something we, as humans, try to reach. Projects can be seen as boundary that provide a clear point where closure can be reached. But you have interesting points, as the project can be become an artificial, alien artifact. Also it is natural that in an agile approach there should be an adequate set of small, regular milestones (User Stories) that should provide this feeling to the team.

    1. I do not think that we, humans, do not look for closure everywhere. Parent-child, sibling relationships, marriages, friendships and partnerships are few examples where closure is not at all what we look for, unless things go really bad. On the contrary, we tend to extend a lot the physical, temporal and emotional boundaries in those cases. In those cases, milestones are also a way to enhance the relationships, rather than search for closure.

  2. Allan

    Another "smelL" I see from the "treat everything as a project" mentality is a common failure to see interdependencies, especially resource constraints. The correlation is the "push" of new work into a system that cannot accommodate it.

    Re-conceptualising as streams of value forces us to think about flow, and look at the factors that reduce flow (one of which IMHO is commonly the push approach).

    It's hard for some people to make this change of thinking....

  3. Yes. This is all true!

    Now the question arises, why is this so? I believe it is a mal-adaptation to the fact that value is not actually measured, only cash-flow. Furthermore cash-flow is assigned to people (depersonalised as cost-centres), and is off-loaded as fast as possible due to budgets. Thus projects are a way of offloading cost onto someone else's budget, which is usually the operational slush-fund in a different organisation. And so it goes around...

    Personally I blame the CIO. And possibly the CFO. And don't get me started on the CEO and the board ;).

    So, I wonder, what can be done?

  4. Richard - nice to hear from you!

    Good point.
    I've also been wondering why Projects rule and why BAU (Business as usual) is such a dirty word.

    I wonder if, and here is a hypothesis for people to agree or disagree with...

    In the late 80's to mid-90's downsizing and delayering were the corporate creed. This meant a lot of junior and middle managers got booted out. I wonder if this was the cause of project-itis? Things still needed "managing" (although some disagree and there is a discussion there) so instead of junior and middle-manager we got project managers. Instead of business-as-usual (to be squeezed, downsized, delayered and outsourced) we got Projects!

    Just an idea....

  5. I can only agree; let's stop call everything a project.
    Projects are made to develop programs, not software. The distinction between a program and a software is that a program has no potential of evolution. A software has a potential of evolution oriented towards the developer's horizon. The end date of projects prevent developers to "project" (!) themselves in the future, forbidding any anticipation, thus any future evolution. For example data structures are "closed", they can't be easily extended. Which developer is really able to develop an extensible software when he's already preparing to move on to the next project ?
    "Project" is some kind of sex without love: no investment allowed.

    - Oranadoz

    1. Thanks Oranado!
      Using the s-word probably just got this blog blocked on many filters :-)

      You also reminded me of a Woody Allen line which might apply is projects are sex without love: 'Sex without love is an empty experience' says Diane Keaton, 'But you got to admit' says Woody, 'as empty experiences go it's one of the best' (from Love and Death)

      Somehow it seems to fit! :-)

  6. The projects are the tool the non-technical managers to control a development they do not understand.
    Here control means:
    - knowing what to expect (milestones and deloverables)
    - having firm dates wheh to expect something to see/touch (milestones)
    - reducing (their own) stress of not seeing "progress "
    - knowing whom to ask/push for what
    And thus the projects are means of extracting the "workflow" out of development, depersonalize it and automate it at the end

  7. You said "Project success criteria are “On time, On budget, On scope” and not business value"

    How is business value measured? How can you do it without having costs, schedule and features as a part of the equation?

    1. Measuring business value is going to vary depending on you environment. The simple answer is to go to your stakeholders and ask "What is the benefit of this?" and later "What benefit was delivered?". They may not be able to give you a £$€ number but they should be able to say something.

      Cost, schedule and features may play a part in the pre or post work evaluation but they are not in themselves value. Features in particular are very misleading, nobody ever bough an iPod for features - you can get the same features elsewhere for less.

      The real expert on this is Tomb Gilb, I suggest you read Competitive Engineering

    2. Let's change the product to houses. You cannot talk about the "value" of the house without talking about the cost and then the schedule. Watch Grand Designs, Location Location Location, or any of those programmes: after the obligatory tour of the finished project when you all marvel at the great beauty of it, they are always asked what it cost and they are always asked how long it took to build. Without the answer to those questions you only have a small part of the picture.

  8. Dear Anonymous - I'm sorry I don't get your point?

    Did I say ignore cost? - No
    Did I say cost is irrelevant? - No

    What I did say is we should look at value first.
    As you yourself say, at the end of the programme, they look at the house and ask "what is the cost?" - I don't watch these programmes so I'll have to believe you

    You should definitely look at cost.
    What I have argued - if not in this post then elsewhere - is that value is more important, we should look at value first. And we should feedback on ourselves.

    But please, what was your actual point?


Note: only a member of this blog may post a comment.