February 13, 2026

Volume 04 - Issue 06

Feb 13, 2026

This week I’m loving

This week’s love goes out to Jesus Romero for a fun LinkedIn post in honor of Valentine’s Day about project manager love languages. He points out that if our love language is a mismatch to our stakeholder’s expectations then we can experience misalignment and disruption.

Image credit: Jesus Romero - LinkedIn

I think I would add a few things to this list.

Speaking in Stoplights. The love language of risk. “This project is about to run a yellow. I think we should…”

Acts of Advice. The love language of mentorship. “If I was in your shoes I’d…”

Process Gardening. The love language of continuous learning. “What I see going off the rails here is…”

Which love language is your favorite?

What would you add?

From the Practice

This week’s Practice spotlight shines on a great write up by Joshua Barnes one of the creators of Disciplined Agile that discusses something many project managers overlook: whether a project can be broken apart into smaller pieces. For those of you not familiar with Disciplined Agile, this article may be a tad unapproachable, but the message is important, so I’ll simplify it here.

Joshua points to a question we might all want to be asking: “Are your projects too big to succeed?”

Technical project managers will be familiar with the idea of breaking down work into smaller pieces or slimmer slices but we typically apply this concept only at the task level. Joshua asks, should we also apply this at the project level?

You may ask, what is the advantage of breaking a large project into smaller projects?

Joshua notes several important considerations:

Reduced dependencies
Exposed assumptions
Earlier value delivery

And most importantly, in my opinion, earlier value intelligence (i.e. if we deliver earlier we can learn whether we have the right bet earlier).

Further, this also reduces initial investment and the ROI (Return on Investment) risk, and when we learn early about a “first step” on our planned path, we can possibly avoid wasting the rest of the investment entirely!

…traditional project scoping, tied to annual funding cycles, produces bloated, mismatched packages of unrelated features. Stakeholders optimize for budget protection, not for flow or customer outcomes. The result is a scope document that looks unified but is actually a collection of loosely related needs, features, constraints, and assumptions bundled together for funding convenience.

So how can we slice and dice a large project?

Joshua suggests a simple approach.

Map all the known requirements into a single visual workspace.
Group these requirements based on natural patterns such as being related to the same persona, workflow, or outcome.
Look for a group that is well understood, can be estimated, addresses priorities, and makes sense in a high-level sequence toward the final desired outcome.
Scope this group as a project.

You can repeat this process for other groupings and also examine which things depend on each other and which things may be able to be executed simultaneously. This can fundamentally change the organization of our resources as well.

By decomposing projects into increments and recombining them based on real dependencies, organizations create something more valuable than a better project plan. They create evidence. Evidence that smaller batches reduce risk. Evidence that visible dependencies prevent late-stage surprises. Evidence that value-sequenced delivery produces better outcomes than politically sequenced delivery.

An interesting read

This week’s interesting read is an article by Maarten Dalmijn that talks about something I teach in many organizations I work with: the advantage of PULL planning vs PUSH planning.

Like Maarten, I’ve seen many companies take what we now view as a “traditional” approach to planning that takes into account things like holidays, team size, resource allocations, historical velocity, and sometimes various complex simulations such as Monte Carlo experiments. My chief concern with these efforts is that they waste a ton of time for essentially zero benefit.

Maarten draws the analogy of this effort to the myth of Sisyphus. If you don’t know this story, read about it here.

We’re wasting our time polishing spreadsheets, improving estimates and perfecting fancy capacity calculations, just to PUSH a big boulder up a hill that keeps rolling back.

If you’ve got a fancy spreadsheet for velocity forecasting to plan your work, then you’re just like Sisyphus: you’re PUSHING rocks up-hill and you will never reach the summit.

The biggest problem with this approach is it only works if your forecasts are accurate and your forecasted capacity exceeds the required effort. At the start, we use estimated effort to represent required effort, and I hope that you can intuitively see what will be wrong with that substitution. If the required effort exceeds the estimated capacity - which it likely will since someone always gets sick; then we simply run out of capacity for the required effort and cannot complete the deliverables in the time planned. The boulder, rolls back down the hill. Worse still, likely your organization did something cray cray like plan the whole year of work, so when the first boulder rolls back, not only is that work not finished, but now it has put every other work package at risk as well. And… like Sisyphus, you are now in an eternity of never getting the boulder to the top.

My mantra I give to companies struggling with this problem is:

We need to shift our mindset from allocating resources to work; to allocating work to resources.

When we make this shift our approach is informed not by theoretical capacity but by actual capacity.

What matters is how much capacity you have and how much work it really takes…You’re pulling more work as more capacity becomes available based on THE REALITY OF THE WORK.

Now the typical reaction to this shift is expression of worry about how we will know when we will achieve the ideas we set out to deliver. Most businesses have stakeholders to report to and accountability to customers that drive this panic.

And here’s the answer: have clear priorities that define what is “Must Do” vs things we hope to be able to accomplish. You can take this all the way to a full MoSCoW framework if you want, but at a minimum, we need to know the non-negotiables.

Then, we focus the team on those “Must-Do” items and the trade off is: when real effort exceeds what we expect, some of the “nice-to-have” items fall by the wayside. As the team focuses on work, and accomplishing it within the effort required instead of within an artificial, and wrong estimate, of the work required — the team also accomplishes greater productivity because their stress and burnout trying to achieve artificial targets is reduced. If you implement a properly prioritized PUSH system you should actually improve your delivery, not reduce it.

And the ultimate bonus? You get all that time back that you waste on those perfect spreadsheets for resource allocation and all the simulations that built them.

Let the reality of the work dictate your planning. PULL work instead of PUSH.

PULL keeps your boots on the ground and allows you to get a good feeling for the true size of the boulder you’re facing.