Hi Sarah, that's a loaded question but I'll give it a shot:
Define your operating model. Describe what you do and what you don't do in it. This might translate to your service catalog. Describe how you are to be engaged. Ask your users to complete your Business Requirements. I've attached my example.
Document the never-do list and update it as you make mistakes, which you and your team will. Some of mine include never bulk edit other groups, roles or teams without fully understanding the impact. Never delete queue topics without knowing the impact. I'm sure there are some others the community can ( and should! ) share.
Build a "Workfront Support" request type and log everything as a request/make your requesters use the tool and work the request in Workfront. If you can't use the tool as a team, you'll never be able to convince your users it'll work for them. If you don't force them to use the tool, they'll never stop emailing you requests for modifications. Keep this simple but ensure that you know what each request is for, perhaps in a single drop menu on the form with (Custom Form, Template, Users Edit, etc.) As you mature, expand your selections and fields when you identify the need. Try new things! If they don't take hold, don't force them, delete them.
Have a clear intake process for new requests. Document and socialize what the process is for each type of request. For example, half of your items might be quick BAU items that can be worked as issues but configuration changes might require conversion to a project with a sequence of tasks. Document this in a table somewhere. Something like this:
Use the tool to manage your work. Build dashboards that show you all of your team requests so you have a clear understanding of your team work. "https://community.workfront.com/discussions/community-home/digestviewer/viewthread?MessageKey=8ae9dbff-25f1-4abe-ac7a-64ff43f764da&CommunityKey=aaafaff0-5e4e-4e38-8903-f1f990935567&tab=digestviewer#bm8ae9dbff-25f1-4abe-ac7a-64ff43f764da">See my post here on the topic . Always communicate in the "Updates" tab. If your sidekick admin can't pick up your request at any given moment and sort out where to pick up where you left off, you have a problem.
Check each others work, show them what you've done to solve a problem, read their updates, look at their documentation, etc. Do this every day. Drop in on each others work and collaborate.
Make changes in a Preview or Sandbox environment before going to production and make your users sign off. As you make a change, document what you did in a release notes.txt file and store it with the requests. This will make the release to production much easier to perform.
Create "Administration" reports that you can share with everyone involved in changing Workfront. Let them see the core configuration so they can help determine what changes are needed. Run these reports with the access rights of an "Admin Service Account" to ensure that users aren't limited in the data they see. Use this service account so that if the owning admin user leaves the system, the reports don't break. These are the must-have reports that we use:
User Lookup (add prompts) - Allows you to lookup users and see all of their profile configurations and make edits quickly.
Custom Field Lookup (add prompts) - Allows you to easily find and change a custom field.
Queue Topics Lookup - Find topics and see the configuration for editing.
Template Lookup
Report Lookup
Statuses - Create a "Status" catalog report if you're using custom statuses and decide now if you want issue/task/project statuses to be synchronized. Educate yourself well on group-based statuses early or you'll possibly end up with a mess.
Share your "administrative" views, filters and groupings with your admin team and give them manage rights.
Request Types - If you're publishing request types and queue topics, setup your "Request Type" projects so that they're stored in a "Request Type Management" portfolio and make sure that routing rules route the issues to "Target Queue" project stored in a "Queue Management" portfolio. If you don't route issues to different projects, you'll run into issues with sharing.
Own Reports and Dashboards if you can or limit it to a select few. If you open up report/dashboard creation to everyone, you'll spend significant time helping others determine why their thousands of reports are broken.
I'm sure I'll think of more and will try to return to this thread with them as I do. Narayan Raum Workfront CoE Manager & Delivery Lead SunTrust Bank
