Managing Project Logs using Jira

As an Atlassian Platinum Solution Partner, we love working with Atlassian tools – especially Jira.

Jira Software makes it easy for our delivery teams to collaborate, plan, track, test and manage releases of software versions.

Jira’s flexibility, extensibility and custom reporting options help us improve efficiencies and transparency for our clients at every level of their organisations.

Today, we’ve decided to give you a behind the scenes look at how we use Jira in our adopting an Agile PMO using Jira blog series.

We’ll be discussing managing Project Logs using the Jira toolset, focussing on:

• Introducing Project Logs and demonstrating how Jira software can be adapted to provide a centralised approach for managing and reporting this important information.
• Outlining how Jira can have a dedicated project set up for tracking project or programme-level management related information – which in this example we simply call a ‘RAID’ project.
• A project having specific issue types setup for each of the different project management items – each one having its own customised workflows, fields, screens, etc.
• How key project management information can be displayed on various reporting dashboards.

RAID Logs – risks, assumptions, issues and dependencies

RAID Logs are a simple, effective management tool used to organise project-related information by the tracking of Risks, Assumptions, Issues, and Dependencies.

• The risk Log records information such as probability, impact, proximity, mitigation, owner and alike for things that could go wrong but have not yet occurred.
• The assumption Log records information such as sensitivity (impact), stability (confidence), reporter and alike for things that have been assumed within the project/programme.
• The issue Log records information such as issue description, action owner, impact, resolution date and alike for known issues within the project/programme.
• The dependency Log records information such as description, due date, owner, impact, the likelihood for dependencies within the project or programme.

Additional Note: You could have separate dedicated RAID project for each of your project or programme areas – or you can simply put everything into a single centralised project and use ‘Component’ or another field to identify the specific project or programme to which the individual RAID items belong.

Other Logs – actions, decisions and change requests

Other project Logs can also be managed in similar fashion including actions, decisions and change requests.

• The action Log records information such as status, owner, review date, target resolution date and alike for things that require attention or progression by someone (usually external to the actual delivery team).
• The decision Log records information such as decision details, decision maker, date, event, options considered and alike for things that have been agreed or confirmed that impact the project/programme.
• The change request Log records information such as impact of change, estimates, approvers, status and alike for any proposed or agreed changes in scope that impact delivery of the project/programme.

Additional Note: Sometimes you may wish to separate some of the specific issue types items into their own Jira project which makes things easier to share specific content with stakeholders, different teams or external parties (e.g. ‘Change Requests’ or ‘Actions’) rather than risk of exposing all types of information.

Benefits of using Logs

The right level of detail needs to be captured in these Logs, and it should be dynamic content that is constantly maintained throughout the project lifecycle.

These Logs can be an effective tool for audits and governance, while also providing an excellent overview of the key information associated with the project or programme delivery.

Traditionally, these project Logs are created using Excel spreadsheets – which are then hard to manage, share, audit and report on. Jira provides an excellent alternative means for recording and tracking your RAID items and other project information.

Benefits of using Jira software for Logs

Jira software can be an excellent means to collate RAID items into a centralised and collaborative repository for your organisation.

You can pick and choose exactly what type of Logs you wish to adopt using Jira and easily create your own bespoke issue types to record any other types of items.

You can add customisable ‘meta-data’ onto your items to distinguish between different business areas.

Each of your type of information can have their own specific workflow to allow creation, review, escalation, resolution and closure.

You can add your own Custom fields for capturing any required details within any specific RAID Logs.

For example, your ‘Impact’ and ‘Likelihood’ fields for RISKS could be set up, as shown below:

These custom fields can be made mandatory (i.e. empty or ‘None’ values won’t be allowed).

An unlimited number of additional fields can be set up to capture its own type of information, e.g. numbers, drop-down lists, text fields, dates, user picker, etc – as shown below:

Any standard or custom fields can be set to be mandatory for specific RAID issue types and/or even required at different workflow steps.

Jira automatically sends out email notifications as/when your RAID items are edited, transitioned or updated.

Comments can be added onto your RAID items, and all items can be assigned to specific people for actioning – preventing the need for additional emails.

You can also have scripted or automated custom fields which are automatically created or updated based on other related information – for example ‘Impact to Delivery’ severity field based on score of ‘Impact’ x ‘Probability’.

Your previous and existing RAID Log spreadsheets can be imported into Jira to produce and show ‘a single version of the truth’.

RAID Logs in Jira

Jira allows for the simple searching of results based on filtering the data using standard and custom fields.

Jira also allows for the advance searching of results using its own Jira query language (or JQL).

Using JQL, you can build your own complicated, compound, boolean and nested queries to find any specific information.

Your queries can be saved and shared as filters for subsequent re-use by yourself or others.

Your search results can be displayed in a navigable ‘listing’ together with any of your desired standard or custom fields.

Once set up, your selected fields for each query can also be stored within the saved filters.

These queries can also be set up with their own subscriptions to automatically email results to yourself and/or any predefined groups of users.

Email subscriptions sending the users automated reminders about any late items or due this week are often beneficial.

RAID Workflow in Jira

Your JIRA administrators can set up a common or dedicated workflow for each of your issue types.

These workflows allow for tickets to be transitioned to different statuses representing the lifecycle of the issues.

These workflows can be as sophisticated as needed to meet your requirements.

Transitions between the Statuses can be labelled to meet your exact needs. If needed, transitions can be restricted to only specific users or groups (and these options won’t appear to other users).

Multiple transitions can be created, and custom fields can be captured at various transition points within the workflow.

Validation means that certain fields can be set to be required at specific transitions and post-processing steps can allow things to automatically happen as part of transition (such as auto-setting fields, users, dates, etc).

Transitions can be made available from any other point within the workflow and/or individually set up as their own links just between specific statuses – as shown below:

Comments, integrated notifications and history of changes

Jira includes the option to add comments within any of your RAID items. These comments allow for discussions and communication to happen about the specific items.

Email notifications are automatically sent out to the creator, assignee, and watchers for each ticket whenever a comment is added and/or when any other data fields are updated.

Any changes made to the tickets are automatically captured within the changelog – details of what fields were changed, by whom and when are always captured.

The adding of comments and the notification of changes provide significant improvement to the overall experience – especially compared to logging details in spreadsheets.

By default, Jira shows a full audit history of all changes, as shown below:

RAID Matrix dashboard

You can build your own Jira dashboards – enabling you to see an overview of all your RAID items from across all projects or programmes.

Dashboards are automatically updated and always show the latest information.

You can click on the links in the dashboard information to open the listings for these specific items.

These dashboards can be shared with other groups of users as needed.

You can build a dashboard with a matrix of results for each RAID issue type – as shown below:

RAID Dashboard on Jira

The RAID items are organised and displayed together based on the ‘meta-data’ used to identify the specific project or programme.

These dashboards can be customised to suit and can include any other Jira information as needed.

You can build your own Jira dashboards for displaying a summary of your RAID items – as shown below:

Escalated and exceptions risks dashboard

You can build your own custom dashboards to highlight specific RAID items that meet certain requirements.

For example, you could highlight the following types of RAID items:

• Those which have been put into a specific ‘status’ (i.e. escalated).
• Those which have been given a certain ‘flag’ field and/or a trigger has been set.
• Those where an expected ‘due date’ field has now been passed.
• Those which have been given a ‘high risk’ (or certain RAG status – e.g. RED).
• Those which have had a field changed in a negative direction – i.e. risk likelihood has got ‘worse’ or assumption changed to be deemed ‘less reliable’.

Risk ROAMing on Jira

Jira is an excellent choice for Risk Management regardless of your delivery approach or methodologies.

For SAFe®, there’s the expectation that risks are analysed and put into one of the following four categories.

• Resolved
• Owned
• Accepted
• Mitigated

The process can be referred to as Risk ROAMing and is undertaken as part of PI Planning.

We can achieve this in Jira by using workflow transitions and simple Kanban board setup – where individual items can be dragged into their correct column to match required ‘risk response’ – as shown below:

The option for blocked is also available (which sometimes is applicable).

Once your Risks have been categorised as part of the ROAMing exercise – this information can also be displayed on a dashboard.

The charts used and fields displayed can be customised to meet your requirements, and these dashboards can be shared with specific groups of users.

Conclusions and next steps

Maintaining project Logs (especially RAID Logs) is usually a key management technique used within many project or programme delivery approaches – including Agile methodologies.

Risk ROAMing is also part of Programme Increment (PI) Planning, an essential part of SAFe®.

Jira is an excellent software tool which enables the creation, management and reporting of your RAID log items while vastly improving internal communication and cross-team collaboration.

Jira provides the flexibility which can easily incorporate changes to suit your specific requirements.

Adopting Jira to give a ‘single version of the truth’ will prevent project-specific information being ‘siloed’ away and the use of email subscriptions can help prevent details from becoming out of date.

Dashboards can provide excellent means for internally tracking your project related information and dynamically reporting latest details onto stakeholders.

As Atlassian Partners – GlobalLogic can help you to introduce or adapt your existing Jira set up to be the best solution for managing your project management information and Logs within your organisation.

We have pre-built Jira project templates which can be used to accelerate the initial setup/deployment. These additional projects can then be further refined to meet your exact requirements.

Please contact us if you like to receive more details or arrange for a demonstration.

Get in touch

Reach out for more information about how GlobalLogic can help you select, customise, and implement the right Atlassian tools to make your project a success.

About the author

Tim Cavalier – Atlassian Consultant for GlobalLogic

Tim is a certified Jira Administrator with over 12 years of experience from leading the introduction, development and support of Atlassian tools across multiple businesses – including undertaking Jira data migration from server to cloud and/or data-centre for a number of our clients.

Also, Tim has vast hands-on expertise in leading IT technical delivery, PMO and support teams including the set-up of centralised project governance frameworks and PMO processes based around Atlassian product suite.