In this post, I share a generic Risk Register than can be tailored for almost any Digital TV Systems Project, especially projects around Set-Top-Box product development. The register can be used by Program & Project Managers from the customer (Pay TV Operator), vendor (Middleware / EPG / Drivers / CA) or Systems Integrator. It can be tailored to meet the specifics of a project.
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
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
Whilst one might think it is common knowledge that all projects must maintain a Risks Register or have Risk Management as an active work package that is managed by a Project Manager or Risk Manager, because it is well understood in the project management industry that not managing risks is a recipe for disaster; it is nevertheless surprising how few companies or projects do this properly, especially in the field of Digital TV systems, and more especially in Set-Top-Box projects. Of course I've not done any deep research on this, but I've been in projects long enough and worked in world class companies to know that behind the scenes, it is not something that is well managed, unless specifically required by a customer. In fact, in my current company, they'd never seen a detailed risk register as mine in the history of their projects! Not only did they not maintain a risk register, they also had no concept of assigning owners to risks and agreeing on a mitigation plan that must be actively tracked to manage the risks.
Digital TV Systems Projects can be complex, they come in a many shapes and sizes, but they generally follow the same pattern: There will be a STB element where some development & integration is required, Headend, possible new STB Hardware. It will involve vendors such as EPG UI Application vendor, Middleware Vendor, STB Manufacturer, Chipset Vendor, Systems Integrator, Customer (PayTV Operator). The project will consist of multiple work-streams to manage, these work-streams come together in delivering the entire programme.
At the macro level, the outlook of the programme must be assessed through managing the core macro risks. Each work-stream owner or project manager however, is expected to maintain and manage independent risks specific to that work-stream. For example, the Middleware PM should maintain a separate risks register to manage risks specific to the Middleware vendor, escalating anything upwards to the customer, should some risks manifest themselves at the macro level, impacting the overall programme delivery. It is impossible to manage every risk in detail, and therefore it is expected that every individual Project Manager maintain his/her own risk register.
The risk register at the programme level concentrates on the bigger picture: what can go wrong with the work-streams that will negatively impact the programme? What actions can be taken to prevent the risks from materialising? Who do we assign as owners to manage these risks? How do we regularly monitor and control the outcome of these risks?
If this is done at the macro, programme level - there is an expectation that vendors internally are maintaining the same rigour in monitoring & controlling, i.e. managing their individual risks. It is sometimes necessary to request your vendors to share their risks register, or send regular status reports on open risks.
Risk Registers should not be hidden, they must be communicated to the entire team. It does not make sense to reserve risk management to an elite few. This was the case in a past project where the stakeholders would meet at least twice a month to discuss risks & communicate status to the customer. Not once did the rest of the project team have visibility of the risk register, neither could we influence it. Managing risks effectively requires clear communications at all levels. The project must create an environment where people can feel comfortable sharing issues or concerns that could impact the project. Leaving risk management to an elite few prevents collaboration and fosters secrecy, which is wrong. We need full participation from all project team members.
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.
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.
Uncertainty Diagrams
Uncertainty diagrams are a powerful tool to communicate possibilities of project outcomes. Risk is all about uncertainty. It is very difficult to predict when a project will complete, because we know that no two projects are alike, but we can come pretty close to predicting a realistic outcome based on probability, that takes into account history from past projects, and overall gut instincts.
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...
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"...
Not I.
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 |
The first thing to note is that I have deviated from the standard formula of:
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.
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.
Download the tool: Free Risk Register Template
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.
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.
I am not saying I'm an expert at Risk Management, since it is not my core function or primary responsibility. What I am saying is that Risk Management is an often overlooked area in Digital TV projects, although this strongly depends on the project manager in charge. It is difficult to implement in practice, but is something that is quite important and must be done. I have attempted to share what works for me, from my own toolbox in the hope that it will help fellow professionals. I think starting with fifty risks is a good kick-starter for the project manager who's never done this before.
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!
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!
No comments:
Post a Comment