Enterprise-wide use of a single WF instance?

[SteveTe]

My organization is already using WF in the marketing department but two additional units are interested in using WF for product development and scheduling functions. To me, it makes the most sense to work within the same WF instance rather than having 2 or 3 separate instances. Though the units will have different templates, workflows, statuses, etc., they will also share executive leadership, users, and reporting. Has anyone been involved in an implementation like this? Does WF in its current incarnation support this enterprise-wide business case or does going with 2 or 3 separate instances save lots of unseen (by me) headaches?

[EricLu2]

Hi: We have multiple groups within the company using WorkFront. We considered whether to get new instances or just “partition” the existing single instance. In the end, we chose the latter alternative. We did it using Companies and creating different access profiles that keep people in one company from seeing projects in the other company. We have a number of people who will be involved in projects that cross “companies” in WorkFront (as you mention below). Having everyone in one instance makes it very easy for everyone. I have trouble imagining why I would want to purchase multiple instances of WorkFront for a single Corporation. Maybe if one had to deal with Government or other highly restrictive security considerations we’d go with multiple instances. Does this help? Any questions about how we partitioned WorkFront? Thanks, Eric

[SteveTe]

Eric- Yes, I'm curious how you did the virtual partitioning. Do they operate like different instances (with different administrators, for example) or are they in a shared envrionment with access to various functions limited based on department? Do all "companies" still share some of the functionality that doesn't seem to lend itself to partitioning, such as most of the functions in Setup? Can you easily report across the units? I had a call with WF Consulting and they confirmed future updates to the Group function will allow for Groups and Subgroups (already in sandbox) and ability to assign different statuses based on Group membership (coming in Q4). In all, this seems to lend itself to making the recommendation to configuring a single instance.

[Doug_Den_Hoed__AtAppStore]

Hi Steve, We have worked with many Workfront customers who control one or more Workfront domains and for various reasons would like to Merge them (or alternatively have one Workfront domain and would like to Split it) using our "http://store.atappstore.com/workfront-merge-or-split/">Workfront Merge (or Split) solution. I would add that performing a Workfront Merge is one of the most challenging (and expensive) activites we offer, and therefor encourage you to carefully weigh the pros and cons for your organization -- as you are doing. Regards, Doug

[Former Community Member]

I've worked in enterprises that had both a unified instance and divided instances. Divided instances were set up based on the org hierarchy for security purposes and because the global nature of statuses, and preferences were perceived to cause possible issues. Unfortunately, 2 groups using different instances were merged and a lot of confusion instilled. Eventually a major project was undertaken to merge 2 of the instances. It worked, but it was a tremendous amount of effort. With the new hierarchical groups finally coming into production, I would be very wary of splitting up instances. That being said, a large enterprise instance has its own problems. You tend to have a large number of system administrators who need to coordinate their activities. Changing any global parameter needs to be discussed and reviewed for problems. And there will be a point in time when one administrator makes a huge mistake such as deleting all of the teams from a huge part of the company. The other thing is that you need to be much more careful about security. Some team will want to open up the instance to outside users and any global shared reports can be visible. Tight control of layouts and understanding of the access model are key. As an instance grows, naming conventions are key. For example all reports starting with the short code for that group/dept. Or all projects needing to belong to a portfolio. Shared fields can also cause problems, who controls the list in the Department field? But you don't want multiple fields with almost identical names cust, customer, customer name, primary customer, proposed customer, etc could be extremely confusing when it comes to reporting time. Basically a large instance needs: A primary admin and/or a strong governance committee A good data model with a description of the intent of each field Strong naming conventions for reports, dashboards, forms, fields, etc Control of global sharing and basic security model Use of layouts to minimize distractions/confusion for new users Good internal documentation of reasons behind each selected global parameter On Wed, Aug 17, 2016 at 9:17 AM Lucas, Eric < globalforum@communitylists.workfront.com> wrote: > Hi: > > > > We have multiple groups within the company using WorkFront. We considered > whether to get new instances or just “partition” the existing single > instance. In the end, we chose the latter alternative. We did it using > Companies and creating different access profiles that keep people in one > company from seeing projects in the other company. We have a number of > people who will be involved in projects that cross “companies” in WorkFront > (as you mention below). Having everyone in one instance makes it very easy > for everyone. > > > > I have trouble imagining why I would want to purchase multiple instances > of WorkFront for a single Corporation. Maybe if one had to deal with > Government or other highly restrictive security considerations we’d go with > multiple instances. > > > > Does this help? Any questions about how we partitioned WorkFront? > > > > Thanks, > Eric > > -----End Original Message----- >

[AdinaPi1]

What Melinda and Doug said. They took the words right out of my mouth. =)

[VernPh]

We have multiple instances of Workfront in our organization (some with hundreds of users and others not so many) and have found that approach to be beneficial to us. The benefits of different instances relate to being able to make the user experience less confusing. Many objects within the instance are global, which means users will see long lists of options in many circumstances. As has been mentioned, strong naming conventions help to resolve this because the user can quickly identify the subset of objects that they have an interest in. In our minds, that's an unnecessary burden upon the user. One characteristic of our instances is that each community uses Workfront in a slightly different way and for different business reasons. For example, one instance is very help desk centric while another implements typical project management processes related to monitoring and control. When an idea has been expressed for us to combine instances, I have addressed that by defining the process for merging, assimilating and maintaining the long list of global characteristics - in addition to managing a more robust security policy and architecture. Those steps are usually enough to where the suggester says, "Never mind." In our contractual relationship with Workfront, there is no cost avoidance realized by combining instances so there is no financial incentive to do so. In fact, as indicated in other posts, an additional administrative overhead and cost would be needed in order to coordinate new and changed global objects as well as usual system administration functions. If the organizational structure is in place and well-regulated; and there is strong functional commonality (e.g., enterprise wide policies and processes) then perhaps a single instance would be beneficial. Vern Phipps

[GregBe1]

Vern, I assume in your case the Users in each instance never cross over and do work with the folks in a different instance. If they do, how do you handle that? I also assume that your business is solidly divided and there is no need to do any reporting that combines more than 1 instance, right?

[AnthonyIm]

Hi Steve, We have one global instance with over 1,000 employees across 13 different business units. And with some of the business units being conflict shops, I can let you know that we are able to separate things so that the end users only see what they need to. The biggest reason we wanted one instance (besides it making my life easier) was that we are getting to the point where clients and resources are being shared across multiple units and having them all in one instance has made it very easy for them to work. I did a presentation about this at LEAP this year with my boss, Kathy. I've attached the deck if you want to take a look. Let me know if you have any questions.

[VernPh]

Yes, it is true that there must be a strong division of labor, function, or purpose between instances and for the most part this is true in our organization (but may not be true in others). There are some activities where a functional overlap exists and the decision has been made that a few PMs have two accounts (and two licenses). These are unusual circumstances that perhaps an example would illustrate. (I manage a Data Warehouse, so please tolerate my use of that in the example.) A corporate or enterprise project exists that is being managed by PM #1. One of the tasks in the WBS for that project is for the Data Warehouse to conform to new or updated data and data structures. The Data Warehouse constructs its own substantial project of several hundred tasks to accomplish that transition and assigns someone to oversee that effort. The overall project is managed in one instance and the Data Warehouse sub-project is managed in another. If PM #1 wants to have insight into the gory details of the Data Warehouse project, PM #1 must either rely on the Data Warehouse's PM’s or they can look in the Data Warehouse's instance. Generally, PM#1 does not want to know, for example, that Analyst A has completed the mapping of Table xxx but is content to know that of the 100 tables that EDW must remap, 75 of them have been completed. Only in few cases does the PM need to have an account in both instances. Our circumstance is obviously not comparable to other circumstances or environments, but this is one business case where multiple instances actually works well and we are content with that approach. One primary difference between the two instances is that one instance uses Workfront for higher level project management and reporting while the other instance uses Workfront for detailed task and workflow management at an individual level.

[SteveTe]

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

[Former Community Member]

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----- >

[AnthonyIm]

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.

[MartyGa]

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.

[VernPh]

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

[AnthonyIm]

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.

[SteveTe]

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?

[AnthonyIm]

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. ;)

[ElizabethVo]

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

[EricLu2]

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

[EXP_-_DustinMa]

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