The Money Files

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.

Objectives

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

Outputs are delivery from a project. PM purists will tell you that a project delivers outputs and a programme delivers outcomes.

Whatever.

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.

Intermediate 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.

End Benefits

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.

I’ve been managing projects for a long time, and I’ve had budget responsibility (at least for the tracking, if not the actual spending) since virtually the beginning. In this short video I summarise 3 things I wish I had known about project budgeting. These are the hard-won tips that I’m sharing so you don’t have to make the same mistakes or wonder the same things!

Read more here: http://www.projectmanagement.com/blog/The-Money-Files/7491/

Wondering how to manage your first project budget? This infographic I created has some simple tips.

You can read more about some of the ideas on this infographic in this article.

Earlier this month I wrote about the different roles involved in contract management. There are two key roles that play a part in managing project contracts: vendor management and contract management.

They sound similar, so what is the difference?

Let’s look at the key differences between these two areas, and then it’s clearer to see why project managers need to rely on both during contract negotiations and the ongoing relationships with suppliers.

Vendor managers work with suppliers with a focus on the business’ relationship with them over time. They are looking to get the best outcomes for the organisation out of the relationship with the supplier.

Contract managers focus on individual contracts. They understand the requirements, details and can work specifically with the supplier and the project team on the needs of a particular engagement.

In other words, contract managers take a more focused view of a relationship with a supplier, looking specifically at the needs of one contract (although in reality they are probably managing more than one at a time). Vendor managers look at the holistic relationship with the supplier, across multiple projects, multiple contracts and probably have different contact points within the supplier organisation.

Contract Management Roles

The differences become even clearer when you start to look at the different job functions within those two groups.

Contract managers look at:

• Individual contracts, starting at the moment the scope of a project is clear, or there’s the acknowledgement that some kind of resource needs to be procured.
• Terms and conditions relating to that specific procurement, including working with the rest of the wider project team to establish the best type of contract (fixed price etc) for the specific deal.
• Risk management related to this contract.
• How to get the best value out of this contract.

The contract management personnel in your business will be looking at the contract lifecycle, ensuring that the project’s needs are met from start to end, and that the contract wraps up neatly at the end when everything is complete on the project.

A key skill for contract managers is negotiation. They’ll be working on setting up the contracts and that can involve a lot of research, influencing and negotiating to secure an outcome that everyone is happy with. The relationship is formed at an early stage, and a positive experience of the negotiating and requirements stage is going to set up the culture of the relationship going forward. Skilled contract managers will know how to get the best deal while still making it a win win for everyone, and starting the contract off on the right foot.

Vendor Management Roles

Vendor managers take a longer-term, strategic look at contracts and the organisation’s relationship with suppliers over time. They look at:

• The business strategy for vendors and securing resources, such as managing the list of preferred suppliers. By focusing on specific, strategic vendors, your vendor management team could negotiate a better deal, such as using the same vendor to do the build and support of a new software tool.
• Ensuring relationships with vendors stay positive, and improve over time through good communication and support from both sides.
• Master services agreements. These are overarching, longer term contracts that set out the generic terms and conditions of working together. Then each individual specific work engagement will have another contract, but this can be shorter and easier to set up, as it doesn’t have to have all the terms and conditions in each time.
• Vendor performance metrics. These could vary depending on the vendor and the type of resource or service they offer you. You can see the value of having metrics measured across all the work the supplier is doing for you.
• Risk management at a vendor level – this could include regular checks on financial performance, for example, to identify vendors who may be at risk of letting you down. Knowing whether your vendors are under financial pressure can help you put mitigation plans in place. The recent issues with Carillion in the UK are an example of where a failing supplier has caused issues for projects.
• How to get the best value out of the relationship with the vendor overall, for example, by placing several contracts with a preferred supplier and benefitting from economies of scale.

Where These Teams Are Based

Every organisation is different, so I can’t specifically tell you where your vendor management or contract management teams might be based. But generally, if your organisation is typical, this is where you will find the teams.

Contract management roles (for you, as the buyer) are likely to be in the procurement division, or with the legal team. If you are in a vendor organisation, as a contractor, for example, then your contract managers may sit with the sales team, or in the legal team.

Vendor management experts could sit with procurement, or they may be in a different area of the business. In some organisations, you will find them with the strategic project office, supporting the delivery of project contracts across the business. In large organisations with plenty of supplier relationships, they might be in a separate, dedicated business unit like a supplier management team.

What does it look like in your organisation? Let us know in the comments below.

It’s time for another instalment of What’s New In the PMBOK Guide®-- Sixth Edition. Following on from my look at the Plan Procurement Management process (which you can read here), and Conduct Procurements, we’ve reached the third of the Project Procurement Management Knowledge Area processes: Control Procurements.

The headlines are:

• The changes to this process mostly feel very… average.
• It seems to be a lot of aligning terminology
• But, there is one big change relating to closing procurements – more on that in a moment.

Now let’s take a deep dive into the process and see how the new version of the PMBOK Guide®-- Sixth Edition has evolved.

Control Procurements Process

This is the third process in the Knowledge Area. We’re in the Monitoring and Controlling process group (surprise, surprise).

Inputs

The changes all feel very cosmetic here – at least they do to me. Procurement Documents is out, to be replaced by Procurement Documentation. Work Performance Reports are out, but Project Documents are in, which would cover performance reports broadly, if you wanted to include them.

Project Documents would also cover:

• Lessons learned log
• Milestone list
• Quality reports
• Requirements documentation and the traceability matrix
• Stakeholder, assumption and risk registers
• And anything else your professional judgement feels should be included.

Finally, enterprise environmental factors and organisational process assets appear – almost as if they don’t want to be left out when they are in so many other places!

Enterprise environmental factors that relate to this process are things like marketplace conditions and your code of ethics that relate to how procurements should happen. You’ll use these factors to make better decisions about whether or not to step in and take action to keep a procurement agreement on track.

Organisational process assets are those things that relate to your company’s processes, and that can have an impact on how you work through those processes. The obvious one here is the procurement policy because that can influence how you progress, monitor and ultimately close down a procurement.

Tools and Techniques

The contract change control system no longer features, but expert judgement appears. Data analysis also features in this process as a technique, and it covers earned value analysis, trend analysis and performance reviews. These are all ways of assessing how the procurement is going, and they give you data that can help decide if you need to step in to do a bit more ‘controlling’ to keep the agreement on track.

Procurement performance reviews are no longer included (because these are covered by data analysis). Records management system has also been removed. I get that it’s a tool, but it’s not hugely useful here, at least not to the point where it has to be called out.

Inspection and audits are now split into two separate tools, whereas previously they were bunched together as ‘inspection and audits’. That takes the total T&T for the revised process to five.

I don’t have much else to say on this point – it all strikes me as pretty self-explanatory and also common sense.

Outputs

And…. Drumroll….

Here is where we have the major change to this process. Closed Procurements is now an output of Control Procurements.

Why is this a big deal? Well, in the PMBOK Guide®-- Fifth Edition, Close Procurements was a whole process in itself. That whole process has disappeared.

Honestly, this is a good thing. It reflects what we have all known for a long time: generally, project managers don’t have the authority to legally close down a contract. We don’t authorise the final payment. We don’t terminate a deal. We may be the catalyst for the payment or the termination, and we do have significant influence over how it happens, when it happens and who is involved, but ultimately, we don’t have the final say. That is the project sponsor’s responsibility, or perhaps someone high up in the finance department. Or perhaps a procurement or contracts specialist, or a lawyer. Basically, a whole host of people are better equipped to do this than we are as project managers.

That’s not to say that on some projects, the teams are so lean that project managers do have the authority to go ahead and do this. But even if you take the steps, it’s generally someone else who gives you the go ahead to do so, like the project sponsor.

The work to do the closing of contracts is now covered as part of Control Procurements, so if you are doing it yourself, you still have a few pointers in the book.

Procurement documentation updates is the only other change to the outputs list (so in total, we’ve added two to the list and taken none away).

Procurement documentation is a wide-ranging phrase that covers all kinds of things relating to your agreements, including:

• Approved and unapproved change requests
• Technical documentation
• Reports, warranties, paperwork to do with deliverables
• Financial records which could include purchase orders, invoices, bill of sales, payment records, receipts and so on
• The final reports from those inspections and audits carried out in this process, as mentioned in the Tools & Techniques
• Work schedules, timesheets for effort, plans
• And, as we’ve seen before, the guidance is non-exhaustive, so if your organisation uses some other kind of documentation for procurements, then by all means include it in your own list.

That brings us to the end of the Project Procurement Management Knowledge Area. There are just those 3 processes, and aside from the Close Procurements change, most of the other changes will not radically change how you go about doing your work.

Overall, I think the message to take away is to involve the experts in your business who have more experience in procurement than you. And if it is their job to do procurement full time, either as a contracts manager or a legal expert, then take advice, let them do what they are great at and you stay focused on getting the deliverables delivered.

If you’d like to see me summarise any other processes and the changes that the new PMBOK Guide® -- Sixth Edition has given us, then let me know in the comments below!