Projects: the project comes in "on time and under budget" or is "late", but the work is fixed.
Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups.
You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes!
I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar.
Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work.
A project tries to fix both work and date, which doesn't work and is rarely on time.
A time box fixes the date, not the work. Iterative delivery always hits the date and generally works.
---
Using your weekend desk example:
You could want a wood inlay desk.
For the "job to be done", the desk has to support you doing work.
In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend.
If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk.
The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk.
If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid.
Certainly, doing the inlay after assembly will require more effort.
So then ask yourself, was the deadline real, or was the inlay requirement real?
If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real.
---
What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements.
But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements.
Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead!
You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient.
If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.
It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
The problem is the professional definition of project, which comes with project management practices and preconceptions.
Those are generally harmful, because they try to manage or control both time and resources needed to deliver unknowns in advance of an inherently discovery-based process that results in (re-)scoping as you learn:
https://en.wikipedia.org/wiki/Project_management_triangle
> It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
I posit it's not just "prefer", it's reality. That all "projects" are in fact "fixed time, variable scope" in hindsight. In other words, "it takes as long as it takes" to uncover and ship a minimum viable scope for the "job to be done".
As an entrepreneur, it's preferable to create a workplace that acknowledges that reality up front, and designs the "way of working" for it.
As an engineer, it's preferable, as you note, to join one.
---
Some more musings:
The OP's post says work stops being fun. A key reason why is all the unfortunate beliefs, management overhead, and recrimination for practices trying to override reality and failing.
Small startups don't care. The cost of 5 people being wrong seems irrelevant compared to charging at the problem and getting it done, or finding out it doesn't work so you can pivot. How many "Show HN" are after a pivot? How many "Launch HN" for that matter?
Enterprises care. The cost of 500, or 5000, building the "wrong thing" seems unacceptable (even if less cost per person!), so big companies keep piling on layers of risk management that delay getting in touch with reality.
One reason they do this is the value of the outcome isn't clear. Perhaps it's political, perhaps it's make-work to keep someone's department full sized, perhaps it's a failure of imagination. So they develop scar tissue about shipping multi-year boondoggles that deliver no value. The problem was, it wasn't valuable in the first place, and if they'd just tried it out in the small and iterated, they'd have learned with fewer man-hours than all the planning.
For a great take on this, see Tom DeMarco (author of Peopleware) rethinking his entire stance on projects after 50 years(!) trying to tell people how to project-manage better:
https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...
He even throws in the towel on estimation with the now famous phrase, "All projects that finish late have this one thing in common: they started late."
He effectively accepts reality: the needful is the needful, the value is the value, so if it's valuable you'll do what you have to do, just start already and get it done.
What I've found is, a big enterprise can understand this. The CEO can hold his business leaders accountable to telling the value that an effort should generate, the CFO can "venture capital" an appropriately sized investment in a fixed capacity team, and the team can focus to deliver value -- or offer a pivot -- before they run out of funding and can't raise another round.
If they're shipping well, and getting market traction, the business leader looks good, the CEO is happy, and the CFO can continue to invest. One neat thing with this is the remarkable "budget" predictability that comes with investing in teams instead of in projects. Control your capacity and focus, you'll always hit your expense numbers, with net higher RoE as a nice side effect. So not only are customers getting value early, boards and shareholders are impressed with "hitting the numbers".
So this solves that iron triangle.
By continually focusing in on shipping what brings high RoE, you can let "the business" pick any arbitrary amount of time (quarterly? annually?) to announce sets of new features as releases. You can keep teams steady and employed delivering instead of wastefully scaling up then laying off as if tacit knowledge loss didn't have a cost.
And people can feel good about building value they can see as they work.