A benefits dependency map is a fancy way of saying that you have a diagram that links what your project is delivering to the benefits that the business receives as a result.
It has been probably my most useful communication tool with board members. They love it, because they can see exactly why the project is happening and how I am meeting strategic objectives with what I am working on.
Why you do it
While the comms to senior stakeholders is helpful, the major benefit of this kind of diagram is actually the process you go through to draw the thing in the first place. This is because going through the process helps you work out what you should be focusing on.
The map helps you see what is important to deliver and why that is the case. This information can inform your decision making and risk management, making it easier for you to prioritise work in the future. If you know a particular deliverable links directly to a benefit, you can make sure your team focus their efforts on that one.
And as I mentioned, it is also a good communication tool for sharing the overall benefits with stakeholders. Especially if you draw it at a high level so it fits on one PowerPoint slide!
What is a Benefits Dependency Map?
Your benefits dependency map shows the link between your project or programme and the business or organisation’s strategic objectives. Personally, I have found it useful to identify where benefits are ‘claimed’ twice and there are overlaps in the business case. Two different projects in a programme claimed the benefit, and that could have skewed the results (or the interpretation of the results) of what we delivered. Having the map meant that we could link both projects to the same benefit to show that they were both important, without double-counting. That saved me a big headache with our financial team who would have expected twice the cost savings – which would have been impossible!
You can use the benefits dependency map to streamline your projects benefits too. With the information in it, you only focus on the essential, important headlines (although you might want to note the smaller benefits somewhere else).
That works both ways. You can also then cross-reference outputs with benefits to see if you are busy delivering anything that doesn’t directly link to the benefits that you are trying to get.
A further, useful, cross-reference to do is to check that you have enough benefits and that they are evenly spread throughout the project or programme. Are there any areas of the project that support loads of benefits, and other workstreams that have very little in the way of practical benefit-driven output? That will tell you where you should be putting your efforts for resources and prioritisation.
What goes into a benefits map
Creating a benefits dependency map is actually very easy. You read the map from left to right. You create it (or at least, I do) as a flow diagram or flow chart. I do mine in PowerPoint. I use PowerPoint because I happen to have it, I know how to use it and so does everyone else on my team. You can use any drawing package you like or none. In the past I have drawn freehand in my notebook and taken a photograph – it’s low tech but it gets the message across.
Here are the things you need to include in the map.
Start at the left hand side of the page. Think of your page in columns. You will need 4 columns. You can add the swim lane style dashed lines to create columns on the page if you like, but I don’t like to do it that way as I don’t think the lines add anything. I mention it just so you know that you have to split your page into 4. Do it landscape, it’s easier.
Write down the project objectives. Pop these in text boxes (the PowerPoint way) so that they stand out and so you can easily use arrows to link the objectives to the next part of the map.
Outputs are delivery from a project. PM purists will tell you that a project delivers outputs and a programme delivers outcomes.
That assumes that a project alone cannot deliver anything that is absorbed into the business and delivers an outcome, but let’s leave the debate about whether benefits can be included in project management to another day!
If you subscribe to the ‘projects can’t deliver outcomes’ school of thought you may need to squeeze in an additional column that describes whatever business change is required to turn the output into an actual benefit.
It’s worth noting this because people sometimes assume that if you deliver a new product, it will magically sell millions of units without any effort on behalf of anyone else, but you need the rest of the business lined up to support the benefit (sales) through educating staff on what the new product is, training the sales team, marketing efforts that span beyond the life of the project etc.
If your management team need a bit of help working this out for themselves, give them a headstart by being specific about the role that business change has to play in the delivery of benefits.
Next, add in the immediate benefits. These go in the third quarter of the page, off centre to the right. Add these into boxes and draw lines from the project outcomes to the correct benefits.
In practice, you’ll have to move the benefits around a bit on the page so you don’t end up with a mess of lines. It might take several attempts to get things in each virtual column in the right order so that the lines don’t cross each other in a big mess.
These are the quick wins, the obvious things. When you have completed your project, this is what you get for the business. Perhaps that’s more sales, better staff morale – it could be anything but it’s probably what you put in the original business case.
This is where you link the immediate project benefits to the longer term strategic objectives for the company. Create a set of boxes on the far right of the page with the relevant strategic objectives in. Don’t add on objectives where your project has no link. If you do that you’ll end up with floating boxes and nothing linking to them. This will only serve to make it look like you have forgotten something or that you aren’t delivering enough benefit. So make it easier on readers by only documenting the strategic benefits that you can justify linking to.
You should be able to draw a line between the immediate ‘business case’ benefit and a strategic corporate objective. If you can’t, it’s time to start wondering why you are doing the project in the first place.
And that’s it! You should have a single page with a number of boxes on, each box leading to another, until you reach the strategic objectives of the company. You can link what your project is doing to the corporate goals.
Now that’s a powerful communications tool.
In this video I share a few ideas for how to get started with project communications when you don’t have much money to spend on getting fancy mugs printed with your team logo and all that. You can do some great work communicating about your project even if money to do comms is at a premium. You might not be able to take all these ideas instantly and apply them to your own project, but I hope they give you inspiration for finding similar ideas that will work in your environment.
It is possible to communicate far and wide, spreading the vision about your project, and do it all on a shoestring!
Read more about the ideas in the video here: http://www.projectmanagement.com/blog/The-Money-Files/7570/
In today’s installment of my occasional series interviewing experts in their field, I caught up with Jack Appleman. He’s a proponent of clarity and communication – and he wants people who write for business to just do it a bit better.
Being able to get your ideas across in writing is so important. Without that, you can’t convince, negotiate, delegate or engage your stakeholders. So, let’s dive in.
Hello Jack. What's the mistake you see most from people when it comes to business writing?
The two biggest mistakes are overwriting—conveying the same point multiple times with too many words—and inserting pseudo-sophisticated text in an attempt to impress the readers when most people want clear and straightforward language.
Yes, I see that in comms I get. Hopefully not in what I send out! What tip do you think would most benefit project managers writing about their projects at work, say, in an email or proposal?
Start with a paragraph that succinctly explains the bottom line because readers are increasingly impatient.
For example, begin a project proposal with a compelling paragraph that sums up the most important information and then provide required sections such as goals, required facilities, deliverables, etc. This offers readers a choice: Those who just want the top-line information can stop after the first paragraph while others who want more details can keep reading.
Many project managers get promoted from operational or technical jobs where everyone knows the jargon, to a job where people don't. How can people reframe what they know about technical writing into business writing for a wider audience?
Apply the same principles for both types of writing. Technical writing typically involves communicating instructions or information about technical issues or specific projects, which must be clear, succinct and well-organized—the same skills needed for business emails and other documents.
Often, technical documents are unnecessarily filled with jargon. When writing to a non-technical audience, either avoid the jargon or explain any term that readers may not understand.
OK, great. How can people develop their writing skills?
Use common sense when reviewing what you’ve written. Ask yourself, “Is this good? Would I be satisfied if I were reading it?”
Try to complete your first drafts faster so you can allot more time on the all-important editing phase. You should also consider taking a live or online business writing course or signing up for one-on-one writing coaching.
Effective business writing—for project managers and everyone—is about getting your message across in a clear, concise and well-organized way so the reader understands it and takes your desired action. It’s not any more complicated than that!
Much of what project managers do is computer-mediated communication, either email or instant messaging, or through a project management tool. What are the pitfalls of that and how can project managers get round them?
Today, virtually everyone communicates via email or text messages. Apply the same principles of effective writing regardless of the communication channel, and practice proper etiquette (e.g., complete sentences, no weird abbreviations and correct grammar).
Plus, recognize when the message is too complex or sensitive to send via instant messaging or a text.
Good advice, thank you! How can people find out more about you?
Jack E. Appleman, APR, CBC, business writing instructor and author of the top-selling 10 Steps to Successful Business Writing (2008, ATD Press), has developed innovative teaching methods to help working professionals achieve better results with their writing. The principal of Successful Business Writing, Jack has led workshops, webinars and coaching programs for organizations including HBO, Johnson & Johnson and the U.S. Olympic Committee, which have consistently earned outstanding evaluations.
This month we’re talking about all things outsourcing and there’s nothing more important than communication when it comes to making an outsourcing partnership work.
More specifically, there’s nothing more important than trusted communication. People can be sceptical about outsourcing arrangements and if you want the partnership to really work it has to be built on trust.
In other words, you want them to believe the information that is in your status reports and other comms and to take what you say at face value. They should trust you to report the right things and they should trust the content in the report itself to be truly representative of the project today.
Here’s how to make your project communications trustworthy, and it’s easier than you might think!
First, there should be no surprises for your sponsor.
Whether you are working for a client or internally, reports aren’t the best way to find out about major project problems. There are other ways that you can do that. You should put big problems in your reports but only once you have cleared them through other communication routes.
Share The Reports With The Team
You should send your reports to your team members as well. I mention that because I know not everyone does it by default. Sometimes reports only go to stakeholders, clients, users, customers but not the people who are doing the job.
The fastest way to build trust between you and the team is to not drop them in it. You don’t want your reports to be full of blame and things that come as a surprise to them. This isn’t the way that they should find out about changes or schedule amendments. You have other routes open to you to inform them about those, although of course they should be mentioned in your reports once everyone knows about them.
Mostly we think of formal project reporting and communication as something we do to people outside the project team. But you have to have your team on side. They are ambassadors for your project and they need to be talking about it and promoting the benefits of your project with the people they work with and meet.
They will provide you with updates for your standard communications but they’ve got to understand current status and be able to field questions from your users or their colleagues as well, and they can do that better through understanding the big picture, whether they are on the outsourcing side or the customer side.
Stay on Message
Everyone hears the same version of the story, whatever their position. It undermines your communication efforts if different stakeholders are receiving different versions of the truth.
Staying on message limits the impact of your message being changed as people share it with their colleagues. It’s also surprisingly easy for a team member to undermine your efforts about talking positively about your project, even if they don’t mean to, with a few off-hand remarks.
Finally on this, you’ll be more trusted as an individual if your team feels that you are representing their work properly in your reports, and they’ll believe that you are sharing everything with them if the reports are a transparent reflection of the work. If they see – whether they are a colleague or part of the management team – things in there that they weren’t expecting then they could start to feel that you are hiding things or simply that you aren’t on top of it all.
The Benefits of Trustworthy Reporting
The main benefit to come out of being trustworthy when communicating about your project is simply that people trust you. This is huge in project management and leadership because someone with good credibility who is trustworthy will find it much easier to get work done through other people. Your reputation counts for a lot.
You’ll also save time because you’ll believe what they are telling you and you won’t have to go routing around for a different version of the truth, or spend too much time trying to put what they’ve told you in a way that’s acceptable to the stakeholders.
When people feel confident that they can give you the truth about a problem and you aren’t going to turn that against them, then you’ll find it easier to make your reports accurate because they’ll tell you the truth from their side too.
Outsourcing relationships can work and be hugely successful (and I’ve seen some of those in action) but you need great communications based on trust and teamwork to really get the benefits of why you outsourced in the first place.
Staying on message limits the impact of your message being changed as people share it with their colleagues – and this goes for positive marketing messages as well, not just crisis management communications. Having said that, ultimately you can’t stop people talking to others about your project, and from a marketing perspective when the message is positive, you absolutely want them to be talking about it.
These days everyone has an audience. They always have had, as colleagues have convened at the water cooler or around the kettle in the office kitchen. Today they have the tools to share information more quickly with their networks through social media, internal social networks and they’ll add their opinion there as well.
Remember that it’s people who stop projects, not crises. So being prepared in your communications planning for problems gives you a better chance of controlling gossip and unhelpful communications and thus limit the overall impact on your project.
This diagram is very linear but it’s important to recognise that the more you can hear what’s being said by the people hearing your message, the easier it will be for you to either correct the story or respond to their concerns.
Create Feedback Loops
Feedback loops are an essential part of your marketing communication because you need to know what is working. If isn’t working, ditch that method of communication and try something else.
A simple way to start gathering feedback today is to tell people how to give you feedback, for example in the last line in a newsletter article – provide your email address and a call to action to send you their comments. When you do receive and act on feedback close the loop by telling them what you have done with it.
On projects there’s also a formal feedback loop in the form of the post implementation review at the end of a project.
You do get more immediate feedback than that with communication activities, especially if you are talking to someone face-to-face, but I believe it’s worth building formal feedback loops into your marketing activities.
This gives you the chance to track how you are doing and correct your course if necessary. Here’s an example of a project I’ve done this on.
Feedback Improves Satisfaction
We tracked customer satisfaction results monthly. I gave each stakeholder group the opportunity to rate the project team across four measures: management of top issues, communication, planning and delivery. The stakeholder group that gave the project the worst scores was actually the IT department, and that’s the graph you see here. A bit embarrassing because that is the team I work in. The issue was spending so much time communicating to stakeholders outside the project team and my department that my immediate colleagues were getting a rough ride.
There were too many last minute requests from my project team, or assumptions made that didn’t allow the rest of the IT department to do their jobs efficiently. Once I put in place monthly stakeholder satisfaction scores and understood what was going wrong it was a slow but achievable job to turn around the perception of the project and build engagement.
We managed that by using each monthly conversation with department heads to explain how we were addressing their concerns and asking what else we could do to improve the experience of being on the project. We proactively marketed what we were doing differently so they felt listened to.
By taking the feedback into account and acting on it, I was able to manage expectations and improve the both satisfaction and project management practice. It was an exercise in marketing the project and the achievements and there’s a lot more about how it worked in my book, Customer-Centric Project Management if you’re particularly interested in that.
From this project we learned two things. First, you have to be able to adapt what you are doing. And second, satisfied, engaged stakeholders are a huge asset when things go wrong on projects. Putting in the effort helps you build great relationships and that’s a massive advantage when you need to take difficult decisions.
For more information on project marketing and the tools you can use to communicate about your project, watch my PMXPO talk on the topic. You can get it here (and claim a PDU at the same time).