You are free to download this tool, use it as a template for your own projects, as long as you retain some attribution to me as the original author. All my work on this site is licenced according to Creative Commons Share-Alike attribution.
Over the past decade of working with Digital TV projects, especially around Set-Top-Box projects, I've come to experience common themes that repeat themselves one project-after-another-after-another. Whilst it is true that no two projects are the same, I do believe that projects will ultimately be exposed to similar risks, issues & opportunities - besides, we can no longer say that Digital TV is a new and emerging field. We've been making Set-Top-Box (STB) hardware & developing STB software for just over two decades now, and as with all manufacturing & development processes, we have probably reached a point where some standard blueprints can be put together, forming templates that can be used to guide such projects going forward.
So it is the aim with this post, to share a Generic Risks Register, that is borne out of my own personal experiences - that I myself use as a template for managing Risk on every new project I embark on.
Until this year, most of the stuff has been in my head, I've taken time and energy in the last four months to create a detailed register of the Top 50 Risks a Programme, Project or Risk Manager can use immediately as part of implementing Risk Management in his/her projects.
Over the years, I have come to use a few sources of reference to better understand the subject of Project Risk Management: these are shared on the left-hand margin, with links to Amazon where you can find out more. I own & have read all these books. I use them as a constant source of reference and re-alignment, not only to refresh my memory, but as an enabler to inject some new ideas into my day-to-day management of projects. The tool I've created is built on information pulled out from these various reference works.
Risk Management in DTV Projects - My take
The Risk Register is basically a tool. It doesn't mean that creating a fancy register is a sign of managing risks effectively. Often is the case that registers are created upfront at the beginning of the project during "Initiation & Planning Phase" and thereafter forgotten about. Projects must adopt active risk management, where it becomes highly visible the team are concerned about risks, and are doing everything in their power to deal with them. This might involve setting up weekly Risk Tracking sessions, regular communications of the register and assigning a custodian who's primary focus is to manage, track & close down project risks.
If the risks are well managed & well understood, then presenting an uncertainty diagram can hold a lot of weight in communicating to stakeholders. I have yet to use uncertainty diagrams externally, that is, I maintain these visualisations for my own internal purposes, but I've never shared this with the stakeholders, although I think I should introduce this to them gently soon...
In January a couple of years ago, I had assumed the position of Overall Programme Manager for a project that had actually kicked off three years prior to me getting on the project. This particular project had been slipping for some time and was suffering from the usual scope creep and never-ending change requests from senior stakeholders.
The project kept stumbling, until at such point in November, the previous year, the stakeholders had a rethink and decided to refocus the project, this changing the scope yet again. Suffice to say, the project involved new technology end-to-end, across pretty much the entire value chain, and the expectation from senior stakeholders was to deliver this complex project in under twelve (12) months, for November the same year! Since I had only just been in the company for a short period where I still not proven myself nor gained the respect from fellow colleagues, I really had to restrain myself quite a bit, resisting the urge to openly challenge the leader (CTO) explaining in so many ways why and how that expectation was seriously flawed...
I was close to challenging the senior stakeholder (CTO) in front of the entire department, that everyone was living in dreamland. Never in my career had I seen a complicated DTV system come together in under twelve months, especially when the components are new, never been done before and the teams fairly immature...I did however rise to the challenge and set about planning a strategy where we could have some chance of aiming for this delivery, if all went well.
The next day I shared with the management team the required strategy to deliver this project. They were blown away, never had they seen such a detailed plan put together overnight. Of course, the resultant plan was an extremely high risk plan that I didn't feel at all comfortable having my name published on, so I made it very clear in my communications that to deliver on such a wildly optimistic & highly risky plan that all the planets must align beautifully together, that no risks materialise and that The Power-That-Be is on our side, and if only cows could fly over the moon...
Later that quarter, on a conference call with the company's group-wide CEOs, I was unexpectedly put on the spot to give my opinion about the realities of achieving the plan. Tongue-in-cheek, biting my lip, having sought the confirmatory nod from the CTO's 2IC, I thus shared my honest opinion.
At the time, I said: November was absolutely unrealistic, at best we might be lucky to have an engineering system ready. March the following year, is most likely for an engineering field trial, with a 50-60% probability of launching in July, but most likely it would be November with an 80% probability.
So I basically said the project actually needed two years and not one. This is what happens when CFOs and a less informed, less experienced management team, cobble up a straw-man plan together (in 1.5 days) when they have no clue or basis from previous experiences to build confidence that such a plan can actually be achieved!! I was not consulted to provide any input into the plan presented to the business decision-makers, and was asked to set about delivering a plan for an apparently hard deadline, that was absolutely undeniably ludicrous...just like in DeMarco's The Deadline...
The CTO flipped his lid as he was not physically present in the meeting room but instead was dialled in on a very bad line, was furious I shared my opinion that was not backed up by any scientific evidence, and only based on my own gut feel. It was the first time in the history of the company for a project manager to stand up and express concerns about a plan not being achievable.
Never before had anyone the guts to do so, the status quo had always been "Manage as best as you can, communicate clearly and when the project slips as it surely will, you know you've got your ass covered"...
Why should I put undue pressure and urgency into a plan that I know on day one is not achievable? If I were asked to do it again & resist the status quo, I will do it again & again without any hesitation (I don't care if it's a career-limiting move, I have my own principles I live & work by)...Anyway, I was told to write an email to everyone on the call that I was put on-the-spot and made to give an opinion that wasn't based on any factual evidence, and just my gut-feel...
The email thread basically went something like this:
<< Senior Stakeholder, Group CEO>> Please confirm dates in your minutes are correct: 50% confidence in next June, definite achievable date next NovemberAt some point though, a project manager must stand his ground, as I stood firmly on mine, used the risks as a means of backing my prediction and got the plan to change to a more realistic one. Moreover, despite me being the youngest of all senior managers on the team, I was the only one with enough experience & exposure in working first-hand with projects of that nature. But it was still a very tense situation, and even today, I am still not sure whether this CTO fully appreciates my insights... Nevertheless I had done my job, and got us some breathing room, which was appreciated by the downstream teams, although no one really came by and thanked me. In terms of uncertainty diagram, this is how I viewed the project at the outset (suffice to say, it ended up going the way as I predicted):
<< Other Group CEO's reply>> He just took minutes from the call, best that khanmjk confirms
<< My response>> Hi, confirming that I was asked on the spot to provide outcomes for the project. This was based purely on my own experience from past projects of a similar nature, it is still my own opinion that November is unachievable and will at best give us an engineering system for internal testing. Using your own past internal projects as references, I would say that from the point of reaching the milestone of functionally complete Engineering system to a Launch Candidate, I would expect as an absolute minimum, a six (6) month testing/stabilisation period, taking us to May/June with a candidate close to launch readiness...
|My Uncertainty Diagram (a.k.a. Risk Diagram)|
Overview of My Generic Risk Register
I won't go into the theory behind creating risk register and the various methods of risk discovery or visualisation, if you interested in this you can read my PMP Exam Notes on Risk Management, or you can purchase a copy of the PMBOK guide shown in the sidebar.
The first picture below is a snapshot from the tool's help notes section that describes the fundamental inputs required. The second picture is a snapshot from the actual register, focusing on the core elements. The register matrix is quite deep, so there are some columns hidden in the spreadsheet for ease of viewing.
The spreadsheet is best viewed on a Mac, I've not had time to make it look pretty for Windows PCs.
|Help Notes from My Risk Register Tool|
|Snapshot from Risk Register - Details of Risk Log|
Risk Rating = Probability X Impact
I have tailored this to include a cost factor, where my formula becomes:
Risk Rating = Probability X Impact X Cost (where cost is optional, can be set to 1)
I agree that Cost is implied overall in the variable Impact. That Impact can be quantified across many variables, of which cost is an obvious factor. Without going into too much detail, it is just my preference to include Cost as an explicit variable because it drives home the severity of the Impact. This is especially true on the part of PayTV Operators, where cost is a deciding factor. It is not meant to embody just monetary costs, I use Cost to imply social, ethical, responsibility & reputation factors. This in itself means that we can further quantify the Cost variable and break it into its own constituent parts.
If only DTV Project Stakeholders have that long-an-attention-span and are interested in the detail behind quantifying everything!! For practical reasons, projects often overload an existing project/programme manager to own risk management (a.k.a. Risk Manager). This risk manager, apart from managing his/her project work packages must also now manage the risk register. Time being a limiting factor, one usually settles for a basic matrix that's not too complicated. I was told even that my register is too complex. Imagine if I applied Tom Gilb's Impact Estimation table to quantify each risk in detail, according to value by stakeholder, impact on business and quantifying all associated factors?? Or imagine if for each risk, we associate Tom Demarco's Uncertainty Probability diagrams?? Or use Agena's Bayesian Simulation for visualising risk profiles?? If you are using any of these tools in your own projects, please get in touch with me.
In my Risk Register Template, I've provided the Top 50 risks I think are a good starting point to get you off the ground. For each risk, I describe my rationale behind highlighting the risk, which is based on solid past experience from real-world, multi-billion dollar revenue generating projects. For each item, I also highlight the potential consequences of the impact should the risk materialise, and also provide some standard steps a Risk Manager can choose to help mitigate and control the risk. For each risk, we assign a specific owner, in addition to the Risk Manager overseeing the overall risks. The purpose of the Risk Owner is to do everything it takes to control the risk. The table is sorted by Rank Order, which is basically using Excel's Rank function, arranging the items in ascending order of priority.
If you find this tool useful, or would like to share your own experiences, or wish to enhance the template, please do get in touch!