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?
I’ve already discussed that project managers are a necessary addition to a development team, as well as the fact that some are overzealous, which takes its toll on the team dynamics. Today I want to discuss why lazy project managers are actually terrible and destructive additions to any development team.
They don’t respond to information requests. How many times have you contacted someone with a question and not wanted to receive a reply? I’m not sure that’s ever happened to me, because generally I ask questions with the expectation of an answer. This is no different for project managers, and in fact, the majority of their job is balancing the plates up in the air while shuffling people toward the end goal. This requires providing INFORMATION when individuals need it. An engineer, artist, designer, etc. should not have to ask twice, or even three times for an answer that is relatively easy to obtain.
They come to meetings noticeably unprepared. I’ve been to numerous meetings where everyone arrives on time, is ready to contribute and discuss, and all that is necessary is the person in charge to get things underway. In fact, the project manager has that duty. So, the meeting begins, he/she then asks what needs to get discussed. Wait a minute, shouldn’t the purpose of a meeting be to have an agenda? A plan of action? Open ended meetings tend to be rather unproductive and useless, which is why we rely upon the manager of the project to get things focused. Not knowing where people are, what they are to do, or why the meeting was being held in the first place is a huge issue with productivity in teams.
The behave reactively, rather than proactively. A sign of any truly great person is their ability to see problems ahead and act on those before they become a problem. Lazy project managers, however, sit in their cubicles and no one really knows what they’re doing with their time. The idea is based on the knowledge that they don’t go out of their way to resolve issues ahead of time. Until YOU go speak to them, the issue doesn’t exist as far as they’re concerned, and in reality, once you leave their office, it gets shoved to the back burner for some YouTube amusement.
Are unresponsive unless 1. The boss asks, or 2. you go and talk in person. Everyone is interested in maintaining their job placement for as long as it suits them. This is a fact of the working world, so of course, when the boss asks a question, the answer must be somewhat forthcoming. With non-supervisor people, however, the communication channels tend to be more lacking. In fact, sometimes, the communication becomes non-existent. This forces the coworkers to actually go to the project manager with questions because they likely will never get answered via the telephone or email.
They destroy team enthusiasm and engagement. This is less a feature of lazy project managers, and more of a symptom of having one on a team. When a project manager is performing their duties to the best extent possible, they provide a level of cohesiveness to the team that is hard to obtain any other way. This aspect is removed, however, when the project manager is lazy with respect to their duties. The ties of comradery never fully develop, and in fact, many times are reduced to merely “having to” work with your team on some project that no one cares about.
There are some things I’m missing in the above list, however, these are the most problematic issues I have seen in my time engineering. Project managers can, and I would argue MUST, be the lynch-pin in any development project. Success or failure to launch lies significantly on their shoulders, and as such, they should be treated with reverence and respect so long as they get off their asses and do it.
Mind you, more often than not, the project managers I have worked with have been proactive and successful, but those that cause problems are the ones that stick out in peoples’ minds.
What have I missed? Am I off-base? Let’s discuss in the comments!
In my prior post, I discuss some reasons and guidance on what to do if no lower level employees’ ideas get heard. Not always is it a systemic issue, however, and I would argue that more often than not, it’s YOUR ideas that don’t get heard. Continue reading “How To Get Your Ideas Heard”→
I recently read a post by John Hunter entitled, “Finding, and Keeping, Good IT People,” and couldn’t help but think it merited some additional thoughts on the subject. He makes a few main points in his post, namely: look at the hiring process, reduce your requirement count, treat existing staff well, and a good programmer is a good programmer. I’m going to expand on all of them here.
Look at the hiring process
Your hiring process is intended to filter out the large number of applicants into a small pool worthy of interview. How this process is implemented can turn good engineers off from of a job simply because it is not robust enough to handle the applicants that apply. Continue reading “Hiring and Keeping Good Engineers (part 1)”→
So now to the final discussion in my series. About Great engineers! I have been pondering this one, because, for some reason it’s the hardest to provide valuable information about. Great engineers/employees in general are hard-working, deadline-meeting, project-churning machines that bring value to your organization consistently with a smile on their faces. What could be wrong with that?! I’ll guess that nothing is wrong with that, though there is the matter of keeping them as great engineers. Lack of motivation, disinterest in doing the same ol’ thing, frustration with other engineers, and many more daily occurrences can push their productivity down. So for a manager, your job is to ensure that they are happy and able to do their duty!
Hopefully, you have already read A Manager’s Focus and An Engineer’s Focus. If not, I encourage you to do so, because the purpose of this post is to discuss why it is that engineers and managers tend to have difficulty communicating. In fact, many times, while watching communication happening during meetings, it is fascinating to realize that both are talking, thinking their point is getting across but in reality they are talking to the equivalent of a brick wall!
Engineers (of all types) are logical, analytical, and overly detail-oriented individuals. Because of this, their focus lies in the project on which they are working. Ok, everyone knows that, but the more interesting facet is that engineers see the world in a completely different way. Of course, they are fully aware of the future customer, and they are also cognizant of project requirements, but what is different, is how that information is processed.
In the world of business, you can look at required tasks several different ways. At the largest scale, you can look at how a company’s stock price fluctuates with organizational decisions, ROI, Resource management and supplier/customer relations. Each area you turn to, there are many different components which aggregate into the whole. You can keep going further down until you finally hit those workers who are doing the seemingly menial tasks that must be accomplished in order to get the answers you (the manager) need to have in order to perform your job satisfactorily.