Resource Management: Stop Managing People-Start Managing Flow, Capacity, and Intent

I was fortunate to travel to Melbourne, Sydney, Manilla and India as part of my work discussing good practices using a specific SaaS product in product, project, and program management processes. The industries ranged from banking, investment, FinTech, defense, transportation, non-profit sectors, and healthcare. One of the things that kept resurfacing is managing resources. Those that were using adaptive approaches want to use the metrics to push the velocity. Others that were following plan driven approaches thought of the people's unutilized capacity meant productivity loss. At the program level, people reasoned that all resources are interchangeable that they can be moved from one team to another across the projects in the program! 

I feel that rushing to use some metrics to measure resource utilization may also lead to failures. Resource management is not about people shortage or utilization of people's time. In fact, the resource management focus should be managing flow, capacity, and intent. So, let me elaborate with some examples. 

One team using an adaptive approach reasoned that the velocity was unstable and stories often spilled over to subsequent sprints. Their conclusion was that team members had maxed their available capacity! So, either new people have to be added or AI and automation must be factored.  I asked how much the backlog was ready with risks to delivery, clear definition of ready for pointing, and how much wiggle room for people existed for innovation and experimentation! The discussions led to the fact that features were big in the backlog without a clear articulation of value to the customer. So, the story points were not based on risks to delivery or a clear definition of done! Hypothetically, even if the team delivered 20% more, they were taking on technical debt - just enough to fill the velocity charts told the narrative the management wanted to see! How is the improved velocity valuable to the customer or business if the backlog was not ready? One important hidden lesson is that poor backlog readiness masquerades as a resource problem! 

Another plan-driven team used hours! Here, planning looked at number of people in the release, available hours/person between the start/end dates and made sure that everyone had 100% of the available capacity filled with tasks! In theory, great! But, the same team commented that the challenges were the work delivered had more defects and incorrect documentation for the users. Follow-up discussions pointed to inadequate time understanding the collaboration on the work (assumptions were made and assumption analysis was done) and metrics on number of defects logged/closed meant the increased defect density (defects/requirement) was demotivating! So, does utilization mean quality delivery?   

I always emphasize that we should measure what matters! This applies to resource management too as we shift focus on flow, capacity, and intent. For instance, we should come up with good leading indicators during release/phase or iteration/sprint planning to see how ready we are to maximize flow, utilize capacity, and improve intent. Here are some good resource management metrics to support this approach. 

Measure	Description	Impact	Steps
Backlog Readiness Index	% of upcoming backlog items meeting DoR	If this is low, it means: Story spillover Sprint churn Scrap/Rework	Define DoR (clear AC, risks, responses) Review next 1-2 sprints of backlog Count items meeting DoR (A) Count Total items reviewed in planning (B) Compute A/B
Capacity vs Demand Ratio	Comparison between available team capacity and planned demand	If this is high, it means Overcommitment Under estimation Team Burnout Low Quality	Calculate team capacity (days or points)(A) Sum planned work effort(B) Compute Demand(B)/Capacity(A) (Closer to 1, higher the risk)
Resource Availability Rate	% of actual time available for planned work	If this is low, it means: High context switching Hidden operational work Inadequate planning	Identify capacity (A) Subtract meetings, support, shared work (Good practice is to allocate 20%-30% for these things) (B) Compute Available Time (B)/Capacity (A)
Unplanned Work Ratio	Portion of work that entered the sprint after planning	If this is high, it means: Unstable Delivery Discovery Delay Weak Decision-Making (This may be either upstream or downstream issues)	Track work added mid-sprint Compare effort vs planned work Express as %
Technical Debt Accrual Rate	Rate at which new technical debt is accruing	If this is high, it often means: Declining throughput Delayed Design Issues Disappointed Clients	Tag unclosed items/release Track debt/release Project trend over time

At the end of the release, phase, iteration, or sprint review, measure delivery performance using lagging indicators. These includes time-to-market, defect density, feature adoption, schedule/cost variance (part of earned value management), and team's throughput. There are various other KPIs that can be used based on the industry, team maturity, product life cycle stage, etc. 

It is important to avoid some anti-patterns when measuring flow, capacity and intent. Some of these patterns are around treating backlog readiness as paperwork exercise without truly spending time on it, planning releases with 100% capacity, ignoring unplanned work exceptions, accumulating technical debt without increased visibility, and measuring outcomes without tracking leading signals. 

What are your thoughts around this concept resource management at the product level? I am looking forward to your ideas.