People Management: Internal Workflow

This article addresses several topics:

• Internal workflow
  • Day to day
  • Projects

Internal Workflow

A people management team may be a single person within a small organization, a small group or department within a medium-sized organization, and a large group or collection of teams within a large organization. In many organizations the people management team is still being called the human resources (HR) team or the HR department, although some organizations use terms such as Talent Management team or even People Operations team.

Figure 1 depicts the high-level workflow for a people management team. A customer of the team, perhaps an employee somewhere in your organization asking for career guidance or a manager asking for help with their staff, submits a request to the team. This request is triaged. Straightforward requests that you address on a regular basis are handled via your day-to-day workflow. Requests that are unusual, perhaps because they require a large effort to address or because they are the result of a unique event for your organization, are either handled via a project lifecycle or are organized into smaller pieces of work and handled by your day-to-day workflow.

Internal Workflow: Day-to-Day (Continuous Flow)

We find that a lean approach where the work is performed in continuous manner is the most appropriate for the day-to-day work of people management teams. The fundamental idea is that people management professionals face a constant stream of requests for help, each of which should be prioritized and worked appropriately. The lean lifecycle of Figure 2 addresses this situation well.

Let’s work through Figure 2 one aspect at a time:

• New requests. Other teams within your organization will make requests of a people management team on a regular basis. Examples of new requests may include onboarding someone, offboarding someone, helping someone identify a mentor, addressing behavioural issues of an employee, consulting with a team or manager to help them to understand people management issues surrounding a decision, executing on a communication strategy, addressing a minor regulatory change, and many more. Sometimes the work for a project (see below) comes in as a large batch of requests. Each new request captured as a work item and put into the work item pool for the team.
• Work items. The work items for the team are often maintained via a Kanban board. For a team working at the same location this is very likely sticky notes on a whiteboard or wall that is easily accessible by the team. For a team that is geographically distributed it very likely be a digital tool such as Jile or Trello. The aim is for the team to self organize and manage their own work.
• Prioritize the work. Someone within the team, or collaboratively by the team itself, will need to prioritize the work items. On a software development team there is often someone in the role of Product Owner who would do this work. On a People Management team this role typically doesn’t exist, so this responsibility tends to fall either on the Team Lead/Manager. Prioritization is typically performed on a just-in-time (JIT) basis when the work is pulled into a team, although it can be done any time at the discretion of the person responsible. The more frequent that new requests for work come in, the greater the need to prioritize JIT.
• Pulling work into the team. The team pulls a single work item into their process when they have the capacity to do more work. You want to pull in the highest-priority work that can be performed by the person(s) with the ability to do that sort of work.
• Performing work. The team, or typically a subset of the team, performs the work to be done to fulfill the given work item.
• Obtain feedback. As the work progresses the people doing it should obtain feedback from others, in particular the person(s) from which the request came from, to ensure that they are on the right track. Feedback can come from informal demonstrations (“hey, can you come look at this”), formal demonstrations, requests for feedback, reviews, and so on.
• Coordinate. The team should regularly coordinate the work that they are doing. A common practice is to have a short (10-15 minute) huddle/stand-up meeting each day to do so, although we’ve seen teams coordinate twice a day and other teams as little as once a week – we find daily to be effective in most situations. During these coordination sessions the team will typically discuss their priorities for the day, their expected capacity to do work that day, and any bottlenecks they foresee or are currently experiencing. Each team will discover a coordination strategy that works for them – when to hold the sessions, what to discuss in them, and most importantly how to keep them short and focussed.
• Replenishment sessions. This is a working session where team members identify work that they believe should be performed. This may be to address team-health issues (perhaps to receive training or have an team-building exercise), to address long-term strategic goals, or to run experiments with new ways of working (WoW) amongst other things.
• Finish. When a work item is complete the appropriate customer(s) of that work item are notified and the team now has capacity to pull more work in.

Internal Workflow: Projects

A project is a piece of planned work or activity that is performed over a period of time to achieve a particular outcome. Projects are large pieces of work, typically taking many days or weeks to accomplish, that require a significant (for your team/organization) budget. Common projects that a people management team may experience:

• Review and rework of organizational policies due to regulatory changes.
• A layoff/downsizing event.
• An acquisition/large onboarding event.
• Annual reviews (yes, this is a questionable practice but many organizations still do this).
• Organizing a hackathon or college recruiting event.
• Large learning events such as conferences or team-building exercises.

Figure 3 depicts an agile project lifecycle that a people management team may choose to follow to implement a project. This lifecycle is based on the Scrum method and has been extended to address the full lifecycle from beginning to end.

Let’s work through Figure 3 one aspect at a time:

1. Initial vision and funding. Someone within your organization will identify this new project, the outcomes they would like to achieve from it, and initial funding to do the detailed inception work to get it going.
2. Organizational roadmaps and guidance. Your organization very likely has guidance (standards, principles, guidelines, …) that it expects teams to follow as well as business roadmaps that your team should work towards. These things should be known to to team and will guide and constrain the decisions that you make.
3. Project inception/initiation. This should be a short period of time, typically hours or days. The aim is to perform fundamental project initiation activities such as putting the project team together, identify and understand what work needs to be performed, and plan how you intend to do the work. You want to do just enough organizational work so that your project will be successful. For large or complex projects you may find that you want to have an executive review of your strategy before the rest of the effort receives funding.
4. Work backlog. The backlog will first be identified during Inception but then allowed to evolve over time based on feedback and evolving needs. It is very common, and should be expected, that your understanding of what work needs to be performed will evolve as the project progresses. The work backlog is typically ordered by business value so that your team will focus on the most valuable work at all times. It is also common to consider dependencies between work items as well – sometimes if you do X first then Y and Z are much easier to perform.
5. Iterations/sprints. We have found that a one-week sprint tends to work best for typical people management projects. At the beginning of the sprint the team identifies the work the believe they can complete during that period, they plan what they need to do and how they’re do it, and then they do it.
6. Iteration/sprint planning. At the beginning of each sprint the team gets together, they identify the work items they believe they can accomplish during the sprint and they collaboratively identify what needs to be done and who will do it. Agile teams are self organizing in that the people doing the work are the ones who plan the work – the manager or team lead may facilitate this planning work but they don’t tell people what to do. This is an important nuance that is critical for agile culture.
7. Daily work. People on the team collaborate to accomplish the work. Hopefully team members are able to work with the customer, or at least someone who can fairly represent the customer, so that they can get input into their work to ensure that what they’re doing reflects the actual needs of the customer.
8. Iteration/sprint wrap up. At the end of each sprint the team should seek feedback on what they have done, which is particularly important when they have not had access to their customer(s) earlier in the sprint. This feedback session is often a “show and tell” or a demonstration. The team should also consider taking some time to reflect on how well they’ve been working together so as to identify potential improvements.
9. New ideas. Customers/stakeholders will often generate new ideas for your team when they’re given the opportunity to see what you’ve done. These ideas can come in at any time although it is common to generate ideas during demo/feedback sessions.
10. Transition. Once the work is complete, or at least a valuable portion of the work is complete, it should be delivered or transitioned to the customers.

We find that an agile approach tends to work best for most business-related projects due to the regular cadence provided by iterations/sprints. Having said that, there is nothing wrong with taking a lean approach instead if your team is more comfortable with that. See Figure 4 for this sort of lifecycle. However, in practice we’ve found that when a people management team prefers a lean project approach over an agile one the more common strategy is to simply organize the project work into a collection of tasks and then feed it into your normal day-to-day workflow.