The Money Files

by
A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog

RSS

Recent Posts

What’s New in Project Resource Management (pt 2)

3 Alternatives to Prototyping [Video]

What’s New in Project Resource Management (pt 1)

How to Create a Benefits Dependency Map

3 Things I Wish I Had Known About Project Budgeting [Video]

What’s New in Project Resource Management (pt 2)

Categories: resources

Hello again, and welcome to another column in what has now become a regular-ish feature: What’s New In the PMBOK Guide®-- Sixth Edition. Last month I took my first look at Project Resource Management (read Part 1 here). Now it’s the turn of the second process in this knowledge area: Estimate Activity Resources.

Does this process name seem familiar?

If it does, it’s probably because you would have come across this topic previously in the Time Management knowledge area. In the new updated Guide, Estimate Activity Resources has been moved to Project Resource Management.

Estimate Activity Resources Process

This is the first process in the Knowledge Area. We’re still in the Planning process group.

This process is where you work out what resources you need to deliver the tasks you have to get done.

Inputs

There are two new inputs, which are:

Project Charter: Project management plan. That makes sense, doesn’t it? The project management plan contains the sub-plans that can be helpful for working out how long activities are going to take. The resource management plan and the scope baseline in particular will give you information for your task estimating.

Project documents: The vaguest of inputs is now used in this process as well. It covers a range of possible documentation including:

  • The activity list (because otherwise you wouldn’t know what you were trying to estimate for)
  • Activity attributes
  • The assumptions log – there might be things in here relating to how tasks need to be carried out
  • Cost estimates
  • Resource calendars, although I’m not 100% clear why. At this point you are only estimating how much time an activity will take, not allocating a person to it. Tell me if I have got that wrong. As the next process is to acquire the team, I’m not sure that you’ll get a lot of useful information out of resource calendars as you don’t know who is on the team yet. Anyway, for the people you already know will be allocated to this project, including yourself, there could be some value in looking at resource calendars at this point.
  • The risk register – there might be some risks relating to resourcing or the approach to tasks that will help you establish how long the work will take.

Tools and Techniques

There are 7 tools and techniques for this process. Expert judgement and bottom-up estimating came from the old version of the process. These are the new tools and techniques:

Technique: Analogous estimating. Watch a quick video on what analogous estimating is.

Technique: Parametric estimating. Watch a quick video on parametric estimating.

Technique: Data analysis. This actually covers a range of techniques and different ways of doing data analysis including looking at the resource capability and skills of individuals, considering different option for tools such as whether the project would be best served with a manual or automated tools, and make or buy decisions. Here’s a video on the 5 steps for a make or buy analysis.

Tool: Project management information system. This was just known as the project management system in the last version.

Tool: Meetings. Are these a tool or a technique? I think they are a tool. When you are working out how much effort it takes to do a certain activity, you’re going to have a lot of meetings. This is time where you’ll talk about the level of effort involved, the quantity of materials or resources needed, and of course come up with the actual estimates themselves which is the whole point of this process.

Outputs

There are two new outputs, and they are the obvious ones.

Resource requirements are what you get when you work out how much effort an activity is going to take. These can be prepared in various forms like a list of dates a resource has to be available for, a person spec, a table of types of role and then % availability for a period of time, and so on.

This output was called Activity Resource Requirements in the previous version. I imagine it was changed to make it broader, as the whole focus on this area has now moved to more clearly encompass types of resources that are not people.

Second, we have basis of estimates. This is the background and the ‘workings’ that show how you got to your resource requirements. You may have a lot of detail here, like all the calculations for your detailed estimating, and methodologies. Or you may have basically just guessed like a lot of us do, drawing on your past experience.

In which case, you’ll be noting down assumptions and confidence levels, but there won’t be much in the way of calculations!

However you have arrived at your estimates, it will be good to consider the risks identified that influence the success or otherwise of the estimate. Stick these on your risk log so your resource risks can be tracked along with everything else.

That’s the end of this process. The Knowledge Area has 4 more processes to work through, so next time I’ll take a look at Acquire Resources.

Pin for later reading:

Posted on: June 18, 2018 09:00 AM | Permalink | Comments (8)

3 Alternatives to Prototyping [Video]

In this quick video I introduce three alternatives to prototyping. Prototypes on projects can be almost a mini-project by themselves. They are time consuming and can be expensive. There are alternatives if you are prepared to consider them.

If you’d like more information on the options in this video, or to find out more about pretotyping (which I decided not to include in the video but is another valid alternative) then check out this article: Alternatives to Prototyping.

Pin for later reading:

Posted on: June 12, 2018 12:02 PM | Permalink | Comments (8)

What’s New in Project Resource Management (pt 1)

Categories: resources

It’s time for another instalment of What’s New In the PMBOK Guide®-- Sixth Edition. Following on from my look at the Procurement Management knowledge area (Part 1, Part 2, Part 3), I’m now taking a look Project Resource Management.

I got so many comments and messages saying that you found it helpful to have a breakdown of the major changes in the new version that I thought I’d do another Knowledge Area. You know that in this column I try to focus on things related to project budgeting, financial management and accounting. Resource management is an area that has a huge impact on the overall cost of a project. If you can use your resources effectively, you can get the most out of them – and I don’t mean making people work overtime because their workloads are so heavy. I mean making sure that you don’t have resources sitting around waiting for work, and equipment in a warehouse taking up space for weeks before you actually need.

As before, I have to thank the authors of a free pdf including Asad Naveed, Varun Anand and others, for their comprehensive guide to what is new in the latest version. I have my own electronic version of the PMBOK Guide®-- Sixth Edition, and I’ve drawn on that too. However, I can recommend their 130-page guidance document as it is helpful for pointing out the headlines of where things are different.

Ready? Let’s dive into resource management and see how things in the project management world are different with this latest update.

We’re starting with the first process: Plan Resource Management

The headlines are:

  • The name of this process has changed, as might be immediately apparent if you’ve memorised the process names. It’s no longer Plan Human Resource Management but Plan Resource Management.
  • Other changes are much in line with what we’ve seen in other processes – making the process broader and relying more on professional judgement for exactly what needs to be included.
  • There’s one very interesting new output – more on that in a moment.

Plan Resource Management Process

This is the first process in the Knowledge Area. We’re in the Planning process group (as if you couldn’t work that out!).

Inputs

There’s nothing major changed for the inputs to this process although Activity resource requirements has been dropped. I think this is to do with the fact the whole process seems to be more aligned to not simply dealing with people any longer. By dropping the ‘Human’ from the Knowledge Area name, you can use the same processes to deal with other types of resources. And you might not need activity resource estimates in the same way for those. Having said that, we’ll see more about activity resource estimates next time. Watch this space…

The two new inputs are:

Project Charter: No real surprise there as this should include any pre-approved financial resources (i.e. budget) and a list of key stakeholders who are likely to be your main (human) resources.

Project documents: Again, this vague input turns up here. Project documents could include your schedule, from which you can derive what is needed when, requirements documentation, which also helps you determine what skills and resources you need, the stakeholder register for your people planning and the risk register.

Tools and Techniques

Organisation charts and position descriptions are out. I quite liked having org charts to rely on, but I can see that they aren’t the most brilliant source of information about people. Especially as now so many teams are flatter or self-organising. I would still recommend having an org chart for your project team though.

Read next: How to create a project organisation chart

Networking is also out. That tells me that the whole process is losing the ‘human’ element and focusing more on being about generic resources, which may or may not include people.

That’s evident in what has been brought in as well.

Data representation is the new technique. It’s a nice vague term but it includes things like:

  • Hierarchical charts – all the breakdown structures (work breakdown, organisational breakdown, resource breakdown)
  • Matrices – RACI would be a good one to include in here because it relates to what people are doing on the project and ties in neatly with resource planning and management.
  • Pretty much anything else you want to include. Even writing things down in long blocks of text is a representation of data (not a very interesting one, but it could be interpreted that way).

Outputs

So what is that output I thought was so interesting?

It’s a Team Charter.

Team Charters are the kind of thing you do as an icebreaker exercise with a new project team. They talk about the values for the team, ground rules, agreements and guidelines for how you are going to work together such as any standards for communication.

The PMBOK Guide®-- Sixth Edition says your Team Charter could also cover conflict resolution processes, meeting guidelines and decision making criteria. In other words, your Charter can become the guidebook for social interaction on the team.

The Human Resource Management Plan output has been renamed as Resource Management Plan, in line with the rest of the process.

Finally, project documents updates is a new output. We’ve seen this in other processes too. Depending on what you update, the project document updates we are talking about cold include the assumption log and risk register, but could in reality be any number of documents that get an update once you have done your resource planning.

That’s the end of this process. The Knowledge Area has a whopping 6 processes, so next time I’ll take a look at Estimate Activity Resources. Doesn’t sound familiar? It’s new to Project Resource Management. See you next time!

Posted on: May 29, 2018 08:59 AM | Permalink | Comments (9)

How to Create a Benefits Dependency Map

Categories: benefits, communication

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.

Posted on: May 23, 2018 08:59 AM | Permalink | Comments (17)

3 Things I Wish I Had Known About Project Budgeting [Video]

Categories: budget, video

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/

 

Posted on: May 17, 2018 11:59 PM | Permalink | Comments (5)
ADVERTISEMENTS

"Of all the 36 alternatives, running away is best."

- Chinese Proverb

ADVERTISEMENT

Sponsors