Risk Log – what should be in it?

February 27, 2018 Leave a comment

There are many different Risk Log templates available, some more complex or simple than others. But what do we really need to record?

Often we don’t have much choice about what we record in our Risk Log, because we have to use a corporate template, which might be more or less fit for purpose. Some are much heavy-weight than others. For example, I just counted the number of columns in the Risk Log template where I am working currently and there are 35!

That is too many for me, I am much more of a minimalist. (Can one be more of a minimalist)? One of my pet hates is having to keep scrolling backwards and forwards across a record because there are too many columns – and in my experience, most of the time, most columns are empty but the useful ones are placed apart from each other.

I want the log to be useful to me as a PM – I am the one who should use it the most. So, we need a simple Excel spreadsheet with the following:

ID – We need a unique reference. Start at 1 and keep going.

Status – We only need three values – Open, Closed, Realised. Realised means a Risk has happened and has become an Issue. Closed means a Risk has passed without occurring.

Risk Description – This is the Event, Reason, Outcome descriptive text discussed in the previous post.

Probability – How likely is the Risk? No more sophisticated granularity than High-Medium-Low is needed, using a coloured RAG status visually so we can quickly find the Reds. Some places prefer a percentage. This suggests a level of precision that doesn’t exist but we need it if we want to work out a cost. I suggest using something like 50-25-10 for HML if we have to give a number; too often in the past I have wasted time discussing whether a Risk Probability should be 20% or 30%. Sometimes more granularity is needed to work out a contingency cost for a budget, otherwise it’s not worth worrying about it.

Impact – Again, use a RAG status for High-Medium-Low. Some places prefer to split impact on Cost and Time as they can vary – but we can just write that in the description. We only need the RAG status to help us quickly locate our main risks; showing Cost/Time separately makes them harder to spot. Just take an average view of both combined (they are often similar anyway).

In practice, I have found I use the RAG status to filter the key risks e.g. for management reviews. Simpler is better here – all we want is a way to identify the most critical Risks, as PMs we probably know what they are anyway, and they ought to be the Red ones!

Action Plan – sometimes there are separate fields for mitigation and response, but I don’t see the need. Often there is more than one mitigation or response depending on the circumstances, so I don’t see the problem with recording both together in a single box.

Comments – this is the one I find most useful (and is sometimes not even present) – just make a note every time we do something. Always start a comment with a date (and initials if more than one person ever updates the log). Sometimes a busy Risk might get quite deep but I find having all comments in one place more than makes up for it.

I might also have columns for some or all of date opened, last updated and date closed but only if I’m going to want to sort by date. Otherwise we might just as well use the comments field in the same way to record opening and closing

So – I have just seven columns. This means my log fits nicely within a single screen/page so I can see everything at once. And it can easily be printed out.

Categories: Work Tags: ,

Recording Risk

February 1, 2018 Leave a comment

I have already written about the importance of a Risk Log, so now we have one, what should we record?

Often we write them down in shorthand. To quote a couple of examples I have come across recently in actual logs:

“Lack of wider business engagement”
“Staff retention proves difficult”

It is certainly more important to record the Risk first before it is forgotten and refine the wording later (as part of the weekly review I mentioned previously). A well-phrased risk statement should allow somebody with minimal knowledge of the project situation to be able to understand exactly what might happen and why. If you are like me and can barely remember what happened last week, let alone six months ago, you will then easily recall the risk detail and what to do about it several months later when it actually happens.

Some places I have worked have adopted a very strict policy, sometime enforced by templates. A common template wording is “There is a risk that (event happens…) because (cause…) with the result that (outcome…)”.

Let’s look at these three points in turn:

Event – what could happen. Sometimes it can be difficult to separate the event from the outcome – we might be late because something takes longer than planned. Often in software it comes down to “we underestimated”, all other causes of risk are much less common (but it’s not usually acceptable to say so).

Cause – why the event has happened. It is important because we can identify mitigating actions that we may be able adopt to make the event less likely. It may also be that our assessment of likelihood varies for different causes. So let’s think about at another recent example I came across which had no cause given:
“There is a risk that the Client review of the Requirements documentation highlights major concerns and results in significant additional effort to address issues” (no cause given)

It may be that we have missed out something fundamental. Is the cause lack of agreement (or understanding) of project scope? Is it that the expectations of the format or structure of the document are misaligned? Or is it simply that the requirements team are not skilled enough and have done a sub-standard job? Even though all causes have the same result (more effort and time), we may want to assess and record different mitigating actions.

Outcome – the consequences of the event. In the example above, irrespective of cause there might be a delay while we deal with some issues, and I might want to add some contingency time in the plan. Experience suggest that there will always be at least a small number of review comments that need to be addressed so it is sensible to plan some time to address comments. So here we should consider if we need to factor in any additional time over and above our planned contingency. Some outcomes might be more serious than others, e.g. if we have misunderstood scope, we may have to go right back to the beginning, whereas if the document has been written by an inexperienced team member, maybe a few days effort from somebody more experienced and another review cycle will be enough to recover the situation.

Personally, I wouldn’t get too hung up about the exact wording, as following a rigid format can sometimes get convoluted. (Worst of all is when the log has a separate column to enforce an entry for each part which then means that three lots of cutting and pasting is needed every time you want to transfer a Risk to a status report). It’s better to be concise rather than always following a precise formula, but I would want to make sure it answers all three aspects (event, cause, outcome) and is expressed in language that can be understood by somebody without any detailed knowledge of the project.

See Also:
Quick summary from Better Projects

Categories: Work Tags:

Risk Granularity

December 30, 2017 Leave a comment

I have recently started a new project in its early stages so have been thinking how best to set it up for success. One question that I as Project Manager have had to address is the approach to be taken to the level of granularity of Risk to be recorded. Do we take a very detailed description of each specific risk, carefully costed and regularly updated, or a very high level approach, with very few risks with a crude finger in the air estimate of impact? I have worked in places that have adopted both extremes as well as somewhere in between.

The culture of the organisation is important; my experience of engineering companies is they are much more risk averse and expect a much tighter level of detail than many others. The stage of the project is relevant – during the early stages much detail is unknown so most Risks will reflect this by being at a very high level.

In commercial projects most Risks can be often summarised as “we underestimated” and the main purpose of the Risk Log (especially early in the project when all estimates are suspect) is to justify a price with additional contingency. We might simply add a percentage figure to certain cost elements to allow for our own uncertainty, unless there are some obvious specific big ticket items straight away.

At one extreme, I have worked on programmes and projects where the Risk Log was extensive, containing lots of carefully delineated and costed risks, which inevitably took a lot of time and effort in curation. Why would you want to do this? One reason on a larger project is that even small bits of Risk can add up to quite significant amounts of money. Depending on the way Risk is managed. It may also be that as a PM you are automatically authorised to spend a stated amount of money to mitigate the Risk, in which case it needs to be clearly defined so there is no argument when it happens.

On the other hand, there is a great temptation to turn Risk Management into a cottage industry, especially on larger programmes where there is a Programme Management Office with sufficient resource to manage a heavy-weight process. (I have also noticed that the programmes I’ve worked on that have had a very rigorous process tend to be failing projects… or maybe that’s just me being cynical).

At the other extreme, I have worked elsewhere where the expectation was that there would be no more than about five Risks adding up to about 10% of the total contract value, which between them would be general enough to cover most eventualities. Typical examples would be – unable to recruit a team at the expected cost, activities take longer than planned, or a key team member resigns incurring cost to recruit and train a replacement. In general on projects like this the Project Manager is expected to hit the budget and manage the deliverables vigorously, and the contingency is there to give enough wriggle room to make sure. In these projects, provided we are on time/budget, I have rarely been under pressure to pay much attention to the Risk Register, and when we have stepped out of the good zone it has usually been down to a specific Risk materialising which we had to deal with, and move on.

So, if not forced to follow an approach by existing practice to follow, what is the right amount to record? My view is to treat the Risk Log as a worry list (and follow Seth Godin’s advice not to worry too much), particularly those of the higher impact ones that are most likely to happen in the next few months and that you are actually in a position to influence. You should briefly note other lesser impact or more distant risks when you think of them in case things change, but don’t spend too much time on them. Focus on the key risks use the log a reminder of when things might happen, what you intend to do about it, note when you highlight them in reports, and keep enough detail to demonstrate your thinking without being a burden. By focusing on the key risks in sufficient detail you will find the log is a helpful tool.

Categories: Work Tags:

Risk Log – time consuming red tape?

September 26, 2017 1 comment

Despite being an experienced Project Manager I sometimes feel I could do better at formal Risk Management and on reflection I’m probably not alone.

My experience of Risk Management in practice is that from time to time I work on a project where suddenly it comes under a lot of scrutiny, everyone looks very closely at Risks for a while, then interest wanes and it is forgotten again. When this happens it is easy to view maintaining the Risk Log as a bureaucratic overhead.

Formal project management literature advises that if we are carrying out Risk Management seriously we should maintain a detailed Risk Log (or Register), which should record all the potential risks that might affect our project, and what we propose to do if they occur. We should review them regularly and update them as things change. I have spent most of my career working for large consultancies or other large organisations, all of whom mandate a formal process and provide extensive guidance including an all-encompassing Risk Log, which our Project Management Plan duly confirms we maintain on a regular basis.

In practice most projects I have worked on have been far less diligent. I have rarely inherited a project in mid-flight with a comprehensive and up-to-date Risk Log. The exceptions were either large programmes where there was a PMO team with somebody dedicated to maintaining Risks and Issues, or where project status was so Red that a full Risk Review exercise was needed. Otherwise, the mere existence of a log with some entries in it has been deemed as compliant, but of course having a log does not equate to managing risks.

In practice like many PMs I am continually calibrating the more likely risks in my head on a constant basis. Much of the time we don’t look at the log; we keep track of (most) risks that are likely to occur within the current planning horizon and deal with them as needed. Sometimes weekly reports highlight some of them. But what about further ahead? Keeping a log does provide some immediate benefits to a PM.

Firstly, it provides a list of all the things you should be worrying about in a single place. Get into the habit of reviewing Risks regularly. Mike Clayton’s advice (1) is to review Risks every day (where does he find the time?) – I found a weekly slot worked better for me. I set aside time in my calendar to review the entire log prior to the weekly reporting cycle. A formal weekly review takes no more time than trying to report on Risks haphazardly. I also include Risks as an Agenda item on my weekly team meeting, which is usually on a different day of the week. (The Agile daily standup question “what is preventing me from getting my job done” will also identify some risks although it tends to have a shorter term focus). This can be combined with reviewing Issues at the same time as there is overlap between the two.

Secondly, the log provides a useful record of actions/decisions taken to manage Risks, particularly the small number that require disproportionate management time. My weekly review helped me to update them while my memory was still fresh. This saved my neck a couple of times when a Risk became an Issue, somebody senior asked “why wasn’t I told about this sooner?” and I was very easily able to quote instances of escalating it at meetings or via email.

The other thing that having a Risk Log gives is an ID to use as an easy reference for filing emails etc. so I can easily find all related correspondence. If using Sharepoint or a similar filing system allowing Metadata, Risk ID can be used as a keyword for searching. When the project filing system is rather less sophisticated, I create a subfolder in the same location as the Risk Log to store supporting documents, appending the Risk ID as the first part of the file name e.g. ‘R-012_Escalation.msg’. It has saved a lot of time – by being very easy to put my hands on the key email to answer those ‘who did you tell and when?’ questions.

There is a difference between mechanically recording details in a Risk Log because our PMP says so, and making it work for us, but very little difference in effort needed to use it one way compared to the other.

(1) Mike Clayton, Risk Happens, Marshall Cavendish, 2011

Categories: Work Tags:

Changing jobs after a long time at one place

August 26, 2017 Leave a comment

Last year I changed jobs after about 15 years working for the same company. Starting somewhere new was more of a challenge than I expected.

At beginning of your career, it is common to hop from one role to the next every couple of years, and never really get immersed in one place for too long. (This was certainly my experience – I worked for five organisations in my first 12 years). In those roles, being relatively junior, you have a clear and focussed job to do based on your skill set. After a week or two of induction and finding bearings you can get straight on with your job and quickly find your stride.

Eventually you reach a point in life and career where a bit more stability is needed. By this time your career may also be reaching the point where advancement becomes more difficult, and you need meaty experience, which takes longer to attain. It also often coincides with greater demands from your private life – maybe by now with mortgage and family, security of employment becomes more important, or the convenience of being able to get home on time.
If I’m honest I was in one place for too long, although I had good reasons for staying as long as I did. I was ready to leave when suddenly the recession arrived in 2008 and good jobs dried up. As the market was starting to pick up again I had some clear internal career progression opportunities so I stayed put, and didn’t resume looking until my CV was bolstered a few years later.

I had forgotten how hard it is to start again, even as an experienced hire. Coping with a dramatic change in culture is expected and welcome – the challenge comes from no longer knowing how all the simple day-to-day stuff is done. Not “how” exactly, as the principles of project management remain constant, but the detail of the processes is different. The little nuances of the way things are written, or expectations around how ideas are socialised. Where to go to find out, who to ask.

At a personal level too, it is more of a challenge than I thought. There is a need to prove myself again, which creates its own pressures, sometimes self-imposed, after many years of having established a reputation. At my age I don’t want to run the risk of being let go too soon after starting; even after passing the six months’ probation stage I still felt anxious that I wasn’t yet doing myself justice. Last time I felt had to perform in this way I was still relatively early in my career and I was used to being in this position as a matter of course.

There are many positives too. I am able to bring in my experience of doing things a different way in my previous organisation or for my previous clients. It is refreshing to see where my new employer does things better. I have found myself assuring my more cynical colleagues that actually, things aren’t so bad here.

Above all though, I am glad I moved from a career perspective irrespective of the respective merits or otherwise of my former and new employer. From a personal standpoint it is very easy to become jaded and lose that little bit of spark at work when you have worked for the same company for a long time. I needed the refreshment provided by a new set of challenges. I recovered my enthusiasm for work, even maintaining it through quite a difficult first assignment. As the old saying says, “a change is as good as a rest”.

Categories: Personal, Work Tags:

Radio silence

August 25, 2017 Leave a comment

In the last three years a combination of family troubles (now all settled), difficult projects and a concerted and successful effort to change employer took up all my energy and spare time; a few posts were half-drafted and never completed.

I wonder how much benefit my thoughts and experience bring to other people (I hope so – a couple of the Use Case posts generate some traffic) – but I find that attempting to commit some thoughts to (e-)paper is personally beneficial as it makes me think in a more structured way about some of the things I am doing. I have no idea how some people find the time to post daily, about once a month is enough for me!

So here goes again…

Categories: Personal

Iterative planning

April 22, 2014 Leave a comment

I previously wrote about how we combined elements of both Agile and Waterfall practices on a project to allow us to develop in an iterative way whilst remaining within the confines of our client’s Waterfall methodology.  In this post I want to look a bit more at how our iterative development approach was organised.

We planned the development into 3-week cycles.  Two weeks would have been too short to get some of the meatier components completed in a single iteration, and we would have had to break them up artificially.  Four weeks was too long and wouldn’t have given us enough flexibility.  We reviewed it as we went along and we always felt it was the right length.  On the other hand a 2- or 4-week cycle would have fitted better with the natural business cycle – which suited a regular drop in middle of the 4-week financial period.  The 3-week cycle worked well until we reached the go-live date when we needed to release code every 4 weeks and other issues briefly caused us to suspend our regular cycle (by then we had completed the core development anyway).  Three weeks would have worked well with a quarterly delivery cycle once things had settled down again into a regular pattern.

We adopted the agile principle of delivering a build on the deadline, and adjusting the scope to ensure it happened.  Within this, we to ensure that any build we provided was coherent and could process data from end-to-end, even if we couldn’t cover certain cases.  This meant that once we had covered off the minimum requirements, we were always able to deliver into production.

To ensure, outwardly at least, we appeared to be following a waterfall process, the development cycle included all technical specification updates alongside code changes, and all affected unit tests passed (we automated unit tests for new functionality but inherited manual testing for legacy code).

Business Analysts and Designers ran ahead of the development team so that there was a backlog scoped/designed to a sufficient level of detail, on a “just in time” basis so we didn’t waste too much time on low level detail until it looked like it might be in the next iteration or two.  They worked with the development team at the beginning of the cycle to make sure all requirements were fully defined.

The system test team also ran on the same 3-week cycle but two weeks in arrears, giving them up to two weeks to test the last build and then at least a week to prepare/update tests for the next release before it was delivered to them.  As we neared the intended release date we focussed on ensuring that code delivered to production was coherent.

The way each iteration cascaded into the next is more easily shown in a gantt chart:

iterative gantt

System testing prioritised the most important functionality first. This meant that critical bug fixes identified in the initial round of system testing could be fitted in to the next iteration, because at that stage it was being worked on by the developers.  Non-critical bugs identified in testing would be added to the work queue and fixed in the next iteration if possible

Priorities for each iteration were set and revised jointly with the client, especially as the deadline drew nearer.  At each project meeting progress was discussed and changes to priorities noted so the team always had a clear view of what was likely to come next.

Ultimately this worked well; despite constantly shifting sands we completed our initial baseline on time and went live with a system containing all essential code from Day 1.

Categories: Work Tags: ,