Expand my Community achievements bar.

Join us for our Coffee Break Sweepstakes on July 16th! Come ask your questions or share your use cases on Creative Briefs for a chance to win a piece of Workfront swag!

Taking things to the next level with Workfront

Avatar

Level 5
Hello Everyone, Well it's time to take things to the next level w/Workfront- we're going to bring on 3 additional departments w/in my division this year. My department, creative services, was the pilot group to use Workfront. When we were configuring the instance, it was a bit overwhelming to try to configure in a way that was universal to the entire division because you don't know what you don't know at the beginning, and we were just trying to get our own MVP up and running. So- it's now time to take a step back and revisit all the decisions we made during our configuration and the setup. My question is to those of you who are admins and have been involved with enterprise wide rollouts- any helpful hints, things to consider, etc, etc? We have a WF value engineer coming to see us next week to help formulate a plan. Some general questions: How many departments are in your instance? To get an idea of scale, I can imagine the instance getting really complicated really fast- do you have a naming convention that you follow to keep track of everything? i.e- department initials after everything? And just to give me a frame of reference on what to expect- how many custom forms, data fields, reports, and templates do you have in your instance? Karen Rutz Harvard Alumni Affairs and Development
29 Replies

Avatar

Level 10
Hi Karen: We do mostly IT projects; We have in excess of fifteen different "departments" using WorkFront or so. I say "departments" because the size of each entity varies widely, but I don't want to use the words Group or Team to describe them; We differentiate them into different Companies, or Groups, or just Teams depending on how they need to interact with other. If they need a lot of interaction with entities in the same Group, then we just make them a Team. If they work occasionally/infrequently, we put them in their own group. If they don't work with other entities at all, they get their own Company; We have one primary form we use for projects, one for tasks, and one for issues. We have other forms for specific uses on those three objects, especially issues, but they are used for special situations and not generally; We have something like 1800 reports. I think maybe 200 are used regularly. Because WorkFront doesn't provide any report usage metrics, we have no way of know for sure which reports are used and how much. I'm hesitant to delete a report unless the report was created by a deactivated user and wasn't shared with anyone. In our custom forms, we have a few hundred attributes. We use about thirty of them regularly and consistently. We do have a naming convention, but because of the way we divide people up (see item 3 above), we don't need to put department or organizational names in the project name. If we don't want someone to see a project (creating ambiguity and confusion, perhaps) we simply don't share that project with their company, group, or team; Not sure if that helps at all! Eric

Avatar

Level 2
Karen, I feel more and more organizations are going to do the same thing you are. I was involved in an instance that had 5-6 different departments - all for different processes - using the tool and here are my top three leanings form that experience. Have a Governance Group - Make sure that there is an admin representative from each department that meet on a regular basis. As you know there are certain features of Workfront that can be changed, but its effect is global (i.e. late notification settings, branding elements, etc). This group is created to make sure there is not one rogue department making changes that effect the entire instance. Appoint a Final Decision Maker - From that governance group, make sure you have someone who has the final say on any issues that may come up from the group. The person will be the owner of Workfront. Use a Department Modifier - We put an abbreviation in front of all our reports, dashboards, custom form fields, request queues, templates, etc. Basically everything. This helps to differentiate items that are named similar but have specific uses for each department. We used two letter modifiers before each item - HR (human resources), IT (information tech), RM (retail marketing), TD (training and development), etc. This also helps if there is a question about a specific item, you know where to start looking for answers. Your time frame on this just depends on the needs from each department. If their process in very complex, it may take a while to set up their templates and custom forms. You may have some departments that are up and ready in weeks, but others may take months. Just remember that it is not a "set it and forget it" process. After and few months, you will want to review what you have set up to make sure it is working as planned for users. Hope this helps and good luck. Joe Benes Brighthouse Financial Charlotte, NC

Avatar

Level 4
If you only do one thing.... MAP OUT YOUR CURRENT STATE PROCESSES, AND THEN OPTIMISE THEM BEFORE IMPLEMENTING WORKFRONT :) We did not, and are still feeling the pain 2 years later.... Hope this helps, Phil Phil

Avatar

Level 4
TRUE! Workfront will not fix things if your processes are not in shape ☺ PATRICIA MORENO | WORKFLOW SYSTEMS MANAGER/PRINT PRODUCTION SERVICES T 973 917 6745 | M 973 865 8530 | patricia.moreno@mccann.com 49 Bloomfield Ave, Mountain Lakes, NJ 07046 "https://www.webcargo.net/request/index/id/7299708/dp/0yrcdXl0dzPIyXDQZS"> Click here to send me files via WEBCARGO.net This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message. Thank you very much.

Avatar

Level 10
Software is a force multiplier. If you have a good process that saves your company $100/day, using Software can multiply that and save $1000/day. If you have a bad process that costs your company $200/day, using Software can multiply that and cause you to lose $2000/day. J

Avatar

Level 5
Thanks everyone for the quick reply!!!! All helpful insight!!! One follow up question. Obviously our overall objective is to streamline process, gain efficiencies, and provide visibility into the work of various departments. We all work very silo'd, and I'm sure we're reinventing the wheel alot, and not working cross departmentally very efficiently. As we start to talk to other departments- I'm really interested in identifying the points of intersection between departments. Can any of you site an example where workfront helped streamline a task/function between departments and how did you accomplish that? For example: My department- creative services, works on all the event collateral. For a print invitation that we are designing- we need a data list of names to send to the mail house to mail the invites. The data list comes from the operations team. Right now- that is a separate ask to operations from the event team. But I'm imagining there will be a smarter, more efficient way to tie this all together in workfront. I know alot of this will be on us to rethink workflows- but I'm just looking for examples to help me get outside of my silo a little bit. tks Karen Karen Rutz Harvard Alumni Affairs and Development

Avatar

Level 1
That is an excellent analogy. Tami Nelson Director, Project Portfolio Management 212.424.0891 A&E Networks Tami.Nelson@aenetworks.com "If a story is in you, it has got to come out" ~W. Faulkner

Avatar

Level 10
Hi: Like you, we operate in a silo'd fashion. The projects that are run in each silo frequently have an impact or involve people in other silos. Previously, when people used Excel and MS Project to manage their projects, there was no cross-silo visibility. With WorkFront, we can quickly determine cross-silo impact. One of the key things we did was allow everyone in WorkFront to view every project. We have no walls between the various groups in IT. No one can "hide" a project from anyone else. Increasing visibility was a big win. We created an element of a custom project form where the PM can tag the various teams that need to be involved in a project early on. That way, each group can run a report and see the projects that PMs in other silos think may impact them. I don't trust people to communicate consistently because they are, well, people. We flag the project, and the impacted people know about it through automated reporting. The other thing we got was cross-silo reporting. We can now report activity consistently because there is no cross-silo barrier, and because the projects in each silo are configured, structured, and run the same way. That allows us to make more meaningful decisions about where the problems are, where the opportunities are, and so on. Hope that helps. Eric

Avatar

Level 10
Using the API was a big win for us in this type of scenario (any workflow really). If you have a developer that can code the API here are the steps we do to accomplish similar workflows that you've described: Create a Request (Issue) custom form to capture any fields you need for your process. Create Request Project to display the Request form (and expose it to whomever you wish – by person, team, group, or company) and do your routing etc. Create a Landing Project for the Request to go. This is done so your permissions etc. aren't done in the Request Project. Once the request is submitted the API has a job that is trigger by the looking for the custom form itself (we can use other criteria as well to trigger it). The API converts the Request to a Project using a Template that has tasks to all the different teams/groups/companies We also have code in the Template that interacts with the API to delete certain Tasks that aren't required for this request. So the resulting project will only have the tasks that are needed. People work their tasks, when all are complete, WF marks the project complete and marks the original Request (Issue) Closed. All done. We also put these processes in specific "Programs" to easily find and report on, etc. For example, we use this for New Hires. A new hire may require a new computer, phone, access to certain applications, a cell phone, a badge, etc. And these are all done by different people in different teams. If the person filling out the New Hire Request doesn't check the box for a cell phone, the API removes the Cell Phone Task for us. We have several workflows that work similarly. And what everyone has said is true. If your process is ill-defined, it will take time to get it right. The aforementioned New Hire process was a bear to work with because so many teams had to do something and no one knew the whole process. So it took me a long time to get it perfect. And it still evolves. I do recommend getting a resource so you can use the API. It has saved a ton of time and really helped with our adoption. It can be impressive which makes people want to jump on board and request more workflows (which is good news/bad news right �� ) And I don't know if anyone said this already, but if you want adoption, REQUIRE EVERYONE that will use Workfront to take the Workfront Training (and you can track who actually took it). You can tell them which classes are required and which are optional, but I highly recommend this. We did the following: Learned and configured with the WF Tech for 5 weeks Required all our staff that would use Workfront to take the WF training (gives them basic WF skills and knowledge) Provided our own classroom training to train people on the new processes themselves (gives them process skills and specific knowledge on how it should be used for your instance) Then walked the floor for 2 weeks after deployment helping answer questions and solving issues. This was a big win because people weren't asking questions until we stopped by (they just suffered in silence). Hope this helps. I know it's a lot. Feel free to reach out if I can help. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT ------Original Message------ Thanks everyone for the quick reply!!!! ¬¨‚ĆAll helpful insight!!! ¬¨‚ĆOne follow up question. ¬¨‚ĆObviously our overall objective is to streamline process, gain efficiencies, and provide visibility into the work of various departments. ¬¨‚ĆWe all work very silo'd, and I'm sure we're reinventing the wheel alot, and not working cross departmentally very efficiently. ¬¨‚ĆAs we start to talk to other departments- I'm really interested in identifying the points of intersection between departments. Can any of you site an example where workfront helped streamline a task/function between departments and how did you accomplish that? For example: My department- creative services, works on all the event collateral. ¬¨‚ĆFor a print invitation that we are designing- we need a data list of names to send to the mail house to mail the invites. ¬¨‚ĆThe data list comes from the operations team. Right now- that is a separate ask to operations from the event team. ¬¨‚ĆBut I'm imagining there will be a smarter, more efficient way to tie this all together in workfront. ¬¨‚ĆI know alot of this will be on us to rethink workflows- but I'm just looking for examples to help me get outside of my silo a little bit. ¬¨‚Ć tks Karen Karen Rutz Harvard Alumni Affairs and Development

Avatar

Level 4
Great insight and examples Vic! Sounds like your use of the API would also be a great presentation for the next Leap

Avatar

Level 10
We actually did at the last two Leaps. I'm hurt you didn't attend �� Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 5
Hi Lucas- Can you share w/me what kind of data field you put on the project form? was it a check box of each department? Any chance you could do a screen shot of the form and the report? I really like this idea! tks Karen Karen Rutz Harvard Alumni Affairs and Development

Avatar

Level 5
Thanks Vic- impressive! Not sure we'll be able to do this out of the gate- but a girl can wish! As you all mentioned- we have to do the hard work documenting our processes first. tks Karen Karen Rutz Harvard Alumni Affairs and Development

Avatar

Level 10
I'll second Vic's point regarding the API. This is an area where we are taking things to the next level. Some of the things we're doing with the API include: Creating new projects in Workfront using data from our finance system. Creating and syncing projects in Workfront from tickets in ServiceNow (service desk system) Sending alerts to users when certain Task fields are changed by certain groups of users (e.g. planned dates, custom fields) Sending fancy HTML emails to our customers confirming scheduled work Sending out CSI surveys to customers related to their work. Updating exchanges rates of multiple existing projects (there's no way to do this in bulk using the regular user interface) I'm now looking into importing (syncing) time-off data from our payroll system Creating, storing and reporting on trend-related data which otherwise isn't natively available in Workfront. There are tools out there (e.g. Azuqua) that make the API accessible without requiring traditional programming resources. David Cornwell Pentana Solutions

Avatar

Level 2
David - Are you able to use the API to change customer fields in work front? We are struggling with this. Scott Goddard Consortium

Avatar

Level 10
Is anyone going to share, via examples, documentation or video, how to do this using API coding. I'm very interested in automation of this workflow. Currently, my workflow is completely manually done by me. I have zero knowledge as to how to automate any portion of the process, using API coding. I am very interested in taking Workfront to the next level. Thank you. Benetta Perry APS

Avatar

Level 10
@David Cornwell , my understanding of Azuqua is that it's the connector between WF and another application eg WF and Service Now in your case but it's not meant to be taking WF data, massaging it, and then send it back to WF without another application. Is this correct? Polly Co

Avatar

Level 10
@Benetta Perry , they only have this documentation on their site. API Docs | Workfront Developers If you have programming/coding experience, the code samples in the site will give you an idea on how to start. Polly Co

Avatar

Level 10
I'd be happy to chat with you and screen share what we're doing to provide a clearer picture of the possibilities. However, our API was coded by a developer (or former developer – my boss). Without his coding background (and smarts) it wouldn't have been possible. I agree with David that there are tools out there to help, like Azuqua, but I have zero knowledge of those tools. But again I can show you how we've set it up and how it runs. My boss set it up in a data driven way that allows us to create new workflow streams very easily and without having to perform coding changes (in most cases). It was pretty clever how he designed it. I don't think he's on this thread, so I'm not kissing up �� Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 4
Vic, that's something that I would be interested in checking out as well. Not sure if we can get a Workfront sponsored informal webinar that you would be willing to share on, or if its something that one of us could set up...but I'm interested in seeing the concept. Thanks! Scott