Difference between revisions of "PreProject Phase"

From EUDP
Jump to: navigation, search
m
(Example)
 
(27 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== What ==
 
== What ==
  
<imagemap>
+
<imagemap>Image:PreProjectOverview.png|
Image:PreProjectOverview_img.gif
+
rect 158 16 256 74 [[Pre_Analysis|Pre Analysis]]
 
+
rect 158 156 257 214 [[Pre_Contracting|Pre Contracting]]
 
+
#<!-- Created by Online Image Map Editor (http://www.maschek.hu/imagemap/index) -->
poly 186 36 262 36 262 54 186 54 186 36 [[Pre Analysis]]
+
desc none
poly 365 27 386 27 386 46 365 46 365 27 [[Pre Contracting]]
+
 
+
 
+
 
</imagemap>
 
</imagemap>
[[Pre Analysis]]
 
  
[[Pre Contracting]]
 
  
 
== How ==
 
== How ==
Line 18: Line 13:
 
'''The dish'''
 
'''The dish'''
  
A lightweight analysis of the system-to-be  
+
A lightweight analysis of the system-to-be.
  
 
'''Ingredients'''
 
'''Ingredients'''
  
*      All information available from the customer  
+
*      All information available from the customer.
  
 
'''Process'''  
 
'''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.
+
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.
 
Gather information about the stakeholders at all the meetings.
  
Draw Rich Pictures when necessary.
+
Draw [[Rich Picture]]s 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.
+
Evaluate if the customer can write stories describing the system-to-be in a casual manner. Show examples of [[storytelling]] and [[storycard]]s 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.
+
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.
+
Prepare a [[Stakeholder Analysis]] by using the information gathered at previous meetings.
  
Write a System Definition based on the information gathered so far.
+
Write a [[System Definition]] based on the information gathered so far.
  
Prepare a Development Plan for the Launch Phase.
+
Prepare a [[Development Plan]] for the Launch Phase.
  
Prepare a Quote based on the Development Plan.
+
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.  
+
Write the [[PreContracting]] for the Launch Phase by including the necessary artefacts produced during the PreProject Phase.
  
 
== Why ==
 
== Why ==
 +
A development process is the process of fulfilling a customer's needs.
  
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.
+
Customers are rarely able to specify exactly the requirements for the system-to-be.  
  
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.
+
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.
  
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.
+
Requirements must be clear, concise and testable, thereby dictating an unambiguous outline of the system-to-be.
  
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 development process enables the system-to-be to fulfil the customer's needs.
 +
 
 +
[[Image: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.
 +
 
 +
===Iterative===
 +
 
 +
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.
 
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.  
+
===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.
  
== Example ==
+
==Example==
  
An example will be presented later. Please return to this page later.
+
[[Media:Hydrogen - Pre-project.pdf|This]] is one example of completing a PreProject Phase. It has been performed by third semester students at AU Herning in 2010.

Latest revision as of 14:16, 30 August 2017

What

Pre AnalysisPre ContractingPreProjectOverview.png


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 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.

Why

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.

Iterative

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.

Example

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