PDS management and key man risk

There’s a pretty standard chain of events that lead to key man risk in PDS land.

First, PDSs are handled by whoever doesn’t run away fast enough (which is probably a long distant memory in most places now).

Then, someone is given the job of looking after PDSs. These days, that might be their only job.

Over time, they learn about the product set in excruciating detail – which products are governed under which constitutions, why we have that one line on page 3 about an obscure risk, etc.

Plus they have all the insider knowledge such as who is responsible for the various operating aspects of each product, who to ask if you have a question, how to decide which person’s wording is included when there’s a disagreement, how to handle each stakeholder and so on.

Your PDS manager’s expertise is a double-edged sword. On the one hand, yes, it’s an obvious risk, but on the other, far out they do a good job! Especially when it’s a job that most people don’t want.

Sometime a business is well aware of key man risk, for instance when product updates are being organised around the planned holidays of the PDS manager. And sometimes it’s in the category of ‘yes we know we only have one person who does PDSs, but it’s not that complicated, and we’d muddle through if we have to’.

Let’s talk about the second category. I know of a real-life example where the person in charge of PDSs was unexpectedly put out of action for a number of months because of a car accident. Yes, the team muddled through without them. But not well enough, and they ended up having to re-roll all the documents at ASIC’s behest. Fun times.

So, what to do about it?

Well firstly, you need a watertight and well documented process. Just like all the procedures that you find in a call centre. A ‘break glass in case of accident’ file if you will. And don’t forget that the better you are at something, the more details you’ll likely gloss over. So if you’re the PDS manager, make sure you get someone to read it through and check that they could follow all the instructions. Including what to do when things inevitably don’t go to plan.

Secondly, you need a clear record of who is responsible for what content across the suite of PDSs. This could be in Excel (although frankly that sounds very painful to me) or housed in your PDS software.

Don’t forget, PDSs need to both meet the legal requirements AND accurately reflect how the product works. The first is reasonably straight forward in a crisis, there are lots of excellent legal firms who can sort you out (for a fee of course!) but the second is where it’s easier to come unstuck.

Again, an example. I was working with a firm where they were the newly anointed Responsible Entity and therefore the PDSs were being reviewed with fresh eyes. The law firm we were working with insisted that a particular paragraph had to go in (something to do with tax if I remember correctly).

So off I went to the Ops team to confirm that this matched how the product operated. It didn’t. So the Ops team investigated if the product could be modified to match the new paragraph. It couldn’t. So I went back to the law firm and asked why the para had to go in? ‘Good practice’ I was told. It was only when I explained that the product didn’t work that way, and could he please point me to the relevant reg guide or legislation that required it, that he backed down and said it wasn’t actually required.

My point? That it’s only because of my prior experience and knowledge that the extra para didn’t end up in the PDS. It takes a fair level of confidence to argue with the partner of a major law firm, but that was what was required to get a good result.

Next, you need a “decisions made” file. This could be an Excel spreadsheet, or contained in more sophisticated software, but at the end of the day, you really want to be able to look back and see why a decision was made to change a piece of content. It can feel like overkill at the time, especially when everyone is so busy just trying to get the PDSs out the door, but you’ll thank me in 3 years’ time when there’s a complaint or ASIC issue and you’re trying to establish just why that wording was changed.

And lastly, I highly recommend building out a wiki over time. Again, this could be in Excel, or on your intranet, or even just a word document that everyone has access to. At Mayflower, we use a system called Slab.

Your PDS wiki is where you can store all the tricks and tips you’ve learnt over the years, as well as the above documents, links to constitutions, old versions of PDSs, link to the folders with all the verification certificates (unless of course you’re using modern PDS software which stores it internally), etc, etc.

There’s absolutely no point creating all this great information if no-one can find it if your PDS manager isn’t there.

Longer term, you probably also want to think about having more than one person manage your PDS processes. This can be very difficult to organise though, as a) it’s very bloody difficult to get additional headcount for something like PDSs that most definitely don’t make anyone more money, and b) PDS managers are control freaks and often aren’t very good at sharing. (And I say that with love and affection!!!) Their control freak nature is what makes them excellent PDS managers to begin with.

Your better bet is to demonstrate that your PDS manager’s exceptional skill set could be put to better use than just managing documents, and that an additional (cheaper) resource could free them up to put their expertise to work adding value to the business.

So there you have it, the measures to put in place to minimise your key man risk when it comes to PDSs. And with that, I’m going back to bed. Damn Covid!