Thursday, January 16, 2014

Project Planning Software

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).
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.