What’s new? v4.68 – Managing positions

v4.68.0 — Project positions At kickoff, a team is usually a list of roles (“an architect, two developers, an analyst”), not of people. Since 4.60 a task could request a profile, but that profile didn’t exist as a project member: it didn’t appear in Members, had nowhere to carry its rate and there was no one to…

v4.68.0 — Project positions

At kickoff, a team is usually a list of roles (“an architect, two developers, an analyst”), not of people. Since 4.60 a task could request a profile, but that profile didn’t exist as a project member: it didn’t appear in Members, had nowhere to carry its rate and there was no one to replace.

* The profile is now declared as a team POSITION, from the project’s Members. It appears marked as “Position to be filled,” tasks can be assigned to it and it counts toward the budget from day one.

* The position carries its cost and billing rate for THAT project, and the project lead sets it. This is the missing piece: until now a profile’s rate could only be changed in the instance catalog, which requires administrator permissions. Two different things are now separated: which profiles exist is still an administrator’s decision (it’s a firm-wide taxonomy, and if everyone invented profiles, no cross-cutting report would mean anything), and what this project pays for that profile is decided by whoever runs the project. The position’s rate overrides the catalog’s. If left blank, the catalog’s is used; entering 0 means “this profile costs me nothing,” which is different.

* Replacing the position with the real person takes one click. The person steps into the position: they inherit the agreed rate, the profile and the notes, and the tasks that requested that profile become theirs — you’re told how many before it happens, and it can be undone. If the person was already a project member, their membership isn’t duplicated, and a rate someone had already entered for them isn’t overwritten.

* A catalog profile’s rate can now be edited. Before, it could only be entered when the profile was created, so an existing profile —the seeded ones or those that come with the industry packs— could never get a rate, short of deleting it and creating it again. You declare one position per profile and project. Tasks point to the profile, so two positions with the same profile would be indistinguishable when filling them. The PMO manual was also brought up to date: the resource request section said assignments go only to people (since 4.60 also to a profile), and the list of data in a request included allocation per project, which the system doesn’t track — capacity is a single number per person across all their projects. This is now stated next to the table instead of in the fine print. Updating doesn’t turn anything on: no position is created in any project and no existing member changes. They have to be declared by hand.

← Back to the index