Despite the summer period, the Twproject development team has certainly not stopped and today we are releasing a new version that we are sure you will appreciate. This new release, which is free for all customers, includes an important new feature on the workload and in particular on the use of department on projects, but let’s see all the details.
In Twproject, it was always possible to assign a department to a project, but the assignment had the sole function of giving all those belonging to that department specific permissions on the project.
From today, this assignment will have even greater value.
But this release does not only include this important change, we have also significantly enhanced Twproject’s financial management, making it more suitable for highly structured companies.
Also included are numerous bug-fixes, a complete list of which can be found on the changelog page.
This upgrade is free of charge for all Twproject users and includes updates to the database. A full backup of the application is therefore recommended before upgrading.
Let us now see the new features in detail.
This important new change has several consequences.
As we have already mentioned, the assignment of a department to the project has always been possible, but the function was only to grant permissions to people who were part of the department/section (permissions are those given by the role with which the department is assigned).
Resources could not record hours worked on the department, but required their own allocation.
From today this will be possible! Being part of a department assigned to a project will give you the possibility to report directly on this assignment, you will be able to see the project and work with the to-do’s.
This major change will allow you to assign a department without worrying about who will be in charge of the activities specifically, knowing that everyone in it is fully operational.
In work environments where there are large teams and where there is a tendency to work in agile mode, it will be very convenient to have one assignment to which everyone reports.
Also, the assignment of a ToDo to a person will no longer create an assignment to the person if that person is part of a department/team already assigned on the project.
In the worklog analysis interfaces, however, the detail of the persons who reported on the departmental allocation is shown, while all analysis, control and approval procedures remain unchanged.
This is a new default behaviour of Twproject and therefore does not need to be activated.
Consequently, in all interfaces where one’s own assignments are shown or where one can record one’s worklogs, in addition to one’s personal assignments, those of the department to which one directly belongs are also shown, with the possibility of reporting on them.
If, on the other hand, a person also has his or her own nominal assignment on the same stage, the departmental one is ignored and only the personal one is shown.
Obviously, this change, which gives the department an even greater importance than it has had up to now, could not remain incomplete, which is why the optimised load calculation on the department as a whole was also added.
Until now it was only possible to view the workload of people; with this release it becomes possible for departments as well.
The workload calculation takes into account many parameters such as dates, status and type of projects, estimated assignments, planned hours through the plan and/or ToDo’s, actual workable hours net of leave/vacation/illness, hours already worked on each assignment, for each person belonging to the department. Once this data has been extracted, the algorithm tries to optimise the allocation of resources so as to obtain the most plausible load possible, based on the available data:
- Hours worked by the resource (both person and department)
- Work capacity for that day. It is the sum of the capacities of all the resources belonging to the department; it takes into account working hours (horizontal or vertical part-time) and can therefore differ from day to day.
- Total load calculated as the sum of all contributions.
Colours are assigned on the basis of the phase/project. If several resources are allocated to the same phase/project, the box represents the total of all contributions.
Unavailabilities, shown at the bottom of the bar in pale pink, are holidays, leave, etc., entered in the Twproject diary indicating their type.
For more details on the algorithm implemented by Twproject for this calculation, we recommend reading this post on resource workload.
Improved cost management
Let us now move on to the part concerning cost enhancement.
Several configurations have been included that can be switched on and off by default, giving you greater control over budgets and estimates.
The activation of the parameter BUDGET_OVERFLOW_FORBIDDEN makes the application prevent the input of financial costs, or costs arising from allocated resources, if these exceed the allocated budget. In addition, the sum of the budget distributed over the phases must respect the budget defined on the higher level.
This behaviour is intended to facilitate the financial planning activities of the project manager, who is then guided by Twproject in entering consistent estimates with the available budget for each individual project phase.
If we then analyse in detail the control exercised by the budget, we see that:
- each sub-phase cannot have a budget greater than that of the phase to which it belongs (overflow) and, similarly, the budget of a parent node cannot be less than the sum of the budgets of its own sub-phases (underflow).
- the estimated costs of a phase cannot exceed the budget of the relevant phase as well as the costs arising from the work of the assigned resources (hourly cost of the resource multiplied by the estimated hours of work on his or her assignment).
- the real costs, in turn, are subject to the control of the estimated costs to which they must necessarily refer and which they cannot in fact exceed.
- lpersonal expenses are tied to one’s personal budget, which in turn contributes to eroding the phase budget.
In order to better manage finances, Twproject shows for each node the budget allocated to all its sub-phases, if any, as well as the residual usable amount (value given by the budget on the phase minus what is allocated to the sub-phases and the costs of the phase itself).
As mentioned, by symmetry with the overflow, the underflow is also controlled, so an already entered budget may not be changed below what has already been distributed or estimated, and likewise, an estimated cost may not be lowered below the actual cost already incurred.
Two new budget management permissions have been created.
Management of resource cost per hour
Twproject has two cost per hour indications: one on the resource, the other on the assignment.
This is done in order to differentiate the cost of the employees to the company (cost on the resource) from the value with which the resource is ‘sold’ to a customer (cost on the allocation).
However, should it be necessary or more convenient to always use the cost of the resource, this new flag has been introduced, the activation of which disables the hourly cost on the allocation, which is then ignored.
As a consequence, any change of hourly cost on the resource will be propagated immediately to all task assignments with active or pending status. The display of historicised consumptive costs (worklogs) and estimates, discounted to the new cost, is also activated.
The historicised worklog cost (actual cost) is the sum of the individual worklog costs to the hourly cost of the resource at the date of entry, while the estimated cost is the historicised hourly cost, on what was actually recorded, and the current cost for the residual part:
actual worklog cost + (estimated hours – hours worked) * current hourly cost
Please note that if the hourly cost of a resource is changed, the project cost page should be interpreted by taking into account the above calculation, not simply by multiplying the hourly cost by the hours.
Management of final reports (worklog entry)
Linked to the management of the project budget, but independent of it, is the blocking of worklog entries in the event of overruns.
Once this property is activated, it will no longer be possible to enter hours in excess of the estimate; therefore, in the case of non-estimated hours, worklog entry is disabled.
In the case of assignment to a department (see next paragraph), the block is activated on the total number of hours entered by the whole team.
In the event of an overrun, an alert warns of the error and shows the remaining number of hours that can be entered.
Note that this ban does not take into account budget overruns (provided the functionality is active), but only the estimate on the allocation; this is to avoid blocking normal work activities in the event of changes in the hourly cost of resources.
The property WORKLOG_ROUNDING_TO instead, controls the rounding to ‘n’ predetermined minutes. The value 0 (default) does not round and therefore deactivates the property.
Management of cost centres
With the same aim of simplifying the management of large teams and complex projects, several innovations concerning cost centres were introduced.
Cost centre propagation
A new default behaviour means that when the cost centre on a task or resource is changed, all ‘children’ having the old cost centre are updated to the new one. If, however, a child had a different one, it is not changed.
Choice of cost centre type
Its activation involves the appearance in the cost centre editor of a new drop-down menu, the ‘type’, having only two values, project and resource, and the task and resource drop-downs will only show the respective cost centres.
Cost centre inheritance
This new custom feature has been introduced so that additional project costs inherit the cost centre from the phase, with no possibility of modification.
With this release we have introduced 5 new permissions related to phase/project management of the budget, revenue and cost centre.
The application update procedure automatically adds them to all existing roles that have similar cost permissions.
To increase security, ownership of project phases will automatically be inherited from the parent node.
Thus, if even the individual project phase will have a different manager (e.g. a junior project manager) than the main project, this manager will not acquire ownership over all aspects of the phase, such as costs, etc., by default.
Many other new features
- Kanban: added search in each column.
- Assignment list: the printout now also includes any customised fields.
- Operator loading: in the detail popup, we have increased and improved the summary information.
- Tasks with an undefined status: their progress percentage is always zero and they are not taken into account in the project progress calculation.
But all this is but a brief extract of what you can find in Twproject 7.1.007!
With this release, Twproject has made many other system improvements and bug-fixes, a complete list of which can be found on the changelog page.