Fall 1999 Vol 2 Issue 3

Insights into Process Modeling and Management for IPPD

Insights into Process Modeling and Management for IPPD

INSIGHT SPECIAL FEATURE

INCOSE INSIGHT Fall 1999 29

Special Feature

Abstract: In order to reducecycle time, increase customersatisfaction and lower costs,

Oerlikon Aerospace initiated a seriesof projects to define and implementengineering and management pro-cesses. The first initiative, in 1992,defined a software engineeringprocess. A second initiative wasstarted in 1995 with the objective ofdefining and implementing a systemsengineering process, and integratingthis process to the software engineer-ing process already in use. We presenta brief description of the context,then describe the systems engineer-ing process. Organizational mecha-nisms to better manage changes arealso described. Finally, lessonslearned are presented.

Process DevelopmentBackgroundOerlikon Aerospace (OA) is thesystems integrator of an air defensemissile system. More than 100 systemsand software engineers were involved

in the development and maintenanceof the system. In fall 1992, recogniz-ing that engineering was a corecompetency, the OA presidentapproved the budget for a softwarecapability assessment, as well as forthe preparation of a Process Improve-ment Plan (PIP). In spring of 1993,assessors certified by the SoftwareEngineering Institute (SEI) performeda formal software assessment. Duringa second formal assessment conduct-ed in February 1997, OA achieved astrong SEI level 2 certification, andeven satisfied eight of seventeengoals for SEI level 3 certification.

Although the organization hadbeen ISO 9001 certified since 1993,it was decided that a systems engi-neering process also had to bedeveloped in order to seamlesslyintegrate disciplines associated withsystems engineering. In 1995, a miniassessment of systems engineeringpractices was performed. After theassessment, it was decided to use, asframeworks, the Systems Engineering

Capability Maturity Model (SE-CMM)©1 and the Generic SystemsEngineering Process (GSEP)©2 deve-loped by the Software ProductivityConsortium (SPC 1995). An in-depthdescription of the systems engineeringprocess has been presented at a sym-posium of INCOSE (Laporte 1997).

Development of a SystemsEngineering ProcessThe GSEP document describes, usingthe IDEF notation (USAF 1981),management and technical activities,and the artifacts produced by eachactivity. The major managementactivities are: Understand context,analyze risk, plan increment devel-opment, track increment develop-ment and develop system. The majortechnical activities, as illustrated inFigure 1, are: Analyze needs, definerequirements, define functionalarchitecture, synthesize allocatedarchitecture, evaluate alternatives,validate and verify solution, andcontrol technical baseline. Each

Development Integration and Implementationof Engineering Processes at Oerlikon AerospaceClaude Y. Laporte, claporte@yortar.com, Sylvie Trudel, strudel@oerlikon.ca

Figure 1:TechnicalActivities of the SystemsEngineeringProcess

30 Fall 1999 INCOSE INSIGHT

Special Feature

major activity is broken down in acertain number of smaller activitiesthat are described, individually usinga modified Entry criteria-Task-Valida-tion-eXit criteria (ETVX) notation(Radice 85). This notation was alsoused to document software processand management processes such asthe project management process. Asan example, the “Analyze Risk” top-level activity is composed of fourlower level steps: Perform Risk Ana-lysis, Review Risk Analysis, Plan RiskAversion, and Commit to Strategies.One step titled Perform Risk Analysisis illustrated, using the modifiedETVX notation, in Figure 2.

Integration of the SoftwareEngineering Process to theSystems Engineering Process.We have used, as a framework tointegrate the software engineeringprocess to the systems engineeringprocess, a document produced bythe SPC entitled: Integrated Systemsand Software Engineering Process(ISSEP)©3 (SPC 1996). ISSEP definesa set of management and technicalactivities and the following interfaces:(1) interfaces between the manage-ment and technical activities, (2)interfaces among management activi-ties, (3) interfaces among technicalactivities, and (4) interfaces betweenthe systems and software or hard-ware development processes. Similar-ly to the GSEP, ISSEP is adaptableand tailorable to a range of applica-tions and project environments.

Deployment of the SystemsEngineering ProcessThe systems engineering processwas deployed for the first time forthe re-engineering of two subsystems

attended a three-day seminar discus-sing the CMM, process, processassessment and improvement. Brief-ing sessions were held and articleswere written in each company’snewsletter to explain the why, whatand how of process assessment andimprovement activities and describingthe progress made. Finally, surveyswere conducted to assess the organi-zation’s readiness to such a changein practices. The surveys identifiedstrengths of the organization andpotential barriers to the plannedimprovement program.

Also, in order to get support andcommitment for the future implemen-tation of processes, working groupswere staffed with representativesfrom many departments, includingsoftware engineering, systems engi-neering, sub-systems engineering,quality assurance, contract manage-ment, and configuration management.Each working group was managedlike a project. It had a charter, abudget and a schedule. A processowner, (i.e. a manager responsiblefor the definition, implementationand improvement of each process)was part of the working group. Amember of the working group actedas a facilitator in each group. There-fore, the process owner would focuson the content of a specific engineer-ing process while the facilitator wouldfocus on the process of developinga process.

Lessons LearnedCertain lessons that could benefitother organisations in the future arediscussed below.

Lesson 1: Tie Process ImprovementActivities to Business Objectives. It wasobserved that software and systemsengineering process improvementreally picked up momentum when acommon focal point was createdbetween management, engineers andcustomers. They understood that thereal benefit of process improvementis that it has the potential to improveproduct quality, reduce time to mar-ket, and reduce cost. Consequently,it improves the ability of an organi-zation compete. Additionally, a multi-

of the air defense system, namelythe launcher control electronics andthe operator consoles. The launchercontrol subsystem is composed of amain data processor which coordi-nates the operation of the sensors,the launch and guidance of themissiles; a missile tracker processor;a target tracker processor; and aservo control processor. The operatorconsoles consist in a radar console,which allows controlling the radarand communication subsystems, andan electro-optical console, whichallows controlling optical sensorsand missile launcher.

Both re-engineering projects weredivided into increments: a definitionphase and a detailed hardware/soft-ware development phase. The iden-tification of each increment wasbased on the nature of the deliverableproduct at the end of the increment.In both cases, the first incrementdeliverable was a system requirementspecification, and the second incre-ment deliverable was a set of designand equipment specifications, plus aqualified working pre-productionprototype. An in-depth descriptionof the re-engineering project can befound in paper presented at the 1998INCOSE Symposium (Laporte 1998).

The Management of ChangeSince the management of change isa key element of a successful processimprovement program, a series ofactions were planned in order tofacilitate the development, the imple-mentation and the adoption of theprocesses, methods and tools. As anexample, to build the sponsorshiplevel, the president attended a one-day executive seminar on processimprovement and two directors

ActivitiesIdentify potential risksEstimate loss and consequencesAnalyze risk dependenciesIdentify probability of risksIdentify risk aversion strategies

Identified risksRequirementsContextTechnical risks

Entry CriteriaContext approved bystakeholders

MeasuresEffort (staff-hours)

Exit CriteriaRisks identified

Inputs OutputsFigure 2.Example of a modifiedETVXNotation –Perform Risk Analysis

INCOSE INSIGHT Fall 1999 31

Special Feature

year Process Improvement Plan(PIP) was a very important tool toillustrate the links between businessobjectives, project requirements andprocess development or improve-ment. Essentially the PIP illustratedthat the engineering of processes wasnot a paper exercise but an impor-tant infrastructure for the successfulaccomplishment of projects. Being amulti-year plan, the PIP also showedpractitioners the long-term commit-ment of management to businessand process improvement activities.

Lesson 2: Train all Users of the Pro-cesses, Methods and Tools. Onceprocesses are defined, it is essentialto train all users. Otherwise, processdocuments will end up getting dustyon shelves. It is illusory to think thatdevelopers will study, on their owninitiative, new processes in additionto their workload. Training sessionsalso serve as a message that theorganisation is moving ahead andwill require that its developers usethese practices. During the trainingsessions, it is necessary to indicatethat, even with everybody’s good will,errors are bound to happen whileusing new practices. This messagemay help reducing developers’ levelof stress when using these new prac-tices. It would be a good thing tohave a resource person available tohelp developers (e.g. on a hot line)when they face obstacles whileimplementing new practices.

Lesson 3: Manage the Human Dimen-sion of the Process Improvement Effort.We wish to make you aware of theimportance of the human dimensionin a process improvement program.The people responsible for thesechanges are often extremely talentedengineering practitioners, who maynot be trained in change managementskills. The reason for this is simple:their academic training focused onthe technical dimension and not onthe human aspect. However, themajor difficulty of an improvementprogram is precisely the humandimension.

While preparing the technical partof the improvement action plan, the

change management elements haveto be planned. This implies, amongother things, a knowledge of (1) theorganisation’s history with regard toany similar earlier efforts, successfulor not; (2) the company’s culture;(3) the motivation factors; and (4)the degree of urgency perceived andcommunicated by management, theorganization’s vision, and genuinesupport. We are convinced that thesuccess or the failure of an improve-ment program has more to do withmanaging the human aspect thanmanaging the technical aspect.

Lesson 4: Process ImprovementRequires Additional “People Skills.”In an organisation that truly wants tomake substantial gain in productivityand quality, a cultural shift will haveto be managed. Such a cultural shiftrequires a special set of “people”skills. The profile of the ideal processfacilitator is someone with a majorin social work and a minor in engi-neering. The implementation ofprocesses implies that both manage-ment and employees will have tochange their behaviour. With theimplementation of processes, manage-ment will need to change from a“command and control” mode to amore “hands-off” or participativemode. As an example, if the organi-sation truly wants to improve itsprocesses, ideas should come fromthose who are working, on a dailybasis, with the processes. This impliesthat management will need to encour-age and listen to new ideas. Thisalso implies that the decision makingprocess may have to change from theautocratic style, e.g. “do what youare told,” to a participative style, e.g.“let us talk about this idea.” Such achange requires support and coach-ing from someone outside the func-tional authority of the managers whohave to change behavior. Similarly,employees’ behavior should changefrom being the technical “heroes”that can solve any problem, to teammembers that can generate andlisten to others’ ideas.

Facilitating behaviour changesrequires skills that are not taught intechnical courses. It is highly recom-

mended that the people responsiblefor facilitating change be given appro-priate training. The authors recom-mend two books that may facilitatethe management of change: the firstone (Block 1981) gives advice to any-body acting as internal consultant;the second one (Bridges 1991)provides the steps to be followed forwriting and implementing a changemanagement plan.

Lesson 5: Select Pilot Projects Care-fully. It is also very important toselect carefully pilot projects andparticipants to the pilots since theseprojects will foster adoption of newpractices throughout the organiza-tion. Also, first time users of a newprocess will make mistakes. It istherefore mandatory to coach proper-ly the participants and provide themwith a “safety net.” If participantssense that mistakes will be used tolearn and make improvements to theprocess instead of to “point fingers,”the level of anxiety will be reducedand they will bring forward sugges-tions instead of “hiding” mistakes.As an example, the main objectiveof a formal inspection process is todetect and correct errors as soon aspossible in the project lifecycle.Management has to accept that inorder to increase the errors detec-tion rate, they should not makepublic the results of individualinspection, but only the compositeresults of many inspections. Whenmanagement accepts this rule,employees may feel safe to identifymistakes in front of their peersinstead of hiding them. The addedbenefit to correcting errors is thatthose who participate in an inspec-tion may learn how to avoid theseerrors in their own work.

Lesson 6: Conduct Process Audits.Process audits should be conductedon a regular basis for two mainreasons: First, to verify that practi-tioners are using the process, andsecond, to discover errors, omis-sions, or misunderstandings in theapplication of the process. Processaudits help to assess the degree ofutilization and understanding by the

32 Fall 1999 INCOSE INSIGHT

Special Feature

practitioners. As an example, adocumentation management processwas released and practitioners wereasked to produce and update docu-ments using this new process. It iswidely known that engineers are notprone to documenting their work.An audit was launched to measureprocess compliance. As expected(see Table 1), results of the first auditwere not exhilarating. The engineer-ing manager kindly reminded engi-neers, in writing, to use the process.He also informed them that a secondaudit would be performed. As shownin the table, the results of the secondaudit are substantially better than thefirst audit. Also, the auditor gatheredfeedback from engineers; this infor-mation is used by the process ownerto improve the process.

Lesson 7: Conduct Team Effective-ness Surveys. Surveys (Alexander1991) may promote open discussionwith members of a group since mostpeople are not inclined to raise “soft”issues. Also, such tools provide thefacilitators with information that helpthem probe delicate issues. As anexample, if the majority of a work-ing group reports that interpersonalcommunications are weak, the faci-litator can probe the members andinvite them to propose solutions.After a few meetings, the results of a new survey will show if the pro-posed solutions really helped theteam improve performance andcommunication.

Lesson 8: Get Support from Organizational Change Experts.As mentioned above, surveys wereconducted in order to “measure”issues such as culture, implementa-tion history, and team effectiveness.Once the surveys were compiled,we had some indications of organi-zational strengths and weaknesses.The difficult part was to decide whatto do next. As an example, one issuefrom the survey is taking risks, andthat people are not willing to takerisks. One possible reason for suchbehavior was that people did notwant to be blamed for an error. Having found this cause was not toohelpful, since we would have noinfluence over the cause for thisbehavior. It would have been veryhelpful to have access to someonewith expertise in organizationalchange. This would have saved a lotof long discussions and many wronganswers.

Lesson 9: Start a Process Initiativefrom the Top Level Process. Theprocess improvement initiative wasa bottom-up exercise, i.e. first soft-ware process was developed, thensystems engineering process, thenproject management process where.Each additional process “sits” on topof the other. Historically, this wasthe selected strategy because, in1992, only the software CMM wasavailable; then, came the systemsengineering CMM and after, the Bodyof Knowledge in project manage-ment (PMI 1996). If an organization

had to start a process initiativetoday, it would be easier and moreefficient to start from the top bydeveloping the project managementprocess, then the systems engineer-ing process and finally the softwareprocess. It would also be possible todevelop these processes in parallelonce the requirements for the top-level process are stabilized.

Lesson 10: Adopt a CommonVocabulary. To succeed in anyproject endeavor, a common vocab-ulary is a basic requirement. As wedeveloped these processes, werealized that different players haddifferent meaning for the sameword, or the same word had differ-ent meanings, and some words werenot well known to some individuals.We therefore mandated one teammember as the “glossary keeper.”His role was to collect a vocabulary,propose some “clean-up” in theterminology, and to build graduallya common glossary for all processes.

ConclusionWe have shown that the develop-ment and deployment of engineeringand management processes entailtechnical and management compe-tencies. Five elements are necessaryfor successful implementation oforganizational changes. First, manage-ment sets a direction, and processobjectives are linked to businessobjectives. Second, people aretrained to perform new tasks. Third,incentives are provided to facilitatethe adoption of changes. Fourth,resources are estimated and provid-ed. Fifth, an action plan is devel-oped and implemented. We alsolearned that the constant attention tothe “people issues” is critical to thesuccess of a change project.

Improvements required significantinvestments, but both the technicaland management processes willallow complex projects to be deve-loped in a disciplined environment.

As a final word, a quotation fromPfeffer: “It is almost impossible toearn above-normal, exceptionaleconomic returns by doing whateveryone else is doing. It is also

Activity Results from Results from First Audit Second Audit

Comments made by reviewers 38 % 78%

Approval matrix completed 24% 67%

Effort log completed 18% 33%

Review checklist completed 5% 44%

Configuration management checklist completed 5% 27%

Distribution list completed 38% 39%

Document formally approved 100% 100%

Table 1. Results of audits performed on the Documentation Management Process

INCOSE INSIGHT Fall 1999 33

Special Feature

impossible to achieve some lastingcompetitive advantage simply bymaking purchases in the openmarket – something that anyone can do.” (Pfeffer 98).

Footnotes:

1 SE-CMM is a service mark of CarnegieMellon University

2 Copyright by the Software ProductivityConsortium

3 Copyright by the Software ProductivityConsortium

References

Alexander, M., The Encyclopedia of Team-Development Activities, edited by J. WilliamPfeiffer, University Associates, San Diego,California., 1991

Bate, R., “A Systems Engineering CapabilityMaturity Model,” version 1.1, Software Engi-neering Institute, CMU/SEI-95-01, November1995.

Block, P., Flawless Consulting, Pfeiffer &Company, 1981.

Bridges, W., Managing Transitions, AddisonWesley, 1991.

EIA, “Systems Engineering Capability,” EIA/IS731.1 Part 1: Model, Electronic IndustriesAlliance, 1999.

Laporte, C., Papiccio, N., Development andIntegration of Engineering Processes atOerlikon Aerospace, Proceedings of theSeventh International Symposium of theInternational Council on Systems Engineering,August 3-7, Los Angeles, California, 1997.

Laporte, C., Guay, A., Tousignant, J., TheApplication of a Systems Engineering Processto the Re-Engineering of an Air DefenseSystem, Proceedings of the 8th InternationalSymposium of the International Council onSystems Engineering, July 26-30, Vancouver,Canada, 1998.

Pfeffer, J., “The Human Equation BuildingProfits by Putting People First,” HarvardBusiness School Press, 1998.

Paulk, M. et al, “Capability Maturity Model forSoftware,” Software Engineering Institute,SEI/CMU-93-TR-24, 1993.

PMI, “A Guide to the Project ManagementBody of Knowledge,” Project ManagementInstitute, 1996.

Radice, R., “A Programming Process Archi-tecture,” IBM Systems Journal, vol. 24, no. 2,1985.

SPC, “A Tailorable Process for SystemsEngineering,” Software ProductivityConsortium, SPC-94095-CMC, January 1995.

SPC, “Integrated Systems and SoftwareEngineering Process,” Software ProductivityConsortium, SPC-96001-CMC, May 1996.

USAF, “Integrated Computer-AidedManufacturing Architecture,” FunctionModeling Manual (IDEF0), United States AirForce, AFWAL-TR-81-4023, 1981.

Biographies

Claude Y. Laporte has a Bachelor in Science,a MS in physics, a MS in Applied Sciences. Hewas an officer in the Canadian Armed Forcesfor 25 years. At Oerlikon Aerospace hecoordinated the development and implemen-tation of engineering and managementprocesses. In 1999 he started to offer consul-tating services in process engineering andchange management.

Sylvie Trudel obtained in 1986 a Bachelordegree in Computer Science. She worked 10years in development and implementation ofmanagement information systems. She joinedOerlikon Aerospace in 1996 as the processcontrol analyst.