The Four Phases of EUDP

Revision as of 12:30, 6 September 2010 by Klaus (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


The EUDP method will guide you in direction of your goal, similar to what the Approach Flight Director, in the Flight Control Tower does. You will start in high altitude and in a controlled manner the guide brings you closer and closer to your runway, enabling you to see more details while following the glide-path downwards in you flight. In a system development the developer often starts flying at a high altitude and can only see a few details about the project. As the project progresses toward the completion the developer knows all the details. The four phases are the guides that ensures a perfect landing.

The EUDP method consists of four phases.

In the PreProject Phase we define how to get the grasp of a new project. Typically the Customer calls the Developer to get an idea of if a new idea can be realised and within what economic frame. In this phase the developer works without being able to bill the customer. Consequently this phase must be kept as short as possible. The work necessary to complete should bring the developer to the point, where it is possible to present a quotation that covers the Launch Phase i.e. the developer should understand enough of the customers idea to estimate the how long time should be spent analysing more detailed.

The Launch Phase is normally paid by the customer on an hourly basis and therefore the developer can analyse the system-to-be more detailed. The developer describes the general design of the system-to-be and gets an idea of how the system-to-be should be implemented. On the exit of the Launch Phase the developer can estimate a fixed price for developing the total system-to-be and consequently present the customer for a new quotation covering the rest of the project.

If the customer accepts the quote the project can go into the Realisation Phase, where the developer iterates a number of times through several disciplines developing more and more functionality into the system-to-be ending up with the system the customer asked for. Each iteration should last 3-6 weeks. As a result of each iteration the developer delivers a product with a certain agreed level of functionality. The customer can use the system, test it and verify that the intentions are correct. If any misunderstandings are realised they can be corrected quickly and early in the development thereby reducing the cost of correction. Everybody knows that if an error or misunderstanding can be found early in the development the price to correct the problem are far lower than if the error was found late in the development.

Finally it is important to leave the project and finalise the cooperation with the customer with a good feeling for both parties. Hence the PostProject Phase. In the Postproject Phase the customer runs through an acceptance discipline verifying the the product fulfils the requirements. In cooperation the customer and the developer evaluates the product and the project. It is important to learn from every project completed. The key is to find what went well but also to find anything that the customer or the developer find can be improved i further projects. System development is never the same from project to project nor are the customers or the developers. Constant improvement are the key to success for all involved. Improvements can only be gained if a thorough evaluation is conducted.

We mention Four Phases of EUDP. But in reality there are yet another phase that covers methods or rather disciplines that can be introduced in practically all the above mentioned phases - The Cross Disciplinary Disciplines (CDD). The CDD covers subjects like contracting, management with different views, human processes, reviewing and other sociological aspects that a developer may need to complete a system development.