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.

New features

Department assignments

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.

Department workload

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.

Project budget

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
USE_REAL_RESOURCE_COST

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)
WORKLOG_OVERFLOW_FORBIDDEN

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
USE_DISTINCT_COSTCENTER_PRJ_RES

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
COSTS_INHERIT_COST_CENTER

This new custom feature has been introduced so that additional project costs inherit the cost centre from the phase, with no possibility of modification.

Security

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.

After months of study and implementation we are really happy to announce that a new version of Twproject has been released and it includes, among other optimizations, a particular step forward on the use of the Gantt chart.

The Gantt developed by Twproject is undoubtedly one of the best on the current market in terms of flexibility and interaction with other pages in the application. It is also one of the few that allows you to do all sorts of tests on project duration and dependencies, thus proving to be a useful tool not only when sharing timelines but also in the process of studying them.

As always, the new release will be for the immediate benefit of all our customers, who can start using the new features right away!

Dependencies in the Gantt

According to definition, in the context of project management, “dependency” is defined as the relationship between two activities in a project or between an activity and a milestone (a precise point that defines the beginning or end of a relevant phase).

Dependencies thus allow one phase to be linked to the next in a way that indicates that they are consequential.

Introduction of new typologies

Until now in Twproject, the dependencies between project phases that the user could enter were of one type, the so-called classic Finish to start (FS). This means that activity A must finish before activity B starts, or in other words, activity B cannot start before A is finished.

But as we delved deeper into this topic and also through feedback from our clients, we realized that limiting the possible relationships that exist between the phases of a project to this classic type of dependency was reductive. In fact, there are additional relationships that can develop between the activities to be performed and that have been theorized in the principles of project management. Let us look at them in detail:

The Finish to finish (FF) relationship type implies that activity B cannot finish before A is also finished. For example, if activity B is the completion of writing a book and activity A is the writing of the last chapter, it becomes clear that A must necessarily finish for B to be considered finished as well.

Furthermore, there is the case that a certain activity cannot begin before another activity has in turn begun, and in this case the relationship will be Start to Start (SS). A classic example is the project management activity (B) of a project that cannot start before the project itself (A) begins.

Finally, a very specific case is the last type of relationship called Start to finish (SF), which is probably the most complex to understand and applies only in certain contexts. In this case activity A must start before B finishes, or in other words B cannot finish until A is started. Such a scenario may arise, for example, during shift change in a manufacturing plant whose machinery needs constant monitoring. The initial shift (A) cannot be said to have ended unless the next shift (B) has already started, on pain of putting the plant at risk.

We are therefore overjoyed to announce that in the new release of Twproject we have introduced the ability to assign all of the above types of dependencies to project phases.

After creating the dependency between two phases, you can possibly change the default value represented by the FS dependency and select another type of relationship.

The application of the concept of “elasticity”

Another important paradigm shift, which makes us very proud of our work, is that we have made all the newly added dependencies “elastic.”

Indeed, if until now the assignment of a dependency established the linear succession of one activity after another, we know well that in the real world the downtimes.

That is why Twproject decided to allow the user to freely manage this elasticity.

So from now on when you enter a dependency it will be saved at first with the default FS hard type. But this classic “hard” dependency can be converted into “elastic” and with any type of relationship.

This means that two interdependent activities may also not be chronologically consequential and move apart, leaving any gaps between them, or overlap for a time, as long as the logic of chosen dependence is respected.

This is a big change in terms of sticking to the facts when carrying out a concrete project and reinforces the concept of delegation that is central in Twproject.

Imagine a project tree where a Project Manager (PM) is assigned for the whole project and then a specific one for each phase, one for the analysis(PMA), design(PMG) and production(PMD) phase, these phases are linked by an FS dependency.

The PM can define a total project duration and assign a specific duration to the phases, thanks to the elastic dependencies, he can, while maintaining the logic of the dependencies, create a lag between the phases and therefore leave to PMA, PMG and PMD great freedom of action (moving end and start data) without affecting the overall dates!

This was not possible before, since a postponement of an end date, for example of the analysis phase, would necessarily have led to a postponement of the consequent phases, phases over which PMA has no right.

Other news

But it doesn’t end there. With this release Twproject has made really a lot of improvements to the system, a full list of which you can find on the changelog page.

Here’s a sampling of them:

Revenues: a useful tool for turning an estimated value into actual revenue has been introduced to further facilitate the entry of these items.

Worklogs: filters by ToDo and by project have been added to the worklog analysis sheet, and in addition a column with the sum of total worklogs on a phase or project has been added on the timesheet.

Role security: we have made permissions on task management even more secure in relation to cost and form entry.

Agenda: various improvements have been made to the agenda, including the ability to view the duration of ToDo’s, and in addition, events entered in the agenda have been integrated into a dedicated row on the ToDo and resource planner.

So, don’t waste any time and go find out now how much these latest innovations from Twproject will benefit the efficiency of your work!

All clients using Twproject on the cloud will get the update automatically in the coming days, while those who have Twproject installed on their own servers can find the new installers here.

Tag: new realease

New Twproject Release – Assignments and load for departments

New features

Department assignments

Department workload