PreProject Phase

From EUDP
Revision as of 06:35, 25 September 2009 by Ellyk (Talk)

Jump to: navigation, search

What

Error: No valid link was found at the end of line 7.

Pre Analysis

Pre Contracting

How

The dish

A lightweight analysis of the system-to-be

Ingredients

  • All information available from the customer

Process

At the first meeting with the customer schedule a number of future meetings with the customer - and if possible also with a specified user representative. The number of meetings depend on the size of the project, smaller projects may only require three meetings whereas large projects may require several meetings.

Gather information about the stakeholders at all the meetings.

Draw Rich Pictures when necessary.

Evaluate if the customer can write stories describing the system-to-be in a casual manner. Show examples of storytelling and storycards or previously written stories/storycard(s) to inspire the customer. If the customer is capable of and willing to write the stories, it is an excellent idea to let him/her do so. Otherwise, the developer should gather enough information from customer interviews/meetings in order to write a short novel or storycard(s) which express the system-to-be.

Determine if there are Use Cases that need further analysis. If so select the usage situations that need further analysis and prepare Preliminary Use Cases by writing a more detailed usage description.

Prepare a stakeholder analysis by using the information gathered at previous meetings.

Write a System Definition based on the information gathered so far.

Prepare a Development Plan for the Launch Phase.

Prepare a Quote based on the Development Plan.

Write a contract for the Launch Phase by including the necessary artifacts produced during the Preproject Phase.

Why

The Preproject Phase is a very lightweight early analysis of a new project. Use the Preproject Phase to learn just enough about a customer's idea to estimate the cost of a more general analysis.

The Preproject Phase is conducted in close cooperation with the customer - it is the customer who has the knowledge about the system-to-be. Consequently, there will be quite a large number of meetings where the customer and / or representatives of future users and developers meet to discuss, do brainstorming and knowledge transfer to the developer.

Expect that the work will be highly iterative, i.e. the activities performed will be repeated a number of times refining the understanding of the system-to-be in every iteration.

The developer is expected to add his or hers experience, but not to think in solutions, i.e. how to implement this or that. The developer should be open-minded and listen carefully to the customer's requirements and wishes. It is difficult to avoid thinking in solutions. However, if the developer does think in solutions, there is a risk that he/she delivers a product which is easy to grasp, but also a product that does not fulfil the customer's demands in full. With an open mind new hitherto unrevealed ideas may arise and thereby the outcome will be a much better solution for the customer (and in the end for the developer as well). How to implement the new ideas is left to solve rather late in the development process. And through a thorough analysis and design process, it very often appears that what might have looked impossible to solve in the initial stages of the project can in fact be solved in a rather simple and elegant manner.

The goal is to deliver products that solve customers' problems most efficiently and adapt to the current way of working rather than require reorganisation or changing the way a task is done. Therefore, the developer should be careful not to suggest solutions that limit the future users ability to do their work properly.

The more experienced developer may suggest that working routines should be considered changed if he or she experiences that there is something wrong in the way the current work is organised or performed at the customer's organisation. The Rich Picture, for instance, can be used as a very efficient tool to show how the work-flow is organised. Suggesting changes by drawing a new Rich Picture which shows a more efficient work-flow can be presented to the customer. But the developer should leave it to the customer's own organisation or other external consultants within the organisational branch to implement the changes. The developer should focus on developing well-designed IT-systems that solve the customer's needs. The developer should, though, be aware that not even a perfect IT-system can solve conflicts or mis-organised work-flows. Consequently, the developer should back-off if he or she discovers that the customer tries to "buy" problem-solving though the introduction of a new IT-system rather than focusing on the real problem. History has shown that neither the developer nor the customer nor the end-users will be satisfied, and the developer would face a long dark period in his attempt to fix all kinds of problems that by nature originate in organisational problems.

Example

An example will be presented later. Please return to this page later.