OSS Risk Register

If you are not willing to risk the unusual, you will have to settle for the ordinary.” Jim Rohn The attached template provides a risk matrix that includes many common risks encountered across OSS projects in many different countries. It defines many common tentacles, but can only be a starting point for identifying risks on your OctopOSS. The template is built around the concepts defined in Australian/New Zealand Standard AS/NZS 4360:2004. OSS Risk Register (Sample) Template As you’ll notice, risks 001 to 009 of many are shown in the attachment. If you’d like a more complete template or assistance in customising your own template, please contact us here. If you find this template helpful, I’d love to hear about your story, your project and any other enhancements that you’ve made to the template. Undertaking OSS Risk Analysis There are a vast number of potential risks that will be present in any given OSS implementation, so a risk analysis will need to be undertaken for each specific project. The identification and mitigation of risk is one of the many tools in a Project Manager’s arsenal. This document will not seek to replicate the wealth of knowledge available for managing risk. However, this section will identify a set of risks that consistently appear in most OSS projects as well as presenting a standards-based framework for categorising risks. Major Risk Categories The major categories of risk that appear on almost all OSS projects are:
  • Organisational change management – the OctopOSS will touch almost all parts of a business and a large number of people within the organisation. If all parts of the business is not conditioned to the change then the implementation will not be successful even if the technical deliverables are faultless
  • Data integrity – the OctopOSS is only as good as good as the data that is being fed to it. If the quality of data in the OSS database is poor then operational staff will quickly lose faith in the tools. There are many types of risk that relate back to getting quality data into the production database and building checks and balances that ensure the data quality remains high
  • Application functionality mapping to real business needs – the scope of functionality and configurability of OSS tools can lead to implementers getting carried away with delivering “wish-list” functionality that adds no tangible business benefit or requires significant effort for negligible gain. Alternatively, OSS tools are designed to suit multiple customers and aren’t always fully bespoke to suit a single customer’s needs. Customisation generally leads to significant escalation in costs
  • Northbound Interfaces – being able to map your data sources to your OSS
  • Implementation – there are so many sources of risk within this category, as is to be expected on any large, complex project
Toyota Five-Whys Analysis When conducting a Five Whys analysis recently, it was apparent that many of above-mentioned risks are also reasons why OSS projects have a high rate of missing initial project objectives.