Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Information Technology, Resource Management
Resource management strategy for shift to Delivery Teams
Hi, I work in an IT department and we are moving toward a delivery team / product/service structure. The delivery teams will be responsible for day-to-day operations as well as project work. The goal is to address the operations work in an agile way e.g. backlog, sprints; but project delivery will remain hybrid or waterfall given the industry I am in. Ideally, the teams will be structured so that they can complete their projects without pulling from other teams, but it is unlikely that this will be 100% feasible for all teams as it will depend on the size and complexity of the project.

We have resource management (RM) tools and processes implemented by functional org chart team e.g. business applications, servers, training, analytics, etc. However, as we move to cross functional delivery teams, we will need to address how RM will be performed moving forward.

I would appreciate your insights on how to approach RM if you have gone through this type of transition and also how you currently manage resources if you execute in an agile environment (for both day-to-day operations and projects).

In my department there are two opposing opinions on this: 1. We don't need to formal RM as the teams will manage their own work. 2. We need to shift RM processes to support delivery teams' capacity for project work and the shared services whose resources will be divided among multiple teams.
Sort By:
Sara -

I'd first recommend finding a way to separate operations and project work, unless by operations you are referring to break/fix activities on a product/value stream to which a team is dedicated. If it is support type operations, then it will be very challenging to get predictable forecasting.

RM is a classic case of garbage in, garbage out - start with some basic practices, get consistency on those, and then introduce tooling as needed to support that.

If you have product-focused teams, RM is less critical as the team composition and focus shouldn't shift regularly. What is useful is understanding how much work a team is able to complete within a given period of time to decide whether increasing the team size is advisable or not - of course, this will need to take into account the law of diminishing returns as well as the specific delivery process the team uses.

Resource management is about managing competencies, more so than people. Not only should you have core competencies identified but the staff should have development plan that align with them. The focus should be on cross-training rather than single specialty. (My senior staff had two specialties or more.)

yes, a complicated matter, I would tend to your option 1 (no formal RM). But support the teams in getting help from others.

At one client, we established a standup with representatives from all teams every 2 weeks (4 days before aligned sprint end). There was a wall with a matrix of all projects (teams), horizontally depicting the requestors and vertically the suppliers of resources (unspecified as to human names).

Each request was on a yellow card, and contained supplier/requestor team name, requested action, account code and responsible person for this transaction.

Requests could be put on the wall anytime, and asked for anytime between teams, conflict resolution was in the meeting.

We called it demand coordination. With 10 teams and some more covered projects on the requestor side, it took 30-60 minutes and was considered a good process.
I agree with Kiron. Thomas made valid points as well.

Please login or join to reply

Content ID:

"Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."

- Jeff Raskin