Resource Allocation

The Problem

I have observed first hand the following resource allocation problems: 


1.  Starting at the scaling phase.  Many products start at the solution phase skipping the first three phases of sPDLC.  Instead of understanding the customer and the problem, pivoting over a solution, and measuring solution effectiveness, huge product teams are being formed to "deliver a solution which 'business' is asking for."  

2.  Risk management as an after-thought.  A project manager pays very little attention to risks and risk mitigation.  Assumptions are not being prioritized or de-risked upfront.    

3.  Projects are never canceled.  Instead of starting small and canceling early, the budgets and resources will likely double in case of trouble.  Since the problem and the solution goals are never identified, the measure of project success is delivery "on-time and on-budget."  Hopefully, on-scope as well.  Ideally, with the right quality.  Management is incredibly good at saving face and hiding failures due to lack of transparency and the absence of product effectiveness KPIs.

4.  Products are never sunset.  Hundreds of products accumulate over time, creating complexity and bloated budgets.  The economic contribution of each product is unknown. 

5.  Missing problem backlog.  Resources tend to hold on to ongoing projects for job stability.  Lack of a sustainable flow of work through portfolio horizons.

The Solution

In software development, most of the budget is spent on people.  So "resource allocation" actually means how the budget will be spent.  

A product portfolio board executes the governance of each product in a portfolio.  Here I will outline a typical resource allocation process through all three horizons of sPDLC.  The picture above contains numbered circles at critical resource allocation decisions in sPDLC. 

H3 starts with a small team pulling the top problem from a prioritized portfolio backlog.  As described in the sPDLC and horizons articles, the exit criteria from H3 is an idea for the first MVP, which is desirable, viable, and feasible.  Thus, the initial team should be cross-functional (and small) to cover all three aspects.  Typical team size will be three people: one UX designer (desirability and customer empathy), one product manager (business viability and market research), and one software developer (technical feasibility and technology trends).  


The start of H2 marks a transition to software development to develop an MVP or a series of MVPs with potential pivots.  Add one more developer to form a pair (circle #1).  Now the team size is four.

The start of scaling requires substantial software development in a race to win most of the early majority customers.  Add two more software developers to form a second pair (circle #2).  Now the team size is six: one product manager, one UX designer, and two pairs of engineers.

At some point, the team will tire from doing things that don't scale and will ask for help with supporting business activities (circle #3).  Some of these functions may not even exist in the company. 


At this point, some companies make a crucial mistake.  For example, they may create a SAFe program with multiple distributed teams and one hundred developers.  Such massive scaling is premature because the product may still fail.  Besides, communication issues and dependencies management will slow down release velocity and customer adoption.  Instead, I suggest two lean options.  Option A is to add one more pair of developers to the existing team for the total team size of eight.  Option B is to create a duplicate team of six and to co-locate the two teams physically side by side in the same office.  The combined resource allocation in option B is twelve.


Depending on the product complexity and ambition, the scaling phase may last many months.  When the gain in customer adoption and revenue starts to ebb, prepare for another critical point in sPDCL - a handoff to the enterprise.  The best way to learn about software development is hands-on.  Pairing and rotating pairs provide such a learning opportunity.  To transfer knowledge to the H1 team, pair them for several weeks with the H2 team.  Add six or eight developers (circle #4) by either hiring them from outside or re-allocating existing resources. Also, add a product manager and a designer.  Now the headcount is 8 (H2, option A) + 8 (H1) or 12 (H2, option B) + 10 (H1). 


When the product, the H1 people, and the office space are ready, the handoff can happen.  H1 staff moves out to the other office and forms a new program or joins an existing one (circle #5). I will share my thoughts about methodology options for H1. For now, let's assume SAFe.  The H2 team(s) reform to either pull a new problem from the portfolio backlog in H3 or help scale a solution in H2.  A common mistake during the handoff is to pull the original resources into H1.  This short-sighted decision disrupts the sustainable flow of innovation in the portfolio. Also, please note that the mindset and skills of resources from H1 and H2 horizons are different from those in H3.  Transitioning innovation and growth resources into a profit domain won't be productive but rather cause disruption, frustration, and attrition.  I will share more thoughts about this in future articles.


At some point in the optimize phase, the team needs to re-architect the full-stack product to integrate it tighter with the enterprise.  The goal is to reduce costs by leveraging the existing components and teams.  The downside is slower development due to dependencies management and coordination overhead.  When the refactored product goes live, resources should be reduced further (circle #6).  


When the feature backlog has been exhausted, and market saturation occurred (the late majority of customers), the product can be handed off to an existing team focused on portfolio support.  The support team could be located offshore or even outsourced.  Dedicated resources from the optimize phase will perform knowledge transfer to the support team and will be repurposed (circle #7).


When the product does not make economic sense anymore, it should be sunset to reduce portfolio complexity and free up support resources (circle #8). A "next-gen" replacement product with a new sPDLC may be in the works.


Fundamentally, the lean way of software product development is about risk-reduction and practical use of resources.  It implements the following lean concepts:

1. Flow 


2. A holistic approach to value creation and prioritization

3. Upfront value de-risking to eliminate waste

4. De-centralized decision-making  

5. "Pull" instead of "push"

I will add more details about the lean mindset in future articles.