02/01/2023 - Articles

Project-oriented software implementation: customization according to experience

Project-oriented software implementation is a variant of iterative, step-by-step implementation. Find out here for which companies and which use cases this implementation strategy is suitable, where its advantages and disadvantages lie, and how you can successfully implement it for your implementation project.

Was ist die projektorientierte Softwareeinführung?

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.

What should be considered during project-oriented software implementation?

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.

Project-oriented software implementation: advantages and disadvantages

  • Little preparation required: The rollout is gradual and iterative, which allows a high degree of flexibility. Since it is a small, motivated project team, little preparation is required.
  • Not suitable for large projects: This approach is not recommended for projects with a long runtime, such as group-wide ERP implementations.
  • Practical experience: The software is used directly within the framework of a typical company project, which makes it possible to adapt the software to practical experience.
  • Cannot be scheduled precisely: Since it is not yet clear at the beginning of the implementation whether a second or possibly even further test projects will be necessary, the scheduling of the implementation is imprecise.
  • Low termination costs: The recommended test projects have a manageable impact on the company and can be terminated without serious consequences in case of emergency.
  • Duplication of effort: If projects are managed via the central PMO, there may be duplicate efforts in maintaining project data in the old system to enable cross-project resource management and project controlling for the PMO.
  • Suitability for similar projects: In the case of projects that are similar, project-oriented implementation is particularly suitable, as the software can be transferred directly to other projects on the basis of experience gained from a test project.
  
  • Motivational: A successful test project quickly boosts motivation within the workforce.
 

When is project-oriented software implementation recommended?

Project-oriented implementation is particularly recommended if a company's projects are similar and the new software is to be adapted directly on the basis of practical experience. 

If a new software is to be introduced in many locations of a company and profound process changes are to be expected as a result, the project-oriented introduction is the best option in addition to the functional iterative approach. In comparison with this method, the project-oriented introduction scores above all if:

  • Requirements and goals are at least roughly known,
  • The motivation of the later users is low, and
  • The project manager has little experience to fall back on.

Projects with cross-location project teams are not suitable as test projects within the framework of project-oriented software introduction.

When does project-oriented software implementation not make sense?

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.

What are the alternatives to project-oriented software implementation?

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

Software introduction after Big Bang

With the big bang strategy, all software modules are activated for all users on a specific date. The new software replaces the legacy system holistically, so that users do not have to maintain processes in the new and legacy systems in parallel. However, the risk is high.

Functional iterative implementation strategy

Functional iterative software introduction is a variant of the iterative, step-by-step introduction of modular enterprise software. In this approach, the individual functional modules of the new software are introduced into the company one after the other.

Departmental or regional iterative rollout

The regional iterative software introduction and the departmental iterative software introduction following the same principle are variants of the iterative, step-by-step introduction A company introduces a software completely with all desired functional modules successively at different locations or departments.

Combined implementation strategies

By combining big bang and iterative process models, companies can develop customized strategies for introducing enterprise software that are precisely tailored to their individual needs. This enables more precise and flexible implementation.

Are you in doubt whether project-oriented software implementation is the right approach for your implementation project? No problem! We have accumulated decades of experience in the introduction of complex enterprise software and can support your project team individually, specifically and competently through strategy finding, training, workshops and in a consulting capacity.

 

Contact Projektron

Best Practice: Project-oriented software introduction of Projektron BCS at Be Shaping the Future

Be Shaping The Future was confronted with the growth of their company and the complexity of their business processes. Their self-developed software for employee time recording and payroll could no longer keep up with the increasing requirements, which led to an increased use of manual MS Excel sheets. To meet these challenges, the company decided to introduce a standard solution for project management, billing and controlling.

After a thorough analysis of their business processes and a selection of several providers, Be Shaping The Future opted for Projektron BCS. After a pilot phase in which the software was successfully tested, Projektron BCS was introduced as the core software for the company's delivery management.

The implementation included customizations to meet the company's specific requirements, such as integration with other systems and configuration for different working time models. Despite some initial challenges, the system is now running stably.

The use of Projektron BCS goes beyond the original requirements and enables the company to efficiently manage even complex customer projects and optimize internal processes. The decision to use Projektron BCS has proven to be a wise one and will help to realize the company's full potential in the financial sector, Ursula Meyer, Delivery Manager in the case study of Be Shaping The Future - Performance, Transformation, Digital GmbH describes.

"The pilot phase began with BCS.start as a SaaS solution: the system was set up, configured for a few projects and available within a few days. After a short training session for the selected users, we got started. During this pilot phase, it quickly became clear that we had made a good choice with Projektron BCS - our requirements were met as expected. In April 2023, our management decided to introduce Projektron BCS as the core delivery management software at Be Shaping the Future."

Ursula Meyer
Delivery Manager, Be Shaping The Future - Performance, Transformation, Digital GmbH, Munich

"When introducing Projektron BCS, we opted for a step-by-step approach: After the technical implementation and initial configuration, during which we were supported by a Projektron consultant, we initially only entered one major project in BCS.Over the following months, all projects were successively entered in BCS and after about a year, an entire business unit switched from its existing solution to Projektron BCS."

Iván Sándor Szerbin
Application Support, IDS GmbH, Munich

Conclusion: Project-Oriented Software Introduction - Achieving the Goal with Tiger Team

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.

About the author

Francisco Josué Artaza has been working with Projektron GmbH for 15 years, currently as marketing manager and user consultant. He is certified in IPMA, PRINCE2, and as a Scrum Product Owner. He is an expert in software implementation strategies and has developed a tool that facilitates the selection of the appropriate strategy.

  

All references To top