Making a Battle Plan

by Walt Stoneburner
"Grunts answer 'how,' management answers 'what.'"

Formulating a Battle Plan

Changing gears from developer to lead can be a bit disconcerning at first. No longer are you responsible for your own actions and performance, but also for those people under you.

True, any one task you might be able to do better or faster, but a team with proper leadership should be able to excel past your best output by sheer means of concurrency. Therefore, trust them, communicate with them, and when there won't be impact to the schedule, allow them to fail and learn from those mistakes.

Your task in leading a project should boil down to several steps:

  1. Ask "What's the problem we're trying to solve?" and know what the minimal definition of success is.
  2. Find out what you know already. What information, tools, and people are currently at your disposal.
  3. Find out what you don't know.
  4. Come up with a high-level to-do list and determine known dependencies.
  5. Priortize the list.
  6. See what constraints exist in time, staffing, budget, and tools.
  7. Sell the idea to the proper target audience.
  8. Allocate the staff and get their buy-in.
  9. Start the work, following your plan.
  10. Continually look for risks that could cause failure, assign probabilities of them actually happening, determine what you could do to mitigate them accordingly.
  11. Handle contigencies, making minor course corrections as needed. Update the plan as you get more detail.
  12. Get status reports from your people without being intrusive. Pass that information up the chain along with praise. In short, communicate up and down.
  13. Always be able to answer "what's the next step after today?"
Your job is to figure out what needs to be done within the people, money, time, and resources you have.

If you can't make it happen, then change the rules. Tell sales to go back and reset the client's expectations with what you can deliver. If management wants it all, give them a list with level of effort, dependencies, and time tables; make them prioritize.

Lastly, if something dreadfully starts to go wrong, ask for help before it turns into a crisis. Ask how you could have spotted it earlier, why it slipped through the cracks, and how best to deal with the situation.

If you have corrections, ideas you'd like to contribute for credit here, spotted a dead link, or would like to suggest a useful resource, please feel free to send them to the author.

SlingCode Search Results About     Articles     Links     Search Tips