10 Resource Planning Steps For Humans (Part 2)

Paul Dandurand

Part 2 in the “People Resource Planning” series about how to improve the project management process through people planning

In Part 1, I provided a brief overview of 10 steps for a human approach to resource planning. Now, let’s start looking at them in greater detail.

1. Identify the hats each person brings to the table

Definition: Think of the term “people roles” as people’s titles or the hats they wear, such as business analyst, architect, product manager, user-experience designer, lab technician, project sponsor, etc.

Why: This is important to avoid wasting time defining roles that cannot be filled. Remember that we’re assuming your people resource planning budget is finite or static. You have to work with what you have, and what you have could be awesome.

How: Identify what roles people have played on past and current projects. Were they successful with those roles? “Success” is not about individuals’ comfort, but more about being challenged and having the ability to flex, learn, and grow with the experience.

Think about a couple of words that best describe the hat someone would wear to get this work done. Have a fun half-hour workshop with your team members to figure this out, with each person throwing sticky notes on a board describing the hats they have worn. If you can’t herd the cats, then just enter a person’s name as a placeholder for the next step and change it later.

Agile: For your hybrid projects that have both waterfall and agile/scrum phases, consider agile roles, such as product manager, scrum master, etc. Let’s assume you don’t have enough agile-experienced people for all of your hybrid projects. In this case, ask those with the experience to establish some best practice steps for how to prioritize requirements for a time-blocked sprint with the agile team, facilitate daily scrums, establish continuous deployment DevOps processes, etc. These steps should be documented with enough detail to help novice agile leads get up to speed. Then, when it’s time to review agile hats, new people can wear them well.

2. Define people roles in your project process

Why: Your planning timelines are better serviced when your future project task role assignments are aligned with your people’s skills, experience, and potential.

How: Start with key tasks that drive critical milestones. As you review each task, think about its purpose and what needs to get done. Think about who has done these tasks on previous projects, note that person’s past role with this task, or define a new role that best fits the work. Since you can’t wave the magic budget wand and hire new people, stick with your existing people’s experiences as identified in the step above. This takes time, but you will get faster with practice. Ask your team members and project stakeholders what expertise is needed for key tasks, and label them as project hats.

Agile: For your agile part of your project, you can still define roles with the tasks to better present data for any roles-based timeline reporting you may build or have auto-populated with a project and process management tool. However, many agile tasks are defined on the fly. If roles are not defined with tasks, keep them in task buckets (deliverable lists), task tags, or scrum board columns. For the agile hybrid project driven by your framework or methodology list of tasks, ensure roles are well-defined for repeatable projects.

3. Determine needs for dependencies

Why: Project task dependencies will affect how work is structured across a project and how it will connect a set of individual workloads against a series of dates.

How: You can skip this step if your project is super small, but give it a try. Start with a critical path with key milestone deliverables. Those are your most important set of tasks or packages of work that need to be done and delivered to someone or something for the next major phase toward completing your project. Link them together as dependencies so you know what tasks depend on previous tasks. Once you have linked critical tasks, then link the supporting tasks.

Avoid overloading links, e.g, link no more than one predecessor for each task. Overkill adds confusion for humans. If you have a project tool, linking tasks with dependencies should be easy. If you’re using a spreadsheet without linking options, then do your best to list them in sequential order.

Agile: You most likely will not define dependencies for the agile part of the project, such as the scrum boards. The reason is that these are usually loaded with requirements on the fly, and re-ordering priorities happens very frequently. Focus your dependencies’ links for the pre-agile and post-agile phases of your project, and skip the agile part except for special tasks.

4. Assign draft project target dates

Why: Having dates is really the only way to get a timeline picture.

How: Like when defining task roles, start with important tasks and give them end dates. Your project’s business needs may drive target delivery dates. If all you have is the date the completed project is due, then that’s your starting point. Some people work backward and some forward. Either way, it’s a nudging game. If you’re using a tool with dependencies, then use its date-propagation capabilities. Don’t worry yet about getting exact target dates, since some may change to accommodate people’s availability.

Like estimating directions with a compass in the woods, you get better over time with practice. Engage your sponsors and stakeholders to provide feedback as you set the path for the dates, and look for milestones that have date flexibility. Dates and their durations will most likely flex based on people’s experience and their availability if they’re working across multiple projects.

Agile: In the agile part of a hybrid project, tasks will not get due dates until they’re identified and selected for the next sprint. Instead of task dates, focus on keeping a constant schedule for continuous deployment with whatever set of tasks you and your team decide can be completed during that sprint. This is fluid and very collaborative.

In Part 3 of this weekly series, we’ll look at how to find the right people for specific roles, make adjustments, and obtain consensus.


Paul Dandurand

About Paul Dandurand

Paul Dandurand is the founder and CEO of PieMatrix, a visual project management application company. Paul has a background in starting and growing companies. Prior to PieMatrix, he was co-founder of FocusFrame, where he wore multiple hats, including those of co-president and director. He helped position FocusFrame as the market leader with process methodology differentiation. FocusFrame was sold to Hexaware in 2006. Previously, he was a management consulting manager at Ernst & Young (now Capgemini) in San Francisco and Siebel Systems in Amsterdam. Paul enjoys photography, skiing, and watching independent films. He earned a B.A. degree in Economics from the University of California at Berkeley.