Expand my Community achievements bar.

Do you have questions about the migration to Adobe Business Platform? Come join our upcoming coffee break and ask away!

Does anyone just leave request as issues, without converting to the project level?

Avatar

Former Community Member
Does anyone just leave request as issues, without converting to the project level?
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

4 Replies

Avatar

Level 5
Yes, it works fine for small requests. It can be a complete nightmare for larger requests. 80/20 rule needs to be in place. How do you keep the simple things simple and the complex things possible. In an all requests are converted to projects: things that take 5 minutes to do, can take 1/2 hour in overhead. In an all requests remain issues, dates can become confusing, multiple assignees can step on each other or ignore a request, and you can only have one team assigned. So best practice would be, if the request can be done in one step try to keep it as a request/issue. If there is a process to complete the request, convert to a templated project. Melinda On Wed, Aug 17, 2016 at 9:38 AM Chandra N Savage, 08986 < globalforum@communitylists.workfront.com> wrote: > Does anyone just leave request as issues, without converting to the > project level? > -----End Original Message----- >

Avatar

Level 3
I agree with Melinda with one difference. We created a Quick Response "bucket" project for requests that were only 1 or 2 tasks. Project requests are converted to some templated project and task requests are converted to a task and added to the "Quick Response". This way, all requests are tied to a production action and are marked as "Closed" when the task/project achieves "Complete" status.

Avatar

Level 3
We implement a triage process for new issues that can produce at least three different results: The issue is resolved without further action. If the solution is relatively simple, then that can work well. Since we are a software maintenance organization, if the change impacts the system, we won't use this approach since we have a strict change process that must be executed. If the resolution is small, we convert the issue into a task (with subtasks from a template) and put that task into a "bucket" project along with other similar tasks designed for just that purpose. For our environment, a large number of issues can be resolved with relatively little effort and so this works well. The bucket projects support our monthly release cycle. If we created a project for every small resolution, we would have dozens of really small projects created weekly, which is significantly unnecessary overhead. If the resolution requires significant effort, coordination between functions, a lengthy resolution time, or other criteria, the issue is converted into a project. So, our answer is, "Sometimes." Vern R Phipps

Avatar

Level 5
We keep a lot of things as requests to reduce the overhead. In some cases, we're even experimenting with things that take a little longer and involve more than one group. Rather than converting to a project, the request is routed to the first team assignment. Someone there grabs it, does their part, then reassigns it to Team 2, where they complete their work. While this doesnt get us the quick look at the duration for each team (actual or estimated) it does get us the overall time to completion and effort applied. It also reduces some of the confusion that others have mentioned with the requestor looking at and perhaps updating the original request when the work is being done on the project tied to it. Might be nice to somehow lock that original request from having documents or comments added or at least tie them to both objects...