It’s project portfolio review time again. The whole team got together from different cities around the country in a meeting room. This way, the PMO can see which projects are on track and expected to finish on time, as well as responsibilities, milestones, etc. Everything goes great until someone asks how these projects will be affected when they start the changeover to producing the new models. This is when having visibility beyond just projects plays an important part when managing your project portfolio, and we’ll explain in the following.
When someone asks, “Which production lines will be affected when the factory starts producing the new model?”
Then, someone else adds questions regarding the tooling in use for those projects, such as project dependencies, supplies, and of course, whether there will be enough asset availability for the projects…
Now, the PMO review is not going as well as it was thought. As the related project data isn't available for the current project portfolio view.
The thing is that the information requested during the meeting probably exists distributed between maintenance systems, records, documentation, supplier spreadsheets, and in people’s knowledge, working with that information directly.
So, how to keep the PMO information, and more operational aspects of it, in the same view?
Many of you might be thinking about a PMO Charter, but in this case an active asset connected to the project is needed that allows you to track project data.
Duplicating information in different tools or platforms, usually with different names or outdated details, over time brings more work, transferring operations activity to the PMO, increasing the risk of inconsistencies across the portfolio and asset records.
In the case of the PMO, they just need to know which production lines will be affected, not control the asset management process. Which means that the asset information should be available in the project portfolio view but not controlled by the PMO.
Including objects from Atlassian Assets into a project portfolio view, as the one that Projectrak for Jira offers, allows you to not only describe projects with their own project fields, but also connect them with live objects from Assets.
At the same time, Atlassian Assets allows you to group those objects into schemas, differentiating them by different types, attributes, and relationships, functioning as a Configuration Management Database (CMDB) or structured inventory.
Why it’s important to differentiate Inventory from Asset Management >>
This will allow us to level up the PMO conversation, broadening the spectrum of dependencies of the project, from the asset management perspective, allowing us to oversee if a project is related to X production line, testing facility, team of specialists, equipment, or maintenance window. This gives the PMO a better view of where operations and risks meet.
Relating the project portfolio with assets can also provide a different perspective on investment: If multiple projects are changing or investing in the same factory, facility, equipment, service, or operational resource, it allows the PMO to better understand where transformation activity is concentrated across the organization.
The value of the Projectrak for Jira Asset field is therefore not simply displaying the name of an asset inside of a project, or across the portfolio. It allows different projects to reference the same organizational reality.
This is where the Asset Field in Projectrak becomes useful. Instead of creating another text or list field where someone manually types the name of a production line, supplier, facility, or equipment, the project can reference an object that already exists in Atlassian Assets.
For example, imagine the PMO creates a project field called "Affected production line". Rather than entering "Assembly Line 4" manually across several projects, the field can point directly to the existing "Assembly Line 4" object already maintained in Assets.
The difference might look small from the project view, but from a data management perspective, it changes the logic completely. Now, the PMO is no longer creating its own version of the asset. It's simply saying that the project is just related to this other organizational asset.
You keep managing the project with Projectrak, while the production line continues to be managed by whoever is actually responsible for that asset in Atlassian Assets, avoiding turning the PMO into another asset management team.
The logic behind it is relatively straightforward. First, the organization already needs to have its objects structured in Atlassian Assets. In automotive environments, this could include object types such as production lines, plants, equipment, suppliers, testing, or other operational resources.
Then, a Projectrak Asset field can be created for the project-level information that the PMO actually needs, such as the main production line, the production facility, testing, strategic suppliers, and critical equipment.
The field uses Asset Query Language (AQL) to determine which Asset objects should be available for selection. It's a simple language, accessible to anyone, and easy to create with the help of Rovo.
If the field is intended to contain production lines, there's little value in showing the project manager every supplier, employee, laptop, building, and vehicle stored in Assets. The configuration can narrow that selection so that the user only sees what is relevant.
This is important because complexity should remain behind the configuration. The project manager should simply see a useful field and select the right object.
This becomes especially interesting when several projects reference the same object. Imagine that three projects in the automotive portfolio are connected to that "Assembly Line 4". The first one is introducing tooling for a new model; the second is complementing an automation improvement. The third is preparing maintenance work that requires part of the line to stop temporarily.
If we go through each project individually, everything could still appear under control; the milestone dates look reasonable. Each project manager has a plan, and budgets are approved.
But once the projects are connected with the same production line, the PMO has different questions to ask: Can these three initiatives realistically happen around the same operational asset without affecting one another? And the answers will depend on each context.
These are the type of dependencies that may not appear naturally when project portfolio management focuses only on project-to-project relationships. Making those connections visible gives the PMO another layer of context before the dependency becomes a delivery problem.
This distinction is probably one of the most important parts of the model:
In short, there are different scenarios: Assets are static, project temporary.
Now, without Projectrak's Assets Fields, trying to manage that information directly in the projects may generate unnecessary duplication of the data in Jira, and to some extent, as these two might collide from different backgrounds (Ops and PMP), this is precisely why maintaining just the relationship is key and more useful than trying to merge them.
This connection opens a more strategic way for the PMO to look at project dependencies, rather than focusing only on the basic project data involved.
The PMO and Operations team can now collaborate better and identify the assets, suppliers, equipment, services, and other operational resources that projects rely on and are more likely to change.
The Projectrak Asset Field makes those connections visible at the project level, so those unexpected questions during review meetings are answered right there on the spot; this way, Atlassian Assets serves as the source of context behind each asset management.