The four questions you need to ask to balance external collaboration and risk management

In Darkest Hour there’s a scene in which Winston Churchill is almost begging Franklin Roosevelt for the warplanes that they had ordered, and now desperately needed. It got me thinking about collaboration and about how important it can be for gaining capability; and how badly it can go if we don’t assess the new risks that collaborating entails. I’ll refer back to this scenario throughout the post but please note that for the history buffs, I know I’m not being historically accurate.

Collaboration is essential to doing business – I don’t think this is in dispute (if you’d like to dispute it, I’ll happily debate you). What I don’t think gets talked about often enough is how we should think about the decision to collaborate. All collaboration should be cost-benefit based, with the decision predicated on whether the benefits outweigh the risks.

I’ve found that the frame below a useful way to think about the decision to collaborate with another organisation.

There are four basic questions that need answering:

  1. What benefit is there to collaborating?
  2. What new risks does the collaboration expose us to?
  3. Can you effectively mitigate the risks?
  4. Who has the authority to decide whether the balance is right?

1. What benefit is there to collaborating?

The UK needed planes to fight a resurgent Germany – but should they build them, or collaborate to get what they needed sooner and maybe even cheaper?

Stage 1 must be about quantifying the gain from collaboration. Collaboration is always about achieving objectives cost-effectively. If your organisation can already achieve the objective cost effectively, you don’t need to collaborate. Your thesis should be that collaborating will let you will gain access to information, capability or knowledge at a cost that makes the risks of collaborating worth the organisational gain. The deliverable from this stage should be a cost-benefit analysis.

2. What new risks does the collaboration expose you to?

Getting the planes sooner and cheaper gives the UK more capability, and more reserves to buy more capability if they need it – but what risks will relying on the US introduce?

Collaboration will always expose your business to new risks – so stage 2 should be identifying and quantifying them. New risks will principally come from two places –

  1.  The fact that your counter-party will always have better information about what they offer.
  2. The information you will expose about and from your business while collaborating.

To get this assessment right, you should seek input from experts in all areas of your business. Once you have an accurate risk register, and assessment of the magnitude of harm, you can move on to mitigation strategies.

3. Can you effectively mitigate the risks?

The war winning or losing question – if the US doesn’t deliver the planes when we need them, what do we do?

Once you understand the risks, mitigation measures can be defined. Risk mitigation will look to balance the incentives of involved parties, minimise the amount of information leakage, make sure adequate information about service quality is available, and ensure that adequate backup plans are in place. Once you understand your ability to effectively mitigate each risk, you can then make a call about whether to insure against or accept any residual risks.

4. Who has the authority to decide whether the balance is right?

Get it right – and the UK gets the planes and has the capability it needs to defend itself. Get it wrong, and the UK faces a resurgent Germany without what it needs to defend itself. Who had the authority to risk the future of the United Kingdom on this collaboration?

Someone in the organisation will need to accept the risks of a new collaboration. How high in the organisation they are will depend on the impact of loss. If you know who this person is, you should consider their appetite for risk early on and include that in your early go/no-go decisions. It goes without saying that putting together a great case for someone whose’ risk aversion won’t let you move forward should be avoided.

Conclusion

We all collaborate many times a day without thinking about it. When we go across the boundary of our organisation, the dynamic changes. We should be doing it because there is a cost-benefit relationship that lets us access information, capability and knowledge at far below the cost of developing it. Benefits though are only one side, we need to also consider the risks and whether we are able to take those risks on behalf of our organisation. If you keep this frame in mind, you should get good outcomes.

Does this reflect your view on collaboration and how it should be approached? If not, I’d love to hear from you and understand why.

The only four reasons why you should collaborate with another organisation

Collaboration is “the act of working together to produce something”. Over the last ten years it has been billed as a magic bullet, and like so many magic bullets, it has become unfashionable to question why, how and if we achieve value from it. Which I think is a mistake that has eroded our understanding of it, and lead to the current magic bullet view.

In a previous post, I outlined what you can get access to when you collaborate. Just because you can though, it doesn’t mean that you should. There are four reasons that I think make collaboration worth consideration:

  1. You need something faster than your organisation can deliver it.
  2. Developing or acquiring what you need in-house is too expensive.
  3. Your organisation cannot create what you need because of regulations.
  4. You’re looking for the capability to become a customer.

Under any other circumstances, you should seriously question the need to collaborate. Collaborating is a build or buy decision that has to stand up to a cost-benefit analysis. If your organisation can deliver what you need fast enough and at a market competitive price, without violating any regulations, what justifiable reason do you have for collaboration?

The three things you can get by collaborating with another organization.

Collaboration is “the act of working together to produce something”.

It’s fundamentally about going outside your organization to get access to something without having to build it. There are also times when you might not be able to get what you need internally for regulatory reasons, or because the capability to become a customer is a self-defeating cycle if you’re just buying your own stuff.

When you collaborate with another organization, you should think about the gap you are trying to fill in terms of one of the following three things –

  1. Information – facts about something or someone.
  2. Knowledge – the theoretical or practical understanding of a subject.
  3. Capability – the power or ability to do something.

Once you define your need in one of these terms, you’re much more likely to make the right decision about whether you should collaborate, and then to find an efficient supplier of what you need.

Reducing risk in government contractor engagements by improving information governance

The last two decades have seen a step change in the methods we use to interact with contractors. Generally speaking, the primary means of engagement is now digital. This has brought with it significant reductions in the cost of engagement, and reduced the time to commencement of work. It has also increased the volume of engagements each employee is expected to support, and the quantum of risk associated with incorrect transfers of information. In discussions with many government entities I have found a number of common areas in which expensive problems occur frequently, that I also believe can be substantially reduced by improving information governance around each engagement.

Incorrect version transmittals. In organisations that run large projects, I’ve found that transmittals are still error prone. Large transmittals (lots of documents, or large documents) generally go out as multiple emails or on physical media – paper or digital. When they do, the probability of using an incorrect document version increases substantially and has obvious consequences for the financial and completion timeline of a project.

Provision and capture of as-built documentation. As-built documentation is typically large and held in systems inaccessible outside the organisation. It almost always has changes that need to be captured in a system of record after an engagement. Content is large enough and changed exclusively digitally, so transmission needs to be via electronic medium, or post work updates become very difficult. After an engagement, capture and correct storage of updated as-built documentation is again difficult. The risks are clear, when access isn’t provided and updates aren’t captured effectively, engagements start with incorrect information that leads to variations and re-work.

Capture of compliance documentation. Compliance documentation is a fact of life for contractor engagements. Workcover, insurance, safe work method statements etc. Good contractor management dictates that this documentation should be captured and stored in an organisational system of record and preferably associated with the specific work. Breakdown in this capture process is usually only noticed when there is a project failure. It can often be explained by an over-reliance on email, and failure to follow information governance processes. Mailbox limits frequently dictate that people will archive to repositories that are typically ungoverned and which can lead to a variety of significant liability scenarios.

Proof of work. Proof of work for contractor engagements has gone electronic over the last few years, particularly where it involves small construction or physical maintenance tasks. In some scenarios, inspectors capture photos of completed work, in others, contractors provide photos to prove completion. In each scenario, the problem is the same, the photo is provided, the payment is ordered, everyone moves on to the next project, often without the proof of work being captured in a system of record. I have spoken to records managers supporting legal action who counted themselves lucky for being faced with directories of several thousand photos with descriptive names like “DSCP1101”. The reality is that photographic proof is often lost with the email archive or laptop of the employee who ordered the work.

Ultimately, each of these scenarios can lead to substantial loss, and reflects an information governance challenge that is relatively simple to address. Many of these challenges can be traced to contractors’ lack of access to information governance systems. Manual work arounds and transfers from a system of record to an ungoverned system (ie. email and paper) introduce information risk that can easily be avoided.

Good solutions to this problem start by ensuring that there is a single source of truth for engagement information, and that all staff and contractors involved have access to it. They wrap an information governance framework around the engagement processes, ensuring that when evidence of transmittal, completion, or compliance is needed, it has been captured, is available and its source is known. This is a gap I’ve often encountered within the government organisations that I deal with. Historically this gap has been caused by tool cost and the security status of cloud platforms. Recent changes to the Australian Government Protective Security Policy Framework, and Information Security Manual mean that tools like our own Objective Connect and others are now viable for use by government. If you’re having trouble controlling risks like the ones above, a tool like ours should be on your list to examine.

Collaboration governance and notifiable data breaches – how do you achieve certainty?

The Privacy Amendment (Notifiable Data Breaches) Act 2017 will come into force on the 24th of February 2018. It means that an Australian Privacy Principle (APP) entity with reasonable grounds to believe an “eligible data breach” has occurred needs to report it to both the Office of the Information Commissioner, and the affected individuals, and conduct an investigation within 30 days. Many organisations will fail to effectively service this requirement because their response will rely wholly on meta-data. Effective responses will be made possible via systems that automate the collection of both data and meta-data about content collaboration events involving external parties.

In the lead up to reporting an event, the difference between a notifiable event and the continuation of business as usual, is likely to come down to being able to answer a few specific questions –

  1. What information did we lose control of?
  2. To whom was it exposed?
  3. What is the level of certainty?

In an organisation with automated external governance capture, the answer can look like “we provided x content to y, here are the audit trails and here is the content in its original form”. This answer will likely have a high degree of stability over time.

Organisations with less mature governance frameworks will rely on machine meta-data and interview data. A response from this organisation will have a high degree of ambiguity – “we can see that x accessed y cloud service and uploaded some content that might contain z data”. Three months later, a response even at this level of certainty may be impossible as meta-data logs are routinely overwritten.

Organisations that effectively move towards maturity do it by enabling content-based processes, with tools that make process work more efficient, and capture data and meta-data as a by-product of usage. In the vast majority of cases that I have worked on, control was lost due to the lack of an approved tool rather than by accidental means or malicious attempts to circumvent controls. Once an approved tool is implemented, steps can be taken to reduce access to other tools over time – this will include putting barriers in front of physical media, internet sharing services and email.

Ultimately, good response under mandatory breach disclosure is going to come down to having both the data and the meta-data. If you’re struggling with how this will play out in your organization and you’d like to understand one approach, please reach out to me, particularly if you’re a HPE Content Manager, SharePoint or Objective ECM customer already.

If you’re looking for a good primer on notifiable data breaches, I found the link below from Clayton Utz extremely useful, you can also find lots of good information on the website for the Office of the Information Commissioner.

https://www.claytonutz.com/knowledge/2017/march/take-notice-mandatory-data-breach-notification-laws-to-take-effect-by-23-february-2018