The heavy marketing focus of Workfront - are traditional PMOs concerned about Workfront's product direction?

[DavidCo3]

Hi, Around 9 months ago when we first engaged with Workfront there was no strong marketing focus apparent to us at that time, and in all sales and investigation sessions, Workfront was promoted as being a system for Work and Project Management to cover all areas of an enterprise (IT, PMO, and of course Marketing). However - especially over the last 6 months or so - with the aquisition of ProofHQ there seems to be an increasingly heavy focus on Marketing for Workfront. e.g. Look at the Youtube channel.....the majority of recent videos are marketing-related. Mobile app download sites for Android and Apple both refer to "Marketers" instead of users or team members. The landing page on www.workfront.com says " Finally, a Work & Project Management Software For Marketers" To be honest, this makes me a bit uncomfortable because Marketing is only a small area of our global business, and at this point our marketing team don't even use Workfront. We bought into the Workfront solution to run our whole business, and I am concerned that Workfront will lose focus on maintaining and enhancing the features that matter to the vast bulk of our users. I wasn't able to make it to LEAP this year so haven't had a chance to hear directly from Workfront product managers or other users who are closer to Workfront. What is your take on it? Is this a temporary push into the marketing industry to increase the user base, or will the product be progressively simplified and become less suitable for larger and more complex traditional project management? Regards, David.

[GabrielaLo]

I see that some people from Workfront have joined this thread and I read your comments about your strategy and how the product should still work for regular projects and such, but the truth is that for those of us who have nothing to do with marketing, it's frustrating to submit our product ideas and get no feedback, and then we join the roadmap calls hoping there will be something for us, and there's nothing, we get a bunch of improvements on design and marketing, but nothing that helps us keep up with the needs of our organizations. There are some other areas of the product that lack critical functionality, and they remain ignored. You have people for customer care and user experience, but how are you caring for me, and what is my experience when my requests are not only dismissed and ignored, but utterly unacknowledged? Ashis is right when he says we are becoming irrelevant on the roadmap, and eventually Workfront will become irrelevant in those organizations that focus on areas other than design and marketing. We have voiced our needs and concerns by submitting our product ideas and we have received no answer. I don't need another note on this thread assuring me that Workfront cares about me. I need someone to take a look at my product suggestions (some of them submitted in 2014 and still unaswered) and address them either by contacting me or by discussing them on the next roadmap call.

[jrieth]

Recycle bin is great for the nuclear scenario where someone deletes a whole project, or a document that otherwise can't be replaced, but as Jason Maust pointed out, the ability to move tasks via cut-and-paste, and to Undo drag-and-drop or cut-and-paste mistakes, is sorely needed. I have project managers who, because they find the Workfront interface is so punishing, routinely build projects in MS Project, importing them into Workfront only after they are ready for resource assignment. Sad. ~Jeff ~Jeff

[KariHe]

I had the feeling one post wouldn't be enough. :) First - Jason, Lucas, Jeff - Got it ! Thanks for taking the time to make sure I understood this is about undo not undelete . You are all asking for a user experience(UX) enhancement - from your descriptions it sounds like you and your users would benefit from Undo/Copy/Paste when entering and manipulating data in workfront lists. The team responsible for our lists area is currently working on making lists more performant(entering, navigating, sorting, etc) - especially for larger more complex lists with lots of custom data and the team is updating the UI to our new style. The list user experience items you each mention are outside this current scope of work. Undo/Copy/Paste are stories on this teams backlog to address at some point - the more requests we get for this area the better. The number of requests attached to a story is used as an input for prioritizing the teams work. Right now, User Action Performance on lists is the teams highest priority and is what they are actively building. Lucas: You asked for something that I believe is very reasonable. You would like more visibility into the who we designed and built a feature for. I'll talk to the PM team and the content team about ways we can add more visibility into our Product Release Announcements, Product Release Webinars, and our Product Roadmap Webinars. Gabriella: You brought up a topic that my team and I talk alot about and spend a lot of time reviewing and acting on - Feature Requests and our Process around managing them. At LEAP, I did a Theatre session called "Demystifying the Feature Requests Process". Thank you to everyone who attended - I collected a ton of great feedback and ideas on how we can improve this process for our customers. :) Allow me to share a few key points about our current process in an attempt to demystify it for this community group. When you enter a feature request, it gets routed to the appropriate Product Manager on the team for review and decision. **By submitting a request you are giving us permission to reach out to you for clarification and where appropriate ask for assistance in research/ feedback . As PMs review requests, they do one of 3 things Reject the Request - this lets you know that its just not something we plan on doing or addressing. Accept the Request and Link it to an Existing Story/Create a Story on the teams backlog - A story is the teams unit of work - the more requests attached to a story is one of the criteria used in prioritizing the teams work. Close the Request - It's something we have already addressed. We get a lot of requests! There are currenlty 1971 requests in the awaiting decision or connected to a story on a backlog. We recieve an average of 200 requests a week. The PM team believes this is a good thing - it means you are as passionate as we are about improving the product. It also means that we simply don't have the resources to execute on everything we and you would like us to. Nearly everything we complete as a Story has 1 or more customer requests associated with it. Again - the number of requests attached to a story is one of the criteria a Product Manager uses when prioritizing their development teams work. Let me use Gabriella's company as an example... ECOM Atlantic Inc. Requests Summary 8 People have made requests. Gabriella is the most active contributor. 14 Requests - in process for making a decision. 19 Requests - connected to an existing story on our product teams backlogs - meaning at least one other customer has also made a related or similar request . 6 Requests - resulted in a new story being created - meaning you made a request and the PM agreed we should add a new story to the product teams backlog to track and prioritze. 8 Requests were Rejected. We last shipped a story that addressed 1 or more requests for ECOM Atlantic Inc. in March 2016. Following - is a story we communicated in our May Product Roadmap Webinar that has 1 or more of ECOM Atlantic Incs requests connected to it. My last stat - Following currently has 29 customers requests(1 or more of them) connected to it. Swagging the who based on company name - 10 (IT PMO), 9(Marketing), 5(Other), 5(more than one department). We do not currently use type of customer requests attached as a criteria for prioritizing our stories. --Kari

[DavidCo3]

Hi Kari - thanks for the insight into how the feature requests are categorised internally. Perhaps part of Gabriela's concern is the lack of transparency of where the requests are up to. For example, looking at my 66 active feature requests, all of them have a status of "Submitted to Product" and most of them have only had the initial automated reply. I have no idea how many have created a new story, how many have been linked to an existing story, whether they are awaiting a decsion or have been rejected (presumably not given their status). This does lead to the impression that they're not going anwhere, however perhaps this is just a transparency issue..... Regards, David.

[SarahDe1]

Agree with David. Would like visibility of where feature requests stand.

[EricLu2]

<> Well done. This is the kind of meaty communication I thirst for. Thank you.

[VernPh]

I too have been a long term user of AtTask/Workfront and have had the same frustrations with Features requests, i.e., lack of visibility and responsiveness. To that, I would add the frustration of being asked to submit Feature Requests for what I see are bugs. Since I help run a help desk (in Workfront) of a software product, I understand the need to fully communicate with submitters and the frustration they can have if they get no response other than automated emails. Based upon what was presented at LEAN and the responses here, that situation will improve. I frankly just quit submitting because never saw any response (either in status reporting or in actual resolution). Regarding the undelete/undo, I would venture to guess that those who have never accidentally deleted something are in a minority, and if I were them, I would worry that when it happens in the future, it won't be something big. I also have a problem with others deleting something and coming to me for help, or me just not knowing that they deleted something. [I suppose the answer is to prevent anyone from deleting anything, but that is not desired or practical.] So, both of these functionalities are needed and indeed necessary for good management. I've more than once had to go to the sandbox and use it as a defacto backup. I echo what was written about users developing projects in MS Project first because that happens here too, and I've been guilty of recommending it, particularly if the project plan is initially dynamic. We deal with many large projects that, as they are being built, anticipate change, addition, and movement; and, as, has been implied, those actions are very difficult in WorkFront. In some cases, we have found that using the Gantt Chart view provides a better user experience. As has been implied, this situation contributes to a criticism of WorkFront as a product they are being forced to use and does not meet their needs. This illuminates another concern that we have in general, and that is the difficulty that we consistently have with navigating and managing large projects with potentially thousands of tasks. Adding a new task, moving or copying an existing task, or other common PM functions (within or between projects) is extremely difficult. The undo or delete function would not solve all of this, but a copy/paste would go a long ways. I perceive that WorkFront is aware of this and is taking steps to resolve that significant limitation.

[EricLu2]

<> You just hit one of my hot buttons. For many defects, Tech Support frequently tells me the product is working as designed and if I want to submit a product request, I can do that. I ask them, seriously? Someone intentionally designed the Gantt Chart so that when you specify a sort order in the report layout, the Gantt Chart orders everything in random order? That is a requirement that was documented and then coded as designed? I asked what randomizing routine did the product manager specify? No reply. They want me to submit a new product feature request to get the Gantt Chart to sort in the order I specify? Back in the old days, pre-Anaconda (you old-timers know what I mean), you could upload a MS Project Plan to an existing AtTask project and AtTask would figure out what the differences were between the new MS Project plan and the existing AtTask plan. We had so many difficulties with AtTask back in the dark ages, we did all of the detailed project planning in MS Project, updated the project plan in AtTask, and then did all the cool reporting and timekeeping from AtTask. At some point in 2013, I think it was, they took that capability out, maybe as part of moving to the Anaconda release. Ah, the good old days of paying for two project management tools ☺ What I have asked for (long ago) was the ability to save a project with a baseline (or snapshot or backup, whatever), and then later make that baseline plan the current plan. That way, you could save a snapshot of the project plan, expenses, everything, and later, restore that snapshot if you needed to. It should ask you want elements of the backup/snapshot/baseline to restore - tasks, issues, risks, actual hours, expenses, you know the usual objects. That would allow us to keep backups and if the indentation of my plan gets completely messed up, I can restore from a previous snapshot. That would be far more desirable to me than allowing MS Project plans to be used to update a WorkFront plan. I don’t want to pay for two PM tools. Regarding project plans of thousands of tasks, I’d step back and look at the WBS approach being used. I’ve run a few projects that had more tasks than MS Project could handle (back in the day, MSProject was limited to 10K tasks). I might submit that projects over 500 or so tasks become leviathans, difficult to change, difficult to find anything in, difficult to understand, positively indigestible. I prefer following a WBS strategy that decomposes the project into major and minor deliverables, and then create project plans to create individual deliverables. That strategy, however, requires certain technical capabilities in the PM tool. Cross project predecessors are a must (which WorkFront has). What I’d really like to see is the ability to roll up a project into a parent project (I hate to say it, well, I’d like WorkFront to roll up subprojects like MS Project does). The subproject would roll up as a single line item into the parent. You could expand the single line item in the parent project and look into (and edit) the subproject. That way, I can manage a large effort at different levels of abstraction. I can also manage a large effort where subprojects are being managed by other Project managers. That would be a really nifty capability to add to WorkFront. I think that would have general PM appeal across most industries and functional areas. I’m not going to mention how great it would be for Marketing ☺ Thanks for your thoughts, Vern. You really got me thinking there… Eric ________________________________

[VernPh]

Lucas, Thanks for your response. I can see we both have some interesting stories about silly “works as designed” responses and have experienced similar situations. Let’s hope that things have improved and will continueto do so. Regarding your WBS suggestion that is a great idea and, although we probably need to improve, we have made some attempts. The separation into smaller projects tends to be somewhat artificial and perhaps occasionally arbitrary due to the nature and function of the data warehouse. We’ve found that keeping the number of tasks below 2000 seems to work best. When asked by an outside entity why we have taken that approach (i.e., multiple small yet interdependent projects), the awkward answer is that we have to in order to work around project size limitations in Workfront. This then creates the situation of a tool driving a project plan, and PMs (perhaps discretely) using MS Project and Workfront in parallel. We’ve learned to live with it because it may only happen once a year or so, but when it happens the situation is both visible and hindering. The ability to support parent/child or subprojects would solve this and other similar planning problems but I’ve not gotten encouraging responses when I’ve brought that topic up so don’t anticipate that change and don’t see it on Workfront’s roadmaps. We are kind of off topic here I suppose, but perhaps it is helpful for the community to know that there are limitations on the number of tasks that should be in a project and care should be taken to listen to Lucas and break effort down into multiple, smaller projects. Thanks again, Vern

[EricLu2]

<> Those are kind words, thank you. Every software product has limitations and in the end, productive work comes from finding that happy ground where you use the software for what it has demonstrated it does really well and staying away from functionality that doesn’t work well. Yes, there are limitations, but I bet most PMs don’t bump into the task-count limitation in WorkFront. I didn’t know MS Project had a limitation until I hit it and then I had a crisis because my WBS strategy called for it to all be interconnected in the same plan. Eric

[KrisLa1]

Actually, our IT department doesn't use Workfront. It is used by our Product development team including marketing. I have to admit we were happy to see them doing more for marketing side of things becase I have over 100 people using the tool in that capacity. We are using Proof HQ it is ok. Right now we are having some color shifts, but they have been working with us to determine if it is fromt he tool or from our side. I would love to know if there are more people out there in engineering/product development using the tool. Always looking for ways to learn how others use it.

[CynthiaLi]

This is not a new thing for Workfront. I believe they started in the marketing aren a. We do not use Workfront for marketing and seem to be always waiting for upgrades to other areas. Cynthia Little, CCUE Mazuman Project Manager 7260 W 135th St | Overland Park, KS 66233 P: 913-574-5010| F: 816-382-6976 mazuma.org