PM Heroes: Series Introduction
Sometimes we are unaware of who influences our thinking. An approach makes sense, a framework fits, and years later, it is hard to say exactly where the idea came from or who first explained it clearly. This post is the first in a series that profiles the people whose thinking shaped mine most deeply. Some of them you will recognize. Most of them you probably will not, and that is exactly why this series exists.
Enid Mumford: Why She's On My List
Let me tell you about someone who changed how I think about project work, and who most people in our industry have never heard of.
In 1993 I was working at Data Sciences Ltd, an IT consultancy in Farnborough, Hampshire. We were one of the founding member companies of the DSDM Consortium, helping define what became one of the first agile approaches. I had studied Enid Mumford’s work as part of my computer science degree, and her ideas shaped the way I thought about people, participation, and systems design. When I contributed to DSDM, her ideas influenced my thinking, even if I would not have explained it that way at the time.
I am not claiming Mumford invented agile; instead, she was saying the same things about people, participation, and meaningful work thirty years before Snowbird. That makes it worth understanding where those ideas came from.
A Practical Academic
Enid Mumford was born in 1924 on Merseyside and spent most of her academic career as a Professor at Manchester University. What made her unusual was that she arrived in academia with actual work experience behind her. Before researching organisations, she had been a personnel manager at an aircraft factory and then a production manager at an alarm clock manufacturer. She had sat in the meetings, managed the workers, and watched the decisions get made. That grounding in industrial reality shaped everything she later wrote about work, technology, and the people caught between them.
She spent decades researching why computer systems failed, not in the technical sense of crashing code or broken hardware, but in the broader sense of failing organizations. These were systems that were never fully used as intended and instead generated workarounds rather than efficiencies.
Her deepest insight was that failing to make work better was its own category of failure, one that went beyond usability entirely. Her answer, developed patiently through fieldwork across Britain and Europe, was that user involvement had to be built into design from the start. The machine might work perfectly, yet the people using it might still reject it entirely.
The Problem Nobody Wanted to Admit
In the 1960s and 1970s, organizations were pouring money into computing systems at a rate that seemed to promise transformation, yet those systems kept failing repeatedly. The failures were rarely technical; they were most often social. People resisted the systems, worked around them, or quietly left jobs that no longer resembled the ones they had signed up for.
Mumford kept asking why, and the answer made many people uncomfortable. The people who would actually use these systems had been left out of designing them entirely. Experts built what they thought users needed, and users got something they did not want, did not fully understand, and had no particular reason to trust. Predictably, it did not work, and the systems sat underused or generated more workarounds than efficiencies while everyone blamed everyone else.
She called this the “human factors” problem. We would probably call it a lack of user involvement, or stakeholder engagement, or requirements misalignment. The diagnosis is the same either way. The solution she proposed was radical: give users a genuine, structured role in designing the systems they would use. They were not consultees to be managed; they were participants with real authority.
ETHICS: People in the Design Room
In 1983, Mumford formalized her approach and published it as a methodology. She called it ETHICS: Effective Technical and Human Implementation of Computer-based Systems. The name was deliberate, because she was making a point that method names rarely make: that there are moral dimensions to how we introduce technology into working lives.
ETHICS gave users a structured process to work through together:
- Identify their own needs and problems
- Set objectives for efficiency, effectiveness, and job satisfaction
- Examine alternative design options
- Choose the solution that best met their priorities
What is missing from that list is telling. There is no IT department informing people what they are getting, no project manager presenting the solution after the build is done. There is also no stakeholder sign-off happening when the work is already finished. Mumford’s process put users in the room from the beginning, not as recipients of a decision made elsewhere, but as the people making the decision.
Mumford argued that the people whose jobs would be transformed by a new system were, in fact, the best judges of what it should do. They understood the day-to-day reality of the work in ways that technical experts and business leaders simply could not replicate. Each group had part of the picture, but none, working alone, had all of it. A team that had genuinely participated in designing a system, she observed, would operate it more effectively and adapt to it more willingly. That is not a management poster platitude; it is an empirically grounded observation supported by her fieldwork across multiple industries.
Five Needs: What People Actually Want From Work
ETHICS was not just a design methodology; it rested on a deeper and more carefully argued theory of what makes work satisfying. Mumford defined job satisfaction as the fit between what employees need from their work and what the job actually requires of them. The better the fit, the more engaged and effective people tend to be. The worse the fit, the more likely you are to see resistance, absenteeism, and that slow erosion of commitment that project managers usually notice far too late.
She identified five categories of need:
- Knowledge: using existing skills fully and having opportunities to learn new ones
- Psychological: recognition, responsibility, a meaningful sense of advancement
- Task: variety in the work, genuine autonomy, useful feedback
- Support and control: fair pay, decent supervision, appropriate tools
- Ethical: being treated fairly and kept properly informed
Think about the last software rollout you were involved in. Did the new system give people more variety in their work, or less? Did it give them more autonomy, or did it route every decision through a workflow that removed their judgment? Did it use the expertise people had built up, or replace it with a process that made their experience irrelevant? Mumford’s framework makes these questions visible in a way that most technology projects simply ignore. A system that destroys task variety, removes autonomy, or de-skills the people using it fails this framework regardless of how technically elegant it might be. We see the consequences of ignoring these dimensions in adoption failures all the time. Mumford was naming the cause before most organizations had even started asking the question.
Participation as a Right, Not a Favour
Here is what made Mumford genuinely radical, and what separates her work from the softer forms of stakeholder management we tend to practise today. She did not argue for user participation primarily because it produced better software, although it did. She argued that participation in the design of systems that govern your working life is a democratic right. Workers should have genuine control over the tools and processes they work within. This is not a productivity argument; it is a recognition that workers are human beings with interests and expertise that deserve respect.
This was rooted in her earlier fieldwork on the Liverpool docks and in the North West coal industry, long before computers were part of the picture. She had seen what happened to work and workers when changes were imposed from above with no consultation, and she had studied the industrial democracy movements that pushed back. When computing arrived, she brought that same lens with her.
She distinguished three levels of participation, in increasing order of depth:
- Consultative: users are asked for their opinions on a proposed design
- Representative: a chosen delegate speaks on behalf of user groups
- Consensus: everyone affected participates directly in the decision-making
Her preference was consensus, which is the most demanding to facilitate, the most time-consuming to manage, and the one most likely to produce a system people will use and defend. If that sounds familiar, it should. Self-organizing teams, sprint reviews, and retrospectives are, at some level, Mumford’s industrial democracy applied to software delivery.
What Agile Independently Rediscovered
The Agile Manifesto arrived in 2001. Mumford had been making these arguments since the 1960s, in different language, in different industries, but pointing in the same direction. When you lay the ideas side by side, the convergence is striking.
To reiterate, this is my mapping, not a claim of influence. The Manifesto authors were not citing Mumford. Both arrived at the same conclusions by paying attention to the same reality. Knowledge work succeeds when the people doing it have genuine ownership and a genuine voice. Mumford’s theoretical foundations offer a richer grounding for why agile works than most agile literature does. If you want to understand the human science underneath the ceremonies and artifacts, her work is still a great place to start.
QUICKethics: Just Enough Process
Later in her career, Mumford developed a lighter-weight version of her methodology called QUICKethics. Where the full ETHICS method provided a comprehensive, structured process for participative design, QUICKethics was designed for situations where speed mattered more than depth. It saw particular use in Business Process Re-engineering projects during the 1990s, where teams needed the principles without the full ceremony.
The underlying logic was straightforward: match the rigour of your approach to the complexity and stakes of the problem you are solving. Apply full ceremony where the situation demands it, and a lighter touch where it does not. That principle, which Mumford was applying to organizational change work in the 1990s, is exactly what agile practitioners mean when they talk about tailoring. Every sensible project manager who has ever right-sized a process to a project is doing something Mumford formalized before the word “tailoring” had entered the PM lexicon.
Why It Still Matters
Large IT projects still fail regularly and spectacularly, and often for exactly the reasons Mumford identified sixty years ago. Users are excluded from design, and systems are built by technical teams for business stakeholders, shaped by requirements that were written by people who will never use the software. The people who will actually live inside the system day-to-day receive a demonstration two weeks before go-live and are given two hours of training. Then everyone wonders why adoption is poor, and the benefits case never materialized.
Mumford’s work applies to knowledge work today as powerfully as it did during her fieldwork. The specific technology changes with every cycle, but human beings do not. Every project manager rolling out new tooling without genuinely consulting the people who will use it is running an experiment Mumford already ran.
This is the first in a series profiling people who shaped my thinking about project management. They do not always appear on the standard reading lists, but they deserve to. Enid Mumford gets the opening slot because her ideas are both foundational and largely forgotten outside academic circles. She died in 2006, yet her work remains ahead of most organizations’ practice.
If your team is not genuinely involved in designing how they work, you are not doing agile; you are doing it to them.
