Have you ever tried to allocate down to the skill level or considered changing your company's fiscal year? We take on those topic and more in today's Q&A.
Q&A
1. Estimate from Allocations is Missing
2. Clarity Auditing: OOTB Vs Custom Object
3. Changing Your Fiscal Year
4. Allocating Down to the Skill Level
5. The Maximum Allowed Result is 100,000 Rows
Please feel free to comment on any alternative answers you've found. At Rego, we always love your input.
1.
The Team tab has an action that allows you to update ETC, based on a change in the allocation percent (found in the resource properties from the team tab). This action is called Estimate from Allocation. It appears to be missing from the 14.2 Team tab Actions menu below.
I double-checked the Actions Menu to make sure it's selected:
Then I found a knowledge base article on this issue that indicates the system is down for maintenance. Being impatient, I’m wondering if anyone has found a way to put Estimate from Allocation back on the Team tab Actions menu.
Answer 1
This action will only show up on projects which have a single effort task (~rmw). If the project has a complete WBS structure with many task assignments, this job will not be available as the job would not know how to perform the split.
Answer 2
I believe this is usually a link to the Job: Update Estimates from Allocation, which requires that the project/NPIO, have an Effort task – id = ~rmw.
If there is no effort task on the Project, I think this won’t display in the list. It would make sense, since you normally, on NPIOs, don’t get to see the Task tab and therefore can’t set the ETCs directly.
You can test that out. I may very well be wrong.
2.
I'd like to use a process to track down interface changes. Do you have details about Clarity Auditing OOTB versus a Custom Object?
Answer
There were two times I had to use a custom object to hold audit information:
1. Tracking information on who approved action items and when.
2. Tracking audit information to cater to a complex portlet requirement displaying audit information.
I would not usually suggest using a custom object, but if you really cannot use the OOTB audit info, then you do not have much choice. With a custom object, you will have to create a purge strategy, which includes anticipating the quantity, level, and number of days the custom object will hold data.
3.
We've set our fiscal periods, but now we're changing our fiscal year. What's the best approach?
Answer
Changing fiscal periods is not easy. I’ve had many clients ask about it, but none actually moved forward after they found out what’s involved.
Here's why. The user interface around fiscal periods is complex. You have to use SQL to change periods. And if you're updating financial plans, the fiscal time periods will render the financial plans incorrect.
Part of the difficulty is a blob, where the fiscal period detail on cost plans is stored. Changing the fiscal periods through SQL will not adjust the details stored in the blob with the new dates of the fiscal periods. However, if you don't have cost plans, this isn’t an issue. You can use a simple gel script to adjust your fiscal periods. If you do have cost plans, there are some options below. (Note: for On Demand the options are more limited.)
- Update the fiscal periods and accept that your cost plans will be inaccurate. The totals will be accurate, but the costs by fiscal period will be incorrect. PMs will be responsible for creating new cost plans on their projects.
- Update the fiscal periods and write a process to XOG in new cost plans. This will not be an easy process to write, and will leave old, incorrect cost plans in your environment.
- Update the fiscal periods and write a process to update your existing cost plans. Again, a difficult process, and it will not update any budget plans in your environment. Budget plans cannot be changed, even through XOG.
- Update the fiscal periods and write a process to modify the blob data in the cost and budget plans. This is the most difficult and risky solution. It would be the most accurate, but we don't recommend it.
4.
Have you seen companies allocate down to the skill level (as opposed to the higher role level)? We want to know how much a resource is available, by skill.
Answer 1
Really there are two choices:
a. Revise role to include skill and role. Then the role/skill can be used in OOTB portlets.
b. Rego has an offering for “primary skill” in regoXchange with a bunch of portlets and processes. The field goes on resource and team. We also have a process to push from resource to team, and we have portlets to show capacity by role and then skill.
Answer 2
I think the best way to do it is based on a roll and replacing the role with a named resource. Assuming the resource is only allocated once for the project (for that specific skill), you should be able to allocate based on the project role (for whatever that skill might represent. You would need to have portlets and other reports set up to really be able to analyze the data though.
Answer 3
I have seen a lot of organizations look at roles/skills in different ways, but attempting to Allocate at the skill level is not recommended. Everyone (or nearly everyone) has multiple skills. Attempting to look at Allocations at a skill level will make it look like you have far more capacity than actually exists, not to mention confusing your data. If a resource is skilled in both SAP and Web development, do they have 40 hours of availability in both? 20 hours in each? It can make your head explode.
If there are truly critical skills that need to be closely managed, then those should be built into the Role, e.g., Developer-SAP, not just Developer with a skill of SAP.
And if needed skills are used in the project set-up (using the Properties on the Team Tab) then you can see overall demand and usage of skills across the organization, but the formal Allocation is against the Role. And reporting can show where a shortage of particular skills exist.
5.
Is it is a SQL Server setting causing this or a clarity setting: "hit the maximum allowed result of 100,000 rows." We have over 100,000 resources in our system, and the adoption metric process pulls all of them monthly.
Answer
This is actually a gel script select query limitation, unlike the excel export and NSQL governors that can technically be modded via the database. We don't recommend changing this setting, as it will impact performance. To get around this limitation, retrieve your data in smaller batches.
Thank You------------------------------
A special thank you to Jenn Rinella, Christopher Flanagan, Sankhadeep Dhar, David Matzdorf, Rob Greca, Michael Meyers, Josh Leone, Juan Ortega, Ram Iyer, and the Rego Team for this Q/A material.
