eﬀectively utilizing project, product and process knowledge · utilizing project, product and...

Effectively utilizing project, product and process knowledge

Christof Ebert a,*, Jozef De Man b

a Vector Consulting Services, Stuttgart, Germanyb Alcatel-Lucent and Ghent University, Antwerp, Belgium

Received 26 July 2006; received in revised form 16 June 2007; accepted 17 June 2007Available online 4 September 2007

Abstract

Improving project management, product development and engineering processes is for many companies crucial to survive in a fastchanging environment. However, these activities are rarely integrated well due to the diversity of stakeholders with individual knowledgeabout projects, products and processes. This case study shows how Alcatel-Lucent over time achieved effective interaction of engineeringprocesses, tools and people on the basis of a knowledge-centric product life-cycle management (PLM). Starting from identifying project,product and process knowledge, we show how they can be effectively integrated for best possible usage across the enterprise. The casestudy provides insight into how to best embark on PLM and how to effectively integrate product development with supportive tools. Itdescribes how the concepts can be transferred to software engineering teams and IT departments in other companies. Concrete resultsfrom several product lines, such as efficiency improvement and better global development underline the business value.� 2008 Elsevier B.V. All rights reserved.

Keywords: CMMI; KM, knowledge management; PLM, product life-cycle management; Process improvement; Project management

1. Introduction

Systems and software development requires profoundtechnology and product knowledge combined with effectiveusage of teamwork, processes, methods and tools. Toreduce complexity and boost performance, it looks justrational to put a small group of software engineers atone place, share the project objectives, agree processesand technologies to apply and let the project run. Unfortu-nately, reality is different, especially in times of globaldevelopment of solutions involving many different compe-tences, components, interfaces, processes and tools, all con-tributing to increased complexity.

Today’s global software engineering with short releasecycles, interacting product lines and product and solutiondevelopment from many sources has advantages but alsodrawbacks. While the positive side accounts for faster cycletime, time-zone effectiveness and reduced cost, we should

not close our eyes for severe disadvantages. Working in aglobally distributed project for instance involves overheadfor planning and managing people and suffers from lan-guage, psychological and cultural barriers. It often trans-lates into knowledge needs which are not satisfied in duetime due to these obstacles.

Of growing importance in such ever-changing environ-ments is effective management of software engineeringknowledge. We will talk here less about specific technicalknowledge on a dedicated software technology, which istypically provided from various sourcing channels. Welook rather into the knowledge linked to the key assets ofa company, namely project, product and processknowledge.

This article describes how Alcatel-Lucent over the pastyears has mastered challenges in product development bya clear focus on product life-cycle management (PLM)and engineering knowledge management. Specifically wewill address what we did to integrate these two aspects,how our results can be transferred to other settings andwhat the benefits are. We will share results from severalyears of gradually building environments and a culture of

0950-5849/$ - see front matter � 2008 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.06.007

* Corresponding author.E-mail addresses: [email protected] (C. Ebert),

[email protected] (J.D. Man).

www.elsevier.com/locate/infsof

Available online at www.sciencedirect.com

Information and Software Technology 50 (2008) 579–594

sharing software engineering knowledge. Integrating andutilizing project, product and process knowledge is anongoing journey, involving continuous process improve-ment, on which it builds. Specifically we were interestedin supporting product development and project manage-ment with efficient processes in order to substantiallyimprove performance along the product life-cycle. Thechallenge we faced was centered on more effectively utiliz-ing software engineering knowledge as a mandatory driverfor business success in software-intensive productdevelopment.

The article is organized as follows. The next section pro-vides a brief introduction to PLM and KM. Section 3 sum-marizes related work. Section 4 describes the environmentof the case study. Section 5 briefly introduces the differentelements of software engineering knowledge. Section 6summarizes lessons learned from integrating project, prod-uct and process knowledge to a useful and used environ-ment. Section 7 provides concrete results and the value tothe enterprise, which we achieved over the past years.Finally, Section 8 concludes this industrial case study andsuggests future work in knowledge management and PLM.

2. Product life-cycle management and knowledge

management

IT and software companies are challenged with costpressure, decreasing cycle time and very rapid technologyand feature evolution. At the same time, several of thesecompanies have overloaded their R&D capacity and capa-bility with many technologies, complex roadmaps of multi-ple variants and unclear value contributions of productsand new features. Portfolio Management is still insuffi-ciently practiced for managing IT assets in a corporation[1]. The primary (and often sole) measurement is the finan-cial performance. Often, too many projects run in parallel,without concrete and quantitative objectives and withouttracking where they are with respect to expectations. Pro-ject proposals are evaluated in isolation from other ongo-ing activities. Projects are started or stopped based onlocal criteria, not considering the global trade-offs acrossall projects and opportunities [2]. Only one-third of all soft-ware engineering companies have techniques to effectivelyshare knowledge on their products and development pro-jects [1,2,20].

Fig. 1 shows the many challenges a software enterpriseor IT department are confronted with, such as competition,cost reduction, quality and cycle time improvement butalso technology hypes to be assessed and solutions to becreated. The challenges are different for different companiesbut must be mastered in order to remain competitive.

Mastering these challenges demands continuousimprovement along three axes, namely:

• Consolidating: Focusing on few relevant core productswhich distinguish the enterprise in the market; maximiz-ing the business value from these products; value crea-

tion from solutions instead of mere shrink-wrapproducts; establishing eco-systems of customers, suppli-ers and contractors.

• Industrializing: Mastering projects, processes andknowledge by intelligent collaboration. This is the focusof this article and case study.

• Globalizing: This is optional and depends on the marketto be addressed and size of the corporation. Small andmedium-sized enterprises might use global suppliers,while larger enterprises establish a global software engi-neering capability. The third axis is pointless without thefirst two, as many examples of failed global developmentshow [2].

We mastered these various challenges by embarking onproduct life-cycle management (PLM) several years ago –long before it became popular in IT. We were successfulwith PLM because we enriched it with a knowledge-centricapproach instead of following a tools-centric approach as ithappens often today [3]. A clear and objective-drivenimprovement strategy driven by business needs, such ascycle time reduction or improved predictability, avoidedthat we would build a theoretic knowledge managementor process improvement framework that would be of littlepractical use.

We will briefly define product life-cycle management(PLM) and knowledge management (KM) to clarify princi-ples that we applied. PLM is the overall business processthat governs a product or service from its inception tothe end of its life in order to achieve the best possible valuefor the business of the enterprise and its customers andpartners. It combines processes, people and tools for theeffective engineering of products – from their inceptionuntil end of service. KM is the process that deals with sys-tematically eliciting, structuring and facilitating the effi-cient retrieval and effective use of knowledge. It involvestacit knowledge of experts and explicit knowledge, codifiedin procedures, process and tools. KM stretches from know-how to know-what and know-why.

In our view, PLM and knowledge management mustmutually support each other. Knowledge-centric PLM

Globalizing(customers, markets,

engineers)

Consolidating(products, solutions,

eco-systems)

Industrializing(projects, processes,

knowledge)

Pressure toinnovate

Technologyhypes

Solutions(end-to-end)

Globalcompetition

Costreduction

Qualityimprovement

Cycle time

Continuous improvements

Productivityboost

Fig. 1. Mastering today’s challenges by consolidating, industrializing andglobalizing.

580 C. Ebert, J.D. Man / Information and Software Technology 50 (2008) 579–594

must bring together process, product and project knowl-edge from a learning perspective and thus improves engi-neering productivity. Fig. 2 illustrates this view of PLMand the need for good knowledge management. To workeffectively, people need to handle a variety of differentforms of knowledge from processes, technologies, projectsand products. PLM helps to integrate those along theentire life-cycle of a release or product or beyond to anentire portfolio.

Our ambition with knowledge-centric PLM is to enableR&D organizations to more effectively handle knowledgewithin the daily operational activities. Often informationis reused, but with high redundancies or manual overhead.At times, the redundancies create rework – as things arenot done right first – or even errors that remain in the prod-uct. An example is handling of product requirements andbusiness case information. If this information is not sharedbetween stakeholders along the project, the developmentwill end in exceeding time and budget with gold-platingand rework due to having the wrong focus.

Being able to not only reuse information but also embedknowledge into integrated workflows for specific tasks,generates immediate returns by making engineers moreflexible. Consider the time and effort necessary to moveengineers from one project to another. Having standardknowledge management around a standard product life-cycle reduces the learning curve to allow focusing on realtechnical challenges instead of organization overhead. Weshould however be aware that knowledge management isnot reduced to workflow management, which we considera facilitator for effective knowledge management.

Knowledge management systems offer different perspec-tives to allow for instance navigation based on work prod-ucts, roles or processes. Technological innovation andsuccessful new products are the results of well-oiled rela-tionships and tightly choreographed teamwork, not only

amongst the different business units or divisions of a corpo-ration, but also between autonomous and geographicallydispersed enterprises.

To ensure effective execution on project and productlevel, knowledge management should be closely linkedand integrated in the company’s product life-cycle. Typicallife-cycles might follow ISO 15288 (systems life-cycle [25])or ISO 12207 (software life-cycle [26]). They have in com-mon a gating process between major phases based ondefined criteria. These gates enforce evaluating the overallstatus (both commercial and technical) and deciding onwhether and how to proceed with the project. For illustra-tion, we will use a simplified product life-cycle as it appliesto software, systems and IT projects. Fig. 3 shows for eachof these standard life-cycle phases a sample of decisionsand actions that are taken to ensure progress against com-mitments and objectives. It highlights the various knowl-edge needs to guide those decisions. Our ambition to usePLM as a vehicle for synchronizing knowledge needsbecomes obvious from this introductory picture.

In the early years, we nicknamed this initiative ‘‘e-R&D’’ [3], but later on called it PLM as this term gotwidely used in industry over the past years. The vision ofPLM is to provide outstanding R&D performance. Thisis achieved through the three drivers of PLM, namely man-agement efficiency, process excellence and technology effec-tiveness. Management efficiency targets lean managementpractices and ensures that people take realistic commit-ments and deliver accordingly. Process improvementaddresses the R&D and product management processesand aims to improve our process capability. Technologyeffectiveness leverages on management efficiency and pro-cess excellence and looks into providing the right innova-tive technology to address our customers’ needs. The glueto bring these three drivers together is knowledgemanagement.

Fig. 2. Knowledge-centric product life-cycle management integrates processes, people and tools for effective engineering.

C. Ebert, J.D. Man / Information and Software Technology 50 (2008) 579–594 581

PLM as a concept and solution applies to software engi-neering as well as systems or hardware products. It appliesto different types and sizes of companies, because it is notprescribing a solution suitable only for big companies butrather a clear focus on processes along the life-cycle. Weuse it for complex solutions with multiple hardware andsoftware components as well as simple software services.For better understanding, this article narrows down thescope toward systems built primarily from softwarecomponents.

3. Related work

We will look here at the impact of related work in thedomains of product life-cycle management, knowledgemanagement and process improvement. Compared toother work in this domain, this article shows two majorbenefits, namely:

• Knowledge management embedded into PLM offers asolution for both efficiency improvement and complex-ity control in technical product development.

• Our longitudinal study in an industrial context showschange management over 5 years of incremental growthindicating that such solution needs sufficient time toevolve and become engrained in an organization andits genes.

KM has reached the software engineering community inthe 1990s. Software engineering knowledge was rarely ade-quately managed before. It was often randomly collectedand stored in corporate document vaults with little or nomeans for efficient and effective reuse. Increasingly, KMhas gained ground as a discipline that needs dedicatedattention, not only from a functional but specifically from

a cross-functional perspective [4,5]. Initiatives such asbuilding a coherent software process terminology [6] or cre-ating an initial body of knowledge [7] helped building afoundation to bring together very different disciplines. Asummary of the discipline of KM and its specific challengesin the software world is provided by Burke and Howard [8]and Dingsøyr and Conradi [22].

There are some publications that deal with this subjectand show how to bring knowledge and experiences intosoftware organizations [4,5,8–13,21,22,27]. Though theyprovide concrete examples, they mostly deal with handlingonly a single dimension of software engineering knowledge.For instance, how to reuse experiences from dealing withnonfunctional requirements is very pragmatically describedin [9]. Most references, however, are still more on the the-oretic side than answering practical questions from day-to-day project business [4,8,10,11,14,21]. Applicability andactual application in industry-scale application develop-ment and solutions integration are not always evident inmany of the above-mentioned research papers. Based ona quality improvement paradigm, Basili et al. defined theexperience factory [27] which tries to condense best prac-tices and redistribute them in new software engineeringprojects. But time was not yet ready for putting such ideasinto industrial software development, due to lack of for-malized processes and the necessary support tools. Basker-ville and Pries-Heje [13] mapped the capability maturitymodel on knowledge management and found that suchapproach could be enhanced with specific needs relatedto KM. Specifically, they indicated how to utilize KM ontop of ‘‘classic’’ process areas, such as training, in orderto mitigate the dependencies on specific skills andemployees.

An initial framework for KM needs from a softwareengineering viewpoint had been proposed by Martinez

• Go / No-Go fornext phase

• Decision for strate-gy and roadmap

• Decision to invest• Decision to

allocate resourcesfor next phase

• Action to providemore informationor analyses

• Decision to pro-ceed and allocateresources for development

• Decisions forbudget, features, priorities, time-lines, plans, mile-stones, suppliers


• Decision to pro-ceed and allocateresources for sales and service

• Decision during development

• Decisions duringmarket entry

• Launch decision• Action to provide

more information or analyses

• Decision to continue or todiscontinue the product

• Decisions duringservice and sales(repair, suppliers, features, changes,corrections, road-maps, support, versions andvariants)

Strategy Concep volutionMark et entr y

Development

• Go / No-Go fornext phase

• Decision for strate-gy and roadmap

• Decision to invest• Decision to

allocate resourcesfor next phase


• Decision to pro-ceed and allocateresources for development

• Decisions forbudget, features, priorities, time-lines, plans, mile-stones, suppliers


• Decision to pro-ceed and allocateresources for sales and service

• Decision during development

• Decisions duringmarket entry

• Launch decision• Action to provide

more information or analyses

• Decision to continue or todiscontinue the product

• Decisions duringservice and sales(repair, suppliers, features, changes,corrections, road-maps, support, versions andvariants)

Strategy Concep volutionMark et entr y

DevelopmentStrategy Concepttt volution

Mark et entr y

Development

Market entry

Development

Fig. 3. The context of PLM and the needs for effective knowledge management to drive coherent decisions.


et al. [14]. This study helps in determining an enterprise’sposition versus a generic framework of potential require-ments. It starts with evaluating the KM-specific needsand then maps them on the specification of requirements.The difficulty however is that it remains fairly abstract atthis point and offers little help to companies in buildingtheir own environment based on existing processes andenvironmental conditions. Aurum et al. [5] and Dingsøyrand Conradi [22] provide some useful case studies whichhelp using KM techniques in software engineering. Theyboth underline with many industry and scientific casesthe major problems in applying KM to software engineer-ing. There is a lack of agreed modeling languages thatallow effective tagging and retrieving of information. Soft-ware is also developed typically in a rather ad-hoc way,meaning that engineers prefer to invent something newbut dislike digesting somebody else’s previous work. Thelatter has changed with the growing interest in open sourcesoftware [23] which stimulates both knowledge sharing aswell as building open processes for evolving software com-ponents or tools.

PLM is about mastering knowledge to the benefit ofmanagement efficiency, technology effectiveness and pro-cess excellence. PLM though it heavily talks about integrat-ing processes has focused so far primarily on tools. Itemerged from hardware tools, such as product data man-agement, underlining the need for unique referentials toachieve reuse and configuration control. Often tool ven-dors market product life-cycle management as hardware-centric. This should not be a surprise since the supportevolved from the tradition of product data managementtools with focus on component descriptions, interfacedescriptions and structured representation of the ‘‘bill-of-material’’. Strict configuration management is an integralpart of this support due to the serious impact of any changeand the need to synchronize with many stakeholders. Insuch hardware-driven solutions, referential data, such asproduct data, and respective engineering change manage-ment were integrated with collaboration platforms andthe resulting engineering tool was labeled ‘‘PLM’’.

While PLM tools interwork with many HW design andmanufacturing tools, they only recently started to look intospecific software engineering environments. Examplesinclude Dassault/MatrixOne, Agile or PTC with theirhardware-centric design and data management tools,which increasingly interwork with software engineeringtools, such as IBM/Rational’s Clearquest for defect track-ing or Telelogic DOORS for requirements management.

We consider such tools only as components supportingpart of a broader process, covering all engineering pro-cesses and the interfaces to product management, supplychain, portfolio management and service management. Infact, portfolio management and product managementfunctions in our organization benefited from such inte-grated view on engineering because we could provide seam-less interfaces that ease decision-making along the entireproduct (and service) life-cycle. Processes without tools

have not much value. This was confirmed in a recent studyat the London School of Economics which we fully supportwith our own data (see Fig. 4) [2,24].

Other approaches merely extend enterprise data man-agement to cover some interfaces to engineering processesand label it PLM. For instance, major ERM vendorsevolved their environments to support engineering docu-ment management. CRM environments since recently inte-grate with defect tracking tools. However, such IT-centricapproaches do not go beyond interface management anddo not integrate with systems and software engineeringprocesses. Their scope is limited to interfaces and front-end processes.

We see PLM as a management principle guided by theneed for effective knowledge sharing and founded on man-agement efficiency, process excellence and technology effec-tiveness. We do envisage and recently see it with somevendor statements, that our knowledge-centric view onPLM will be adopted.

PLMneeds bothprocess and tools support as indicatedbyFig. 4. Tuning processes, improving project managementand establishing visibility on new product introduction– techniqueswell described by common improvement frame-works, such asCMMI [7] –will not cure this if not adequatelysupported by tools. The prospect of new, high-marginproducts, combined with the delayed impacts of resourceallocation decisions, seduce product managers into startingmore projects than their development resources can handle.Like in manufacturing during the 1980s, today’s softwarefactoriesmust focus simultaneously on the above-mentionedthree dimensions, namely management, process andtechnology.

The tight integration of project, product and processperspectives together with knowledge management acceler-ates process improvement in technical product develop-ment. This was so far not described in research andshows the value of our longitudinal study. While the SEIreports in its annual summaries a duration of over 3 yearsas mean time from CMMI maturity level 1 to maturitylevel 3 (which requests defined processes and shared engi-neering knowledge) [6], we could achieve at Alcatel-Lucent

HighLow

+ 2%0

+ 20%+ 8%

Tool support

Proc

ess

focu

sLo

wH

igh

HighLow

+ 2%0

+ 20%+ 8%

Tool support

Proc

ess

focu

sLo

wH

igh

Fig. 4. Efficiency gains with improved processes and tools. Tools withoutprocesses are nothing, processes without tools are not good enough.


an acceleration by up to 50%. We could also accelerate theramping up of new product development, e.g. in offshoresituations with different cultures involved – depending onthe underlying maturity level – up to few months for amaturity level 2 or 3 organization [19].

4. The environment of this case study

Alcatel-Lucent provides end-to-end communicationsolutions, enabling carriers, service providers and enter-prises to deploy and manage a user-centric communicationservice to any type of user, anywhere in the world. Lever-aging a long-term expertise in telecommunications networkequipment, applications and network services, Alcatel-Lucent faces today an increasing need to design, integrateand deploy solutions that are built from equipment andservices of a wide range of internal and external suppliers.Effective software engineering plays a key role in this pic-ture, as a vast majority of R&D investment today is onsoftware technology and applications.

To stay competitive with its systems and software devel-opment, Alcatel-Lucent has over the past years put in placean orchestrated improvement program of its processes andthe supporting engineering tools environment [3]. But thiswas not considered to be enough. We needed to effectivelyintegrate and utilize knowledge from three dimensions,namely projects, products and processes. We haveapproached PLM in three implementation tracks, namelystrengthened process capability, visibility and workflowintegration.

Strengthened process capability is key to our implemen-tation of PLM. Since more than a decade Alcatel-Lucenthas been successfully embracing the Capability MaturityModel (CMM) and, more recently, its successor, theCMMI, both owned and maintained by the Software Engi-neering Institute [6,7]. We combined this model with astrong focus on business objectives and metrics to follow-up of implementation of change. In fact, a close link toAlcatel-Lucent’s business needs was a major push to focuson what is essential for customers and shareholders. Forinstance, several years ago, our voice networks primarilyfocused on field quality improvement. Rapidly changingmarkets are pushing the carriers to offer new services at arapid pace. So we had to cut cycle time to less than halfover few years. Such seamless shift of priorities in a consis-tent and sustainable way is achieved with a strong organi-zational process focus.

How do engineering tools come into the picture? Pro-cesses without adequate tool support remain theoreticand difficult to enforce. Our objective is to improve visibil-ity in engineering and mastering a variety of workflows andexternal interfaces related to R&D. PLM must bridge theneeds of process improvement with tool support. Globalworkflows together describe how software engineeringwork products are designed and maintained. They alsoprovide the link to corporate business processes and spe-cific tools environments. Some are entirely internal to engi-

neering, while others are at the boundary to otherfunctions. An example for such a workflow and relatedinterfaces is service request management. Service requestsresult from field operations and some are treated withinR&D to implement corrections that are again deployedto the field.

In Alcatel-Lucent, these elements are centered on a stan-dardized product life-cycle (PLC) [15]. For well-orches-trated product launch, development, post-launch anddiscontinuance, all functions of the enterprise must playtheir role in developing and executing an integrated plan.The potential for growth as well as replacement must beassessed based on a common framework. Fig. 5 showsthe product life-cycle in a simplified format and how thedifferent product-related processes are anchored. Note thatwe portray the PLC as recursive and applicable to productsand their individual releases. Therefore, processes such asstrategy or concept repeat each other for each singleinstance of a product release. Our implementation ofPLM covers most of these processes to some degree, withfocus on visibility (e.g., progress, documents) and interfacemanagement. We will describe here the framework usedand how it was integrated to PLM.

To show concrete results from using PLM in day-to-daysoftware engineering projects, we took snapshots and sam-ples from the PLM product release portal. This portal andthe underlying PLM processes evolved since 2001 and com-prise today hundreds of products with their releases cover-ing all business divisions of Alcatel-Lucent. Project size ineffort ranges between some person-weeks and several 100person-years. All projects that had recorded valid data inthe history database were used. For empirical studies, suchas presented later to show the value of PLM, no ‘‘outliers’’have been thrown out, thus avoiding to overlook influencesfrom other parameters than the four process elements thatwe analyze here. The projects, though primarily in thedomains of embedded systems or software applications,cover a wide range of the entire world of software-intensiveprojects. Results therefore apply to other industries thancommunication. This is also supported by benchmarks

Strategy volution

Requirementsengineering,

Analysis

Architecture, design,

implementation

Validation,integration,

industrialization

Project management, risk management

Change management, configuration management

Supplier management

Stra

tegi

c m

anag

emen

t,po

rtfol

io m

anag

emen

t

Ope

ratio

n, s

ervi

ce,

mai

nten

ance

Prod

uct m

anag

emen

t

Quality management, quantitative management

Concept

,

,

,

t

,

,

,

t

Market entry

Development

t t t

Fig. 5. PLM provides the process architecture and the handles forcollaborative knowledge management and optimized tools solutions.


we have been doing in the field of automotive, defense andinformation systems.

5. Elements of software engineering knowledge

5.1. Project knowledge

Project knowledge is the knowledge about resources,functional and attribute requirements, work products, bud-get, timing, milestones, deliverables, increments, qualitytargets and performance parameters. Project knowledge isclosely linked with product and process knowledge. It dealswith the instantiation of processes to deliver a product.

KM for projects should address concrete use cases of theinitial target communities and then gradually grow to cap-ture more use cases. For instance, a key use case that weinitially defined and applied was: ‘‘Support the projectmanager to retrieve information from past projects thatapply to her current own project.’’ A project managementteam is typically interested to learn from previous projectsin order to better manage quality and reliability. A productline manager is interested to improve the portfolio he isresponsible for, and to ensure the right baselines and evo-lution paths are agreed and implemented to serve anever-changing market.

PLM for projects requires a clear definition of context,scope and objectives. These parameters are closely linkedto business objectives of the product line. A software pro-ject team might be interested in identifying which checklistto apply to improve coding or peer reviews. Departmentleaders in software organizations are interested in skill evo-lution that is aligned with future technology needs. Theymight also insist on deploying peer reviews and similartechniques to improve maintainability and become lessexpert-dependent.

Being able to not only reuse information but also embedthe respective processes into integrated workflows for spe-cific tasks generates immediate returns by making engineersmore flexible. Consider the time and effort necessary tomove engineers from one project to another. Having stan-dard knowledge management and standard PLM reducesthe learning curve to real technical challenges, instead oforganization overheads. We should however be aware thatknowledge management is not reduced to workflow man-agement, which we treat a facilitator for effective knowl-edge management.

5.2. Product knowledge

Product knowledge is the knowledge about productfeatures, and how they relate to other products, stan-dards, protocols and the like. Especially in telecommuni-cations, which is characterized by a particularly rapidtechnological change and uncertainty in an environmentthat often integrates technologies of several decades,product knowledge is the key success factor for a solu-tion supplier.

Developers need product knowledge to reuse successfulimplementation strategies and actual implementationalready realized before. Product management needs it tomanage release roadmaps and product portfolios. It is cru-cial for defining technology and marketing strategy and toevaluate whether products and solutions fit in these strate-gies. It is also key knowledge for senior management toestablish the optimal organizational structure for develop-ing, marketing and selling products and solutions. In atechnology-driven company, product knowledge is struc-tured hierarchically and maintained by multiplestakeholders.

5.3. Process knowledge

Process knowledge is the knowledge about business pro-cesses, workflows, responsibilities, supporting technologiesand interfaces between processes. In software engineering –unlike hardware engineering – this aspect of knowledgemanagement is often neglected and as a result, activitiesdo not scale up and performance decreases.

A common product life-cycle across the entire company isthe global framework for detailed processes, some of whichare defined at the corporate level but many of which are tai-lored in the business divisions to adapt to their specificneeds. We can definitely recommend to start with a genericproduct life-cycle (PLC) and then continue on a moredetailed level, rather than working in the opposite direction.This top-down approach applies for the entire discussionaround business process reengineering and e-commerceintroduction. Start with a generic (business) process, applyit in pilots and product lines, in order to improve on businessprocesses, and then allow specific tailoring.

Sharing and reusing process knowledge is the most diffi-cult amongst the three dimensions. A small example showsthe intrinsic difficulties. To successfully deliver a productwith heterogeneous architecture and a mixture of legacycomponents built in various languages, certain processesmust be aligned on the project level. This holds for projectmanagement, configuration management and requirementsmanagement. It allows tracing customer requirements thatmight affect several components through the project life-cycle. It allows reusing requirements in a product line. Onthe other hand, design processes and validation strategiesare so close to the individual components’ architectureand development paradigms that process standardizationis very delicate. And, for efficiency reasons, the managerof such heterogeneous project or product line surely wouldnot like that within each small team the work producttemplates or tool-based workflows were redefined.

6. Introducing and using PLM

As we have learned from the article so far, industrial sys-tems and software engineering must integrate project,product and process knowledge with a perspective onorganizational learning. The answer we investigate here is


primarily centered on enabling R&D organizations to moreeffectively handle knowledge within the daily operationalactivities. Often information is reused, but with high redun-dancies or manual overhead. At times, the redundanciescreate rework or even errors that remain in the product.An example of such redundancies leading to defects is han-dling of product requirements and business caseinformation.

To benefit from improved business processes, the differ-ent functions of the enterprise plus potential external part-ners (e.g. component suppliers, outsource manufacturing)need to agree on processes and practices. They need to havecommon access to knowledge, performance metrics anddecision-making protocols. They need to share informa-tion, communication and underlying resources.

The barriers to such harmonization and cooperation arenot to be underestimated. They range over language barri-ers, time zone barriers, incompatible technological infra-structures, clashing product line cultures and not-invented-here syndromes. An obvious barrier is the profitand loss responsibility that results, especially in toughtimes, in a focus on current quarter results and not ininvestments in future infrastructure. Incumbents perceiveproviding visibility a risk, because they become account-able and more subject to internal competition.

Processes must be easily accessible for the practitionersand managers. They must integrate seamlessly. By focusingon the essence of processes, integrating processes elementswith each other and providing complete tools solutions,organizations can tailor processes to meet specific needsand allow localized and problem- or skill-specific softwarepractices, while still ensuring that basic objectives of theorganization are achieved. This is what we call managedprocess diversity.

Practitioners do not look for heavy process documenta-tion, but rather for process support, that exactly describeswhat they have to do at the moment they have to do it.Modular process elements must be combined according

to a specific role or work product to be delivered. Stillthe need for an organizational process, as described byCMMI maturity level 3 is strongly emphasized and rein-forced [7]. To bridge this gap, different approaches havebeen described recently for managing process diversity[16–18]. Fig. 6 shows the solution to above-mentioneduse case of supporting a project manager to retrieve infor-mation. The information collected at the product and pro-ject level is aggregated at the enterprise level with filteringby business division, business unit and product line. Thisallows the available information to be used for portfoliomanagement. Managers can also drill down efficiently todetailed information about ongoing and proposed projects.

Let us now look into how we built our knowledge-cen-tric PLM solution. In a first step, we agreed on the setsof processes and process elements that should be subjectto tailoring and those that should be invariant. This wascaptured in a simple process meta model (Fig. 7) includingmilestones (when?), roles (who?), work products (what?)and activities or workflows (how?).

In the next step, we investigated which criteria woulddetermine selection of a specific process. We identified sev-

Fig. 6. PLM with knowledge management to zoom from a product line summary into single engineering projects and their respective project statusinformation.

WorkProduct

Activity

Role Milestone

What?

How?

Who?

When?

Global metamodelwith entities, relationships and attributes

Define instances of entities, their relationships and attributes

Product ManagerTechnical Project ManagerProduct Quality Manager.....

Business CaseTechnical Requirements SpecificationProject Quality Plan.....

DR0DR0+DR1.....

WorkProduct

Activity

Role Milestone

What?

How?

Who?

When?

Global metamodelwith entities, relationships and attributes

Define instances of entities, their relationships and attributes

Product ManagerTechnical Project ManagerProduct Quality Manager.....

Business CaseTechnical Requirements SpecificationProject Quality Plan.....

DR0DR0+DR1.....

Fig. 7. The underlying process meta model and how instances are built.


eral criteria that determine the layout of processes: the pro-ject size in terms of effort; the product type (for instancewhether it is a generic R&D project, or a customizationor maintenance project, or a prototype); specific compo-nent criteria (e.g. design paradigm, programming language,development platform, industrialization parameters relatedto market introduction and customer interfaces) and theprocess edition (the process is subject to configurationmanagement, especially for big projects which overlap withongoing improvement activities).

Having an understanding of the organizational pro-cesses, the next step is to understand how processes are tai-lored in projects or product lines, and how they link tolegacy process descriptions with a finer level of granularity.The process meta model helps with integrating and facili-tating the sharing of process elements across the bordersof product lines. Fig. 8 illustrates how such an instantiationlooks like. For example, common project roles are definedat the corporate level independent of the developmentmodel, e.g. the Product Manager, Technical Project Man-ager, Product Quality Manager. The model can be tailoredby adding specific roles such as the System Architect orIntegration Test Leader for a specific development model.

Knowing about how process elements link with eachother and how they are tailored, the next step is to integrateR&D workflows, such as software development or soft-ware maintenance with their (e-) business counterparts,such as supply chain and service request management.Our vision was centered on visibility in engineering andmastering a variety of workflows and external interfacesdescribing how software engineering artifacts are graduallygenerated. Some are internal to engineering, while othersare at the boundary to other functions. They all have theirown tool environments, often overlapping with each other.Many of these tools are proprietary, at times legacy and

surely not intended originally to work with each other orto be managed externally.

We have not tried to immediately replace this collectionof different engineering tools by a single comprehensivesolution for various reasons, such as cost, risk and timing.Instead, we have developed a lightweight framework forfederating the existing tools. This approach has manyadvantages. It can start small and still immediately achievea corporate scope. Based on the meta model illustrated inFig. 7 and as an integral part of our PLM approach, wedeveloped a life-cycle portal and workflow managementanchoring the dates and status of the major milestones,the names of actors of key roles and references to key workproducts as defined in the standard product life-cycle. Theportal is shown in Fig. 9. The portal was linked to the orga-nizational hierarchy maintained in one of the corporate ref-erential databases. This modest initial system could alreadyprovide some powerful support: structured navigationthrough the organizational hierarchy, presentation ofroadmaps at each of the levels of the organization, visibilityon key actors. From the very beginning, we also establishedsimple hyperlink interfaces to corporate solutions: theorganizational referential database already mentioned,the global directory services for authentication and emailsupport, the product catalog. Many embedded hyperlinksallow navigating with a few clicks to the final element thereader is interested in. In fact, we managed to get with fourclicks from the Alcatel-Lucent corporate Intranet-home-page to any running project with its data, processes andknowledge.

Initially, this portal provided an integrated view on pro-ject and product knowledge. The process perspective wasmanaged in a separate process asset library, partly at thecorporate level (for the corporate standards) but mainlyat the business unit level for the detailed engineering pro-

Fig. 8. Instantiation of a tailored process model by reusing available process artifacts and building upon the common underlying meta model.


cesses. The meta model on which the product life-cycle isbased is also the framework for the process description.Process assets include checklists for decision reviews, tem-plates and process descriptions for the creation of workproducts, role descriptions, recommended tools and associ-ate user guides. It was a straightforward step to add linksfrom the product release portal to the corresponding pro-cess assets.

The integration can easily be achieved at the corporatelevel and with corporate solutions but this is obviouslynot sufficient. How did we adapt this approach to supportseamless integration with the heterogeneous set of pro-cesses and tools at the product line level? We addressed thisfirst at the level of the meta model and defined an inheri-tance mechanism to allow tailoring of the model. The tai-loring is typically used to add more detail but is notallowed to alter the corporate framework and, even moreimportantly, must be based on the same meta model.Although process descriptions in the product lines hadbeen developed without such a model in mind, they couldnevertheless be mapped easily to it due to its very genericnature. As explained above, the basic entities of the modeladdress the basic questions that are addressed in any pro-cess description: what must be done, how, by whom andhow. This allowed us to provide a first level of integrationinto the operational systems and asset libraries of the prod-uct lines. For more detailed support and navigation, thesesystems can take over at a lower level.

It should be clear that the support environment is not anad hoc set of hyperlinked web pages and tools. The productlife-cycle provides a standard and mandatory frameworkfor all processes and instantiations of these processes inprojects. The object-oriented inheritance mechanism ofthe product release portal ensures a seamless presentationof the corporate processes and the detailed product lineprocesses in a single view from the operational context ofa selected project.

Integration is much more than just hyperlinking of doc-uments. But it is clear that key elements of the business casefor our integrated PLM approach are to avoid multiple

entries of the same data, thus reducing inconsistencies,inaccuracies and excessive rework. Projects are typicallyrequired to submit the same data in various local supporttools, presentations for project reviews and corporate dat-abases for aggregated reporting. To position the productrelease portal as a single source of information, we offera simple export facility to enable local tools to extract dataand merge it with more detailed information collected inthose local tools. Also an import mechanism is availableto support automatic uploading from local databases.

Another element of our strategy is to rely on existingcorporate systems and standards as much as possible toavoid duplication of data. An example is the interface todocument management systems. To avoid configurationmanagement problems, documents are not stored in theproduct release portal but hyperlinks are provided into sev-eral document management systems. While documents canbe stored in different systems, they are uniquely identifiedby means of a document number. When a document isentered in a document management system, some metadataincluding the identity of the system is copied into a globaldocument number register. The product release portal isintegrated with the register to generate hyperlinks intothe document management system automatically.

The entry level for the portal is the organization struc-ture which makes it equally accessible for all functionsand not just for R&D. Examples are marketing (e.g. howfar is a product from its delivery?), security (where are cer-tain protocols or components embedded that might causesecurity threats?) or procurement (how much royalties dowe have to pay in a certain region?).

Usability of any workflow support system is determinedby the degree to which it can be adapted or tailored to theprojects’ needs. There are organizational and project-spe-cific environmental constraints, which make it virtuallyimpossible to apply the workflow system out of the box.Most commercially available workflow systems thereforeoffer some adaptation of a standard workflow to a pro-ject-oriented instance, which ensures that each single activ-ity supports the project targets. Adaptation is achieved by

Fig. 9. Different views on the relevant software engineering knowledge from project, product and processes and examples of cross-referencing.


offering a set of standard workflows, which are selected(e.g. incremental delivery vs. grand design; parallel vs.sequential development; development vs. maintenance).On a lower level, work products are defined or selectedout of a pre-defined catalogue. Some models distinguishamong mandatory and optional components. Most ofthem are implemented based on object-oriented paradigmsthat allow building of classes of process elements and (lim-ited) inheritance in case that hierarchical refinement isoffered. Many vendors are offering platforms for enterpriseportals with flexible mechanisms to display informationfrom various sources including legacy systems, but alsothose systems fail to offer the support for integration andorganizational tailoring we want to achieve [10].

Low-level process change management is exactly thepoint where current workflow systems for unified processesfail. Though these workflow systems offer lots of function-ality from various application use cases, they do not wellintegrate process needs on the above-mentioned levels intoa hierarchy with guided selection. We therefore decided tobuild the integration layer ourselves; based on simple andgenerally supported web standards, creating the necessaryflexibility in a situation where not all requirements of thesoftware engineering workflow management would alreadybe known.

The tool itself was built entirely open to both externalbusiness processes and legacy R&D processes, strictly fol-lowing the architecture described above. To support orga-nizational tailoring, the organizational structure is includedautomatically from the corporate reference database wherethis information is maintained. All person-related informa-tion is also kept up-to-date through an automatic link intothe corporate directory services, which are also used as thebasis for a common authentication mechanism.

With the availability of shared knowledge, the next chal-lenge was how to push its utilization. Only active knowl-edge management guarantees the information qualityrequested by its users. This is in many companies an unre-solved chicken–egg problem, because KM is approachedonly with tools in mind – and not with people and pro-cesses. To break that circle of not using available knowl-edge, we want to emphasize concrete guidelines:

Cope with distance and diversity. Use different communi-cation channels to address audiences that are less familiarwith each other. Apply remote team building by havingnon-technical discussions or events by telephone or video.Distributed management demands more effort, which mustbe budgeted both in terms of effort as well as skills. As arule, you should plan some 5–10% of overhead for manag-ing these teams. In the worst-case scenario with highly frag-mented tasks and loss of escalation to resolve conflicts, theoverhead can grow to 20–40% as we experienced in somecases.

Plan for sufficient training. A common failure in globalsoftware engineering is the lack of necessary technical orprocess skills and thus delays. Assure that skills and com-petences ramp up in due time before they are needed in

the project. Adapt training mechanisms to the variety ofcultures and preferred communication means. Mix differ-ent formats, such as classroom (can be remote and virtual),life webinars or e-learning of predigested contents. Forcedepartments, team leads and project managers to periodi-cally assess skills and skill needs of their teams. Demandtraining plans for each single engineer. Always rememberthat sufficient training and right skills is one of the bestmotivational instruments. Different roles and competencesmust be individually coached on the specific knowledgeneeds. Consider sending managers and staff to remotesides. Rotate middle management across sites so they willnot get into the ‘‘us versus them’’ mode. Assure that man-agers feel obliged to live for some time in various culturesand countries.

Foster knowledge sharing. Install performance objectivesand indicators around the sharing of knowledge and thesuccessful collaboration as a team. A very simple stepcould be to advocate shared team targets with a distinctpercentage across a product or development activity. Ded-icated awards might also help as we found out at Alcatel-Lucent. Agree explicit communication protocols with theteams. This might include the recommended communica-tion channels and when and how to use them most effec-tively. For instance, it seems a normal pattern for manyengineers to send e-mails if they do not know other peoplein person. It is a good practice to demand that your engi-neers also call unknown persons by phone in order todirectly share technical questions. Have a common productrelease portal for all project-related information. We foundfor instance that as long as document attachments are sent,people effectively learn less and trust they could always calla peer to retrieve the information. Instead, we advocatedsending pointers to repositories and link the various repos-itories by means of common context (e.g. by tagging) andthrough search engines. Today we can even use dynami-cally updated links depending on what project is chosen(Fig. 10).

Fig. 10. Linking the dimensions of project, product and processes.


7. Results

Knowledge is a crucial resource that drives future suc-cess and must therefore be adequately managed. Wedescribed a PLM concept and implementation that effec-tively integrates systems and software engineering process,tools and KM. Like any other improvement a knowledgemanagement program is only effective if broadly used.We followed up usage and usefulness during the implemen-tation. Quantitative measures give a feedback on numberof unique visitors per site, number of page visits for criticalinformation, such as project homepages, number of docu-ments or number of visits directed by search engine results.More relevant even are qualitative measures like how muchvalue has been created by the process of sharingproject, product and process knowledge, reusing availableknowledge, and what new competencies and expertise havebeen built-up in the organization and what is the value ofit.

We introduced the PLM concepts in several steps. Man-aging process knowledge was already on the move in thevarious organizations when they started CMM(I)-basedprocess improvements. Project and product informationstarted to be managed via the product release portals whenwe had a critical mass of product lines embarking all at thesame time on CMM(I) maturity levels 2 and 3. During theintroduction years of this product release portal across thecompany, we reached a growth of access rate of 10% andmore per month. Typically, all product managers and engi-neering management (e.g., line managers, team leads, qual-ity managers, support) utilize it. Today with quantitativelymanaged processes and continuous improvement, the plat-form facilitates access to company-wide performance data,creates roadmap visibility and offers standardized access toprocesses, workflows, roles and competence management.The system has a registered user community of over10,000 people and around 450 different visitors each work-ing day.

Although it is tempting to try and demonstrate theimpact of knowledge management on the performance ofthe organization quantitatively, we need to recognize someimportant factors that influence the feasibility and confi-dence level of such measurements, especially in this casestudy.

• The deployment of knowledge management wenthand-in-hand with process improvement and growingmaturity of the participating organizations. Without a‘‘control group’’ to assess the impact without knowledgemanagement and all other factors kept equal, it isimpossible to attribute measured improvements toknowledge management only.

• Often global data on the performance of business divi-sions only becomes visible with the introduction of theenvironment to support knowledge management. Thiscauses a lack of comparable data for the period beforeknowledge management was deployed.

• The impact of knowledge management is not likely to beincremental andmay not show in the traditional engineer-ing and project measurements. The latter focuses onwhether the product was built right, while PLM andKMhave an effect on whether you built the right productor implement the right features at the right time.

Obtained benefits can be extracted with activities thatwould not have been possible without this frameworkand have a direct influence or the efficiency or effectivenessof the company

• The members of the Project Core Teams of all productreleases are registered in the product release portallinked to their role. Distribution lists for each role canbe generated automatically to support selective targetingof notifications of dedicated training or other importantmessage to all affected persons.

• The system supports the corporate Product Life-cyclebut also registers any tailoring that is used in businessdivisions. This information is evaluated and used toguide the evolution of the corporate PLC, by identifyingtailoring that is beneficial to the entire company andincorporating this at the corporate level for applicationacross all divisions.

• The operational support environment is integrated withthe process environment. A product release portal ini-tially contains a template with work products that mustbe developed and pointers to the templates for thesework products and links to document management sys-tems where the documents can be uploaded. Once thedocument has been uploaded, the link is automaticallyreplaced by a pointer to the document itself to supportfurther updates. Process knowledge must not besearched in a separate database but is available just-in-time in the operational support environment.

• A survey mainly among Marketing, Pre-Sales and Salesfunctions revealed that 89% considered the informationof the described solution as very important or importantfor their work. Sixty percent of the respondents fre-quently accessed the portal to obtain information. Thiswas still not replacing person contact because 80% (also)frequently contacted the product manager and 70% theproduct marketing manager to obtain information.Eighty percent of the respondents would actually preferto have the information available in the support envi-ronment. The main reasons for relying on personal con-tact were the desire to get the latest information and alsoa lack of knowledge about all features of the supportenvironment. It should also be noted that the personalcommunication is well supported by the portal becauseall key actors of each product release are registered witha link to contact information (telephone, E-mail).

On top of these rather qualitative results, we also triedto identify controlled experiments where our PLM solu-tion was introduced in settings that allowed measuring


the impact before and after the changes (for details onmeasuring processes and ROI see [2]). Fig. 11 showsthe effects on engineering efficiency during the introduc-tion of PLM to several software development teams.We took a snapshot of defect detection along the entireproduct development from comparable projects. Threescenarios are provided that lie roughly 5 years apart.They are represented as three scenarios in the graph.The horizontal axis provides relative project timebetween start and delivery to field usage. The axis is nor-malized to allow comparing projects of different dura-tion. The vertical axis provides relative defect detectionover project time, also on a relative scale. Combiningthese two views in one graph allows to compare whendefects were effectively detected and removed along theproduct life-cycle. To flatter such defect detection curvein the beginning, the more defects are delayed in theirremoval to activities after the activity which introducedthe defects, thus increasing cost of engineering [2].

The projects were customization projects (i.e. variantdevelopment) of a communication system at Alcatel-Lucent. The size of the projects is roughly 10 person years,while the size of the software organization is about 200 per-sons. The duration is about 1 year from start of specifica-tion until release. Expected release quality was the samedue to existing frame contracts. This allowed a benchmark-ing of defect detection because most influencing parameters– except PLM introduction – were stable during the fieldstudy. Technology used is software embedded to hardwarefor the control and management of these systems. This typeof software is comparable to what many other companiesare doing and therefore shows an interesting benchmarkon the effects of PLM.

Scenario A was our starting point before we introducedany change. It was the traditional process with design,implementation and integration exhibiting late defectdetection and unpredictable release time. The S-curve inFig. 11 indicates that defects are detected mostly duringtest thus creating extra rework and high cost of non-qual-ity. We first embarked on process improvement based onthe capability maturity model but without tools and knowl-edge management. Effects were visible with a more linearcurve of defect detection. But still we were not satisfiedas engineering work had become somewhat cumbersomedue to heavy processes. We introduced PLM as describedin this article with a strong focus on structuring engineeringknowledge along the domains of process, project, productand technology knowledge. With these changes engineerswere able to directly access specifications when doing areview, or testers could verify their test cases with originalcustomer requirements, and so on. As a result, defect detec-tion is now almost linear with around 40% of defects foundmore than 30% earlier than before contributing to a morethan 30% reduction of cost of non-quality.

When looking into the different dimensions of knowl-edge within R&D, we distinguish product knowledge, pro-cess knowledge and project knowledge. PLM drivesproductivity improvement and thus frees resources forinnovation. The business case combines several aspects(see also Fig. 1 which sets up the challenge of PLM), suchas improved quality, reduced cycle time or better produc-tivity. Specifically, the combination of KM (mostly implicitknowledge) and explicit project and process information incoaching of engineers and managers has tangible benefits.Such coaching will cost but it does pay off. Looking onlyat cost of non-quality, i.e. time to detect and correct

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Szenario C 0% 4% 10% 24% 32% 51% 60% 71% 84% 92% 100%

Szenario B 0% 0% 1% 5% 15% 36% 46% 58% 71% 84% 100%

Szenario A 0% 0% 0% 0% 4% 15% 29% 48% 62% 81% 100%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Cycle time (relative scale over product development)

Def

ect d

etec

tion

(rela

tive

scal

e to

talin

g al

lat

defe

cts

foun

d du

ring

prod

uct d

evel

opm

ent) Scenario C: Efficient defect detection

with lowest cost of non-quality due to full PLM and knowledge management

Scenario B: Improved efficiencydue to better processes, but , without support of tools and KM

Scenario A: Starting point with late defect detection (inefficientprocesses)

Fig. 11. Efficiency improvements during the stepwise introduction of PLM.


defects, we found that projects with intensive coaching (ca.1–2 percent of accumulated phase effort) could reduce thecost of non-quality in the respective engineering phase byover 20% (more details in [2,19]).

We can directly address the customer needs by linkingdedicated improvement objectives, such as return rate,via the product release portal (with all type of performancefigures) to process changes in R&D. Over past years, Alca-tel-Lucent proved substantial field quality improvementsand defect reduction. Two-digit field quality improvementshave been shown in Alcatel-Lucent by applying thisapproach. The efficiency and effectiveness of engineeringprocesses directly influence engineering cycle time [2]. Forinstance, earlier defect detection means faster and morecomprehensive defect correction. A defect found duringdevelopment costs according to our own studies some 5–20% of the effort to correct compared to its detection dur-ing test. Utilizing a consistent product life-cycle and pro-cess repository is a necessary condition for reducing cycletime, as they reduce frictions of unclear interfaces andresponsibilities as well as cutting rework because of incon-sistent assumptions and cutting retrieval time for specificdocuments and work products. Several product lines cutcycle time to almost half with strong focus on productlife-cycle and continuous process improvement. Again thevisibility of performance together with knowing whichchanges contributed to the effects helps in setting the stageand effectively sharing best practices.

With decreasing size and duration of projects, engineersneed to be flexible to quickly start working in a new envi-ronment. While technical challenges cannot be reduced,the organizational and administrative overheads must bemanaged and limited. Alcatel-Lucent relies on a consistentproduct life-cycle across the company to ensure we candeliver solutions independent of where the componentscome from. In a company the size of Alcatel-Lucent, it iskey to align working environments and the developmentprocess in order to reduce the learning curves when startinga project. With process asset libraries linked to tools, weare able to filter out and evaluate scenarios of how processchange affects tools, or where tool changes would influenceprocesses. So-called ‘‘best-practices’’ can be communicatedwith related tools and procedures to move up engineeringeffectiveness and learn from the best in class. Interfacesto tools and their user guides can now be embedded inthe process support environment. PLM supports integratedworkflows and knowing how a process relates to a productline or the current project development phase. For exam-ple, clicking on a work product name can activate an inter-face to a document management system and administrativedata, such as the document number, are automaticallyderived from the project context. Information is presentedin a consistent way for all projects, avoiding replication ofdata and reducing search time. The product life-cycle viewof the workflow system provides a dashboard with immedi-ate visibility on key data and responsibilities contributingto management efficiency.

Increasingly, project roles and also specific work prod-uct templates or process related roles are standardizedand can be reused thus facilitating more consistent skilland human resource management. Transferring productsto another location, as is today often the case, is facilitatedby standardized role descriptions and workflows. Ramp-uptime is shorter with new engineers responsible for suchtransferred products. We found during the introductionof our development centers in Asia that organizations withdefined and continuously improving processes using thePLM framework were faster and more effective in master-ing global software engineering.

8. Conclusion and outlook

We have shown the benefits of an approach to combineknowledge management (KM) and product life-cycle man-agement (PLM) at Alcatel-Lucent by bringing togetherknowledge about products, projects and processes. PLMhas been successfully growing from one product line togradually cover the entire company today, independentof the type of markets, products or solutions. TodayPLM concepts are being introduced in all product linesin order to stimulate organizational learning, and improve-ments. With this initiative, R&D is fully included into oure-business evolution.

We do not rely on general-purpose mechanisms forknowledge management but strongly rely on a commonlyapplied corporate product life-cycle, which provides theframework for knowledge management. Process assetsare linked to the product life-cycle (PLC) definition, andproduct and project data are following the same structure.The corporate PLC can be tailored to adapt to the specificneeds of the product lines. This tailored life-cycle providesthe interface to detailed processes and tools support of theproduct lines. A product release portal supports the instan-tiation of the PLC for each product release and provides afederation framework for process, product and projectknowledge.

What did we achieve with PLM? Since we considerknowledge management a regular management activity,we followed through like in other improvement projectsby looking into performance results from real projects, aswell as some process-related aspects, such as knowledgeutilization. We found improved quality, reduced cycle time,improved engineering flexibility, reduced overheadsimproved communication, increasing alignment of pro-cesses and tools and faster ramp-up time and skill manage-ment. Initially, improved visibility and alignedterminologies and roles already brought huge gains, as theyfacilitate a borderless solution building inside the company.

The results of the survey mentioned above gives usimportant clues about future work. We should not expectthat all knowledge can be codified and made available viathe intranet. Personal contact will always be necessary toprovide context and analysis. The support system shouldtherefore be extended to facilitate interpersonal communi-


cation and evolve toward a global who-is-who not only atthe operational product/project management level but alsoat the tactical and strategic level.

Correctness and completeness of the information isanother aspect that needs to be worked on. We are con-vinced this cannot be achieved by imposing a reporting dis-cipline only. It can only truly be achieved by ensuring thatthe provider of information is directly benefiting frommaking the information available. This can be achievedto continuing to evolve the system to ensure informationcan be captured as early as possible when it is required atthe lowest operational level, e.g. by supporting period pro-ject reporting in presentation format to avoid informationis presented first a set of slides for the project review beforeit is entered in the system.

To conclude, we recall a few of the key success factorsfor our approach:

• the systematic use of a standardized PLC as the frame-work for processes and tools support,

• the definition of a tailoring mechanism to enable leanadaptation of this PLC to the specific needs of businessunits,

• the development of a lightweight product release portalas primary access point for all project relatedinformation,

• a clear focus on knowledge and competences rather thanIT infrastructure to master PLM needs across thecompany.

PLM as a concept and vision is currently on its way intothe mainstream software and systems industry. Recent evo-lutions in the PLM domain signal that vendors realize thevalue of the more integrated PLM concept which wedescribed in this article. Hardware CAD vendors like Men-tor are moving into the software domain [28]; software IDEvendors, such as Borland with their ‘‘application life-cyclemanagement’’ [29] or Telelogic with their ‘‘enterprise life-cycle management’’ [30], are moving toward processimprovement and are evolving dedicated PLM solutions;systems tools vendors such as Dassault [31] are growinginto knowledge and systems data management; and dedi-cated systems engineering PLM environments built aroundknowledge sharing and collaboration such as eASEE [32]are starting to be used in systems and software industriesrather than stand-alone engineering tools suites. Comparedto the more traditional approaches, such as extending anexisting PDM-tool, dedicated PLM-solutions like eASEEare built around concrete business needs such as reusingsoftware components or integrating documents and prod-uct or variant data.

What is next in PLM? Knowledge management must bebetter linked to business. Aligned business objectives andmetrics must guide and monitor the development pro-cesses, the product lines and the project teams. Take asan example a mobile phone or game design (with lots ofembedded software). Being a commodity, business-

oriented targets cover return rates or brand loyalty. Defectsincrease return rate and reduce brand loyalty with devas-tating business impacts. Looking to projects, productsand processes will improve the design away from overlynarrow focus on manufacturing aspects toward usabilityengineering. Knowledge and experience from past projectswill be embedded into the underlying design processes. Westress the need for adequate knowledge management (KM)as a basis for success in product and solution development– an aspect going well beyond most PLM approaches oftoday.

References

[1] Meta Group, The business of IT portfolio-management: balancingrisk, innovation and ROI. White Paper. January 2002.

[2] C. Ebert, R. Dumke, Software Measurement, Springer, Berlin,Heidelberg, New York, 2007.

[3] F. Harvey, Bright stars in the Jupiter project. Financial Times (18September 2002) 38.

[4] S.K. Chang, Handbook of Software Engineering and KnowledgeEngineering, vol. 1, World Scientific, Singapore , 2001.

[5] A. Aurum et al. (Eds.), Managing Software Engineering Knowledge,Springer, Berlin, 2003, ISBN: 3-540-00370-3.

[6] SEI: CMMI Executive Overview. <http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-exec-overview06.pdf>, 2006. Cited 22 May2007.

[7] M.B. Chrissis, M. Konrad, S. Shrum, CMMI. Guidelines for ProcessIntegration and Product Improvement, second ed., Addison-Wesley,Reading, USA, 2006.

[8] G.D. Burke, W.H. Howard, Knowledge Management and ProcessImprovement: A Union of Two Disciplines. CrossTalk magazine,June 2005. <http://www.stsc.hill.af.mil/crosstalk/2005/06/0506Bur-ke.html>. Cited 22 May 2007.

[9] K. Schneider, J.-P. von Hunnius, Effective experience repositories forsoftware engineering. Proceedings of International Conference onSoftware Engineering 2003. IEEE Computer Society. Los Alamitos,CA, USA, 2003, pp. 534–539.

[10] M. Lindvall, I. Rus, Knowledge Management for SoftwareOrganizations, in: A. Aurum et al. (Eds.), Managing SoftwareEngineering Knowledge, Springer, New York, USA, 2003 (Chapter4).

[11] J.S. Edwards, Managing Software Engineers and their Knowledge, in:A. Aurum et al. (Eds.), Managing Software Engineering Knowledge,Springer, New York, USA, 2003 (Chapter 1).

[12] I. Rus, M. Lindvall, Knowledge management in software engineering,Special issue of IEEE Software 19 (3) (2002) 26–38.

[13] R. Baskerville, J. Pries-Heje, Managing knowledge capability andmaturity, in: T. Larsen, L. Levine, J. DeGross (Eds.), InformationSystems: Current Issues and Future Changes, IFIP, Laxenburg,Austria, 1999, pp. 175–196.

[14] P. Martinez et al., Requirements for a knowledge managementframework to be used in software intensive organizations. IEEEInternational Conference on Information Reuse and Integration. IRI-2005, 15–17 August 2005. IEEE Computer Society, Los Alamitos,2005, pp. 554–559.

[15] C. Ebert, Understanding the product life-cycle: four key requirementsengineering techniques, IEEE Software 23 (2006) 19–25.

[16] M. Lindvall, I. Rus, Process diversity in software development. Guesteditor’s introduction to special volume on process diversity, IEEESoftware 17 (4) (2000) 14–18.

[17] M. Deck, Managing process diversity while improving your practices,IEEE Software 18 (3) (2001) 21–27.

[18] A. Cockburn, Selecting a project’s methodology, IEEE Software 17(4) (2000) 64–71.


[19] C. Ebert, Global Software Engineering. IEEE ReadyNote (e-Book),IEEE Computer Society, Los Alamitos, USA, 2006 <http://www.computer.org/portal/cms_docs_cs/ieeecs/jsp/ReadyNotes/dis-playRNCatalog.jsp>. Cited 22 May 2007.

[20] Cathleen A. Benko, Warren McFarlan, Connecting the Dots.Aligning Your Project Portfolio with Corporate Objectives,McGraw-Hill, New York, USA, 2003.

[21] L. Scott et al., Understanding the use of an electronic process guide,Information and Software Technology 44 (10) (2002) 601–616.

[22] T. Dingsøyr, R. Conradi, A survey of case studies of the use ofknowledge management in software engineering, InternationalJournal of Software Engineering and Knowledge 12 (4) (2002)391–414.

[23] C. Ebert, Open source drives innovation, IEEE Software 24 (3) (2007)105–109.

[24] London School of Economics mit McKinsey: Does IT improveperformance? June 2005.

[25] ISO/IEC 15288:2002. Systems engineering – System life-cycle pro-cesses. ISO, <http://www.iso.org>, 2002.

[26] ISO/IEC 12207:1995. Information technology – Software life-cycleprocesses, ISO, <http://www.iso.org>, 1995.

[27] V.R. Basili, G.H.D. Caldiera, Rombach: experience factory, in: J.J.Marciniak (Ed.), Encyclopedia of Software Engineering, John Wiley& Sons, New York, 1994, pp. 469–476.

[28] Mentor Graphics PLM solutions, <http://www.mentor.com/>. Cited11 June 2007.

[29] Borland PLM and application life-cycle management solutions,<http://www.borland.com/>. Cited 11 June 2007.

[30] Telelogic enterprise life-cycle management solutions, <http://www.telelogic.com/solutions/elm.cfm>. Cited 11 June 2007.

[31] Dassault PLM solutions, <http://www.3ds.com/products-solutions/plm-solutions/>. Cited 11 June 2007.

[32] eASEE Product Lifecycle Management, <http://www.vector-consult-ing.de/vc_easee_en.html>. Cited 11 June 2007.


eﬀectively utilizing project, product and process knowledge · utilizing project, product and...

Documents