Context-speciﬁc intellectual capital— The next link in ...€¦ · links to matching work breakdown structures. This primacy of outputs rather than tasks is orthogonal to many

Context-specificintellectual capital—The next link in theknowledge chain

by C. A. Singer

Intellectual capital reuse and sharing in thespecialized domain of project planning andexecution are the focus of this paper. The keyexpansion beyond ordinary intellectual capitalis pairing a context-specific intellectual capitalstructure with a matching context-specificintellectual capital management process.Beyond the fundamentals of gathering,archiving, indexing, and subsequentlyretrieving the appropriate intellectual capital,we explore both the context-specific structureand the related context-specific processspecifically tailored to project planning andproject execution. This tailored structure andprocess allow intellectual capital frommultiple, different projects to be artfullyblended, combined, and shared amongmultiple organizations and project teams.

Traditionally, the two approaches to managingprojects are: task-oriented and output-oriented. Inthe task-oriented approach, a work breakdown struc-ture defines the phases, activities, and tasks that mustbe accomplished. In contrast, an output-oriented ap-proach focuses on the work products that need tobe created during the project. In this paper, wepresent a work-product-dominant approach thatlinks to matching work breakdown structures. Thisprimacy of outputs rather than tasks is orthogonalto many conventional approaches for process def-inition, but lends itself well to a robust intellectualcapital (IC) management approach.

The author’s experience with context-specific intel-lectual capital (CSIC) is primarily with developing IC

for software development and maintenance projects,most recently within the IBM Global ServicesMethod. However, the approach described in thispaper is applicable to a wide range of process-ori-ented and project-oriented endeavors.

This paper first presents the structure of IC, defin-ing terms and providing an example from softwaredevelopment and maintenance. It next reviews howa project manager might use CSIC during projectplanning. Having defined CSIC and shown how it isused, the paper then defines and examines the fourelements of the CSIC Engagement Model Lifecycle:authoring, project preparation, project execution,and experience harvesting. After discussing thesefour elements, an organizational “superstructure” formanaging CSIC is described. To evaluate the poten-tial effectiveness of CSIC, the reasons why projectsfail are discussed and the result is related to CSICuse as a mitigator. Finally, additional observationsand conclusions are given. This paper is based on expe-rience and is not intended to be a research paper.

Skills-based approach. Skills imply the capacity foraction toward some application. As such, much ICis prescriptive and attempts to supplement individ-ual skills to achieve a solution or solve a problem.In organizations, IC may also focus on the team asan integrated collection of individuals. Both for theindividual and the team, the application of IC focuses

�Copyright 2003 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

SINGER 0018-8670/03/$5.00 © 2003 IBM IBM SYSTEMS JOURNAL, VOL 42, NO 3, 2003446

on either performing specific tasks or producing spe-cific results.

Skills and intellectual capital go hand in hand. Tobe useful, the IC must be geared to the skill level ofthe practitioner. In the project domain, the tasks tobe performed must be within the capabilities of theassignee. Similarly, the task descriptions and workproduct descriptions must be suitable for that as-signee. A task such as “assure that the database isnormalized” may be sufficient for a practitioner ofgiven skills and experience, yet baffling to one oflesser or different skills. Similarly, a template for a“performance test plan” may be sufficient only forthose who have studied a particular approach to testplanning. Others, even if experienced in performancetest planning, may not be able to develop the desiredplan. This mismatch is addressed by requiring prac-titioners to have specific skill sets, training, or cer-tification, or by providing sufficient additional tuto-rial documentation, or by both. Conversely, IC thatmicromanages tasks may be resented or thwarted bya highly skilled practitioner.

IC is not, however, a shortcut to skill building or areplacement for skills. Within the project context,it is an enabler for practitioners possessing the ap-propriate basic skills to perform certain tasks in or-der to create work products. In the project domain,context-specific intellectual capital recognizes theavailability of individuals with specific skill levels asnecessary preconditions for accomplishing specifictasks and creating or modifying specific work prod-ucts. Multiple skill levels or skill sets may warrantdifferent, custom instances of IC. When planning andexecuting projects, different cost, completion time,and variance may be associated with these differentskill levels. Consider, for example, that both a gen-eral handyman with a pair of pliers and a masterplumber with his toolkit can each fix a leaky faucet,but the costs, completion time, and perhaps the qual-ity (and perhaps certainty) of the results may vary.Additionally, the IC necessary to provide suitableguidance to different practitioners with different skilllevels may vary in granularity, width, or depth.

Output-based approach. At the organizational level,expertise goes beyond skills (inputs) and relates togoals (outputs). Specifically, organizational exper-tise focuses on planning and executing processes toattain organizational goals. Because organizationsproduce goods and services, the associated goals are,in turn, either product- or service-related. This pa-

per focuses its attention on useful, project-relatedIC in a goal-oriented organizational context.

In the specific context of software development andmaintenance, the CSIC discussed in this paper per-tains to the work products (outputs) that contributeto the development of a new software system or themaintenance of an existing system. In information-based activities such as software development andmaintenance, the problems associated with the re-use of IC are acute. This situation contrasts to thetraditional, manufacturing realm where processes areto a great extent repetitive and skills are embeddedin the product or the production line. In the infor-mation-based realm, IC is embedded in unique orcustomized processes, augmented by the professionalknowledge worker’s skills. Try as we might, we can-not turn intellectually driven activities into repeti-tive production line functions. Nonetheless, there isan accumulated body of project-related expertise thatcan be shared and used to our advantage.

Comparing IC, CSIC, and project artifacts

IC is the overall domain; CSIC is the subset that isexplored within this paper. Just as it is vital to un-derstand the distinction between knowledge and IC,it is important to understand the distinction betweenIC and CSIC.

IC is knowledge that is of value to the organization.IC is reusable, valuable, and manageable. To be re-usable requires that the IC be in a place, form, andcontext that can be reused. Additionally, to be valu-able, IC must be subjective, filtered, locatable, assess-able, modifiable, and usable: The project plannermust be able to find the most appropriate IC amongmultiple alternatives. Additionally, the planner isable to determine how appropriate the IC is to hisor her specific efforts. The planner must also be ableto tailor or modify the IC for current and future use.For IC to be usable, the project planner must be ableto integrate and use this IC within his or her projects.Finally, IC must be manageable, including the abil-ity to control access, assess usage and usage patterns,gather feedback, measure satisfaction, and makechanges. Specialized IC-related systems are used tomanage IC and help ensure that it meets thesecriteria.

CSIC is a specialized form of IC with various spec-ified types of IC (see next section) to serve differentpurposes. CSIC is appropriately structured with well-

IBM SYSTEMS JOURNAL, VOL 42, NO 3, 2003 SINGER 447

defined interdependencies among these specializedtypes of IC. It is context-driven; that is, the IC is ap-plicable only to specific systems development proj-ect contexts. CSIC is designed and structured to serveas a set of flexible building blocks for project plans.

Project artifacts include any and all project-specificmaterials required to meet project or contract needs,or both. They include temporal documents, drafts,and other material—inputs, outputs, working doc-uments, customer deliverables, and so on, but onlysome of these artifacts will become IC. In contrastto IC (and CSIC), project artifacts are managed viaa project-specific control book tool or system.

The reason for defining project artifacts is exclusion-ary to distinguish them from IC. The transition ofsome project artifacts to IC is part of an authoringprocess discussed later. Project artifacts are managedat a project level; IC is managed at an organizationallevel.

The structure of CSIC

The CSIC approach centers on an architecture thatcaptures and communicates those constructs neces-sary to promulgate best practices for reuse and shar-ing both when building the project plan and whenexecuting this plan. This may include an optional toolsuite that helps throughout the CSIC life cycle.

The key construct is the work product, which mustbe produced in order to achieve the goals of the proj-ect. Complementing work products is the workbreakdown structure, documenting the tasks that cre-ate the work products. All these items are wrappedinto a package named an engagement model. Wenow describe operational definitions for several keyconstructs.

● The engagement model is a packaged project planmodel that includes a set of work products thathas to be produced to accomplish the project athand, synchronized with the work breakdownstructure delineating the tasks needed to build,populate, or maintain these work products, andtechnique papers and guidelines to provide spe-cific help in performing tasks and building the workproducts. An engagement model is a starting pointfrom which a project team tailors its specific proj-ect plan.

● The engagement template is the instance of an en-gagement model tailored to a specific situation. An

engagement template may also serve as a startingpoint for subsequent projects. It is a precursor ofa project plan.

● The work product represents anything producedduring the execution of the project. The sum ofthe work products is the totality of things that haveto be produced in order to achieve project success.During project execution, work products may bedependent on other work products as inputs. A keyfeature of work products is that they are designedto be shared among multiple engagement models.The following are related constructs:

— A work product description portrays in detail ev-erything that has to be produced in order tocomplete a specific type of work product.

— A work product template provides a local in-stance of the work product description tailoredfor the project at hand.

— A work product instance is the actual contentsof the work product. The work product con-tents are created and evolve during project ex-ecution, possibly with multiple successive tasks,each impacting the same work product.

— A deliverable (or deliverable package) is agrouping or packaging of work products suit-able for a customer or some other external ac-tor. A deliverable may include portions of sev-eral different work products. It is a convenientconstruct for grouping outputs and mappingthem to contract or other project requirements.

— A thread is a convenient grouping of work prod-ucts that have some commonality and often ap-pear together in a project plan. A thread is anease-of-use extension that grew from commonpractice.

● The work breakdown structure is the phase, activ-ity, task, subtask, etc. It is the decomposition ofwork to be performed in order to create, modify,or maintain a work product.

● The technique paper provides a specific instructionon how to perform a procedure that links to a spe-cific work product or a task. Technique papers arefrequently oriented to specific skill levels and skillsets. Thus they are specific, tactical documents, notgeneral instructions on how to do something.

● The guideline is a general “how to” or tutorial thatlinks to any component of an engagement model.

SINGER IBM SYSTEMS JOURNAL, VOL 42, NO 3, 2003448

Beyond the engagement model and its components,a superstructure enables the management of mod-els and their components. Method architecture is the“glue” that holds all of this superstructure together.The enhanced method architecture is work productdominant; that is, the design and subsequent selec-tion of work products dominates the approach tobuilding an engagement model. The work breakdownstructure is a secondary feature that follows the workproducts. An additional key feature of the architec-ture is heavy reuse of work products. Method is a for-mal term for the sum total of contents within thisarchitecture. For example, a role of “method author”is defined to more clearly describe the person whodelves into the contents and authors an engagementmodel. Method database is a repository for all methodcomponents.

Figure 1 depicts the engagement model consistingof two primary component types, the work productsand the work breakdown structure. Additionally,technique papers and guidelines are included withinthe scope of an engagement model. A thread is de-picted as a simple grouping of work products.

A simple example of the capturing process

To be functionally useful, IC must tend toward thespecific. Flexibility and generalization not only ex-pand the opportunity for IC reuse into other con-texts, but also challenge its applicability. In order tobetter appreciate this maxim, let us explore a simplerecipe in extreme detail. In its simplest form a rec-ipe is a single, unique process designed to producea single unique output. It is clearly a form of context-specific intellectual capital. Note that significant doc-umentation is necessary to fully describe even a sim-ple activity such as baking cookies.

The recipe in Figure 2 includes a list of ingredientsthat are the inputs, such as flour, sugar, and eggs; aseries of steps or tasks, such as combine, beat, add,and stir; and the expected outputs—Toll House**cookies. A recipe may also include an assumed ge-neric skill level or understanding of specific tasks, suchas how to crack an egg, mix ingredients or use a mixer,and turn on an oven. Additionally, there may be animplied list of required equipment, such as an oven,mixing bowls, and spoons. Lastly there is (implied)


preparation, such as gathering or purchasing the in-gredients (inputs), equipment, and other items.

Adding decisions and offering variants provides thenecessary flexibility and potential for customization;however, they may also complicate matters. Theremay be decision criteria or task completion criteria,for example, “bake until golden brown” vs “bake for9 to 11 minutes.” We see options in the recipe suchas the “Pan Cookie Variation” that provides an al-ternative based on preference or resource availabil-ity. We must also consider scalability, which encom-passes baking only a single cookie, or perhaps ahundred dozen cookies. Certain IC is readily scal-able; others have limited ranges of applicability.

Again, the focus for the cookie baker is primarily onfollowing the directions in the recipe. Little extraor-dinary skill is required; here “extraordinary” is de-fined within the context of normal cookie-baking ac-tivities. There is relatively little variation and onlylimited decision-making.

As a tutorial, let us look at this recipe expressed asa work breakdown structure:

Phase 1—Combine ingredients

● Activity 1—Measure and combine ingredients insmall bowl—Task 1—Measure 21⁄4 cups all-purpose flour—Task 2— Measure 1 teaspoon baking soda—Task 3— Measure 1 teaspoon salt—Task 4—Combine in small bowl

● Activity 2—Measure ingredients for large mixerbowl—Task 1— Soften 2 sticks (1⁄2 pound) butter—Task 2—Measure 3⁄4 cups granulated (white)

sugar—Task 3— Measure 3⁄4 cups packed brown sugar—Task 4—Measure 1 teaspoon vanilla extract

● Activity 3—Measure additional ingredients—Task 1—Measure 2 cups (12 oz. package) Nes-

tle Toll House Semi-Sweet Chocolate Morsels—Task 2—Measure 1 cup chopped nuts

● Activity 4—Beat ingredients in large mixing bowl—Task 1—Beat ingredients from Activity 2, above,

in large mixing bowl—Task 2—Add eggs one at a time into mixture,

beating well after each addition

—Task 3—Gradually beat in flour-based ingredi-ents from Activity 1

—Task 4—Stir in ingredients from Activity 3,above

Phase 2—Prepare and bake mixture

● Activity 1—Preheat oven—Task—Preheat oven to 375 degrees, Fahrenheit

● Activity 2—Drop mixture onto ungreased bakingsheet—Task—Drop by rounded tablespoon onto bak-

ing sheet (until mixture is exhausted)

● Activity 3—Bake mixture—Task 1— Bake for 9–11 minutes or until golden

brown—Task 2—Let stand for 2 minutes—Task 3—Remove to wire racks to cool com-

pletely

The in-depth description just given may not appearto be the best way to communicate how to bake tastycookies. The work breakdown structure is lengthy,a bit stilted, and lacks the communication power andstyle of the printed recipe. However, if accurate, itis a most exacting description of the necessary tasks.In a CSIC environment, tasks could link to techniquepapers, documents that would supply additional in-formation or guidance, such as how to break openan egg or grease a cookie sheet. Again, it may seemsomewhat simplistic to consider having a guidelineon “how to break open an egg” or “how to grease acookie sheet,” but how else can this be successfully ac-complished in a consistent manner and in accordancewith the recipe? The answer is three-fold—experience,skill training, and detailed intellectual capital.

In contrast, let us briefly consider a work-product-based approach. At first this may seem awkward be-cause a task-based approach is more familiar. Inlooking at the recipe, we could define each of theintermediate components as a work product and thenprovide guidance as to how each of these work prod-ucts is to be created. They are:

● Small bowl mixture● Initial large bowl mixture● Secondary large bowl mixture (with small bowl mix-

ture added in)● Final large bowl mixture (with nuts and chocolate

morsels)


● Dropped mixture on cookie sheet, ready for bak-ing

● Golden brown cookies

Details could be provided on how to prepare eachof the previous work products, including the finalwork product, a deliverable: the cookies. Addition-ally, other recipes might benefit by reusing some ofthe previous work products, perhaps changing onlythe “final large bowl mixture” to, for example, de-lete the nuts, or replace the chocolate morsels withbutterscotch morsels.

In the cookie recipe example, the focus is primarilyon process execution skills as opposed to decision-making. Baking cookies can be considered a proj-ect. Hands-on training via an apprenticeship is likelyto build the necessary skills for each task. IC in theform of a recipe serves as a vehicle for perpetuatingthis single process. Note that this example impliesan individual activity without any significant orga-nizational context or without any significant sched-ule or resource issues. Similarly, there is no formalplanning, only preparation. Finally, the IC (recipe)is fairly stable; it is unlikely to be impacted by newexperiences, changing technologies, strategic corpo-rate change, environmental changes, etc.

Consider briefly a second, similar activity: bakingbread. What do baking cookies and baking breadhave in common? What cookie-baking skills are ap-plicable to bread baking? Answers to these questionshave implications on training, staffing, career paths,etc. Can a cookie baker be used when we have abread baker shortage? Also, what IC associated withbaking cookies can be gainfully applied (reused) tobaking bread, and conversely, what IC would not ap-ply or even have negative value (be wrong)? The CSICframework addresses such issues.

Using CSIC for project planning

In relation to IC, project management has two pri-mary phases: planning, which is determining andcommunicating how to go about doing something,and execution, which is performing to plan. Projectmanagers frequently reuse contents from previousprojects as they plan new projects. This reuse maybe as simple as a fleeting thought or idea broughtto mind when a current situation recalls memoriesof a similar previous situation, or it may be concrete,such as reusing portions of a previous project planin the current planning effort. CSIC requires the gath-ering and storage of project-related IC for reuse and

the retrieval and reuse of this IC both for project plan-ning and for project execution. Characteristically, weare speaking about parts of previous experiences orplans.

What we are trying to accomplish. We are trying todevelop CSIC as a set of reusable project plans and

plan fragments that will provide a useful startingpoint for future project planning and that will thenpersist in order to support execution of the result-ant project plan. A resultant benefit may be that thesuite of project plans created within an organizationadheres to what can be called a common “shape.”The added benefits of this commonality are discussedlater.

Sample scenario. Before delving into the details, letus explore a sample scenario: Suppose that you, thereader, are the project manager chartered to do asoftware development project. This project will pro-duce an order entry and fulfillment system. The sys-tem will have a Web-based “front-end” (i.e., the cus-tomer will access the system via the Web), but youknow that the new, integrated system will need tointerface with several existing (legacy) systems, suchas the corporate inventory management system.

Your first challenge is to develop a flexible, achiev-able project plan that will accomplish your goals.Without an IC system for reuse and sharing, youmight begin from one of two extremes: a clean sheetof paper or a project plan that you encountered ona previous, similar project. You would then modifythis plan and proceed.

A “best case” situation might be one where you havesuccessfully planned and executed this type of proj-ect before—you can dust off your old plans and ideas,make a few experience-based adjustments, and thenproceed. But what you may be doing is perpetuatingan outdated or mismatched solution or, to be harsh,mediocrity. Note that a comfortable, tried-and-truesolution may not be the current corporate best prac-tice. There is the danger that this less-than-best prac-

Project managers frequentlyreuse contents from

previous projects as they plannew projects.


tice will supplant the needed best practice. This sit-uation can occur at the project or part level.

Given access to a library of reusable project plans,you need to intelligently search for an appropriate,best-fit project plan as a starting point. An appro-priate project plan is one where assumptions and con-straints are compatible with your project. A best fitplan is not only compatible with constraints and op-portunities but also minimizes the amount of cus-tomization or tailoring that you will need to do.

Failing to find a suitable project plan for your“Web � legacy” project, you might seek to combinetwo plans: a Web-based development project planand a second project plan for building systems thatinterface with legacy systems. But there is no assur-ance ahead of time that these two plans will be com-patible or that you can successfully blend them to-gether. The IC may not be of a form that can besubdivided into reusable components and thus“mixed and matched.” Furthermore, the plans mayincorporate different, incompatible development ap-proaches, reflect different standards, use differentterminology, and so on. By setting standards andkeeping a constant eye toward future reuse and pos-sible blending of IC from multiple project domains,the CSIC helps enable this blending of plans.

Ideally, a framework would be in place to ensure thatall IC forms a compatible, interoperable set (that is,all IC would share compatible approaches, standards,terminology, and so on). Additionally, there wouldbe a system in place to help locate and use this IC.The IC must be provided in a form that can be sub-divided into reusable components. In this sample sce-nario, if there is no direct “Web � legacy” IC avail-able, two separate sets of IC, one “Web” and one“legacy,” might be located, and elements of eachcould then be blended together as a starting pointfor project planning.

This is our enhanced CSIC approach—building ICcomponents within a framework that enhances theability to later form a comprehensive whole frommany parts. Common approaches are encouraged,thus increasing the opportunity to successfully blendmultiple components.

Knowledge management life cycle

Before developing a detailed view of the Engage-ment Model Lifecycle, let us look at the general

knowledge management life cycle. Mach and Owoc1

cite a cycle (adapted from Mercier-Laurent, Jakub-czyc, and Owoc) with four components: knowledge-accumulating, knowledge-creating, knowledge-shar-ing, and knowledge application. Lindvall, Rus, andSinha2 cite the fundamental Nonaka and Takenu-chi model (circa 1995) with four types of knowledgeconversion: socialization, externalization, combina-tion, and internalization. They go on to cite “TheKnowledge Lifecycle” from Wiig. This life cycle isdepicted as: knowledge creation/acquisition,organization/storage, distribution, application/reuse,and (again) knowledge creation/acquisition. TheKnowledge Management Forum3 also cites Wiig ina position statement “On the Management of Knowl-edge” which identifies the following knowledge-re-lated processes: create, build, compile, organize,transform, transfer, pool, apply, and safeguardknowledge. Similarly, S. Schoenert4 designates thefollowing life-cycle functions: (establishing) goals ofknowledge, identification, generation, storage, dis-tribution, usage, and evaluation. Gongla and Riz-zuto5 detail how communities of practice and accom-panying knowledge networks have evolved within theIBM Global Services organization. Although a strongbusiness context is embedded within this approach,knowledge use still is somewhat generalized.

Although there are multiple, different activities de-scribing various elements of “authoring” (knowledgecreation, compilation, storage, etc.) in each of theabove cases, there is only a single category for knowl-edge use (application, usage, reuse, etc.). This re-flects a context-free approach to knowledge manage-ment, where using the knowledge is likewise context-free, simply a single, broad, “umbrella” category.

It is not until we look at Basili and Seaman6 and theSoftware Engineering Experience Factory that wesee knowledge management applied to the specificendeavor of software development projects. We seea project organization with the traditional “plan” and“do” linked by the project plan and nourished by anexperience base. This is closer to the CSIC approachdescribed in the following section: Built on the foun-dation of the detailed structure provided by CSIC, theEngagement Model Lifecycle heavily emphasizes theuse of IC in project planning and project execution.Thus the Engagement Model Lifecycle enables thelevel of IC reuse that is vital to successful project plan-ning and project execution.


How to make the Engagement ModelLifecycle happen

The Engagement Model Lifecycle discussed hereinis a specialized instantiation of the general knowl-edge management life cycles. The authoring activityis to a great extent analogous to knowledge gather-ing and filtering, classification, and storage. Projectpreparation and project execution each involve thereuse of IC, requiring location, selection, and retrievalof appropriate IC. Experience harvesting might beconsidered the maintenance phase of the life cycle.

In the previous example, valuable new CSIC, relatedto the specific scenario, may have been created dur-ing the planning process. Additionally, lessonslearned during project execution may also contrib-ute to the CSIC, either subtly as reflected in modi-fications to work products, or explicitly as additionalwork products, technique papers, or guidelines. TheEngagement Model Lifecycle extends beyond proj-ect planning and project execution to this creationand modification of IC.

There are four major activities in the EngagementModel Lifecycle, shown in Figure 3. They reflect anidealized life cycle as follows:

1. Authoring—based upon or updated by experi-ence

2. Project preparation (planning)—based on the au-thored engagement models

3. Project execution—based on the project plan4. Experience harvesting—gathering experience as

gained during project planning and project exe-cution

All fit within an organizational/project context. Thisbroader context better reflects the reality that onedoes not directly deliver process; one delivers projectsbased on process fundamentals, principles, and les-sons learned. Similarly, one does not directly deliversystems engineering or quality initiatives such as theCapability Maturity Model (CMM) or ISO-9000; onedelivers projects based on processes from thesedomains.

Authoring. Before exploring several cases of author-ing uses, let us examine the roles employed in es-tablishing best practices and their reuse as CSIC.These roles have evolved through experience. Be-cause these are roles, not individuals, it is certainlypossible for a single individual to fulfill multiple roles,or (more likely) for a team to share a single role.

Nonetheless, we use the term “person” in describ-ing each role. The organizational SME (subject mat-ter expert) is the person who knows the business, theproject, the program, and the account, and is a per-son who can also provide context. The process SMEis the person who focuses on the work from the view-point of project management, project process, soft-ware engineering process, and quality. The methodauthor is the person who translates or “ports” ex-isting processes into a common, reusable central con-tents repository or database. The contents facilita-tors make up the central team that helps and enablesthe authoring process. These facilitators also enforcestandards and encourage reuse. They have the broad-est view of all available IC and look toward common-ality and how the many may benefit from the workof the few. Conflict resolution is also part of this role.The contents owner is the person who owns and main-tains the central contents repository. The tool ownerand developer is responsible for the enabling IC toolplatform, and so on.

Note that a detailed discussion of tools for manag-ing CSIC is outside the scope of this paper, but seethe following for an overview of the enabling IC toolplatform.

Again, this roster is based on the author’s experi-ence and reflects the organization design developedby the sponsoring organizations. One should not con-fuse the number of roles with staffing requirements.The preceding roles reflect unique skills and respon-sibilities dictated by the structure of the CSIC and itssupporting environment as well as the organizationaldictates of those field organizations that perform

Figure 3 Engagement Model Lifecycle

AUTHORING• DEVELOPING• PUBLISHING

EXPERIENCE HARVESTING• INTELLECTUAL CAPITAL MANAGEMENT

PROJECT PREPARATION• DEFINING• PLANNING

PROJECT EXECUTION• PROJECT CONTROL• PROJECT TRACKING• ASSIGNMENTS

ORGANIZATIONAL/PROJECT CONTEXT• DIRECTING PROJECT PROCESSES

• SUPPORTING PROJECT PROCESSES

From an internal presentation by Paul Gignesi of IBM.


software development and maintenance projects.Some project participants may fill multiple roles, and,conversely, some roles require several workers.Clearly “one size does not fit all” because roles andorganizational structure must be appropriate for theorganizational context in which the CSIC is imple-mented. Further discussion of the CSIC-related or-ganizational structure appears later.

The authoring process. The authoring process istreated like any formal project, with a project plan,a schedule, cost estimates, documents of understand-ing among organizations detailing responsibilities,and so on. This discussion, however, focuses moreon the technical aspects of the authoring process,not the organizational or project aspects.

Simply put, either best practices or fragments of bestpractices are gathered for reuse. This gathering canbe done proactively or passively. In the proactivemode, when management somehow senses a needfor an answer (an itch), a project team is assembledto provide the answer (to scratch that itch). In thepassive mode, best practices are sought, with thehope of finding that the answer already exists, suchas, another team has been quite successful at deal-ing with a relevant opportunity, and therefore, thereis an opportunity to use their expertise.

Evaluating (measuring) project success, evaluatingproject artifacts and IC, and gathering additional ICare important post-project execution steps. Unfor-tunately, many circumstances make it difficult to ac-commodate these vital project steps.

The proactive approach is essentially analogous toa design effort. A project is formed employing a teamof experts to “design” an archetypical project planand the components that support it. This approachmay be followed when a series of similar projects areon the planning horizon. In contrast, the passive ap-proach finds an existing best practice and somehowcaptures its essential pieces in a manner that is con-ducive to future reuse.

The authoring process—Use Case 1, freeze drying.The primary authoring paradigm is what we callfreeze-drying. Analogous to the process that removesthe water from coffee, leaving behind the essentialgood taste, this freeze-drying process takes the proj-ect practices of existing systems and extracts theirsubstance and essence to make them available toother teams, consistent with the method architec-ture. Again, a key factor here is reuse. Authoring is

not simply a translation of existing practices into workproducts, technique papers, and such, but an activ-ity that involves analyzing the current IC and themethod database contents and reusing or blendingas much existing content as practical.

The method author, supported by the organizationalSME and the process SME, reviews the (source) bestpractice, as is, and translates it into components, suchas work product descriptions, technique papers, anda work breakdown structure. This first review doesnot consider blending with the current method con-tents database. Afterward the SMEs conduct a for-mal review for contents, redundancy, and complete-ness.

Many additional aspects of proposed IC need to beexamined. These include: (1) decomposition—Is theIC at its most granular, decomposable level that en-ables reuse, or is it still a composition of severallinked parts? Note that when decomposing IC, link-ages should be maintained. (2) perishability—Doesthe IC have a reasonable period of freshness, or willit become stale with foreseen changes in technologyor the business environment? (Consider, for exam-ple, the constructs developed for the anticipatedproblems deriving from the change in specifyingdates as the twentieth century became the twenty-first century [the Y2K problem].) (3) applicability—How useful will the IC be in other contexts? Bound-ary conditions may be set, as, for example: “This workproduct is not to be used with real-time systems.”(4) adaptability—Can this IC be transformed for usein other contexts and still be useful?

After the method author has isolated and docu-mented this best practice, the contents facilitationteam then works with the author to evaluate workproducts. An in-depth review of all proposed newwork products is conducted, and reuse of existingwork products from the method database is explored.Proposed new work products introduced by the newengagement model template can result in severaloutcomes: (1) A new, unique work product is addedto the method database. It will be available to oth-ers in the future. Supporting material such as tech-nique papers and selection criteria (when to use thiswork product vs a similar work product) are created.(2) An existing work product is determined to be asuitable replacement for the proposed work prod-uct, and the engagement model is modified accord-ingly. (3) The proposed work product is determinedto be superior to a similar work product in the ex-isting method database and is earmarked to replace


the existing work product. (4) A hybrid work prod-uct is developed, based on the proposed work prod-uct and similar, existing work products.

Work products, like all content within the methoddatabase, are under configuration control. Anychanges undergo impact analysis (via an incidencematrix) involving all engagement models that cur-rently reference the specified work product and are

subject to a release process that includes changes todocumentation, training materials, and so on. Thevarious subject matter experts are part of the aboveprocess and also perform a formal review and ap-proval. The contents facilitation team provides sev-eral additional quality checks ranging from techni-cal writing issues (grammar, spelling, format, style)to overall technical reviews. This team also includesa publishing role for physically adding the engage-ment model and its components to the method da-tabase.

The authoring process—Use Case 2, building new pro-cesses from existing components. This use case is aunique opportunity to build new processes, but notfrom scratch. As the process is detailed, existingmodel components, work products, and techniquepapers, for example, can be reused (best case) orserve as the basis for additional new components(next best case).

This use case is technically similar to Use Case 1;however, it frequently has several organizational orproject differences, mostly focused around require-ments. Among the requirements are determiningwhat challenges the new process should be meeting,as well as review and approval processes.

The authoring process—Use Case 3, building new pro-cesses from scratch. For completeness, a tabula rasaapproach should be considered, but in reality thissolution is a worst-case example of Use Case 2—onewhere no existing model components can be reused.

In most cases, this solution amounts to “reinventingthe wheel.”

The authoring process—Use Case 4, hybridizing mul-tiple approaches. What should be done when thereare multiple similar approaches within an organiza-tion to perform the same type of project? One an-swer is to select one by having a run-off. A secondis to consider a hybrid, taking advantage of thestrengths of each approach. This second methodlends itself well to the analysis afforded by our work-product-dominant architecture. By extracting andthen comparing the work products incident to eachapproach, a consistent basis for comparison can bedeveloped. As appropriate, new engagement mod-els can be built.

The authoring process—Additional use cases. Addi-tional authoring processes, such as maintenance ofexisting IC, including both adaptive and correctivemaintenance, need to be considered. However, theyare outside the scope of this discussion.

The authoring process—The imperative of sharing andnormalization. The ability to share (reuse) existingwork products when building an engagement modelis perhaps the greatest advantage provided by thisenhanced approach. Various types of system projectsencounter similar situations and can reuse workproducts to great advantage. For example, the teamthat the author led used the freeze-drying techniqueto capture four “best in class” maintenance-relatedengagement models. Then, given a method databasewith existing work products from “normal” custom-ized application development engagement models,we needed to create only four new work productsduring our authoring process. In conjunction withthe contents facilitators, we determined that one ofour newly captured work products was superior toa similar work product already in the method da-tabase. After appropriate impact analysis was con-ducted, the switch from the inferior work productto the superior one was made in conjunction witha major new release of the method database.

Sharing may extend further via a concept calledthreads; for example, a natural clustering of workproducts related to testing may be defined as a “test-ing thread.” In building a new engagement model,this testing thread may provide a convenient start-ing place for authoring that part of the engagementmodel.

As the method database grows,it is necessary to

provide better selection criteriaand selection support to

aid project planning.


Project preparation (planning). As was discussed,CSIC is the foundation for creating a project plan.During the project preparation and planning pro-cess, the CSIC is used to create a customized instan-tiation of an engagement template. This engagementtemplate in turn serves as the basis for building adetailed project plan.

In practice, a method adoption workshop (MAW) isconducted to expedite the project-planning process.The MAW is a group meeting that requires partic-ipation by all project stakeholders both for their ex-pertise and to assure buy-in. The central activity ofthe MAW is the creation of an engagement template.The starting point is the selection of engagementmodels or engagement templates as the basis for tai-loring. Selection involves browsing through existingengagement models and engagement templates andtheir components, carefully examining constraints,strengths, and applicability, then determining whichamong several similar engagement models and en-gagement templates is a best starting point. The se-lection is followed by tailoring an instance that is thebest fit for this particular effort. Tailoring includesidentifying and selecting required work products,customizing work product instances as necessary, andthen generating a work breakdown structure basedon the (input/output) dependencies of these workproducts.

The work-product-dominant approach excels here.Experience shows that focusing on the work prod-ucts that need to be produced in order to achieveproject goals is most helpful in identifying and se-lecting an engagement model or engagement tem-plate as a starting point. Rather than concentratingon “what do we need to do,” the focus on “what dowe need to produce” is sharper. The details of a givenwork product can be explored to further determinesuitability. Furthermore, tailoring work products isa straightforward means of customizing project plansto meet unique requirements.

Again, the CSIC is especially adept at supporting thisrigorous planning process. The CSIC provides the ap-propriate IC alternatives when and where they areneeded. In contrast, generic (unstructured) intellec-tual capital is unable to deliver this promise beyondthe provision of search engines.

Although we do not discuss the intellectual barriersto the selection and adoption of other people’s ICin this paper, it is worthwhile to highlight a generalchallenge. This challenge occurs when the project

planner’s mental model of how the project shouldbe accomplished takes precedence over and is in-compatible with those models in the IC. This is es-sentially a conflict of perception vs reality.

As the method database grows, it is necessary to pro-vide better selection criteria and selection supportto aid project planning. This is especially importantwhen there are several similar pieces of content; forexample, test plan for Web-enabled systems, test planfor enhancements, and test plan for corrective main-tenance. Additionally, a library and retrieval systemis needed to facilitate the reuse of engagement tem-plates and other contents.

Project planning, an organizational context. Tailoringcontents on an organizational or multiproject basismay be useful. For example, contents may be tailoredto meet organization standards. Similarly, when a se-ries of similar projects is on the planning horizon,tailoring may be done for this class of projects.

A MAW may take place at an organizational level asan engagement template is tailored to meet customeror contract needs. Work products may be added tomeet unique requirements. Other work products maybe deleted or modified. Still other work productsmight be designated as “mandatory” (not to be re-moved in subsequent MAWs) to satisfy managementor contract requirements. The resultant engagementtemplates again provide a “closer” starting point forplanning subsequent individual projects.

Method authoring may also take place for a similargroup of projects; for example, a maintenance shopthat is expecting several similar projects in the nextsix months might conduct a MAW for what it expectsto be a typical project. The result of this class MAWis a tailored class engagement template. As each in-dividual project begins, the project manager verifiesthat the class engagement template is suitable forthat specific project and then continues.

A variant of this approach is to go beyond tailoringto produce a single class project schedule (using com-mercial project-scheduling software) for this class ofprojects. Each subsequent project then begins at thescheduling level: verifying plan appropriateness, es-timating, adjusting roles and resources, resetting theproject start date, and so on.

Project execution. Project execution is the logical“work the plan” phase within most project ap-proaches. The normal project execution steps (as


specified by the project plan) take place here, as theywould with any project, only they are supported muchmore effectively by the CSIC. The CSIC provides ad-ditional resources for project execution but does notfundamentally change the way in which project ex-ecution is performed or managed.

During project execution, work products are pop-ulated when and as appropriate. It is here that a sup-port tool provides quick links to relevant supportingmaterial such as technique papers, guidelines, orwork product templates. This support is a key leverthat the CSIC environment provides during projectexecution.

Tools that provide scaffolding for project execution,such as configuration management and issue man-agement, are beyond the scope of this paper, as aretools that support the selection of, navigationthrough, and use of the engagement models.

Experience harvesting. Experience harvesting, al-though a vital component of knowledge manage-ment, is often neglected because it is seen as a helpto other (future) projects but not as a direct benefitto the current project. In a worst-case scenario thereis neither funding for this activity, nor managementguidance to encourage it, and thus nothing is in theproject plan for experience harvesting. The projectteam disbands and goes off to other projects with-out having done the appropriate post-project anal-ysis and experience harvesting.

Because our approach makes good use of existingassets, it must have experience harvesting to honeand expand method contents. The impetus for in-clusion of these activities into project plans and, es-pecially, funding for these activities may need tocome from organizational rather than project-specific resources.

The experience harvesting process then blends backinto authoring. Feedback from projects helps to eval-uate the utility and appropriateness of existing IC.This may result in proposed changes to existing ICor modifications to guidance, such as usage or ap-plicability. Additionally, new IC, such as a new workproduct template instance, may be harvested froma current project. This new IC is then evaluated forinclusion in the method database.

The CSIC enabling tool platform

Just as the CSIC is a detailed instantiation of moregeneralized IC, so too, the CSIC enabling tool plat-

form is a detailed instantiation of more generalizedIC management systems. It manages the IC through-out its life cycle from authoring through analysis. Thisis not unique.

What sets the CSIC enabling tool platform apart isthat it accommodates the various engagement modelcomponents described earlier. It deals specificallywith both work products and a work breakdownstructure, and is capable of linking the two. The gen-eration of an appropriate work breakdown structurefrom a selected set of work products is key here. Ad-ditionally, the tool platform serves, both during proj-ect planning and during project execution, as an in-telligent assistant providing direct linkage tosupporting information as and where needed. Thusa work product template is only a “click” away whenexamining a work product. Similarly, technique pa-pers and guidelines are appropriately linked andavailable.

Another outstanding feature of the CSIC enablingtool platform is the ability to provide secure accessto (and downloads of) specific extracts of the engage-ment model database. The project planner can scopeout the areas of potential interest and receive (only)the appropriate IC. In response to the planner se-lecting engagement models of potential interest, thetool examines the incidence among components inorder to generate the linked advance (like a “bowwake”) and then extracts an appropriate, nonredun-dant subset of the engagement model components.

Organizing for CSIC

The CSIC superstructure is the organizational frame-work for using CSIC in project management. In thissection, we consider how to best set it up.

Organizational imperatives for successful imple-mentation. There are four primary imperatives forsuccessful implementation: (1) The approach re-quires a significant level of commitment at both themanagement and practitioner level. Long-term man-agement commitment is mandatory. (2) A separate,dedicated organization for maintaining the methoddatabase must be established. This organizationshould also maintain the tool suite, also discussedin this section. (3) CSIC-oriented skills managementmust be integrated into the organizational profes-sional development management approach. (4) Allparticipants must receive appropriate orientationand training.


Experience has taught us that there must be a sep-arate, adequately funded organization whose solecharter is to manage the CSIC. By overseeing eachof the four phases of the CSIC engagement life cycle,this central organization can ensure the utility andthe quality of the method database. This organiza-tion maintains the method database, helps blend con-tent, and resolves conflicts among engagement mod-els. Additionally, this organization maintains the toolsuite that enables the CSIC. This organization alsomaintains standards and trains and certifies practi-tioners.

It should be cautioned that this organizational de-sign will not be appropriate for everyone. Factorsthat led to this organizational design include: a greatquantity of high-quality IC to be “mined” and shared;a large, geographically dispersed organization; manydifferent participating groups, each with unique chal-lenges; a requirement for specific, in-depth exper-tise; limited cross-organizational socialization ortechnical contact; a wide variety of different projectswith differing project environments and contexts(outsourcing, in-house development, consulting,etc.). This design is a complex, expensive, large-scalesolution that may not necessarily scale down to beeconomically viable for smaller organizations.

Although project managers (as project planners) aremost intimately involved with the CSIC, there is a needto train all project participants, even those only in-volved with project execution. At a minimum, ev-eryone needs to know how to access and understandthe IC necessary to perform their tasks. Conceptu-ally, it is important that everyone be aware of the“sharing” environment.

Does the IC “own” project management best prac-tices? Ownership of project management best prac-tices is a key organizational issue. The two extremesfor establishing, sharing, and disseminating best prac-tices have centered on the “ivory tower” (remote,centralized) approach and “the field” (hands-on,practical) approach. This dichotomy is especially rel-evant if there are several organizations or teams do-ing similar work in the field.

The ivory tower approach traditionally is having acentral organization charged with the responsibilityfor all process-related functions. Staffed by a cen-tral team of experts and typically augmented by in-dividuals brought in on temporary assignment fromthe field, this group establishes standard practicesand processes and selects or builds tools and arti-

facts to help this standardization along. Years ago,they would have provided a large, three-ring binderfilled to the brim with goodness. Today, that three-ring binder is likely electronic.

In contrast, the field approach recognizes that thereis much goodness learned from practitioners doingactual work and that a small central activity works

in conjunction with practitioners in the field to find,hone, and then disseminate goodness. Frequentlythere is an informal liaison between this central ac-tivity and the field. The results are often providedto other field activities as optional with minimal sup-port, typically in “as is–where is” fashion.

The field approach was established in part becauseof shortcomings in the ivory tower approach. Al-though tools and architecture were centralized, it dif-fered by having process expertise distributed in thefield; that is, the project and process SMEs in the fieldwere responsible for virtually all (technical) content.Corporate centers of excellence such as those deal-ing with project management provided additional re-sources in support of this effort. Content (method)authoring was also “in the field” with formal doc-uments of understanding establishing and regulat-ing authoring efforts.

Again, the enhanced approach as implemented inthe author’s organization is a hybrid with a small coregroup that manages the central repository of con-tents, the method database. The group providesmethod architects and authoring support. Addition-ally, this group manages the supporting tool suite.There is limited conflict between the need of the fieldfor control of content and the desire of the coregroup for organization-wide content uniformity.

This asset-based CSIC framework can be a most use-ful aid in institutionalizing best project planning andexecution practices. The work-product-dominant ap-proach strongly supports the definition of processes

The CSIC superstructureis the organizational

framework for usingCSIC in project

management.


and reuse. A robust authoring environment is neededto hold all of the pieces together.

Supporting tool suite. Here we briefly discuss thesupporting tool suite. The tool suite stores a linkeddatabase of architectural components, in this in-stance the method database. It assists in the author-ing process that in essence populates the method da-tabase. During project planning, the tool suiteprovides access to the method database and the ca-pability to tailor an engagement model into an en-gagement template. During project execution, thetool provides active links to technique papers andto guidelines. Finally, the tool supports metrics andother experience harvesting.

Maintaining IC context is a key characteristic of thetool suite; that is, the various components are treatedinterdependently, and links among content are al-ways maintained.

The benefits in how CSIC addresses keyproject issues

We might ask why is it that some projects still fail;moreover, we might ask how CSIC addresses the fol-lowing issues:

1. Poor plans—The culprits here are often incom-plete project plans or ill-fitting project plans. Theroot cause is frequently lack of suitable plans (IC)as a starting point for the planning process. Build-ing a plan instance from IC that is not fully suit-able may result in extraneous steps as well as omis-sions, such as failing to perform a certain testingactivity. A second contributing factor is lack of aformal planning process by which plans are cus-tomized to the situation at hand.

CSIC addresses this head on. It provides the IC,the tools for accessing the appropriate IC, and aformal process for building project plans. Theplanning process also involves all of the variousroles (and constituencies) required to build a suc-cessful project team. This process not only devel-ops the project plan but also provides a criticalreview of the plan and buy-in by project stake-holders.

2. Skill and execution issues—Project plans assumespecific execution capabilities and skill levels. Spe-cific issues include inability to perform tasks, re-source estimation, and deviation from plan or un-

expected outcomes. Even simple tasks can causeproblems. With reference to the cookie recipe ex-ample, we might ask: How does one soften but-ter (Phase 1, Activity 2, Task 1)? Will the tech-nique used impact the quality of the cookies? Howmuch time should we allocate for this activity?

CSIC addresses these issues by integrating skillsand skill management into the overall organiza-tional approach to project management. Addi-tionally, it formally matches skill requirementswith project roles.

3. Ambiguities and process errors—Looking againat the cookie recipe example, we see an artificiallyimposed sequence in Phase 1, Activity 1 of thework breakdown structure. There is no requiredsequence for the first three tasks (measuring var-ious ingredients). Because there is no statementto the contrary, we may presume that the ingre-dients can be added to the small bowl in any se-quence. In contrast, the tasks in Phase 1, Activity4, are sequence-dependent. Performing them outof sequence may cause problems. This type of er-ror may occur in project planning or in projectexecution.

CSIC addresses these errors very well via detailedplanning and supporting IC such as work producttemplates and technique papers. Skills trainingis an additional requisite component to address-ing process errors.

4. Resource issues—Poor estimates and the inabil-ity to track resources against project progresscomprise these issues.

In addition to enabling detailed plans, CSIC ad-dresses these issues through IC that is orientedtoward project estimation and resource manage-ment that takes into account various skill levels.

5. Scalability and applicability—Failure of planningto accommodate significant variations in scale re-sults in ill-suited plans that can lead to failure.Similarly, lack of applicability (or inappropriate-ness) of IC also contributes to project failure.

CSIC addresses this issue to the extent that the ICproperly reveals scalability and applicability issuesand constraints. Additionally, the MAW processfor building project plans focuses on this prob-lem.


6. Leadership and communications—This issue isa catchall for many project issues.

CSIC addresses this issue to the extent that clearproject plans are easier to articulate. Addition-ally, the in-gathering of stakeholders as part ofthe MAW can be a useful precursor to team build-ing and to establishing project leadership. Also,the CSIC clarity of roles enhances communicationsduring project execution.

7. Unclear or changing requirements—If a customerwants walnuts in the chocolate chip cookies andthe recipe is read as implying pecans, the projectmay fail. Clarity requires that all ambiguities beresolved in a timely fashion. In this case it wouldbe most preferable to determine the type of nutsdesired before purchasing (or costing) takes place.If this discrepancy is not noticed before Phase 1,Activity 4, Task 3 (stir in ingredients), the mix-ture may have to be scrapped and the processstarted again. Similarly, if the customer at thispoint asks for pecans instead of walnuts, it is nec-essary to have a change management process inplace to evaluate this request.

CSIC addresses requirements management issues byestablishing work products and processes that arespecifically oriented toward requirements manage-ment and change management. This action helps re-duce but not eliminate problems related to require-ments and change.

In summary, CSIC can address many key project man-agement issues. However, CSIC, even when properlyimplemented and appropriately managed, is not apanacea.

Additional observations

In this section, we discuss some additional observa-tions about this approach.

Benefits of commonality. As noted above, whenproperly implemented, CSIC addresses many symp-toms of project failure. A key additional benefit ofthis more consistent approach to project manage-ment comes into play at the program (multiproject)management level. A portfolio of projects based onthis set of more consistent project plans and plancomponents is easier to manage. Project plans sharea more consistent “shape,” common work products,and a standardized approach (as driven by technique

papers and guidelines). This commonality enablesprogram managers to regain control of the projectportfolio. Often it is an unmeasured bonus. Addi-tionally, practitioners moving among projects haveless relearning and transition issues—everyone usesthe same terminology. As a result, the movement ofpersonnel (such as specialists) among multipleprojects is more efficient. There are related positiveimplications for training, testing, documentation, andother activities.

A discussion about managing in the multiproject(program) environment would entail more than isintended for the scope of this paper.

Usability of the approach. The approach is intuitiveand works well. However, planners who are accus-tomed to a task-oriented (work breakdown structure)approach to project planning will need to reorienttheir thinking toward output (work product) dom-inance (similar to the issues that were encounteredmany years ago in moving to “object-oriented” ap-proaches to systems development). As with any newapproach with its own nomenclature and structures,there are transition issues.

The key to usability is the uniform quality of the var-ious parts of the method database. This maxim ap-plies especially to work products.

Conclusions

Context–specific intellectual capital provides signif-icant benefits to those organizations that invest inbuilding and maintaining the appropriate CSIC in-frastructure and contents. The focus on work prod-ucts and building a robust collection of work prod-ucts that are useful for multiple, different projectsis especially worthwhile. CSIC is clearly of value inthe domain of software development and mainte-nance project planning and management, and likelyhas applicability to other process-oriented domains.

The establishment of an appropriate level of sup-port and infrastructure (as well as tools) for CSIC isa significant organizational undertaking. Althoughthere are no hard and fast guidelines, this approachis most likely cost effective for larger organizationsthat have a significant portfolio of systems develop-ment and maintenance projects.

Acknowledgments

This paper is based on the creativity and hard workof several IBM teams both past and present. It has


been fun working with them, and the author thanksthem for their contributions to his understanding andappreciation of context-specific intellectual capital.

**Trademark or registered trademark of Societe des Produits Nes-tle S. A. Corporation, Switzerland.

Cited references

1. M. A. Mach and M. L. Owoc, “Validation as the Integral Partof a Knowledge Management Process,” 2001 Informing Sci-ence Conference, Krakow, Poland (June 19–22, 2001).

2. M. Lindvall, I. Rus, and S. S. Sinha, “Technology Support forKnowledge Management,” Proceedings of the 4th InternationalWorkshop on Learning Software Organizations (August 6, 2002).

3. What Is Knowledge Management, from B. D. Newman, “AnOpen Discussion of Knowledge Management,” the KnowledgeManagement Forum, at http://www.km-forum.org/what_is.htm(August 2002).

4. S. Schoenert, Powerpoint Presentation, University of Koblenz-Landau, German, available at fac.cgu.edu/�chatters/mgt516/slides/KM3.PPT.

5. P. Gongla and C. R. Rizzuto, “Evolving Communities of Prac-tice: IBM Global Services Experience,” IBM Systems Journal40, No. 4, 842–862 (2001).

6. V. R. Basilli and C. Seaman, “The Experience Factory Or-ganization,” IEEE Software, 30–31 (May/June 2002).

Accepted for publication April 18, 2003.

Carl A. Singer IBM Advanced Business Institute, Route 9W, Pal-isades, New York 10964 ([email protected]). Dr. Singer is cur-rently a senior consulting faculty member developing and manag-ing several executive-level courses. He has a B.S. in organizationalscience from Case Institute of Technology and did graduate workthere in operations research. He has an M.S. in industrial andoperations engineering from the University of Michigan and aPh.D. in industrial administration from the Krannert School ofBusiness at Purdue University. He is also a graduate of the U.S.Army Command and General Staff College and the U.S. ArmyWar College. Dr. Singer joined IBM in 1995 to develop tools forformally leveraging project expertise as intellectual capital. Histeams have developed several engagement models for softwaremaintenance and for Rapid Custom Development, a software de-velopment methodology that can be used when time to marketis critical. He serves as a member of the executive committee ofthe IEEE Software Engineering Standards Committee (SESC).


Documents

Context-speciﬁc intellectual capital— The next link in ...€¦ · links to matching work breakdown structures. This primacy of outputs rather than tasks is orthogonal to many