Tip Jar Topic: "Anybody" or "SysAdmins Only" For Report Creation?

[Doug_Den_Hoed__AtAppStore]

Hi Folks, Another excellent topic popped up among my Workfront colleagues this week: when it comes to building Reporting, is it wiser to let Anybody create them as they need them, or to formalize that responsibility and centralize it with the SysAdmins Only ? So top up your beverage, and settle in for another (mostly anonymous) episode, as below. Regards, Doug ------------- Hi everyone - I'd love to hear your thoughts about Reports Management in WF. So, I just got done speaking with a customer who is trying to determine the best way to manage report creation in Workfront over the long term. When considering whether or not to allow each PM to create their own reports vs. assigning one person on the team to create them, vs. only sys admins. The list of pros and cons seems endless. I suggested that they "start small and scale gradually" and we discussed what that meant (e.g. one-to-three report creators per "group" or "process", governance, etc). Ended up being a very thought provoking conversation. Approaches Discussed Set up a report request queue Hide "built-in" reports via Access Level, if reporting becomes too excessive (determined more of a struggle for Enterprise, or shared/multi-group, instances) Send a report of reports to others within the organization to spark idea - less reinventing the wheel should they find something similar Build a reporting gallery layout template to walk new groups through to show what's possible. Then copy and apply. Wanted to get everyone else's thoughts/best practices/suggested approaches on this topic? "Justin" ------------- Hey "Justin", The reporting functionality is one the most powerful pieces in Workfront. Any user with a plan license can analyze their own metrics, quickly find relevant information, and personalize their own dashboards. The ability of a user to customize the software themselves is one of the "big three" requirements for successful adoption - the other two being formal training and team created rules and norms. I hesitate to ever limit a users ability to create reports. Rather, I suggest that admins create a naming convention for the reports that are shared with groups of users and put those reports on clearly defined dashboards. I also teach admins how to run reports on reports and to create filters for reports. A naming convention and a filter will quickly remove superfluous reports from the admins view. Audit reports can help to identify reports created by users who are no longer active in the system and are not widely shared. This is similar to auditing custom fields that are no longer used on forms. There never needs to be a limit to how many reports are in the system nor should users' ability to create reports be restricted. This is a critical part of user adoption. It also allows users to share the power of Workfront with their colleagues. Almost always it is the "marvelousness" of reporting that hooks a neighboring department into wanting Workfront! CARRIE MCCLOUD Sr. Consultant - Application Design Expert Workfront [NOTE: used with permission] ------------- Hi Carrie, Your "Big Three" comment caught my attention. It sounds like you have some wisdom, and I'd like to learn more about it. Would it be possible for you to elaborate to me (and/or Field Support)? Regards, Doug ------------- Doug Den Hoed, you asked for more detail about the "big three" concepts I mentioned in another field support thread. Happy to share! Synopsis here for anyone interested. When I worked at the University, my research partner and I conducted a study to investigate the effort required to implement a project management tool. Specifically we used a three prong attack: Looked at theory and previous research related to virtual teaming and software user adoption Conducted a survey among PMI members Analyzed marketing approaches for software companies The PMI International Research and Education Conference selected us to present in Ireland, which also exposed us to some fantastic wisdom on the subject - awesome conference! We learned several aspects that directly related to successful implementation, including what I refer to as "the big three". Throughout the research and the survey responses these three factors were stand outs in their impact on adoption: Ability of the user to customize the interface - End users that had a tool completely configured for them with little say in the matter had very high dissatisfaction levels. Users that had some control over the settings and the ability to customize the tool had higher satisfaction and adoption levels; Formal training - It was important that training not only be made available, but that direct managers and supervisors encouraged and endorsed the time needed for training. Users that simply had "access" to training were not as successful as users whose managers explicitly made time for training and supported their team in learning the tool; Teams creating rules and norms around how the tool is to be used - Teams that did not take the time to specify the details of their processes or validate the "what if" scenarios, were significantly less successful than teams that talked through all of the "what do we do when this happens" situations and created rules and norms for using the tool. In other words, if users didn't know what to do in a given situation, then they would do nothing and the tool was not adopted. Another take-away was the expectation of time commitment when implementing, especially remote vs. face-to-face. Virtual teams can perform at the same level as face-to-face teams, but it takes more time for them to reach the same level of performance - primarily because the time involved in building trust. We learned that a face-to-face meet at the beginning of a project is the most effective way to reduce this time. For long projects, another face-to-face meet halfway through. I think you know my research partner, "Bubba"... Warm regards, CARRIE MCCLOUD ------------- That last "take away" is HUGE in my mind - and often has a direct impact on Carrie's "big three". Albert Mehrabian, a pioneer researcher of body language in the 1950's, found that the total impact of a message is approximately: 7% verbal (words only) and 38% vocal (including tone of voice, inflection, and other sounds) and 55% nonverbal. The "cost" of not establishing genuine trust versus the "savings" of virtual meetings is an interesting dynamic as we weigh the short-term spoils of the transaction versus the long-term potential of the relationship. Looking forward... "Miles" ------------- This is great stuff. Is there a "long form" somewhere? I'm dealing with this right now, and would love your detailed insights. Thanks, and great work! "Cassidy" ------------- Awesome Carrie - thanks so much! Regards, Doug P.S. my apologies for the delay in responding; I'm conducting all-day executive coaching, and just catching up on emails now, from the bottom up, obviously. ------------- Really solid work Carrie (and research partner...) The sad part about #1 is most customers think having the system configured for them is better service. Convincing a team regarding the value of their direct influence and involvement in the building process is a rare skill. It's easier to just do the work and hand it off. The more challenging thing to do is effectively "sell" the client on the necessity of their involvement. And then having the maturity and patience required to take the navigator's seat without becoming the annoying back seat driver who finally yells, "[DANGIT]!!! JUST PULL OVER AND GET OUT! I'M DRIVING THE REST OF THE WAY!" ... Well done both. "Timothy" ------------- This is a really great thread! Carrie - thanks for sharing this with us! "Dave" ------------- Hmm...Carrie, last weekend we had another juicy conversation on field support around Tasks vs Issues, which I volunteered to sanitize (fake names, no emails, etc) and post on community.workfront.com in order both to share, and to ask for further Wisdom of the Crowd. I think this thread is similarly worthy, and offer to do so again (presuming there are no objections). Shall I refer to you as "Cora" for anonymity, or would you prefer that I use your real name so people can complement and tag you? Regards, Doug ------------- I'm fine to use my real name, thanks for asking Doug! CARRIE MCCLOUD ------------- Just remember, Bubba is spelled with 3 bs. "Bubba"

------------------------------
Doug Den Hoed - AtAppStore

Got Skills? Lend a hand!
https://community.workfront.com/participate/unanswered-threads
------------------------------

[ChristineFe]

Hi all, I had originally opened up reporting to everyone, and I found that it got really messy fast. Two of the main reasons: 1) people are busy and they would start a build a report and never finish; and 2) they thought they knew how to build a report and couldn't and wouldn't ask for help. These two reasons created a lot of unfinished reports that nobody used. In the end, I restricted report creation to just system admin(s), and it took me a while to clean up the system of all the unused, half built reports. Hope this helps! Christine Fecik Creative Traffic Manager Workfront System Admin Elekta

[AnthonyIm]

Hi Doug, Personally Kathy & I don't care if they want to create their own reports. We want them to get the information out of Workfront the way they want. The issue we are more worried about is that they will spend a ton of time trying to do something that takes us only a few minutes (since we know the tool better). Understanding the data structure of Workfront and what all the different parts of a report mean/can do takes time and we have a lot of groups that are currently understaffed so there isn't a lot of time to learn this feature of the tool. We recommend to our users to submit a ticket through our internal Help Desk Queue so that Kathy & I can work on it for them. But we'll let them take the first stab if they want. They should just if they get stuck or to quickly double check it to make sure it is showing them exactly what they want. (People get really confused with Assigned To versus Assignment Users on a task report) Anthony Imgrund FCB

[pco88]

I'm with Anthony on this one that I don't really think it's an issue whether the others with plan licenses create their reports, I would encourage it if they want to learn how to do it. But for the most part, report creation/innovation falls on the systems administrators. I don't see their report creation mess (the ones that are incomplete and unused) anyway unless they share with me (I cannot remember the last time somebody shared any with me) and I don't even look at those myself. With the report usage stats, clean up should be easier when/if I have the time to look at it since we can see what's not on a dashboard and when's the last use. If the user can't recall the report, I'd just put it a holding cell to remove at a later date. So I say when it ain't broke, don't fix it. Polly Co

[DanielCo]

Also, now that we can report on report usage, we can more quickly zero in on reports that are not used (i.e. half finished reports or one time use reports). Daniel Cooley Kenall

[TerryHy]

Ditto on what Anthony and Polly outlined. When we first rolled out, I listed Report Creation as one of the education classes that those with a Plan License should take/recommended, although it wasn't required at the time. They first had to get through those 3 hour long Work Management education classes (remember those…before the new Ascent). And, at that time, I just wanted to get them used to the 'basics' in Workfront before they dove into creating reports. I agree that the Reporting functionality is super cool and robust, but it does require a fair bit of knowledge about Workfront itself and the particular nuances of the reportable fields (not to mention text mode, which is a whole other sphere of needed knowledge). As Anthony mentions, I can't tell how many times I've had to explain the difference between "Assigned To" and "Assignment Users" field functionality to others, and that alone took me a few days to figure out before I had an a-ha moment on it (and that is after being in the system for a few months as a System Admin). A few of our Plan Licenses have picked up on creating reports, but at some point during their report building, my intervention was/is needed in order to help them finish the report, e.g., fixing an incorrect field, helping them with grouping, potential text mode applications, etc. It is often easier for me to create the report, as I know a bit more about the system. We have a queue that users can submit a "new report" request or "edit report" request, whereby I can help work on it for them. By far, new/edit report requests are my top requests and also the ones that take the longest amount of time to do. My overall main concern is that I don't want them to spend hours trying to figure out how to put a report together and end up getting frustrated with it. For those that want to try creating a report, I tell them to give it a try if they want, but submit it to the queue after a little bit of time, if they can't figure something out. I am also looking forward to using the new report usage functionality to do some housekeeping on our reports. Terry Hynd EBSCO Information Services

[PatrickHa2]

We don't limit it to Admins only, but don't open it up to anybody either. Instead we identify team leads and SMEs that we think could help create reports. We do have a dedicated admin for our Workfront instance, but it's not totally sustainable to think he can serve all needs all the time. It's important that you standardize the input of work into your system to make the the creation of good reports as efficient and democratic as possible. Think naming conventions, controlled vocabularies, and a standardized and universal taxonomy. Patrick Haywood Plantronics, Inc.