The Risk Advisory Services team has been consulting with our financial auditor colleagues in 2016, or what we in the biz call “busy season”, or sometimes “the big show”. As a result, we’ve had the opportunity to discuss the results of regulatory exams for many banks all over the region, allowing us to gauge current trends in regulatory findings. We have noticed a finding at several financial institutions that merit some discussion here in deTECH.
Here’s the skinny – it looks like banking regulators have started focusing on project management in the IT portion of their examinations; or have, at a minimum, expanded the depth of their evaluation of this section. Project management has often been considered a necessity for large companies. Complex organizations with departments in separate offices or geographical locations and many stakeholders must have a plan to implement change on a significant scale.
The point in community banking where project management becomes important to successfully implementing change is about the to $2 billion asset mark. At this level (in general, of course), the number of employees does not lend itself well to quick, close communication. Projects become larger than one individual can handle on their own. Additional regulatory requirements like Sarbanes Oxley or FDICIA have kicked in and changes must be filtered through the lens of internal controls. Keeping these moving parts going in the same direction, keeping all stakeholders informed, meeting deadlines and budgets, lends itself well to a formal project management program.
However, our observations of regulator comments doesn’t indicate that only on $2 Billion+ institutions need to address project management. We’ve seem similar comments for small banks, less than $500 Million in assets, indicating asset size does not appear to be factored into the expectation of having a project management process. So, for those companies (not just banks) without deep pockets and wide resources, what does project management look like?
The FFIC’s IT Booklet for Development and Acquisition provides some action points for developing a project management plan. The seven key points include the following:
- Project plans
- Definitions of project requirements and procedures
- Project management standards and procedures
- Quality assurance an risk management standards and procedures
- Definitions of project roles and responsibilities
- Involvement by all affected parties
- Project communication techniques
The good news is that whether or not you have Project Management Policy/Program, your organization probably already uses several project management techniques. When a decision is made to move forward with a purchase or substantial change, the goals are laid out, responsibilities are assigned for coordinating with the appropriate staff and vendors, a risk assessment is performed (even if it’s not always documented), and some committee, often an IT Steering Committee, monitors the progress of the project. These steps might not be written down and archived in a neatly organized project plan, but the process is often there.
So as you continue planning for 2016, consider how your organization can use your current project management principles to more effectively handle changes. Look for ways to document and take credit for steps that are being performed informally. And during your next regulatory exam, you’ll be able to knock the project management questions out of the park.
Bryan is a Manager at YHB and serves on the Risk Advisory Services Team. Bryan focuses on assisting organizations in a variety of industries with internal audits and IT-related audit and consulting services.