The Money Files

What happens when you can’t track project cost?

This happens when other people are spending your project budget and not letting you know where it is going. The first you hear about resources being acquired or a deal being signed is when the invoice gets passed to you from Finance with a big question mark written on it. When this happens you can’t accurately keep track of what is being spent, and whether it is being spent on the right things. How to fix it: Sort out the process for spending money. Make it clear to the project team (even those people who are more senior than you) that purchase orders have to go through you for tracking, even if you don’t have the authority to actually sign them. Let the Finance team know as well so that they can be copying you in on requests and making sure that the process is adhered to. They have no interest in receiving invoices that can’t be paid or getting the company into debt with inappropriate suppliers so they will be on your side! Read more here:

https://www.projectmanagement.com/blog-post/17629/5-Common-Project-Budget-Problems--and-How-to-Fix-Them-

Pin for later reading:

This article is part seven of my look into project risk management, and today the topic is project risk identification.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Read part 5 here: Planning Risk Management

Read part 6 here: The Risk Management Plan

Identify Risks is the second process in the Risk Management Knowledge Area. It’s where we work out what risks might befell the project.

In the process we look for overall project risk and also individual project risks – things that might affect one particular area of the project.

Typically, risk identification is done at the beginning of the project to work out what existing risks there are facing the project. However, it should be an ongoing activity, and you’ll revisit it from time to time during the project. Especially as you start to spend the risk budget or work out the cost of risk management activities – I think risk identification and management tends to spawn new risks. Perhaps that’s just because you get better at spotting them once you get started!

Inputs

There are loads of inputs to this process.

• The project management plan
• Project documents like the lessons learned log, duration estimates and requirements documentation
• Agreements, for example for procurement of external resources, because there is likely to be some risk in entering into any deal outside of your company’s immediate control
• Procurement documentation – check out what this has to say on seller performance reports, how changes will be managed, inspections and so on
• Enterprise environmental factors like benchmarking studies, commercial risk databases if you have access to them
• Organisational process assets like actual risks from past projects, checklists from past projects etc.

The project management plan has lots of areas that could give you useful information for the risk identification exercise including the requirements management plan because that might reference particular at risk deliverables.

The schedule management plan probably talks about areas of the schedule that aren’t yet fully known, and that is another area of risk.

The cost management plan may identify budget areas that haven’t been fully costed or understood, or areas of contingency that might warrant raising a risk to keep them on the radar. Cost estimates are a project document that might also be useful, because the cost may be expressed as a range and that implies a risk to the budget as you don’t know what the cost is going to be.

And so on.

Tools and Techniques

There are also quite a lot of tools and techniques, although most  of them will be familiar, I’m sure:

• Expert judgement
• Data gathering including brainstorming (as you would do in a risk identification workshop), checklists and interviews
• Data analysis
• Interpersonal and team skills especially facilitation for your risk workshops
• Prompt lists (these are a list of categories against which to brainstorm – start with PESTLE if you don’t have any of your own)
• Meetings.

The data analysis you might want to do could include root cause analysis to uncover the underlying reasons for a risk – because knowing those will help you develop a better action plan.

You could also do a SWOT analysis, or look back on previous SWOT analyses. We used to do these annually as part of the department’s strategic planning, and there were often useful overarching risks in there that would translate to a project.

Outputs

The end result of this process is the risk register. The risk register will include the initial risk responses if you already know what it is you are going to do.

There’s also the beginnings of the risk report and the updates you do to various project documents like the assumptions log, issue log and the lessons learned register – if you find anything worth putting in those.

Who gets involved?

Pretty much anyone who is working on the project can get involved in risk identification. That includes you as the project manager, the sponsor, team members, the risk management team from your company if you have one, any other subject matter experts, customers and end users… basically anyone who has any interest or influence over the project or knows anything about the work you are doing.

Risk identification is everyone’s job. Set that expectation at the beginning of the project and you’ll be fine!

Next time I’ll look at qualitative risk analysis – in other words, what to do with those risks now you’ve identified them.

Pin for later reading:

Benefits management: I wish we spent more time on this as I think it would help the wider project management community deliver more successfully. We’d know what success looked like, for a start. And we would hopefully work on fewer vanity projects because they would be weeded out – only projects with a decent return on investment (whatever that means to you and however you measure ‘return’) would get started… and hopefully completed.

A benefits dependency map is an easy thing to create to bring some sense of clarity to the benefits you see on a project.

This infographic gives you the headlines: it’s all about linking project objectives through to deliverables and then intermediate and end benefits. Then you can easily see how the project is going to achieve that return the business case talks about.

And if it isn’t clear, you’ve got time to do something about it before realising the project isn’t going to deliver the benefits you expected. Tweak the objectives, change the deliverables – do something to bring the project back in line.

Find out more about benefits mapping here.

Disruptive technologies such as big data are hitting businesses across all functional areas, not just project management. And with the recent uptake of collaboration tools for virtual teams because we haven’t been able to get into offices in the way we could before, it’s even more important to understand what that tech might mean for us.

Companies have to come up with practical ways to incorporate this massive amount of change and to sift through the trends that are worth adopting while ditching those that are not relevant at this time. This is starting to come to the fore in the form of the chief digital officer or other digital leadership position at the very top of businesses. We are also seeing digital PMOs—divisions supporting the project structure in the way a traditional PMO would, but with a leaning toward paperless, integrated, and online ways of working, along with the culture changes that brings.

Shadow IT – a challenge

Shadow IT is another challenge for the person or team taking on digital leadership within their organization. This is where employees have downloaded their own apps or software for work purposes.

I think it’s common in businesses where IT processes are slow and bureaucratic. When individuals don’t want to have to wait for software to be formally approved and installed, the Internet makes it possible for them to download pretty much anything they want and get started immediately. This forces business leaders to look for adaptable, speedy, and flexible models and processes while also giving them the headache of managing data security and unapproved software.

The culture of collaboration

It’s not all about the tech. Part of the challenge facing the digital leader, be that a project manager or a PMO director, is managing flatter teams, both across business teams and within projects.

Employees create their own internal networks outside of the traditional hierarchy, which potentially makes many of the formal line management structures redundant and forces the organization to become flatter. The digital divide—those employees who are familiar with digital working practices and those who are not—is a further team-related problem that digital leaders have to face up to and proactively manage.

Successful collaboration and teamwork comes from a culture that supports those ways of working. If virtual teams are to be successful, and if collaboration tools are to be fully embedded in the working practices of the team, then it’s important for businesses to invest in collaboration offline as well.

I think as we move forward, we’ll see greater investment in building corporate culture, fostering employee engagement, and creating the environment to deliver successful change. All of this underpins the use of any technology and supports the business objective of getting the right people to do the right things the first time, which cuts down on overall project costs.

It also supports the urgent need for knowledge sharing in a global economy that is facing significant talent gaps. As the Baby Boomer generation leaves the workplace, taking with them an incredible amount of organizational knowledge, companies need to find alternative ways to capture and maintain their knowledge assets. Technology (like wikis) has a part to play, as well as collaborative work environments where knowledge is freely shared.

This article includes a few points that were made in my PMI book: Collaboration Tools for Project Managers. Given what we’ve been going through and seeing so far this year, it felt appropriate to try to pick out some comments on tech for teams and where that might be taking us – because it seems to me that virtual working is here to stay.

Pin for later reading:

This article is part six of my look into project risk management, and today the topic is the project risk management plan.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Read part 5 here: Planning Risk Management

So: risk management plans. What should you expect to see in one?

Here are some things you can include in your risk management plan. You don’t always need all of them – good project management is all about tailoring, so pick and choose what is appropriate and necessary for your project.

Risk strategy

This is a statement about the general approach you are taking to managing risk on the project. You can reference any organisational guidelines, the risk appetite of the company and the business context for risk management.

Methodology

The methodology section is where you define the specific way you are going to manage risk on the project. That includes the approaches you will use, any software tools or other tools that are available to you and that you’ll use, and the places you’ll get data from to make decisions about risk actions and planning.

Include information about tracking risks: how will this be done? How will you record what has happened and how will adherence to the process be audited (if it will)?

Roles and responsibilities

I think it’s always useful to have this section in the risk management plan, even if you refer to the main roles and responsibilities document or a different place in the project management plan. I think it helps to know who is responsible for what, and for everyone to see that it is everyone’s responsibility to be on the look out for new risks.

Document who is going to lead risk management, any supporting roles, and who else is ‘hands on’ with the risk management process. Explain what their responsibilities are.

Risk budget

It’s also handy to record the project funding available for risk management (if you are lucky enough to have a dedicated risk budget). I think it’s worth calling out even if there is no dedicated risk budget, because it makes it clear to  senior execs and the project sponsor that managing risk takes money, and if there is none, there’s a limit on what you can usefully do to avoid or mitigate the risk.

In this section you’ll want to talk about how you can access the risk budget – because let’s be positive and assume there is one – and how the funding will be tracked and reported so you can see when it’s running out.

Timing and reporting

Write a short section that talks about how often you’ll do risk management reviews, when each part of the process takes place and how risk management is woven into your project schedule. I would include formal risk workshops in here, alongside a formal monthly risk review, while noting that risk management is an ongoing activity bound into everything else we do on the project.

You can also record how and when risk reporting is going to be done, and what is going to be included in the risk reports. I would mention what level of risk is going to be reported in each place. For example, in Steering Group meetings I would report every significant risk. In monthly project reporting, the template we used to use only had space for the top 3 risks.

Categorisation of risk

Finally, document how you are going to categorise risk on the project. You might already have organisational-wide definitions and categories, in which case you should use them. If you don’t, you can easily make up some categories. Things like Technical, Commercial, Reputational, Environmental etc are all common categories. Think about what the project is trying to achieve and what departments are involved, and that can be the basis for your categorisation. I would start with a simple list and allocate each risk to one category only.

If you want to get a bit more detailed and dive into risk management further, you can create a risk breakdown structure which is a useful way of grouping risks and seeing how they interact and relate to each other.

Risk appetite

Include a statement about how much risk the project (or organisation) is prepared to accept. You’ll get this either from ‘official’ company sources or from the project sponsor.

Remember that risks can aggregate together: lots of small, insignificant risks can make for one massive problem if they all happen at the same time.

Definitions and matrix

Include definitions of how you calculate probability and impact. It’s really important that everyone understands what these two concepts are and then what the different levels mean. Ideally, you should have this at PMO level if not organisational level, because then you can more easily comparer the risk profile of different projects.

Alongside your definitions, include the probability and impact matrix that helps you assess the risk score. Or link to where it can be found – there’s no need to reinvent the wheel or create lots of additional pages in your documentation, just reference the PMO documentation if there is any.

Pin for later reading: