Although program management primarily addresses the issue of team size, as you see in Figure 1 it is only one of several potential scaling/complexity factors faced by a team. It is important to recognize that a program team is likely to face several of the other scaling factors in addition to team size.
Figure 1. The scaling/complexity factors of the Situation Context Framework (SCF).
Your decisions around how to choose and evolve your way of working (WoW) will still be affected by the other scaling factors:
- Geographic distribution. Chances are very good that large teams will also be geographically distributed in some way. There are two flavors of this: Are teams geographically distributed (e.g. in different physical locations) and are people within a team geographically dispersed (e.g. people are working in cubes, on different floors, in different buildings, or from home)? Both add risk. Coordination within the program becomes more difficult the more distributed the teams are, and more difficult within teams the more distributed the people are. Distribution hits the leadership (the product owner team, the architecture owner team, and the team lead/product delivery) teams particularly hard because members should be located with their delivery sub-teams but also need to work regularly with their counterparts located elsewhere. The implication is that the team may require extra tooling to enable collaboration and more importantly be prepared to invest in travel regularly to foster better communication between disparate locations. Furthermore, when your stakeholders are geographically distributed it may require your Product Owners to get support from agile business analysts in the various locations to help elicit requirements from them.
- Organizational distribution. The larger the team, the more likely you are to involve contractors, consultants, or even to outsource portions of the work. When external organizations are involved the Program Manager will likely be involved it the contract management effort, which in turn may require assistance by the team leads.
- Skills availability. The larger the program, the less likely it is for you to immediately have sufficient numbers of people with the sufficient skills to do the job. The implication is that you will need to work with your People Management group to help existing staff to learn the requisite skills or hire people with those skills. You may also need to work with Vendor Management to partner with external firms to provide people, or even entire teams, with needed skills.
- Compliance. Compliance, either regulatory compliance required by law or self-imposed compliance (i.e. CMMI compliancy ), will definitely have an effect on your approach to program management. In fact, the larger the program the more likely it is to fall under regulatory compliance due to the greater risk involved. Regulatory compliance generally requires greater governance both within the program and outwards facing as well. Under some regulations your coordination efforts will require proof that they occurred, such as some form of meeting minutes that capture who was involved, the decisions made (if any), and action items taken by people. Compliancy may also motivate more sophisticated approaches to capturing requirements by your Product Owners and to documenting technical concerns by your Architecture Owners.
- Solution complexity. The larger the team, the more likely it is that they are taking on greater solution complexity. More accurately, greater complexity often motivates the creation of larger teams to deal with that complexity. Greater solution complexity will motivate greater attention to architecture and design, thereby motivating more regular collaboration of the Architecture Owners.
- Domain complexity. Similarly, team size and domain complexity tend to go hand-in-hand. Greater domain complexity will require the Product Owners to work in a more sophisticated manner and may even motivate them to get support from agile Business Analysts (or junior Product Owners as the case may be).