As a manager, one of your jobs is figuring out how you can score the best projects for your team. After all, the best team wins in everything! That’s not true, of course, but it IS the implicit assumption that most people run by. After all, the best teams get the biggest budgets, the best and highest profile projects, and the best rewards for completing those projects.
Alas, you must take the projects that your manager dictates, though this isn’t really a problem. After all, someone is paying you to do the work that needs to be done, and they, like you, are always looking for the optimal way to spread their work over their resources.
So here you sit, looking at a list of tasks that must be completed by your team, and you are wondering where to start. Here is my outline of the steps you should take to get your priorities straight and look AWESOME to your superiors:
- First and foremost are the deadlines. Personally, while I despise day planners and do all of my scheduling electronically, I still print out hard calendars when I have to arrange tasks in my year like a puzzle (this happened a month or so ago when my partner and I realized that we had a hundred things to do and no idea when we could do them). So sit down and put your deadlines on the calendar. Don’t worry yet about the work required, just put down the hard-fast deadlines. If one deadline is soft, put a mark for the desired completion date and give yourself a wavy line to indicate that it can possible go X days beyond.
- Now that everything’s on the calendar, the next step is ponder the tasks assigned to your team. How large are they? Field issues may be a line of code changed, back through quality assurance, and out the door. A large project may be nine months long and require six people to complete in time. Likely, if you’re managing your own engineers, you have had experience as one beforehand (I would hope), so use that knowledge and gauge the length of time required for each project. If you can’t, leave it blank.
- Once everything’s “estimated”, you are on to the next task. I put the quotes around estimated, because the reality is that once you have been in management for some length of time, your ability to accurately estimate development time is somewhat muted. So, this step is actually starting the estimation process. First, set up a meeting with your engineers and tell them about the projects. By sharing the work expectations for the year, you are sharing that responsibility with them, and letting them know that your decision are not arbitrary. Leave everyone with a copy of the task list and assign someone to estimate the length of each project.
- Now, you can setup a follow-up meeting, or you can merely have your engineers reply to your inquiry via e-mail. Either way, you must receive a response so that you can move on to comparing your estimates with your engineer’s. If they don’t match by some acceptable range of error, you need to discuss why they are so different with the engineer. Both of you should indicate what assumptions you were making and where the time came from. Mind you, a full-on Gantt chart is not necessary at this phase, but a good guess requires some thought.
- Now that everyone is in agreement about timelines, your task becomes to look at the priority of the projects. Some, must be ready on-time (or before), while others are on the back burner. There are also hot projects. At my current company, we have varying degrees (though no one really knows which supersede which), from “hot” to “volcano hot” to “nuclear blast hot” and several more in between. Field issues generally take highest priority, but there are some customers that make unrealistic demands that you MUST meet. If there is any doubt as to the actual priority of the project, ask your manager and find out.
- Once priorities are determined, connect your estimates with your priorities with your calendar of deadlines. Top projects generally are due first, and so, allocate them immediately following the current tasks of your engineers. For the rest, focus on the priorities, and place the lesser ones further down.
- Last step (before deploying) is to determine which engineers should get which tasks. You know your engineers and their capabilities, so do your best to place each project with care, because the engineer who gets a task they aren’t good at, likely will take longer and do a poorer job of implementation than another who loves that type of work. Mind you, you’re not playing favorites here. You’re simply playing to each of your team’s strengths.
Once you have the plan, you must deploy the plan. I prefer transparency, as do most people I interact with. No surprises there, and if there are any changes, notify the team. Have a meeting and go over the plan and what your thoughts are. Welcome changes if they are forthcoming, but don’t let the team dominate and choose their own tasks. If you do, very likely you have an engineer who is shy and won’t speak up about wanting to do something.
What other helpful hints do you have to help with project prioritization? Are there any steps I left out?