Tip Jar Topic: Task or Issue?

[Doug_Den_Hoed__AtAppStore]

Hi Folks, A few of my Workfront colleagues and I have been kicking around this interesting philosophical topic over the last couple of days, so I decided to share it in community and ask for some Wisdom Of The Crowd. I've changed the names to protect the (don't you believe it) innocent. Regards, Doug --- On Fri, Mar 16, 2018 "Craig" wrote: Ok, this is perhaps a philosophical/moot question, but why the heck can't we have a % complete field on Issues? What would that break or complicate? Yes, I know that I can add one with custom data. I'm just wondering if someone in product development could explain to me why it's not built in. - Craig --- On Fri, Mar 16, 2018, "Tim" wrote: Agree with Craig - even planned work is completed in chunks. Another idea in lieu of a custom form would be to create few custom statuses, such as "In Progress - 25%", "In Progress - 50%", "In Progress - 75%". Best, Tim --- On Friday, Mar 16, 2018, "Derek" wrote: From a philosophical perspective, if we're at a point where we're tracking % complete on an issue - wouldn't we convert it to a task? Derek --- On Mar 16, 2018, "Dawn" wrote: Hmm…excellent point. I concur with Derek Regards, Dawn --- On Sat, Mar 17, 2018, "Craig" wrote: I see that in some cases, but if you're using request queues to support a help desk, what, besides the percent complete aspect, would be the benefit of converting it to a task? Some help desk items might require a weeks to accomplish, e.g. replace all the keyboards on the 3rd floor. It'd be nice to monitor the progress during that time. --- On Sat, Mar 17, 2018, "Tim" wrote: Great points everyone. Here are some more thoughts... When organizations want a clear separation between planned work and 'unplanned' work, it makes sense to leave the issue as an issue. Further, sometimes you don't want it to be 'scheduled' or count towards the project percent complete / earned value calcs. I try to avoid converting issues to tasks when not needed since the custom form cannot be matched / pre-attached and the issue is always deleted so there are key details that are lost if not pulled by a calculation (that could be difficult for the customer to maintain). Best, Tim --- On Sat, Mar 17, 2018, "Dawn" wrote: Now THESE are the circular philosophical discussions that make cracking my laptop on a Saturday worth the trouble! Great stuff! On my home planet, ancient law defined the question of Task vs Issue was whether the item in question would or could affect the Project's timeline: Tasks (might) push, but Issues cannot . Over centuries, across many industries, the universality of this wisdom proved itself out; including the sage corollaries to err on the side of Issue whenever possible (the ancient when in doubt, leave it out ), but to not ignore the reality that sometimes Issues morph into timeline-affecting Tasks (the similar don't fight it: re-right it ). I'd like to share this thread with community, so we can get some more Wisdom Of The Crowd. Provided I remove emails, last names, etc. for privacy, any objections? (Dawn: waited a while...no objections) Regards, Dawn Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[William--]

There is an additional constraint not addressed in this thread, about approvals. If you are capturing approvals for unplanned work to go forward, you typically don't want to lose that documentation. But converting the issue to a task will strip the approval path. We have some request queues where approved requests spawn a small handful of tasks. For the moment, we add a summary task to the request queue project with the same title as the approved request. We then add and assign the few children tasks that need to be done, and move the original approved request from the project level down to the summary task to keep everything bundled together. This allows us to see the % done, assign different parts of the request to different resources, and preserve the request in its original state with forms and approvals. We try to add in a few efficiencies such as categorizing the summary tasks within larger parent tasks (e.g. Alpha Requests and Gamma Requests). Since the children tasks are always the same and assigned to the same resources, we use the Duplicate task feature and re-title it before moving the request down from the project level. As far as reporting goes, we don't have a need to exclude these tasks from the project timeline, but perhaps that could be done by attaching some fields to the hybrid task/issue (tissues?) and filtering them out in reporting. William English

[JasonMa]

While we very rarely convert an Issue into a Task, I would agree that the term "In Progress" does not do an adequate job of relaying exactly where an Issue is at in the life cycle of getting resolved. For us, there is a little bit of a chicken-and-the-egg problem. It would be great to have people update the % complete on an Issue so as a PM I would know the state...BUT our folks are so opposed to updating Workfront that almost all of our Issues are assigned to the PM as we are the only people who bother to update them. It would be nice if it was there as an option but in the long run probably wouldn't really get used enough in our case. Also, and I'm not sure what types of Project Issues others have (meaning Issues not spawned from a queue), but a lot of our Issues are very analog. For example, "Approval for item X has not been approved by the Sponsor" The item is either approved or it isn't. Its state is either 0% or 100%. I would say those types of Risks/Issues make up half of our total. Jason Maust McGuireWoods LLP