Struggling with managing both "Project" and "Task" based items

We have a space where stakeholders submit requests through a form. These requests fall into about a dozen types—some are complex and should be treated as projects, while others are simple updates that should be handled as tasks.

However, the form lacks the ability to differentiate between the two - allowing only submissions as projects or tasks. We've resorted to projects with custom triggers for specific blueprints based on form responses. But for requests that don’t require a blueprint and really should be tasks, they still come in as projects, just without subtasks. This is frustrating.

A potential solution could be to use the "Change item type" function for these cases. However, using this function strips critical information like the author, comments, and history from the ticket. Instead of truly changing the item type, it seems it duplicates the item and attributes it to whoever performed the "change," which is not ideal. At the very least, the author, or original submitter, needs to be retained - but this field is never editable.

This all causes several issues:

Reporting Challenges: We aim to report on tasks to track specific work team members are assigned. But we either need to do double reporting on projects to include those "project" tasks or risk missing them entirely.
Dashboard Complexity: Team members must maintain separate widgets for assigned tasks and projects to capture all actionable work.

We can't be the only team struggling with these item types, what are others doing to account for this?

Find more posts tagged with

Comments

Glen Turpin

We had a similar problem and recently took a radical approach. There are tradeoffs, but it's working for us.

We realized that we have relatively few large projects that span months, but we have an awful lot of small projects that span days or weeks and are composed of a handful of tasks. So we created a custom task type (called a Job) for these smaller projects and shifted all our forms to create jobs (i.e. container tasks) instead of projects. One of the upsides is that we can now view all our jobs in a Kanban view, which has made it easier to get an overview of all the work in progress across the team.

We still use projects but reserve them for the very large bodies of work, and we often use jobs to group work within a project, so a project is composed of jobs which are composed of other tasks.

Joseph Colliu

Thanks @Glen Turpin, can you share some of the downsides you've experienced with this approach? Off the top of my head, one I can think of is you have less flexibility with views using tasks that are available within projects - most notably gantt and stream views which are helpful with multiple workstreams occurring within a larger task.

Glen Turpin

@Joseph Colliu Less flexibility with some views as you identified and more challenging to re-organize mid-sized bodies of work. You can't select a bunch of tasks within a parent task and move/modify them together, for example. It's also more challenging to connect floating tasks to a job since you can't just tag the task at hand into another task, you have to go to the desired parent and add it as a child. That's a scenario that happens for us quite often, where something starts as a stand-alone task and later something bigger evolves and we want to associate the initial task to the new, larger job.

Joseph Colliu

@Glen Turpin I'm curious, since you moved to a fully task based system, what benefit did creating the custom task type "Job" vs just using the standard task type for everything - the container and all child tasks?

Glen Turpin

@Joseph Colliu The biggest win for us is visibility and prioritization in a kanban-style view at the job level. We don't do many big multi-month projects, but we do an awful lot of smaller, multi-day or multi-week projects (89 active jobs right now), but we were struggling to get a view that allowed us to have a birds-eye view of everything on our plate and the corresponding status of each job. Projects didn't allow us to do that, and viewing all the tasks (691 active tasks now) was too in the weeds. Now, we have a filtered view for "job" task types that gives us that big-picture view of all the work in progress and we can quickly see the status of the recruiting campaign vs the thought leadership campaign, for example, on a manageable kanban board.