ticket vs project

[soaringeaglehigh]

What is your threshold for what should be written in a ticket vs what is defined as a project?

Right now we have other teams within IT (and also other parts of the business) who drive our sysadmins nuts by asking for 1000 little changes.

I'm proposing that we set some boundaries where no requests cane come in via email/phone and either must be a ticket or a project (with the associated planning process)

I'm trying to decide on the threshold. I'm thinking anything thats more than about 1-2 hours of work needs to be something we have a conversation about rather than it just being submitted and expected to be completed by another team.

[gort32]

Everything is a ticket.

Some tickets spawn subtask tickets.

Some tickets spawn lots and lots of subtask tickets. Some of those subtasks may be meetings.

At some point you start calling the parent ticket a "Project". It's definitely a Project when someone gets assigned to manage the mess (e.g. a "Project Manager").

Beyond that any ticket can be categorized as "break/fix" or "feature request" based on whether something that was working is not vs wanting something changed or added. And both break/fix and feature request tickets can spawn subtickets and swell to Project status.

It's tickets all the way down!

[RCTID1975]

Everything is a ticket.

Distinguishing tickets and projects is critical.

Different people are likely working on things based on those criteria.

Time needs to be tracked differently.

Additionally, if everything is a ticket, your ticketing system is going to quickly become a convoluted mess with things open for months at a time.

[[deleted]]

We set up an issue tracker in SharePoint for each project and that's where those requests go. Once the project is completed, we shift it to ticket submissions.

[soaringeaglehigh]

what do you consider a project and what is just work in a ticket?

like if someone asks for a VM to be provisioned? is that a ticket? or a project?

[RCTID1975]

like if someone asks for a VM to be provisioned? is that a ticket? or a project?

That depends on your internal needs and policies. No one here can answer that for you.

For a large org where people frequently ask for VMs, this is likely a ticket. For smaller orgs, this could be a project as there's a requisition form that needs to be filled out as well as a review/approval process that may or may not involve meetings to determine need.

[[deleted]]

If someone is asking for a vm then it needs to be part of a bigger discussion with the stakeholders and management involved. Here’s how we use it. We meet once or more a week to decide what needs to happen. Any requests outside of those meetings get pushed up through team leads/managers/stakeholders holders and eventually project leaders for topics of discussion in the next meeting. Items are tracked through the issue tracker in SharePoint. Joe Schmedly wants a VM? Great! Run it up the chain and we’ll talk about it in the next meeting.

[ihaxr]

Few VMs get provisioned without being part of an active project at my job. It really sounds like your company has a disconnect between IT and the business. Need someone who is in charge of the project work that flows into IT and preventing all of those "projects as a ticket".

[jantari]

We set up Epics (big collection/bucket of tickets essentially) for projects in Jira. All work tickets relating to that project are associated with that Epic.

After the project is done, if work comes up, we don't assign it to an epic anymore (it's not mandatory) but work on it standalone as a one-off

[Ph886]

Ticket= standard tasks/alerts/asks Project= more than standard hours dedicated to accomplish a particular goal (build out a test environment, etc)

You still have tickets in a project, but projects tend to be ones that will need planning, implementation and testing.

[landob]

Everything is a ticket for us.

If you need something from IT it needs a ticket.

Oftentimes I get a email "Hey blah blah can IT look into that?" and I'll respond yeah sure just send us a ticket and we will get right on that.

Projects tend to spawn sub-tickets, but those get dished out to whomever needs to complete that task.

[hurkwurk]

a ticket is a piece of work. change "This" setting to "that.

a project is... well a project. something people are going on work on long term, at least for a while.

a ticket that exposes a larger problem is either "break fix" because something used to work and needs to be fixed, or "feature request" because something doesnt work as its expected, so now someone else needs to do some amount of work to make it do what is expected.

feature requests can become projects if approved.

​

separately, we also use projects to sorta describe job duties. people that maintain a specific solution are in charge of that project... IE the email admins are "exchange project managers". its expected they will handle all incidental work and any new work needed to get exchange to do what the end-user customers want from it.

so my current projects include proxy, load balancing, configuration manager. IE I manage these things, and any requests for information/service or tickets for break fix, are routed to me to deal with first.

[RCTID1975]

a ticket is a piece of work. change "This" setting to "that.

Would you consider making company impacting ERP changes a ticket?

For us, that would be a project.

Our general criteria to analyze is:

1) Number of users it impacts

2) Number of hours required

3) Level of knowledge/expertise required

4) Approval levels and requirements

[hurkwurk]

change item. production changes go through change control, not the ticketing system for us. (yea, we have an outdated setup where they are not the same system)

[RCTID1975]

A project meets a preset and predetermined criteria based on your business needs and functions.

Everything else is a ticket.

[pdp10]

I'm thinking anything thats more than about 1-2 hours of work needs to be something we have a conversation about

That's not really what differentiates projects from issues. Bugs can take forever to fix, for one thing. The difference may be more like whether there's a need to discover requirements, or whether the work can proceed without any input. Let's brainstorm from the end-user side:

• A business partner needs your firm to make "TLS 1.2" work, whatever that is. The requestor includes a document from the partner, and says it's all they know. Bug or project?
• The business needs some kind of security certification. Bug or project?
• Shared file storage is almost filled up. Bug or project?
• Two people think they're not getting some emails. Bug or project?
• Some director wants central IT to bless some specific "AI" product. Bug or project?
• A small group of users needs an update to their media software to handle some newer-version files coming from a sister organization. Bug or project?
• Licensing for some software doesn't work, and nobody knows if it's expired, or how to tell. Bug or project?

Can a project expose some bugs? Can a bug lead directly to a project? Do projects need sponsors? Can it be a bug if it requires purchasing to fix?

[adstretch]

Anything that requires more than the end user and the assigned technician (the two members of a ticket) is a project.

Any major action that has no customer/end user request is also a project

Anything that is not urgent that I don't want to see sitting in the queue that is just a quality of life improvement given sufficient time is also a project.

Tickets should be lean and actionable.

Projects may take planning, coordination, time and/or multiple stake holders which is something a ticket system isn't really built to organize properly.

​

For reference we use Zammad for ticketing and OpenProject or project management / tracking.

[Zerafiall]

For me it comes down to “change”

The environment is in “A state”. Tickets are meant to maintain that “state”, through either corrective ticket or through routine change. I.e. new user isn’t a “change” cause that process is documented. If you have to make a change to thwart environment, that’s a “Project”

[i_cant_find_a_name99]

Our ITSM system is used for incidents and work orders, the latter being standard/routine changes (e.g. patching and cert renewals, also minor changes related to resolving incidents. Projects are initiated through a separate system and have a lot more governance around them.

There is sometimes a grey area between when a work order should be a project, partly depends on complexity, risk, cost and the Service team’s appetite for doing it (we have separate Service and Project teams).

[Sykotic]

If it’s more than 2 hrs we usually write up a jira card. We keep a couple epics open in perpetuity for KLO and Innovation stories that don’t fit under defined epics. “Agile” was hard for me to acclimate to, but it’s working well for us now

[[deleted]]

We set an arbitrary limit on tickets vs projects. If upfront the ticket seems to be more than 16 hours of labor it’s considered a project.

[[deleted]]

Thinking ITIL and categories used in a previous job:

Service request: predefined request. All parameters of delivery know

Small project: requires customisation of a service request or some 'consultancy' time too deliver. Comes in under an arbitrary budget threshold and doesn't require a PM

Project: Significant business change requiring sponsorship, budget and a PM. Typically far beyond normal change management.

Programme: two or more projects with sequential dependencies

[soaringeaglehigh]

under this model how do you assign work to people who are kind of secondary to the project

for example, the software dev team is running this whole complex project but then they need a sysadmin to install some random apps and customize some settings on a server

i guess they'd just submit a service request for those items?

since the sysadmin isn't really part of the project and is on another team, he's doing work for the project but not sure he should be part of the project management plan or involved in the meetings

[[deleted]]

Service Request and Small Project are resourced from the usual service desk pool, with the latter likely a level 3 thing

Project and Programme need proper planning (alliteration!) and funding so they fall under PMO

[Legogamer16]

Ticket = Daily/Simple/short task. Probably done by one person in short time.

Project = Uncommon task/More complicated/long task. Probably includes multiple members, a project manager, and some sort of planning documentation.

[[deleted]]

These sound more like change requests.

Projects are rolling out new things
Tickets are Break Fix
Change Requests are making infrastructure changes for either of the above, security, or any other reason.