Enterprise-wide use of a single WF instance?

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

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.

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

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

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

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

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?

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.

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.

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