Governance frames of reference


Figure 1

The term 'process' is used frequently in most performance improvement activities to denote a variety of related concepts that operate at different levels of detail. These distinct viewpoints can be helpful in understanding behaviors from the different perspectives stakeholders perceive. Unfortunately, when approached from only one of these points of view, trying to understand organizational performance can be a bit like blind men trying to understand an elephant... it is only possible after accepting that the subject is a living organism that operates at many different levels. Three perspectives are particularly noteworthy:

  • The value stream perspective at the top level of abstraction for understanding what a system is supposed to do, and how lower-level elements should be threaded together for operation within a particular operating context. This representation depicts a value stream, and considers process elements from both their static and dynamic characteristics. Ideally, a value stream map is available to inform this viewpoint, which should draw from elements of the organization's process architecture.

    This top level of abstraction can help to communicate a broad understanding of the high-level interactions between work units, without considering the details of how these interactions will actually be performed. At this level, the essential properties of organizations elements can be considered, much as a Concept of Operations is used to describe a system at a high level. This value stream view can serve to allocate an organization's policies and authority to responsible agents. The guidance at this level may be narrative in nature, with a mix of both prescriptive (designating inclusive characteristics) and restrictive (describing rules of composition and exclusion) process specifications. This viewpoint may also enable scope determinations to be made between competing or cooperating organizations or groups, and may also define obligations and provide a means of assuring compliance with such information. However, at this level, there is generally insufficient information for workers to know specifically how, or when, to accomplish their work; in fact, the descriptions may be neutral with respect to time, ignoring the constraints which plans and schedules always introduce.

    In selected scenarios (such as when efforts are prioritized to mitigate or resolve issues), techniques such as narratives and story-telling may help to explore dynamics and communicate expected responses to particular situations. Typical scenarios at this level include making investments, performing investigations, and coordinating logistics for near-term demands for development and production systems. This perspective may also serve an important role in defining rules of conduct, communicating collaborative business and technical approaches, and structuring demonstrations of compliance.

  • The statement of work perspective, in which processes describes the specific requirements, activities, and work products involved in getting things done, and the roles and hand-offs that are expected to occur along the way. This perspective is important to understand the component building blocks that are to be integrated together (typically via some planning process) to accomplish the overall business objectives of value stream elements. Such components may be embodied as process definitions, standards, or discipline-specific handbooks, or may appear in Web sites or be provided as a part of other governance-related delivery mechanisms. At this level, information flows may be defined, though they are likely described at a very high level as abstract entities; since the consistency, pace, and maturity of this information are critical to flow rates, this will generally not be sufficient for many types of improvements, but can still prove useful to identify 'hot spots' for further elaboration.

    This frame of reference provides appropriate detail for planning and training purposes, and is thus important for managing the business and improving the capacity and capabilities of its organizations. In effect, it partitions the work into meaningful activities from which patterns can be discerned and acted upon. Some see this level as unnecessary for experienced teams, but this thinking has several serious flaws. First, it fails to take into account the need to standardize on a common action vocabulary to organize information for decision-making (risks, investments, prioritization, etc). Second, it overlooks the opportunity to provide template documents to jump-start new efforts and exploit reuse and patterns of successful approaches. Third, it ignores the need to establish, and continuously improve, a list of evaluation criteria that represent the critical focus for each intellectual step in an activity. Finally, it overlooks opportunities to allocate responsibility, coordinate action, enable automation, and focus attention on critical areas of a process that must be optimized to enhance overall throughput.

    These building blocks should be built on a set of higher-level requirements, and naturally will rely upon skilled and disciplined individuals in order to use their experience, judgment, and discretion in implementing the process steps. In the absence of these components, desired efficiency improvements will be difficult to achieve for an organization overall, since there will not be enough money to improve everything at once, and sub-optimization is therefore very likely. Indeed, the elements necessary for improvements - checklists, template documents, and mechanisms for assigning and coordinating action - can generally become the focus of improvement, only after individuals can consistently perform their work, and as the organization grows (triggering a demand on experienced people for training new individuals joining their teams). Indeed, these higher-level processes can provide an important overview of required activities, and can over time be linked to supporting documentation for less experienced individuals. An example of such a high-level writing is available on this site for a typical risk management process, which reinforces roles that become the basis of assignments and what they are to do, without describing how to achieve these outcomes.

  • The job perspective, in which interactions and implications of the time dimension are added to processes, with the necessary aspects of control, resources, and information flows (queues, triggers, etc), introducing aspects of control and feedback into thedynamics which results from these constraints. This perspective typically focuses on achieving predictable performance through competencies that build on person-independent foundations that can provide for sustainable improvements. This is typically accomplished with more detailed user instructions ('how-to') for the work itself, and precise data and tool definitions and information flows associated with each process so that it is designed to operate in a 'stand-alone' manner. These details should guides the sequence and coordination of the various process steps, define process prerequisites and completion criteria, and identify anticipated results, measures and key checkpoints. These 'scripts' of jobs may take the form of written procedures, and are then sequenced together (and sometimes tailored) within the context of plans, strategies, schedules and resource availability that are established for a project. If time can be thought of as a string, these are beads that are threaded onto that string, and these threads are what transform material and information into products over time; visually, you might imagine different colored beads to designate different roles and procedures being invoked at different times. Once developed, this structure can then be used to guide daily work, and is particularly critical for organizing, planning, and development activities for implementing automated guidance, execution support, and process assurance support. These details can also become the 'worry beads' for the team that has to make the entire thread work.

    Another aspect of this perspective is that it often reveals the need for a set of business rules, i.e. statements that define or constrain some aspect of doing the work, or defining what to do when exceptions to defined processes are needed. They are thus intended to assert structure and to control or influence behaviors. Business rules can be examined from two viewpoints:

    • From a business viewpoint, they create the traffic controls and guardrails on the project's roadway, or the constraints on behaviors for the actors who must lead these activities and perform actions within the context of the project's plans and schedules. These controls can range from access limitations on information, or authority restrictions on certain actions, such as who can approve a purchase order or document, to constraints on resources or time.
    • From an information system viewpoint, these business rules document the decision-making that allows raw data to be transformed into actionable information, within the envelope of constraints on the values of that information (for example, what additional information must be captured over time in order to authenticate that information).

All these process 'frames of reference' are valid, and need to be rationalized, or confusion and chaos can result. Each can have its own hierarchical structure to achieve the intentions of the level. But not every situation requires each view, or is tolerant of the time it takes to elaborate those views. For example, consider the Provincial Reconstruction Team Playbook, published by the Army Lessons Learned command, for use in Iraq and Afghanistan. It communicates strategy and responsibility from a statement of work perspective, and relies upon the troops on the ground to have discretion in execution for much of their operations. To do this, the details still require further elaboration in jobs (plans) at the tactical level for each campaign. In other situations, the need for much more rigorous protocols at the job level is apparent. For example, consider the needed tradeoffs in authorizing a new drug therapy for a disease. While such drugs can be beneficial when applied properly, they may be hazardous if applied to the wrong patients or in the wrong way. A key challenge is thus in knowing which of these perspectives to use, and when, for accomplishing a particular set of business objectives.

The rules for how such jobs can be threaded together, and the structures and relationships which can be formed among these perspectives, collectively bind the business, organizational, and process architectures together. It is in this context that issues of iteration, parallel execution, and interactions between processes must be clearly defined. This is essential in order to provide flexibility in a variety of job situations, while correctly transforming and providing the necessary information for downstream processes.

While technology for workflow tools are impressive and mature, such tools can only be effectively applied once such an information structure is in place that covers the above perspectives, and is accepted by stakeholders as being sufficiently mature to guide work. Leveraging such capabilities is relatively easy to accomplish when the underlying process structure is linear (such as they are typically in an assembly or manufacturing sequence in a factory, or when processing trivial transactions such as business expense reports). However, this can become much more difficult to achieve in complicated settings where there has been little precedent for the development being undertaken, such as when creation, evaluation, synthesis, and reflective insight are being applied over multiple cycles and phases of implementation.

An example of this more complicated situation is often experienced early in complex engineering development efforts, and often involves taking a cyclic approach to progressively elaborate and understand the requirements, alternative solutions, and risks across several design problems, while concurrently elaborating these across teams, as each strives to simultaneously optimize a new product's design and production. This is more like eating an elephant, a task that should be attempted only after careful consideration and planning!

A rationalized governance framework for accomplishing a business result must provide an approach which will appropriately address all of the Governance Stakeholder Needs, successfully operate within each of these Governance Frames of Reference (value stream, statement of work, and job), and establish an appropriate balance between the ability to make changes across the business areas in the near-term, and the desire and capability to realize benefits in the long-term.