Nonviolent Project Management

Nonviolent Project Management

Photo of a hand drawing the four steps of the NVC process

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

4 comments
  1. Couldn’t agree more! We have found that lack of agreement on how to define success among stakeholders is the root cause of many project failures. Ask three business stakeholders, the architect and the Project Manager when a project is done and you’ll probably get five different answers. It’s surprising how many projects begin with “Let’s start now and we’ll figure it out later”. No matter how complex the business need or the number of stakeholders, far better to not start a project without a shared vision of success.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: