- Use diagramming to 'externalise' a problem if appropriate. This makes it easier to focus in on areas and to 'see' interactions more naturally. Also helps identify 'seams' to break out smaller pieces of work. Diagramming also works well in a group setting as a shared point of reference.
- Tackle the most poorly understood or risky elements first. In software, this could mean spiking code to explore uncertain areas to uncover complexity which might affect timelines or become a blocker later on. Prototype things in order to learn without needing to build everything out.
- Separate requirements into groups using MoSCoW - must haves, should haves, could haves, won't haves. Actively push the lower priority requirements later on the timeline (or as a later phase outside of the main project scope)
- Try not to get sucked into detail during upfront planning. It's true you'll need to work out the details anyway at some point, but without discipline you could end up taking a 'depth first' approach, and miss the wood for the trees. Domain complexity can be left to implementation time. See however the point on de-risking areas of concern.
- For team projects, consider running a session to capture risks upfront. Anything which could affect the timeline. Schedule check ins with stakeholders throughout the project. Also involve people early on from whom you may need support.
- Again for larger, or team, projects - consider keeping a decision log. Very helpful when you wonder 'why did we decide to do it that way, there was a good reason but what was it again ...'
- Break the project into milestones. A key deliverable in the real world, with a due date, for each one.
- Remember every project with any uncertainty is likely to overrun unless you bake in extra time for unforeseen problems. Trouble is, we only tend to plan for what we know about, and early planning phase is when we know the least.
- Identify external dependencies and get the ball rolling on those early on.
- For smaller (or personal) projects, keep an outlined list "Getting Things Done" style. Always have a next actionable thing noted down for each project. This makes it easier to cycle around different projects or areas with minimal context switch overhead.
Partially, also writing pseudo-code is a superpower sometimes...