General principles

1 - Essential and ancillary tasks

A task represents works in the project and has a non-zero duration.

We often find in a project tasks to realize on a priority basis, and other tasks either distributed throughout the project (project management, support) or to execute if there is time available ... With traditional project management software that put all the tasks at the same level, these non-priority tasks are likely to appear as the critical path, and to have a proper schedule you will ignore them or cheat on their data .. . This can lead to forget work, misjudge the charges ...

This is why I have provided two types of tasks: the essential tasks that are only taken into account in calculating margins and critical path, the end of these tasks is the essential end of the project, and other tasks called ancillary which are not taken into account in margin calculations. This causes that an essential task can not be dependent on an ancillary task.

2 - Events

Unlike tasks events have not work to do and have no time. They may represent steps of the project, objective dates that we want to show in the schedule, or be intermediates in the definition of links between tasks.

There may be links between tasks and events and for that I have provided two types of events: the essential whose may depend essential tasks, and ancillary.

Events do not represent work and are therefore transparent in the margin calculations, their possible displacements are not taken into account. However if they were set a fixed date, margins are calculated not to move that date fixed.

3 – Decomposition in levels and groups of tasks

When a project exceeds a few dozen tasks, it is recommended to do a tree with several levels, and for this tools are available such as the Work Breakdown Structure (WBS).

Planning of such project raises philosophical problems depending on whether we favor top-down or bottom up, and we prefer distribute or consolidate margins.

This program is not aimed at large projects, the task decomposition in levels has not been retained.

However to facilitate entering and presenting data, we can define tasks groups or groups.  They are tasks or events grouping (only one level is allowed, a group cannot contain groups).

A group has a beginning, and all tasks or events of the group must begin after this beginning. A group ends when all its member tasks are ended and all its events were reached.

A group can be defined as essential or ancillary. An essential group can only contain essential members, and an ancillary group can only contain ancillary members.

4 - Links

The most commonly used links are links from the beginning of a task after the end of a task known predecessor. These links have been defined as simple links, and their entry is easier. However you may define other link type: begin to begin, end to end, end to begin. For each kink, you may define a delay.

The program allows to have for a task, a group or an event as many links  that we want with predecessors task, group or event. However there are limitations:

You have to note that when you put for a group, end to end, end to begin or end to date links, the group end may be after the end of all members of group.

To facilitate the definition of links the program will provide the list of items (task, group or event) selectable as predecessor, and you will make a selection from this list to define a link

In a link definition we can define a delay in general positive. The program allows to define a delay in a whole number of working days for each link, and can have positive or negative numbers, which can sometimes be useful.


5 - Durations

All durations are whole number of working days. In most cases, estimates are not precise enough to require fractions of a day. For simplicity, the program only supports integer number of working days, both for the duration of the tasks and for the delays and margins.

6 - Not Worked days

Durations and delays are expressed in working days, it must known if the day will be worked or not worked during the project to define the calendar dates.

The program has planned to define in the preferences days worked and not worked for all future projects, taken into account when creating the project, and to be able to change these days in each project.

These not worked days are usually Saturday and Sunday, and a number of legal holidays.

To simplify the work of defining the calendar, it was provided a mechanism taking into account holidays. Unfortunately these holidays vary from country to country and even in some countries with different regions or states. This is why it is provided a base that will allow each user to define its non-working days depending on local regulations and customs.