Project methodology

CALEO carries out projects in coordination with the customer side. Stringent project implementation and the involvement of experienced consultants ensure the success of the project.

During conception and implementation, particular attention is paid to creating solutions that provide long-term benefits to the customer and that can be operated and further developed at a reasonable cost. In addition, care is taken to ensure that the new solution fits seamlessly into the customer's existing system landscape.

Depending on the size of the project, the objectives, the subject area and the customer's wishes, we carry out projects in an integrated phase model that has proven itself in numerous SAP projects or in the currently very popular SCRUM methodology.

An agile project approach is particularly suitable for subject areas in which change requests occur frequently due to the fact that the target image has not yet been defined - in most cases there is no business blueprint yet - which can thus already be intercepted during implementation and reduce subsequent costly change requests to a minimum.

On the other hand, the integrated phase model is suitable for a large number of projects in the financial area - this includes in particular the topics of consolidated financial statements and business planning - as it creates clarity about project duration and performance at an early stage.

We have already carried out a large number of projects in both project methodologies and therefore have extensive experience in both worlds

Projects are usually started with a conception phase. During this phase, the business processes and customer-specific requirements are analyzed and defined. The rough concept (blueprint) to be created defines the basic functions of the application to be created and serves as the basis for scoping and further project planning. In the concept phase, the underlying technologies are also selected (software selection). If necessary or desired, a proof of concept is realized in the form of a prototype. The conception of a new application requires profound know-how about the underlying business processes as well as the possibilities of the available software.

CALEO designs processes and applications together with customer employees to ensure that all company specifics are sufficiently taken into account. Our consultants, in turn, contribute their expertise and many years of project experience in the financial sector to the concept phase.

The starting point for the technical design (detailed concept) is the rough concept created during the concept phase with the requirements for the new solution. The technical design contains a detailed description of the data models, master data as well as the functions to be implemented and the associated processes. The detailed concept is approved by the customer before implementation begins and serves both as a basis for building the application and as a reference for later testing of the application according to the proven V-model approach.

The creation of the technical design requires in-depth knowledge of the software used. Our consultants specialize in specific software packages and bring this specialized knowledge to the technical design.

The basis for implementation is the detailed concept from the design phase. The implementation typically starts with building the data model (e.g. BW InfoCubes). Then the logic of the application is implemented step by step. The individual subcomponents are already tested by the responsible team during implementation to ensure that the functionality described in the detailed concept is available. At the end of the implementation phase, all functions described in the detailed concept have been implemented and are ready for the overall test of the application.

Following the construction of the application during the implementation phase, quality assurance is carried out as part of the test phase. The tests ensure that the required functionality according to the detailed concept is available and works under realistic conditions so that a smooth go-live can take place. Integration tests validate the interaction of all components along the individual process steps. A user acceptance test gives the subsequent users the opportunity to test the application extensively before going live.

After the application has been successfully tested and approved, it goes live. The objects are transferred from the development environment to the production environment. In addition, the new application is supplied with master data and, if necessary, with historical transaction data.

System documentation is created that describes customizing and in-house developments in detail. The system documentation is the basis for the subsequent maintenance and servicing of the system.

User documentation describes the use of the system from the perspective of the subsequent users. In the course of going live, training is also provided for future users.

The methodology dispenses with the classic waterfall approach often practiced in larger SAP projects and pursues the goal of quickly delivering tangible results for the client. If necessary Change requests requested by the customer can thus be integrated directly within the next iteration and thus cause lower project cost risks.

At the beginning of the project, a project backlog is created together with the client's project team. The project backlog collects all deliverables and deliverables to be created.

In the course of sprint planning, services and deliverables are prioritized from the project backlog, coordinated with the client and a task backlog is created for a 14-day sprint.

Subsequently, the task backlog is processed within the framework of a sprint. At the midpoint of each sprint, a sprint review is held by the project team in order to identify any issues. Identify necessary change requests at an early stage and, if possible, integrate them directly into the deliverable within the sprint. The goal of a sprint is to deliver functionalities and results to the client within the 14 iterations, which can then be tested at an early stage.

At the end of each sprint, a results presentation takes place within a sprint review meeting. Tasks that are not completed are written back to the task backlog of the next iteration and prioritized again for the following sprint together with new task packages from the task backlog.