For further information, please contact our expert.
Project Methodology
A
solid and resilient foundation
of process models and project methods
Marina Yesayan
Senior Consultant
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.
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:
- Transparency: The progress and obstacles of a project are recorded on a daily basis so that they are visible to everybody.
- Inspection: Functionalities are delivered and assessed at regular intervals.
- Adaption: The product requirements are not fixed permanently at a particular time, but re-evaluated after each delivery and adapted by further iteration if necessary.
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