John Trainor

For projects, the most robust offering is Atlassian Jira/Confluence. And as it is widely used, if you are using a vendor, they most likely also use Confluence / Jira and therefor you can share your chosen instance for collaboration. Slack is also an acceptable option and with Salesforce ownership will be widely adopted meaning clients and others will likely be able to collaborate easily.

Collaboration tools are often suited to different use cases. For projects, most organizations are choosing a collaboration tool to support all projects in flight and in the future. 1. Initial project request 2. Requirements 3. Development notes 4. Testing plans and acceptance criteria - which are tracked as the tech team and then the users test the deliverables. 5. Project or enhancement acceptance and close. The ability to turn all of this over to auditors is essential. For client facing functions there are requirements ranging from simple video conferencing to credential granting and user guides. There are several tools to meet an of these needs. Often organizations will therefore have a mix of collaboration tools.

The audience needs to come away with a clear understanding of the aspects of the program and their roles within the data governance program. And yet, they can't come away with a feeling that they are going to have a heavy burden imposed on them for data quality, reporting, or definitions. A good data governance program will recognize that within any organization a lot of the aspects of a program are already in place, they just aren't always formalized. So as long as people realize it is more of a structural change and not an imposition of more responsibilities, they will be more likely to embrace the program and that will lead to success.

Keep it interesting. Start with the history of the Basel Committee on Banking Supervision (BCBS) being formed in 1974 and meeting for the first time in 1975, as a response to the failure of Herstatt Bank in Germany on June 26, 1974. This led to the coining of the term Hestatt risk, when one leg of an FX transaction settles, but a counterparty fails before the 2nd leg can settle, leaving one party missing a payment. My audience all came away from the training saying they learned something interesting. And I think it helped them pay closer attention to the rest of the training.

Don't limit the testing to a limited data sample. Make sure that front to back workflows don't break as a result of redacted data being passed to a process which requires the original data.

Make sure that the tool integrates well with your processing platforms, which rely on the data. Ensure that no processes break because they rely on the original unredacted data.