I would like to understand the impact of different resourcing models for software projects. First, I would like to identify the different resourcing approaches that are used to resource software projects. Here are some models that I can think of based in my own experiences:

  1. Product centred resourcing
  2. Planned resource pooling
  3. Chaotic resource pooling

Model 1 - has resources that are product focused. In this model the project team is dedicated to a product (e.g. a SOA service). In this model, the product is the central concept and the team stays and grows with the product. This model promotes continuous learning for the team in the product domain, and facilitates rapid development of new features because the project team is intimately knowledgeable about the product. This model seems to be very effective for evolving existing products in product centered companies.

Model 2 - pulls resources from a resource pool when starting up new projects. This model appears to be most suitable when developing new products from scratch. In this model team members need to acquire the domain knowledge required before starting the project. The model does not seem to be effective for product based companies because product domain knowledge is lost when resources disband after the project completes. This model is typical in consulting organisations.

Model 3 - is really an extension of Model 2. In Model 3, resources are replaced with other resources mid-project. Thus model treats resources as commodities where new project team members are expected to acquire the same knowledge as the resource that they replaced. This model leaks the most domain knowledge, and is is characterised by low morale and low productivity. This model is usually found in organisations that are constantly fire-fighting.

Question: Is there a taxonomy of software resourcing models that I can use rather than creating my own?


2 Answers 2


I'm not sure if there's a taxonomy for teams, but there are different ways of looking at teams and how they are organized and structured.

First, there are a few dimensions that you can talk about - formalization, standardization, and centralization. Formalization is the level to which rules, procedures, and written documents guide the behavior of individuals and groups. Standardization is the level to which activities are performed in a consistent manner across the organization. Centralization is the level to which the ability to make decisions is kept at the higher levels in the organization.

These three factors of discussing an organization also lead into the concept of mechanistic and organic structures. Mechanistic organizations have high degrees of standardization and formalization, often (but not necessarily) with a high degree of centralization. The end result is consistent, repeatable, and reliable performance. The other end of the spectrum is organic structures, which give lower level employees more freedom to conduct their work how they best see fit, which often leads to more innovation at the cost of consistency and repeatability across the organization as a whole.

There are also ways of looking at the reporting structure of a team. Four views of this are the functional team structure, a lightweight team structure, a heavyweight team structure, and autonomous team structure.

In a functional team structure, everyone works in their functional departments and there is no cross-functional integration. In a lightweight team structure, everyone works within a functional department and functional managers have authority over the individuals while a project manager coordinates the functional roles with respect to an individual project. Under a heavyweight team, project managers have authority over the individuals who are provided by a functional group but will return to their functional group after their role in the project is complete. In an autonomous team, the project manager has long-term control over resources provided from functional groups.

Strategic Management of Technological Innovation by Melissa A. Schilling has a few chapters dedicated to different ways of organizing teams, specifically focusing on product development and innovation in the workplace. It's not unique to software, but may be a relevant starting point through it's citations.


Model 1 is the divisional organization, Model 2 the matrix organization. Model 3 would be a weak matrix based organization. Note for IT organizations functional type is not best suited when each job is different and are projects.

  • 1
    how does this answer the question asked?
    – gnat
    Nov 25, 2013 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.