Redmine Best Practices

Introduction

This is not a manual-style explanation of how to use Redmine.
Instead, I will write about the following points when using Redmine (or similar project management tools):

• Things you should pay attention to
• Things you should stop doing (bad practices)

* This also includes things I have heard on Redmine Japan.
* I think these ideas are also useful when using project management tools other than Redmine.

What is Redmine?

Redmine originally started as a tool for IT developers, but today it is a project management tool used in various fields and types of work.

When someone asks me, "What is a project management tool?", I explain it as something that allows you to:

"Write down things you need to do on sticky notes, and remove them when they are done"

• with the help of IT, and
• in a more systematic way.

The sticky notes are Redmine tickets, so it basically means:

1. Write what needs to be done in a ticket.
2. Remove it when it is done.

Remove tickets

So, if I had to give one purpose of using Redmine, it would be:

"Write tickets and remove them."

* If you can make removing tickets feel good through gamification, it becomes easier for people to keep using the tool.

• Remove your own tickets
• Remove other members' tickets too
• Keep records

At the same time, properly record the actions taken to complete the tickets.

To make tickets removable

If the number of tickets that cannot be completed keeps increasing, people's motivation will not improve, and use of the tool will not be encouraged. To make tickets easier to complete, pay attention to the following:

• Create tickets at a manageable level of granularity Tickets that cover too wide a scope (are too large in granularity) cannot be easily completed.
  → Split them into child tickets (create them at a granularity that can generally be completed in a few hours to a few days).
• Do not write multiple tasks in one ticket Even when leaving records (comments), it becomes difficult to tell which task the work was for.
  → As above, split them into child tickets with an appropriate level of granularity.
• Create tickets with clear completion conditions With a ticket such as "Improve operations", it is unclear what needs to be done before it can be completed.
  → Create tickets that describe the actual actions that need to be performed, such as "Do XX to YY", and make the completion conditions clear.

Visualization

Keeping records makes visualization possible. Visualization is important.
Be conscious of what you want to / should visualize. If this becomes unclear, you may end up with unnecessary information or fail to capture what you actually wanted to visualize.

This depends on the project, so it is difficult to say "this is the answer." Here are some examples.

The following is an example for a development project.

• Things to do (or things that should be done)

  • Write them in tickets (pay attention to granularity)
  • Assign someone responsible (if undecided, assign it to the project manager or whoever is responsible for making assignments)
  • Set a period (a tentative period is also fine)
  • Give it an appropriate title
  • Write a sufficient description (overview)

• Schedule
  By recording the period and progress percentage in tickets, they can be visualized as a Gantt chart.

• Task status

  • Properly write the work being done in comments. Change the status and assignee as appropriate.

Things to Pay Attention to When Operating

• Do not divide settings too finely
  When operating Redmine, it is tempting to divide various settings into many detailed categories.
  However, the more finely you divide them, the more the cost of configuration, operation, and maintenance increases. I recommend not dividing them more than necessary.
• Basically, do not directly reflect the organizational structure
  It may be fairly common to structure the data based on actual departments and positions at the beginning, but doing this will often fail or make management difficult.

A project management tool is not a tool for managing the organizational or job-position structure within a project. It is ultimately a tool for handling tasks.
I recommend defining only the minimum necessary and efficient trackers, statuses, roles, and projects needed for the purpose.
Start with the minimum and change/improve things as necessary.

The following are some specific examples of bad practices.

Do not create too many trackers

A tracker is a category for tickets, so let's create a separate tracker for each type of work.
→ "Let's create separate ones for each type of work/department!"

This is fairly common.

* A Redmine tracker has the characteristics of a form (it has input fields and an approval workflow).

But often,

you create many trackers, only to find that they actually have the same workflow.

• If the input fields and workflow are the same, there is a high possibility that the same tracker can be used.
• The more settings there are, the higher the management and maintenance costs become.
• It becomes painful when you try to organize them later.

Too many input fields

I said that a tracker is like a form, but
it is also easy to end up with a situation where you keep adding custom fields until you no longer know what needs to be entered.

• There are fields that are ultimately not filled in.
• There are fields that have become merely nominal and are not actually being used.

Unless you plan to use the information later for analysis or aggregation, it is often sufficient to simply write it in the ticket description field.

If there are items you want people to enter (but do not need to analyze), use the Issue Templates plugin.
→ This also helps prevent a proliferation of trackers.

* Apparently, some systems actually have around 100 input fields... hell.
* I have seen trackers with both an assignee and a person responsible for handling the ticket. What is the difference?

Keep statuses to the minimum necessary

Making them more detailed than necessary makes things difficult to understand.
→ A good state is one where someone who has just joined the project can understand which status to select.

• Have you organized the actual workflow?
  Some statuses exist in actual business operations but are unnecessary in the system.
  Stop creating statuses when it is unclear whether they are really necessary.
  You can always add one when it actually becomes necessary.
• Do you really need a status where no assignee can be assigned?
  → This makes it more likely that tickets will not be completed.
• If there are multiple statuses that occupy the same position in the workflow (for example, separate ones created for different departments), consolidate them.

* Apparently, some systems actually have around 30 statuses... Can you really understand and keep track of that workflow?
* Redmine can also be used as a Kanban board by adding a plugin, but a Kanban board with 30 statuses would be chaos...

Stop subdividing roles too much

"It is not good for too many people to be able to see things. Let's use roles to divide permissions in detail."
→ I have seen places where roles are created for each job position...

PM? PMO? PL? What can each role actually do in Redmine?
→ Roles with clearly defined responsibilities, such as approver, reviewer, and observer, are better.

* You do not need to create roles based on job positions, such as "these permissions because they are a PM" or "these permissions because they are a PL."

What about workflows?

There is one workflow for each combination of role × tracker.

The more there are, the harder they are to manage.

For workflows that are the same, try to handle them with the same tracker whenever possible.

• Task (no approval required)
• Customer approval task
• Manager approval task

If the workflows are the same, such trackers should be consolidated so that the same tracker can be used even when work crosses departments. This makes things easier to understand.

Do not unnecessarily subdivide projects

It is common to have "one project per case"...

If using "Versions" is sufficient, use Versions.

• Redmine also makes it easy to integrate with source code.
  → By using appropriate plugins together, it is possible to configure a Subversion/Git repository server on the Redmine server.
  → I recommend associating one product/service with one project.

If you have a project such as "XX Service - YY Improvement", you can create a "YY Improvement" version in the "XX Service" project. This allows you to divide the roadmap for each product/service as needed.

• GitLab Milestones work in a similar way.

Structuring by organizational hierarchy is a bad idea

This is common.

But what if a project needs to be carried out collaboratively by multiple departments?

→ I recommend structuring projects by case.
However, if the phases are different, consider whether the problem can be solved by using Versions instead of unnecessarily splitting the project.

How should Versions be used?

Basically, I use Versions to divide a project by period.

It seems that some people use them to divide projects along axes other than time, but

if you later need to divide something by time, you will no longer be able to divide it appropriately. Therefore, do not use this approach except for projects where such a requirement will definitely never occur.

Adding too many members

Was it too much trouble to think about? There are way too many members, aren't there?

Basically, only add people who are actually involved in the project as members.

Want to let someone view it only?
→ If a public project is sufficient, that is enough.

Conclusion

Especially when starting operations, when adding trackers, statuses, or roles, you may sometimes think:

"I added all these fields! It's perfectly structured to match our company, and the workflows are reflected too. Awesome!"

But you may simply have failed to analyze or abstract the actual business processes.

Think about ways to make things work well with fewer settings.

Having detailed settings and properly abstracting business processes are two different things.