Our client, a leading national energy provider we have engaged with over several years, needed to establish and onboard their Security Risk team to Jira to support their project framework, as this team lacked a holistic way to track and report on key lifecycle events for their Audit and Condition Report process.
With this being a new branch of the organization, the engagement would require us to implement net-new processes to meet the needs of this group. Historically, audits can be cumbersome, and the ability to track and report against that was critical to the Security Risk Team.
Through conversations with our Account Managers and Solutions Architects, this project was agreed upon for a 6-week timeframe, the first 4-weeks covering discovery and configuration, with the remaining 2-weeks for User Acceptance Testing (UAT) and rollout support. We supported our client with 2 Subject Matter Experts (SMEs) that would work alongside our main point of contact(s) from the client-side for a continuous feedback loop and quality assurance. Our delivery team designed a specific Jira Software project to track and manage both the audit and condition reports. It was decided during the discovery and design process to utilize native out-of-the-box reporting capabilities within Jira. During the project, we used the Create on Transition app to automate workflow functionality and self-referencing transitions to seamlessly update key metrics on the Jira ticket. Additionally, we configured and designed reporting templates in the Confluence knowledge base to provide executives a more detailed view into specific Audit & Condition Reports respectively.
Below are details of what our initial Discovery, Design, and Configuration entailed:
- The client was looking to use Jira to manage compliance with key Risk Security processes.
- The current processes were housed in email and Sharepoint. There wasn't a lot of transparency as to where things were in the process lifecycle.
- They needed a tool that would be flexible enough to handle future process changes
- The solution also needed to accommodate leadership reporting asks, as the team previously did not have any automatic reporting available.
- The solution needed to accommodate several approval steps.
- The Security Risk Team wanted to utilize out-of-box Jira and Confluence functionality as much as possible.
- It was evident that the two main processes (Condition Reports and Audit Engagements) functioned differently at a high level but that we could utilize Jira issue hierarchy and issue linking to bring both processes to life in the same project.
- At a high level, our team was able to utilize the Epic level for running Condition Reports. Having this larger container of work enabled us to organize the work connected to the Epic.
- Our delivery team developed workflows that could be shared amongst the project issue types where possible.
- They also designed a workflow and process for RFI's that the team receives from their internal business partners.
At the conclusion of the project, we were able to deliver the following:
1 project, capturing 2 separate processes. ( Condition & Audit Report )
In order to lessen the administrative overhead of adding these Security Risk functions into an instance that otherwise did not have Security Risk processes, we were able to reuse workflows and screen schemes between issue types. Since their processes were being moved into Jira, the team was able to utilize workflow validation to ensure that key data they wanted to report on was consistently available for reporting. We helped them narrow into what this key data was and as a result, gained positive feedback from the team and leadership as work autonomy within the Security Risk Team and Dashboard/Reporting metrics were visible to key stakeholders.
This project would be foundational in our client's overall Risk Management reporting, which was enabled with the standardization of tracking existing and residual risks on a company-wide Enterprise level.