Skip to main content

I’d be keen to hear from any Planview customers who have particularly complex Role hierarchies and Rate cards to understand how you cope with all of the day to day maintenance.

We have around 10,000 resources, split across 350+ roles with a constant demand for more to be added. Associated with this is a need for more accurate cost recovery, so an ever-increasing number of rate cards which would potentially run at an individual level or using multiple attributes which Portfolios doesn’t appear to support. Combined with a constant churn or individuals between roles and timing impacts of when individuals can move roles without impacting their timesheets, this is becoming a challenge which will ultimately be unsustainable.

With the benefit of hindsight I think it’s fair to say we may have structured our resources differently to limit/standardise the number of roles and that’s currently under review, but what I can’t understand is how we can address the Role and Rate management in a way that won’t require a significant number of additional System Admin roles just to manage the resources.

Does anyone have experience of managing this scale of resource pools, and if so, how have you managed to balance the need for accuracy/granularity over the admin overhead?

It would be good to hear from anyone who has:

  • Created innovative ways which allow Resource Managers to manage rates
  • Injected extra bodies into the Admin team exclusively to manage Resource config
  • Established processes to upload roles and/or rates into Portfolios from external sources 
  • Managed to work with the OOTB functionality and large resource pools whilst supporting the need for constantly changing Roles & Rates data, without the need for a massive Admin injection!

Hi James,

There is an option to handle this via web services. Planview provides several dedicated services specifically for managing rate cards. Additionally, you could implement an interface that manages rates based on data from an external source. These solutions are definitely feasible, though they do require engagement from the GIS team in Planview, which can be a costly process. That’s why web services remain the most affordable and straightforward option.

This approach also means that Resourcing Managers wouldn’t need to be responsible for managing rates manually, as the process could be automated. However, the admin team should still manage and own this process. They not only have the necessary permissions but also a broader oversight of what’s happening within the system, ensuring consistency and control.

We’ve implemented this kind of solution ourselves and found it to be an effective way to reduce manual workload while maintaining accuracy in rate and role management.

Regards

Michal 

​@James Bonfield at NASCO we did what Michal described utilizing web services mixed with some creativity while utilizing internal technical resources who could help build our solution without large engagement with the PV team. 

Are all of your rates just based a role name or do you have roles by a grade level?  We have a little of both but part of our solution was having a rate set that we set the rates by grade level and then utilize web services to update the role rates in the primary rate card based on the grade level identified. 

I feel we are overly complicated with our processes as well and utilizing the web services, with a few custom process steps, the admins rarely update rates aside from annual rate updates.

Hope this helps. Best of luck

Pam Sargent

Thanks for this ​@pamela.sargent .

Our roles are (in my opinion) unnecessarily complex and rates are highly variable - each of our business units have control over the rates and recovery expectations, so we have similar roles across the organisation demanding rates based on different parameters. Some are satisfied with a single blended rate for the role for that specific team - easy enough to manage.  Others want differing rate cards based on location, grade, skillset etc. 

I have a challenging task to re-educate my community and get them to consolidate around a simpler role structure - I need to get them to accept that roles don’t have to be the same of Job titles and they need to give up some of their legacy naming conventions, so not expecting that to be an easy task! At the same time I’d like to exploit more of the resource attributes so we can retain or enhance granularity of the roles but not within the role title. 

As far as the rates are concerned I really feel for both our Admin team and our Resource Managers, but I can’t satisfy both at the moment. We can phase in rate changes and forward date, but the process is really inefficient, made that much harder with a large number of rate cards, the admin overhead is huge.

The way we have our timesheeting and progressing engine configured combined with our financial calendar and PV limitations means that role changes are currently undertaken manually in the window between month end and the first progressing engine run of the following month - that may be as little as a day so lots of pressure on out Admin team. 

I’d really like to get to the point where I can support individual rate cards per resource and give the responsibility to maintain these to the Resource Managers without Admin intervention - that would make everyone happy but it looks like we’ll need to explore web services and in-house solutions to support this kind of capability

​@James Bonfield If you haven’t already, I would encourage you to speak with a Technical SME at Planview to see what can be done creatively via web services.  If you have the identifying attributes on a resource then maybe there is a view that can be created to help with capturing the individual calculations and then those can be added to your rate card. 

We have individual rates on some resources, although one resource cannot have multiple rates (though I think there is a setting in PV that allows that), and we utilize web services to create the rate card for the individual within our rate set. We have a technical person in house but they worked closely, via a Planview RAS, with a Planview SME to help come up with our solution. 

I do wish you the best and definitely feel for your Admins. Managing rates in PV is probably my least favorite thing as an Admin.

Reply


Terms of UseCookie settings
All Data Subject Access Requests (DSARs), and requests of “Do Not Sell My Personal Information” according to the CCPA, must be submitted through the Planview DSAR portal located here

Planview has appointed a Data Privacy Officer (DPO) to be responsible for overseeing our Privacy Management Program and related privacy compliance measures. DPO can be contacted at privacy@planview.com