What size of project team is optimal to deliver a new IT application, with quality, in the shortest length of time? Based on empirical evidence, if the team needs more than two pizzas to satisfy its hunger, it’s probably too big. (At least, that was what Amazon.com discovered.)

The principle here is that the team should be no larger than it needs to be. So, rather than engage in a fruitless debate over the nature of projects — “ours are real business applications (never mind that Amazon’s are revenue-generating) and thus more complex than some little web thingy” — let’s look at what the “two pizza limit” is really saying:

1. Keep the core team small, and use competence when and as needed. Most businesses put many individuals on project teams for extended periods of time (if not “for the duration”) on the rationale that their specific knowledge and skills might be needed. Better practice is keeping the core team small — so that communications are fast, frequent and effective — and focusing carefully on what, precisely, is needed by “experts” so that they can be brought in, used for their expertise, and leave, free to contribute to some other team. This is the true difference between the idea of the centre of excellence as a practice area in the mould of a consultancy and the centre of excellence merely as just another organizational unit.
   
   

2. Break the project into chunks. This is not a call for “many small releases”, effective though that has been. What it says is: architect and specify a solution, then turn that over to a team to create and implement it, then turn that over to a team to deploy, refine and optimize the resulting  “product”. Each team is small and focused, and it requires that the work of the preceding step actually be done before proceeding, instead of co-developing all steps more or less in tandem. (This also allows the organization to learn from its errors in a more effective manner: bad design skills, for instance, can now be isolated, and a true “scope freeze” once the design is done can more readily be implemented.)
   
   

3. Avoid over-specifying the solution. The tendency in IT today is to answer all requirements with “a package”. While this can be effective in delivering complex functionality in a less-risky manner (on the surface), it often leads to two bad sets of decisions that affect projects: trying to use more features than the requirements actually require, and force-fitting requirements into the capabilities of the package. Having just a very few core packages (to provide a data architecture with some degree of master data model consistency) and writing bespoke code that does specific functions tied to that data architecture is often faster, cheaper, and less risky than trying to merge packages into a coherent whole. (The resulting parts are also easier to replace later, as well.)
   
   

4. Trying to do too much at once. Requirements often become a “bit bucket” filled with everyone’s pet peeves, especially if requirements and specifications are co-developed. Projects should begin because the business case is built from the requirements, and some deployment rules-of-thumb for costing. Excess requirements can be squeezed out at this point, as they are less likely to produce value that adds to the benefit stream. In addition, separation of the business problem and its outcome (requirements) from any of the technical aspects of delivering the result (specifications onward) allows problems in the problem definition to be probed when the only cost is a little more meeting time and some paper for record-keeping, rather than throwing away months of work with significant mid-project scope change.
   
   

Every step in the process of going from “let’s solve this problem” to “that works well, thank you” can be done by small, tightly-focused teams. That is the true lesson of the two pizza rule — and it is as true when one is deploying a major package as it is for a small little application.