Author: Andrew Koprowski

Now that you have a Workfront Requests queue to track errors, it is time to show our admins how to troubleshoot Workfront using a real-life example (with historical Revolutionary War heroes as our users). 

Remember, in the first article titled, “Think Like a Workfront Admin: What is Troubleshooting?” we discussed four fundamental questions to ask after reviewing the technical support ticket: 

In addition, we identified the process for troubleshooting errors in Workfront: 

Let’s attempt to solve George Washington’s error in Workfront. 

George Washington submitted a request to the Workfront Requests queue as a Technical Support request. After reviewing the form, we have identified the error involves a report on a layout template: 

Based on the custom form, we can identify three out of four fundamental questions when reviewing Workfront errors: 

        1. George Washington is attempting to view a list of active projects he owns on the “My Active Projects” report in Workfront.
        2. George Washington has the Planner Access Level.
        3. George Washington’s Layout Template is Creative Director (based on the ID in the Custom Form).

 

The last question we need to answer is, “Does the user have the correct sharing permissions on the corresponding object?” In this case, we need to review the sharing rights on the “My Active Projects” report. 

Upon further investigation, we have identified that George Washington does have the correct sharing permissions for the “My Active Projects” report. The report is visible system-wide, without restrictions: 

 

Now it’s time to follow the troubleshooting process! 

      1. Answer the four fundamental questions for troubleshooting errors in Workfront.
      2. Log in as George Washington in Workfront. 
      3. Replicate the error by navigating to the Projects area and viewing the “My Active Projects” report. Picture 1 shows the results that George sees when reviewing the report and picture 2 shows the results George should see but does not:

 

 4. In order to properly resolve the error, we need to further investigate the key features of the report. 

          • First, review the report’s filters and determine that the filters are set up correctly (we use wildcards to make the report dynamic).

          • Next, review the report’s settings and notice that we accidentally set the “Run this report with the Access Rights of Andy Koprowski.” When selecting a user in the “Run this report with the Access Rights of” field, it will overwrite the existing filters of the report. So, instead of viewing active projects with an owner ID equal to $$USER.ID, the report will instead show all active reports owned by Andy Koprowski. 

          • To resolve the error, remove Andy Koprowski from the field, “Run this report with the Access Rights of” and save changes to the report.
          • Next, log back in as George Washington and confirm that the update to the report resolves the error: George can now view all of his active projects.

          • Remember to respond to the error ticket, informing the user that the error has been resolved and move the status of the ticket to Closed. 

 

In our next blog in the “Think Like a Workfront Admin” series, we will discuss how to create advanced reports using advanced views.

In the previous article, we discussed what is troubleshooting and what to expect as a Workfront System Administrator. Now, it is time to shift our focus to Workfront queues.

What is a Workfront Queue?

A Workfront queue refers to a special type of project that stores requests, issues, change orders, and bug reports submitted by Workfront users. Organizations traditionally use queues to capture requests and develop a working backlog of active issues that Workfront System Administrators will resolve. Every organization that leverages Workfront should have a version of a Workfront Request queue.

A successful Workfront Requests queue has the following features:

  • Project name: is informative and clearly articulates the queue’s purpose
  • Project status: equates with a status of Current (this activates the queue)
  • Queue topics: are easy to understand
  • Custom forms: have the appropriate fields to adequately capture the error
  • Other features:
      • The project is published as a Help Request Queue
      • The project enables “Anyone” to add requests to the queue

 

We have successfully outlined the characteristics of a functioning Workfront Requests queue and you are probably thinking, what does an example queue look like? Fortunately, you are in luck. Below is an example queue structure that many successful Workfront organizations use to capture Workfront issues submitted by their workforce.

  • Project name: Workfront Requests
  • Project status: Queue (equates with Current)
  • Queue topic structure:
      • Technical Support
      • Enhancement Idea
  • Custom forms: contain fields to identify the object/area of Workfront experiencing the error, space to describe the error in detail, and a final message to nudge the user to submit any photo/video proof of the error

There are many benefits to having a Workfront Requests queue, but the benefits are not just for Workfront System Administrators. Providing a Workfront Requests queue empowers your users to take control of errors and improves error resolution communication. In addition, logging errors helps Workfront System Administrators conduct intelligent and meaningful conversations with their Workfront Account Executives, Customer Success Managers, and Support Engineers. The more detail captured per error, the better equipped you and Workfront Support will be to quickly resolve the error.

Lastly, creating a Workfront Requests queue that captures technical support requests (errors) and enhancement ideas (product enhancements), supports your organization’s Workfront governance model. Users will build a product backlog of enhancement ideas, which can be routed to your Workfront Governance team. Rather than assuming the enhancement idea is valid and should be resolved, the Workfront Governance team can discuss the idea, determine the ROI of the idea, the overall impact to your user group, and ultimately decide if the enhancement is worth pursuing.

We will be returning to the idea of a Workfront Governance team and structure in a later series.

In our new series, “Think Like a Workfront Admin,” our consultants will walk you through how to troubleshoot Workfront like a pro!

Are you a new Workfront system administrator? Or perhaps you are a seasoned Workfront administrator looking for new ways to troubleshoot system errors. Either way, you’ve come to the right place.

First, we need to start with the basics and answer the following questions:

‘What is troubleshooting and how do you troubleshoot Workfront errors?’

Any software application, no matter how advanced, will need to be troubleshot by a system administrator or software subject matter expert from time to time. I’ve been in the IT world long enough to know that even the simplest line of code can break and when it does, it is best to be prepared with the right questions to quickly fix the problem.

So, what is troubleshooting?

Troubleshooting is identifying a problem, understanding the root cause, and correcting the problem. That’s it!

Next, we will discuss, how do you troubleshoot errors in Workfront?

Typically, errors are identified by your users. That’s right, the standard plan, work, and review license users will find more errors than you, the system administrator. Let’s be realistic, every system administrator builds Workfront to work, but Workfront doesn’t always work as expected. Don’t take it personally (I had to learn that the hard way). Just remember, it’s your job to identify the root cause and quickly solve the problem.

When an error is identified, you should ask the following questions:

When you answer all of the questions above, you will typically find the root cause of basic problems in Workfront. I cannot tell you how many times users have reported “errors” that weren’t actually software errors, rather, the user needed an upgraded license, access level, and/or layout template.

To make things easier, I execute the following process for each error:

 

After following the process above, if you aren’t able to identify the root cause and resolve the error, you will need to submit a ticket to Workfront Support for additional help.

In the next post, we will discuss “How to create an internal request queue to track and resolve errors that your users identify.”

Stay tuned.

 

In my last post I talked about the benefits of having a dedicated Workfront system administrator. But from my experience with clients I’ve learned that not everyone anticipates needing full time resources to support a SaaS application. More often than not this stems from a lack of context—being unsure of what duties a sys admin could or should take on and not knowing just how much time those activities can consume. If your organization decides that it needs a Workfront administrator but doesn’t know what to expect, I have created a “starter” list of roles and responsibilities I have performed while working as a Workfront administrator:

 

1. User profile management (1-2 hours per month)

While your account rep will almost certainly ensure you don’t go over your license count for any extended period of time, it can be incredibly helpful to keep track of how close you are to the threshold, whether licenses are appropriately allocated across groups, and whether accounts need to be deactivated. Additionally, it’s a good practice to regularly validate that users have all the appropriate settings—layout template, job role, team assignments, etc.—even more so if you’re leveraging group administrators. Most of this can be easily done by setting up a few key reports. But they still require someone to manually check the information. Below are three simple reports I’ve used in the past:

  • Quarterly license audits
  • Bi-weekly Human Resources termination audits
  • Monthly groups and teams audits

 

2. Report and dashboard management (4-8 hours per month)

This one is no small feat. Depending on where you are in your Workfront journey, creating and managing reports could actually account for the vast majority of your time. The trick, of course, is to create a suite of reports that can be flexibly applied across users through a combination of wildcard filters. But the path to get there is not always so easy…or quick. In my experience, work in this area typically falls into one of three categories:

  • Create reports and dashboards to support project managers, project teams, and executive leadership
  • Customize layout templates for different user personas by applying dashboards to enhance the user experience
  • Quarterly report and dashboard audits

 

3. Custom fields and forms management (1-2 hours per month)

Custom fields can get tricky. Staying on top of field consistency and eliminating redundancy can be the difference between sys admin sanity and overload. But your users don’t really tend to care about all that so long as the fields and forms they need are to their liking. So it’s a “shadow” responsibility for any prudent admin to consistently review custom fields, make sure they have the right data type (string, date, currency, etc.), and that there’s as little redundancy as possible. Doing so will ultimately help keep the Workfront instance leaner and reduce the overhead associated with changes.

  • Create and update custom fields and custom forms to support the various teams using Workfront
  • Review fields across user groups and identify opportunities to consolidate

 

4. Create and maintain standard PMO processes and training documents (8-32 hours per month)

While Workfront is certainly a powerful tool it can’t technically dictate or enforce what your processes and procedures look like. It can help provide some structure; but it still requires users to take an appropriate set of actions in any given situation. That said, your processes certainly need to be simpatico with Workfront. And your procedures need to tie the two together. The Workfront administrator is a powerful resource for helping to do just that: defining procedures, mapping processes, and creating or maintaining training materials that educate staff on how to apply a process in a Workfront-driven world.

 

5. Troubleshoot technical Workfront issues and bugs and coordinate with Workfront technical support when necessary (40-48 hours per month)

I mean, come on, can you imagine a world without a support desk?

 

6. Test Workfront beta preview releases and inform executive leadership and the PMO of Workfront Release changes (4-5 hours per month)

Release management is a big one. There are really two scenarios: 1) completely new functionality or features are being released and you need to assess whether it makes sense to leverage them; or 2) features are being deprecated and you need to game plan how to roll out and train staff on alternatives. The latter doesn’t happen very frequently but when it does it poses a huge risk. Which is why someone needs to stay on top of the releases.

  • Workfront conducts three releases a year that have minor and significant changes to the software. It is recommended that a Workfront administrator or a dedicated resource review and test all new features in the Preview Sandbox region prior to launch
  • Testing is conducted to confirm that current workflows and processes will not be negatively impacted

 

7. Project development and management (1-2 hours per month)

These activities ring particularly true for organizations that don’t yet have fully matured project management methodologies—organizations where project plans may be subject to frequent change or the portfolio/project hierarchy is still fluid. But even teams that have been “PMO-ing” for ages will still find that they need to make the occasional change as they better learn how to take advantage of things like workflow automation and some of the other collaborative features of Workfront.

  • Create project templates in coordination with the PMO
  • Quarterly portfolio, program, and project audits
  • Quarterly queue audits

 

8. Perform general maintenance and updates of the Workfront system (4-8 hours per month)

Invariably things need to get tidied up. Even with the most careful user base there are errors and incorrect settings. And while it’s easy enough to ignore these things, they can go a long way to ensuring data integrity. And if you don’t care about data integrity right now, you will when it comes time to perform operational analysis. Want to know how long projects for a specific line of business take? Then you need to make sure the necessary custom fields are filled out. Need to re-baseline your project benchmarks? Then you need to have confidence in your duration actuals. At the end of the day, the data is all incredibly important, and while users do their best, you need a system of checks and balances to help ensure integrity and accuracy.

 

9. Create configuration documentation for all internal changes and updates to the Workfront system (1-2 hours per month)

A lot of organizations don’t take this one seriously. They see it as needless overhead. But from experience I can tell you it’s anything but. Configuration documentation is basically a requirements and design artifact that gets created when you implement the system and gets updated with each major change you make. It serves, in this sense, as a change log so that if ever you make a serious design/architecture faux pas you have a historical record of what things got changed from so that you can more easily change them back. Trust me when I say nothing is worse than implementing a major change only for there to be user mutiny and no quick means to change things back.

 

10. Traffic intake management (8-12 per month)

Depending on your processes or how many licenses you have, the number of users that can create projects might be incredibly limited. In these instances, traffic and project set up are handled, primarily, by system administrators. They act as traffic managers and make sure all the requisite details on custom forms are filled out and that all approvals are completed in accordance to PMO processes (as applicable). While this area of responsibility is more closely aligned with business users, it can often fall within the purview of sys admins and, when it does, it can take up a significant amount of time.

 

By now, hopefully you’ve realized not just how important dedicated sys admin support is, but how much of it there is to do. It takes a lot of time from a very skilled resource and can be incredibly difficult for someone to do “in the margins”. If you’ve been doing the math you know my “starter list” can easily eat up over 70% of an FTE. And that’s before we even delve into more advanced functions like operational analysis and continual process improvement. The moral of the story is that, if you’re wondering if a dedicate Workfront administrator will have enough to do, you’re asking the question the wrong way. The real question is “who will support these responsibilities if you don’t have a dedicated administrator?”

 

If you’re interested in learning more about what to look for in a Workfront system administrator or if you’d like information on our managed services, contact us at info@leappoint.com.

 

5 questions to ask yourself if you’re debating getting a system admin for Workfront

Many of our clients ask if they should hire a Workfront system administrator. As an ex-sys admin myself, my short answer is almost always “yes”. Workfront, like any other SaaS application in your stack, needs consistent love and care to ensure you’re getting the most out it. And as such, I highly recommend adding a full-time sys admin to your team. In fact, depending on the size of your Workfront instance, you may need more than one. But before you decide to hire a Workfront administrator, ask yourself the following questions:

 

  1. Do your current resources have the time necessary to maintain and update your Workfront instance?
  2. How many users will actively use Workfront?
  3. How mature is the PMO/project management function at your organization?
  4. Does your team/department have the budget to hire a Workfront system administrator?
  5. Has your organization used a Portfolio Project Management (PPM) tool in the past?

 

Let’s take a look at each of these questions in more detail and consider how and why they impact the potential need for a system administrator.

 

1. Do your current resources have the time necessary to maintain and update your Workfront instance?

If your resources do not have the time to test, maintain, and update your Workfront instance, it is highly recommended that you invest in a Workfront administrator or hire a consulting company [insert shameless self promotion for LeapPoint] to handle admin responsibilities. One of the biggest misconceptions about SaaS applications is that you pay someone to implement them for you and then you’re done. Full stop. No more changes required. The reality though, is that environments are in an almost constant state of flux. As users gain a more complete understanding of what the system can and can’t do, their requirements often change; as teams and processes and procedures all evolve, so too must the system configuration; as new features are rolled by the software vendor you need someone there to assess what they are, if they should be leveraged, and then actually implement the necessary changes. When you start to tally up the list of things that need to be done it becomes pretty clear that it’s a difficult responsibility for someone to assume in their spare time. And that’s before routine things like fielding user questions or creating reports.

 

2. How many users will actively use Workfront?

This question really builds upon the previous.  Just because you have X-number of users does not necessarily mean you need Y-number of system admins. However, when you think about maintaining and updating Workfront for the various user bases, there’s obviously a correlation between the number of users and the number of teams, groups, and processes and, in turn, the general complexity of the configuration. Many large enterprises have hundreds if not thousands of active users. And so managing licenses, teams, groups, and companies within Workfront takes significant time and the larger your active user base, the more likely you’ll need a Workfront administrator. While there’s no hard-and-fast rule, my experience has been that organizations typically benefit from a dedicated system admin at around 100 paid licenses (Work or Plan) and an additional 1/2 – 1 FTE for every 150-200 users past that. While it may sound like overkill to some, remember that the system admins are really the ones who ensure things run like a well-oiled machine. They’re the ones who are going to make sure you’re able to use the system to drive measurable business value.

 

3. How mature is the PMO/project management function at your organization?

Successful change management takes time, energy, and money. The more significant the change, the more of each of those things it usually takes. So when we think about the project management maturity of an organization, there’s going to be a very strong correlation between how nascent or unstructured their approach to project management is and the degree of change inherent in bringing in a very structured, very robust PPM tool like Workfront (see “Has your organization used a Portfolio Project Management (PPM) tool in the past?” for more on PPM). Having a dedicated Workfront system administrator can help promote and implement PMO initiatives or related PM processes if you don’t have a formal PMO. Even if you don’t have clear workflows and processes (or perhaps especially if you don’t), a dedicated Workfront administrator can help reduce the time it takes to implement changes at your organization, especially if change happens frequently.

 

4. Does your team/department have the budget to hire a Workfront system administrator?

The one’s pretty self explanatory. You can’t buy what you can’t afford. A couple of thoughts on the topic though. When making the case for sys admin support think about the previous questions and the fact that the effort related to them isn’t really optional. If you want Workfront—or any SaaS application—to be successful and deliver valuable impact to the business, these activities all need to be given dedicated attention, even if the attention isn’t coming from a dedicated resource. So if you don’t hire a sys admin, those responsibilities still have to go somewhere. And that usually means tradeoffs in terms of productivity or quality or potentially both. The other consideration I’ll throw out is that, in a lot of organizations, it can be easier to get budget for contractor support than headcount. It’s also easier to contract out part-time system admin work than to find a direct part-time hire. Together these facts help bolster the business case for this type of support, especially when you can demonstrate the value a sys admin will bring (or the risk inherent in not having one).

 

5. Has your organization used a Portfolio Project Management (PPM) tool in the past?

Workfront is a complex and powerful PPM tool. With that being said, a Workfront administrator has the knowledge and capabilities to configure your Workfront instance as efficiently as possible. When thinking about the cost-benefit of sourcing a sys admin versus using someone from your existing team, don’t discount the learning curve required to truly become an expert. And not just an expert in Workfront. But an expert in PPM methodology as well—object hierarchy, object relationship, etc. And then think of all of that in the context of having to manage and administer Workfront as part of a secondary responsibility. It’s sort of like trying to fly the plane while building it……while trying to learn to fly…..while trying to learn to build an airplane. A Workfront system admin is someone who will come equipped with all of this knowledge, helping you drastically reduce the time to value on your Workfront investment.

 

Ok, so DO I need a Workfront system administrator?

A good administrator will know how to configure your Workfront system to maximize user engagement, increase overall tool efficiency, and improve the effectiveness of the system and the way it’s used. They will know the limitations of the tool and when to “customize” objects (i.e., develop new features that are not out of the box features) in order to meet your organization’s demands. And they’ll know how to strategically “evolve” the configuration to provide continued improvements at a digestible pace. In a nutshell, they’ll enable your organization to leverage Workfront to drive tangible business value. So do you need one? Almost certainly.

 

But not every organization can justify hiring a full-time Workfront administrator. Some organizations repurpose an existing role so that part of the resource’s time will be devoted to Workfront administrative duties. Other organizations contract consulting firms like LeapPoint to perform Workfront administrator roles on their behalf. Either way, hiring or contracting a Workfront administrator will help your organization maximize user engagement, mitigate technical bugs and issues, and reduce the time and cost of fixing, maintaining, and updating your Workfront instance.

 

Still not sure? In the next post I’ll delve into more details about what the day-to-day looks like for many admins, providing a discrete list of responsibilities to help the Workfront community get a better sense of the full scope of the role, and discussing how Workfront administrators can help drive continuous improvement for the organization.

 

Want to learn more about system admin support? Contact us at info@leappoint.com.