I think project planning software can be overkill in a lot of circumstances. Software like MS Project is great at looking at things to spot critical paths and temporal dependencies, but I think it's most useful as part of planning cycles when leadership is dedicating a lot of time to it. When I've been part of teams that tried to stick with it for any period of time, it always ended up taking more time to manage and update the visualization than seemed productive in the operations stages of the project. Especially when continuing to account for changes and project drag (hopefully created by timely opportunities rather than unexpected difficulties!).
I'm a fan of the recurring meeting and discussion item spreadsheet. Google docs is great for this. In meetings with key leadership we typically identify ways to be concurrent and
complementary rather than sequential, just getting together and talking about things on our minds is important. People are pretty good at identifying the points of friction and often have an intuitive feeling for what's going to cause a problem before the problem happens. If you hide those discussions about the important things behind useless details or re-iteration of milestones and goals, you greatly reduce your chances of getting to those goals on time. The problem pops up anyway, like a horror movie monster, after the chance to kill it early has passed. Here's an xkcd comic to illustrate my point.
The most important thing we do is get
together to find opportunities to identify and rectify problems fast. Having a list of items we want to discuss at that meeting allows
everybody to voice their concerns/ideas. How the spreadsheet (or presentation or document) looks doesn't drastically change how I prepare
for it. It's the difference of "try to understand it all every time we
get together" versus "let's talk about the important stuff, because we
all have a basic understanding of the whole plan". We can aim for the
former, especially when taking on new team members, but I suspect that projects that tend
toward the latter in out-of-planning-cycle phases are more efficient.
I'm a planning nerd, having had this stuff beaten into me by USMC
Infantry Battalion Commanders I've worked with in the past. So sometimes I skim over the Marine Corps Planning Process (like a nervous survival instinct reflex). http://www.mca-marines.org/files/MCWP%205-1%20MCPP.pdf
It's a neat read. The first few pages are most useful, although in
practice I've found them to somewhat be aspirational. The later parts go
into how to neat nuances like identifying "trusted local people to
resolve problems" at remote villages (that guy at the other organization that knows how to reset your password or get you in the server room). Indicators and measures of success (we talk about this at
every single meeting I've ever been to). It's a good formal capture of important
stuff that really good program managers end up doing
anyway (and usually learned about the hard way). Of course many parts
don't apply! And it is a war manual, so reader beware. Please ignore all the
parts about the targeting enemy personnel, only good guys here! Let's all be dogecoin friendly to each other. Hostile work environments suck.