Agile Risk Management Approach

 PRINCE2 Agile Risk Management Approach

Introduction

This document describes how to manage risk within an agile/PRINCE2 project environment.

Risk management procedure 

 

Tools and techniques 

Identify risks using the PRINCE2 Agilometer 

Records

The risk register should be visible and clear for all to see and use, like this one:

 

Each risk should be written on a post-it note and put onto the whiteboard in it’s appropriate grid location, depending on the probability/impact assessment

Reporting 

Risks will be discussed during daily standup meetings or with the project board when they visit the project room.

Timing of risk management activities 

At the end of management stages, after any significant release, a re-assessment of the environment using the agilometer will help. However, risks could be identified and discussed at any time.

Roles and responsibilities 

Everyone is responsible for identifying risks and everyone collectively should help the manage risks, however, some would need escalating for further help, see the risk tolerances below.

Proximity 

How close a risk might happen is referred to as its proximity they can be categorised as: 

    Imminent - will potentially happen within a sprint, 

    Within the management stage, 

    Within the project, 

    Beyond the project - after release into operations

Risk responses 

We can respond to risks this way:

 

Early warning indicators 

The project manager and board could monitor the behaviours of the team and look to see if they are appropriate, and the team should monitor their own behaviours openly and honestly.

Risk tolerance 

The team can manage risks that are in the purple boxes themselves.
Risks in the blue boxes should be raised and discussed with the project manager.
Risks in the yellow boxes should be discussed with the project manager and project board.
Risks in the red boxes should be discussed with corporate management.
Security risks should be raised with the cyber security team no matter where they are on the grid.
Health and safety risks should be raised to the department H&S officers.
Reputation risks should be funnelled through the communication management team.

Risk budget 

Due to the low risk to delivery, a risk budget is not necessary.

Here’s some links to simple tips on how to make your project or programme office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

Outputs, Outcomes, Benefits & Dis-Benefits are Agile?

There has been several discussions about the correct definition of these words but most seem to understand that an output would be a deliverable from a project which lead to outcomes when something changes and these things should be beneficial in some measurable way. 

Dis-benefits are negative outcomes that almost every change experiences in some way. I’ll come back to these. 

Let’s take an example that differs from most of the examples provided. 

Locally we have had more freezing temperatures lately and the footpaths have been dangerous to walk on, particularly for elderly or disabled people. 

Our local council has done nothing whatsoever to make the footpaths safe and ice free. This is a true statement but the objective of this blog is to help understand the reasoning behind the relationships rather than critical of the council.

Let’s launch a project to grit the footpaths.

The main roads are gritted because they are legally obliged to do so, that is out of scope here.

Government is trying to discourage us from driving in many ways but if we don’t drive to work we need to walk or cycle, so there is a clear need to do something otherwise we will all be driving again. I am personally biased here because I am one the very few who is in the fortunate position of actually walking to work.

The output is a little intangible but we could state something like “Thawed footpaths” or “gritted footpaths” 

Outcome: Safer footpaths, fewer people falling over and fewer people driving which reduces emissions. 

Benefits? These should be measurable improvements in something related to a strategic objective. This is where things get tricky because where’s the benefit to the council?

Fewer people falling over and getting injured is a benefit to the NHS and the individual concerned, and we could argue that this is not a benefit for the council, even if it should be. 

Fewer people driving to work is a benefit to the road capacity but how much money is actually saved by a few less cars? Even if 50% of drivers decided to walk? Savings in road maintenance is probably almost zero. 

Reducing the use of vehicles will contribute to net zero and one could argue that this is a benefit, but where is the cost/benefit analysis.

Where’s the cost/benefit in this? If we are going to invest time and money into a project, then there should be some return on that investment, that is the logic behind project business cases.

Are there any dis-benefits here? Yes, gritting the footpaths would prevent people using them whilst the gritting is in process. 

Let’s look at this in another way, the way that has justified many government projects. 

The changes that the government has implemented to discourage driving particular vehicles, such as the road tax costs based on engine capacity and emissions. 

The congestion charges move the traffic from the city centre to the ring road. Recently they have introduced fifteen minute zones which discourage driving.

Improvements in public transport could be considered an option but many of these have been larger capital projects such as installing trams on existing highways which tend to also discourage driving. That is a huge capital expenditure and I am not sure any have actually paid back the initial investment, but I do not know for sure. I do recall, as a child, my mother taking us to the centre of Birmingham to watch the last ever tram to leave. 

Why did they close the trams? They were too inflexible in a rapidly changing cityscape. 

This blog, like lots of projects has drifted in its scope, away from why the local council did not grit the footpaths, but in a nutshell, there’s nothing in it for them.

Congestion charges, equals more revenue.

Fuel price hikes, equals more revenue.

Road tax based on engine size, equals more revenue.

Fifteen minute zones, equals more revenue.

Trams discourage driving and encourage public transport also equals more revenue.

Bus lanes mean more revenue for the buses that travel along them and the additional traffic congestion uses more fuel and therefore also equals more revenue.

Gritting the footpath does not equal more revenue, it equals less revenue from fuel tax.

Investment in Outputs, is one thing, if nobody used the footpaths after gritting, we’ve wasted money.

When people change their behaviour, they walk to the shops or work and we have the outcome we are seeking.

Those outcomes lead to measurable benefits (and this is where some manipulation of the financial rewards takes place)

In an agile environment the developers would decide that the output had value for a customer somewhere, not necessarily as a cost/benefit business case, but it has value.

Therefore we could argue that agility is more likely to achieve the long term outcome, because they are prepared to invest without an immediate return on investment.

Here’s some simple tips on how to make your project or programme office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

There's No “i” in Team

 What it is this statement meant to do:

To help people understand that they can perform better when working as a team and taking the views of other team members into consideration. 

Executive Summary (of the reality of this statement):

A telling off for anyone brave enough to show some initiative and do something that the boss didn’t tell you to do. Daring to have an opinion. Disagreeing with the boss.

The detail of this statement in use:

Attempting to locate the source of this statement is quite a challenge because almost every manager and, more appropriately, management consultant, has used the term, but all would deny it. But, if they hadn’t used the term it wouldn’t be as well known.

Some people work better in teams, some work better alone, not everyone appreciates how important it is to work in a team when in business, almost every type of business requires team work, almost everybody would benefit from working in a team and almost every team is made up of individual characters.

The term has been used a gentle reminder to team members that others have some value too. A reminder that a team can only perform to its peak performance when we all work together towards a common goal, optimising performance of the individual by working as a team.

I was a manager of project managers at one time and during a particularly fraught team meeting, desperately trying to get them to manage their projects in some standard sort of way, so that I could plan and prioritise the project portfolio. Back to the story, well, I was getting more than a little frustrated with the constant excuses why they couldn’t comply with my perfectly reasonable request to standardise. 

I said it, “THERE IS NO i IN TEAM”

They looked at me in horror, stopped them dead in their tracks, they were dumbstruck.

Then one of them replied:

“There’s no F in team either”

Here’s some simple tips on how to make your portfolio office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

Expose or cover up?

Should a PMO Expose or cover this up?

This is not a 100% true story about a PMO but it is factual about the sustainability of biofuels.

In my neighbourhood I walk my dog and my daughters dog whenever I can. We’re lucky enough to be just 10 minutes walk from open countryside. 

Around ten years ago the government funded a biofuel power station 25 miles away and since then the fields around my town are now covered with a biofuel which locals call elephant grass I’ve no idea what the correct biological name is. 

The fields previously grew food crops that changed each year to keep the soil fertile. Today the monoculture biofuel is grown every year and cut down with huge machinery and then transported in massive bales by the truckload on a 50 mile round trip to the power station. In addition, the soil structure seems to be degrading each year and, rather bizarrely a local farmer was prosecuted because the biofuel once cut into little pieces is considered a pollutant. 

That’s the background, now we come to the dilemma for the fictional PMO particularly now we have an emphasis on ESG (Environmental Social Governance) 

These fields have huge irrigation systems that were used when the biofuel was originally planted, but after the first year or two they are now sitting unused, rusted and degrading. The electric motors on every wheel base have no doubt copper coils that are seized never to turn again. They have large rubber tyres that are potentially polluting the ground around them. Plastic pipes for the water are broken by the summer sun and winter frost. 

These are massive, and the photos don’t really show how large they are. The one dog that you can see is about 3 feet tall to give some perspective. There’s three of these devices in the one field all sitting doing nothing anymore. 

The dilemma for the PMO is about the ethical decision to expose these dis-benefits or not?

I see the choices being:

1. Let everyone know that claiming that this biofuel is sustainable and environmentally friendly might not necessarily be true. 
2. Keep the information quiet because the long term effects are more important than the wasted energy used to build the structures, they have been funded with taxpayer subsidies and to move it requires even more. 
3. Capture lessons from this and make sure it doesn’t happen again. 
4. Measure the amount of carbon saved from fossil fuels while ignoring the fossil fuels needed to produce the structures and transport the crops that way we can contribute to net zero. 
5. This is not a PMO issue, the project has finished its now a problem for business as usual operations.  

They’re maybe some people who will dispute that this is the case because they see anything green through rose tinted spectacles so here’s another photo showing an oak tree growing to approximately 9 feet tall and they grow at a rate of between 1 and three feet a year after two years of acorns sprouting and establishing themselves. 

What do you think a PMO should do in this circumstance?

Is this one of the reasons why the latest P3G portfolio governance guidance from the TSO includes a principle to separate decision making from stakeholders? 

Finally, does biofuel contribute to net zero, if so how does it NOT emit CO2?

If you want to be greener I wrote a little help to help you be the change you want to see:

https://apps.apple.com/gb/app/ru-green/id6444596173

Here’s some simple tips on how to make your portfolio office more agile (simply)

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

User Stories in project management and more...

 User Stories

Agile teams use a concept called User Stories which is a simple concept and structure:

As a … (role)

I want … (some feature)

So that … (some value)

Here’s a reasonable example

As a project manager

I want scrum training

So that I can improve my relationship with the developers

That would NOT be considered ‘Ready’ because we have no idea what effort is required, no idea what level of training is needed, no idea about the current relationship and no idea what type of projects they manage. Once we have this information the User Story (or Backlog Item) would be ready for someone to start work.

The structure of a user story is simple enough and can help a team understand how features add value. 

As a phone user with an almost flat battery 

I want my charging lead to not work because it is not an official Apple one

So that I am unable to use it until I get home. 

As an ear bud listener 

I want to have to re-select them

So that I keep the caller waiting for a response. 

As a music listener 

I want to be deafened by the screen off button 

So that it disturbs my listening pleasure 

As a LinkedIn user

I want my posts scanned for political content

So that the fact checkers can check the checkers

Edit Jan 2023: 

As a MacBook Pro user

I want a software update that crashes the thing at least once a month if the battery get low 

so that Apple can force more updates on me

Now of course most of the above stories are not real ones, but it is an interesting way to see the value that user stories hold, and here's a little tip, if you are raising a help desk ticket or logging a complaint about anything technology related, try using the user story format, you would be surprised how the support teams will react.

As far as a PMO is concerned, the user story concept is a great way to start thinking about your projects and programmes, it gives a very clear vision from day one.

Software developers might balk at some of the user stories, complaining that they are too large, these are called EPICS, but the format is the same and epics get broken down into smaller user stories in a similar way to breaking our projects into stages and programmes into tranches.

User stories are similar to PRINCE2 product descriptions, the main difference is that a product description is usually a document formally signed off and agreed. User Stories are a starting point they do not fully define anything, they encourage, deliberately, further discussion with the customer or product owner. How is that any different from most project mandates?

Agile, scrum in particular, starts with the premise that the work has already been justified in someway. User stories include the “so that…” which implies value is being delivered and one could argue that this does, to some degree, justify the work. Also the product owner and customers have asked for these features to be developed which also justifies the development. The danger for project and programme managers is they try to put measurable benefits on every user story, this is usually not needed and the bigger picture project is where that should happen, not at the detail.

I hope you enjoyed this and gained some value from it, should I put any measurable benefit on that value? 

For more help on how to make a PMO (Simply) more agile please try this:

Agile PMO's (Simply) - Apple iBooks

https://www.amazon.co.uk/dp/B0BH5477LM

Making MOSCOW work

 

Of course this is nothing to do with the Russian city of Moscow, but images for prioritisation do not inspire much emotion, please forgive me for trying to capture attention.

MoSCoW prioritisation

This is commonly used in the agile environment, particularly during planning and during a sprint. 

Simply put:

MUST - this is something that must be done, without it we will probably fail.

SHOULD - this is something that is important and should be done, but we won’t fail without it.

COULD - this is something we could do if we have time.

WON’T - this is something we won’t be doing at all because at this time we don’t need it (out of scope in project terminology)

What could be easier than that?

The challenge comes with the definition of the word ‘should’

It means two things depending on the intonation.

We should do that, or, we SHOULD do that.

The first intonation of ’should’ would indicate it is ok not to do it, the second implies that we really really SHOULD do it.

This image of prioritising a ball point pen illustrates what we mean by SHOULD, if your project was to only deliver the ink refill (MUST) and NOT deliver the SHOULD, your project would have failed. Yes the customer could actually write something, but they would not be happy.

If you decide to use this prioritisation technique you need to make it very clear that the word should means, like in the pen example, that you SHOULD do it, otherwise the technique falls into disrepute quickly. This is because users and customers will rapidly learn that the chances of getting a should delivered are minimal and the could’s have no chance of ever being looked at, therefore they, quite reasonably, decide that everything becomes a must.

Agile improves on MoSCoW in other ways too, in particular having  fixed time and cost. In other words zero time and cost tolerance, and this doesn’t mean that you can finish early either, allowing a sprint to complete early can have a detrimental effect on MoSCoW too.

If we have flexibility for time, this means we can finish a little bit late or a little bit early. PRINCE2 calls this time tolerance.

If we have a backlog of requirements to complete with several sprints, which is the normal manner in which scrums and sprints are used, we would naturally start with the MUST have requirements in the first sprint, then finish the must haves in the second sprint but include some SHOULD haves too. 

This would normally mean we have some time at the end where we don’t have enough to complete another must have or another should have, some teams will then stop that sprint and start another one so that we can get more MUST’S and SHOULD’S done, and the COULD’s get pushed aside.

The alternative is they extend the sprint a little bit to get the next MUST or SHOULD in because they tend to be larger than the COULD’s

With that thinking, the could’s never get done, and MoSCoW falls into disrepute once again and the users are back to making everything a must have requirement.

ALSO, at the end of each sprint we want to have a sprint review and a sprint retrospective, if we allow the time to be flexible they get skipped too. 

For more help and guidance to make any project office, simply more agile:

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM

The data has a better idea? AI in project management

Is it sensible or practical to introduce AI into project management? There has been a lot written about this subject recently, some predicting the end of project management as we know it, some predicting radical changes in the project management processes we use, some even suggesting that project managers will be replaced by computer models and intelligence.

In this blog I want to consider the practicality of automating a manual process like project management.

The world has spent many years automating processes and I have been involved in many projects using software systems at the heart of the automation, some successful, some less than perfect, some a disaster.

Can we automate project management?

What sort of data would we have available for our bots to work with?

Let’s start with the lowest level of detail because that is usually reasonably accurate data relating to tasks being performed by members of the teams. This data has two main inputs, the predicted and the actual.

Can we automate or use AI on the predicted data? Usually this is based on experience and would very often have a knowledge bank somewhere, either in the form of a standard schedule of rates, or data from previous similar tasks or product development. 

Of course we all know that things can go wrong with predictions, which is why we have project managers in the first place, if everything is going to go according to plan, we don’t need a project manager it can manage itself. But the data to predict the effort, cost, timescales, scope and quality is available for AI systems to be able to access. AI systems would be able to analyse historic data and put some form of confidence factor on the plan and our schedules may well be more predictable. Probably.

Collecting the actual data? Can this be automated? This will very much depend on the type of work being done. If it is IT based it is possible to make a link between the size and headings in a document or spreadsheet and analyse the progress information, possibly. If the project is producing new software it could analyse the number of objects created, number of tests run, number of bugs or warnings the compiler flags, this could give some degree of confidence in the actual data.

We could even have some data from construction projects and more manual tasks as the deliveries get made, weight of materials used etc could be combined to provide us with reasonably accurate progress data. 

Would this machine collected data be any less accurate than data collected by team managers and reports from people? How accurate are progress reports anyway? How often do people enjoy writing a progress report? If we have a timesheet or task management system how accurate is the data?

There seems to be some value an AI system can add at this level if, and only if we have some experience with the tasks, some previous data about the tasks, some knowledge base about the disciplines in a machine readable format.

One question I would ask at this point is, would we expect the performance of the teams to improve as we complete the tasks more frequently and at what point would we say, this is as good as it gets. 

Moving up the chain a little, away from the task details, project managers issue work packages which is the PRINCE2 term for asking a team to do some work, but whatever term we use, project managers need to ask people to do some work.

Could this benefit from AI?

The project manager would have a plan relating to the dependency of work packages, the available people, internal or external, stakeholders, risk mitigation, changes from the original scope, issues that occurred since the baselined plan.

That is a lot of data, and reasonably well structured, how could AI help? Would we want the AI system to send out the work automatically? Sounds reasonable, the plan is available, the date approaches, and assuming the progress information has been updated it should be straight forward. If the resources are internal they would probably have access to the same system as us, if external there is often links into systems to trigger purchases and contracts.

Good configuration or asset management and change control is very often automated these days in the IT world, so if things have not been completed as planned or changes have been made the system should be able to detect this, analyse and evaluate the possible scenarios and using the data, send or delay the sending out of work.

Of course this is where the majority of issues occur and where we must be managing risk. In terms of managing risk, Monte Carlo analysis and probability should give us an understanding of just how risky a task is, there are many systems available to help, but is this artificial intelligence or brute force scenario based? For now let us assume that we do not care about the difference, we just want to mitigate the risk of delays, cost overruns, quality control failures, scope variability, complexity of task, the weather, sickness, computer updates (daily), internet connectivity, mistakes being made, fall outs between team members, rumours of strike action, strike action, lockdown responses to a virus, a flat tyre on a delivery van, lost car keys, trips, falls, accidents, childcare, elderly care, mental health and stress, fire, fire drills, morning after the night before, morning sickness, accidentally deleting a file, emails going into spam, confusing work instructions, misunderstandings about the work, disagreements on the work, unwillingness to do the work, BAU taking priority, customer complaints and firewalls.

That is a lot of data.

And AI likes a lot of data, but I suspect the project manager might not want the AI system to automate the sending out of work packages even if it could.

One of the other uses that AI should help with is decision making, too often decision making is done emotionally and intuitively usually based on our own professional experience with extreme personal or political bias rather than with data. 

A change towards a data and fact-driven approach will take into consideration past challenges, learnings and plain facts, is a fundamental and radical change and requires a true mindset change. 

Almost all projects require decisions to be made all the time, let’s start at the first decision in PRINCE2, which is to approve the project brief before the PM starts the detailed planning. The decision is, do we bother with this project at all? Is it worthwhile? Do we know what is required? Do we know how we are going to deliver the project? Do we know who is going to help us? Have we done this before?

Historic data, and broader knowledge could be used to help with those decisions. Plus, do we have the capacity to start planning the project, do we have a project manager with the right skillset available? How many projects can a project manager manage? Depends on the scale of the projects they are asked to manage and this could be data driven based on complexity scoring which would require a project brief, and we have one of those, prepared by a project or programme manager.

 We won’t talk about AI preparing a brief just yet.

I believe we are a long way off, and particularly as we move towards more agile approaches to project management, self-organising teams and low tech visual planning.

See my book for help in transforming a PMO into an agile world very simply.

Agile PMO's (Simply)

https://www.amazon.co.uk/dp/B0BH5477LM