Skip to main content

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.

Comments

  1. I would like to ask one question "If this project is so important to the stakeholders and they need to know about it so much - why are they not sitting with the team in the shared space all the time?"

    -Sudhindra

    ReplyDelete
  2. Hi Sudhindra,

    That's such a good point. It's a fine balance.

    The stakeholders who aren't in the team room have other stuff they are focusing on, and that's actually a good thing. The product owner should be a funnel for all the other people out there who are doing customer research, focus groups, competitor analysis, and so on. And your operational teams are supporting all of their current business-as-usual processes to keep the flow of money coming into the company.

    As you point out, what you want to do is ensure that there's enough communication to keep everything aligned--but do it without drowning everyone in too much of a time commitment.

    ReplyDelete
  3. Excellent post, but assumes the internal communication on the team is good because they are in a shared space, virtual or not, and constantly communicating. Do you have any recommendations when the development team is dispersed globally, and although using Rally, somehow important information does not get communicated between developers, with lots of "I didn't know x was doing y" or duplicate effort or effort at cross-purposes?

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica