The library provides users, performing the functional responsibilities of leadership roles, an ability to know, understand and communicate, the basic and fundamental resources, interdependencies and commitments, involved in realizing, operating and sustaining business capabilities.
The use of the library enables and assures users have the basic and fundamental knowledge needed to successfully participate in the management of cross-functional, multi-organizational efforts. Either performing their own work, or collaborating with others, on a multi-team effort.
Operating within the bounds of this 'highest-order' knowledge, the user is enabled and assured they can utilize the actual detailed knowledge of their organization, in a truly better, efficient, effective way. Totally integrated across all the actual specific resources involved in the organization’s specific detailed-level of work and knowledge.
Because the Library was developed to support the Workforce Virtualization Transformation Capability of the Institute, the library is used to provide the knowledge needed to control large, complex, enterprise-wide business efforts, involving many teams of workers, of many knowledge domains. For example, operating at, or developing an enterprise-wide-capability, as in ERP-type solutions, or managing and controlling a business transformation needed for the enterprise to operate digitally and/or virtually.
On the other side of the argument, it should be noted use of the library delivers the same level of value and satisfaction on cross-functional, multi-organizational initiatives of smaller scope and scale, such as a program or project.
The knowledge is differentiated by Knowledge Space Topic. Each Knowledge Space is presented as one or more web pages, dedicated to the topic.
Each presents the knowledge on the topic, from the perspective of the topic, with
-
links to subtopics provided on the right sidebar of the page,
-
links in text and metadata, to bi-directional references within the library,
The Knowledge is structured, aligned, and displayed to be quickly used to develop a virtual workforce capability, work in a virtual working environment, and manage a virtual workforce.
Therefore, the Library provides the Knowledge needed to prepare for, achieve, and sustain the ability to realize workforce virtualization.
Using the Library to Perform Work
To use the library to help perform work, users self-associate themselves to one or more knowledge domains.
Knowledge domains are associated to one or more capabilities and the resources needed by the relationships established within the library. The knowledge domains define the type of work the people are involved in, based upon the type of knowledge needed and the function the work serves.
For example, a user that practices, aspires to practice, or just interested in knowing about, managing and controlling programs, projects, and other initiatives, and interested in knowing, understanding, and communicating the basics and fundamentals of what their responsibilities involve and who/what they support and supports them, would associate themselves to the Program-Project Management Domain.
The associated knowledge space then provides the user with the interrelationships with, and interdependencies on, the use of their work to support others, and on the work of others to support them, in order to properly support the overall effort everyone is involved in.
In this case the association is to the Program-Project Management Domain Knowledge Space.
From the right sidebar it can be seen the knowledge is presented in 3 web pages, dedicated to the program-project management domain. This space presenting the knowledge from the perspective of managing and controlling a program or project.
On the right sidebar of the page, the knowledge space links to the home page of the domain, and to the 2 subtopic pages of Analysis and Planning, and Execution and Control of programs-projects.
There are also links in text and metadata, to bi-directional references within the library to other resources related to program-project management.
Most notably, at the bottom of the page is the metadata reporting section providing the interconnections and interdependencies between resources. It is through this reporting that the power, value and satisfaction to be had in using the library is validated.
It demonstrates the level of availability, handling and control the user can have over the enormous amount of knowledge associated with what it takes to successfully perform cross-functional, multi-organizational work. There is no searching involved. All relevant knowledge is delivered to the knowledge space.
Domain
Metadata reporting begins with the knowledge domain itself. Opening the report we see the object ID, the name as the link to the metadata popup window, the short description and link to its knowledge space.
Through the grouping the breakdown structure is shown, starting with Knowledge Domains > Program Operations Domains > Program-Project Management Domain.
The title of the grouping is a link to the metadata popup window for the object, with short descriptions and links to knowledge spaces.
In this case the Knowledge Domain and Program Operations Spaces with further elaboration on the topics and the metadata reporting sections.
In subsequent reports below the domain report, the reports are opened to see what resources involve, or are involved in, the work of the knowledge domain.
Domain involved in Capabilities
The next report in the reporting section shows the Program-Project Management domain is involved in 3 capabilities. One is categorized as an enablement-type of capability. The others are categorized as management-type capabilities.
Clicking on the name of the VW Management, Leadership & Coordination Capability launches the metadata popup window for the capability object.
This window shows the metadata for all resources with direct relationships to the capability.
It therefore reports only on the goals the capability supports, and the processes involved in implementing it.
Since the Program-Project Management Domain is involved with the capability, the same data will be reported in the Goals and Processes reporting for the knowledge domain.
Links to the knowledge spaces are provided here and in the knowledge space reporting, and these resources are explored here, later in the reporting.
Through use of the metadata popup windows the user can see that all capabilities support the same set of goals.
In an aligned and balanced enterprise, architected to serve its purpose, it is typical of top-level initiatives and associated operations to share the same set of top-level goals. The basic and fundamental reason for this is to integrate shared resources and force resolution of conflict when it arises.
Importantly, the composition of processes used to implement the different capabilities vary.
The basic and fundamental reason for this is the capability has a specific purpose. Each purpose drives an associated set of specific functions needed to realize it. Each function is provided by a specific process, the combined output of all processes, the outcome, satisfying the specific purpose of each capability.
The VW Management, Leadership & Coordination Capability, being a management capability, involves command-type processes, the capability having a program management purpose, needing program operations management functions.
The VW Governance Capability, also being a management capability, involves control processes, the capability having an oversight purpose, needing program technology management and executive management and assurance functions.
The Workforce Virtualization Transformation Capability, being an enablement capability, involves enablement processes, the capability having a business transformation purpose, needing program technology management, enterprise design, and executive management functions.
More information on the capability is available to the user at the knowledge space for the capability
Domain involved in Goals
The Program-Project Management domain is involved in 12 goals. Ten tangible goals and two intangible as shown in the report. The report provides the ID and name of each goal, the name being a link to the metadata popup window for the goal. It also provides a brief description of the goal and a link to its knowledge space.
Taking the link to the knowledge space provides further elaboration on the topic, as well as its metadata reporting section for the goal for all associated resources.
Domain involved in Processes
Returning to and continuing with the knowledge domain reporting, the Program-Project Management Domain is involved in the Program-Project Management Process used to implement these 3 capabilities.
Clicking on the name of the Program-Project Management Process launches the metadata popup window.
This window shows the metadata for all resources with direct relationships to the process.
It therefore reports only on the work products used and produced and the responsible lead role of the process.
Since the Program-Project Management Domain is involved in the process, the same data will be reported in the Processes reporting for the knowledge domain.
Processes use and produce work products. Work products are a resource one process produces as an output which other processes use as an input. In other words, the work products of one process are used to support the development of work products produced by other processes.
Domain uses Work Products
The Program-Project Management Process uses 183 work products produced by other processes. For example, the 28 work products of the Supply Chain Management Process.
This report provides the user quick access to the definition of what the work product is, to the links to its metadata, and to the work product’s knowledge space, further describing the work product through content and metadata reporting on:
-
what process produces it,
-
what SOP addresses it,
-
which lead role is responsible,
-
the knowledge domain involved,
-
the associated workforce (e.g., skills, abilities and other talents),
-
working environments (e.g., facilities, tools and equipment), and
-
technical solutions (e.g., standard solutions and reference architectures).
Many of the plans listed are referenced by and used in the Program-Project Management Process to produce the Program-Project Management Plan. For example, the Supplier Management Plan.
If for instance, the program-project manager has not received the Supplier Management Plan and wants to know who to contact about it, by exploring the link to the Supplier Management Plan knowledge space, the user can see this plan is the responsibility of the Supply Chain Manager role. By knowing who in the user's organization is fulfilling the Supply Chain Management role, the user then knows who to contact.
The point to be made is managing and controlling 183 types of work products is a large amount of work requiring the attention of the producer and users of the work products. It is difficult, if not possible, to track and address this work without a list of it to reference, and even harder yet to remember all the associated resources which support the work.
The library places the knowledge the user needs at their fingertips, generally either displayed on the page, or a click away from it.
Domain produces Work Products
Continuing down the metadata reporting section, the Program-Project Management Process produces 32 work products used by other processes.
For example, the Program Management Plan, covering the specifics including and beyond the generic content all Management Plans.
Domain involved in Lead Roles
Next in the metadata reporting section, the user can see the Program-Project Management Work Products are the responsibilities of the Program-Project Manager, the lead role of the Program-Project Management process of the Program-Project Management knowledge domain.
Clicking on the name of the Program-Project Manager launches the metadata popup window.
This window shows the metadata for all resources with direct relationships to the lead role.
It therefore reports only on the SOPs, Workforce, Working Environment and Technical Solutions the lead role uses.
Since the Program-Project Management Domain is involved with the lead role, the same data will be reported in the Lead Roles reporting for the knowledge domain.
The production and use of work products are the interconnections which define the interdependencies between the processes and lead roles, and in turn, the interdependencies between their related knowledge domains and lead roles involved in the total work the processes support.
Processes are defined through Standard Operating Procedures (SOPs). SOPs define the minimum essential activities (processes) the practitioner must perform. The lead role of a process, and other roles involved in the process, uses SOPs to communicate, command, control, and otherwise lead the process activities.
Domain involved in SOPs
Next in the reporting the user can see the program-project management domain utilizes 20 SOPS.
In this example, many of the SOPs involved in the Program-Project Management Process are used to produce the 32 types of Program-Project Management work products. The point to be made is 20 types of SOPs is a large amount of work requiring the attention of the lead role. As with work products, it is not easy to track and address this work without a list of it to reference, and even harder yet to remember all the associated details.
By defining the details of the leadership process of a basic and fundamental knowledge domain, SOPs close the loop with the lead role responsibility for work products used and produced, in leading the user’s business process definition. In this way the user will ‘know’ the connections between the SOPs they need and their business processes and other process assets they actually have through their organizations. In other words, the library helps the user more efficiently and effectively use their process assets, with the knowledge in the library guiding the way, and the user’s documentation describing how their organization desires the work to be performed.
Domain involved in Workforce
The Program-Project Management domain is involved in the following characteristics of the workforce.
Domain involved in Working Environments
The Program-Project Management domain is involved in the following working environments.
Domain involved in Technical Solutions
The Program-Project Management domain is involved in the following technical solutions.
Using the Library to Realize a Capability
To use the library to realize a capability, users self-associate themselves to one or more capabilities.
Capabilities are associated to knowledge domains and the resources they need by the relationships established within the library. The capabilities define all the types of work involved in its realization, based upon the type of capability it is, and what resources it needs to realize it.
For example, a user, interested in knowing, understanding, and communicating the basics and fundamentals of the resources, they and others are responsible for, and the way they fit into the overall effort in leading a virtual team capability, would use the knowledge space of the capability to be explored.
In this case of multiple knowledge domains the user has the need to utilize the knowledge spaces of capabilities they are involved in, their own knowledge domain spaces, and the spaces of the knowledge domains they are associated with in the realization of the capability.
For example, a user that practices, aspires to practice, or just interested in knowing about, architecting enterprise IT, and interested in knowing, understanding, and communicating the basics and fundamentals of what their responsibilities involve and who/what they support and supports them, would first associate themselves to the IT Architecture Domain, and explore the IT Architecture Domain Knowledge Space to see what SOP activities they are involved in leading their effort, and the associated work products they are responsible for.
What this means is, the IT Architecture user, in addition to using the library for the IT architecture work they perform, would use it to integrate with all the other domains associated with the capabilities they are involved in, including realizing the WV Transformation Capability.
Capability involve(s) Knowledge Domains
The WV Transformation capability involves 15 knowledge domains including the Enterprise Development Domains, specifically 5 Domains, each with a process, lead role and sets of work products, SOPS and other resources needed.
In other words, the IT Architecture user, in addition to responsibility for their own work, as described by the knowledge domain's involvement in the capability, also has the responsibility to know, understand, and able to communicate all the work to be performed, and the associated interdependencies between the work of the other 14 domains involved in the overall effort.
Capability produces Work Products
The WV Transformation capability involves 282 work products.
The significance of this is, the IT Architecture user has the responsibility to understand the interconnections and interdependencies of 282 work products to enable and assure their work on the program-project is successful. But it should be noted that there may be several instances of each of the work products.
Depending on the scope and scale of the program-project, there could be 1000’s of actual work products. The point being, from the perspective of managing and controlling a business capability, there are more work products to know, understand and communicate than any one person can keep track of without the aid of the library reporting, Otherwise, minimum essential work products will be missed, misused, or underutilized.
Capability involve(s) SOPs
The WV Transformation capability involves 105 SOPs.
In this example, many of the SOPs involved in the capability are used to produce the 282 types of work products. The point to be made is 105 types of SOPs is a large amount of work requiring the attention of the lead roles. As with work products, it is not easy to track and address this work without a list of it to reference, and even harder yet to remember all the associated details.
Using the Library to Be Successful
As shown in the use cases above, each knowledge domain and each capability is constructed as a grouping of workers (people) with the knowledge/skills/abilities, and an associated set of processes, information, technology and other resources needed, to perform the associated type of work the knowledge domain is involved in.
Regardless of whether the user is in the knowledge space of a knowledge domain or a capability, the most important reports to the user are always the SOPs (activities) and work products (inputs and outputs), as these reports define their responsibilities in terms of the work to be performed and the results expected.
This is true whether there are instituted business procedures, or not, as even if the process defining the activities is tribal knowledge, these minimum essential actions are necessary for the business to operate correctly.
When these activities are missed, or not fully addressed, issues arise, whether in a non-conformance to a business compliance requirement, or simply impacting the activities of other practitioners.
In regard to impacting the activities of other practitioners, the actions taken are always intended to produce results, the results most often being a work product, a tangible item whose dependencies are often unforgiving.
If a minimum essential work product input is missing, late, or incomplete, it can negatively affect many other minimum essential work products.
Furthermore, unacceptable results lead to unacceptable outcomes, and therefore, dissatisfied customers, stakeholders, and shareholders.
To be successful, lead roles must account for all the SOP activities and work products, and then follow the work, to know the status and state of the activities and work products. They must enable and assure the activities are performed and the work products produced as planned and expected. Status and state of the work must be known, understood and communicated in order to keep the overall flow of work (the activities and work products of all practitioners) under control, achieving goals, and accomplishing the mission.
It should be noted that in using the library, lead roles/processes/knowledge domains are 1-to-1 relationship elements in relation to each other, but they also have 1-to-many relationships with other elements.
The problem is the quantity of some of these other elements, far exceeds the ability to show their structure graphically.
Processes produce and use many work products and involve lead roles. Lead roles use many SOPs. The relationships can only be presented in the metadata reporting.
