Once a mission is defined for an organization, it typically must be translated into a set of expected behaviors for internal teams and members. These target behaviors must define who is expected to accomplish what, and allocate obligations for coordinating activities to groups and individuals responsible for all aspects of integration. These behaviors are commonly called responsibilities, and must clearly and comprehensively establish the boundaries between each of the organization's actors. This structuring of work and jobs should assure that the business outcomes desired by the organization can be achieved within the structure which the organization has adopted.
Donald Reinertsen describes why organizational boundaries must be taken into account in performing this allocation:
A boundary is a formal way of dividing authority in an organization. There are two ways of communicating boundaries inside the organization. Unfortunately, the most common approach is trial and error. Some people refer to this as discovering the location of the invisible electric fences... There are two practical problems with using trial and error. First, from a technical perspective, it is slow. Second, touching electrical fences does not encourage the team to use initiative in making decisions.
These responsibilities are usually grouped within containers called roles before they are assigned to individuals. These roles may be thought of as 'hats' which different individuals or teams assume at different points in a work flow so that desired outcomes are achieved. Each of these roles is given a short, unique name which allows these responsibilities to be referred to easily.
An example of the roles and responsibilities which Microsoft uses is depicted in the figure above; a more detailed elaboration of those roles is available here. For another example, the positions which baseball players play on the baseball field can also each be considered to be roles. Note that in that environment, professional players often specialize, and the top players nearly always are successful as a result of long practice in that role.
In some situations, fulfilling even one role may be more than one individual can feasibly achieve for a particular job, work package, or value stream, no matter how capable or experienced a particular individual may be. In other situations, an experienced individual may easily assume multiple roles on different projects. But it is important to recognize that a given responsibility neither dictate the degree of difficulty which will be required to fulfill that responsibility, nor the relative importance that portion of a job may have in achieving value as an endeavor has chosen to define it.
Many factors contribute to whether multiple roles can be performed concurrently:
- the specific experience and competencies of individuals who serve in these roles
- the environment in which the work must be performed
- the complexity and difficulty of their work
- the novelty and demands of the situation
- the robustness, uniformity, and effectiveness of the overall governance system
- the granularity and fitness of the portfolio information infrastructure.
Once roles are named and defined, lower-level organizations, teams, or individuals can then be assigned to fulfill them. This often requires a process of elaboration and iterative refinement to deploy such a structure across a large organization. In these situations, each role will typically then need to interact with many other roles in order to perform actionable work; together, all these roles are collectively bound together within a communications network that should guide and coordinate work among these actors. Work queues and congestion will inevitably arise within this network, and these constraints must be addressed, and the loads on resources re-balanced in a timely fashion, if delays in processing are to be avoided.
At a higher level, these roles often are organized within an occupation, which both serves to establish the competency qualifications for candidates for a role, and may also provide an identity that people adopt for themselves as they perform their assignments - for example, a practitioner might identify themselves as an engineer, a scientist, a technician, or a manager. Each of these may also have different levels of performance expectations that are established for progression through a career within these occupations.
As the interactions between such roles are standardized and performance is stabilized, traffic patterns among roles will become evident. As they do, the efficiency and effectiveness of the communications channels that are used within different scenarios and situations will begin to become evident. As an example, if interactions relating to requirements development are limited to involving a manager role, developer role, and customer role, this could be an early predictor of future quality issues, since the role responsible for testing should also be involved.
The use of 'manager' or 'director' in the name given to a role does not always mean that that the role operates in the upper levels of an organization's hierarchy, serves as an official company spokesperson, or is assigned to perform a prescribed set of traditional management functions within a defined area of responsibility. For example, the roles of product manager, project manager, program manager, and program director are widely used within the industry, but are rarely consistent across organizations. The confusion this causes can create tension to exist between these different perspectives, and may lead to inflation of titles without equivalent growth in responsibility.
There are several rules of thumb which should be kept in mind when designing the interactions of such roles in order to provide for efficient execution and assure that outcomes are achieved reliably:
- Protocols must be established to assure that end-to-end exchanges of information are complete, understood, and available when required
- Feedback mechanisms must provide communications paths to anticipate issues and communicate areas of concern
- The time and resources allocated to perform any role must be realistic for the job at hand
- Artifacts and work products should be assessed against defined standards which effectively characterize the needs of the downstream users of work artifacts
- Measurements of effectiveness and organizational assessments should be performed by a community of peers who are experienced in performing reviews and oversight, and which have a record of using that information to effect change
- Sufficient time must be provided to resolve problems which these reviews will inevitably reveal prior to final release
The following groupings outline how one organization's architecture might implement a distribution of roles and responsibilities for performing work. These descriptions are offered as a representative partitioning which may be adopted and tailored for other scopes and contexts. They are not intended to be comprehensive or appropriate for all situations, but are offered as a demonstration of how responsibilities could be partitioned, and the types of interactions required in practice. Such groupings will always need to be tuned to the unique mix of each business, product, and customer relationship.