the journal of defense software engineering -...

The Journal of Defense Software Engineering

Sponsored by theEmbedded Computer

Resources SupportImprovement Program

(ESIP)

November 1999Volume 12 Number 11

Published by the Software Technology Support Center

Published by the Software Technology Support Center

BackgroundThe organization is a systems integratorof an air defense missile system. Morethan 120 systems and software engineersare involved in the system’s developmentand maintenance.

The organization had been ISO9001 certified since 1993. In 1997 theorganization had been certified asCMM® [1] Level 2 by independentassessors certified by the SoftwareEngineering Institute. In addition to sat-isfying Level 2 goals, the organizationmet eight of the 17 Level 3 goals.

It was decided in 1995 that a formalsystems engineering process had to bedeveloped and implemented in order toseamlessly integrate disciplines associatedwith systems engineering. For an in-depth description of the process and itsapplication in the organization, the readeris referred to other papers that have beenpublished [2,3].

The organization thought that it alsowould benefit from a standardized projectmanagement process. In 1996 a workinggroup selected A Guide to the ProjectManagement Body of Knowledge©, devel-oped by the Project ManagementInstitute [4], as the framework for theorganizational process.

The Management of ChangeSince the management of change is akey element of a successful processimprovement program, a series of mech-anisms were put in place in order tofacilitate the development, implementa-tion, and adoption of processes, meth-ods, and tools.

Organizational ProcessCoordinationIn early 1997, the thought was thatimplementing these processes would needorganizational coordination and direc-tion. A steering committee, the ProcessAction and Coordination Team (PACT),was established. The PACT is made up ofvice presidents, the manager responsiblefor quality assurance, and the coordinatorfor process performance improvement.The functions of the PACT are to:

• establish time-to-market, quality, costs, and product performance objectives to be supported by organi-zational processes

• set priorities in accordance with company vision and yearly objectives

• work as a liaison with executive committee

• establish consensus among different groups

• provide support for process perform-ance improvement:- Review results of assessments and audits- Charter technical area working groups- Budget for resources for process groups-Monitor process performance

Process OwnershipA process owner is responsible for theprocesses’ effectiveness and efficiency,methods, and tools. As an example, eachyear the process owner develops a processimprovement plan (PIP). Process ownershave also been delegated to review the tai-loring of the process before a project isapproved. Knowing that a project manag-

er and a process owner may have conflict-ing views about the tailoring of a process,a policy was written to handle such con-flicts. In the event of a deadlock betweena project manager and the process owner,both would present a risk analysis to avice-president for the final approval ofthe tailored process.

Awareness ActivitiesTo build the sponsorship level, the presi-dent of the organization attended anexecutive seminar on process improve-ment and two directors attended a three-day seminar discussing process, processassessment, and improvement. The coor-dinator for process improvement attend-ed process improvement courses and con-ferences. There were briefing sessions andarticles in each company’s newsletter toexplain the why, what, and how ofprocess assessment and improvement anddescribing the progress made.

Meeting GuidelinesIn order to facilitate the conduct of work-ing group activities, the facilitators pro-posed a certain number of meeting guide-lines to the members of working groupsduring their group’s kick-off meeting [5](Table 1). The facilitator read each pro-posed rule and asked participants if theyagreed with the rule. Once the discussionended, the facilitator reminded the par-ticipants that in the future, he wouldfacilitate each meeting using the set ofrules selected. After a few meetings, thefacilitator invited participants to become

8 CROSSTALK The Journal of Defense Software Engineering November 1999

Addressing People Issues when Developing and Implementing Engineering Processes

Claude Y. LaporteYortar Technologies

Sylvie TrudelOerlikon Aerospace

This paper describes the approach used by a defense contractor to address the people issues raisedwhen developing and implementing engineering processes. First, a brief description of the contextis presented, then organizational mechanisms to better manage changes are described, and finally16 lessons learned are presented.

The Capability Maturity Model and CMM areregistered in the U.S. Patent and TrademarkOffice.

secondary facilitators, (i.e. when a partici-pant observed a behavior which violatedone of the meeting guidelines, he raisedthe issue with the offender). Eventually, agroup can manage the “soft issues” with-out an outside facilitator. During meet-ings, a process owner focused on the con-tent of a specific process while the facili-tator focused on the process of develop-ing a specific engineering process.

Decision MakingIt was also decided that consensus deci-sion-making was the preferred option.We defined consensus, according to thedefinition found in The Team Handbook[5]: consensus is not unanimity, consen-sus is based on the assumption that solu-tions are more likely to succeed if all ofthe key participants are “comfortableenough” with the outcome to move for-ward. From time to time “thumb voting”procedures [6] were used to make deci-sion by consensus. This allows the follow-ing three alternatives: if the proposition isfavored, the thumb is up; if someone canlive with the decision, the thumb is to theside; and if someone cannot live with thedecision, the thumb is down. In the latercase, the members of the working grouphad to take time to understand the issuesat stake and proposed an alternative thateveryone could live with.

Team EvaluationFrom time to time, members of the

working groups had to evaluate theirgroup’s effectiveness. A survey [7] wasdistributed at the end of a meeting.Individually, members completed the sur-vey and sent it to their group facilitator.The survey addresses the following issues:goals and objectives, utilization ofresources, trust and conflict resolution,leadership, control and procedures, inter-personal communications, problem solv-ing, experimentation, and creativity.Issues that members brought up were dis-cussed to generate suggestions forimprovement.

Team CharterEach working group was managed like aproject: it had a charter. The charter list-ed a budget, objectives, key players, rolesand responsibilities, deliverables, riskissues, and expected schedule.

Lessons LearnedCertain lessons likely to be used by otherorganizations in the future are discussedbelow.

Lesson 1: Set RealisticExpectations for SeniorManagementAppropriate expectations must be setprior to embarking on process develop-ment. The trap, especially for a lowmaturity level organization, consists ofcommunicating to management the ideathat a process improvement initiative will

be easy, fast, and inexpensive, has to beavoided at all costs.

A typical scenario looks like this: sen-ior management hears about the benefitsthat attaining a maturity level could rep-resent for the organization’s competitive-ness. A project manager or an externalconsultant states, in order not to upsetsenior management, that such objectivesare easily attainable. Senior managementmandates middle managers to attain thisobjective in a short amount of time. If aformal process assessment is performed, astring of countless findings are surfacedto senior management. These are findingsthat developers had known about for along time but which middle managersignored due to the management mode ofdealing continuously with the problemscreated (i.e. fighting fires). Then, seniormanagement that had publiclyannounced its objectives suddenly realizesthat it will take a lot more time andresources than initially estimated.

Three reactions are possible. Seniormanagement may accept the findings andconfirm that it will continue to supportthe objectives announced. Or seniormanagement may announce discreetlythat objectives will be lowered. Finally, itcannot accept the assessment findingsand not put in place an action plan tocorrect the deficiencies highlighted by theassessment. This decision could have adestructive effect on the morale of thedevelopers, since they know that the defi-ciencies they had been long deplored willcontinue to be ignored.

The lesson is to prepare a short actionplan — some sort of a brief appraisal ofthe situation — preferably by someonewho is not involved in the targeted sector.Estimate the time and resources necessaryto perform a formal assessment, prepareand implement an action plan. It is betternot to proceed to an assessment if it isnot intended to deal with the findings.Once the problems are identified andpublicized within the organization, if themanagement decides not to act, it sends avery bad message to practitioners.

Lesson 2: Secure Management SupportA second lesson for low maturity levelorganizations consists in realizing that

November 1999 CROSSTALK The Journal of Defense Software Engineering 9

• One conversation at a time.• In the meeting or out, but not both (i.e. participants should make a

commitment to participate in the meeting for the full duration).• 100-mile rule (i.e. no interruptions; telephone messages are not

allowed unless urgent)• How decision will be made (e.g. by consensus, majority or minority

rule, autocracy, or unanimity).• Once a decision is made, participants support it inside and outside the

meeting.• Be as open as possible.• Listen, with respect, to others and do not interrupt.• Silence is consent.• Few recreational stories.• Differences are respected.• Avoid blaming individuals.• Come prepared to meetings.• Publish minutes and action items at each meeting.

Table 1. Proposed meeting guidelines.



most of the assessment findings target thedeficiencies of management processes. Itis necessary to create an environmentwhere the organization is ready to investin implementing processes rather thanblame its managers; in other words wherethe management is ready to fix theprocess, not the people. This is one of thereasons it is necessary to keep seniormanagement informed so it can showunderstanding and full commitmentwhen these findings are publicized withinthe organization.

Beside senior management buy-in, itis essential that middle management andfirst-line managers become strong sup-porters of the process improvement pro-gram. The strongest signal managers sendis their day-to-day activities, because whata manager does talks louder than what amanager says. The developers mustreceive clear signals that the changesannounced will be implemented and newpractices will be enforced.

Lesson 3: Identify ManagementNeeds, Expectations, andUnderstanding of the ProblemThe involvement of process owners ormanagers is largely related to their under-standing of the situation i.e. strengthsand weaknesses of management andprocess. Once convinced that the currentsituation is undesirable, they will providethe leadership, direction, and momentumto implement solutions. They can alsokeep working groups focused on solvingthe right problems since it is very easy,after a few meetings, for a working groupto start solving what it perceives to be theproblems.

Lesson 4: Establish a ProcessImprovement Working Groupbefore an AssessmentIt is best if a small process group becomesactive in process activities several monthsbefore the on-site assessment. The processgroup should take this time to familiarizeitself with the models, such as theCapability Maturity Model (CMM) orthe Electronics Industries Association(EIA)731 [8] and associated processimprovement methods and tools. Ideallythere should be one full-time person inthe process group, while the other mem-

bers could be assigned on a part-timebasis. Beyond their technical competen-cies, the members of the process groupshould be selected based on their enthusi-asm for improvement and the respectthey have within the organization.

Lesson 5: Start ImprovementActivities soon after an AssessmentWith regard to the development of theaction plan, the organization shouldcapitalize on the momentum gained dur-ing the assessment period. The organiza-tion does not have to wait for a com-pleted action plan to begin processimprovement activities. The implemen-tation of certain improvements is animportant motivation factor for allmembers of the organization.

Lesson 6: Collect Data to Document ImprovementsBefore and during the assessment, it isrecommended that quantitative and qual-itative data be collected. It will be usedlater to measure progress. One couldobtain project data such as budgets andschedules, or measure the degree of cus-tomer satisfaction regarding productquality level. Since senior managementwill have made investments, it is impor-tant to be able to demonstrate that theseinvestments have been profitable.

Lesson 7: Train all Users of theProcesses, Methods, and ToolsOnce processes are defined, it is essentialto train all users. Otherwise, process doc-uments will end up collecting dust onshelves. It is illusory to think that inaddition to their workload, developerswill study new processes by themselves.Training sessions also serve as a messagethat the organization is moving aheadand will require that its developers usethese practices. During the training ses-sions, it is necessary to indicate thaterrors are bound to occur while usingnew practices. This will help reducedevelopers’ level of stress when usingthese new practices. It would be wise if aresource person (i.e. a hotline) is availableto help developers when they face obsta-cles while implementing new practices.

Lesson 8: Manage the HumanDimension of the ProcessImprovement EffortThe authors wish to make the readeraware of the importance of the humandimension in a process improvement pro-gram. The people responsible for thesechanges are often extremely talented engi-neering practitioners, however, not toowell equipped in change managementskills. The reason for this is simple: theiracademic training focused on the techni-cal dimension and not on the humanaspect. However, the major difficulty ofan improvement program is precisely thehuman dimension.

While preparing the technical part ofthe improvement action plan, the changemanagement elements have to beplanned. This implies, among otherthings: (1) a knowledge of the organiza-tion’s history with regards to any similarefforts, successful or not; (2) the compa-ny’s culture; (3) the motivation factors;(4) the degree of emergency perceivedand communicated by (a) the manage-ment, (b) the organization’s vision, and(c) the management’s real support. Theauthors are convinced that the success orfailure of an improvement program hasmore to do with managing the humanaspect than managing the technicalaspect.

Lesson 9: Process Improvement Requires Additional People Skills In an organization that truly wants tomake substantial gains in productivityand quality, a cultural shift will have tobe managed. This requires a special set ofpeople skills. The profile of the idealprocess facilitator is someone with amajor in social work and a minor in engi-neering. The implementation of processesimplies that both management andemployees will have to change theirbehavior.

With the implementation of process-es, management will need to change froma “command and control” mode to amore “hands-on” or participatory mode.As an example, if the organization trulywants to improve its processes, a primesource of ideas should come from thosewho are working, on a daily basis, withthe processes. This implies that manage-

Technology Change Management

ment will need to encourage and listen tonew ideas. This also implies that the deci-sion-making process may have to changefrom the autocratic style, e.g. “do whatyou are told” to a participatory style, e.g.“let us talk about this idea.” Such achange requires support and coachingfrom someone outside the functionalauthority of the manager who has tochange his/her behavior. Similarly,employees’ behavior should change frombeing the technical heroes who can solveany problem, to team members that cancollaborate and listen to others’ ideas.

During the first few months of theintroduction of a new process, a newpractice, or a new tool, management andemployees must acknowledge that mis-takes will be made. Unless a clear signalhas been sent by management and a“safety net” has been deployed to recog-nize this situation, employees may hidetheir mistakes. The result is that not onlythe organization will not learn from thosemistakes but other employees will makethe same mistakes. As an example, themain objective of a formal inspectionprocess is to detect and correct errors assoon as possible in the project life cycle.Management has to accept that in orderto increase the error’s detection rate,results from individual inspections willnot be made public, only compositeresults from many inspections (e.g. atleast 10 inspections from different proj-ects) will be made public. When manage-ment accepts this rule, employees shouldfeel safe to identify mistakes in front oftheir peers instead of hiding them. Theadded benefit to correcting errors is thatthose who participate in an inspectionwill learn how to avoid these errors intheir own work.

Facilitating behavior changes requiresskills that are not taught in technicalcourses. It is highly recommended thatthe people responsible for facilitatingchange be given appropriate training. Theauthors recommend two books that mayfacilitate the management of change: thefirst one [9] gives advice to anybody act-ing as an internal consultant; the secondone [10] gives the steps for developingand implementing a change managementplan.

Lesson 10: Select Pilot Projects CarefullyIt also is important to carefully selectpilot projects and participants to thepilots, since these projects will fosteradoption of new practices throughout theorganization. As stated before, first-timeusers of a new process will make mis-takes. If participants sense that mistakeswill be used to learn and make improve-ments to the process instead of pointingfingers, the level of anxiety will bereduced and they will bring forward sug-gestions instead of hiding mistakes.

Managing the human dimension ofthe process engineering initiative is thecomponent which not only fosters theadoption of change but also creates anenvironment where changes could beintroduced at an increasingly greater rate.Members of the engineering organizationnow realize that managing the “softstuff ” is as important as managing the“hard stuff.”

Lesson 11: Conduct Process AuditsProcess audits should be conducted on aregular basis for two main reasons: first,to ensure that practitioners are using theprocess, and second, to discover errors,omissions, or misunderstandings in theprocess application. Process audits help toassess the practitioners’ degree of utiliza-tion and understanding. As an example, adocumentation management process wasdistributed and practitioners were askedto produce and update documents usingthis new process. It is widely known thatengineers are usually not prone to docu-menting their work.

An audit was launched to measureprocess compliance. As expected, results

of the first audit were not exhilarating.The engineering manager kindly remind-ed engineers, in writing, to use theprocess. He also informed them that asecond audit would be performed in thefuture. The results of the second audit aresubstantially better than the first audit(Table 2). The auditor gathered feedbackand suggestions from engineers; thisinformation would be used by the processowner to improve the process.

Lesson 12: Conduct TeamEffectiveness SurveysUsually people are not very likely to raise“soft” issues. Such tools [7] may promoteopen discussion with members of a groupin order to improve its performance andprovide the facilitators with informationthat helps them probe delicate issues. Asan example, if the majority of a groupreports that interpersonal communica-tions are weak, the facilitator can probethe members and invite them to proposesolutions. After a few meetings, theresults of a new survey will show if thesolutions really helped the team improvetheir communications.

Lesson 13: Start a ProcessInitiative from the Top- Level ProcessThe process improvement initiative was abottom-up exercise (i.e. first softwareprocess was developed, then systems engi-neering). Historically, this was the select-ed strategy because, in 1992, only thesoftware CMM was available; then camethe systems engineering CMM and afterthat, the Project Management Body ofKnowledge. If an organization had tostart a process initiative today, it wouldsimplify process integration to start from


Activity Results from FirstAudit

Results fromSecond Audit

Comments made by reviewers 38 % 78%Approval matrix completed 24% 67%Effort log completed 18% 33%Review checklist completed 5% 44%Configuration managementchecklist completed

5% 27%

Distribution list completed 38% 39%Document formally approved 100% 100%

Table 2. Results of audits performed on the documentation management process.



the top by developing the project man-agement process, then the systems engi-neering process, and finally the softwareprocess. It would also be possible todevelop engineering processes in parallelonce the requirements for the top levelprocess are well stabilized.

Lesson 14: Get Support from Change ExpertsAs mentioned above, surveys were con-ducted in order to “measure” issues suchas culture, implementation history, andteam effectiveness. Once the surveys werecompiled, we had some indications oforganizational strengths and weaknesses.The difficult part was to decide what todo next. As an example, one issue on thesurvey was risk taking (i.e. people resenttaking risks). One possible cause for suchbehavior could be that people did notwant to be blamed for an error. Next wewould have to find the cause for thisbehavior, and so on. It would have beenvery helpful to have access to someonewith expertise in organizational change.This would have saved a lot of long dis-cussions and many wrong answers.

Lesson 15: Tie ProcessImprovement Activities to Business ObjectivesIt was observed that software and systemsengineering process improvement reallypicked up momentum when a commonfocal point was created among manage-ment, engineers, and customers.Understanding that process improve-ment’s real benefit lies in improvingproduct quality and reducing time-to-market and cost, leads to improving theorganization’s ability to better compete.Additionally, a multi-year PIP was a veryimportant tool to illustrate the linksbetween business objectives, projectrequirements, and process developmentor improvement. Essentially the PIPillustrated that the engineering ofprocesses was not a paper exercise but animportant infrastructure for the success-ful accomplishment of projects. Being amulti-year plan, the PIP also showed topractitioners the long-term commitmentof management to process improvementactivities.

Lesson 16. Adopt a Common VocabularyTo succeed in any project endeavor, acommon vocabulary is a basic require-ment. As we developed the processes, werealized that different players had differ-ent meaning for the same word, or thesame word had different meanings, andsome words were not well known to someindividuals. We mandated one teammember as the “glossary keeper.” His rolewas to collect a vocabulary, propose someclean-up in the terminology, and to grad-ually build a common glossary for allprocesses.

Conclusion

We have shown that the developmentand deployment of engineering and man-agement processes entail technical andmanagement competencies. Five elementsare necessary for a successful implementa-tion of organizational changes:

• Management sets a direction and process objectives are linked to busi-ness objectives. Without a clear direction, confusion may mislead people from reaching the desired change.

• People are trained to perform new tasks. Without the proper training, anxiety among the organization’s staffis likely to slow down the occurrenceof change.

• Incentives are provided to facilitate the adoption of changes.

• Resources are estimated andprovided. Otherwise, frustration mayput an end to the organization’s willingness to change.

• An action plan is developed and implemented to avoid false starts.

These years of process improvementactivities have demonstrated that constantattention to the people issues is critical tothe success of technological changes. Wesuggest to manage those people issues asrisk items and to track them throughoutthe improvement effort.

Finally, as stated by J. Pfeffer in hisbook The Human Equation, “It is almostimpossible to earn above-normal, excep-tional economic returns by doing whateveryone else is doing ... it is also impos-sible to achieve some lasting competitive

advantage simply by making purchases inthe open market — something that any-one can do” [11]. ◆

About the AuthorsClaude Y. Laporteobtained a bachelor ofscience degree in 1973from le Collège MilitaireRoyal de Saint-Jean. In1980, he obtained amaster of science degree

in physics at Université de Montréal, and in1986, a master’s degree in applied sciencesfrom the Department of Electrical andComputer Engineering at ÉcolePolytechnique de Montréal. He was an offi-cer in the Canadian Armed Forces for 25years and a professor for more than 10years. From 1988-92, he was involved inthe implementation of the AppliedSoftware Engineering Center. He left theCanadian Forces in 1992 at the rank ofmajor. He joined Oerlikon Aerospace,where he coordinated the development andimplementation of software engineering,systems engineering, and projects manage-ment processes, methods, and tools. In1999 he left Oerlikon Aerospace to launchconsultation services as a partner of YortarTechnologies. He is the president of theMontréal Software Process ImprovementNetwork.

Yortar Technologies481 BissettSaint-Jean-sur-RichelieuQuébec, Canada J3A 1W6Voice: 450-349-4088Fax: 450-349-4620E-mail: [email protected]

Sylvie Trudel obtained abachelor’s degree incomputer science in1986 from LavalUniversity in Québec.She worked for morethan 10 years in devel-

opment and implementation of manage-ment information systems. She joinedOerlikon Aerospace in 1996 as the processcontrol analyst for the software engineeringdepartment. She is a full-time member ofthe organization’s Process Action andCoordination Team. She played a majorrole in the introduction of formal inspec-tions. She was a team member and sitecoordinator of the formal software engi-

Technology Change Management


neering process assessment.

Oerlikon Aerospace225 Seminaire sudSaint-Jean-sur-RichelieuQuébec, Canada J3B 8E9

E-mail: [email protected]

References1. Paulk, M. et al, Capability Maturity

Model for Software, Software Engineering Institute, SEI/CMU-93-TR-24, 1993.

2. Laporte, C., Papiccio, N., “Development and Integration of Engineering Processes at Oerlikon Aerospace,” Proceedings of the Seventh International Symposium of the International Council on Systems

Engineering, August 3-7, Los Angeles, Calif., 1997.

3. Laporte, C., A. Guay, J. Tousignant, “The Application of a Systems Engineering Process to the Re-Engineering of an Air Defense System,” Proceedings of the 8th International Symposium of the International Council on Systems Engineering, July 26-30, Vancouver, Canada, 1998.

4. A Guide to the Project Management Body of Knowledge, Project Management Institute, 1996.

5. Scholtes, P., The Team Handbook, Joiner Associates Inc, 1996.

6. Popick, P.R., S.A. Shear, “Ten Lessons Learned from Implementing Integrated Product Teams,” Proceedings, International Council

on Systems Engineering 6th Annual International Symposium, Boston, July 7-11, 1996.

7. Alexander, M., The Encyclopedia of Team-Development Activities, edited by J. William Pfeiffer, University Associates, San Diego, Calif., 1991.

8. EIA 731, Electronic Industry Association, Systems Engineering Capability, EIA Standard EIA/IS 731 Part 1: Model, 1998.

9. Block, P., Flawless Consulting, Pfeiffer & Co., 1981.

10. Bridges, W., Managing Transitions, Addison Wesley, 1991.

11. Pfeffer, J., The Human Equation: Building Profits by Putting People First, Harvard Business School Press, 1998.

Addressing the People Issues when Developing and Implementing Engineering Processes

the journal of defense software engineering -...

Documents