The Money Files

As your PMO grows in size and responsibility, you’re going to need to get more people to work in it. That can be quite a hard sell, as it’s often difficult to explain what the PMO does and justify the value it brings, let alone secure the funding for an additional role (or two).

In this video I share ideas for how to put together a successful proposal for securing project management office resources as your team gets bigger. Top tip: use statistics and evidence where you can to show that the remit of the PMO is expanding and that can justify the extra person to support the additional workload.

Tell me in the comments: how many people are in your PMO? Is it easy to get funding for additional resources or are you stuck at a certain team size because of an inaccurate perception about what the PMO does? I’d love to hear!

Pin for later reading

Is it time for your project to wrap up? Congratulations! In this infographic I share a few tips for closing down your project in a smooth and controlled way.

These are things I’ve learned over time, because I’ve struggled in the past to get people to take responsibility for the stuff that the project has delivered. I’ve realised that a strong closure process and handover to the operational team is crucial if you want to be able to walk away from the project and not end up as the ongoing informal support person for whatever it was that you delivered.

In brief, my top suggestions for the closure process (not so much the handover to live, that’s a whole other topic) are:

• Close off everything on your project schedule by marking it as complete.
• Update the risk log and copy open risks to the closure document.
• Organise a post-project review to talk about how the whole thing went.
• Celebrate! Don’t forget this part 😊

Whare are your top tips for the last stage of a project? Share your ideas for making the project closure process as smooth as possible in the comments below!

The Practice Standard for Earned Value sets out the Develop Schedule process, which is simply a way of turning all the stuff in your WBS into a workable plan with timescales. Basically, it’s time to turn the WBS into a Gantt chart.

I guess you could use earned value for non-Gantt chart scheduling, but I can’t get my head around how that would work (tell me in the comments if this is something you do!).

The Practice Standard doesn’t go into loads of detail about how to make a project schedule, as there are other places you can go for that information – like the Practice Standard for Scheduling and also the PMBOK® Guide. However, the particular earned value bits of scheduling are covered in the EV standard, and especially this process.

Inputs

There are two inputs to this process:

• The scope baseline
• The resource breakdown structure.

The scope baseline is more than just the WBS. It also includes the scope statement and the WBS dictionary, so it’s the full set of documents about project scope and the full understanding of what the scope is. It’s the exact spec to a level of detail that allows someone in the team to get the work done.

The resource breakdown structure is the comprehensive guide to who is working on the project as well as the other, non-people, resources required to get the job done.

What to do

The Practice Standard is light on the ‘how to schedule’ element, as I mentioned above, but from a specifically EV perspective, here’s what to take into account:

• Create the schedule in a scheduling tool.
• Make sure dependencies are noted and accounted for, using the scheduling features of your tool
• Manage the relationship with the budget by setting up whatever you need to in the system that will manage that relationship. This might mean setting up control accounts in your accounting software or however you are tracking the budget figures for the project.

This last part is particularly important because it’s the way the schedule and budget relate that drives the EV calculations. You need the same dates, milestones, assumptions and resources set up in each so the measurement is consistent between both systems. In other words, you need to be sure that the work being done is accurately accounted for so that you are working out the right planned value.

Finally, get your project schedule approved the normal way and it then becomes the schedule baseline, against which you can track progress and monitor performance.

Outputs

The output for the Develop Schedule process is only the integrated master schedule, as you would expect.

The ‘master’ part of the IMS, as I understand it, is a way of referring to the fact this is the top level project schedule. The control account managers may have detailed sub-plans for their parts, and you might have intermediate level plans, depending on how complicated the project is. But the IMS – the master schedule – is the full picture of everything required to get the project done.

Dealing with changes

As with any aspect of project management, we have to allow and account for what happens when things change. It’s great to have the IMS as your overarching master schedule and performance measurement baseline, but it’s unrealistic to think that we’ll deliver everything perfectly to plan because that isn’t what happens in real life.

So, we need to use the change control process as and when needed, to make sure the whole thing stays aligned to actual performance. That’s not to say you’ll be re-baselining the project every day, but you will keep the schedule up to date with real progress to compare back to the original baseline, and then re-baseline if and when that becomes appropriate.

If you make schedule changes, you also need to consider what that means for the project budget. When using EVM, you can’t get away from the fact that the two need to align – that’s the point of this way of project tracking, after all.

The IMS exists as a way to outline what the team is planning to do and it gives you the logic for measuring performance. It’s important to get it as good as it can possibly be because it’s what future progress will be measured against and it’s used for calculating future outcomes – and you should want those to be as accurate as possible.

Next time, I’ll be looking at the next process in the earned value landscape, which is establishing the budget.

Pin for later reading

I’m surprisingly enjoying my deep dive into earned value management – it’s not a technique I would say I’m hugely experienced in, but it’s something I’m committed to learning more about.

In this infographic I summarise the 5 limitations of earned value:

• Numbers don’t tell you the whole story and you need a bit of contextual narrative too
• Data has to be accurate otherwise you’re making assumptions and predictions based on what isn’t truly happening
• Quality has to be assumed because EV doesn’t factor in quality as part of the way it measures performance
• EV and Agile aren’t perfectly aligned but that’s OK because if you’re in an agile team you’ll have other (more appropriate) ways of measuring performance
• There is a lot of jargon! And the words sometimes can get in the way of being clear about what you are talking about.

What other limitations of Earned Value have you come across as you’ve used it? Or perhaps you aren’t using EV because of another limitation that is stopping you from embracing it in your environment? Let us know in the comments below!

This is an occasional series on project risk management, and last time we looked at what options are available to you as part of your risk response strategy. Today, we’re looking at how do you actually implement risk responses.

There’s a whole risk response process in the PMBOK® Guide that helps you work out how to approach this part of managing your project.

The Implement Risk Responses process is where you take your response plans and actually do the work to make them happen. The execution of risk response plans is important because you can’t always rely on talking about a potential problem as enough to get it remedied.

There’s no single time to be doing this – you’ll be identifying risks the whole way through your project, so as and when you’ve come up with a new one, you’ll prepare the risk response plan and then implement it. Make time during the project to ensure you think through how to do the implementation part of the risk response strategy – incorporate it into your regular risk meetings.

Inputs

The inputs to this process are:

• The project management plan, and in particular, the risk management plan section
• Project documents including the lessons learned register, the risk register (because this is where you will have written down what you are supposed to be doing) and risk reports if you have them
• Organisational process assets.

The risk management plan will include the names of people responsible for the risk management process, and that’s helpful for assigning ownership of the management actions. You may also have info in there that relates to the level of acceptable risk – this is what you are trying to achieve by doing your risk management activities. It’s not always necessary to remove the risk completely; sometimes just reducing it to a level that’s acceptable to the project or the business is enough.

The OPAs are things like the corporate lessons learned repository which might give you insights into how other risk management approaches were implemented and what were effective techniques at doing so.

Tools and Techniques

The tools and techniques are going to depend very much on what kind of implementing you are doing. How to implement the ‘acceptance’ strategy is obviously very different to an approach where you are going all-out to mitigate it with a huge action plan.

However, there are some common threads to what kinds of tools and techniques you can adopt here, including:

• Expert judgement (drawing on the expertise of your team leaders and your own knowledge about how best to implement the plans)
• Interpersonal and team skills, especially influencing – that’s mainly going to fall to you to ensure that the work gets done
• Project management information system (document and record what you are doing).

Basically, use your PM knowledge to ensure that the planned actions for risk response actually happen.

Outputs

The outputs of this process are:

• Change requests (because your plans might involve adding or removing tasks to your project schedule, for example)
• Project document updates, especially to the issue log, lessons learned register, team assignments (as people’s work assignments need to be updated to reflect their new tasks), the risk register and risk reports.

And, of course, the work of doing the risk responses – built into your To Do lists and action logs, and discussions with team members.

As you get more experienced with project management, you won’t spend much time thinking about ‘doing’ this process. It just happens naturally as part of the things you’re doing on the project. It becomes an integrated part of how you manage risk, and so much aligned to the other parts of risk management that it all flows together. I don’t have meetings where I sit down and say, “Today we are going to do the implement risk responses process.” That’s just not a called out part of how we make risk management happen… but the process does happen. It’s simply integral to everything else and a natural part of how we work together as a team.

The process exists to remind you to make sure that risk responses aren’t something that you simply talk about. You want to avoid that issue of writing down risks and having a lovely risk log, but all the risks sit on there and nothing happens to actually take action on them.

Next time I’ll be looking at how to monitor risks to ensure that your action plans are being carried out as you would expect and are having the right impact on your project.

Pin for later reading