What To Do Before Assigning Team Members

“We need Todd on this project. He’s critical!”

“What’s Todd’s role? What other roles do we need? Does Todd have the tools he needs?”

“I don’t know, but Todd needs to be on this. He’s on all projects.”

There was a couple problems with this conversation. First, Todd (who was a senior developer) was assigned to all projects. Second, not his role, or any others, were clearly defined. We also didn’t have a list of all the tools needed for this project.

Every question was met with “Well, Todd needs to be on this!” You know what? Todd probably DOES need to be on the project, but let’s take a deeper look before we over-commit him to yet another effort.

After you have worked with the sponsor and necessary stakeholders on clearly defining scope and what “done” looks like, it’s time to start setting your sites on the team who will actually do the work.

There are two steps I take when starting to put a team together; identify the roles and tools required.

Identifying roles. We naturally have a tendency to name people when starting a project. Unless you’re new or work at a large organization, chances are you have team members identified in your mind you want. As difficult as it is, resist the temptation!

Instead, look at the roles you’ll need on the project separate from the people who’ll actually do the work. Not sure all the roles you need? Yeah, happens to me all the time. Look at previous, similar projects. What roles did they have? Also, ask other project managers or domain experts what roles may be needed. For example, in a technology project I’ll find a senior IT person, buy them coffee and ask what roles they think I should have. Then, document them.

Identifying tools. If I’m building a shed, I’ll need items like a hammer, saw, screw driver, screws, nails and a level. But if I’m missing a tape measure, I’m going to get stuck pretty quick.

Same goes for your project. As you put your team together, take a look at the tools required. Software licenses. Manufacturing equipment. Transportation for materials. It could be anything that when your team starts work, can stop progress quickly. Do your best to identify those up front. As with identifying roles, if you don’t know what’s needed up front, ask someone!

In both identifying roles and tools, you may get to a point where you say “Hey, we don’t have that person” or “We let that software expire”. Maybe your whole software development team is already 110% allocated and can’t take on any more. Identify and document these gaps. How will you fill them? In the instance of personnel, do you hire or engage with staff augmentation? How many software licenses are needed? Rent or buy equipment? All these gaps can be reviewed and filled. Be sure to engage the sponsor (and maybe accounting) in the discussion.

Once the roles and tools are identified and gaps filled, it’s time to add names! Create a simple table of names, roles and any tools the person will use and display it at the kickoff. Team members will appreciate how their role fits into the bigger picture.

Before you get some people together and say “Go forth and conquer this initiative!!”, take the time to identify the roles first, people second. Then, ensure you have the tools they need to be successful. Good luck!