Good article. In my experience organisations will mostly start projects in order to incubate change and to try and develop a new way of working. We can argue over the effectiveness of each specific approach (and I know plenty that have failed) but the execs who sponsor these projects tend to come to the project decision because they have been ineffective through operational methods or regular service delivery.
Now I fully agree with your critique of "lazy thinking", which applies to both operational methods and projects equally.
As a C-level exec, across most organisations from startups to large enterprises, there is often a challenge to get more done with less. At the startup end of the spectrum you often dont have the people or skills needed to make a specific change, so you initiate a project with people augmentation. Or at the enterprise level you need the current business to keep on running but explore a new thing or way of doing work that requires a specific project. It so happens that many projects in these circumstances fail. There is extensive literature published on this, both within software and outside it.
However I dont think the choice of a project versus another method of delivery is the source of these failures/overruns/problems/issues/etc. What I think lies as the root cause is a reductionist and deteministic mindset. The reductionist mindset tells us that if I break a thing down into component pieces, make the pieces and then assemble them that will create the end result that I need. This is a separate discussion and, in short, prompts the need for systemic thinking.
The deterministic mindset tells me that if I do a thing (in this case a project), I will get the desired outcome without considering the possibility of variation. If something unexpected happens and the project will be delayed then the question is usually "how long?" This is the typical challenge of determinism, not the question "how likely is it that we get another delay?"
The assumptions to challenge are reductionism and determinism, not projects.
Good article. In my experience organisations will mostly start projects in order to incubate change and to try and develop a new way of working. We can argue over the effectiveness of each specific approach (and I know plenty that have failed) but the execs who sponsor these projects tend to come to the project decision because they have been ineffective through operational methods or regular service delivery.
Now I fully agree with your critique of "lazy thinking", which applies to both operational methods and projects equally.
As a C-level exec, across most organisations from startups to large enterprises, there is often a challenge to get more done with less. At the startup end of the spectrum you often dont have the people or skills needed to make a specific change, so you initiate a project with people augmentation. Or at the enterprise level you need the current business to keep on running but explore a new thing or way of doing work that requires a specific project. It so happens that many projects in these circumstances fail. There is extensive literature published on this, both within software and outside it.
However I dont think the choice of a project versus another method of delivery is the source of these failures/overruns/problems/issues/etc. What I think lies as the root cause is a reductionist and deteministic mindset. The reductionist mindset tells us that if I break a thing down into component pieces, make the pieces and then assemble them that will create the end result that I need. This is a separate discussion and, in short, prompts the need for systemic thinking.
The deterministic mindset tells me that if I do a thing (in this case a project), I will get the desired outcome without considering the possibility of variation. If something unexpected happens and the project will be delayed then the question is usually "how long?" This is the typical challenge of determinism, not the question "how likely is it that we get another delay?"
The assumptions to challenge are reductionism and determinism, not projects.