Form Follows Function

Problem: A project lacks well-defined roles.

Context:

You know the key atomic process activities.

Forces:

Activities are too small, and their relationship too dynamic, to be useful process building blocks.

Activities often cluster together by related artifacts or other domain relationships.

Solution:

Group closely related activities (that is, those mutually coupled in their implementation, or which manipulate the same artifacts, or that are semantically related to the same domain). Name the abstractions resulting from the grouped activities, making them into roles. The associated activities become the responsibilities (job description) of the roles.

Resulting Context:

A partial definition of roles for a project. Some roles (mercenary analyst, developer) are canonical, rather than deriving from this pattern.

Design Rationale:

The quality of this pattern needs to be reviewed. The idea came from the approach taken in a large project re-engineering effort I worked with in March of 1994.

Louis Sullivan is the architect credited with the primordial architectural pattern of this name [Rybczynski, p. 162].

This pattern interacts with other structural patterns such as Organization Follows Location, Organization Follows Market, and Architect Also Implements. Also see Engage Customers.

One manager notes: "In my experience from Project Management Audits ... projects both leave out roles (e.g., no named architect) and define several people with the same role. The second is most problematic, since it causes staff confusion. But the missing role also occurs because projects have inexperienced managers. This is a big problem...around System Engineering roles, or lack thereof."

Next: Domain Expertise in Roles