Don't Let the Rocks Restrict the River

How do you add flexibility and iteration into a rigid system?  A defined management structure?  How do you manage stakeholder risks?  And how do you avoid the downfalls of assumptions?

I sat in three different sessions at the recent PMI Congress event, each on different topics, and somehow all three came together quite obviously for me.  Maybe it will make sense for you as well.

So I will start with a great analogy I heard in the first session that rang true for me, as it relates to exactly how we might go about shifting to adaptability.  The session, delivered by Joy Beatty of Seilevel, was about the challenges of introducing Agile into Large Enterprises.  A bit of a mix around Agile methods and change management issues.

"Find your rocks in the river, and let the water flow around them."

The rocks, of course, are those non-negotiable aspects. Those required checkpoints, the gates, or those points where dependencies come into play when particular requirements need to be met.

The water? The process of how to get there, how to continue to move forward with processes that might require a bit more flexibility.

When we are thinking about adding adaptability and iteration into our PM structures, we need to understand how that may impact our stakeholders, and the dependencies that can kill agility.  We need to map out our processes, and explore how those tie in to other processes within our organization. 

  • Which other teams might need information from us (or the system being altered), and what information that is, when,
  • What impacts our changes might have on others' activities or capabilities, and
  • What cannot be changed at all for those groups - sometimes full systematic change cannot be done all in one go, and we need to be aware of that.

From there, we mark those rocks in our system - lock them in, and ensure that the boat will not be rocked (excuse the pun).  Everything else that can be managed around those...let them flow.  Keep people informed of plans, progress, changes, etc., but let it flow. 

But be careful.  Make sure that map you've developed is whole, holistic.  Have you found all of your stakeholders? 

I listened next to a talk about stakeholder engagement, delivered by Rick Furino of Microsoft.  He spoke of all the categories of stakeholders to consider, their differing priorities and perspectives and why those exist, and how to better engage them.  And he did it in a way as to draw the audience in - a perfect demonstration of engagement processes at play!

Be sure you've worked through the many categories of stakeholders, and asked enough questions to flesh them out.  Ensure you understand what their needs and priorities are, how influential they may be, and how that might impact your project.   

Because guess what - there are likely silent stakeholders you might have missed.  Or you assumed they didn't matter, that you weren't upsetting anything for them.

Those are the ones that will come out of the woodwork after you have made a change that you assumed would not matter, would not impact anyone.

The last session of the day was delivered by Beth Spriggs.  Beth naturally had the audience fully engaged throughout the entire session, asking questions, making statements or posting pictures up, and asking for our assumptions.

Helping us to understand just how many differing perspectives there might be in just one room. 

And then she would change the context for the same discussion, and ask us to reflect on our assumptions just made.  To demonstrate just how easy assumptions might change or can be wrong. 

She suggested several things we can do to reduce the risks of assumptions, and I would suggest that these strategies can be applied also to looking for and assessing other risks as well.

1. Always 'zoom out' - context is everything, particularly when dealing with conflict!

2. Explore your own assumptions - what are you taking for granted, put it in writing.

3. Share your assumptions and ask for feedback.

4. Ask for different perspectives, ask lots of questions. 

5. Ask others for their questions.  Q-storm...

6. Ask people what other people are saying - not to assume there isn't trust or things not being said, but to see how others' view others' stories - it may shed light on more potential risks.

7. Perform a 'checking assumptions exercise' - live collaboration where a list of assumptions are reviewed by all - if everyone is aware of one, it isn't necessarily a risk...but if only one person is aware of it, put it on the risk register to ensure it is addressed!

So, if you want to achieve success in introducing changes, whether they are agile-focused or something else, make sure you have a clear understanding of your stakeholders, their issues or concerns, the potential barriers to success, and any assumptions you or your team may have!

This article was originally published on projectmanagement.com to highlight sessions at the 2016 PMI Congress.