A transformation process is almost done; the reports for delivery are complete, the new customer app is built, and the supplier has already submitted the final invoice. This allows the PMO team to move to the next project… but… suddenly the Operations team starts asking questions about who owns this, who provides support, who’s the main contact, what the infrastructure for this app is… In this blog post, you'll to learn the importance of Asset Management and how it affects your everyday project operations. Let's keep going...
...at the same time, the service desk team is handling several faulty laptops without reliable warranties, while on the other side, the fleet coordinator is trying to triage and help one of the drivers with a flaw in his vehicle that has broken down. It’s one of those days.
Each team has a list, but none of them provide real answers, and that right there, it’s the real asset management problem… which it’s not usually about the lack of data or order. It’s usually about the lack of connected context.
For many organizations, asset management begins and ends with a spreadsheet, usually containing data about laptops, monitors, mobile phones, vehicles, software licenses, or office equipment, and each row includes details such as tag, serial number, owner, location, and status.
This is useful, of course, but that’s an inventory. In fact, according to the Merriam-Webster Dictionary, it defines it as “the quantity of goods or materials on hand.” On the other side, according to ISO 55000, which provides an international overview of asset management, it defines it as the “realization of value normally involves a balancing of costs, risks, opportunities, and performance benefits.” They also treat an asset broadly as something with actual or potential value to the organization, which can create confusion with inventory, and it's the usual case.
To make it clear, let's compare the questions each discipline asks:
| Inventory Question | Asset Management Question |
|---|---|
| Do we own this laptop? | Is it secure, supported, useful, and economical to keep? |
| Where is this server? | Which apps, services, and projects depend on it? |
| Who uses this software? | Are we receiving enough value to renew it? |
| When does the contract expire? | Who must evaluate the supplier before renewal? |
| How many vehicles are available? | Are they safe, compliant, maintained, and fit for demand? |
| What did the project deliver? | Who will own, fund, support, and eventually retire it? |
Put simply, inventory records the asset; asset management connects that asset with value, responsibility, cost, risk, service, and action.
The service desk needs to know which laptop belongs to which employee, as these are visible with immediate needs. The broader work is less visible. The real challenge is deciding who owns an asset, measuring its performance, getting its business outcomes, calculating its risks, and when further investment is no longer justified.
As a consequence of not controlling that broader aspect, problems such as ignoring the operational handover, not having enough trustworthy information, teamwork overlaps, fleet teams managing faulty vehicles, new budgets are approved without knowing there are already existing assets, and records become outdated.
We have covered different types of assets from different backgrounds. That’s why projects, requests, incidents, maintenance tasks, and approvals are different forms of work belonging to different areas, making assets, apps, vehicles, contracts, services, and locations common to them. Here’s where the connection between the tools that manage each of these aspects becomes relevant.
For example, the PMO normally manages temporary initiatives, which are projects, programs, milestones, risks, budgets, etc. On the other hand, asset management focuses on things that continue after those initiatives finish. One reason why managing both with the same tool might not seem smart; at the same time, connecting those two would avoid tons of manual rework.
When a project starts, it doesn't happen from scratch in an empty environment, as they depend on existing apps, infrastructure, suppliers, locations, teams, specialists, etc. In fact, many projects might depend on the same asset at the same time.
And of course, having all those dependencies hidden in different tools and documents doesn’t allow the Project Management Office stakeholders to get the full picture of possible risks at hand.
When a project finishes, it doesn’t mean the organization is (or isn’t) receiving value from it: The app created on that finished project might be unreliable, expensive, underused, poorly adapted, difficult to support, etc.
Connecting the project to that operational asset makes it easier to track the benefits after the project team has moved on.
As not every organization needs to organize their assets the same way, and not using the same platform, the right option will rely on the number of assets they control, the frequency of change, and how much operational data is required.
Different asset data requires different solutions, from spreadsheets to custom fields in Jira, fleet platforms, enterprise asset management SaaS, or a hybrid architecture. Everything goes, depending on the need. The right choice will depend on the data. Rather than forcing everything into one tool.
⬇️Discover your right approach with this self-assessment table⬇️Download it by the end of this blog⬇️
Atlassian Assets is an asset and configuration management capability within Atlassian’s service-management platform that allows teams to represent assets and configuration items as structured objects, connect them, and link them with Jira Service Management requests, incidents, problems, changes, and similar work. Atlassian also supports broader use cases across functions such as HR, facilities, sales, marketing, and legal.
The main advantage of this Atlassian app is that it can model relationships between those objects and make them available in Jira work, right where people need them, and that’s possible by following these five concepts:
The fact that Atlassian Assets can represent projects, programs, sponsors, apps, contracts, and more doesn't make it a project portfolio management engine. It’s important to note that a project object in Assets can provide context and governance information, but its dates and relationships don’t automatically become a complete tool for projects. It’s a complement.
As Atlassian Assets can represent model vehicles, drivers, depots, insurers, suppliers, and service stories, and Jira Service Management can manage requests, approvals, faults, inspections, and repair workflows, you can use both as a complement. But definitely doesn’t offer a full solution for fleet operations.
The real goal is to make data useful and transform it into information when someone wants to make a decision, e.g., a project manager needs to understand how a project is affected ot an service desk team needs reliable context about a vehicle incident, and that’s why Atlassian Assets becomes a useful tool, because it connects asset information with the work that's already happening in other Atlassian Apps. However, Assets should be treated as a part of the solution, not as the whole solution.
The best place to start is by rethinking the process you need to solve. What information do people need, where does it currently live, who owns it, and what should happen when that information changes?
As different teams have different needs, there’s an asset management approach suitable for each; that’s why comparing the approaches and understanding where each one works best can allow you to identify what better matches your assets, processes, integrations, and operational needs.