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:
Actually, PRINCE2 has two definitions of a project:
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
- 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?”
