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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…