Reserve Admin and KTLO Time for Resources
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2016 06:50 PM
We're just getting ready to start using resource management for the first time in Geneva and have been building out test cases. I'd like to reserve Admin and KTLO hours for a given resource so that time is reserved on the Resource Management Workbench when people are looking to book them to projects and they don't risk getting overbooked. An example would be for someone who spending 10 hours a week on Admin and has 30 hours available for project work. What would be the best way to show the 10 hours baselined for that resource? I would need to vary it by resource so that a different resource might have only 5 hours of Admin time per week reserved.
I think this could be done by setting up a KTLO project and allocating resources to that project, but we'd like to use the KTLO bucket as is in the time cards since we were advised against this project based approach during earlier Service Now meetings.
Any advice or related experiences would be appreciated.
Thanks!
Erin
- Labels:
-
Resource Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2016 06:57 AM
Erin -
What do you think about users documenting their time on the actual change, incident, etc so that you can pick up information on the configuration item or category of work they performing? Have you looked at the "time worked" field as an option on these records to generate the time card instead of using the time card application as the first stop?
All of the time cards that are generated can be surfaced up to the home page of the user so they can add incremental time from there.
This is meant to more accurately tie time to the task that is worked on and move you towards understanding how much it costs to support different services.
If you would email me at emily.mcmullin@servicenow.com, Ill send you a presentation that compares the approaches of using time cards and "time worked" entries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2016 07:36 AM
Yes, we are absolutely headed in that direction.
For Admin, I don't think we would typically have tasks available that would cover things such as company meetings, time entry, status reporting, etc. That shouldn't be a large chunk of time, but something we want to monitor since we're assuming there will be a small portion of each team member's capacity taken up by those activities.
For KTLO, my expectation is that incident tasks should always be used to collect time for break/fix work. Where I think we need something more general is for maintenance activities that we don't yet track in Service Now (i.e. requests that come in via a separate sharepoint process, maintenance file loads, etc.). That's where I'm thinking we'll need a general bucket and to reserve varying amounts of time depending on the type of work a given resource does.
We have looked at the time worked field and configured it to display during our prototype. We have run into some issues/confusion with having it overwrite what is entered in the time card grid view at the end of the week (after "Generate Time Cards" has been used to pull in the task level assignments). Also some issues/confusion in how it handled retro time worked changes when people were going back to adjust. We're wondering if it might be most straightforward to not make the time worked field available on the incident but have people use "Generate Time Cards" and just enter time in that view. Still trying to figure out how it all works and what cause the least amount of confusion when we roll out the process.
I really appreciate the responses. This is a great community!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-10-2016 10:52 AM
For tracking against them, meaning charging time, Time Cards has an 'Admin' and 'KTLO' category.
So...for forecasting/planning/assigning work for projects - you could adjust the 'Average daily FTE Hours' value for users to only be the hours they should be available for projects. And then for reporting, you can still have them assign time to 'Admin' in their time cards. Note that you can do a combination of 'Time Worked' and 'Time Cards' functionality to where the timer is running for all tasks in the system and pulls into the Time Card, but they can also do a manual Time Card for Admin, Meeting, KTLO, etc. Here's how we set up Time Worked & Time Cards and some clarification on functionality SN Time Worked & Time Card Training - 20150901.pptx - Google Drive . Hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2017 08:54 AM
We're in the beginning stages of using the Resource Management module and have a similar need for our IT infrastructure resources to plan/allocate time for Daily Admin tasks, time for Tickets, and finally for projects. Resources have different allocations for Admin and Ticket work and we want to keep that visible so the approach to remove that time allocation from their FTE available time does not work for us.
One thought is to create a Program "Infrastructure Resource Allocations" (a program vs a project as a project would show in the portfolio project list), Then create Admin and Ticket Allocation resource plans for each resource. Has anyone done something similar to create resource plans for Admin and Ticket allocations

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2017 09:21 AM
Jim,
If you create a demand/project/program and don't associate that entity to a portfolio, then it won't show up in the Portfolio.
I don't know that creating it as a program just to avoid it showing up is necessary.
Did you see my earlier post about creating a demand and tracking it there? What are your thoughts on that approach?
BTW - we are talking internally in Product Management about how to make this more elegant...