Enterprise-wide use of a single WF instance?

Layout templates let you control access to global lists. As does strict access control. If you don't have access to a report or project you don't see it. The admins are out of luck in that they see everything, but a user can get a very specific focus view with a little work. On Mon, Aug 22, 2016 at 10:17 AM Steve Teitelbaum < globalforum@communitylists.workfront.com> wrote: > Anthony- > > Thanks for the response...the deck was very helpful. Though some of the > research I've done suggests that global lists can be an issue for users > (hundreds of filters/views/etc.) you suggest that you've been able to > mitigate that problem by ensuring the users see only what they are supposed > to see. I'm sure naming conventions would be helpful but would not limit > the number of options. What is your solution to this? > > All the best, > > steve > > -----End Original Message----- >

As Melinda pointed out, you can control the filters, views, and groupings in their layout. We have at least two for every agency (one for PMs and one for Workers) so we can use that to control which ones they see. We have also removed the ability for anyone to share anything system wide. Only myself and the other admin can do this. The only thing that we don't hide is the teams. Since we have agencies that work with each other, we need them to be able to assign tasks to teams in other agencies. For this, we use the naming convention Agency: Team Name (example - FCB WW: Project Managers) Reports, calendars, dashboards, schedules, custom forms, etc. are only shown to people if they have access to them. Again, because we don't allow people to share system wide, most of the things people see are relevant to them. When I create reports that are business unit specific, I do tend to put the agency name somewhere in the title so that I know who that is for. (Example: "HackerAgency Hot Sheet" or "Hot Sheet (HackerAgency)") We really like having everything in one instance and haven't had too many complaints. The biggest ones are not being able to have a local person at the agency be a system admin (although I hear that is coming), having different statuses (that is coming soon), and different hours per day. Other than that, the teams don't notice too much but the executives and shared services teams love it. Hope that is helpful.

I would agree with everything already posted, and add that the group structure is important to nail down as well. Project templates (as well as lots of other objects) can be group specific and therefore aid in limited what one group sees when they create new projects. Another thing that we've done in some areas is to create reports of items that people frequently need. Reports of Reports, for example, instead of having people go to the "reports shared with me" section.

At the risk of drawing out a topic unnecessarily, but I'm concerned that what appears to be a simple topic can be more complex than thought. Our large organization evolved with multiple instances (8, with around 1100 users) and have made several attempts to combine, so I talk from that practical experience that may not be germane to others. Starting out with only one instance may be easier but still introduces concerns that I have mentioned before in a different way: There is an overhead that must be planned for, staffed, and supported in order to manage access and control, resolve conflicts and define/enforce system wide policies and procedures (including naming conventions) whose level of effort may not be anticipated as part of startup. If disjoint (e.g., stovepipe) organizations use the same instance of Workfront, they may have to conform to global standards that require changes in process or terminology (and may not want to). Layout Templates and access controls via groups resolve some issues (e.g., reports), but as far as I know, there are some objects or functions whose access cannot be fully constrained to a certain set of users and are not configurable using layouts. For example I don't know any way to limit the following: List of Severity List of Priority List Status List of Job Role List of Team List of Group Program/Task/Issue defaults Notifications settings and email texts Custom data fields with some common selections and some domain specific If your organization chooses to allow certain sets of users to access some advanced functionality (in order to reduce overhead and support flexibility in processes, for example), other objects become problematic, for example: Custom Forms Custom Data Expense Types Risk Types I suppose the point is that the use of different instances is not universally good or bad. It depends upon the nature of the organization being supported. It goes without saying that I have a lot to learn and I would welcome insight into merging multiple instances (wthout changing functionality) that I've been dealing with for over 3 years. Vern R Phipps

Hi Vern, You bring up a good point. If you are looking to combine multiple instances but want all the customizations from each of your instances, you will not be able to combine them into one instance. There is some standardization involved when using one instance. For us, because we wanted to get to a point of standardization in our agencies, it made sense for us to go with one instance. Also, we've only ever had one instance so people went from their chaos into Workfront so there was change mgmt and compromise needed anyways. When a new agency wants to join Workfront, we work with them on what they can customize for their office and what they will need to conform to. For the most part, we don't have any issues and the few we have, they are going to be solved soon by Product or aren't that important. At FCB, we have 13 different agencies in one instance. Now, myself and my partner in crime Kathy are from corporate and our job is being global system admins for the instance. It is part of our job description. We do have Local Agency Admins who have Plan licenses and an access level that is open to everything except sharing system-wide. This helps with adding/editing users, creating teams and creating/editing Custom Forms for their group. This has helped us out a lot, but there are still things we need to do for them as system admins. As for the list of things you provided, list of groups and job roles doesn't really matter as they are based on info from our financial system and everyone uses that financial system. For statuses, that is going to be remedied soon when different groups can have different statuses. Now for the others, everyone has to share the same list. We have a "governance" group I guess you could say that has to approve any changes that are needed. An agency will ask us to change something, we then go to all the SuperUsers from the various offices (normally as a survey). If someone or an office has concerns about a change, we talk to them about it until we can ease their concerns. In the four years we have been on Workfront, so far, there have been no issue. Sometimes, there are issues with Custom fields. Two offices want a field that is different (i.e. Single Line of Text vs Comment box) but want the same name. So far, they are good about saying "Agency 123's Job Number" and then when building reports changing the display name of the column to just Job Number. In conclusion, we at FCB found the benefits of cross-agency projects and being able to incorporate Share Services departments more beneficial than having different terminology or lists of items. So we went with the one instance. The company does have to pay for two non-billable system admins, but we have also become SMEs on several different areas of the business and can share past experiences and best practices with the agencies across our global network. We also reduce the admin work that local offices would have to dedicate for their own instances and can help montior agencies for any issues so we can help course correct before it gets too out of hand. But that has what has worked for us.

You raise some very good things to consider...I will absolutely take them into account as we plan for this. A related question that has come up...if multiple business units are joining the existing instance and they routinely have projects that cut across units, what are the pros/cons to having one large project that assigns tasks to producers across business units vs. having each business unit responsible for their own projects and daisy-chaining them together using cross-project predecessors?

We have agencies that do use different ways to work across groups/business units. For the ones that use one big project, the main Project Manager owns it and they give Manage Rights to the Data PM (we do Direct Marketing) or Broadcast Producer so they can manage their section of the projects. I've also seen it where the Data PM and Broadcast Producer just act like Resource Managers and if dates need to change or tasks added, they go to the Project Owner to do that. We normally see this from teams that are used to collaborating with others and aren't so siloed. We also see this from agencies where the Project Owner is in charge of all the hours for a project. Then there are the groups like you said who have different projects that are linked by Cross-Project Predeccesors. These teams tend to like it this way because the client or Project Owner don't really care what the Data or Broadcast teams do as long as it is done by a certain date. We tend to see this approach from agencies that tend to be siloed and like to work in secret. We also see this in agencies where the Data PM or Broadcast Producer are in charge of their team's hours instead of the Proejct Owner. The teams love the way they work so I don't know if there is a "right way" and, honestly, I don't care as long as the planned hours are getting in there some way. ;)

Vern, Are any of your multiple instances across different countries? Specifically, I am concerned about latency or user experience impact if we combine a global instance across the Americas and EMEA. Thanks, Elizabeth Volini JLL Chicago IL 312-702-4516

Hi: Our multiple Companies are not in different countries. I thought, generally, customers in EMEA use a different set of servers than those in USA or Austrailia/New Zealand. I think you are wise to be concerned about sharing a single instance across such long distances. Eric

Hi Elizabeth, Eric is correct. We have 5 server clusters, with our 4th one located in our EMEA area (London and Poland if I remember correctly). However, we utilize a caching tool called Akamai, where it's a cloud based service that caches static content, so really the only delay is pulling live data from the WF database (such as a report.) Overall, most of my clients are content with performance now, as we worked incredibly hard to make Workfront as stable performing as possible over the last year and a half. Depending on which instance of JLL you're in, will be dependent upon which server cluster you're on. If you're in the EMEA instance, you're already on our server cluster 4. I'd be happy to discuss this further with you, you should be able to reach out to Kristin R. in your organization if you want to set up a call for us to hop on to go over this. Thanks, Dustin Martin Tier 2 Assigned Support Engineer Workfront