Home / Management / Project Management / Phase the Project

Phase the Project

The result of the project has been sufficiently determined and defined. Then you can then record the activities in an action plan. An action plan is always more concrete for 'tomorrow' than for 'the day after tomorrow'.

You lay down the substantive activities that you'll carry out or have carried out to achieve the project result in a plan of action. The plan shouldn't be too tight. It only indicates how the project can best be carried out. This according to current understanding and the now known and prevailing circumstances. The action plan changes with the changes in insight and circumstances during the project. However, this's done in a controlled manner and never implicitly.

- think of all substantive activities that are necessary to achieve the project result
- does that from front to back, so from now to later. Do that the other way around too, so from the end to the beginning
- always do the above together with those who will carry out the work
- determine the natural, logical order of these substantive activities
- find out which activities can be performed in parallel. If necessary, do this by splitting them
- make sure there's a verb in every activity
- indicate per activity what the intermediate result should be
- describe the tools and materials to be used for each activity. Describe the approach or working method for each activity.

Points of attention:

- ensure that an action plan contains only substantive activities. Make sure it doesn't contain management activities
- sometimes a project contains a large number of activities. Then it's useful to divide these into subprojects
- ensure that the action plan contains all substantive activities for the benefit of a project. So not only the fun activities or just the activities of the 'project organization' itself.

Perform the initiation phase

In the initiation phase, it's about obtaining an equal picture of the project (result) from all involved. An equal indication of the project result for everyone involved in the project.

Target

- Obtaining the same picture (indication, order of magnitude) from everyone involved in the project
- Obtaining insight into the facts, what the problem is, what the goals are and above all: what the result is and what's not.

Start

- A problem / a goal / an idea / an initiative

Activities

- Determining the state of affairs
- Investigating the problem
- Examining the objective
- Formulating the desired result (and partial results if it concerns a
- larger project)
- Investigating the feasibility and enforceability of the result
- Defining the project (what is outside the project?)
- Describing the working method (improvisation, routine or project-based)
- Investigating whether, and if so which, sub-projects are needed and the relationships between them
- Inventory of the substantive activities
- Dividing the work into phases:
1. Detailed for the next phase
2. More global for all other phases
- Drawing up the project assignment.

End

- An approved project assignment.

Points of attention:

- almost everything that goes wrong in a project originates in the initiation phase
- there's almost never enough time to go through the initiation phase the first time. But there's always enough time to repeat that phase many times over.

Perform the definition phase

The definition phase involves drawing up a complete and concrete set of requirements, which the intended project result must meet in terms of: preconditions, functional and operational performance, requirements, wishes and design limitations.

Target

- Obtaining a complete and concrete set of requirements that the intended project result must meet (sometimes elaborated in terms of preconditions, functional and operational performance / requirements / wishes (what is required of the intended project result?).

Start

- An approved project assignment.

Activities

- Collection of basic material
- Interviewing the client, users and administrators and conducting research to find out the requirements
- Assign the requirements to subprojects (if any)
- Check whether you've collected all requirements by sorting requirements into four categories
1. Preconditions: these are requirements that the project result must meet unconditionally. These come from the environment to which the project must connect, from road and regulations (such as house style)
2. Functional requirements: these indicate what the project result should perform in the future, what it should or should be able to do. They can often be deduced from the goals to be pursued or the problems to be solved
3. Operational requirements: these come from what the users, customers and others can, want or need to do with the project result. Users are also those who need to manage and maintain the project result
4. Design restrictions: these come from the makers, which they find useful. Remember that a good design constraint prevents 'reinventing a wheel', but an excess of design constraints doesn't easily lead to a balanced project result.

End

- An approved project program.

Points of attention:

- avoid vague demands
- better now a fierce discussion of conflicting requirements than at a later stage
- a precondition that has been forgotten always has dramatic consequences.

Specify and sort requirements

The substantive requirements determine the 'what' of a project. The requirements collected must be complete, concrete and unambiguous. That's why it's necessary to look specifically at the definition phase for the purpose, importance and origin of the requirements (and wishes).

When locating and sorting project requirements in the definition phase of a project, it's important to remain complete, concrete and unambiguous. To this end, it's necessary to search specifically for the purpose, importance and origin of the requirements (and wishes). After all, the requirements determine the what of a project.

What to do?

- specify the preconditions (requirements that the project result must unconditionally meet), including the current and applicable legislation, but also the relationships with the relevant environment. To do this, check what the project result should connect to and what it should then take into account
- specify the functional requirements by indicating what the project result should perform in the future, what it should or should be able to do. Find these requirements specially with the client; they can often be deduced from the goals to be pursued or the problems to be solved
- specify the operational requirements by considering what the users, customers can, want or have to do with the project result. Users are also those who have to manage and maintain the project result; sometimes 'users' are the possible victims
- specify the design constraints by identifying what creators find useful, what requirements they naturally shape and how. Remember that a good design constraint prevents 'reinventing a wheel'. But too many design limitations don't easily lead to a balanced project result

A few tips:

- a vague requirement isn't a requirement; an unfeasible requirement may not be accepted either. Issues:
- requirements must not conflict with each other
- from preconditions through functional and operational requirements to design limitations, the weight (the priority) decreases.

Create subprojects

The need for sub-projects mainly arises with larger projects. Subprojects make it possible to maintain a better overview of the entire project. They also provide insight

Working with subprojects requires a clear specification of all relevant interfaces or relationships between those subprojects. It also requires monitoring of those interfaces against unauthorized and unintentional changes. Subprojects offer the possibility to test the project for completeness or completeness.

What to do?

- split the project into subprojects. Subprojects are logically related chunks of work within a project, in which:
1. coordination with other chunks is relatively simple
2. within a chunk, coordination is mainly based on experience, know-how, etc.
- object-oriented approach
1. discipline- oriented approach
2. sequence- oriented approach
3. performance-oriented approach
4. place- oriented approach
- specify each sub-project
- assign the requirements of the project to the subprojects
- specify all interfaces (relationships) between subprojects (requirements and activities).

Some tips:

- the more subprojects; the more relationships can be monitored
- the more subprojects; the more parallel working is possible
- logical sub-projects don't always fit seamlessly into the existing permanent organizations that participate in the project.

Perform the design phase

The design phase is intended to get a detailed solution / design. How will the project result look in detail?

Target:

- The design phase starts with an approved project program and ends with an approved project design.

Activities in the design phase:

- detail the project program
- investigating 'make or buy' options
- searching for solutions / designs per subproject
- searching for / designing project tools
- coordinating subprojects and project tools
- adjusting after testing the partial designs
- preparing the final project design
- detailing and adjusting the activity overview:
1. detailed for the next phase
2. more global for all other phases.

How do you make the project design?

- define the design schemes (design drawings, detailed tables of contents, layouts, etc.):
1. for the whole project
2. per subproject
3. in detail
- describe the realization methods (qualitative)
- describe the realization tools (qualitative)
- record the action plan:
1. detailed for the preparation phase
2. more global for the other phases
- record the results, grouped by management aspect, of the management activities carried out during the design phase:
1. the management requirements, with margins;
2. the associated management plans;
3. the corresponding arrangements for progress monitoring.

Points of attention:

- the what determines the how, not the other way around
- don't proceed if you don't know what the project result should look like
- good design can be made, used and maintained. But it'll also (should be) be destroyed someday
- prevent the designers from tinkering endlessly. The design just has to be good enough

Perform the preparation phase

The purpose of the preparation phase is to obtain an exact description of the result to be realized so that the implementation / realization of the project result can and will run smoothly (at the touch of a button...)

The preparation phase starts with an approved project design and ends with an approved realization program.

Activities in the preparation phase:

- working out the detailed designs
- drawing up realization instructions and the like
- purchasing / creating tools (quantitative)
- contact third parties to be contracted (suppliers)
- training (instructing) those who will carry out the realization
- detailing and adjusting the activity overview:
1. detailed for the realization phase
2. for the aftercare phase more global.
- drawing up the realization program (script)

Points of attention:

- do everything possible so that, humanly, nothing can go wrong in the realization phase
- anticipate the possible and accept the impossible

Execute the realization phase

The motto during the realization phase is: perfecting the result in one go. So: realizing what was meant, expected and agreed in previous phases.

The realization phase starts with an approved realization program and ends with an approved aftercare program.

Activities

- Contracting third parties
- Running the program
- Drawing up documentation for the aftercare phase (use, management and maintenance)
- Training (educating) the users and, if necessary, the administrators and maintenance personnel
- Detailing and adjusting the activity overview for the aftercare phase
- Drawing up an aftercare program.

End

- An approved aftercare program.

Points of attention:

- the project result must now be completely ready
- it all started here
- provision must be made for the use, management and maintenance of the project result. But also in the demolition of the project result

Perform the aftercare phase

The aftercare phase is the most important phase of all phases. This involves the use, management and maintenance of the project result.

Use the project result

- manage the project result
- maintain the project result
- maintain the tools improve
- modify the project result and tools
- optimize the use, management and maintenance of the project result demolition
- destroy or replace the project result

Points of attention:

- pursue goals and reduce problems. This can only be done in the aftercare phase with the help of the project result
- the aftercare phase is part of the project in a broad sense. This project in a broad sense runs from the unknown start of the initiation phase to the unpredictable end of the aftercare phase
- specially the aftercare phase must be started well

Share on Facebook Share on Twitter Share on LinkedIn
Back to top


Copyright 2011 - 2020 - All Rights Reserved