Object Definition in O3PM

Intro – The Trouble with Twins

Creating a digital twin of a real-world object sounds easy enough. Just make a note, give it a name, and fill in some metadata. Right?

Not quite.

In my time working within Object Oriented methodologies, I’ve learned that defining objects is a deceptively complex task. I’ve been handed “objectives” that were really just ideas, goals without a shape, intent without an interface. Only weeks into the project would we realize we weren’t working with an object at all. We were trying to build a system around a phantom.

That’s a problem. Not just in object-oriented approaches, but in any form of project management. These shortcomings are always painful, but nowadays, as I work with O3PM, I feel their impact especially clearly. In O3PM, objects are the building blocks of everything. They hold responsibilities, track progress, and link to people, tasks, and other objects. When they’re vague, the system collapses.

It is one of the strengths of O3PM to point out such issues at every project step, naturally forcing PMs to properly set up and work within their projects.

To ease the issue of object definition, I created a short questionnaire that guides through the process of definition. The results are clear and consistent objects, aligned with standardized classes and capable of transforming muddy intent into concrete, traceable units that I can hand over to team members and stakeholders alike.

This article introduces that questionnaire to assist you in your object-oriented journey, whether you’re working in O3PM or not.

The Questionnaire: Clarifying Your Object

The questionnaire is built around the following categories:

1. Function
2. Interaction
3. Properties
4. Standardization

These categories emerged from years of defining ambiguous objects in real-world projects. I developed them to help detect missing context early, define object boundaries clearly, and create reusable building blocks. They’re meant to solidify an object enough to stand on its own, interact smoothly with others, and be handed off to teammates without confusion. The goal is clarity without overengineering.

1. Function

This is your north star. Often, defining an object’s function is enough to clarify it.

• What is or are the functions of the object?
• If you’re stuck, try this alternative: What is the goal of the object?

2. Interaction

Understanding dependencies and interfaces helps define what your object needs and supports.

• What does the object interact with—and how?

Within O3PM I use a number of interaction-related properties that encapsulate the object’s connections. Here are some examples:

• parts: entities the object consists of
• blocked: other objects that must exist before this one can function
• requirements: criteria the object must fulfill
• responsible: person or role in charge
• support: assets or objects supporting this one

3. Other Properties

To serve as a digital twin, the object should include a set of properties that “capture its essence” or KPIs. Here are some of my commonly used properties that capture key characteristics.

Additional metadata

• version: versions of the object
• power: power-output the object can produce
• capacity: storage of the object
• time: timeline information such as start or end dates
• cost: budget, expense, or resource allocation
• etc.: anything else your workflows or queries depend on

4. Class

Ideally, the object should fit into an existing class to reduce overhead and achieve standardization. O3PM aims to assign every object to a class.
But don’t let yourself be limited by your existing classes. Projects are about creating something new, and if new classes are necessary to achieve that, go for it. Also, keep in mind that classes can be merged later on.

• Based on its function and properties, what class or type does this object belong to? Is it a task? An entity? A location? A project?
• Do you need to create a new class to capture this object’s nature?

I try to keep my classes as abstract and wide as possible to capture a wide set of objects.
In addition to classes I use therefore the property type as another descriptor. In addition I can assign multiple types to a single object, like pdf and invoice to clearly define it.

Examples

Let’s put it into practice.

Instead of simply presenting objects, this section walks you through real-world scenarios where I or my team were given information from concrete to vague, partial, or overly broad. By working through the questionnaire, we were able to clarify the object’s purpose, refine its boundaries, and embed it into the O3PM structure with confidence.
Each example is grounded in a moment where definition was missing and clarity had to be built.

Use these examples as blueprints. The original input is followed by the answers we developed through the questionnaire, showing how definition emerges through structure.

Object 1: Car (clear and concrete)

In this case, the object was already well understood and tangible. We knew we were dealing with a car. Following is the mapped information from the questionnaire.

• Function: Transportation of people and equipment
• Interaction:
  • blocked: valid driver’s license, purchase contract
  • responsible: vehicle owner or logistics lead
  • requirement: must be registered, insured
  • support: garage, fuel, maintenance contracts, insurance coverage
  • parts: engine, tires, cargo space
• Properties:
  • version: Different cars over time that fulfilled the same function
  • time: operation start and expected lifetime
  • cost: acquisition cost, fuel budget, maintenance expenses
• Class: entity with type car (I didn’t want to define a specific car class)

This entry served as a baseline. In the next example, we move one step further into the grey zone.

Object 2: Document (based on a real input)

We received an email with a rough description of a measurement plan for placing sensors in a smart city testbed. It included some ideas for locations and mentioned responsibilities, but had no structured format or object status.

Initially, it wasn’t clear whether this was a note, a task, or just an idea. By applying the questionnaire, we were able to clearly define it.

• Function: To document a concrete plan for where and how to place sensors in the project area
• Interaction:
  • blocked: sensor requirement analysis, technical inspection
  • responsible: MEP planner
  • requirement: understandable by the installation team, approved by project manager
  • support: technical drawings, prior city grid information
  • parts: location proposals, map sketch, list of required hardware
• Properties:
  • version: initial draft, revised after meeting, final draft (Author Note: These are horrible version names and shouldn’t be used by anyone. They are only added here for ease of writing.)
• Class: file with type pdf

This example shows how a vague input like a mail can become a clearly defined and reusable object, embedded in the project system and trackable in various queries.

Object 3: Decision (revealed through wrap-up)

The starting point was a project meeting where I updated partners on the status of several deliveries. Midway through the presentation, someone raised a critical question that sparked a long discussion. A flurry of tasks followed, which I noted down.

It wasn’t until the post-meeting wrap-up that I realized something was missing. The tasks seemed clear at first glance. Upon closer inspection, it turned out that the tasks as written didn’t fit into the task chain and ran the risk of causing confusion and conflicts among project partners.

Therefore, I stepped back and created a general entity object. In this file I added the tasks and worked through the questionnaire which revealed the exact type of a single object that addressed the issue through gap analysis: what do I have vs. what do I need.

• Function: Inform and align partners about the current delivery status and achieve a mutually agreed upon decision about next steps
• Interaction:
  • parts: Delivery documentation, status report, scope and risks
  • responsible: Project Manager
  • requirement: must achieve shared understanding and agreement
  • support: meeting notes, email thread, task list
  • parts: affected deliveries, reasoning, assigned follow-ups
• Properties:
  • version: initial consensus in meeting
• Class: atomic with type decision

Without this object in place, the tasks, simply handed to the team and various partners, would have caused quite the stir (confusion and coordination issues to put it mildly). Once we defined the decision explicitly, everything around it not only gained structure and clarity, but was easier to execute in significantly shorter time and at lower cost.

Final Thoughts

If O3PM is the operating system of your project, then objects are your apps—and they only work when they’re properly installed. The clearer the object, the more useful your system becomes.

By walking through this short questionnaire, you can define even abstract ideas in a way that’s actionable, queryable, and scalable. And in doing so, you bring yourself one step closer to a consistent, modular, and intelligent project and document structure that scales and supports momentum.

So next time someone hands you a vague goal, ask the right questions—and build a better twin.