Nonviolent Project Management

Nonviolent Project Management

Some eighteen years ago now, I started using a technique I named “Stakeholders and their Needs” – as part of my approach to managing software development projects. I’ve found it a useful enough technique to continue using and evolving it on just about every endeavour I’ve worked on since then.

Aside 1: There’s a paper describing this and other aspects of the whole approach – which in its early days was called “Jerid” and more recently has evolved into “Javelin”.

Aside 2: This was all long before I became aware of Rosenberg and Nonviolent Communication, or even paid much attention to e.g. Gandhi and the general idea of nonviolence.

Aside 3: As in some other posts, I’m leaving to another day the contentious question of whether we should even have “projects” in the world of software and product development. And whether “Project Managers” should be doing the management of said projects.

Aside 4: I recognise that managing a project is about more than just ensuring that the right thing gets built. But given that so many projects fail in this key regard:

• Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester Research)
• 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)

Source:
Software Project Failure Costs Billions. Better Estimation & Planning Can Help

I posit that anything that can help us ensure we are building the right thing has significant value.

Before Requirements

I had, for some years before adopting “Stakeholders and their Needs”, come to see the benefits of a clear and shared understanding of the pertinent “requirements” for a project. And the benefits of evolving those requirements (and their clarity and the shared understanding) as the project progressed, by means of e.g. early and frequent delivery of both working software, and of the interim work products, such as the list of stakeholders and their needs, described here.

But I had also come to see that it was more or less a matter of chance whether the right people got involved (as “stakeholders”), whether they had the inclination or support necessary for them to engage with the project, and particularly whether they understood the formalisms of  the requirements models. Most of all, perhaps, was the key question: “How likely is it that the people who would benefit most from understanding what the project was doing – how it was going to meet their needs, and when – could actually understand those things?”.

The answer then – and I suspect, quite often even nowadays – was “Not very likely”.

So it seemed that some less formal, more easily shared, and understood, articulation of what the project was trying to achieve might be useful. And it seemed handy to have a (prioritised) list of the folks the project team needed to have conversations with about needs (what the team, and the stuff they’re producing, should do).

Thus “Stakeholders and Their Needs” was born.

Here’s a simple (abridged) example:

Name	Group	Role	Needs	Contact
David Hains	Corporate	Head of Development	Improved organisational development capability Weekly face to face status report Daily RAG status update	555-1234
		Personal	No surprises No calls when on holiday
Charlene Smitts	Programme Office	Programme Manager	Clear visibility into project progress Advance notice of any and all resource changes	555-6661
Betsy Doohan	Project Team	Project Manager	Enhanced reputation as a PM No late nights	555-8882
Charlie Watts	Project Team	Developer	Making a difference Improved C++ coding skills	555-2313
		Personal	Pay rise before September
Bill Harlan	Marketing	Product Owner	Ground-breaking product Long-term product success Happy customers 25% market share before Xmas	555-1022
		Personal	Promotion to Head of Products

We can have other columns too, such as “stakeholder priority” or “email address” – whatever the project team and its wider stakeholder community find they need.

This technique allows everyone to see what everyone needs from the project. When needs conflict – as they inevitably will, from time to time – folks can see the conflicts and move to resolve them. Of course, if some folks are unwilling to disclose their needs to the group, then some needs may go unseen and thus, possibly unmet. This points to the advantages of a climate of dialogue and trust, where folks feel comfortable enough to share their real needs with each other.

And, crucially, the project team and its external stakeholders have a fairly clear, albeit broad-brush, comprehensive, comprehensible and topical statement of what “success” looks like.

Additionally – for those folks who seek such things – this approach affords traceability, from the list of stakeholders and roles, through their various informal needs, and thence to the more formal requirements (Use Cases, User Stories, Quantified Quality Objectives, etc.), and eventually to the outputs/deliverable (e.g. the system components in production).

The Nonviolent Dimension

So, from its inception, this technique, with its focus on needs, turns out to be pretty much in line with the fundamentals of Nonviolent Communication. I suspect that’s why it has proved to be of such enduring benefit over the years.

One further change, now I better appreciate Rosenberg, would be to see if the addition of an “Actionable Requests” column would offer some benefit. Actually, I wonder if a “Feelings” column might not provide some benefit, too. Although I can appreciate that for the vast majority of e.g. Analytic-minded organisations out there, talking about and sharing feelings is even more challenging and uncomfortable than sharing one’s needs.

And this approach also offers a way to take the coercion and violence out of the relationship between the Project Manager (if the project has a person dedicated to that role) and the development team. Given that the team (they’re stakeholders too!) can see everyone’s needs, they have the information they need to make everyone’s lives more wonderful. Violent tactics such as coercion and obligation only get in the way, and are conspicuous by their incongruence, here.

Indeed, the same goes for all the relationships pertaining to the endeavour.

Afterword

This technique is at the root of my approach to “Covalence” – the discipline of ensuring that any endeavour delivers the necessary value to all its stakeholders.

– Bob