PASS (Pay-roll Accounting and Settlement System)

Background Information
  Objectives
  Involved companies
   and their roles

Starting scenario

Expected business impact

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

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

Conclusions and future actions

Glossary

References

Key Lessons

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:

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.

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

• 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.

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.

• 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.

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.