The Money Files

Over the last couple of months I’ve looked at some of the tech trends affecting us as project delivery professionals working in an online world.

One of the technical challenges I haven’t talked about yet of using collaboration tools is how you archive the data effectively. Archiving tools are available, but they are yet another system to integrate within your technology landscape. There’s nothing to say that their development will keep up with the constant evolution of the SaaS marketplace; in fact, I think it’s fair to say that they aren’t.

Forrester reports that only 15% of businesses actively capture and archive data from collaboration sites (Hayes & McKinnon, 2015). The old approaches to data management and records compliance just don’t cut it with new communication channels, even where interoperability makes it possible.

This problem is going to get worse before it gets better. Regulatory bodies will catch up with the increase in data being stored across collaboration tools and online and will demand that companies manage their archives more effectively.

Organizations will be forced to adopt more robust methods of managing archives with the associated cost of data management that comes with this. Archiving strategies need to be built in conjunction with the adoption of online tools and with flexibility in mind.

All the trends I’ve talked about – like AI, robotic processing automation and interoperability - bode well for both the manufacturers of project management software, and (one would hope) the people using them. Better data, better collaboration, and better end-to-end systems should increase the likelihood of success on projects because it all contributes to better decision making.

And I believe collaboration tools are already improving the results of teams where they are being used – I certainly see that in the conversations I have with my mentoring clients and the project managers I work with every day.

However, the great results we expect from tech will only come about if the tools being applied meet a genuine business need. You can’t layer tools into a broken, uncommunicative team and expect them to suddenly work together, just like that. The team culture has to be ready and open to change, the infrastructure has to be there, the management desire to want virtual and online working to succeed has to be there – and people have to see the benefit.

The business need that drives all of that is likely to overlap the areas of technology, collaboration, and culture. The way people work online—both in and outside the project environment—is not perfect, and we can expect to see more evolutions and innovations in the years to come, both in terms of tools and the way in which interactivity is encouraged and fostered.

I hope that we will eventually look back and realize that this was the time that organizations made the shift to the collaborative project environment. While the societal change may feel fast, in organizational terms, it is infiltrating slowly. Project leaders are essential in supporting innovation and effective collaboration in all its forms.

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.

I’m often asked about ‘the minimum’ for any given project management process – as if the rest of the process is somehow superfluous and anyone who does those extra bits is wasting effort.

I think most project management processes are implemented with ‘the minimum’ in mind – or at least they should be. However, project cost management is a big topic and it got me thinking about the kinds of things I would consider ‘winning’ at managing the project’s financials. What would the minimum be?

Ultimately, if stakeholders are happy and the work is progressing and under control, then I’m winning!

I’ve put what I think the key achievements for project cost management should be in the infographic below. I’m not sure that ‘achievements’ is quite the right term because this is our job we’re talking about, not some kind of badge-collecting exercise. But I couldn’t think of anything better! Leave a comment below if you’ve got a different term I should be using.

These are the things that I consider to be the basics for myself doing cost management on a project. Your ‘minimum’ list might be different. And if it is, let us know in the comments!

The key things are:

• Agree a contingency budget
• Estimate accurately as a team
• Set up good governance
• Create a financial baseline
• Work with suppliers.

This article is part eight of my look into project risk management, and today the topic is qualitative risk analysis.

I did not expect this to turn into so many parts, but risk management is an in-depth topic and there’s a lot to cover!

In case you missed them, and to save you a job digging through the archives, here are the quick links back to the previous instalments:

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

Read part 7 here: Identify Risks Process

What is qualitative risk analysis?

What is it, apart from being a word that lots of people (myself included) stumble over and get confused with quantitative risk analysis (more on that next time).

Qualitative risk analysis is simply the process of prioritising the risk based on probability of occurrence and impact, as well as some other characteristics if they are relevant. It’s what most of us would recognise as an important step in project risk management – the part where we decide which are the risks we are going to focus on because we don’t have time to spend effort on all of them.

Perform Qualitative Risk Analysis is the third process in the Knowledge Area of Project Risk Management.

The point of doing it is to prioritise individual risks by looking at how likely they are to happen (probability of occurrence) and how bad they would be for the project if they did happen (impact). When you look at those two data points, you can prioritise all the project risks.

As with risk identification, it has to happen throughout the project because risks come and go and also change in severity. Something that has a low probability of occurrence today could have a dramatically different likelihood of occurring tomorrow if something else happens to make it so.

The process doesn’t talk much about risk proximity although it is mentioned in a ‘other factors you can consider’ list in the PMBOK® Guide. I find proximity another useful measure for prioritising risks. That looks at how soon the risk is likely to happen if it happens at all. Risks that are likely to occur far in the future can be postponed for a bit while the team focuses on risks that have a likelihood of occurrence for next week.

In the process we review the risks we identified and prioritise them based on our subjective opinions and those of the team. Therefore it’s only useful if we also understand the risk assumptions and attitudes being brought to the table by the people doing the assessing.

It’s important to note that the assessment of risk is relative – you compare the risks on this project to each other, and come up with a relative priority. If you compared them to the risks on another project, you’d probably get a different result.

Inputs

The inputs to this process are:

• The project management plan – mainly the risk management plan which tells you how you should be analysing and prioritising risk based on the matrix and data in it
• The project documents, especially the assumptions log, risk register and stakeholder register
• Enterprise environmental factors like industry studies or commercial risk databases
• Organisational process assets like info from past projects.

The stakeholder register is important because it gives you input as to who should be involved – and because assessing risk is generally subjective, even if you do try to use data-based categories for the assessment, it’s helpful to know what their risk tolerances and appetite are. If you use a neutral (professional) facilitator, they can help uncover some of the bias in the team and assess the risks more objectively. You’d hope, anyway.

Tools and Techniques

There are also quite a lot of tools and techniques, many of them centering on interpersonal skills and professional knowledge.

The tools and techniques you’re likely to use include all of these (there are quite a few to choose from, you won’t necessarily use them all on the same risk – pick and choose what makes sense to help the analysis of the particular risk you are looking at):

• Expert judgement (although bear in mind they could be biased given past experiences)
• Data gathering from interviews
• Data analysis (obviously, in a process to do with analysis)
• Interpersonal and team skills, notably facilitation as we also saw in the risk identification stage
• Risk categorisation (use the risk breakdown structure or your categories list for this)
• Data representation – this just means how you write down the output of your analysis. You can use a probability and impact matrix or a hierarchical chart like a bubble chart or just keep the info in your risk log and use that
• Meetings.

There are quite a few ways you can do data analysis.

Risk data quality assessments: This is where you look at how reliable the data is that you are using for your assessment. If the data scores low, you will want to get some better data on which to base your next steps and action plan.

Risk probability and impact assessment: This is what most people think of when they think of risk analysis. It’s the table you will find in your risk management plan that tells you how a risk will score based on how likely it is to happen and the impact to the project or business if it does.

Other factors: You can consider pretty much anything you like when you make your judgements about risk. The PMBOK® Guide lists a few including proximity (as we saw above), controllability, urgency, connectivity and strategic impact.

Use as many criteria as you can do reliably and repeatably so you’ve got lots of data to go on when you make your risk assessments.

I tend to find that organisations stick to probability and impact, and some go as far as adding in proximity (how soon the risk is going to happen, if it happens). However, there are others, like how easy the risk would be to manage, how easy it is to detect and control, strategic impact and how connected it is to other risks – because that would influence a wider section of our risk pool

The challenge with doing the assessment is identifying unconscious bias in both the individuals involved in the process and the process itself. You’ll need to be aware of the risk appetite of the organisation and just challenge everything. Do your best!

Outputs

The outputs of the process are updates to the project documents, specifically:

• the assumptions log
• the issue log
• the risk register
• the risk report, which is a document you’ll be creating as you go through the whole Knowledge Area, although I can’t say personally I have ever written one. The risk report info has always been contained either in the risk register or in monthly project and steering group reports.

The end result of this process is that you have a bunch of documents to update.

At the end of the process you get a list of risks (from the process to do risk identification) with a weighting or score of how risky they are. That feeds into a future process which is to look at what you are going to do about those risks.

You’ll want to make sure your assumptions log, risk log, issue log and risk report are all up to date.

These are all living documents so in case you hadn’t realised by now, this process is something that repeats during the life of the project. You’ll be doing risk prioritisation pretty much in every team meeting, or I’d recommend at least on a monthly basis.

Share the documents with whomever needs to see them so the whole team has access to the latest information.

In my experience, as you talk about the riskiness of risks, you also formulate ideas for what you might do to mitigate them. So the processes happen in parallel, often within the same risk workshop. It’s helpful to understand them as separate activities, but don’t worry if you end up planning risk responses at the same time as having a conversation about how troublesome the risk is likely to be.

Next time I’ll be looking at quantitative risk analysis.

Pin for later reading

In this video you'll learn 4 different tools to manage cost control on your project. Cost control is an important aspect of project management, and there are things you are already doing on the project that can help you manage your finances more effectively.

For more information, read this article: https://www.projectmanagement.com/blog-post/19000/4-Tools-for-Cost-Control.

Pin for later reading

Someone emailed me the other day asking about how to use percent complete to track progress on their project schedule. It’s not the worst way to measure performance, but as I’ve got more experienced at putting schedules together, and the work I do is more uncertain, I’ve got less interested in using percent complete.

It means very little (at least, the way we were using it – which was basically a guess to feed into a schedule that was also mainly guessing given the level of complexity and uncertainty, and changes every week).

So I started thinking about schedule performance tracking – and there are plenty more ways to measure your progress than sticking to percent complete.

The infographic below shares some of the ways I know to measure your performance. You wouldn’t want to use them all on the same project necessarily, but it’s good to have options. Which ones do you use?

There’s a video here about schedule performance tracking measures if you would like some more information.