Projects are not the best way to get great return on your software development.
And in this podcast I'll tell you why.
Or listen at:
Published: Wed, 17 Jul 2019 15:48:44 GMT
Transcript
To achieve the best ROI from Software Development, you need to take the entire life of that software into your thinking.
If you consider software as a product; it has a creation stage, a maintenance stage and a destruction stage. Every software "product" will go through these stages.
Every software product is created.
Every software product goes through a maintenance stage. This could include "keeping the software running" to making substantial change over a very long period of time.
And finally, every software product, will go through a destruction stage. This is often overlooked, but there will generally be a stage there - even if it is an end to ongoing maintenance costs. Most software products however should be carefully decommissioned - take for example a product that stores user data - that data needs to be handled in a legally and morally appropriate way.
To achieve the best ROI over the full live of a software product, you need to balance the needs and values of those stages.
For example, there is little point investing considerable effort to make a software product cheap to maintain if it will only exist for a matter of hours or days.
Conversely, if a software product is expected to have a lifetime of many years, then investment in making it maintainable is paramount.
Ok, so with this in mind, let's think about projects.
By definition a project is specifically to achieve a "particular aim". By its very nature if should focus those involved in that "particular aim" ... it pretty much encourages us to ignore everything outside of that aim.
So it encourages us to not think about the full lifetime of the product.
Certainly I've been involved in projects where we have been laser focused on delivering the immediate aims and explicitly told not to worry about the longer term.
That isn't to say that projects can't be run in such a way to consider the longer lifecycle - they certainly can - but if you start with a project mindset you need to expand your thinking out from the aim.
In my personal experience is has to be a mature, confident team that can do that.
What I see a lot more is spreadsheet project management;
A list of initiates, changes, whatever you want to call them - make their way onto a spreadsheet. There is then some opaque prioritisation process (generally involving shouting & political posturing). Resulting in a whole bunch of spreadsheet rows for a software development team to get done as quickly as possible.
As I said in the last podcast, the focus then becomes"how do we get that spreadsheet row done" rather than any anticipated benefit.
We will generally have some process - you may have a project management office for example - the process pushes those spreadsheet row through - always with the focus on getting that row done.
So is it any surprise that we struggle to think about the fuller product lifecycle?
I've certainly worked with project management teams that will actively seek to do the minimum possible - not as part of any lean or agile thinking (concepts that I'll pick up later in the series) - but to allow that "development resource" to be allocated to more project - to progress more spreadsheet columns.
This comes back to the utilization mindset I talked about in episode 2.
This is why I would always advocate think in terms of changes to a software product rather than delivering that change via a project.
Simply thinking about a change in the context of a long lived product drives better decision making - and thus better long term return on investment.
That isn't saying that you choose to do anything different - but at least you have thought about it and have the opportunity to make an active decision.