logo design...copyright Elena Yatzeck, 2010-2014

Wednesday, April 6, 2011

Agile Project Communications Management

Pop quiz:  as an agile project manager, how much attention do you pay to your communications plan?
  • A:  Dude, see the Agile Manifesto!  We're all busy creating working software here, and if you want to know what's going on, come to our biweekly showcase, or just drop by and visit the team room.
  • B:  Ho ho!  My group has "Communications Plan" language we can just re-use for all of the projects, so I don't have to spend a lot of time thinking about it--I just drop it into the charter and off we go! 
  • C:  I think we're fine.  We're using application lifecycle management (ALM) software, and we keep it up to date for anyone who wants to check.  Plus we have some regular meetings and a distributed email list people can subscribe to, and that seems to get the job done.
  • D:  [runs away screaming]
  • E:  Ahem.  "Project Communications Management" is number 7 of the 9 Project Management Institute (PMI) Project Management Body Of Knowledge (PMBOK) Knowledge Areas.  It can be divided into four project activities:  "Communication Planning," "Information Distribution," "Performance Reporting," and "Administrative Closure."  As specified in PMBOK, I create a communications plan during the early phases of the project, follow it all the way through, and review it as I go to make sure it is still working.
So of the choices above, up until recently, I would probably put myself at "C," which at first glance looks to be the only pragmatic option the quiz offers.  If Mr. PMBOK confronted me, waving ISO compliance forms in a menacing way, I would be able quickly write up what I was doing and call it a plan.  If Agile Guy and I were chatting about Ruby and playing Beer Pong together, I wouldn't make him too uncomfortable either, if the topic of my communications plan came up.  Like Elizabeth I, but with less influence, I would be owning the whole via media thing.

Recently, however, I've begun to think that all of these options have a common flaw for agile project communications management:  an underlying belief that project-level communication is, in Mr. PMBOK's words, "information distribution."

Agile Guy will tell you that his showcase is richer than Mr PMBOK's weekly emailed status report, since it takes place in a shared space where something tangible is being shown, and where verbal and non-verbal message components can all get through optimally from the team to the stakeholders.  But both of these guys are picturing project communication as a one-way trip for some discreet pieces of project intelligence.

In the diagram below, "A" is the project team and "B" is the stakeholders:



Agile Guy would be quick to say that the whole point of agile software development is that it is collaborative and NOT just a set of one way communications.  It is a series of multi-person, multi-directional conversations which leverages and quickly builds the wisdom of the whole team, and which includes an evolving group consensus.  In the diagram above, the team room would be a literal shared space, and the one-way arrow would instead become a set of models (software pilots, wire frames, etc.) which everyone would contribute to.  Information would not be conveyed from point A to point B, because A and B would be sitting together in a shared reality building something real through words and actions.

Exactly!  I say.  Let's extend the communications model used INSIDE the project team, and do something more like that for communicating BETWEEN the team and its stakeholders.  While you're off in your shared space building something great, what about the stakeholders who aren't in the room?  Are you going to fob them off with a biweekly "showcase" which devolves back into transmission of "what we did" from Point A (team reality) to Point B (stakeholder reality)?  Well, it depends.

If you're building software which will make a significant difference to your business (and if not, why are you building it?), then your project communications plan should be creating a shared discussion among the stakeholders around that business change which is very analogous to the discussions occurring constantly in the team room.  You and your Product Owner jointly own that problem--you are the one with the experience to know you need an appropriate communications plan, and your Product Owner knows the stakeholders.

So what would this agile project communications plan look like?  Here we need the wisdom of Mr. PMBOK along with our own brilliantly agile selves, and we should all be taking a much closer look at the professional disciplines of marketing and "internal communications management," whose practitioners spend all of their time figuring out how to find people and speak with them in their own language.
  1. As Mr. PMBOK would tell you--spend some serious time up front with your Product Owner and your whole team thinking about what the "conversations" need to be among the stakeholders, and how you can get those conversations going and keep them going.
  2. Get people into a shared space:  physical, virtual, or at least mental.  This is way harder than you might think.  You need to think carefully about the media which will reach your stakeholders, and most likely this will require an energetic person to create a network of project champions by actually speaking with them, and getting them to agree to speak to others.  This is not a "knowledge management" issue--it is a human issue, especially today.
    • A project web presence is pretty useless unless someone seeks it out.  
    • Executives and techies are actually the LAST people you should attempt to reach through blast email.  Most executives I know will tell you straight out that they don't read their email.  Most of my tech-savvy friends get more than 1000 email messages a day.
    • And even if they knew about your ALM presence, your stakeholders are so busy fending off unwanted email, the LAST thing they're would do is take some time to log in and check out your awesome color-coded virtual project cards.
  3. Create occasions for conversations, not lectures.  This could be meetings or even one on one conversations.  A rule of thumb for many consultants is that client conversations should involve the client speaking 60% of the time.  You'll need communications techniques which involve leading with questions, and allowing information you might be eager to convey leak out at a pace you don't set.
  4. Plan to continue to put energy into building a shared project business environment all the way through to UAT and delivery.
  5. And as agile and PMI both mandate, keep checking to see if it's working--figure out what metrics you will use to judge whether the business is ready for your software and whether your various communications compaigns are working, so that you can know whether you're being effective and adjust if you're not.