Managing Priorities in Day-to-Day Operation
How to maintain focus and get the timing right in a Fast-Paced Work Life.
Now what is this all about?
First there was talk of DCVI and Super Sprints, then Drum Beat and NewPDP and now he shows up with a pomegranate tree and wants to overhaul day-to-day operations entirely.
This is getting wilder by the minute.
Don’t worry. I haven’t lost my mind, and I have no intention of making things more complicated than they need to be.
Quite the opposite: I want to show you a way to better manage the complexity of everyday operations, and in doing so, create more space for the work that actually matters — your projects.
Paradoxically, simplifying requires one small addition, a new term: the ITEM.
The term ITEM encompasses everything that needs to be done to create value in the daily business.
I’d like to use the analogy of a pomegranate tree, because I believe it makes this concept easier to grasp. It will run through the next several articles. I ask for a little patience, with the hope that by the end of the series, the full picture comes together.
Imagine that everything sitting on your desk is like a pomegranate hanging on a tree.
The Idea in a Nutshell
Let me get straight to the point:
Let’s not limit hybrid project management to projects alone. Instead, let’s put everything that needs to be done into one shared, comprehensive backlog.
What do we gain from this? Two concrete outcomes:
1. We gain greater transparency, can recognize patterns, and continuously improve how we work and prioritize our resources and activities.
2. We build a database that allows us to leverage AI to navigate our growing pool of experience and identify smarter ways of working.
So let’s take a closer look at what this can look like.
Real Life Is Not Black and White. It Has Many Colors
Classical project management.
Agile project management.
Hybrid project management.
I often find myself listening to debates about which methodology owns the future and which is destined to die out.
That framing is misguided. Real life cannot be neatly sorted into boxes, that’s simply a fact.
Over many decades, I’ve observed that no single true doctrine is practically workable, because there are always situations that simply don’t fit. Ignoring those situations is not a solution, the problems don’t disappear just because we look away.
So let’s try to build a model that accommodates everything that genuinely occurs in real organizational life.
To reference the pomegranate tree model: I’m talking about the pomegranates on the tree. There are many of them. They vary in size and ripeness, just as our work items do.
The pomegranate itself, however, is also a system in its own right and therefore offers a good analogy for the complete model. In the upcoming articles I will cut open the pomegranate, but for now let's stay with the fruit on the tree.
Let’s explore what can qualify as a “pomegranate.”
Projects
A classic project is defined by a fixed start, a fixed end, and a fixed result.
At its core, a project is a detailed, planned change executed according to established rules.
The outcome of a project can span many domains.
a new or modified product,
a process,
an organization,
or an infrastructure.
A wide range of change needs can be addressed through project management methods.
Projects are typically large-scale change initiatives: long-term in nature, requiring significant personnel and investment.
Features, Functions, and Product Properties
Features, functions, or product properties can be developed either within a projects or incrementally outside of them in short cycles, at smaller scale.
Like projects, Feature-, Function-, and Property Development have a defined start, end, and deliverable. Various methods apply: agile sprints, systemically controlled workflows, and others.
What all these methods share is an incremental approach: each step produces a shippable result ready for real-world use.
Unlike projects, the other methods are designed to be significantly shorter and less resource-intensive. While exceptions exist in practice, treating them separately is precisely what helps avoid scope creep and keeps them lean.
Technologies
Technologies mature like we humans, they start as babies and only reach their full potential as adults.
It begins with an idea, which is then explored and refined through research, before eventually, if it makes it that far, being incorporated into a product development effort that can reach customers.
This journey cannot be precisely planned, nor can the outcome be predicted.
There are expectations, but no guarantees.
Nevertheless, it is essential to progress through this phase, so that at the right moment, the technology is sufficiently understood to be incorporated into a product development cycle with a fixed timeline and defined deliverable.
Here too, there are plans to be executed and investments to be made. But the outcome remains uncertain for a long time.
This is a critical pillar of the NewPDP framework, to which I will dedicate further articles.
Customer Applications / Market Opportunities
Before a project can start, or before feature development begins, customer needs must be understood. These may be entirely new requirements or evolving versions of known ones.
To advance any product, the organization must know what customers need and understand the commercial potential: Are customers willing to pay for it? If so, how much?
Generating this insight requires organizational effort. Resources in the form of time, capacity, and money.
In this context, customers can also be internal ones. Internally too, new requirements and business opportunities emerge that need time to mature.
Problems
A problem exists whenever the actual state deviates acutely from the desired state.
Problems share a key characteristic: at the moment they arise, the time needed to resolve them cannot be predicted.
The target state is clear: “The problem is solved”, but the path to get there is not.
To be clear: problem-solving must follow a structured methodology, and that methodology is well known.
But the time required for
root cause analysis,
defining countermeasures,
validating their effectiveness,
and implementing them
depends on what is discovered along the way, and therefore cannot be reliably predicted upfront.
Even though the work is project-like in nature, it doesn’t meet the strict definition of a project I outlined earlier. So let’s call it what it is: problem-solving.
Processes
To work through or resolve any of the above, organizations need ways of working, know-how, and tools. These must be created, adapted, and continuously improved.
Some of this work can take the form of a project. But in many cases, it makes more sense to prioritize activities based on need or value without a fixed plan or predefined outcome.
Organizations that neglect this will face existential problems sooner or later.
The investment must be made at the right time.
People
Investment must flow not only into processes and tools, but also into people.
Whether it’s:
an individual investing time in their own development,
a team working on cohesion and collaboration,
or a manager focusing on coaching and leadership
it all takes time.
… And There Is More
I’ll stop the list here for now. I think you understand the concept.
I group all of these categories under the term ITEM.
What all ITEMS have in common: an organization, and the people within it, must invest time and money in each of them.
Please share in the comments: which categories do you find missing?
ITEM Management Is Extended Multi-Project Management
If I asked you how much time and money you personally invested in each of these ITEMs over the past few weeks. Would you know the answer?
If I asked how much time and money your team or department invested in each of these ITEMs. Would you know that answer?
I’ll be honest: for many years, I couldn’t answer those questions, and that was a source of both stress and performance gaps.
It left me feeling reactive rather than in control, and I regularly found myself realizing that important things had been left unattended, or that results weren’t available when they were needed.
Meaningful prioritization is only possible when you have a clear picture of everything that needs to be prioritized.
Multiple Projects Require Program Management
My world as a product developer consisted of development projects and series support activities.
Both had structure: projects had project plans and decision gates; series support activities had their own cadence.
Maintaining an overview of all active projects seems obvious to estimate resource needs, spot interdependencies, and handle conflicts proactively.
This is exactly what project program management addresses, a well-established method described by leading project management bodies.
And yet, despite decades of awareness, many organizations still fall short here.
It's high time to close that gap.
When I take this idea to its logical conclusion, I realize that focusing only on projects isn’t enough.
The other ITEMs also need their place in the organization’s calendar, and in every individual’s.
I therefore propose extending project program management into ITEM Management.
How to implement this operationally is something I’ll explain in dedicated articles.
But Our Team Members Are Fully Dedicated to Projects!
Congratulations! If you’ve really achieved that, those team members have a short ITEM list. That’s great, and worth striving for.
But that shouldn’t cause us to lose sight of the people who don’t have that luxury.
And when we look at the organization as a whole, the ITEM list fills up fast, and there are always people who need to keep all of it in view, ensuring that nothing critical falls through the cracks and that results are available when they’re needed.
The goal is not to maintain a long list for the sake of bureaucracy.
The goal is to create transparency, and through smart management, continuously reduce the list of active ITEMs to a manageable scope.
This is not about inventing additional overhead. It’s about capturing everything that is already being planned and considered in one shared database.
Data Is the Fuel for Efficiency
It’s widely accepted that AI can help us plan and prioritize our activities.
There are countless approaches to improving project management, simplifying project control, stabilizing project workflows, and increasing overall speed through AI.
Yet in every one of these discussions, I kept running into the same obstacle: the data foundation was too weak for AI to deliver meaningful and helpful results.
That led me to a clear conclusion:
We must start collecting the data now. Immediately.
And once that data is transparent, we can begin using it right away even before AI is operating at full potential.
In the upcoming articles I will describe in detail how this can be implemented operationally.
To do so, I will use a sample database that I created specifically for this purpose and that you can get from me.
So subscribe to my newsletter to make sure you don't miss these articles.
If you have any comments or feedback on this topic, please write them in the comments.
or send me a direct message.
We can also chat about it.
I’m looking forward to hearing from you!
If you found this article helpful, don’t forget to share it with others who might enjoy it too!