.. raw:: latex

    \newpage


.. title:: Planning elements
.. include:: ImageReplacement.txt
.. index:: Planning elements

.. _planning_element:


#################
Planning elements
#################

ProjeQtOr provides all the elements needed to build a planning from workload, constraints between tasks and resources availability.


The planning elements :ref:`test-session` and :ref:`meeting` are described in their topics.

.. index:: Project 

.. _planningelem_project:

Project
#######

The project is the primary entity of ProjeQtOr.

It is also the top-level of visibility, depending on profiles.

Sub-projects
************

* You can define sub-projects on any project and this unlimited. 
* On the parent project screen, you can view the children in the subproject section.
* Then, the projects may not be real projects, but just organizational breakdown corresponding to an organization.

Project type
************

There are 4 types of projects which are not managed in the same way.

OPE: Operational project
------------------------

   Most common project to follow activity.
   
   All new types are created with **OPE** code., 

ADM: Administrative project
---------------------------

   Type of project to follow non productive work : holidays, sickness, training, …
   
   Every resource will be able to enter real work on these projects, without having to be allocated to the project, nor assigned to project activities.
   
   Assignments to all project task will be automatically created for users to enter real work.
      
   These projects are not visible on Gantt type screens.
      
   Some sections and fields are not visible or do not work on administrative projects like Paused, Fix planning or the minimum threshold.
   
   
TMP: Template project
---------------------

   These projects will not be used to follow some work.
      
   They are just designed to define templates, to be copied as operational projects.
   
   Any project leader (profile) can copy such projects, without having to be allocated to them.
   
   
PRP: Proposal project
---------------------

   These projects will not be used to follow some work.
      
   This type of project makes it possible to define whether a project is strategically interesting to carry out.
   

.. seealso:: 

   :ref:`project type<project_type>`


Project traitment
*****************


.. rubric:: Fix planning 

When the "correct planning" box is checked, the project planning will not be recalculated.

* This avoids modifying the expected values.
* Planning will always be the same no matter what you do on other projects.

.. warning:: This may lead to dependencies unconsistancies



.. rubric:: Non extendable project 

When project perimeter is fixed you can't:

* add new elements to this project
* delete elements from this project
* move elements to or from this project

.. rubric:: Under construction

When a project is under construction, no :ref:`automatic emails<notif-on-event>` will be sent, no :ref:`notifications<notifications>` or :ref:`alerts<automation>` will be generated for the project elements.
   
* A project can be under construction as long as it isn’t stated. Set to :term:`In progress` status.
* The resources don't see it on :ref:`timesheet<timesheet>`.



.. rubric:: Exclude from global plan

* Do not show the not plannable items for this project on the global planning view.
* This means that only standard planning items will be displayed excluding:

* :ref:`Actions<action>`
* :ref:`Decisions<decision>`
* :ref:`Deliveries<deliveries>`
   
.. rubric:: Validated work treatment    

Activates treatment of the validated work based on the sum of the work of the project orders otherwise it will be calculated on the sum of the validated work of the activities.



.. rubric:: Manual indicators

* Fields: :ref:`Health status<health-status>`, :ref:`Quality level<quality-level>`, :ref:`Trend<trend>` and :ref:`Overall progress<overall-progress>` are manual indicators.
* They allow define visual way the general health, conformity, trend and progress of the project.
* Some manual indicators are displayed on the :ref:`Today screen<today-screen>`. 

.. figure:: /images/GUI/PLANNINGELEM_ZONE_ManualIndicator.png
   :alt: Manual indicator on the Today screen
   
   Manual indicator on the Today screen

.. rubric:: Special fields

* The value of the fields the Project name, Sponsor, Project code and Contract code can be used as the substitute value of special fields.
* See: :ref:`administration-special-fields`

.. rubric:: Monitoring indicator

* The :ref:`indicators<indicator>` can be defined on the :ref:`progress data<progress-section>`.


.. _projet-donot-start: 

.. rubric:: Do not start project before Validated Start Date

* The schedule should only start from this date, as if there was a fixed milestone preceding the project.
* Resources cannot be charged to the project before the specified date (as with a project under construction). 
* This option must be enabled in the :ref:`global parameters<gp_planning-section>`.






.. _project-reserve:

.. index:: Project (Reserve)

Project reserve
***************
   
Project reserve is an amount reserved based on identifying :ref:`Risks<risk>` and :ref:`Opportunity<opportunity>`.

It calculated from contingency reserve of risks minus potential gain of opportunities.

ProjeQtOr uses a technique as "Expected monetary value (EMV)" to convert risks and opportunities into an amount.

The amount of project reserve will be added to remaining amount.





.. index:: Activity

.. _activity:

Activity
########

.. sidebar:: Other sections

   * :ref:`Assignment<assignment-section>`
   * :ref:`Progress<progress-section>`
   * :ref:`Predecessor and Sucessor<predSuces-element-section>`
   
   
An activity is a kind of task that must be planned, or that regroups other activities.

An activity can be:

* Planned tasks.
* Change requests.
* Phases.
* Deliveries.
* Versions or releases.

:ref:`Resources<resource>` are assigned to activities. During an :ref:`assignation<assignment-section>`, some work is initially planned on this activity for the resource.

For a resource, assigned activities are tasks in which he can entry the :ref:`Real work<real-work-allocation>` 


.. _parent-activity:

Parent activities
*****************

* Activities can have parents to regroup activities or planned tasks. 
* Activities can be sorted inside their parent activity, on the :ref:`Gantt<Gantt_chart>` planning view, using drag and drop in the list area.
* Parent activity must belong to the same project.
* When a parent activity contains an assignment with a workload then the planning mode applied does not correspond to any of those proposed in the list of planning modes.
* On a parent activity the planning mode is no longer displayed.

.. topic:: **planning example**
   
   Example with a parent activity with no load and 2 sub-activities with 10 days of load for each of the resources (analyst 1 and analyst 2).
         
   In this case, the parent activity is the result of the sub-activities that compose it.
         
   .. figure:: /images/GUI/PLANNINGELEM_ZONE_MotherActivity.png
      :alt: Mother activity without workload
            
      Mother activity without workload
            
            
   If workload is entered for a resource on a parent activity, and this resource is also scheduled on child activities, then the total of this workload will be displayed on the parent activity for this resource.
         
         
   .. figure:: /images/GUI/PLANNINGELEM_ZONE_MotherActivityWorkload.png
      :alt: Mother activity with workload
            
      Mother activity with workload
            
   The dates and durations section display the result 
         
   .. figure:: /images/GUI/PLANNINGELEM_ZONE_MotherActivityDates.png
      :alt: Dates and durations section on parent activity
            
      Dates and durations section on parent activity
            
            
   The dates and duration section of the activity shows the overall load for a resource.
         
   20 workload days = 10 workload days for Analyst A for parent activity + 10 workload days for Analyst A for activity A.   
      
   The mother activity, even if it has priority in relation to its position in the WBS, will distribute the workload assigned for the resource after the workload on the sub-activities.
         
   .. figure:: /images/GUI/PLANNINGELEM_ZONE_MotherActivitydetails.png
      :alt: the load of the mother activity is planned after the sub-activities
            
      the load of the mother activity is planned after the sub-activities
         

.. _activity-planning:

Activity planning
*****************

* :ref:`Tickets<ticket>` can be linked to an activity (task).
* Work on tickets will be included in the activity.

 .. compound:: **Assignment of resources to task**

    * Resources who will work on the ticket doesn't need to be assigned to linked activity before.
    * The assignment will be automatically created once that resource has entered the working time (real work) in the ticket.
    * The assigned task and the sum of working time entries by resource in tickets will be available in its timesheet.

Traitment
*********

.. rubric:: Fix planning 

* When box “fix planning” is checked, the activity scheduling won’t be remade.
* This will avoid change on planned values.
* The planning will always be the same whatever you do on other projects.

.. warning:: This may lead to dependencies unconsistancies


.. rubric:: Filter on list

Ability to filter activities by data or type, for instance by assigned resources

.. rubric:: Monitoring indicator

* The indicators can be defined in the :ref:`List of Values<list-of-values>`.

* See: :ref:`health-status` and :ref:`overall-progress`

 


.. _test-session-planning-element:

Test session
------------

   This planning element is a specialized activity aimed for tests.
   
   A test session allows to define a set of test case that must be run to meet a requirement. 
   
   It can grouped other test sessions or be a task. This allows to define the structure of test sessions.
   
   Dates, works and costs of test sessions (child) are summarized in the test session (parent).
   
   A task is assigned to resources for to be performed.


   .. seealso::
      
      :ref:`test-session`




.. _milestone:

Milestone
#########

.. sidebar:: Other sections

   * :ref:`Progress<progress-section-milestone>`
   * :ref:`Predecessor and Sucessor<predecessor-successor>`   
   
A milestone is a flag in the planning, to point out key dates.

Milestones are commonly used to check delivery dates.

They can also be used to highlight the transition from one phase to the next.

ProjeQtOr offers two types of milestone:

**Floating milestone**

* This milestone will automatically move to take into account dependencies.

**Fixed milestone**

* This milestone is fixed in the planning, not taking into account predecessor dependencies.
* This kind of milestone is interesting, for instance to set-up start date for some tasks.
* Fixed date is set by validated date.


.. rubric:: Monitoring indicator

* The indicators can be defined in the :ref:`List of Values<list-of-values>`.

* See: :ref:`health-status` and :ref:`overall-progress`




.. rubric:: Section Details

Items related to the milestone (target milestone) are displayed in the table.


.. figure:: /images/GUI/PLANNINGELEM_ZONE_SectionDetails.png
   :alt: Section Details
      
   Details: item linked

 
* Contains the list of :ref:`product versions<product-concept>`.

* Contains the list of :ref:`Requirements<requirement>`.

* Contains the list of :ref:`Tickets<ticket>`.

* Contains the list of :ref:`Activities<activity>`.



.. _dependency-planningElement:

Dependency
##########

   Dependencies allow to define the execution order of tasks (sequential or concurrent).
   
   All planning elements can be linked to others by dependencies.
   
   There are several types of dependencies that allow to start and/or finish before/after another element.
   
   Dependencies can be managed in the Gantt chart and in screen of planning element.
   
   A delay can be defined between predecessor and successor.

   Several types are available:
   
   * |DependancySS| **Start to Start**: second activity cannot start until the first activity has started.
   
   * |DependancyES| **Start to Finish**: first activity must be completed before the second activity can begin.
   
   * |DependancyEE| **Finish to Finish**: first activity must be completed before the second can be completed.
       
   Anyway, the successor can end before the predecessor. Note that the successor "should" not end after the end of predecessor, but in some cases this will not be respected:
       
      * if the resource is already 100% used until the end of the successor
      * if the successor has another predecessor of type "End-Start" or "Start-Start" and the remaining time is not enough to complete the task
      * if the delay from the planning start date does not allow to complete the task.

   .. seealso::
   
      :ref:`Dependencies<dependencylinks>`
      
      
.. _meeting-planningElement:
      
Meeting
#######

   This planning element acts like a fixed milestone, but it's a task.
   
   Like a milestone, a meeting can be a transition point. 
   
   But also, like a task because it's possible to assign resources and planned work.
   

   .. seealso::
      
      :ref:`meeting`      