Resource Skills

​@James Bonfield we have tried to go down the path of using skills in Planview a couple of times but these are the things that caused us to not stick with it:

1. Sometimes we have a matrix of skills...resource A has the skillset of Design Thinking but only for Product A
   1. When we tried to build this in the skills attribute we found that if we needed both details then it was a long list of skills to encompass each product, maybe even customer. 
   2. This matrix of skills was not easy to incorporate, or we couldn’t find a low maintenance way to do it at the time. 
   3. We wanted some dependencies...if I choose skill A then my list of values in the next attribute should be limited. There are some capabilities of this in PV but we didn’t go down that path due to how that would then look on requirements. 
2. RMs were not good about re-evaluating the skills each year, or semi-annually. 
   1. Our data seemed to be outdated. 
3. Different business areas wanted to label skills different...or what is a skill vs a job (i.e. Project Management vs Project Manager). 
   1. We tried to implement consistency across the company but due to this the list of skills became so long. 
   2. We even tried stating what kinds of things are not needed as a skill but getting RMs across the business to agree was difficult.
4. We thought about having resources do self-evaluations and populate then RMs review but that required custom reporting to identify recent changes that an RM would have to manage and then if they did not agree go back and change it back. (sometimes people feel they are SMEs but others may not want to categorize them in that way)
5. When we did pilot this with a few groups the RMs ended up not using the information because they were close enough with their team to “just know” who would be the good fit. 

What I learned as an Admin is that if the skill list isn’t already aligned across the company, then there is a lot of effort up front to try to align what should or shouldn’t be in the list.  Do you only do core or technical skills and leave out soft skills or do you put everything under the sun on each resource, which adds to feeling overwhelmed when doing periodic reviews for up to date information. 

Also, if you are going to align a proficiency rating to the selected skill be sure those proficiencies (aka quality ranks) are defined clearly.  One manager may feel the resource is novice but the resource, or another manager, may feel they are competent. (we had limited, competent & SME as our scale)

If skills were more clear cut then it could be beneficial for some companies, however for us it felt like the capturing & utilization of skills in Planview is too basic and a lot of work that did not provide enough ROI...or we made it to complicated with our scenarios. ;-)

I don’t say this to scare you away, in fact would love to hear back from you if you go down this path and what allowed it to work for you. 

Best regards,

Pam Sargent

NASCO

Thanks very much ​@pamela.sargent - I’ll take this into consideration!

It sounds like some of the challenges we’ve faced elsewhere on the system which have only made maintenance and data alignment a real challenge.  

The advantage we may have this time is that for a number of core roles & business areas, skills and proficiencies are already captured to a common standard. I’d be looking at the practicalities of integrating into this data, but still suspect the list of skills will be a long one!

Regards,

James

We have had good success focusing on automation using the API’s.   By connecting our Workday (HR Data) Server to our Planview data using the SOAP API’s we are able to keep both both the employee information from HR up to date in Planview (Written in Python).   I run a script daily to synchronize the two datasets.    Not only does this create/terminate the resources in Planview, but it also keeps skills and team assignments up  to date.    

We went down a different approach and instead of using skills, we were interested in the  The amount of contribution a resource can contribute to the work.   We standardized effort contribution on the project to an experienced employee = 1 FTE.   We then know roles like Senior Manager for instance would not work on the project directly and a junior person would not be as efficient doing the work.   A model was created based on the type of  resource on the team.      Using the business card title, I was able to determine the amount contribution to expect from a resource.

Table #1

Senior Manager = 10%  (.1 FTE)

Manager = 20% (.2FTE)

Senior Lead 150%   -- (1.5 FTE)

Individual Contributor -- 100% (1 FTE)    

Junior -- 50% (.5 FTE)

Table #2

   oData pull for team resources with business card title.   Using the business card title classify each resource with a matching value in Table #1 using decoding key works like Manager, Senior Manage, team Lead.

Last, multiple the 2 tables together to get the expected contribution of the team.    The output is then loaded are resource Requirements to Planview by providing org and a baseline taken.   Now timesheets are used to judge plan vs actual.   A byproduct is we get the cost of development vs Plan.     This method allows for accurate forecast of a team ability to do work and the measurement of the plan vs actual.