An overcomplicated project management workflow usually needs fewer decisions, not a new tool. Simplify it by defining one intake path, a small number of visible states, one accountable owner per work item, and explicit limits on started work. Remove fields and automations only after exporting the current system and testing a small pilot.
Diagnose the workflow before changing it
Choose a recent project and follow three real work items from request to completion. Record every place each item was copied, every status it entered, every required field, every notification, and every handoff. Mark which steps changed a decision and which merely duplicated information. Ask users where they look for the current answer and where work most often waits.
Do not begin with a feature comparison. The same application can be simple or tangled depending on how the team uses it. The first target is a shared definition of what counts as a work item, when it starts, when it finishes, and which states it moves through. The current Kanban Guide describes those elements as part of a Definition of Workflow and treats items between started and finished as work in progress.
Choose one system of record
Decide where the authoritative work item lives. Email, chat, forms, and documents may still create requests or hold supporting material, but they should point to the same item instead of becoming parallel task lists. Set one intake route for routine work and one documented exception path for urgent work.
Match the tool to the scale of coordination. Microsoft's comparison says To Do is oriented toward individual tasks and shared lists, while Planner is aimed at team work with visual plans, buckets, assignments, and dates. That does not mean every team needs Planner or every person needs To Do. It means the coordination model should fit the work rather than forcing a personal list to behave like a portfolio system.
Reduce states and fields
Start with a narrow state model such as Requested, Ready, In Progress, Blocked, Review, and Done. Each state needs an entry rule, an exit rule, and an owner. If two states have the same rule or no one can explain the difference, merge them in the pilot. Keep only fields that drive routing, priority, reporting, compliance, or a real decision. Hide or archive the rest before deleting anything.
Use templates sparingly. A template should reduce missing information, not create empty sections that users mechanically skip. Replace multiple priority labels with a small policy: what can interrupt current work, who can make that decision, and what happens to the displaced item.
Limit started work
Count items that are started but not finished and set a trial limit by team or workflow stage. The Kanban Guide requires an explicit definition of how work in progress is controlled. A limit is not a performance quota. It is a signal to finish, unblock, or renegotiate before starting more.
Review blocked items every day. Give each blocked item a reason, an owner for the next action, and a review date. If the team repeatedly exceeds the limit, examine demand, capacity, and policies rather than adding another status to hide the queue.
Remove automation in a safe order
Export the projects, tasks, comments, attachments, users, roles, and automation settings. Then classify automations as required, useful, noisy, or unknown. Disable one low-risk automation in a sandbox or pilot project and observe a full work cycle. Check whether any permissions, reminders, integrations, billing rules, or compliance records depended on it.
Keep automation that enforces a necessary handoff or prevents a known error. Remove notifications that nobody acts on, duplicate synchronization, and rules whose owner is unknown. Document the remaining rules in plain language so a new team member can predict what will happen.
Pilot and measure the simpler path
Run the reduced workflow with one team or project for two to four weeks. Track throughput, work-item age, cycle time, number of blocked items, reopened work, and manual corrections. The Kanban Guide identifies work item age, cycle time, throughput, and work in progress as core flow measurements. Pair those measures with short user interviews because a faster board that loses critical context is not an improvement.
At the end, compare the pilot with the baseline. Keep the change only if work is easier to find, ownership is clearer, delays are visible, and the export or rollback path still works. Train the rest of the team with examples, not a catalog of features.
Maintain the small system
Assign an owner for the workflow itself. Each month, review unused fields, stale statuses, broken automations, access, integrations, and aging work. Each quarter, test an export and restore or import sample data. Require a named problem and a success measure before adding a new field, state, integration, or tool.
The simplified workflow should make the next decision obvious: what is ready, who owns it, what is currently in progress, why something is blocked, and what finished means. Everything else has to earn its place.
Sources
- The Kanban Guide, May 2025 — Kanban Guides, May 1, 2025
- To Do vs. Planner — Microsoft Support