PASS (Pay-roll Accounting and Settlement System)

This project is carried out with the financial support of the European Union under the European Systems and Software Initiative (ESSI). EP Number 21223


Background Information
  Involved companies
   and their roles

Starting scenario

Expected business impact

Implementation of
 Process Improvement
  Technical environment
  Phases of the experiment
  Internal dissemination

Results and Analysis
  Skills Key Lessons
  Technological Point-of-View
  Business Point-of-View
  Strengths and weaknesses

Conclusions and future actions



Key Lessons

This section summarizes the key lessons we have learnt from undertaking the experiment.

Technological Point-of-view

One of the fundamental principles of the BOOTSTRAP software process improvement methodology is that before any investments are made in technology, the methodological questions on how to build solutions have to be answered, the methodological solutions to be institutionalized have to gain organizational acceptance and be compatible with the existing or improved processes of the organization.

This principle conforms to the philosophy promulgated by Watts Humphrey in his inseminating work on Managing the Software Process where he writes the following:

"They are thus prone to embrace some magic technological "silver bullet" that will painlessly solve all their problems. While technology is important and is the long-term key to improving the software process, it is rarely of much help in solving problems that are not precisely understood. Since most people object to having someone else's solutions to undefined problems imposed on them, the unplanned introduction of technology generally causes resistance to change."

The above BOOTSTRAP priorities are usually summarized by the following formula:

O > M > T

where O stands for Organization, M stands for Methodology, and T stands for Technology.

Armed with all the above wisdom, we still fell in a double trap. Since there was a budget allocated in the project for buying a tool, we wiped out our wisdom and carefully selected the LBMS tool before institutionalizing the necessary processes. Then, with the tool at hand, we could not wait plunging into learning it, expecting that it would provide us ready-made solutions for all of our problems. Nevertheless, we had to realize the facts of life quickly. Not all of the necessary processes were readily usable in our case in LBMS.

At this point, remembering the wisdom, we returned to defining both the planning and review processes independently from the tool. On the one hand, this approach proved well to be necessary for the review scenario. On the other hand, we also invested a lot of work into the planning scenario until we discovered that in this case, the model coming with LBMS was actually fully applicable. This is the point where we came to appreciate that LBMS was not simply a tool but also an experience library to which the above wisdom does not directly apply.

The lessons from the above experience are the following:

  1. Do not yield to the temptation of immersing into the use of however expensive tools before having analyzed the real problems and processes the tool is intended to solve. This was the reformulation of the above wisdom.
  2. Today, most products on the market, that are positioned or considered as tools, go much further than that. They include a library of templates or experiences which may well be more valuable and have a validity independent from the tool itself. The above wisdom does not apply to these libraries which are most of the time worth being examined before starting to analyze our own problems.
  3. After examining the libraries, do not yield to the second temptation of immersing into the use of the tool. Listening to the wisdom, examine your real problems and processes and try to critically match the solutions offered by the library to them. If the match is not perfect, try to adapt first and ultimately develop your own solutions. This is the point where the use of the tool may become valid and also appreciated.
The above lessons allow us to extend the scheduling priorities the BOOTSTRAP methodology is based on. Using the formula, the priorities look like the following:

L > O > M > T

where L stands for Library of experiences or templates. The importance of the extension lies in the fact that the cornerstone of the model is still O while the so called tools include L, M, and T.

Business Point-of-view

It was the development of MemoLuX's organization in compliance with ISO 9001 requirements and not the certification itself which was an objective of the PIE. We recognized in time however that the improvement of our maturity level brought us within short reach of the ISO 9001 certification level. We decided at this point to reallocate resources so that we can achieve this business objective. The consequences of our decision were the following:
  • The baseline project was delayed by two months which caused a minor rescheduling of the PIE itself.
  • The maturity level previously improved in the framework of the PIE allowed us to reach ISO 9001 compliance and actual certification within one month as compared to the originally expected duration of 6 months.
  • The higher credibility due to our ISO 9001 certificate brought immediate business benefits significantly earlier than originally anticipated in the PIE.
  • Process improvement could be perfectly continued after the certification.
The lessons from the above experience are the following:
  1. The approach of considering the improvement of the maturity level as the principal objective and the achievement of ISO 9001 certification as a side-effect is valid from the efficiency point of view.
  2. Even if ISO 9001 certification is not the principal objective of process improvement, it may be worth capitalizing on its high recognition by allocating appropriate resources to its achievement at the right stage during the process improvement project. The business benefits may well outweigh the effect of the resulting delays in the process improvement itself.
  3. The ISO 9001 certification does not only have direct business benefits. According to international experiences, there is usually a significant decline of attention towards the quality system after the certificate is granted. The approach of considering certification as a side-effect of overall process improvement not only helps avoiding this trap but the quick success even has a spurring effect on the whole IT organization regarding further process improvement.

Strengths and weaknesses of the experiment

The main strength of the experiment is that most of the weaknesses could be corrected. Due to the strong project monitoring, the need for corrective actions was recognized in time (at the closure of the first stage).
  • resources were re-allocated from the project management task to the use-steps of the scenario development to further actual try-out in the baseline project
  • a software circle as feedback mechanism was founded
  • all intermediate results of each scenario and quality development were discussed in this circle.
The corrective actions resulted in success. Two critical problems were solved. On the one hand the full ISO 9001 quality system documentation was completed in compliance with the redefined process workflows, on the other hand internal dissemination connected with continuos improvement of the deliverables worked due to the new feedback mechanism.

Further lessons derived from recognized and corrected weaknesses are summarized below.

The quality system and the scenario development were running in parallel, however at the beginning no links were taken into account. A quality system consists of the Quality Manual, Procedures, and detailed Working Instructions for the procedures. The scenarios should have been aligned with the Procedures and Working Instructions in the Quality Manual, or at least there should have been a mapping.

The introduction of a scenario was done following a predefined series of steps. There was however a misunderstanding of the "use" step. MemoLuX gave the subcontractor the task to try out the scenarios in ways like "use the planning scenario to plan the development of scenarios", or "use the review scenario to review the review scenario"" instead of "use the review scenario to review the customer requirements in the baseline project".

In order to overcoming such misunderstandings derived from missing interaction between the early stages of the PIE and baseline projects, a software circle had to be created, consisting of the experts and the staff that in future would have to work with the results produced by experts. The software circle had a meeting every two weeks for 2 hours. The result of each step was presented to this circle, opinions were discussed, and feedback was recorded. Without this complementary action, it is questionable whether the results (new workflows) would have ever been accepted by the staff.

Back to the PASS main page

ISCN Logo ISCN Information Request

MailBox I.S.C.N. International Software Consulting Network
Florence House, 1 Florence Villas, Bray, Co Wicklow, Ireland

Tel: +353 1 286 1583, Fax: +353 1 286 5078

Last modified: 14-Jan-99, designed by Reinhard Urban, © ISCN 1998
URL: http//