This guide is for students who already know how to use Vikunja and are starting to take responsibility for a team project.

If you are new to tasks, comments, labels, assignees, or problem reports, start with Using Vikunja. This page is about the next step: using those tools to lead work for other people.

Project management means turning a goal into organized work, keeping that work visible, and helping the team make decisions before confusion becomes a crisis. A student project leader does not need to boss people around. Your job is to help the team know what matters, what is blocked, what changed, and what needs attention next.

What changes when you lead a project

When you manage your own tasks, you mostly ask:

• What am I working on?
• What do I need next?
• Is my task done?

When you help manage a project, you ask broader questions:

• What outcome are we trying to create?
• What work has to happen to get there?
• Who owns each next step?
• What is blocked?
• What is risky?
• What decisions do mentors or team leads need to make?
• What should be true by the next check-in?

That shift matters. A project leader pays attention to the whole path from idea to finished result, not only the task they personally touched.

Start with the project goal

A project should have a clear goal. The goal tells the team why the work exists and how to choose between options.

Weak goal:

Improve autonomous.

Stronger goal:

Create one reliable autonomous routine that leaves the starting area, scores one game piece, and can be selected by the drive team before our first competition.

The stronger goal names the result, the users, and the deadline pressure.

Before creating many tasks, write a short project summary in Vikunja or in the first planning task:

1. Goal: What should be true when the project is successful?
2. Reason: Why does this matter to the team?
3. Deadline: When does it need to work?
4. Owner: Who is responsible for keeping the project organized?
5. Definition of done: How will the team know the project is finished?

Example:

Goal: Build a working pit display for competition.

Reason: Visitors, judges, and team members need a clear way to see robot status, match schedule information, and team materials.

Deadline: It should be ready before packing night.

Owner: Maya owns the project board and check-in updates.

Definition of done: The display runs on the pit screen, starts without mentor help, shows the final content, and has been tested for one full meeting.

Break the project into deliverables

A deliverable is something the project produces. It can be a feature, document, tested mechanism, event plan, or finished setup.

Tasks are small pieces of work. Deliverables are the larger results those tasks create.

For example, the project Pit display might have these deliverables:

• Screen mounted safely in the pit.
• Display software running on the device.
• Final team content loaded.
• Startup instructions written.
• Full setup tested before packing.

Each deliverable can then become several Vikunja tasks.

This helps prevent a common project-management mistake: creating a long task list without knowing what the task list is supposed to produce.

Keep the work breakdown useful

A work breakdown is the project's work split into smaller pieces.

Good tasks are still specific and actionable, but a project leader also checks whether the whole task list is balanced.

Look for these problems:

• Tasks that are too large. Build scouting app is too big to assign as one task.
• Tasks that are too small. A board with 80 tiny tasks becomes hard to read.
• Missing review or test work. Building is not the same as proving it works.
• Hidden handoffs. One group may be waiting for another group, but the task list does not show it.
• No clear owner. Important tasks with no assignee usually drift.

A useful project board shows the next layer of work, not every possible detail for the next six months.

Plan around constraints

A constraint is a limit the project has to work within.

Common robotics constraints:

• Time before competition.
• Robot access.
• Parts that are not available yet.
• Mentor availability.
• Field space.
• Battery charge time.
• School events or snow days.
• Rules from the game manual.
• Students being new to a tool or skill.

A strong project leader names constraints early. This helps the team avoid plans that only work in an imaginary perfect week.

Example:

Constraint: We only have the real robot for the last hour of Wednesday meetings because drive practice uses it first. Any task that needs robot testing should be ready before that hour starts.

That one sentence can change how the team schedules work.

Manage scope

Scope means what is included in the project and what is not included.

Scope grows easily on a robotics team. Someone says, "Could we also add..." and suddenly a one-week task becomes a month of work.

New ideas are not bad. Uncontrolled scope is the problem.

When a new idea appears, ask:

1. Does this support the project goal?
2. Is it needed for the definition of done?
3. What existing work would become later if we add this?
4. Is this a new task, a future task, or a separate project?

Use Vikunja to keep scope visible:

• Put required work in the active project.
• Put nice-to-have ideas in a Later or Backlog bucket.
• Label risky or optional tasks clearly.
• Do not let optional work block required work.

A good project leader protects the team from doing the interesting extra thing before finishing the important required thing.

Manage risk before it becomes a blocker

A risk is something that might go wrong later. A blocker is something that is already stopping work.

Project management tries to notice risks early enough to act.

Examples:

Risk	Possible response
We have never used this sensor before.	Create an early test task before the whole design depends on it.
Only one student knows how the scouting form works.	Pair that student with someone else and document the setup.
The part may not arrive before competition.	Create a backup plan task.
The robot is rarely available for testing.	Schedule test windows and prepare code before the robot is free.

Use Vikunja for risks:

• Create a task for investigation work.
• Add a risk or needs mentor label if the project uses one.
• Add due dates to risk-reduction tasks when timing matters.
• Bring the risk to check-in before it blocks the team.

A leader does not need to solve every risk alone. The important skill is making the risk visible early.

Make ownership clear

Every active task should have an owner.

The owner is responsible for the next move. They are not responsible for doing everything alone.

As project leader, watch for these ownership problems:

• Tasks assigned to nobody.
• Tasks assigned to someone who has not been at recent meetings.
• Tasks assigned to too many people, so nobody feels responsible.
• Tasks where the owner is waiting for help but did not say so.
• Tasks where the real owner is different from the Vikunja assignee.

During check-in, ask ownership questions directly:

• Who owns the next step?
• What do you need before you can move this forward?
• Should this task be reassigned?
• Is this still active, or should we move it back to the backlog?

Clear ownership is kind. It prevents quiet confusion.

Use status to show reality

The project board should match the real project.

If a task is blocked, mark it blocked. If a task is done, move it to done. If a task is no longer important, close it or move it out of the active work area.

A board that looks positive but hides problems is not useful. Project management is not about making the board look good. It is about making the truth visible while there is still time to act.

Useful Kanban buckets for a student-led project:

• Backlog — work we may do later.
• Ready — work that is clear enough for someone to start.
• Doing — work currently in progress.
• Blocked — work waiting on help, parts, access, or another task.
• Review/Test — work that is built but not proven yet.
• Done — work that meets its definition of done.

The Review/Test bucket matters. Many robotics tasks are not done when the first version exists. They are done when the team has checked that they work.

Run a useful check-in

A check-in is a short project meeting focused on status, blockers, decisions, and next steps.

A good check-in is not a long story about everything everyone did. It should help the team decide what happens next.

Use this pattern:

1. Open the Vikunja project.
2. Start with the project goal.
3. Review tasks in Blocked.
4. Review tasks in Doing.
5. Review tasks in Review/Test.
6. Check upcoming due dates.
7. Decide what changes before the next check-in.
8. Update Vikunja before leaving the meeting.

For each active task, ask:

• What changed since last time?
• What is the next step?
• Who owns it?
• Is it blocked?
• Does it need a mentor decision?
• Is it still the right priority?

The last step is important. If the conversation happens but Vikunja does not change, the team loses the decision.

Escalate decisions early

To escalate means to bring a question or problem to someone who can help decide it.

Escalating is not failing. It is part of leadership.

Escalate when:

• The team is stuck between two designs.
• A task needs mentor approval.
• The work may affect safety, rules, budget, or schedule.
• Two groups need the same robot time.
• A deadline is at risk.
• A problem keeps returning after several attempts.

A good escalation includes:

1. The decision needed.
2. The options the team considered.
3. The tradeoff.
4. The deadline for the decision.
5. A link to the Vikunja task or project.

Weak escalation:

We need help with vision.

Stronger escalation:

We need to decide whether to keep working on AprilTag alignment this week or switch to driver practice tasks. AprilTag alignment may improve scoring, but it still has camera-lag problems. Driver practice tasks are lower risk and needed before Saturday. We need a decision before the end of today's meeting.

The stronger version gives mentors something to decide.

Communicate tradeoffs

A tradeoff is a choice where each option gives up something.

Project leaders should name tradeoffs clearly. This helps the team avoid arguments where people are actually optimizing for different goals.

Common robotics tradeoffs:

• Fast vs. reliable.
• Simple vs. flexible.
• More features vs. more practice time.
• Student learning vs. competition readiness.
• Fixing the current design vs. rebuilding it.
• Testing one thing deeply vs. testing many things lightly.

When the team disagrees, try writing the tradeoff in a Vikunja comment.

Example:

Tradeoff: Adding automatic alignment could help scoring, but it may take the rest of the week to make reliable. Staying with manual alignment gives drive team more practice time. We need to choose by Wednesday because the robot is packed Friday.

That comment turns a vague disagreement into a decision the team can make.

Keep records without creating paperwork

Professional project management includes records because people forget. On our team, the record should be useful, not heavy.

Good records answer:

• What did we decide?
• Why did we decide it?
• What changed?
• What still needs to happen?
• What should future students know?

Use Vikunja comments for short records:

Decision: We are not adding a second camera before this competition. It adds wiring and code risk, and the current camera is enough for driver alignment. Revisit after the event.

Use attachments when a photo, screenshot, or file explains the situation better than text.

Do not write long reports nobody will read. Write enough that the next student can understand the project without starting over.

Project health checklist

Use this checklist before a Wednesday check-in or before asking a mentor for help.

1. Does the project have a clear goal?
2. Is the definition of done written down?
3. Are active tasks assigned to real owners?
4. Are blocked tasks marked blocked?
5. Are blockers explained in comments?
6. Are risky tasks visible?
7. Are due dates used where timing matters?
8. Is optional work separated from required work?
9. Is there a next step for every active task?
10. Does the board match what is actually happening?

If several answers are "no," the project probably needs organization before it needs more work.

What good leadership looks like in Vikunja

Good project leadership is visible in the board:

• The project goal is clear.
• The active work is not too crowded.
• Tasks have owners.
• Blockers are honest.
• Decisions are written down.
• Review and testing are tracked.
• People can tell what to do next.

You are not trying to make Vikunja perfect. You are using it to help people think together.

A strong student leader keeps the project understandable, even when the robot is not cooperating.