Viewing an asset in Assets

Let’s have a look at our Jira instance (asset) in Assets. It’s quite an old version and we want to get it upgraded to get new features, security updates, and all the other bug fixes.

We’ll open a change request against it to upgrade it to the latest LTS release: 8.13.

What’s important here is some of the fields of our asset that will affect how our change request behaves:

• Importance (based on which our change will be assigned a proper risk)

• Owner (who needs to give a green light, because he’s the system admin responsible for this Jira instance)

• References to other assets: Server, License, Teams using it (just to see dependencies)

Creating a change request

Let’s open a change request, and choose this Jira instance as an affected object.

Let’s fill in the fields explaining the change:

• Change type

• Change reason

• Urgency

• Impact

Viewing the asset on the change request

After the change request is created, details of our Jira instance are pulled into the request. Both you, and everyone interested, can view it.

You can configure what exactly is displayed here…

Viewing the effect of automation rules

But, there’s more. Thanks to automation rules, Jira automatically:

• Defined the priority as High

• Defined the change risk as High

This will help the approvers take necessary steps when approving this change—for example, they could move the date to a weekend and make sure that the teams using this Jira instance can work without it.

How did we do it?

We added new automation rules to Jira Service Management. The ones used here:

• Use asset’s “Importance” to determine the change risk

• Use change request’s Impact / Urgency to assign a proper priority

But if it was an Emergency… that’s a different story. Thanks to automations, Emergency changes can bypass a few steps, so you can implement them right away instead of running around asking for permissions.

It’s an Emergency after all.

Planning the change

After our change request is transitioned to the Planning stage, the whole team can get together and collect all the necessary info.

• Implementation plan (how will we do it?)

• Test plan (how will we test it works?)

• Backout plan (how do we quickly roll back?)

Just to make sure we know what we’re doing or can roll back if it turns out we don’t.

Review change dates in the change calendar

Get a comprehensive view of all the changes in your project and assess if the change date is suitable against any freeze and maintenance windows.

• What are the change timelines?
• Does it conflict with any other events?
• Do we need to roll out the change on a different date?

Approving the change by the asset’s owner

With the plan ready, we can transition the change request to the Approving step where it will undergo the initial review. It would usually be done by change managers (fetched from a Jira user picker custom field) and someone responsible for this Jira instance—the right person at the right time.

Although you’d usually know who change managers are, you can have as many asset owners as you have assets. You don’t have to know who they are, because Jira will automatically assign them as approvers based on their relation to the asset.

It will be a different owner for a different software or server, or maybe no owner if the asset isn’t that important.

How did we do it?

We used approvers who are related to the Assets object. It won’t always be a fixed group of users – they will change based on the asset you select in the change request.

Jira will:

• Check what’s the affected asset

• Look for approvers in its attributes

• Assign these people as approvers

Assessing the risk: CAB review

After the initial review, the change is moved to the next approval step. Normal changes don’t have established processes so it’s good to properly assess them.

Here the change is being assessed by the Change Advisory Board (CAB) that can include additional experts to reduce the risk and avoid any problems.

Implementing the change

Once the change is approved, we can start implementing it. Let’s assume that all the teams have been informed and we can just upgrade this instance.

Optional: Changing the object’s status

But, in case someone was wondering what’s going on with this Jira instance, starting the work on it triggered a status change.

• Jira is no longer Running, as we’re implementing the change. It’s In Service.

This can be done through Assets post-functions added to the workflow. In this case, they change the object’s attribute when the change request is moved through a certain transition.

This is not part of change management. If you’d like to use it, see Adding Assets functions to workflows in Jira.

Completing and closing the change

Once Jira is upgraded and the work is done, we can complete the change, and see how everything is green again.

When closing the change request, you can select the resolution: Change successful or Change failed.

What’s next?

Once the change is complete, you can also view some Assets reports for your assets and changes that affected them.

For example, you can check how many issues were raised against your assets – how many incidents, problems, or changes.

And if there’s too many… Well, this might just mean it’s time to buy a new asset.