Generic Resources as a feature of the Project Server solution are a well-established concept, not only can they be assigned to tasks in Enterprise Template schedules they can also be used in Portfolio Analysis to identify “Resource Deficits” when considering a mix of projects arising from a Portfolio Analysis selection.
As with “real” resources Generic Resources can be invested with many of the same attributes, both native resource fields such as Group* and Code and any custom Enterprise Resource fields that you may have defined including the RBS attribute.
The real value of Generic Resources lies in defining Resource Fields with associated Lookup tables where the field is used for matching Generic Resources. Whilst it is possible to create more than one field that includes the option for matching Generic Resources you should be careful in doing this as you can end up creating problems for yourself as any Generic Resource may have to exhibit values in two separate fields that are used for matching purposes. This could result in you having to define “permutations” of Generic Resources to model all potential combinations expressed in two fields used for matching purposes. I encountered one occasion where there were 3 resource fields that had been defined for matching Generic Resources and two of those fields allowed multiple values to be selected from a list of more than twelve available values, we lost count of the potential number of permutations before it was decided to exclude two of the less important fields from being available for matching purposes. Whilst they were excluded from matching they could still be used for querying Resources with the primary query being achieved by “Match” feature and secondary attributes queried using additional manual filtering in the “Build Team from Enterprise” dialog box.
The Resource Fields employed in such circumstances would be available to match/query in the Build Team from Enterprise Dialog box but it would be an “elective” process whereas if a field is defined as being used for matching it is a “mandated” element of the process. An illustration of the “elective” querying available in the “Build Team from Enterprise” dialog box is shown later in this article.
Note – whilst a Generic Resource should only have one value from the field used for Matching Generic Resources real people could exhibit more than one value so the “allow multiple values to be selected from the look-up table” option should be selected as well as the “Use this field for matching Generic Resources” option.
A further consideration for Generic Resources may be how many of them are there? This may sound a bit obtuse but it is worth exploring.
I would always suggest that you set the “Maximum Units” for a Generic Resource to be 0% as they represent demand but cannot satisfy that demand, this will result in “ROG” indicators (Red Over-allocated Guy!) appearing in a schedule which is no bad thing during the early stages of assembling a schedule. Setting Generic Resource “Maximum Units” to be 0% also avoids a misrepresentation of capacity being encountered. I have seen instances where “Maximum Units” for Generic Resources have been left at the default 100% figure and some OLAP based reports have then significantly overstated capacity as the calculation has included both real people and Generic Resources.
In this illustration we can see that due to Generic Resources being defined with 0% maximum units they can appear in a report but show no availability or capacity.
I have seen some instances where the “Maximum Units” for a Generic Resource has been set to a value of 800% or even more as there 8 or more resources of that type in the organisation. Whilst this may represent a true figure “in-Toto” the problem with this approach is that no human being could satisfy demand on a task where a Generic Resource has been assigned at more than 100%, for example a simple task might involve 4 Developer Generic Resources so the unaware might simply assign Developer Generic Resource at 400%. Sadly you cannot do a “many to one” match using the Build Team from Enterprise Dialog box and replacing a single Generic Resource assigned at 400% with a single real resource will result in the replacement resource being hugely overloaded.
The answer is to create iterations of your Generic Resource, for example to represent demand for any one of 8 available developers we would create Generic Resources Developer 1, Developer 2 etc through to Developer 8. Each one of the Generic Resources would hold the same Role or Skill value and as such when conducting “Match” using the Build Team from Enterprise Dialog box Generic Resource Developer 1 would be a match for any of our 8 real developers as well as for the other 7
Generic Developer Resources 2-8. If you had a project where 4 developers were required your Team would initially comprise any of the available Generic Developer Resources who could in turn be a match for and replaced by any of the real developers in the organisation.
Creating numerous Generic Resources of the same type is a relatively easy process, best performed in the Resource Sheet in Project Professional, and as they are Generic Resources there are no licence implications as they are not “real” users of PWA. Matching using any one of a number of such resources will result in it, the other iterations of the Generic Resource and real people showing as being a match for the Generic Resource.
A further interesting variation arises when a resource field for matching purposes has been defined with a “competence” element.
For example a skill might be SQL Developer but within that there are competence levels of “Expert, Competent or Novice” – a Generic Resource might exhibit a value of SQL Expert whereas real people might exhibit a value of SQL Expert, SQL Competent and SQL Novice or SQL Competent and SQL Novice or just SQL Novice meaning that the expert would appear if you are searching for a novice, whereas someone who is just a novice would only appear if you were searching for novices only.
In the following illustration I have created Generic Resources to represent these competencies or skills whereas in real life they would simply be “additional attributes” of real people and would be available to query using the “Customise Filters” option in the Build Team from Enterprise dialog box.
In this example searching for CSHARP Novice competence results in 18 resources being found, note this population does include all 3 Generic Resources. Searching for CSHARP Expert however delivers a smaller population.
When searching for CSHARP Expert a population of just 5 resources, including the single Generic Resource for CSHARP Expert, is found.
Establishing and maintaining a “Skills Matrix” of this type can be a bind to begin with and should be reviewed on a regular basis to reflect changing experience and skillsets. As it is likely to be a subjective measure as well it may also be an idea for the resources themselves to grade their ability levels in order to avoid potential issues with “Data Protection” and prejudicial information being maintained by the organisation. Such values can be reviewed with a line manager to achieve consensus. You may also need to consult your HR function when assembling this sort of data just to be safe.
If you are going to record differing skill-sets for resources the “Cost Rate Tabs” can then be used to reflect differing values for differing levels of competence. So a person who is an expert SQL Developer and also a Competent C# developer could have different rates for these two skills. In each case the rate would need to reflect the highest level of competence exhibited by the Resource. As a result you might need a competent SQL Developer but be assigned an Expert, whilst the work may only merit a competent developer the expert developer rate would apply.
Maintaining a skills matrix can on occasions result in abuse. A results focused project manager might well look to recruit experts in all areas to ensure project success whereas resource managers may well want to give resources the opportunity to up-skill and as such might propose a less competent individual for a particular project in order for them to acquire new levels of competence.
If a project is populated with some resources where their being part of the team develops their competence then using “Work Contours” can be a way of accommodating the fact that they may not “hit the ground running” on some of their assignments, a “back-loaded” work contour will result in a task taking longer than originally scheduled and can represent the gradual accrual of improved competence on the task over time.
One last area where the “Match” option in the Build Team from Enterprise Dialog box can prove useful is in identifying skills gaps. Your resources may in some cases exhibit a unique blend of skills, if you were to lose them do you necessarily have a “like for like” replacement – selecting an individual like this in the Build Team from Enterprise Dialog box and then clicking the “Match” button can reveal if they do have any equivalents in the organisation and if they do not may identify areas where skill levels need to be raised.
In my next article I propose exploring options to model “Matrix Management” whereby Project Managers can express demand for resource in their schedule but do not have the authority to recruit (match and replace) named individuals for assignments in their projects.
* As an aside the default “Group” field for resources presents a problem in that it cannot be edited when editing Resource Information in the PWA client browser. We experienced this recently with a customer who wanted to use this “native” field. Having asked the project server community we have arrived at the consensus that as this is a native field and pre-dates the arrival of Project Server that it is very much a “legacy” resource attribute and as such does not offer the potential of Enterprise Resource Fields incorporating look up tables or other custom attributes.