PreProject Phase

Revision as of 14:16, 30 August 2017 by Klaus (Talk | contribs)

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


Pre AnalysisPre ContractingPreProjectOverview.png


The dish

A lightweight analysis of the system-to-be.


  • All information available from the customer.


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 depends 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) describing 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 the PreContracting for the Launch Phase by including the necessary artefacts produced during the PreProject Phase.


A development process is the process of fulfilling a customer's needs.

Customers are rarely able to specify exactly the requirements for the system-to-be.

Capturing and refining the exact requirements are tasks to be done by the developers, thus transforming the customer's needs into requirements for the system-to-be.

Requirements must be clear, concise and testable, thereby dictating an unambiguous outline of the system-to-be.

The development process enables the system-to-be to fulfil the customer's needs.

Transformation Process.png

The development process at a glance

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. In other words, focus is on capturing the customer's needs.

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. However, be careful not to iterate more than necessary to estimate the time needed for the Launch Phase.

Do not think in solutions

The developer is expected to add his or her 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 s/he 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.

Be careful with what your system can do

The more experienced developer may suggest that working routines should be considered changed, if s/he 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, however, be aware that not even a perfect IT system can solve conflicts or disorganised work-flows. Consequently, the developer should back-off if s/he discovers that the customer tries to "buy" problem-solving through 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.


This is one example of completing a PreProject Phase. It has been performed by third semester students at AU Herning in 2010.