Allan Kelly

About Allan Kelly

Allan Kelly has held just about every job in IT, these days he provides training and consulting in development management, processes & products, especially around Agile. He specializes in working with software product companies, aligning company strategy with products and processes. More about Allan at http://www.softwarestrategy.co.uk/allankelly

#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
  • 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?”
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

5 Responses to "#NoProjects – why projects don’t make sense"

  1. Yves says:

    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.

  2. Karthick S says:

    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.

  3. 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

  4. bakri anouar says:

    but if the code is 100% without bug, we can speak about a software dev project way not ?

Leave a Reply


× three = 24



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close