Sara BalsterProject Management Manager| UW HealthWi, United States
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. Saving Changes...
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.) Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Sara,
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. Saving Changes...
I agree with Kiron. Thomas made valid points as well. Saving Changes...
Latha Thamma reddiSr Product and Portfolio Management (Automation Innovation)| DXC TechnologyMckinney, Tx, United States
I agree with Kiron & Thomas. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I have worked in this type of transformation from years, I mean from "project based" to "product based", no matter I always sustained that the first one is totally wrong. Returning to your point, i can wrote a lot but my recommendation is reading SAFe model. I am not saying that you or your organization has to follow it if not apply. But SAFe model is good to take an idea about how to face this type of situations. Saving Changes...
