Motivating SMEs to Software Process Improvement A retrospective

�spire-vm09-foils- 0.0� Start 1

Motivating SMEs to Software Process ImprovementA retrospective at the SPIRE-project of 1998

Gerhard ChroustInstitute of Systems Engineering and Automation,

J. Kepler University Linz, Austriaemail: [email protected]

Erwin SchoitschAustrian Research Centers GmbH - ARCTechGate Vienna, 1220 Vienna, Austria

e-mail: [email protected]

************************************************ dahinter KEIN Folientext *********Two key motives for the European Commission to support software improvement pro-

jects are to strengthen the European Software Industry and speci�cally support small andvery small companies, especially in view of the sustainability of the initiated improvements.In 1997/98 the EU-project SPIRE ("Software Process Improvement in Regions of Europe",ESPRIT Project 23873) was awarded to a consortium from �ve European Countries withthe objective to address individually very small software companies and encourage them toperform one speci�c software process improvement experiment. 10 years later this papergives a retrospective analysis of the results, their sustainability, and today's consequencesbased on a survey of Austrian participants. The paper is based on an original descriptionof the paper , the 'SPIRE Handbook' and two earlier retrospective papers and .

�spire-vm09-foils- 1.0� - 2

Section 1:

Background - SMEs and Software Business

************************************************ dahinter KEIN Folientext *********

1.1 Why do we need Quality of Software Systems?

Time-to-market and quality will be an increasingly crucial factor for the future competi-tiveness of all European industry . Given the tremendous expansion of investment in thesoftware industry in the United States and Japan there exists a real danger for Europe tofall behind . A key enabler for successful industrial production is software. For the users ofsoftware poor quality is costly, time-consuming, dangerous, and sometimes deadly: Failingcomputer systems can mean

�spire-vm09-foils- 1.1� Failing computer systems can mean 3

• loss of competitive advantages and market leadership due to a missed win-dow of opportunity in the market,

• financial loss due to cost overrun,

• loss of time and money due to the need for data restoration,

• loss of market position due to loss of customer data etc.,

• loss of income due to late or non-sent bills,

• bad image in the eyes of the customers due to erroneous, incomplete, mal-functioning interfaces (e.g. web site),

• violation of laws (data security, privacy, violation of regulations likeSarbanes-Oxley),

• critical financial disaster due to the fact that it is estimated that 25% ofcompanies will not survive (!) a catastrophic computer failure of more thanseveral hours,

• etc.

************************************************ dahinter KEIN Folientext *********This implies that software, must be produced within a severely limited time-frame, at

reasonable cost, and with su�cient quality. Yet as demands on software products increasewith respect to size, e�ciency and complexity, many software houses are still experiencingdi�culty in delivering a quality product on time and budget, with su�cient quality. Thisproblem is especially true for small software developing enterprises (SSDEs) which arethe backbone of the European software industry (cf. the distribution in Austria, ).

In this paper we discuss the environment of software development with respect tothe importance of quality (). In the importance of de�ned software processes and theirimprovement are discussed, the problems of SSDEs in and . describes the overall SPIREproject, while describes its results. takes a retrospective view at the impact of theSPIRE-project on the participants and on sustainability.

�spire-vm09-foils- 1.1�Distribution of the number of employees in the sw industry in Austria4


1.2 Why do we need a Mature, De�ned Software Process?

A key to software quality is the quality of the processes used to produce soft-ware. The quality of an industrial product with more than a minimal complexitycan only be ensured by assuring the quality of the production process . In-dustrial maturity in general demonstrates itself in the ability to abstract thedevelopment process from the specifics related to the production of any in-dividual product and following a defined, uniform development process. At areasonable level of detail such a process model consists of some 40 individu-al but interlinked software development subprocesses belonging to around sixprocess categories. (e.g. ).

A milestone in this approach was the concept of process maturity as mea-sured by a Capability Maturity Model (CMM) developed at the Software Engi-neering Institute (SEI) by W. Humphrey and his team. By evaluating the qualityof performance of the development process the CMM evaluates the capabili-ty of an organization to produce high quality software. Capability Maturity ismeasured on a scale of 1 to 5. The five levels are: ’Initial’, ’Repeatable’, De-fined’, ’Managed’, and ’Optimizing’. For each level certain Key Processes areidentified which have to be fulfilled to a certain completeness. Besides mea-suring the current maturity, the objective it also to move up the maturity levelsby successively performing more of the key processes and with a higher ca-pability, see . Typically going from level 1 to level 2 one adds, amongst others,project planning and configuration management. Going from level 2 to level 3one needs a organization-wide defined software process model etc.

Soon two EU-supported alternatives were created: Bootstrap and SPICE, later converted to the standard ISO/IEC 15504 The latter two approachesdid not just evaluate the maturity of the whole development process but di-stinguished several process areas and graded each separately thus creating acapability profile.

The message is that it is not sufficient to analyze one’s capability maturi-ty, the organization should strive to increase its level of competence in orderto improve its market position and competitiveness. Numerous arguments areavailable for undertaking Software-Process Improvement (SPI), see , . Typical-ly the American DoD demands a CMM-level of 3 to admit a bidder in softwareprojects.

1.3 Problems of Small Software Development Enterprizes (SSDEs)

Under the auspices of the ESPITI project (see ) an analysis of the needs ofsoftware developing organizations was conducted. The Austrian results (whichare largely consistent with the European results) are shown in .

�spire-vm09-foils- 1.3� Problems of very small companies 5

************************************************ dahinter KEIN Folientext *********It shows that formulating and managing requirements and the quality sy-

stems are on top of the list.Nevertheless many SSDEs do not attempt a software process improvement

(SPI) project: Some of the reasons are:

�spire-vm09-foils- 1.3� SSDE need SPI but 6

• They are not aware of the advantages of SPI.

• They believe that SPI and assessment methods are only for large compa-nies (as implied by some documentation like ).

• By necessity daily operations gain precedence of the long-term goals ofSPI, despite the fact the return on investment would be high.

• There are no adequate additional resources available (see ) to cover theinitial additional improvement effort (cost and personnel).

• There is no internal know-how or experience with process improvement.

• An external trigger is missing.


1.4 Why do SSDEs need Government Support for Software ProcessImprovement?

The analysis of technology transfer in general , shows that the return on in-vestment for a given technology follows an s-shaped curve with respect toreturn on investment (). After the initial difficult start-up phase the technologyprovides increased potential and return on investment with limited additionaleffort. At some point one reaches a saturation. Added effort brings only mi-nimal improvement. This is more noticeable in software development, since aconsiderable increase of performance in classical industries is due to impro-vement in the (mass) production - and effect which is non-existent in softwaredevelopment.

Sometime before this point one should switch to a new technology. Unfor-tunately at this point - since the new technology is not mature, at least in theenterprise where it is intended to be used - using the same effort would reduceperformance. Alternatively users need additional effort to keep the current le-vel of performance, but often cannot afford it. Government programs can helpto bridge these discrepancies and thus help switching to a new technology .Historical evidence shows that government programs are able to promote andstrengthen software industry, e. g. the ALVEY-Program (Great Britain) , FifthGeneration Project (Japan) and many more.

�spire-vm09-foils- 1.4� Government Projects 7

• ALVEY - Great Britain

• Fifth Generation Program - Japan

• ESPITI (ESSI 27700) Europe


�spire-vm09-foils- 1.4� Technology Change, E�ort and Revenue 8



Section 2:

The SPIRE Project


2.5 Creating Awareness : the ESPITI-project

Recognizing the pan-European need to improve software development tech-nology the European Commission announced ESPITI, the European SoftwareProcess Improvement Training Initiative. ESPRIT project No. 27700, covering17 countries (more than EU members at this time) with two co-coordinators,aiming at "maximizing the benefits from improvement of the software processin Europe through training" . It ran from Nov. 1994 to June 1996, The projectaimed at promoting software process know-how, training and experience ex-change, especially in view of improving the process (SPI). It and was especiallydesigned for small and medium sized companies.

Two key motives for the European Commission to initiate and subsidizesoftware improvement projects were:

�spire-vm09-foils- 2.5� Key motives for the EU 10

• to strengthen the European Software Industry and

• to specifically support small and very small companies.

—> ESPITI - 17 European Partner, Nov. 1994 to June 1996

************************************************ dahinter KEIN Folientext *********The ESPITI project was performed by a consortium from all EU countries

and achieved (SPI) its major goal: the creation of awareness for and disse-mination of information about software quality issues, especially the conceptsof software processes, software process improvement (SPI), software processstandards and assessment of software processes.

2.6 The Motivation for the SPIRE Project

�spire-vm09-foils- 2.6� The SPIRE logo 11

************************************************ dahinter KEIN Folientext *********As a follow-on the EU awarded the SPIRE project ("Software Process Im-

provement in Regions of Europe" ESPRIT Project 23873, as a much smallerproject ) to a consortium of 5 European countries: Austria, Ireland, Sweden,Italy, Northern Ireland.

While the ESPITI-Project mainly aimed at creating awareness of softwarequality and its achievement, the SPIRE-Project was geared to specific softwareprocess improvement experiments in SSDEs companies, running from March1997 to October 1998.

In order to demonstrate the practicability of quality and process improve-ment by SSDE’s some 70 SPI experiments were performed in the participa-ting countries, 19 of them were successfully performed in Austria. Each ex-periment conducted one small process improvement and had to report theresulting achievements. The reports of these experiments were disseminatedworldwide.

Several objectives were to be achieved:

�spire-vm09-foils- 2.6� Objectives of SPIRE 12

• Spreading the Message:

BUT it is difficult to access these small companies and to induce them toattend events.

• Creating acceptance for the message:BUT the message has also be believed and ’lived’ by the software industry.

• Overcoming Managerial Barriers:

BUT SSDEs must see the immediate return-on-investment for investing in-itial efforts.

• Overcoming Software Engineers’ Reservations:

BUT very often software engineers do not see the benefit for their individualwork

• Overcoming Software Engineers’ lack of time:

BUT it is difficult to convince them that the burden of the daily ’fire fighting’could be reduced.


�spire-vm09-foils- 2.6� Objectives II 13

• Tailoring software process improvement for SMEs:

BUT for very small companies, and that is the majority of the software indu-stry (see ) these methods are too costly, to complex and often an overkill.There is often not enough expertise to do this.

• Sharing of experience:

BUT many companies fear that a competitor might gain some insight (posi-tive or negative) into their operation.

• Avoiding the paperwork involved in EU-Projects:

BUT one still had to convince the companies that participation was wor-thwhile.

************************************************ dahinter KEIN Folientext *********This project intended to address individually very small software develop-

ment companies ("SSDE") in order to encourage them to start a software pro-cess improvement project focussed on one single process improvement. It was- so to speak - the proof of the pudding - checking whether the ESPITI messa-ge had fallen on fertile ground.

2.7 Organization of the SPIRE project

The setup of SPIRE was simple but very effective:

�spire-vm09-foils- 2.7� Organisation of SPIRE I 14

• 5 Partners: AT, I, IR, N-Irland, N-Irland

• from March 1997 to October 1998.

• 70 partners selected -> each "SPIRE-subproject"

• a "mentor" was paid for 10 days (total 14 mentors)

• perform a small SPI

• a report was to be delivered

• payment of approx. 14.000 e


• The project was finally scheduled to run for 18 month (from March 1997 toOctober 1998).

� ARC (Austria) Both authors of this paper were key administrators of theAustrian part of SPIRE.

� ETNOTEAM (Italy)

� IVF (Sweden)

� CSE (Republic of Ireland)

� MARI and SIF (both in Northern Ireland)

• In each partner country several SSDEs were selected to perform a SPI-experiment (a "SPIRE-subproject").

• Each subproject was intended to perform a small improvements of a part ofthe participant’s software development process.

• The projects were selected from applications made by potential SSDEs.consultant, was chosen for each participating company. The mentor was toaccompany and guide the subproject and sees to the successful completi-on.

• At the end of the subproject a report was delivered.

• Each company received (upon successful completion of the subproject) acertain amount of money, 14.000 eat most. This was intended only to coverthe additional cost and effort to perform the SPIRE-subproject, cf. .

• Additionally each participant received 10 days of free mentor support. Thementors were paid for by the SPIRE project independent of the funds theparticipating companies received (as mentioned before). At least for Austri-an standards the payment of the mentors was below industry standards.The incentive for mentors was the hope to pick up continuation projects atcommercial rates.

• A reporting structure made sure that the results were accumulated central-ly in each participating country and disseminated to the public in variousforms: reports and fact sheets (4 pages A4) in national language. The bestwere translated into other languages as well, especially into English .

• To help the participants in their efforts a book was written which presentedthe ideas of the improvement standard ISO TR 15504 as it was valid in1997/98 and gave additional helpful information and advice (see ).


Section 3:

The SPIRE Subprojects


3.8 Selection of SPIRE Subprojects

The ground rules for participation of companies were:

�spire-vm09-foils- 3.8� Selection Criteria 16

• Less than 50 persons in software development

• High management commitment

• Interesting project proposal

• Potential to continue with the improvement

• Willingness to be measured before and after the project (see )

• Existence of data which allow a pre- and post-comparison

• A reasonable distribution

************************************************ dahinter KEIN Folientext *********In total some 70 software development subprojects were selected with an

appropriate amount of mentors. In Austria 22 companies were selected and 14mentors.

3.9 Project Steps

The individual subprojects were performed in the following steps:

�spire-vm09-foils- 3.9� Project Steps 17

1. initial software process assessment (Austria - SYNQUEST)

2. Select one small SPI

3. At end - another process assessment, identify effects (if already possible)

4. Sustainable?

5. report


1. The participant performed an initial software process assessment alongthe lines of a SPICE-assessment (). In Austria the tool SYNQUEST (nowrenamed "SPICE light") was used .

2. Based on this assessment the company together with the mentor selec-ted one specific process improvement and implemented it. This processimprovement was intended to remedy a major deficiency in the company’ssoftware development process and was expected to have strong impact onbusiness.

3. Immediately at the end of the experiment another process assessment att-empted to identify the effects of the changes as far as they were noticeableat that time.

4. It was assumed that the change was sustainable for the future.

5. A report for external distribution was written and disseminated via a home-page and the Spire Handbook .

3.10 Evaluation and Assessment of Maturity via Self-Assessment

ISO/IEC 15504 describes to some extent the assessment process and theresults . For an initial approximation of the capability of especially a small com-pany this would have been too much effort. Therefore in Austria a simple PC-based self-assessment tool (SYNQUEST ) was used. Its major advantage isthat it can be done in a self-assessment mode, and can be finished in two to 3hours. It provides extensive help texts. It poses some 37 questions to the user,and for each question the value of 9 standardized attributes is asked for (e.g.’are the results recorded?’, ’are the results used further?’, etc.) (). It collects theinterpreted answers into 9 process categories: (Organization, Project Manage-ment, Quality Management, Configuration and Change Management, Measu-rement, Requirements Engineering, Design and Implementation, Testing andIntegration, Transfer, Operations and Maintenance). At the end it provided va-rious evaluation diagrams from different viewpoints, e.g. "before" and "after" asshown in . It also maps the results on the Assessment Methods BOOTSTRAP, ISO15504(SPICE), and ISO 9000.

The provider of this tool (HM&S) also provides an anonymous data basewhere a user can compare the own result with the industry averages. Thedatabase now contains several 100 assessment results.

�spire-vm09-foils- 3.10�A panel from the SYNQUEST electronic assessment tool18


�spire-vm09-foils- 3.10�A typical SYNQUEST diagram with maturity values for the process categories of ISO 1550419

************************************************ dahinter KEIN Folientext *********The set of goals of the assessment were:

�spire-vm09-foils- 3.10� Goals of the assessment 20

• Provide a realistic evaluation of the current situation

• Raise awareness about software quality deficits

• Develop a basis for a feasible improvement action plan

• Motivate the staff to improvement

• Encourage the participation of senior management and engineering staffmembers

• Reduce cost and effort of the assessment (in comparison to a fullfledgedISO 15504-assessment)



Section 4:

Results of SPIRE


4.11 Performed Subprojects

Some 70 companies from the 5 countries participated (from Austria 21 with 14mentors, 19 companies finished their subproject), contains the reports fromall subprojects. A subset of 6 reports is also included in the SPIRE Handbook. Overall the satisfaction with SPIRE-project was very good, both from partici-pants and mentors.

In discussions the participants made the following statements:

• Up to now we believed that process models are impractical for a software house of oursize

• Since two years we have postponed a planned process improvement (an integrated con-�guration management). SPIRE triggered the concrete implementation, the externalpressure was important to see the project though

• without SPIRE we would not have started

• and if started we would not have �nished.

• The promised reimbursement promised for the end of the project was a major incentiveto really follow through

• we would not have used a mentor

• we would not have known from one another

• we have the feeling that we have improved

A mentor of 3 subprojects made the following comment "I am convincedthat the participants will continue to get involved in process improvement andwill continue in improving the quality of their processes"

4.12 The SPIRE Book

One of the most conspicuous results of the SPIRE-Project was the publicationof a book , see and which was focussed on the situation and the needs of theSSDEs.

�spire-vm09-foils- 4.12� The SPIRE Book (front cover) 22


�spire-vm09-foils- 4.12� The SPIRE Book (back cover) 23

************************************************ dahinter KEIN Folientext *********It discussed the concepts of Software Process Improvement (SPI), the pro-

cess of software process improvement and gave, besides a description of theindividual processes in ISO TR 15504’s exemplar process model (as contai-ned in Part 5 of ISO/IEC TR 15504 ) also indications of industry best practices,theoretical background information, and sections on "things to do", "things toavoid", and "things to think about".

4.13 QoQ Seminars

In Austria it soon became clear, that an introductory seminar would be veryhelpful. For this purpose Gerhard Chroust and Volkmar Haase put togetherhandouts for a seminar in German which could be given (by two instructors) inhalf a day. It had the presumptuous title ’QoQ: Qualität ohne Quälerei’ (’Qualitywithout Torture’). The topics were very much ’down to the earth’, covering allaspects of running a (very) small software house. It finally consisted of 14chapters in 4 focus areas with approx. 450 foils. The German titles are shown in. The accompanying handout contained all foils, several pages of introductorytext and an appendix with literature references, and pointers to useful sourcesof information. The seminar was successfully given at least 20 times.

�spire-vm09-foils- 4.13� QOQ-Seminar, German Chapter Titles 24

Schwerpunkt I: Einleitung :

• Kap. 1: Software-Entwicklung - Notwendigkeiten von Heute

Schwerpunkt II: Qualität und Software-Prozeÿ :

• Kap. 2: Software-Qualität

• Kap. 3: Die Bedeutung des Prozesses

• Kap. 4: Prozeßqualität - technisch gesehen

• Kap. 5: Betriebswirtschaftliche Überlegungen

• Kap. 6: Der einzelne Programmierer

Schwerpunkt III: Wo drückt der Schuh? :

• Kap. 7: Was braucht Österreich?

• Kap. 8: Anforderungsananlyse

• Kap. 9: Kosten im Griff

• Kap. 10: Entwicklung ist nicht alles

• Kap. 11: Produktverbesserung

Schwerpunkt IV: Prozeÿverbesserung :

• Kap. 12: Software-Prozeßverbesserung und das Kleinunternehmen

• Kap. 13: Kleinunternehmen am Markt

Schwerpunkt V: Zusammenfassung :

• Kap. 14: Was haben wir gelernt?


4.14 SPIRE-Cz

Encouraged by the Austrian SPIRE-example the University of EconomicsPrague under Petr Doucek started also some SPIRE-experiments . The pro-ject was started with a survey of the Czech software industry based on a que-stionnaire addressing the following areas:

• General firm’s specification

• Relation to quality

• Main problem areas

• Company’s processes - related to customers

• Company’s processes - related to software development

• Company’s processes - related to project management

• Company’s processes - related to support of software development

• Company’s processes - related to organisation of software development

It contained a total of some 60 questions and brought numerous interestingresults (for example and )

As a conclusion states: With respect to the implementation of a quality system,the Czech software companies showed little interest. They cited in the lack of adequateinformation as the main reason. They also believe that an implementation of qualitysystem as rather di�cult and expensive. The Czech software companies seem to be ableto compete with the foreign companies of the same kind. They stand fair in the �eld ofdevelopment of their own software products. The Czech small and middle-sized softwarecompanies have problems very similar to the Austrian small and middle-sized softwarecompanies.

�spire-vm09-foils- 4.14�Distribution of Employees (Sw industry) in the Czech Republic25


�spire-vm09-foils- 4.14�Reasons of sw-SMEs for neglecting quality systems (Czech Republic)26


4.15 ISA-EuNET - a "Spire" for SSDEs with Safety-related Systems

Addressing the specific area of safety-related systems and software, a similarsmall initiative was accepted by the EU for SMEs, which have even more pro-blems to fulfil the additional safety requirements of functional safety standardsthan with traditional software process improvement.

To raise awareness and provide support, the Network of Excellence, ISA-Eunet ("Intensive Software Systems for Safety Application: a high-tech soft-ware European Lean Network of experts in safety applications") was started[Schoitsch, 2001], an ESPRIT ESSI project as well (No. 27450). It was coor-dinated by QLAB (Italy), partners were ARCS (Austria), ENEA (Italy), Delta(Denmark), GRS (Germany), AUEB (Greece), KEMA (Netherlands), SP (Swe-den) and CRS (UK). It was essentially "inspired" by SPIRE, taking a similarapproach in selecting SMEs to be assisted and supported in their so-calledPIEs (Process Improvement Experiments). The mentoring and on-site activi-ties were performed by the national partners themselves. A considerable partof the effort was dedicated to raising awareness and fostering dissemination.

It started Autumn 1998 and finished June 2000, with publication of "Suc-cess Stories" in May 2000. 12 success stories were published, two by partnersAustria, AUEB, GRS and QLAB each, whereas ENEA, KEMA, SP and CSRprovided one each.


Section 5:

Evaluating the Sustainability of the SPIRE Improvements


Ten years later it is interesting to see in retrospective

• how companies and mentors have fared,

• whether and how the then initiated improvements have survived,

• how the companies, resp. the mentors see their involvement in SPIRE,

• what the companies’ assessment of the performed improvement experi-ment is today,

• how they feel about their involvement and the usefulness of the improve-ment.

5.16 Survival of Austrian Participants

With respect to the Austrian participation it should be stressed that the Austri-an effort and results were considered extraordinary in the European contextby reviewers from the EU. 19 of the 20 companies finished successfully theexperiment in 1998. Of theses 20 companies only one company went out ofbusiness, 2 of the companies merged. Given the average fate of small softwarecompanies in the last 8 years, this already can be considered a success. Ad-mittedly the specific contribution of SPIRE cannot be identified, but several ofthe companies indicated in their comments (see ) that the improvement causedby SPIRE increased their competitiveness. All 14 mentors also still attendingto their business.

5.17 The 2005 Survey of Austrian Participants

To retrospectively find out about the SPIRE project a questionnaire was sent toall Austrian participants in 2005. It contained 11 questions for companies and10 questions for mentors. 9 questions were identical for both. Additionally bothgroups were encouraged to express positive and negative impressions in freeformat. Five of the 14 mentors and 6 of the 19 remaining companies answeredyielding a return rate of approximately 30%. Obviously the results cannot beconsidered statistically significant, but they show a certain trend (). A selectionof the comments is shown in .

�spire-vm09-foils- 5.17� answers to the �x-format questions 28


5.18 Further Observations on the Sustainability of SPIRE

Some indication of the successfulness of the SPIRE project are:

• In Austria the Assessment and Process Improvement Method was alsoused in other areas (supported by the Austrian Ministry of Travel, Innovationand Technology). These areas were:

� Security process improvement (SecuQuest)

� Process Improvement in Touristic Areas

� TeamExcellence: Improvement of intra-company culture and team deve-lopment

• Parts of the SPIRE Consortium continued and worked together for severalyears.

• The successful dissemination and awareness was continued at many con-ferences, workshops and training events

• The 2nd edition of the SPIRE Handbook is still used as training material inSweden, Austria (Telematik Management Course, Krems u.a.), Ireland andUK until today !!

• The case studies were translated into English, French, Spanish, German,Italian and Swedish and distributed on paper and electronically via a website.

As a typical examples the participant in SPIRE confirmed that the improvedrequirement process based on software inspections according to : the quarter-ly updates of their software product could be reduced to two updates per year,resulting in considerable savings.

�spire-vm09-foils- 5.18� Comments to the free-format questions 29

• SPIRE introduced us to quality awareness

• The chosen improvement is still valuable

• The clear structuring and processes orientation for quality assuran-ce was helpful

• SPIRE triggered the first step to SPI

• It established a local community and cooperation

• It made a positive impact on business (consultant!)

• It showed that Assessment and Self-Assessment are needed

• It still had too much overhead and administration

• The consultant was of little help

• It would be nice to have a follow-on project


5.19 Observations by the Austrian Project Coordinators

• Negotiating the actual contract with the European Commission was long-winded and cumbersome.

• It was difficult to design a fully objective and transparent selection processamong national proposals since some factors could only be estimated via’feeling’.

• Objections by the EU which from Austria were seen as trivial or irrelevant(and in many cases did not affect the Austrian contribution and partners)delayed the project start by several months, cutting short the actual projecttime

• Some of the other problems with EU-projects, raised in also appeared inthis project. It should be noted that this comments are with respect to theEU-procedures of the nineties.


Section 6:

Summary


A retrospective of SPIRE (performed 1997/98), especially the Austrian part,allows some conclusions:

�spire-vm09-foils- 6.19� Summary 31

• The size of a company is not a relevant factor in software process improve-ment

• In SSDEs a targeted specific change is possible within a few months, usual-ly faster than in large organizations.

• There is some advantage in being small.

• Software process improvement translates into sustainable business profit.

• Even one small change can have a considerable positive effect.

• The administration of the SPIRE project by a centralized partner relievedthe individual participants from much red-tape and was a key to processperformance.

• The financial support both by project-end payment and provision of mentorswas essential.

************************************************ dahinter KEIN Folientext *********Looking at the current situation we see still a need to improve the situation

with respect to the very small software developing enterprizes (SSDEs). Onehas to convince them that software improvement and even certification is nee-ded in the future. At the same time one must help those companies to adoptthe new ideas. This makes it necessary to adapt proposed methods and pro-cedures of software engineering to these small and medium companies andto disseminate this know-how as widely as possible. SPIRE was an importantvehicle to achieve aim and could be used still in the future. SPIRE proved tobe highly effective way to improve software process quality for small and verysmall software houses (SSDEs). In comparison to the results the investmentof EU-funds was rather small.

Crosby once stated: ’Quality is free’ (meaning that the return on investmentis very high and can be materialized in a short time), but we have to recognizethat despite the fact that quality might be called ’free’ we have to add that’achievement of quality is not effortless’.

There is some hope that this project will be repeated on a European levelfor the SPIRE-project.

As a final observation, it was really regretted by the SMEs and the nationalorganizations being involved as well as the national coordinators, that follow-up actions of the successful initiatives ESPITI or SPIRE (which were planned,an ESPITI-like follow up initiative was submitted as a set of proposals, butrejected) were not possible, so the sustainability and impact of the successfulinitiative was considerably affected - there could have been much more impact!

�spire-vm09-foils- 6.19� And the future? 32

• We still need SPI especially for SSDEs

• Even certification will be needed!

• The SPIRE approach could still be used (on a national level?)

• SPIRE is rather cheap with a high ROI

• "Quality is free" (high RoI)but"achievement of quality is not effortless".

THANK YOU!


Documents

Motivating SMEs to Software Process Improvement A retrospective