Get Everything Done

Two concepts that appear in SoPP and that are discussed in general on this site are over commitment and "little and often". What's the thinking on delivery cadence on multiple "big" and long projects?

For example, chapter 25 in SoPP talks about moving forward, and specifically talks about taking action on projects and keeping them moving forward, rather than halting work on them. But at the same time, there's the issue of over commitment potentially resulting in too little effort put on any one single thing, resulting in nothing actually getting done.

Maybe this is addressed further on in the book, but let's say you have Project A and Project B. Both of these are long, serious products. Project A is more immediately critical, and potentially feeds data into Project B, but both are "essential commitments". They both need to get done, and they need to be delivered as rapidly and with as much quality as possible. There are two options:

1. Work on Project A first, and then after Project A is done, start work on Project B.
2. Work on Project A and B at the same time, and deliver both whenever they are ready.

It would seem to me that doing Project A first would be better because you are more likely to get Project A done well and faster by focusing on completing it first, as you'll have more bandwidth to handle A as well as more focus on A without the distractions and switching overheads of moving to B.

However, this essentially means "hibernating" Project B, and putting it on the equivalent of a Somday list, or at the very least, a differed list. It is still a commitment, and something that needs to be done, at least in the current scheme of things, but no movement will be taken on it until Project A is done. This seems to violate the "little and often" principle, as well as the Ch. 25 concept of forward motion.

On the other hand, working on both at the same time will undoubtedly reduce the time to delivery of A, which is more time critical than B.

If we scale up, I can see many future projects that are things that "need to be done" and in some sense represent commitments, but it's not clear to me that they all need to happen at the same time, and it also seems to me that applying "little and often" to starting a whole bunch of projects, each of which will only receive a little time, is a bad application of the "little and often" principle. So, wouldn't it be better to take some of these and essentially decide, intentionally, that we aren't going to do any work on those right now, even if we are committed to making them happen, in order to maximize our throughput and deliver earlier on project A, at which point we can then dedicate more resources to Project B, and then C, and so forth?

I guess the question, at the root of it, is that for long running projects that are all important to get done, is it general to run them in sequence, one after the other, or to do them all at once, even though that will extend the delivery dates on any one single project, and increase the amount of time spent on all of them? Is there another approach to this?

Then there's another case, where I have a project A' that's a long running project, and we could potentially break it down into a bunch of less long finite projects, but there will always need to be some forward movement on these, but the cadence of that movement isn't clear. So, given the ever present need to move on A' at some rate within the year, how do we commit and schedule other finite projects B and C? Do we break down A' into small enough finite projects that we do A'[1] and then Project B and then A'[2] and then Project C, or do we instead just keep constant time spent on A' all the time, and simultaneously spend time on Project B and C in some order or both at the same time?

Maybe this depends on the size of the project? For example, does the answer change if the length of these projects is a week long versus a month versus 6 months? Is it more about what can be delivered when? What are the factors at play here? For example, let's say Project A can be broken down into 1 week or 1 month long finite projects, but the real big value only really can be reached when all those projects are finally together in the complete Project A, and project B could be similarly broken down, but the finite projects produce even less value on their own, so that you really do need all of Project B done before it's "good enough". Each can be artificially shrunk into smaller projects, with A being capable of even being delivered in smaller chunks and B really needing to be delivered as a single unit. Or maybe some other combination of this? How does that affect the choice?

What is the best way to deliver the most value quickly and over time?

Thanks! I somehow missed that comment in my search for answers.