(Definition: Tactical management is management of -available- means to an objective.)
The “micromanaging” topic always begs the question, “how often should tactical managers check in on the progress of a project or task set?” Any intervention by a manager (whatever the form) generally amounts to: Communicate, Coordinate and Re-deploy resources as necessary. You change assignments and reallocate available resources.
To find a balance between time used for talking about work and time actually working, I generally follow the following guideline:
I ask, how many opportunities for action should I budget in order to make project adjustments? Of course, you want to place as much trust in the team as possible, and not frustrate them by signaling a too frequent change of priority and direction.
So, ask yourself, what is the “pace” of the project? If an objective is 16 weeks in the future, can I adapt to any issues and unforeseen surprises if I review monthly? That gives me only three opportunities to act. Given what I know about my team and our objective does that seem enough? Can you count on your teams to “send up a flare” if they encounter un-foreseen issues?
What about management in a crisis, where we are trying to contain a serious problem in hours, and not days? How often is too often to check status?
Let’s explore the example of the 16-week project. After 4 weeks and 1 review, one fourth of the budgeted resources have been spent and there are only two remaining reviews before deliverables.
With only three fourths of the time and money left, are the remaining resources (if judiciously redeployed) going to be sufficient to bring things back on track? In most scenarios, this seems a little tight. 6-12 checkpoints seem like a better minimum for most projects, depending on the team of course.
Of course, tactical management of -processes- is a different topic, and totally different approaches are needed. Many technology project managers use an iterative development process and a pace established by weekly or bi-weekly “sprints”.
Guided by a rendering, or “wireframe”, each iteration is intended to produce an incremental deliverable which will either converge on a finished product or continually improve an existing one. A week or two is typically long enough to add and test a couple of features, and short enough to keep the scope of very abstract work conceptually manageable.
