Download pdf - Introducing an Iterative Life-Cycle Model at Credit Suisse IT Switzerland

68 IEEE SoftwarE | publIShEd by thE IEEE computEr SocIEt y 074 0 -74 5 9 /13 / $ 31. 0 0 © 2 013 I E E E

From 2005 to 2010, the IT divi-sion of Credit Suisse Switzerland im-plemented a CMMI initiative, which ended successfully with a maturity level 3 (ML3) appraisal. The initiative supported the company’s Application Development (AD) departments in the Swiss region, which in turn supported

approximately 3,500 IT staff working on about 400 projects. The initiative included a requirement for an alter-native to the company’s long-stand-ing waterfall life-cycle management (WLCM) of software development. The organizational unit responsible for defining and standardizing Credit

Suisse’s processes and tools chose to meet this requirement by introducing an iterative life-cycle model (ILCM) based on IBM’s Rational Unified Proj-ect (RUP).1 Because RUP knowledge wasn’t widely available at Credit Su-isse, the company hired external con-sultants to support the ILCM develop-ment and deployment.

We participated in various aspects of the RUP Adoption Project (RAP) to introduce ILCM at Credit Suisse. Here, we report our experience, iden-tifying success factors, good practices, and lessons learned on that project.

Pre-Deployment: ILCm DefinitionThe organizational unit that drove RAP was separate from the AD de-partments that would apply ILCM to software development. The sepa-ration of process definition and pro-cess application had an impact on the project setup and communication. The AD departments represented key stakeholders. They contributed ex-pert teams to the project, which were responsible for defining, standardiz-ing, and supporting the application of specific engineering disciplines. Team members consisted of AD de-partment discipline experts led by an AD department line manager.

The pre-deployment phase included key decisions and practices that estab-lished the structure for the project’s success.

Standardization versus Alignment to Credit SuisseA gap analysis showed that RUP didn’t fulfill all CMMI ML3 practices. For example, there are gaps in the follow-ing process areas: decision, analysis, and resolution (DAR), integrated proj-ect management (IPM), organizational process definition (OPD), and organi-zational process focus (OPF). To fill

Introducing an Iterative Life-Cycle Model at Credit Suisse IT SwitzerlandKatharina Sägesser, Credit Suisse

Bonney Joseph, Wipro Technologies

Rainer Grau, Zühlke

// A large organization’s decision to supplement its

well-established waterfall life-cycle model for software

development with an iterative model required a

carefully coordinated change management project. //

Feature: Software Development management

march/aprIl 2013 | IEEE SoftwarE 69

the gaps, the RAP team extended RUP to the missing process areas.

In all process areas, the team faced a trade-off between adopting stan-dard RUP concepts or aligning ILCM with existing artifacts and WLCM definitions that were well known and understood. In one of the more far-reaching decisions during the proj-ect’s inception phase, the team chose to follow the RUP concepts closely, making only minor adaptations and additions. Several criteria influenced this decision:

• Available resources. RUP was es-tablished in 1998 and is a de facto industry-standard process, so the market can provide skilled prac-titioners, best practices, training, and background literature for in-corporating external knowledge, consulting, and training resources into ILCM. New hires who are al-ready familiar with RUP are easier to absorb into Credit Suisse AD departments.

• Mindset shift and cultural change. Introducing a new process model affects company culture and poses fundamental challenges. Apply-ing the standard RUP terminology helps change the corporate mindset to ILCM and prevent AD depart-ments from falling back into ac-customed habits. RAP adopted the original RUP terminology without change.

• Development and maintenancecosts. Every deviation from stan-dard RUP increases ILCM mainte-nance costs, so keeping their num-ber to a minimum is a priority. It also makes it easier to benefit from new RUP releases.

The project adapted very few elements of the standard RUP framework. In-stead, it mapped between RUP and

WLCM process elements, such as role and artifact template names, and closed the gaps in CMMI ML3 practices (DAR, IPM, OPD, and OPF) by reusing existing WLCM process elements that didn’t corrupt the iterative, incremental RUP concepts.

Keeping as close as possible to the standard RUP framework proved to be a key success factor in the ILCM defini-tion, rollout, and maintenance.

Collaboration within a Large OrganizationDefining an additional life-cycle model within a large organization involves communication with many stakeholders. Direct stakeholders in-clude the process managers and pro-cess engineers, the process expert teams, and the quality assurance team. In our experience, these stake-holders are clearly visible.

Less visible and accessible but equally important stakeholders at Credit Suisse were the project manag-ers and process quality managers in the AD departments. Because these stakeholders are responsible for car-rying out and disseminating the new process within the ADs, their active support is essential for successful de-ployment and rollout.

To involve all relevant stakeholders, RAP established specific activities to foster commitment and collaboration:

• Reviewsessions. Expert team mem-bers attended reviews very early in the process definition.

• Stakeholder-oriented workshopsand training. Stakeholder groups

not directly involved in pilot proj-ects, such as AD department line and quality managers, received spe-cial training.

• Pilot projects and coaching. Early pilot projects in the AD depart-ments received intensive support from the RUP consultants to in-volve them in not only generating feedback for the ILCM process definition but also supporting the change generally.

Coaching as Feedback and Dissemination TechniqueCoaching of pilot projects proved to be the most important of these activi-ties for several reasons. It established a communication channel between the ILCM definition and AD departments, facilitating increased awareness and motivation in the AD departments as well as feedback to the project about defects and enhancements to the ILCM definition. It also helped disseminate ILCM knowledge before the rollout.

The budget for external coaching and AD department pilot projects was limited. Additionally, the company lacked an overall coaching concept for disseminating new software engineer-ing methods throughout the organi-zation. These restrictions had a nega-tive impact on knowledge transfer to AD departments, and to address the

lessons learned, we later developed a proposal for a coaching concept and submitted it to a Credit Suisse working group responsible for organizational development concepts.

Keeping as close as possible to the standard RUP framework proved

to be a key success factor.

70 IEEE SoftwarE | www.computEr.org/SoftwarE


Retrospective of the ILCM Definition ProcessMinimizing ILCM deviations from the standard RUP product and initiating early, intensively coached pilot projects to identify absolutely necessary devia-tions were the main decisions leading

to RAP’s success in defining an ILCM process for Credit Suisse. Two other de-cisions worked well and had a positive impact on the project:

• An external review by PhilippeKruchten, one of RUP’s develop-ersatIBM. His review highlighted the need to address organizational awareness and identify resistances.

• The application of ILCM to RAPitself. Starting with standard RUP in the first pilot projects, RAP pro-ceeded iteratively. Each iteration generated an improved ILCM ver-sion based on direct feedback that ensured dissemination to and sup-port of the AD departments.

There were also negative impacts. For example, developing the ILCM definition outside the AD departments led to a perception of it as a “processes and tools definition” that was disen-gaged from day-to-day project busi-ness. Additionally, as noted, limited coaching resources and a missing or-ganizational coaching concept for pro-cess improvements hindered the dis-semination of ILCM knowledge.

organizational DeploymentOrganizational-level change is often seen as an impediment to current ac-

tivities, and the ILCM deployment represented a fundamental process change in a large organization with complex structures and many rel-evant stakeholders. The RAP rollout team used several strategies to ensure success, which required convincing

project and line managers that, in the long run, the positive effects of ILCM would exceed the effort required to learn how to apply it.

Creating Awareness and MarketingTools for creating awareness included workshops, information sessions, and short training modules for project and line managers. The RAP team also de-veloped marketing materials, such as posters, presentations, and flyers, and improved ILCM and RAP project vis-ibility at Credit Suisse internal events.

We also obtained good results from face-to-face meetings with important opinion leaders and by communicat-ing success stories at internal events, especially stories from business project managers in their role as internal cus-tomers of the IT departments.

Knowledge ManagementRAP addressed knowledge manage-ment by integrating the ILCM defini-tion in the Credit Suisse intranet and establishing an issue-tracking system accessible to all employees. The issue-tracking system published standard so-lutions for issues, making them visible to the entire community.

Workshops and training modules developed for specific target groups incorporated lessons learned from the

initial pilot projects. Pilot project teams had to attend a minimum set of target-group training sessions prior to the project’s start.

We also established regular RUP gatherings where stakeholders could discuss issues openly. These gatherings reported successes, including stories from business project leads, as well as ILCM defects, which were visible in the issue-tracking system.

Managing ResistanceWe identified three major factors con-tributing to resistance toward the ILCM deployment in the AD departments.

Limited budget. First, budget constraints limited the availability of coaching re-sources, so many pilot projects didn’t get the support required to apply the ILCM methodology correctly. Conse-quently, projects applied the process in-correctly, which led to additional effort later and, in turn, diminished motiva-tion and further resistance.

For example, WLCM works out de-tailed requirements specification during the design phase, whereas ILCM works out the specification on a course-grain level through the end of the elabora-tion phase and develops details in sub-sequent steps during the construction iterations. In one specific project, the coach explicitly addressed this changed procedure with the project team at the beginning of the elaboration phase. However, budget constraints that lim-ited coaching in the requirements engi-neering discipline hindered the correct application of the change. A review session after a set of construction it-erations subsequently proved that the requirements were specified in far too much detail during the elaboration phase, resulting in rework during the construction phase.

The team feedback: “There’s no dif-ference between WLCM and ILCM.”

The lesson learned: Requirements

Organizational-level change is often seen as an impediment

to current activities.


engineering required additional coach-ing to address these ILCM-specific issues.

High workloads. Credit Suisse assigned the “process manager” role to AD de-partment line managers. This role ap-proves the project-specific process tai-loring. Credit Suisse line managers have many responsibilities, including staff development and project manage-ment, and heavy workloads that limited the time they had to improve in the pro-cess manager role and, in turn, delayed their acquisition or increased their re-sistance to acquiring the new process knowledge. It also prevented them from informing and motivating teams to ap-ply ILCM in upcoming projects. They tended to meet their responsibility for project-specific tailoring by proposing the well-understood WLCM.

The lesson learned: Key roles in disseminating and approving a new method must have a high interest in the new method and sufficient time to successfully introduce it. Organiza-tional actions such as additions to the company’s management by objectives (MBO) can ensure that this happens. In large organizations, such actions re-quire synchronized attention from top management levels to all parts of the organization.

Rule compliance. The general percep-tion of change as a threat is exacer-bated at large organizations by the fear of violating the often significant num-ber of governmental compliance regu-lations. This threat is hard to discover and mitigate. Face-to-face meetings proved the most valuable means of ad-dressing it for RAP.

For example, the discussion between a coach and an AD department project lead revealed a misunderstanding about how the number of noncompliance is-sues related to the lead’s MBO. The misunderstanding made any changes

to proven best practices seem like a ca-reer threat, and clarifying it opened a decision-making bottleneck.

The lesson learned: Change manage-ment must discover and address per-sonal threats that individuals feel about the process. Personal threats are signifi-cantly harder to discover in large orga-nizations than in small or medium-size organizations.

Mindset Change and Tacit KnowledgeThe RAP team underestimated the re-quired mindset change for moving from a waterfall to the iterative process that ILCM prescribes.

To overcome implicit actions based on tacit knowledge, the ILCM rollout required more training, coaching, sup-port, and positive personal experience than we expected. Example discrep-ancies in mindset and tacit knowledge that showed up in the project included the following:

• Documentfreezeonmilestones. In WLCM, requirement specification are frozen in documents at corre-sponding milestones. In ILCM, re-quirements documents are updated at any time in the project. This dif-ference showed up in requirements engineers tending to overspecify at the beginning of the process and trying to avoid ongoing detailed specification in the construction phase iterations.

• Start of implementation and test-ing activities. ILCM projects start implementation and testing activi-ties earlier than WLCM projects. Two of three pilot projects failed to order the testing and implementa-tion infrastructure in time from the internal service organization, so im-plementation and testing environ-ments often weren’t in place when needed.

• Automated testing on integration,system, and user-acceptance lev-

els. WLCM projects often execute tests manually because they’re done only at the project’s end. ILCM re-quires execution of these tests as regression tests at the end of every iteration. The mindset to imple-ment integration, system, and user- acceptance tests at least partially as automated regression tests was new to many project teams.

• Interdisciplinarycollaboration. Wa-terfall processes draw the engineer-ing disciplines in sequence and base the handover between these disci-plines on documentation. In iterative processes, a team carries out the en-gineering disciplines in a collabora-tive way with shared responsibility. This workflow change involves a mindset change that was a challenge for a small fraction of the workforce, but many projects improved consid-erably in productivity and quality.

Developing clear concepts to address specific aspects of a process rollout can mitigate high-risk issues with explicit organizational dependencies. For ex-ample, two RAP pilot projects work-ing with offshore partners developed contract templates and collaboration blueprints that subsequent AD depart-ments have successfully applied to other projects.

The lesson learned: The ILCM roll-out showed that improvements require a change of accustomed and well-estab-lished habits that exist as tacit knowl-edge. On the basis of our experience at Credit Suisse, we estimate that the suc-cessful change from a waterfall to an it-erative software development approach requires between two and four years, depending on the organization’s size. We further extrapolate that managing tacit knowledge is a key success fac-tor in managing from an iterative-but-defined process model, such as RUP, to agile and empirical process models, such as Scrum.

72 IEEE SoftwarE | www.computEr.org/SoftwarE


Post-Deployment resultsThe ILCM model is now generally available as a credible alternative to WLCM at Credit Suisse. The company has integrated about 25 ILCM projects across all departments, including sev-eral large projects, totaling a budget outlay of over 60 million Swiss Francs (CHF) over the past three years. Of these, 14 projects developed new ap-plications, and 11 enhanced existing applications. ILCM is seamlessly in-tegrated into organizational environ-ments such as the process asset library, measurement systems, quality audits, process compliance assessments, proj-ect status reporting, and project re-view board. In-house ILCM training as well as IBM Rational’s standard RUP training are organized on an on-going basis to elevate the competency levels of practitioners wanting to use the ILCM process. As part of continu-ous improvement, ongoing process en-gineering aims to enhance its usability.

An IT-wide Solution Delivery Pro-cess Harmonization initiative now aims to integrate the ILCM pro-cess into an overall Solution Delivery Framework (SDF), which will eventu-ally address the needs of more than 18,000 IT professionals across all Credit Suisse IT functional areas. The ILCM and its core practices will form the bedrock of the SDF, which will also support agile and waterfall soft-ware development models

An Interim Project Satisfaction Sur-vey (IPSS) conducted for projects run-ning ILCM showed positive results with average values of about 7 on a scale of 1 to 10. ILCM projects’ average cost variance over the past three years is 6.5 percent; the average project cost per use-case point is 9.6K CHF for the past three years. However, the trend is positive with 2011 average at 2.9K CHF based on published results.

Two case studies are representative of successful ILCM applications.

ILCM Case Study 1: Java-Based Application DevelopmentIn August 2009, Credit Suisse started an ILCM project to develop a new Java application. The environment was com-plex, and earlier WLCM development projects hadn’t succeeded. The ILCM project successfully deployed the first release in July 2010. Release 2 fol-lowed in February 2011, focusing on enhanced functionality and interfac-ing to an external partner. The project team is currently working on Release 3, which will further enhance functional-ity and implement a client-facing Inter-net application.

The application’s evolutionary de-velopment and deployment within a very ambitious time frame were mainly due to ILCM. At the project’s start, the main challenge was to change every-body’s mindset from waterfall to it-erative thinking. Additionally, the ear-lier failures with the project required rebuilding faith in the project’s goals and objectives. Within the first few months, the iterative deployments con-vinced the organizational business group for which the application was be-ing developed of the project’s feasibil-ity. Early tangible results helped us gain the trust of the development team and stakeholders.

Every other week, the development team delivered software into the test environment. The business group tested the increment to ensure that functional-ities met their specifications. Using the ILCM methodology enabled a stable architecture to emerge and be verified early in the project. Testing was never-theless a challenge. In iterative software development, refactoring is a common and necessary task that increases the regression testing effort. The project addressed this challenge by making an early investment in test automation. RAP also sponsored an external coach to support the development team.

The iterative approach helped build

a strong, reliable partnership among the business group, IT, and the external supplier.

ILCM Case Study 2: Monthly IterationsAnother successful project required a one-month iteration pattern with a pro-duction release every three months. Re-quirements were unclear at the project’s start and highly volatile throughout the project. Key success factors were plan-ning and monitoring the iterations to foster the mindset shift among delivery teams to think consciously in terms of iterations and overcome the tendency to revert to thinking in terms of the water-fall model.

The customer requirements were functionally decomposed into individ-ual building blocks (vertical application slices). This helped define the project’s scope and establish the basis for itera-tion planning and communication be-tween the business group and IT in a dynamic environment.

The one-month iteration rhythm helped deal with the deployment’s vol-atile nature and ensured stability and motivation. A preliminary cost esti-mate per iteration was prepared based on use-case points.

An interdisciplinary team proved to be a success factor. Teams included no more than 10 individuals, which helped coordinate across engineering disci-plines (requirements, architecture, con-struction, and testing) and reach agree-ment on the release goals.

Cooperation with the business group was a challenge. Stakeholders from that group didn’t appreciate the project’s it-erative approach.

o rganizational change initia-tives in large, complex or-ganizations, such as Credit

Suisse’s introduction of an additional life-cycle model, require an elaborated change management project, capable of


orchestrating a mindset shift at all or-ganizational levels and throughout the practitioner community. The distrib-uted responsibilities in large organiza-tions represent one aspect of the chal-lenges unique to a large organization; the large number of individuals af-fected by proposed changes is another.

Time is an important factor. On the basis of our experience, the mind-set shift takes significantly longer in a large organization than in smaller ones—at least two years, during which active support and coaching are criti-cal. Even so, there’s always a part of the practitioner community that won’t or can’t apply the change because of a specific job profile or working situa-tion. The organization decides whether and how to support these groups with already-established processes.

Coaching support is expensive, but it’s essential to success and best imple-mented through a clearly defined or-ganizational coaching concept. On the basis of the RAP lessons-learned ses-sion, we developed a coaching concept and project proposal for implement-ing it at Credit Suisse Switzerland. The proposal addresses the dissemination and roll-out of technical and method-ological improvements to the AD de-partments. It combines content-based quality checks and derives coaching ac-tivities for all AD department job fami-lies and resource pools.

AcknowledgmentsWe thank all Credit Suisse colleagues and management for their commitment and sup-port during the introduction of the ILCM process. We also thank Credit Suisse for permission to publish this experience report about a demanding and challenging project.

references 1. I. Jacobson, G. Booch, and J. Rumbaugh, The

UnifiedSoftwareDevelopmentProcess, Ad-dison Wesley Longman, 1999.

2. R.V. Uttangi and S.A.A. Rizwan, “Fast Track to CMMI Implementation: Integrating the CMMI and RUP Process Frameworks,”

15 Oct. 2007; www.ibm.com/developerworks/rational/library/oct07/uttangi_rizwan/index.html#author2.

3. “Rational Method Composer,” 2012; http://www-01.ibm.com/software/awdtools/rmc.

4. P. Kruchten, RationalUnifiedProcess:AnIntroduction, 3rd ed., Addison Wesley Long-man, 2003.

5. S. Bergström and L. Reberg, AdoptingtheRationalUnifiedProcess:SuccesswiththeRUP, Addison Wesley Longman, 2004.

6. R. Kneuper, CMMI:ImprovingSoftwareandSystemsDevelopmentProcessesUsingCa-pabilityMaturityModelIntegration, Rocky Nook, 2008.

7. M.B. Crissis, M. Konrad, and S. Shrum, CMMIforDevelopment:GuidelinesforPro-cessIntegrationandProductImprovement, 2nd ed., Addison Wesley Longman, 2006.

8. S.K. Land and W. Walz, PracticalSupportforCMMI-SWSoftwareProjectDocumentation:UsingIEEESoftwareEngineeringStandards, John Wiley, 2005.

9. J.P. Kotter, LeadingChange, McGraw-Hill Prof., 1996.

10. J.P. Kotter, HarvardBusinessReviewOnChange:TheDefinitiveResourceforProfes-sionals, McGraw-Hill Prof., 1998.

11. C. Yali and H. Taozhen, “Conceptual Model of Tacit Knowledge Transfer within Organiza-tions,” Proc.6thInt’lConf.ProductInnova-tionManagement (ICPIM 11), IEEE, 2011, pp. 151–154.

12. M.-H. Chen and G.P. Zhang, “Tacit Knowl-edge Acquisition and Sharing in Intra-Orga-nization,” Proc.3rdInt’lSymp.KnowledgeAcquisitionandModeling (KAM 10), IEEE, 2010, pp. 167–170.

KAthArInA SägeSSer is a senior project manager and program manager at Credit Suisse, responsible for the implementation of CMMI Maturity Level 3 across Credit Suisse IT Switzerland. Sägesser received her Dipl. El.-Ing. HTL in electronics from Zurich School of Engineering, Switzerland. Contact her at [email protected].

Bonney JoSePh is a consulting partner at Wipro Technologies, based in Sydney. His research interests include the Rational Unified Process, lean and agile development methodologies and tools, and the CMMI process improvement framework. Joseph received a BTech in electrical and electronics engineering from Calicut University in India. Contact him at [email protected].

rAIner grAu is director and a partner at Zühlke. As distinguished engineer, he develops organizations with means of lean management, agile methods, product management, and change management. Grau received his master’s degree in mechanical engineering from the Institute for Technology Karlsruhe. He’s an IEEE and ACM member, vice president of the International Requirements Engineering Board, and head of division informatics in the Swiss Association for Quality. Contact him at [email protected].

ab

ou

t t

he

au

th

or

S

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.