Structuring a Practice is where the elements of the practice and their relationships are
defined. Specifically, structuring a practice involves:
Defining the practice -- where the practice fits in the overall Practice Framework and what are its external dependencies
Defining the practice elements -- what elements are contained within the practice and what are their relationships
Categorizing the practice elements into standard and custom categories
Each of these topics is described in the following sections.
General practice structuring guidelines
The practice structure must be developed within the guiding principles and constraints of the practice
framework in which the practice resides.
When structuring a practice, resist the temptation to enter detailed descriptions into the defined method
elements. Instead, just name and briefly describe the elements and enter a few outline details, if they help to
more clearly describe the element's basic definition. For more information, see Guideline: Method Element Naming Conventions and Guideline: Writing Brief Descriptions.
When structuring a practice, be sure to look for opportunities to leverage existing information in core elements and/or
in other practices. If you find existing method elements in another practice that you would like to share, work
with the method architects to get the common information moved to the core where it can be shared. Likewise,
method elements should be defined to maximize reuse. If while structuring a practice you define an element that
can be shared across practices, it should be defined in in the core where it can be shared, instead of in the
Defining the practice
Defining the practice involves identifying, naming and briefly describing the practice, as well as defining
the practice's position in the practice framework (i.e., defining the practice's external dependencies; what are the
practice's relationships with other elements in the framework, including core elements as well as other practices).
When defining a practice, it is important to explicitly define its inputs (Work Product Slots) and outputs (work products that fill slots), as well as any information (e.g., guidance, work
product definitions, etc.) that is shared between practices. It is also a good idea to identify a candidate list
of method elements the practice should contain. This provides more detail around the practice's definition. The
practice contents will be further refined when the practice is designed.
A practice name should be able to be used as a verb phrase – as in "we practice internal medicine", "we practice
iterative development", "we practice component-based design", "we practice use-case driven requirements". Be sure to
following the naming conventions for the practices. For more information, see Guideline: Method Element Naming Conventions.
When defining practices, strive to minimize dependencies between practices (unless a practice is intended to
enhance/refine an existing practice). To reduce the dependencies between practices, information that is shared between
practices should be defined as an Work Product Slots and common guidance. Where necessary, practice elements may
depend on elements in Core plug-ins (e.g., work product slots, common work products, common guidance, etc.), but
ideally should not depend on elements in other practices (unless the purpose of the practice is to extend another
specific practice). Remember, practices are intended to be independently adoptable and interchangeable, so limiting
external dependencies is important.
Any practice that is intended to be an alternative of another practice is not considered an extension/customization of
the other practice. It is a practice in its own right.
Practices are physically packaged in Practice plug-ins. Practice dependencies are represented as plug-in
dependencies. For more information, see Guideline: Defining Plugins. For more information on plug-in types, see Concept: Practice Library Plug-In Types.
Defining the practice elements
Base definitions of practice elements are defined in Practice Base plug-ins. If you are customizing/extending an
existing practice, then the definition of the elements that extend/customize the existing elements should be defined in
Defining the practice elements involves:
Defining the practice method content elements and their relationships
Defining the practice processes and what tasks they are assembled from
Defining the practice guidance and associating the guidance with the appropriate method elements
Each of these is described in the following sections.
Defining the practice method content elements
A practice may contain any number of practice-specific method content elements. In most cases, however, the
key elements of a practice are the work products it produces and the tasks that are performed to produce the work
The following sections provide practice-specific recommendations for defining the method content elements for
practices. For general guidelines on defining method content elements, see Guideline: Defining Method Content Elements. For general guidelines on customizing
existing method content elements, see Guideline: Customizing a Method Content Element.
If the elements to be included in the practice are extensions/customizations of existing elements (or are reusing
existing elements in some way), be sure to note the use of variability and the dependence on the element being
reused/extended/customized. For more information on variability, see Guideline: Using Method Content Variability. For general guidelines on customizing
existing method content elements, see Guideline: Customizing a Method Content Element.
Defining practice work products
Work products in practices may be defined to be used outside the practice, as an
input to another practice, for example (externally-available work product), or may be defined to only be used within
the practice ("local" work product).
Local work products are defined within the practice and may be used as both input and output work products of
Note: Tasks may produce the local work product, but another task must consume the local work product and produce an
externally-available work product.
Externally-available work products may be defined in either the practice or in a Core plug-in (of their definition is
to be shared). No matter where they are defined, externally-available work products must fulfill a Work Product Slot. The fulfillment of the slot is defined within the practice
(not in common). Externally-available work products may be used as inputs and/or outputs to tasks in the
Note: Even if they are defined in Core, these work products are still considered conceptually part of the
practice. The only reason they are physically placed in a Core plug-in is so their definition can be
If the practice work products have significant states that must be recognized in the method (e.g., outlined, detailed,
etc.), be sure to include the definition of those states in the work product description.
You will also need to define a default role assignment for the work product (i.e., what role is responsible for the
work product). For more information on roles, see the "Defining Practice Roles" section.
Defining practice roles
Practices generally implement a Delayed Assignment approach for role assignments so that the practices can be
reused in different contexts where the roles are different. Thus, in most cases, roles and role assignments (e.g.,
tasks to performing roles, roles responsible for work products) are not defined in the same method plug-in as the plug-in where the base practice elements are defined, unless a
role is truly practice-specific. Role assignments for practices are usually defined in Practice Assign plug-ins.
For more information on Practice Assign plug-ins, see Concept: Practice Library Plug-In Types.
Defining practice tasks
All tasks are usually defined in practices. Very rarely are tasks themselves
reusable enough to be in a Core plug-in. For more information on practice library plug-in types, see Concept: Practice Library Plug-In Types.
A recommended way to identify practice tasks is to identify the key states of the practice work products and then
define the tasks so that each task takes a specific work product (e.g., artifact: Practice) to a specific state (e.g.,
designed, detailed). Tasks should also be named to reflect their purpose, so you may want to consider including the
work product name and the intended state in the task name (e.g., design the practice, detail the
practice). Using such a convention results in tasks with a good separation of concerns and with consistent
granularity and scope across practices.
Practice tasks that need information external to the practice should use Work Product Slots as input work products. They may also use practice work products
as input work products. Practice tasks should only output practice tasks, not work product slots.
Again, practices general implement a delayed assignment approach for roles, so the performing role for a task is
generally not defined in the task definition itself.
Defining Practice Guidance
A practice may contain any number of practice-specific guidance elements. However the following is the type
of information that all practices should include:
Goals of the practice
Why anyone would want to adopt it (it's business value). What do you get when you adopt it? What
problems does it solve?
What is provided as part of the practice (i.e., the practice's bill-of-materials)
What is the best way to read/navigate the practice (which elements and an what order).
How to apply/adopt/implement the practice, including information on different levels of adoption, if applicable
Additional information/references related to the practice (e.g., white papers, web sites, etc.)
Practices tend to describe a specific technique for accomplishing a goal. Thus, guidance elements are a key part of a practice. However, some guidance can
be reused across practices. Reusable guidance is packaged in Core plug-ins where it can be shared. A
practice may reference such guidance (i.e., associate common guidance with the practice elements) and use it as if it
was defined directly within the practice. In fact, such guidance can be considered conceptually part of the
Practice-specific guidance should be defined within the practice and associated with the method elements in the
Defining practice processes
Defining practice process is where you turn your attention to the process side of things. How should the tasks
"flow" together? What tasks always appear together and in what order do they appear? Are there specific sets of
tasks that can be reused together in more course-grained flows?
It is a good idea for every practice to provide some capability patterns that describe how the practice elements can be used in a
process. Practice-specific capability patterns represent the key things you can do (the capabilities you gain) when you
choose the process. Definining practice processes defines an overall flow through the practice's content and
validates that you have the right content with the right separation of concerns.
In order to define a practice-specific process, you will need to define a process construction configuration that will
serve as the default configuration for the process (all processes must have a default configuration). Name the
process construction configuration to reflect its association with the practice. Practice processes should be
role-agnostic, which means that the construction configuration should not include the default role assignments for the
practice tasks. Specifically, the default construction configuration for practice processes should not include the
Practice Assign plug-in. For more information on the construction configurations, see Concept: Practice Library Configuration Types. For more information on defining
configurations, see Guideline: Defining Method Configurations. For more information on Assign
plug-ins, see Concept: Practice Library Plug-In Parts.
Assemble the practice tasks (and tasks in practices that the practice depends on, if any) into capability patterns. If
appropriate, create additional capability patterns that leverage capability patterns defined in the practice and in
other practices this practice depends on, if necessary. For example, an architecture practice adds a new work
product and a new task to a basic development practice (thus the architecture practice depends on the basic development
practice). Within the architecture practice you would define architecture-specific capability patterns using the
practice tasks, but you may also define a few additional capability patterns that show how the architecture capability
patterns could be combined with the basic development capability patterns. Such informational-like capability
patterns have been referred to as "reference workflows" as they are not intended to be reused as-is in other processes;
instead, they are to be used as an educational tool and may be mimicked in other processes. It is the practice-specific
capability patterns (the practice's "key activities") that are intended to be reused in other processes.
These guidelines provide practice-specific recommendations for defining processes. For general guidelines on
defining processes, see Guideline: Defining Processes. For general guidelines on customizing existing
processes, see Guideline: Customizing a Process.
Categorizing practice elements
Practice elements can be categorized into standard and/or custom categories. Each of these is described in the
Categorizing the practice method content into standard categories
Practice method content elements should be categorized according to the standard categorization scheme defined in the
practice library architecture. However, since practices usually implement a Delayed Assignment approach for standard categories, the assignment of the
elements to a standard category should be done separately from the base definition of the practice element (i.e., in
Practice Assign plug-ins). For more information on categorizing method elements into standard categories, see Guideline: Categorizing Method Elements Using Standard Categories. For more
information on Practice Assign plug-ins, see Concept: Practice Library Plug-In Types.
Categorizing the practice elements into custom categories
Practices may define their own custom categories (e.g., a practice-specific way to conceptually organize the practice
content, etc.) or add their elements to an existing custom category (e.g., adding content to a custom category of a
practice that this practice is extending,, etc.). For general information on categorizing method elements into
custom categories, see Guideline: Categorizing Method Elements Using Custom Categories.
Special instructions when authoring in the UMF: When structuring a Practice that is to exist within the Unified Method Framework (UMF), you must take into consider the UMF practice
conventions. For more information, see Guideline: Practices in the UMF.