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?”
You can add to that list that projets are bad for long term skill development. Employees are brought on projects for their current skillset. Usually not to ensure they develop new ones and increase long term business value delivery. Also, they end up working away from their business unit manager. This makes for difficult review of their contribution and performance and the base for performance becomes limited to contribution to scope, time and budget.
I notice a couple of considerations missing:
1) The post does not take agile teams into consideration.
2) I am fine with not calling it a project, but do not understand what I should call it.
A project is a temporary unit of work contributing to a product.
A project should not be iteratively developed – a product should.
Kathick,
Sorry, this post doesn’t talk about teams. I’ve written about teams before, and doubtless will write about them again. Basically: aim for a stable team, keep them together, bring the work to the team.
#2 – slightly more difficult, what do we call the thing that everyone calls “a project” but isn’t in fact “a project?” Actually its a bit of a trick question, it is probably called “Work”. It might be called “A product” or might be called a “Work stream.”
allan
I do not see anything wrong in projects. Project is just a way to define the scope, time frame and costs of the development. It does not mean that after the project everything ends. Actually if you keep in mind that project ends and you need to do the handover to maintenace organization, you probably think maintenability better than if you think that you will continue development forever. Also after the project, source code and the software architecture should be in such condition that the owner of the system is able to do the seamless handover to other development organization… Read more »
Project planning plays an essential role in helping guide stakeholders, sponsors, teams, and the project manager through other project phases. Planning is needed to identify desired goals, reduce risks, avoid missed deadlines, and ultimately deliver the agreed product, service or result. Learn more on What is project management? and why it is important for an organization.