An example of a Software Project pattern. [What makes a project successful is Project Leadership, which too often is incarnated as Project Management. What is involved in Leadership that makes a project successful will be covered later.]
Pattern Name: Multi-site Development (AKA “Offshore Development”)
Context: Key development resources are not available in a single geographic location, due to either quality or quantity. Or specific technical or domain skill. One resolution is to move all the required personnel into a single location for the duration of the project. But “the duration“ may be indeterminant. Or there may be a cost differential between development resources in different locations.
Forces: The main forces to be reconciled include:
Total return on investment. That is, getting the project completed for the lowest cost.
Community of Understanding. All levels and locales of development need to know what they should be working on, and how their part fits into the whole (or at least the whole as it is in their location).
Effeciency/predictability. The amount and kind of work that can be accomplished in each location for each appropriate period of time needs to be within a scope of estimation. (“Scope of Estimation“ in the DeMarco sense).
Solution
Resolution of these forces as successful Multi-site Development requires project leadership around at least the following areas:
Resource Usage: Geographic sub-teams own specific deliverables. That is, the distribution of development across geographic boundaries should be tied to the distribution of functionality development responsibility.
Technology/Architecture with at least the following elements. An enterprise architecture articulated to at least cover this project to the extent that clear and precise abstraction barriers are defined. Functional closure behind those barriers. Defined interaction between those functional closures, including processes, techniques and protocols (for example, Service Orientation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/srorientwp.asp)
Iteration lenth between complete system builds should be “moderate”. That is, often enough that there is at least three iterations before the first major release, but not so many that sub-teams become thrashed.
Formality of manufacture moderately high. Geographic distribution demands externalization of artifacts such as requirements specifications, functionality interaction definitions, architectural guidance, plans, milestones, etc.
Other areas of importance include communication and coordination. Various mechanisms exist to promote communication, which is essential to establishing a community of understanding.