Twproject was built to work in various environments, countries, and ways of working. In this section, you can configure many of these aspects. Below you will find information about:
User defaults, Project defaults, Project mailboxes, Calendar and holiday settings, Definition of multiple calendars, and their effects on resources and interfaces!
User defaults
Here are “defaults of default” or defaults when a user does not have her/his own.
Project defaults
Twproject sometime uses default values:
Twproject allows you to create and rename roles. Using Project manager, Worker and Customer role names you can tell Twproject what role it should use.
The same for the Scrum related roles.
Total working hour per day (that is used to convert days estimation in hours estimation) and milestone alert delta (how many days before the milestone date the “milestone approaching” event is raised).
You can set progress to 100% automatically when closing a project.
By default codes used for projects, projects, ToDos, resources are not unique. You can force the uniqueness of codes.
Twproject can generate unique codes from project types: if you select a project type, didn’t type a code, and enabled the “generate codes” option above.
Project mailboxes (e-mail)
This feature considerably expands the management possibilities for anyone handling helpdesk like situations. You can now have multiple “background jobs” running in Twproject that check several e-mail accounts (say, one per main project) and create ToDos for incoming e-mails.
Activate here the service by associating an email to each project, and then adding a configuration line here. You cannot use the same email address for multiple projects. The priority of the ToDo created will be taken from the e-mail.
Some hints:
“port number”, leave -1 for default values: e.g.: pop3=110, pop3s=995, imap=143
“public” means that everyone can send ToDo (via e-mail) to the project, regardless the sender is a Twproject user.
Otherwise only users with ToDo write-permission on that project will be able to add ToDos.
“active” means that ToDos will be imported (alias: mail will be downloaded) only while the project is open, and we are in the time scope of the project.
Calendar and holiday settings
The main and customizable company calendar is already present in Twproject, and it will now be considered the “Default” calendar, where you can define working days and holidays applicable to all resources and projects. However, it still allows setting the working hours of individual resources, including part-time employees.
Definition of multiple calendars
The development of Multiple Calendars in Twproject meets the needs of diverse organizations, such as companies with departments or branches in different countries, which may have distinct working days and holidays. It is now possible to set specific calendars for each department or branch, differentiating them from the default calendar.
Creating and editing a calendar
The system administrator can create a new calendar from the administration page, assigning it a name, description and other data that we will now see.
The calendar editor is in fact divided into two sections: the first contains the name, description, weekly working days and the ‘default’ tick.
It is possible to define only one default calendar.
Please note: the default selection operation must be done with caution as it has an impact on project durations and workloads.
A change in this respect will not directly change the task data, but on first access on the WBS or Gantt the phases will show any inconsistencies due to changes on the calendar.
The second section of the editor relates to the definition of company holidays and closures.
The first click on a cell defines a holiday with a variable date (Easter, Thanksgiving etc.), the second click sets a fixed holiday (Christmas, New Year etc.).
At this point we will have as many calendars as there are different configurations of working days at company level, whether they are determined by different types of work or geographical conditions.
Multiple calendars on resources
But that is not all: there are also important new features in the work settings section of the resource.
For each resource, the calendar to be used can be set via a drop-down menu.
If “Use default calendar” is chosen, the resource in question will use the calendar marked as default (via the tick we saw in the previous section). In this example, the default calendar is called “Default” and has an *.
An important new change introduced in this release is that for a resource, working weekdays can be defined, even if they are holidays for the chosen calendar.
This is useful for handling situations where the company generally does not work on Saturdays and Sundays but, for example, the maintenance department does.
Thus, the selected calendar provides public holidays, but working days can be defined for each individual resource.
Similarly to other work data, such as time, cost per hour, etc., the calendar is also inherited from the organisation chart unless otherwise specified.
If the calendar of a department is changed from A to B, all resources of that department that had calendar A will change to B. Those that had calendar C will keep C.
In the example in the image above, we see that the resource ‘Giulia’ uses the default calendar (which has five working days from Monday to Friday), but Giulia, in his specific case, has set Wednesday as non-working and Saturday as working.
Consequently, all interfaces that display the working calendar (such as timesheet, workload, timesheet overview, etc.) will show the non-working days specific to that resource. In the case of Giulia, Wednesday and Sunday.
Multiple calendars on projects
A further step forward is the fact that with the new version it is possible to set a specific timeframe for both the project and the phases.
A new project is always set to the default calendar. In the event of subsequent changes, the name of the chosen calendar will be shown to the right of the dates (as in the image below).
In this way, one could, for example, have a project using the solar calendar (365/365), but operational phases involving specific departments could use a 5/7 calendar.
In the event that the project calendar is changed, e.g. by adding holidays or company closures, so as to interfere with the task dates, a small alert will be displayed the first time we access the project.
Clicking on the alert will result in a more detailed message, highlighting the points where date changes generated interference.
But how do we change the timing of a project or phase?
To do this, we must use the Gantt diagram; this is because from the Gantt we can immediately see the effects of the change on dates and durations, and there is the possibility of saving at a later date, without the risk of permanently changing the data.
From the options on the project line, we can select the calendar change.
A pop-up will appear for choosing the calendar and deciding whether to try to keep dates or durations.
It is optional to keep dates or durations as far as possible. The conditionality is that there is no guarantee that dates can be kept in full (as in the case where a start or end date corresponds to a holiday for the new calendar).
If milestones or binding dates are violated, the system will send a message and will not carry out the requested change. The user must first change the dates appropriately and then make the change.
With this new version, the first time one logs on to the Gantt, a check will be made to ensure that the start date, end date and duration of the project are consistent with the calendar in use.
In previous versions, if the unique calendar had changed, the end date was simply, and silently, recalculated from the start and duration.
In the new version, dates are kept instead and durations are changed accordingly. In the event of discrepancies, we will see an alert.
If milestones had been touched, these would be highlighted, as well as for the phases that had their duration recalculated.
It is sufficient to change even a single piece of data to enable saving and make the new durations definitive.
Effects of multiple calendars on interfaces
Having different calendars on resources and projects also has natural consequences on the appearance of certain Twproject interfaces, such as the Timesheet.
In this case, we note from the bottom line that the employee does not work on Wednesdays and Sundays.
At the same time, however, the projects she works on have different timetables:
- ‘A.365/365‘ (highlighted in red) is always active
- ‘B.LMM‘ (in yellow) is active for the first three days of the week
- ‘C.MMGV‘ (in green) is active from Tuesday to Friday
Users will be able to mark their worklogs freely, while taking into account the information on the timetable of each project, also made clearer by a more comprehensive legenda.
Twproject never inhibits the insertion of worklogs (except in the distant past or in the future), but simply reports the ‘suspicious’ worklog.
For example, if hours worked are recorded on a date that is non-working in both the resource calendar and the project calendar, this will be considered a ‘suspicious’ case, and consequently reported.
In the case of views with several resources, such as the Workload, the different calendars for each resource will be shown:
Or, as in the case of the Timesheet Overview, since this includes an overall group of resources, the company calendar will be shown:
However, indications and reports from the calendar of the resources involved will appear within it.
We have seen how the use of multiple calendars for resources and projects can improve and make scheduling more realistic.