Supporting communities of interest in a net-centric investment environment.

In the Department of Defense (DoD), significant effort has been devoted to conceptualizing a net-centric environment, particularly with respect to network-centric operations and warfare. In accordance, the DoD Chief Information Officer has issued a Net-Centric Operations and Warfare Reference Model and a Net-Centric Checklist. In addition, the Net-Centric Functional Capabilities Board is developing a draft Net-Centric Environment Joint Functional Concept. While the focus of the aforementioned products is largely oriented to the warfighter, DoD senior management, through various management initiative decisions, has embraced a movement toward a net-centric environment in an effort to effect net-centric business transformation and e-Government.

**********

In support of various Department of Defense (DoD) management initiatives, the information technology (IT) Acquisition Management TransformationRapid Improvement Team (RIT) Pilot Project has provided a blueprint for how the overall investment community can adapt to the net-centric environment (DoD CIO, 2004). After a three-year period of research and experimentation, the RIT Pilot Report has concluded that if we are to maintain information superiority for the warfighter, the investment community must benefit from net-centricity in the same way as the warfighting community. The thesis of the RIT Pilot Report is that the Department's functional and acquisition business communities can also employ net-centricity to achieve information superiority that in turn can yield unprecedented speed, agility, and self-organization for our IT/National Security System (NSS) investment process. This idea of self-organization is analogous to self-synchronization in network-centric warfare (NCW). Self-synchronization in NCW is employed to allow autonomous groups, each operating under the same mission, to rapidly adapt to changing operational circumstances.

The development of a net-centric investment environment creates an environment where a transparency in business operations and full adherence to post-before-process concepts generate a shared situational awareness to all stakeholders, both in terms of communicating current warfighter needs and in providing immediate access to cost, schedule, and performance measures. Oversight and governance must be transformed and decentralized to allow flexible operations. Risk management must become institutionalized and integrated into an evolutionary acquisition framework with smaller, more targeted development increments. Policies must be continually reevaluated to ensure that rapid and flexible responses are possible while still adhering to the law. Overall, a net-centric investment environment is best characterized as one that self-organizes to rapidly meet the constantly changing needs of the warfighter.

A net-centric environment is an environment in which there is immediate access in digital format to the information needed to conduct business. Such an environment requires digital connectivity and collaboration tools, an information-sharing work culture, and the ability to improve overall performance by disseminating best practices and lessons learned to the rest of the workforce. As is clear from business literature (Megill, 2004; Bennet & Bennet, 2004), trust is required to transform our current information-hoarding culture to an information-sharing culture. Our current information-hoarding culture is built on mistrust at all levels. The use of program office portals, ubiquitous connectivity, and collaboration tools is only effective if the underlying work culture is ready to accept this change.

Net-centricity embraces communities of interest (COIs) in large part because it has been shown that transformation in the work culture takes place within and through communities (Lotze, 2004). Communities are comprised of a group of people who work towards a common purpose. Notions of collaboration and knowledge sharing are central to the notion of community in the knowledge management literature. The current version of the draft net-centric environment functional concept defines a net-centric environment as:

   A framework for full human and technical connectivity that allows
   all DoD users and mission partners to share the information they
   need, when they need it, in a form they can understand and act on
   with confidence; and protects information from those who should
   not have it. (Net-Centric FCB, 2004)

While this discusses sharing the information needed, communities are also formed when we generate a shared awareness of the current situation, an understanding of the cross-cutting problems, and the mechanism for sharing innovations across the workforce.

BEST PRACTICES WITHIN COMMUNITIES

The Government Accountability Office (GAO) recently stated that the DoD's acquisition process is not doing a good job of incorporating best practices and lessons learned (GAO, 2004). While a response might be yet another best practices clearinghouse, one thing the literature makes clear--best practices are largely determined and communicated through community use (Megill, 2004; Wenger et al., 2002). While there are often committees to designate something as a best practice, there is a tacit process of innovation that occurs long before a practice rises to be designated as a best practice (Von Krogh, et al., 2000).

The development of functional communities that span both government and industry, such as those that are represented in the Acquisition Community Connection (ACC) portal (http://acc.dau.mil), serves to create shared government and industry knowledge repositories. This allows the collection and sharing of new ideas and practices in a way that leverages pockets of expertise across the workforce. New ideas that are experimented with in one location are able to become common practice through community interaction (Von Krogh et al, 2000). Over time, certain practices become preferred among community practitioners. It is only after many preferred practices are identified that some are deemed best practices. For example, many in the risk management community find a preferred practice to be a simple, qualitative approach matrix for assessing risk. If the majority of the participants identifying and assessing risk are only novice risk practitioners, this approach makes sense. However, risk experts generally agree that a best practice must involve a statistical analysis during the risk assessment process (Driessnack & Dickover, 2003).

More important, communities allow a significant transformation in how learning and training are conducted. In a net-centric investment environment, it is not just the program data that should be instantly accessible; the information and tools required to perform a task, solve a problem, or learn a skill should also be instantly accessible at the time of need. Communities can contextually combine policy, guidance information, performance support tools, and user-centered learning assets with community-developed knowledge assets such as: new ideas; common, preferred, and best practices; case studies; and lessons learned. Discussions among novices, practitioners, and experts can be integrated into a structure that, over time, becomes a robust knowledge resource that aids in learning and performance. This approach enables a transformation in learning in which the knowledge worker can focus on learning only what is needed to perform effectively.

DEFINING COMMUNITY: DIFFERENCES BETWEEN COPS AND COIS

In the DoD, the terms Communities of Practice (CoPs) and Communities of Interest (COIs) are both employed. Unfortunately, there is some confusion about where one term ends and the other begins. The distinction between these terms has become muddled because of the differences in the usage in the knowledge management literature versus the usage in the DoD net-centric literature. Within the knowledge management literature, CoPs are defined by the American Productivity and Quality Consortium as:

   Networks of people who come together to share and learn from one
   another face to face and virtually. They are held together by a
   common interest in a body of knowledge and are driven by a desire
   and need to share problems, experiences, insights, templates, tools,
   and best practices. (APQC, 2000)

Wenger, McDermott, and Snyder echo this sentiment of sharing among people when defining CoPs as:

   Groups of people who share a concern, a set of problems, or a
   passion about a topic, and who deepen their knowledge and expertise
   in this area by interacting on an ongoing basis. (Wenger et al.,
   2002)

Wenger, McDermott, and Snyder go on to differentiate a CoP from a COI in that the CoP is about something, whereas the COI is just seen as an informal network of people. In their eyes, it is the furthering of the practice within a knowledge domain that gives the CoP its uniqueness. In this view, which is prevalent in the knowledge management literature, CoPs are seen as more formal, whereas COIs are described as typically more informal in nature.

The knowledge management literature view of CoPs as formal entities and COIs as informal entities is almost diametrically opposed from the DoD net-centric literature, which defines the COI as the central organizing function that enables collaboration to work in a data-centric sense. For instance, the net-centric DoD frequently asked question (FAQ) defines a COI as:

   A term used to describe any collaborative group of users who must
   exchange information in pursuit of their shared goals, interests,
   missions, or business processes, and who therefore must have shared
   vocabulary for the information they exchange. The COI concept is
   very broad, and covers an enormous number of potential groups of
   every kind and size. Any element of a DoD component, e.g., domain,
   organization, task force, project team or group who must exchange
   information may be considered a "COI." (DoD CIO, 2004)

Furthering this thought, the newly released DoDD 8320.2, Data Sharing in a NetCentric Department of Defense, states that:

   Semantic and structural agreements for data sharing shall be
   promoted through communities (e.g., communities of interest
   (COIs)), consisting of data users (producers and consumers) and
   system developers.... (DoDD 8320.2, 2004)

In a DoD net-centfic view, COIs become the primary method for developing shared vocabularies for data exchange. COIs are also an essential step in building the shared situation awareness that enables self-synchronization of the warfighers. This operational stance for COIs is echoed in the DoD components. For instance, the Air Force Information and Data Management Strategy (IMDS) Policy directs Air Force data producers, the Major Commands and Functional Community leaders, to execute IMDS responsibilities by coordination through AF COIs (Department of the Air Force, 2004). COI tasks become very detailed and specific, including the development of metadata tags and portal-sharing specifications. In the net-centric literature, many COIs are formalized through chartered relationships with functional control boards or business domains, whereas CoPs are rarely, if ever, discussed.

This is problematic in that the contradictory stances between the knowledge management literature usage and the DoD net-centric usage has negatively impacted both understanding and implementation of COIs and CoPs in the DoD environment. The average workforce participant is often confused when exploration of the two terms yields different meanings. When combining these contradictory viewpoints, COIs become completely informal, yet also responsible for coming up with concrete metadata standards for system data exchange. This leads to misunderstandings of exactly what a COI is, how it functions, and how it would be supported. COIs that are tied to FCBs are envisioned in group grope meetings more as large integrated product teams (IPTs), while ad-hoc COIs become something extremely nebulous that other people out on the Global Information Grid (GIG) will magically figure out how to enact.

If COIs are confusing, the place of CoPs in the net-centric environment is even worse. Rarely are CoPs mentioned in policy, so they become something for people to do only if they have spare time. This is problematic, as CoPs are seen as the primary knowledge management and sharing vehicle across the workforce. In one contrasting example, a DoD management initiative directs the development of an IT Community of Practice (DEPSECDEF, 2004). But, because CoPs are not in the policy, their place in the workforce has been marginalized. In practice, this makes the success of CoPs an uphill struggle for the CoP support team.

COMMUNITY CATEGORIZATION: WHICH MODEL DO WE USE?

The other problem in understanding what to do with communities involves the incredibly broad definition given for communities. If communities are defined as virtually any encounter between more than two people sharing information, there is very little guidance that can be provided, either in modes of operation or in community support requirements. This, in essence, goes back to Kenneth Boulding's famous discussion of building categories for different systems types in general systems theory. He stated:

   A general theory does not seek to establish a single,
   self-contained general theory of practically everything which will
   replace all the special theories of particular disciplines. Such a
   theory would be almost without content, and all we can say about
   practically everything is almost nothing. Somewhere between the
   specific that has no meaning and the general that has no content
   there must be, for each purpose and at each level of abstraction,
   an optimum degree of generality. (Boulding, 1956)

To paraphrase, in defining communities as broadly as they have been, all we can say about practically all communities is almost nothing. For this reason, there have been a number of attempts to provide a lower level of specificity required to make communities actionable through the development of different category structures used for grouping communities. In attempting to capture the diversity into a coherent model, everyone takes a different approach based on individual needs and understanding of the dynamics involved. It is hoped that we can find a structure that can represent both the warfighter and investment communities. This is important because in a net-centric investment environment, the interaction amongst the warfighter, requirements personnel, and acquisition program will be tighter than ever (IT R1T Pilot Report, 2004).

In the knowledge management literature, Wenger, McDermott, and Snyder (2002) describe the variants of CoPs on a number of different scales including:

* size (small or big).

* length of the life span (long-lived or short-lived).

* location (collocated or distributed).

* composition (homogeneous or heterogeneous).

* organizational boundaries (within a business unit, across business units, across multiple organizations).

* level of planning (spontaneous or intentional).

* level of recognition (unrecognized or institutional).

Within DoD, a number of these factors are not relevant. Most of the communities envisioned are substantially larger than most of the CoP literature, which usually focuses on communities of 50 or fewer. In the acquisition world, communities can potentially be made up of thousands of government and industry participants. Additionally, most DoD communities are distributed, so co-location is not as critical a variable. However, the rest of the characteristics, including life span, composition, organizational boundaries, level of planning, and recognition all impact the potential nature of DoD communities.

In 2001, the DoD Acquisition Knowledge Management Working Group defined communities along a taxonomy of Product, Executive, Initiative-Specific, and Functional communities (Sylvester, 2001). The Artificial Knowledge Management System (AKMS) model (see Figure 2) was based in part on the types of communities that were envisioned at the time. Product communities were seen only as programs and their stakeholders. The executive communities were geared more toward policy change activities, such as the DoD 5000 updates. Functional communities, while often logistics-related at that time, were eventually going to be based around the functional career fields. The initiative-specific communities were geared around hot initiatives, such as the Reduction of Total Ownership Cost (RTOC), that involved a number of functional areas.

[FIGURE 2 OMITTED]

The DoD net-centric FAQ list defines COIs on a scale of expediency versus institutional, and functional versus cross-functional characteristics (DoD CIO, 2004). The net-centric FAQ, in describing this break-out, makes clear that the rationale for these distinctions concerns the sharing of data assets:

   Expedient COIs typically exploit existing resources (data assets)
   produced and exposed to the enterprise for discovery and reuse.
   These resources include vocabulary, developed applications, and
   other data assets ... Institutional COIs tend to conduct activities
   such as develop vocabularies to provide a common understanding of
   terms used within the community, develop logical data models,
   register community specific extensions to discovery metadata
   schemas, and identify other data-related capabilities and
   services.... Cross-Functional is the idea of Functional Areas, for
   instance, Heath Affairs, Personnel & Readiness and Environmental
   working together to address data issues or topics that cross the
   boundaries of a single Functional Area.

While the sharing of data assets is critical for building the GIG, delegating this responsibility to COI as its primary function has some negative side effects. Collaboration, as a term, has as many different definitions as community does. In transforming the COI to a data sharing input vehicle, we have in essence divorced the term community from its central role in the knowledge management literature, which centers on knowledge sharing among people.

This really brings us to a long-standing debate that took place when discussing the integrated digital environment (Megill, 2004). Then with the integrated digital environment, and now with the net-centric environment, the question still remains whether we see the core of collaboration as primarily involving the exchange of data between different information systems via discovery services, or do we see collaboration as a function that primarily centers around people. If it centers on the connection of information systems, then discovery services and metadata standards become critical. If we see it as involving people, we tend to spend more time discussing trust and work culture transformation.

In reality, both the automatic connections and the person-to-person information sharing are essential for different reasons. In a real-time war environment, there is clearly a need to rapidly download information essential for engaging the enemy. But also critical are the ongoing business processes that relate to creating periodic information products. If a person is responsible for creating a monthly intelligence assessment, while he or she might be able to discover key information from another agency to include in this month's report, the availability of that information for the next month's report cannot be relied on. This type of process-centric collaboration occurs only if the two agencies develop a knowledge-sharing relationship (through an ad hoc COI, for instance) in which each agency understands the new interconnections between the information products and eventually even develops the information products with that interconnection in mind.

The Net-Centric Joint Functional Concept taxonomy of COIs has a simpler, more straightforward breakout, with communities listed along two axis points: life span and whether the communities are formal or informal in nature (see Figure 4). However, in the net-centric investment world, the Permanent/Informal box presents us with a dilemma in that it contains only standing COIs. Standing COIs in this model would include both those tied to FCBs and domains and functionally based CoPs. The primary function of the standing COIs is to work out metadata tagging schemes, while the functional CoPs are a knowledge-sharing and knowledge repository vehicle. Each community type would require different modes of interaction and would have different support concerns.

Even with this ambiguity, in looking at the available models, this model provides the easiest delineation for integrating the different communities from both the operational world and investment world into one chart. In looking at the net-centric investment environment, we find that there are a number of different communities that can be identified:

* Program office and its stakeholders: This is essentially looking at the program as a community. In practice, it functions through a formalized IPT structure.

* Standing COI tied to a domain or FCB: The standing COIs are responsible for working out the sharing of data assets.

* Functionally based COIs (CoPs): The CoPs are responsible for managing the knowledge associated with the particular knowledge domain. Additionally, the CoPs become a vehicle for on-the-job learning and performance support.

* Product-oriented working groups: Product-oriented working groups are tasked with finalization of a product, such as an update to the 5000 series.

* Ad hoc communities: Ad hoc communities are the catch-all category, in that groups of people can come together for a myriad of reasons, including operational, functional, or exploratory.

With slight modifications, we can use the net-centric FCB approach to encapsulate all communities in both the operational world and in the net-centric investment environment. In this approach, the CoP becomes a type of COI that is focused on a knowledge domain and is interested in furthering the state of practice. In breaking them out in this way, we can differentiate the support approach required for Standing COIs versus Functional COIs (CoPs).

Most of the community types already have detailed approaches for growth and sustainment. The traditional organizations (even if we now call them communities) already have common methods of operation. Working groups will differ in size, scope, and approach, but these too already have clear methods of operation. The Standing COIs, while new, have had significant work devoted to determining method of operations, products, and overall integration with the FCBs, so there is no reason to outline them here. However, two areas that need elaboration are the functional COIs and the ad hoc COIs. The functional COIs (CoPs) need elaboration because of their relatively large size in DoD when compared to the bulk of the CoP literature. The ad hoc COIs, while good in concept, have not had their support concepts fleshed out in any level of specificity.

FOSTERING AND SUPPORTING AD HOC COMMUNITIES OF INTEREST

Ad hoc COIs, as an idea, have engendered a lot of enthusiasm, yet there has been relatively little specificity provided in the net-centric documentation. The idea is that to effectively meet new and previously unforeseen challenges, ad hoc COIs would allow the workforce to rapidly respond and self-organize to address the challenges. Through discovery services, the information products on the GIG will have metadata that will allow the information consumer to identify and decide whether the information product is useful. In some cases, an information consumer might decide to form a COI with other workforce participants. The question still being discussed is how to transfer the ideas for ad hoc COIs into an operational approach for implementation. For instance, how does an ad hoc COI form? How would the people forming an ad hoc COI figure out whom to invite and why would they want to come? How would organizations work out the resourcing issues involved in having their people working on items outside their mission area?

The answer lies in applying tools from social network analysis to the GIG architecture. Social network analysis involves understanding the unofficial social networks that allow one to gain access to necessary information and to collaborate with colleagues to actually get things done (Cross, 2004). The COI is formed when someone or some group decides there is value in establishing a community. For an ad hoc COI to form, there must be automated social software tools in place that provide members of the workforce with the shared situational awareness necessary to provide the person-to-person connection-type information they need to decide if there is expertise available that can help them. Ideally, the net-centric environment should be able to identify and make discoverable natural clusters of users who should or could be collaborating. Users may be clustered based on the type of information products they produce, the information they access, or the initiatives they work. The necessary element is for the information products or knowledge assets in a net-centric environment to have contextual information fled to them in the form of who is accessingit and for what purpose.

To enable ad hoc COIs to become a normal part of our daily work, at least three key parts need to be in place:

1. A Method to Identify Potential COI Members.

2. A Method to Request Participation.

3. A Method for Organizations to Share Resources.

A METHOD TO IDENTIFY POTENTIAL COI MEMBERS

For ad hoc COIs to work, there needs to be a method for people to find each other. The reasons for establishing a COI will be as varied as the time frame for COI existence. There may be a number of reasons for wanting to include a person, role, or organization, including the knowledge artifacts people have published, the responsibility of their job role, the types of queries they have been running or the initiatives they are working on, or the organization's mission.

The COI initiator or requestor needs to have a method for easily locating these people in the course of the normal work process. One way to do this is to employ social software or social network analysis tools tied to information product access and use. In this model, all the footprints for knowledge access are captured and shared as security access permits. This means when people access a knowledge asset, they should be able to see:

* The knowledge asset/information product creator.

* How often it has been accessed.

* The people who have accessed this asset.

* The projects and initiatives that have accessed this asset.

* Formal relationships with other knowledge assets.

* Other knowledge assets accessed by these same people.

* Customized taxonomies, ontologies, or key user lists that this asset belongs to or is linked to or contained within.

* Discussions related to the knowledge asset.

This level of visibility is critical to the creation of ad hoc COIs. In effect, this allows our knowledge assets on the GIG to become the driver in developing the key information-sharing relationships that are the precursor to a collaborative, sharing workforce.

A METHOD TO REQUEST PARTICIPATION

Once the COI initiator has a sense of who should be interested in participating in an ad hoc COI, there needs to be a standardized method of sending a request for participation. If this is not standardized and agreed upon, existing organizational barriers will serve to minimize any significant ad hoc collaboration. The request must include a clear rationale for both the COI's existence along with why the requested person should participate. Most important, the rationale should include a priority rating (critical, major, minor), anticipated time frame (immediate, short term, long term, or undetermined), and anticipated level of effort requested. The rationale should include an automated report of the social network analysis footprint that originally prompted the initiator to request participation.

A METHOD FOR ORGANIZATIONS TO SHARE RESOURCES

In addition to a request for participation, there needs to be an agreed-upon mechanism for sharing resources across projects and organizations. This might involve each organization maintaining a resource pool of hours for ad hoc COI participation against which an organization can charge. This approach would allow DoD leadership to actually assign a cost and level of effort for the amount of knowledge sharing they are expecting to occur. Most important, industry participants should be included in this approach as they may have key expertise that could make the difference, especially in a critical, high-priority, time-sensitive situation.

SUPPORTING LARGE-SCALE COMMUNITIES OF PRACTICE

In the DoD acquisition and investment world, our functional COIs are potentially vast. With approximately 100,000 government workers and 1 million contractors, the potential number of participants for each functional community could easily reach into the thousands. This creates a different dynamic from what we find in the knowledge management literature. The knowledge management literature tends to look at small-size communities in which the dynamic involves a large up-front effort, followed by an ever-smaller support requirement as the community stabilizes (Wenger et al., 2002). Small communities follow this trend because once everyone in the community understands the norms and methods of interaction, less support is required to keep them going. But in large-scale communities, as the level of success increases, the number of new members increases. This leads to an increasing need for overall caring and support until a steady state is reached.

To effectively manage large-scale communities, a number of support structures need to be in place. Most important is the idea that large-scale communities, if they are to be effective, require a support staff to provide nurturing and growth, along with supporting various community knowledge management functions. Additionally, a number of capabilities should be present in large-scale communities, including:

* Member tracking and relationship system: The member tracking system is necessary for guiding community interaction efforts.

* Methods to determine community needs: Within each community, it is necessary to determine the community member's needs. These may run the gamut from basic information to detailed discussions of problems to rigorous needs assessments.

* Methods to determine how to structure and integrate the content: The content in the community section should be structured for optimum performance support and community collaboration.

* Requirements fulfillment team: There are a number of requirements that arise in the building of communities. A requirements fulfillment team is key to making these a reality. This team will have a number of skill sets geared towards fulfillment of the requirements. Many options exist for meeting the requirements, including:

--Custom development of application and support structures.

--Purchase of single commercial off-the-shelf (COTS) software solution for requirements fulfillment.

--Value-added-resale of COTS software that is enhanced with additional features.

--Combination of COTS software with additional customization.

--Development of an ensemble of COTS software products to meet requirements needs.

* Content Management System: Through both well-thought-out, agreed-upon processes and automated tools, the support team can manage the site-wide content over time. It is important that the content management system be robust enough while not becoming overly burdensome. If it becomes too difficult for the community members to make contributions and act on the content, there will be no interaction.

* Robust Search Capability: The community site needs a robust search capability to allow both active participants, and external users to be able to find useful content quickly. Most important, content needs to be searchable via common Internet search engines.

* Community Interaction Measures: Community interaction refers to the level of participation within a community of practice. Community interaction is the measure of the health of a community. This is the engine that leads to more valuable knowledge contributions, more subject matter expert participation, more learning opportunities, and more overall value for the community. Community interaction can occur online or offline. Community interaction measures can be both qualitative and quantitative and should drive the overall community development process actions.

CONCLUSION

This article provides guidance on applying communities within a net-centric investment environment. Unfortunately, the current usage of COI in net-centric environment literature is significantly different from its usage in knowledge management literature and is further confused by the absence of CoPs from net-centric literature. After gaining a clearer understanding of the different usages, COIs and CoPs are two complimentary terms that can co-exist. The key to this merging involves expanding the net-centric notion of COIs from being primarily a mechanism to develop data exchange standards for consumption by discovery services to being a vehicle for collaboration among people, which holds just as much priority as functioning as a data exchange service between information systems.

FIGURE 3. NET-CENTRIC FAQ COMMUNITIES OF INTEREST CHARACTERISTICS

Functional                        Cross-Functional

Expedient

* Tactically driven               * Tactically driven
* Implied authority               * Derived authority
* Formal processes modified       * Ad hoc processes
  for need                        * Many entities
* Relatively many entities        (e.g., Forward-deployed
(e.g., New Imagery Analysis              JTF planning
       capability for Damage             New Threat Response)
       Assessment)

Institutional

* Explicitly recognized           * Explicitly or implicity
* Longer term                       recognized
* More formalized processes       * Longer term but priority driven
  based on span of control        * Blended processes resulting from
* Relatively few entities           agreements
(e.g., PSAs such as Logistics)    (e.g., JS area such as Battlespace
                                         Awareness)

FIGURE 4. NET-CENTRIC FUNCTIONAL CAPABILITIES OPERATIONAL SPACE

         Formal                           Informal

                         Permanent

       Traditional                        Standing
      Organizations                      Communities
 (Services, Joint Staff)                 of Interest

                         Temporary

     Working Groups                        Dynamic
      (Task Force,                       Communities
     "Tiger" Teams)                      of Interest

FIGURE 5. COMMUNITIES IN A NET-CENTRIC ENVIRONMENT

            Formal                              Informal

                               Permanent

                                                Standing
                                         Communities of Interest
          Traditional                    (Tied to FCBs/Domains)
         Organizations
    (Services, Joint Staff)                    Functional
(Program Office & Stakeholders)          Communities of Interest
                                        (Communities of Practice)

                               Temporary

        Working Groups                           Dynamic
  (Task Force, "Tiger" Teams)            Communities of Interest
   (Product Working Groups)                   (Ad-hoc COIs)

REFERENCES

Alberts, D. S., Garska, J. J., & Stein, F. P. (1999). Network centric warfare: Developing and leveraging information superiority. Retrieved February 15, 2005 from http:/ /www.dodccrp.org/publications/pdf/Alberts_NCW.pdf

Alberts, D. S., & Hayes, R. E., (2003). Power to the edge. Funded by the Department of Defense, Command and Control Program. Retrieved February 15, 2005 from http://www.dodccrp.org/publications/pdf/Alberts_Power.pdf

American Productivity and Quality Center. (2000). Successfully implementing knowledge management. American Productivity and Quality Center Benchmarking Study.

Assistant Secretary of Defense for Networks, Information and Integration. (2004, December 2). Data sharing in a net-centric Department of Defense. DoD Chief Information Officer (DoD Directive 8320.2). Washington, DC: Author.

Bennet, A., & Bennet, D. (2004). Organizational survival in the New World. Amsterdam: Butterworth-Heinemann.

Boulding, K. (1956). General systems theory--The skeleton of science. General Systems. Management Science, 2(3), 197-208.

DoD CIO Information Management Directorate. (2004, May 19). Communities of interest in the net-centric DoD: Frequently asked questions (FAQ) (Version 1.0). Washington, DC: Author.

Driessnack, J., & Dickover, N. (2003, Spring). Risk community building inside the program management community of practice (PM CoP). Acquisition Review Quarterly. 10(2), 107-114.

Government Accountability Office. (2004, July). Information technology: DoD's acquisition policies and guidance need to incorporate additional best practices and controls. (GAO-04-722). Washington, DC: Author.

Lotze, E. (2004). Work Culture Transformation: Straw to Gold--A Modern Hero's Journey. Munchen, Germany: K. G. Saur.

Megill, K. (2004, March). Thinking for a living: The coming age of knowledge work. Munchen, Germany: K. G. Saur.

Office of the Assistant Secretary of Defense for Networks and Information Integration/Department of Defense Chief Information Officer. (2004, May 12). Net Centric Checklist: Version 2.1.3. Washington, DC: Author.

Office of the Assistant Secretary of Defense for Networks and Information Integration/Department of Defense Chief Information Officer. (2004, December 20). IT acquisition management transformation rapid improvement Team Pilot Report: A blueprint for IT investment in a net-centric environment (Draft Version 0.5). Washington, DC: Author.

Secretary of the Air Force, Chief of Staff. (2004, March 3). Air Force information and data management strategy policy. Washington, DC: Author.

Sylvester, R. (2001, May 16). DoD acquisition knowledge management system (AKMS). National Defense Industrial Association (NDIA) 3rd Simulation Based Acquisition Conference.

United States Joint Forces Command. (2004, November 8). Net-centric environment joint functional concept. Net Centric Functional Capabilities Board (FCB): Version 0.9. Washington, DC: Author.

Von Krogh, G., Ichijo, K., & and Nonaka, I. (2000). Enabling knowledge creation: How to unlock the mystery of tacit knowledge and release the power of innovation. Oxford, United Kingdom: Oxford University Press.

Wenger, E. McDermott, R. & Snyder, W. (2002). Cultivating communities of practice. Boston, MA: Harvard Business School Press.

Noel Dickover, the president of Communibuild Technologies, is an established human performance technology consultant with expertise in Communities of Practice (CoPs), knowledge management, performance-centered learning, usability and interface design, and organizational change. In support of the Commercial Policies and Oversight Directorate within the Assistant Secretary of Defense for Networks and Systems Integration, DoD CIO organization. Dickover serves as the coordinator for the Information Technology CoP on the Acquisition Community Connection (http://acc.dau.mil/it). E-mail address: [e-mail])