What’s Wrong with the Project Approach?

Some time back the late, great Grant Rule wrote this paper on the problems with “projects” as an approach to organising software development. As the original has now ceased to be, I’ve taken the liberty of reproducing it here for posterity:

What’s wrong with the project approach to software development?

January 11th, 2011
Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

1. Those responsible for business strategy are disengaged from, and know relatively little about, software-intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
2. Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well-defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s skip over the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C-suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

– P Grant Rule