nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why Small Projects in Jira Can Be Surprisingly Complicated and What We Can Do About It

Ajay Adhikari

I've been working with Jira and Confluence for 2–3 years, and for the past year, I've taken on the role of a Jira Administrator. In that time, I've helped manage everything from massive cross-team programs to tiny internal projects that barely lasted a sprint.

And here's the twist: it's often not the big, complex projects that give me the biggest headaches, it's the small, short-term ones.

You know the kind: “Just a quick task board,” someone says. “We’ll only need it for a couple of weeks,” they assure you. But then the requests start pouring in:

“Can we customize the workflow?”
“I need automation to send a reminder every Friday.”
“Can we track this with SLAs?”
“Is it possible to have a dashboard showing just my team's tickets?”

Suddenly, this “quick” project has a 7-step workflow, 10 automation rules, and feels more bloated than your last enterprise release.

Why Do Small Projects Get So Complicated?

It seems backward, doesn’t it? Fewer tasks, fewer people… shouldn’t that mean less effort? In my experience, not always. Here’s why:

Small doesn’t mean simple. Expectations are still high, and timelines are tight.
The features are still expected. Teams want the same bells and whistles as your flagship projects.
Reusing “big” workflows can backfire. What works for a 6-month rollout is usually overkill for a 2-week sprint.

A Real Example from My Admin Life

We had a small documentation project, just one Kanban board, a couple of contributors, and a two-month timeline. Easy, right?

It started off simple. But then came the custom statuses. Then reminders. Then automation for unassigned tickets. By the time we were done, we had:

7 custom statuses
10 automation rules
3 custom fields
...all for a project that technically had fewer than 50 tickets total

In hindsight, a Team-Managed Project with a simple checklist might have done the job.

What I've Learned (So Far)

Here are a few practical lessons that have helped me bring back the balance between control and simplicity:

Start small and iterate. It’s easier to add structure than to untangle it later.
Have a lightweight workflow template. Something like To Do → In Progress → Done covers most small projects.
Automate what genuinely saves time. If it’s not solving a real pain point, skip it.
Empower teams. Teach them to use labels, components, and dashboards so they’re not waiting on admins for everything.

Final Thoughts

Jira is a powerful tool—but with great power comes great responsibility (and sometimes, great overcomplication).

The real challenge for small projects isn't building advanced setups—it's knowing when not to.

If you’ve ever found yourself building an enterprise-grade workflow for a three-week initiative, trust me, you’re not alone. Let’s keep small projects simple, flexible and useful without losing our minds in the process.

I'd love to hear from you! How do you keep your Jira workflows simple for small projects? Any tips or stories to share?

Comments

Marco Nowak_g3wnkz

Hello @Ajay Adhikari .

Thank you for sharing!

Hello. I know this challenge all too well. Here's my approach:

As JIRA`s strength is the workflow and its features with no doubt, we only setup projects that really need a workflow that covers more than "open - in progress - done". For other requests we have Microsoft solutions and others in our company. So if users just need a small daily task board we tell them to use Microsoft Planner for example.

In addition we have a requirement questionnaire where we ask the user for users involved or expected numbers of issues per month. So if only 5 issues per month are expected, we don`t invest so much effort to develop an individual solution. It`s basically a short ROI contemplation. And this concerns other requirements within a project`s workflow as well. Is it really worth it spending so much time in developing a single workflow feature that only saves the users a single additional click?

For custom fields we use the description beneath the field name to customize them per project using field configurations. E.g. a stakeholder needs a field "Invoice Category" we would create a custom field named "Category" and do the customization by adding the description "Invoice Category" using field configurations. The custom field "Category" can the be reused by other projects the same way. This will reduce the amount of custom fields.

Best regards, Marco

Josh

Great article, @Ajay Adhikari . So true!

Tanya Christensen

Great and accurate info @Ajay Adhikari - thanks for sharing.

I liken this to when someone comes up to you and says "I have a quick question for ya". Your question may be "quick" but the answer may be long and deep.

Ajay Adhikari

Hi @Marco Nowak

Thanks for sharing—totally agree that not every small request needs a full-blown setup. Your ROI-based approach and smart reuse of custom fields are great strategies.

That said, I still lean toward using Jira even for smaller projects when possible. It keeps everything in one place, maintains visibility, and scales better if the project grows. With team-managed projects and lightweight workflows, we can keep things simple without losing the benefits Jira offers.

Appreciate the discussion!

Ajay Adhikari

@Tanya Christensen Thanks! Haha, exactly! "Quick"

Brita Moorus

Such a relatable post - thank you for putting this into words! 💙 I've also found that the smaller the project, the more edge-case requests tend to pop up. I think it’s because people see a small project as an opportunity to experiment, so the admin effort starts stacking up really fast.

One thing that’s helped me, is setting expectations early, especially around what “lightweight” really means in Jira. I’ve started using a few preset templates for short-term work - like a basic workflow with just 3 statuses and a few automation rules.

Would love to hear more about how you decide when to go with a Team-managed versus Company-managed project. That’s still a decision I struggle with depending on how self-sufficient the team is.

Ajay Adhikari

Thanks, @Brita Moorus Completely agree! Small projects often turn into testing grounds, and that “just one more tweak” mindset adds up fast. Setting expectations early is key, and I love that you’ve built out lightweight templates, that’s a huge time-saver.

On the Team-managed vs. Company-managed question: I usually start with Team-managed if the team is fairly independent and doesn't need complex schemes or cross-project visibility. It gives them more ownership and less admin dependency. But if there's shared workflows, reporting needs, or tight governance, I’ll lean toward Company-managed, with guardrails to keep it from ballooning.

Appreciate you bringing up such a common challenge!

Marco Nowak_g3wnkz

We also used an app called "Delegated Project Creator" where it is possible to let users create projects using predefined templates. That was also quite useful for admins to reduce effort for small, standard projects.

Marcell Bendik

In my experience small project are surprisingly complicated because their lifecycle is no that different from a big project:

I have to understand the business environment / process
I have to customize / setup
I have to support for years

In case of a major project, the topic might come up every month. Constant requests, discussions. It keep my knowledge fresh, easy to support. A small custom project would have such a request once every 2 years: at that time every custom solution seems like created by someone else

Another challenge: small project are usually freshly started activity. The needs are not clear, and that creates multiple re-customization. Major projects probably have some background, history, so the requirements can be more clear. That helps the setup & customization process.

Definitely a ROI calculation help to define how much energy we put into the topic. Once the yearly work item number goes over ~10000, even complex customization creates value.

One of our solution is that we create template projects for general activities. These templates have good built-in customization, for example parameters from Asset. For new project request, we offer these templates with he built-in customizations. For any additional customization, they have to provide strong ROI calculations / business needs. At the end our service request project are very similar, so we can meaningfully support them.

Welcome!

It looks like you're new here. Sign in or register to get started.