Project Methodology

A of process models and project methods
Adrian Bourcevet

From vision to finished product

Based on years of project experience, CubeServ has built up a solid and resilient foundation of process models and project methods for the different types of projects. The general methodology is described below.

Waterfall model

CubeServ generally recommends the classic approach of the “waterfall model” for handling projects. This model is particularly well suited because it allows a step-by-step approach. In the waterfall model, each phase has predefined start and end points with clearly defined outcomes. The outcome documents are approved in milestone meetings at the end of each project phase. The most important documents include the product requirements document and the functional specification.

Based on the fundamental principle of the waterfall model, we recommend a step-by-step process for each individual part program, comprising the steps of initialisation, outline concept, detailed concept, realisation and introduction as described below.

Graphic: course of action based on the waterfall model

Initialisation: Migration planning and project preparation with kick-off

Outline concept: Analysis of the AS IS situation and development of an outline concept

Detailed concept: Concept refinement and prototyping of the application

Realisation: Technical realisation in terms of IT and concept refinement

Introduction: Introduction of the new system into productive operation

Agile methods

Apart from the waterfall model, so-called agile methods, such as SCRUM, have become established. However, the use of agile methods requires appropriate training of the project members.

Scrum is a process model for handling projects. The Scrum approach is empirical, incremental and iterative. It stems from the experience that most modern development projects are too complex to be implemented through realisation of a predefined detailed plan and from the realisation that a continuous flow of feedback is the only way to ensure success. This avoids a situation where the original complexity is increased through an even more complex plan.

Scrum attempts to structure the handling of complexity via three pillars:

One needs to bear in mind here that this approach does not reduce the actual complexity of the job itself.

The aim is the speedy, cost-effective and high-quality completion of a product, which is to match a vision formulated at the outset. The realisation of the vision to produce the finished product is not effected by drawing up highly detailed requirements lists (see requirements document/functional specification), which are then implemented in phases, but by clear descriptions of functionalities from the user’s point of view, which are then implemented in an iterative and incremental manner in consecutive intervals lasting two to four weeks, referred to as ‘sprints’. The requirements from the user’s point of view are usually referred to as ‘user stories’. With the Scrum approach, each sprint ends in the delivery of a finished (software) functionality. The newly developed functionality should be in a condition ready for delivery to the customer.

Our Offer

For further information, please contact

René Lechtenböhmer

SAP Advanced Analytics Expert @ CubeServ

Analysis & Concept


Introduction & Training

Consulting & Support