Project-oriented software implementation: customization according to experience

The choice of the appropriate strategy is a decisive step on the way to successful software introduction. The project-oriented software introduction is a variant of the iterative, i.e. step-by-step software introduction. A small project team first uses the new software in a project typical for the company. In the best case, the project team was involved in the software selection and is not only open to new processes, but also drives them forward as a tiger team. Since the project team is of a manageable size, it is flexible and does not have to invest a lot of time in preparing the test project.

If possible, during the course of the project, the software is adapted to the company-specific processes and guidelines for use in future projects are defined. It is also decided here whether the software and the adapted configuration should be tested in a second test project or whether use can be extended to all projects and departments of the company straight away.

Provided that the company's projects are very similar, for example if it is always software development on behalf of a customer, all future projects can start with the new software after the test project has been successfully completed. It is also possible to start a second test project while the first project is still running, but it is important to make sure that enough time passes so that the lessons learned from each project phase can be used for the second test project.

If the projects are very different, a second test project should definitely be started after the first test project has been started and the first experiences have been gained. After all, as an external project, software development on behalf of a customer requires completely different project structures, management and documentation than, for example, an internal marketing project for employee retention. In this case, a simultaneous project start is not a problem. For an internal test project, for example, it is not possible to implement improvement suggestions on topics such as the business case, risks, offers, customer communication or billing from a test project with a customer focus.

The ideal test project for project-oriented software implementation is one that involves typical company processes and whose failure would not have any far-reaching or serious consequences in the event of an emergency. The termination costs would be low. Therefore, the project-oriented introduction strategy is particularly recommended in an uncertain project environment.

If the motivation of the employees is still low and they are critical of the new software, the project-oriented method is particularly recommended. If the Tiger Team is successful in the test project, it promotes the benefits of the new software internally and thus increases the motivation of the entire workforce bottom-up. Since the first iteration has this signaling effect, it is all the more important to select a suitable project and, above all, an inital Tiger Team that is already motivated. This is because the multiplier effect can also have the opposite effect if the Tiger Team did not have a good experience and thus further lowers the motivation of the remaining employees.

This project-oriented strategy is not well suited if projects are managed via the central PMO. In this case, duplicate efforts may be required to maintain project data in the old system to enable cross-project resource management and project controlling for the PMO. If necessary, temporary interfaces to the old software would even have to be created to enable seamless project controlling. This would be unnecessarily time-consuming and costly.

Since the implementation period depends on the duration of the test project, this approach should not be used for projects with a long runtime, such as group-wide ERP implementations. Since it is not yet clear at the beginning of the introduction whether a second or, if necessary, further test projects will be required, an introduction project cannot be scheduled exactly according to the project-oriented software introduction. A very tight or forced schedule for the implementation project makes the application of project-oriented implementation impossible and leaves only the option of implementation via the big bang method open.

Your framework conditions are not optimal for the application of project-oriented software implementation? In this case, you have a wealth of other options:

The project-oriented software introduction is a practice-oriented concept to introduce a new software in the company. The strategy is particularly well suited for companies where the projects are similarly structured and the new software is to be adapted directly on the basis of the experience gained in practical use. For very different projects, a second test project is recommended to ensure that the software is adapted to the specific requirements.

In the case of large, long-term projects, such as group-wide ERP implementations, project-oriented software implementation is not recommended. In addition, project-oriented introduction can prove problematic if projects are managed via the central PMO.