Complexity rises at an exponential rate to the size of a project. This applies whether your project is business or personal in nature.
The corollary to that is that the risk of failure (of any scale) also rises at an exponential rate to complexity. And when you apply the first rule to the corollary, this means that the odds of something going wrong on a large project are near certain.
There’s also another corollary, that time to work on even the basic tasks increases with complexity. (How fast sometimes depends.) Which means that a big project is almost certainly late and buggy.
The conclusion is obvious: keep your projects small, with very short lead times. You are more likely to deliver on-time, and with less mistakes.
Please note that big projects are not the same as big goals. You can have big goals — but it’s going to take you a long chain of small projects to get to that goal.
This will also allow you to change course relatively quickly in case your goals change. And the likelihood of that also rises with the size of your goals.
An added side benefits of having a chain of small goals is that it teaches you to build a system. Because inevitably you’ll find yourself doing the same set of tasks from one small project to another.
Because you’re working towards your goals in a chain of small projects, make sure the links are approximately the same size, whether in terms of money or time.
For example, many companies that implement Agile software often have a two week scrum cycle. It’s long enough to get any meaningful work done, but also short enough to limit time delays and complexity bloat.