Difference between revisions of "Development Planning Realisation"
(New page: == What == A detailed planning showing activities, resources and interaction for each time box in the Realisation Phase. == How == '''The dish''' Development Plan '''Ingredients...) |
(→Kanban Board) |
||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
A detailed planning showing activities, resources and interaction for each time box in the Realisation Phase. | A detailed planning showing activities, resources and interaction for each time box in the Realisation Phase. | ||
| + | |||
| + | [[Image:DevelopmentPlanning.png|300px]] | ||
== How == | == How == | ||
| Line 12: | Line 14: | ||
'''Ingredients''' | '''Ingredients''' | ||
| − | * All | + | * All artefacts produced in the Launch Phase |
* The Development Plan from the Launch Phase | * The Development Plan from the Launch Phase | ||
* Experiences and metrics from previously performed projects | * Experiences and metrics from previously performed projects | ||
| + | * Development Strategy | ||
| + | * Verification Plan | ||
* The Deployment Plan | * The Deployment Plan | ||
| Line 23: | Line 27: | ||
'''Process''' | '''Process''' | ||
| − | As we know, the Realisation Phase consists of six activities, namely Strategy & Planning, Analysis, Design, Implementation, Verification and Deployment. These activities must be prepared thoroughly in several timeboxes, where each timebox should be of two to six weeks in length. The first couple of timeboxes can be of a different length according to the overall strategy and planning of the project. | + | As we know, the Realisation Phase consists of six activities, namely 'Strategy & Planning', 'Analysis', 'Design', 'Implementation', 'Verification' and 'Deployment'. These activities must be prepared thoroughly in several timeboxes, where each timebox should be of two to six weeks in length. The first couple of timeboxes ''can'' be of a different length according to the overall strategy and planning of the project. |
| − | + | At the beginning of each timebox, plan the work just ahead. You should consider the following aspects: | |
| − | * | + | * Define the ''Activities'' - what needs to be done? |
| − | * | + | ** Define the planned development - what was planned in the strategy for this timebox? |
| − | * | + | ** Define the interaction with others - to what extent is it possible for the customer, other developers, sub-suppliers, the interface and other prerequisites to have an impact on the project? |
| − | * | + | ** Are there any corrections to be made - are there any deviations that could impact any parts of the project? If so, you should take action accordingly. |
| + | * Determine what ''Resources'' are available and in what amount - who will do it and what tools are needed? | ||
| − | Remember to plan the time that the customer needs to interact with the project and | + | Remember to plan the time that the customer needs to interact with the project, and make sure that you have his/her full attention and commitment. Also, allow for considerations and feedback after each deployment. |
== Why == | == Why == | ||
| Line 42: | Line 47: | ||
Resources are always a problem. You never have the right resources at the right time, but you have to do the job anyway. So be careful planning your resources and use those you have with high attention and skills. Good knowledge of human behaviour is essential. | Resources are always a problem. You never have the right resources at the right time, but you have to do the job anyway. So be careful planning your resources and use those you have with high attention and skills. Good knowledge of human behaviour is essential. | ||
| − | Lack of attention to customer interaction is the reason why projects end up in disaster. It is very difficult to plan, so here you really need to draw on your experience and metrics. Murphy's law ("if anything can go wrong | + | Lack of attention to customer interaction is the reason why projects end up in disaster. It is very difficult to plan, so here you really need to draw on your experience and metrics. Murphy's law ("if anything can go wrong - it will!") applies to interaction as well as correction; if you have not planned time for corrections, then you surely will end up behind schedule! Why carry out tests if you do not have time for corrections? Why ask the customer if you do not have time to listen? Again, experience and metrics are crucial factors. |
| − | + | ||
As we know, the main idea of the EUDP method is to involve the customer. In order to do that the right way, you need to plan the time and resources that you want the customer to spend on the project. You must have the customer's commitment! | As we know, the main idea of the EUDP method is to involve the customer. In order to do that the right way, you need to plan the time and resources that you want the customer to spend on the project. You must have the customer's commitment! | ||
| + | |||
| + | == Example == | ||
| + | |||
| + | [[Image:DevelopmentPlan.png|600px]] | ||
| + | |||
| + | '''An example of an incomplete development plan.''' | ||
| + | |||
| + | ===Kanban Board=== | ||
| + | |||
| + | A simple, yet effective, way of project management is to use the Kanban board on a whiteboard. | ||
| + | |||
| + | [[Image:Kanban-project-management.png|400px]] | ||
| + | |||
| + | Using self-adhesive yellow sticky notes, it is easy to see what needs to be done, what is in progress and what has been done. Place the ''to-dos'' for the current timebox in the '''To Do''' column. Each note should be a task that can be developed by a developer during a normal working day | ||
| + | |||
| + | Move a note from the '''To Do''' column to the '''Doing''' column when beginning the development, and then move it to the '''Done''' column when the development has finished, and the task has been tested and is ready for deployment. | ||
| + | |||
| + | There are several advantages from managing a project in this highly visible way, including: | ||
| + | |||
| + | * The development team can easily see which tasks are | ||
| + | ** ahead, | ||
| + | ** in progress and | ||
| + | ** done | ||
| + | * The same goes for the project management | ||
| + | * The customer has visible evidence of progress in the development of his/her project (share it using a webcam or take a daily snapshot and send it to the customer; these are good ways to keep the customer happy) | ||
| + | |||
| + | Some extend the board with an extra column leftmost with all known tasks, the backlog, and move those selected for deployment in the next timebox into the '''To Do''' column at the beginning of the timebox. This column could be called '''Backlog'''. The constant progress of notes moving from left to right is a motivating factor for everyone involved in the project. | ||
Latest revision as of 08:01, 8 July 2015
Contents
What
A detailed planning showing activities, resources and interaction for each time box in the Realisation Phase.
How
The dish
Development Plan
Ingredients
- All artefacts produced in the Launch Phase
- The Development Plan from the Launch Phase
- Experiences and metrics from previously performed projects
- Development Strategy
- Verification Plan
- The Deployment Plan
Artifacts
Detailed Development Plan for each timebox.
Process
As we know, the Realisation Phase consists of six activities, namely 'Strategy & Planning', 'Analysis', 'Design', 'Implementation', 'Verification' and 'Deployment'. These activities must be prepared thoroughly in several timeboxes, where each timebox should be of two to six weeks in length. The first couple of timeboxes can be of a different length according to the overall strategy and planning of the project.
At the beginning of each timebox, plan the work just ahead. You should consider the following aspects:
- Define the Activities - what needs to be done?
- Define the planned development - what was planned in the strategy for this timebox?
- Define the interaction with others - to what extent is it possible for the customer, other developers, sub-suppliers, the interface and other prerequisites to have an impact on the project?
- Are there any corrections to be made - are there any deviations that could impact any parts of the project? If so, you should take action accordingly.
- Determine what Resources are available and in what amount - who will do it and what tools are needed?
Remember to plan the time that the customer needs to interact with the project, and make sure that you have his/her full attention and commitment. Also, allow for considerations and feedback after each deployment.
Why
The detailed Development Plan must be carried out by all members of the project team, including the customer. This is important in order to obtain full attention and commitment.
The activity plan lists all the aspects that each team member has to carry out for each timebox. This will ensure that each team member not only knows what to do, but also what has to be done by other team members. As a result, it is easier to maintain an overview and be able to take active part in the project.
Resources are always a problem. You never have the right resources at the right time, but you have to do the job anyway. So be careful planning your resources and use those you have with high attention and skills. Good knowledge of human behaviour is essential.
Lack of attention to customer interaction is the reason why projects end up in disaster. It is very difficult to plan, so here you really need to draw on your experience and metrics. Murphy's law ("if anything can go wrong - it will!") applies to interaction as well as correction; if you have not planned time for corrections, then you surely will end up behind schedule! Why carry out tests if you do not have time for corrections? Why ask the customer if you do not have time to listen? Again, experience and metrics are crucial factors.
As we know, the main idea of the EUDP method is to involve the customer. In order to do that the right way, you need to plan the time and resources that you want the customer to spend on the project. You must have the customer's commitment!
Example
An example of an incomplete development plan.
Kanban Board
A simple, yet effective, way of project management is to use the Kanban board on a whiteboard.
Using self-adhesive yellow sticky notes, it is easy to see what needs to be done, what is in progress and what has been done. Place the to-dos for the current timebox in the To Do column. Each note should be a task that can be developed by a developer during a normal working day
Move a note from the To Do column to the Doing column when beginning the development, and then move it to the Done column when the development has finished, and the task has been tested and is ready for deployment.
There are several advantages from managing a project in this highly visible way, including:
- The development team can easily see which tasks are
- ahead,
- in progress and
- done
- The same goes for the project management
- The customer has visible evidence of progress in the development of his/her project (share it using a webcam or take a daily snapshot and send it to the customer; these are good ways to keep the customer happy)
Some extend the board with an extra column leftmost with all known tasks, the backlog, and move those selected for deployment in the next timebox into the To Do column at the beginning of the timebox. This column could be called Backlog. The constant progress of notes moving from left to right is a motivating factor for everyone involved in the project.
