Tips For Compliance Related Planning Project Management

“All things are created twice: first mentally, then physically.  The key to creativity is to begin with the end in mind, with a vision and a blueprint of the desired result.” – Stephen Covey

In my last post, we covered the essentials of planning a compliance project.  Simply put, a compliance project without a solid plan is not unlike a house without a solid foundation.  No matter how much frill and filibuster you put into your project, sooner or later, the lack of a solid base will catch up with you, and you’ll end up with a lot of rubble and probably even more explaining to do.

Crossing the Line: Leaving the Relative Safety of the Planning Phase

When you cross that line from planning into the execution stage of your compliance project, you’re making a statement.  You’re stating that you’re ready to embark on the journey, that you’ve got your resources lined up, and a solid plan to get to the finish line.  Move to execution too early, and you risk failure.  Move too late and you risk budget overages, milestone delays, and resource loss.  Crossing into the green light of “all systems go” is a career move, and the success of your compliance project hinges on this decision.

When you move your project from planning to execution, there’s not always a clear demarcation point.  I suppose, in the ‘eating the elephant’ scenario we visited in my last post, this might be when you stop scratching your plans into the dirt, and take off running after the elephant.  In the review of an anti-money laundering (AML) compliance program, for example, this would be when you shift your focus from confirming resources and determining the review’s scope and objectives to deploying your resources.  At this point, you would be progressing into activities like assessing the adequacy and effectiveness of ongoing AML training programs and the existence and maintenance of AML compliance policies and procedures.   

At this point though, whether you’re chasing an elephant, building a house, or crossing the line into your compliance project‘s execution stage, you’ll want to have confidence in your project plan and a set of steps designed and ready for when contingencies, at least the most likely ones, emerge. For example, how will you adjust your project if you lose a key resource to another company initiative or, worse, to turnover?  What will you do if you find that the data you’ve received through the company’s reporting tools is inadequate for the testing you have designed?  

Communicate – After All, You’re All in This Together

Communication is key here.  What I’ve found most effective, on my projects, is to have a project kickoff meeting with your project team, review the results of your planning process, and devise the best way to announce these details to your project audience.  This project team meeting, in a worst-case scenario, might result in identifying a dropped ball, or some risk that has not yet been mitigated. In a best-case scenario, though, you’ll be streamlining the entirety of your planning process into an executive-level announcement that communicates the project’s scope, timeline, and team in a way that captures all the expertise, diligence, and thought you have invested into the project.

This announcement officially introduces your compliance project to your organization and extends beyond the people who you contacted in planning your project.  It’s also another small win, indicating that your project is progressing.  Whether it comes in the form of a letter sent by email, or a slide deck shown in an opening meeting, this announcement should include:

  • PROJECT NAME:  The name of your compliance project acts as a sort of brand. When you use the name of your project in your communications, people will associate the project with its goal with you, and the project team.  Its success becomes your success.
  • TEAM DETAILS:  Identify the team assigned to your project.  For smaller projects, this can mean identifying one person who oversees the entire project.  Announcements for larger projects may also include the entire team, or just second-level team members assigned to the project’s key parts.
  • PROJECT TIMELINE:  Every project needs an end date.  When will you be out of their hair?  Include a quick sentence or two telling your audience when they can expect the project to be complete, and when they will see the results.  Include other important dates, as they pertain to your project.

When the Rubber Meets the Road – Doing the Project

Throughout the execution phase, you’ll be doing the project.  Maybe that means analyzing transactions for potential noncompliance events, testing red flags identified through that analysis, interviewing compliance process stakeholders, all three, or something else entirely. In the review of an AML compliance program, for example, you would be assessing the adequacy of the company’s compliance policies and procedures, the existence and effectiveness of the risk-based customer identification program, and procedures around SAR filings, among other control activities and elements.  Whatever the requirements for your project, there are common components that any well-managed compliance project will have:

  • Project Tracking (External) – If you’re going to spend time on the aesthetics of your compliance project reporting, this is a good place to start.  This tracking will report progress to your stakeholders, on the status of project deliverables, and budget-to-actual comparisons related to time and money invested in your project. When you are deciding which KPIs to include in your project management reporting, there are standard KPIs, applying to almost all kinds of projects that you should consider.  These include variance reporting around costs, resources, and scheduling, reporting around deliverables achieved and overdue, and the percentage of budgeted time/cost invested to date.   
  • Project Reporting (Internal) – Internal project reporting should be easy to follow, and should flow naturally into the deliverables identified in your external reporting.  Internal reporting  tends to be more detailed than external reporting, and often is built of sub-deliverables that link directly to the deliverables included in your external reporting.  For example, if you are reporting a list of overdue deliverables to your external reporting recipients, the internal reporting team may want to see that list broken out into an aging of those tasks or a listing of the teams responsible for each.
  • Project Issues Tracker – What’s not going so well?  Is there functionality that can’t be implemented?  Did the testing for a potential noncompliance item fail?  Did someone notice a bug in your automation of a compliance report?  Keep a list of these issues as they come up, and prioritize which ones need to be fixed ASAP, and which can remain pending until your compliance project is delivered.
  • Regular meetings to review status and findings – All the planning in the world won’t help your compliance project succeed if you don’t provide regular updates to your stakeholders.  With the milestones and budgets you created during your planning phase, you can now provide status updates showing progress against these targets, and show completion of the smaller subtasks you’ve detailed on your project plan.  This is where your small wins will really shine.

There’s a lot of variety in the nature of the compliance projects we come across during our careers.  Because this post provides guidance that can be applied to almost all projects, regardless of style or scope, best practices for the execution of compliance projects are going to take many forms.  There is one theme, however, that emerges in the list of ‘must haves’ for any compliance project – the need to develop and retain evidence showing that a project’s actual work was executed, and that it was executed well.  The form that evidence takes depends on your project, and the type of work it required.  Most compliance projects require at the very least these execution components:

  • Testing – Did your execution phase include some testing, to show client acceptance of your project, that the functionality of your new system will work as you planned it would, or that you made the best effort possible to scan a list of transactions for compliance?   With testing, it’s important to include key details such as: what was tested, how the items tested were selected (sampling methodology), what was the source of your testing documentation, what were the results, and what do they mean (conclusion).
  • Interviews – Who was interviewed, when, and what did they say?  What were the findings coming out of these discussions, and what is the conclusion?
  • Data Analysis – Did you analyze the entire population?  If you used samples, how were those selected?  What were the dates included in testing?  What were the findings, and how do you conclude on these?

Whether the objective of your compliance project is to improve PCI compliance, enhance your AML program’s KYC procedures, or something else entirely, you’ll need solid execution built on strong planning to get there.  In the end, though, as Dr. Covey said, if you design your execution stage well, and all activities play a role in the end you seek to accomplish, you’ll be at a much lower risk to waste valuable time and resources on deliverables that have no purpose. Project execution will flow much more smoothly, and you’ll have the tools developed and available that will help keep you on time and within budget.  And, with a project progressing smoothly and on schedule, you, your project team, and your stakeholders will all rest easier, knowing that your project will deliver its goals effectively, efficiently, and on time.

Check back soon for the third and final installment in the Project Management series, when we will discuss strategies for successfully closing a project.