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.