When To Manage Work as a Ticket vs. a Project

Sometimes, when handling incoming requests, it might not be clear whether the work should be tracked as a ticket or as a project. Here are some tips you can use to determine which makes the most sense based on the issue and your IT service management (ITSM) and project portfolio management (PPM) processes.

What is a Project vs. What is a Ticket?

Projects have a definite start and end. These define the project life cycle. Projects are usually started to generate a product or achieve a specific outcome. The work is unique and does not include ongoing work, operations or processes that follow existing procedures. 

Tickets, on the other hand, are typically used for expected events that come up in the regular course of business such as incidents, service requests, change requests or regular operations tasks. There are processes and resources in place to handle these work items.

Determining a Ticket vs. a Project

So, using those definitions, let’s look at a few examples of requests that a help desk might get, and use some questions to determine if the requests should stay tickets or become projects.

For the first example, let’s say a request is received asking, “Can you replace all of the wi-fi in the library?” Here are a few questions you could ask to evaluate if it should be a ticket or a project:

  • Is this work necessary on a recurring basis? For this example, the answer is no.
  • Does this work require resources and take more time than could be handled in the scope of regular work? For this example, the answer is yes.

Given the definitions we have for a ticket vs a project, we can determine that this request to replace the wi-fi in the library should be handled as a one-time project.

Here’s another example. The IT help desk has received the following request, “My ID card is not scanning correctly in the cafeteria.” Here are the questions to ask for evaluation:

  • Is this work necessary on a recurring basis? Yes. It is common for student and staff IDs to behave strangely, and there are some basic protocols to follow to troubleshoot and fix.
  • Does this work require resources and take more time than could be handled in the scope of regular work? No. As something that comes up regularly, it is considered a regular part of the service desk’s support work.

Based on the answers, and the definitions we are working with for projects vs. tickets, this request would be processed as a ticket.

One other way some organizations may determine a ticket vs a project is to use a list of abstract criteria to determine when a ticket should become a project. That list often includes the following:

  • The issue will cost more than a thousand dollars to fix.
  • The issue will take more than 40 hours of total work to address.
  • There are more than three total departments involved in the issue that needs to be fixed.

When a Ticket Becomes a Project – Defining Project Tiers

The discipline of project management includes many processes that can help ensure that large, risky projects (something like replacing a highway bridge during a weekend, for example) are successfully completed. However, not all processes are necessary for every project.

It can be helpful to define the required activities for every project, plus optional activities that may be undertaken at the project manager’s discretion. Having a defined list of tiers of projects that correspond to the rough complexity of the project can be used as a reference when determining what is needed for your projects. By using a defined list of tiers for projects you can remove ambiguity and create consistency across your projects.

Examples of Project Tiers

If you’re curious about what project tiers might look like in an organization, we’ve pulled together an example list of tiers that you can use as a starting point for defining standard sizes for your organization.

Tier One (Small)

Description:

  • Anything meeting the minimum criteria for a project, such as a significant application upgrade.
  • Could be comprised of projects that involve only one department, and/or cost between $10 and $30k, and/or 40-120 hours of work.

Required project management activities:

  • Project charter
  • Scope change management process
  • Kick-off meeting
  • Regular status updates
  • Close-out meeting
  • Project review

Tier Two (Medium)

Description:

  • Larger/more complex projects. The definition may change depending on the project management activities. Common criteria include the level of risk, number of IT units/teams involved, expected time/duration and level of budget.
  • Could be comprised of projects that involve two to three departments, and/or cost between $30 and $100k, and/or 80-220 hours of work.

Required project management activities:

  • Everything for a tier-one project
  • Work breakdown structure
  • Communications plan
  • A high-level risk management plan

Tier Three (Large)

Description:

  • The largest/riskiest projects for your environment.
  • If projects need to be larger than this tier, consider decomposing the work into several projects grouped into a program.
  • Could be comprised of projects that involve four or more departments, and/or cost more than $100k, and/or 220+ hours of work.

Required project management activities:

  • Everything for a tier two project
  • HR training plan for the project team
  • Detailed risk response planning including appropriate contingencies
  • Clear work package definition
  • A detailed schedule, particularly for the most-constrained people
  • Clear contingency plans (e.g. contingency budget held by a sponsor, contingency tasks)
  • Procurement management plan
  • Quality management plan

The Benefits of One Platform for ITSM and PPM

By bringing ITSM and PPM together on a single platform, you can better understand your resource capabilities and engage in true resource capacity planning.

With resource capacity planning you get a big-picture view of your entire IT organization, allowing you to balance workloads across projects and support; and to see the different types of work that need to be done at any given time.

For example, if you have three IT technicians that need to cover three functional areas of business – like service, projects and operations – you can engage in resource capacity planning and optimize each technician’s workload based on their skill set and their availability. As a result, the work can be completed more effectively and efficiently as each technician is focused on work that plays to their strengths. And because you have a full view of the work and the time it will take; you can avoid overcommitting or underutilizing your resources.

This approach is especially useful when you have limited resources, but an increase in demand for support.

Unique to TeamDynamix, is the ability to also convert an incident or a problem into a project. As the case develops, you can convert it to a project, and from there assign a budget, timelines, and risk grades as required. This gives you a single view of your resources across both tickets and projects – and your end–users and technicians can see all their work in one spot.

There are many benefits to an organization when bringing ITSM and PPM together for proper resource capacity planning, including:

  • Improved IT productivity
  • Improved quality of service (QoS)
  • Improved IT performance measurement and reporting capabilities

To learn more about IT resource optimization and see how other organizations are using ITSM and PPM together check out:

You might also like:

This website uses cookies to ensure you get the best experience on our website. By closing this notice you agree to the use of cookies.