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.

Advertisements
Categories: Work Tags:

Risk Log – time consuming red tape?

September 26, 2017 Leave a 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.

Reference
(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: ,

A few observations on PRINCE2

December 30, 2013 Comments off

I recently attended a PRINCE2 Foundation and Practitioner course, and have offered some thoughts on my experience of it. Here are a few thoughts on PRINCE2 itself that struck me while I was thinking about my role as a Project Manager, in no particular order:

Not as inflexible as I thought. PRINCE2 has a reputation for rigid adherence to process and for generating lots of documents. Maybe that reputation was earned by earlier flavours of PRINCE2, for the current version allows flexibility and the manual has a section on tailoring. Where I thought my recent practices might not follow the PRINCE2 standard, I discussed them with the instructor who nearly always took the view that it was an acceptable use of tailoring.

Continuous Business Justification. My business users have been consistently poor at this through my career to date. As a rule they produce an initial Business Case produced to obtain funding but rarely revisit it between stages or when there is a significant change, unless more funding is required. They have been especially weak when dealing with change within a stage; some strange decisions are taken about functional changes when a quick benefits analysis would show that money could be better spent elsewhere.

Risks include Opportunities. The Risk Theme also includes the concept of Opportunity, defined as an uncertain event that could have a favourable impact on objectives. I can’t recall ever considering this aspect formally in a project, either as a supplier or on behalf of the client.

Lessons aren’t Learned. Like most people I have dutifully recorded lessons at the end of projects (and also as we go along) but what happens afterwards? In PRINCE2 the start of a project should include consideration of relevant Lessons Learned from previous projects. I haven’t seen this take place other than anecdotally based on the experience of the individuals involved. I’m sure I wouldn’t know how to go about finding applicable lessons within my own organisation, and I haven’t seen any evidence of it within the client organisations I have known well over the years. The other area where we could also do better is to review our own project performance more often, at the completion of key stages. Again, this is something that happens erratically, usually because we’re too busy to do it at the time.

Manage by Exception. A key principle of PRINCE2, to ensure management focus is where it needs to be. A tolerance (in time, money or both) is set for each work package, and as soon as it looks as if it might be exceeded the team leader responsible should raise it as an exception to his manager. This may not affect the overall project tolerance, in which case the manager need not take it further. Although my internal management tends to work on this basis, I can’t say that my client managers have adopted this principle very often, too much man-marking goes on….

One quibble. We don’t usually have a Quality Register (rightly?) As defined in PRINCE2 the Quality Register lists all checks that are planned, and as they take place is updated with the date and outcome of each quality check. Almost all the projects I have worked on over the years have carried out the checks themselves – which are planned properly (scheduled in the Project Plan and described in the Quality Plan), and results are duly recorded – but I don’t recall working on a project that had a central Quality Register. Dare I say it, but I think this is appropriate as I see a register adding little value but a lot of effort to maintain it. When I brought this up on the course it generated quite a bit of discussion. We thought there was probably a benefit in safety-critical projects (aviation, defence) but for normal work having an entry in the plan was sufficient.

A PM wears more than one hat. Is a supplier PM a PRINCE2 Project Manager, or a Team Manager? Of course, the answer is “it depends, …” Often, we might fill both roles simultaneously – as well as being a PM from a supplier perspective we are also the Team Manager from the Client’s perspective at the same time. This significantly alters the view we might take of what is required of us.

Overall, PRINCE2 provides a framework to use to save re-inventing the wheel; as a proven and widely recognised standard it can easily be sold to an organisation. As an experienced PM, I was pleased to find little that was new or that I don’t already do. My experience of the clients I have worked for over the years is that they are less methodical – perhaps that’s why they rely on external consultants so often.

Categories: Work Tags: ,

Course review – PRINCE2 Foundation and Practitioner (QA)

November 28, 2013 2 comments

I recently attended this week-long course run by QA. If you are thinking of attending it or a course like it, I hope that by sharing a few thoughts it may help you decide whether to attend it too. My view of the course is coloured by being an experienced Project Manager, so some of what I say may be less relevant if you are looking to move up into Project Management.

Why go?

My motivation for taking the course was simply to get a “tick in the box”. Many organisations expect it and I wanted to obtain the formal qualification as quickly and painlessly as possible. I had some prior experience of working on projects that were operating within a PRINCE2 framework (on an older version), but I knew I had gaps in my knowledge of the formal process and terminology.

The provider was determined by my employer – however I know that other training companies also offer similar courses and I expect they are not very different.

Course format and content

The course is very focussed on passing the exams, not learning PRINCE2, and should be judged accordingly! It assumes both some Project Management experience and that you have read the pre-learning material. It is split into two parts, covering each accreditation level, which can be taken independently of each other, although in fact all course delegates on my particular course stayed for the full week (as is usual). The first two days cover the Foundation level and the remaining three the Practitioner level, each ending with the official exam.

The format of each part of the week followed the same pattern. We were taken through each of the Themes and Processes in turn to the level of detail necessary to pass the exam, and then tried out a set of practice questions. The Foundation exam focusses more on the Themes, whereas the Practitioner exam looks at both Themes and Processes at the same level of detail. The good news is that the Practitioner exam is “open book”, which means that although there is more ground to cover, you only have to remember where to look for the detail in the official manual. The bad news is that each night (apart from after the Foundation exam on the Tuesday) there is homework to do, in the form of a second set of practice questions reinforcing the material covered during the day.

The middle of the week provided a welcome break when we all shared our own experiences of project management: where we felt our existing practice fell short of the PRINCE2 principles, or where adopting its practices might help us in future. We had some lively discussions.

My one real criticism of the course is that I didn’t like the format of the pre-learning. It was on-line only, so I couldn’t do it on the train, and annoyingly I had to wait for the voice to read out the words on the slides before being able to move on, which is one of my pet hates. I read a book (PRINCE2 Study Guide, by David Hinde) instead, which I had already bought before the official pre-reading came through, and which suited my learning style better – I recommend this book for anyone looking to study by themselves.

So, was it worth going?

If you want to gain the PRINCE2 as quickly as possible then – Yes. It would help if you have prior project management experience, but it isn’t essential.

If you are a relatively inexperienced Project Manager and are looking to study PRINCE2 from scratch as a way to learn project management, this is probably not the best way to do it.

With the benefit of hindsight I could probably have got away with just taking the exams after reading up, but actually I found the course useful as a refresher on good practice in general. The course’s cramming style suited me personally; it would have taken me a lot longer to cover the same ground in my spare time or one evening a week and I would have been more likely to forget some of the content by the time of the exam. I was very tired by the end of the week though!

Categories: Work Tags: , ,