Form Follows Function

Visitors' overlook building at Kentucky Dam. This structure is in the form of an open shed because the other functions of TVA (Tennessee Valley Authority) visitors' buildings being accommodated in the nearby construction village, there was need for shelter only at this point. Since the project is in a hot climate, ample ventilation is promoted by the open front, a balustrade height opening toward the back underneath the display and grilles to ventilate the roof space. Most of the displays are arranged as transparencies, with natural illumination during the day, and with floodlights used as substitutes during the night.

...you know the key atomic process activities, but there is little specialization and few well-defined roles. People don't know where to turn for answers to questions.

✥ ✥ ✥

A project must delineate well-defined roles to help identify and leverage expertise relevant to emerging problems.

Individual activities are too small, and their sequencing relationships too dynamic, to be useful process building blocks.

You could build talent lists of the individuals in an organization and partition the work among them, but that makes the organization sensitive to personnel changes. And it would be nice to sometimes be able to talk about the organization structure at a higher level of abstraction than individuals.

You could organize around classical roles such as "developer" and "designer" and "manager," but that's only a partial solution. These roles don't apply to all organizations, and stereotypical roles can't generalize to a wide range of domains.

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

You want to match up specialization, expertise and experience when staffing an organization.

Therefore:

Group closely related activities (that is, those mutually coupled in their implementation, or which manipulate thesame 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. Roles, rather than activities, become the basic project building blocks.

✥ ✥ ✥

For example, if a project depends heavily on a software library, there should be some ownership (see CodeOwnership) embodied in a role such as Librarian. The Librarian has responsibilities and social communication patterns distinct from those of a developer, which makes it a separate role. Other roles such as Vendor Coordinator, Rules Developer, or Computer Graphics Artist speak to the function of the organization and its product.

Other roles convey more subtle aspects of organizational function and structure. One organization featured the roles Code Police and Agitator, reflecting a lighthearted attitude towards what might otherwise be considered onerous functions.

This approach yields a partial definition of project roles. Some roles (MercenaryAnalyst, developer, architect, GateKeeper, etc.) are canonical, rather than deriving from this pattern. Those roles, too, are in concert with this pattern, though at a more generic level.

The idea was used in a large project re-engineering effort that Jim Coplien worked with in March of 1994.

Louis Sullivan is the architect credited with the primordial architectural pattern of this name ([BibRef-Rybczynski1989], p. 162).

This pattern interacts with other structural patterns such as OrganizationFollowsLocation, OrganizationFollowsMarket, and ArchitectAlsoImplements. Also see EngageCustomers.

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."