How to set up a project workflow from scratch (6 steps)
You have a new project. You need somewhere to track the work. You open your project management tool and stare at a blank screen. What statuses should you create? How many columns? Should you add custom fields? Do you need a timeline?
Most teams spend more time debating their setup than actually using it. This guide walks you through a simple workflow setup, step by step, so you can get organized in an afternoon instead of a week.
What is a project management workflow?
A project management workflow is the sequence of stages that a piece of work moves through from creation to completion. It includes statuses (columns on a board), structured data per task (like priority or effort) and views to visualize progress. A good workflow reflects how your team actually works, not how a template says you should work.
TL;DR: Don't overthink your project setup. List your delivery stages, turn them into custom statuses, create a board, add custom fields for the data you actually need, layer in a timeline when dates matter and clone the project for next time. Six steps, one afternoon.
Why do teams get stuck setting up a project workflow from scratch?
Because they try to design a perfect system before they've done any work. They research frameworks, compare tools and debate naming conventions for statuses nobody has used yet.
This is analysis paralysis. The cure is simple: start with what you know and adjust as you go. Your first workflow won't be your last. The point is to get a working setup that's good enough to start, then refine it based on real experience.
The agile principle of "maximizing the amount of work not done" applies to your setup process too. Don't build workflow infrastructure for problems you don't have yet.
Step 1: List your delivery stages
Before you touch any tool, grab a notepad. Write down what happens between "new work arrives" and "work is done" for this specific project.
Think about handoff points. Where does work wait for someone or something? Each waiting point is a potential status.
For example, a web redesign project might look like this:
- New work comes in (backlog)
- Designer picks it up (in design)
- Design gets reviewed (design review)
- Developer builds it (in development)
- Code gets reviewed (code review)
- QA tests it (in QA)
- It ships (done)
That's seven stages. Each one represents a real moment where work changes hands or waits for action. You're not inventing process here. You're writing down what already happens.
Keep it between five and eight stages. Fewer than five and you'll have vague buckets that don't tell you anything. More than ten and the board becomes clutter. If you can't explain what a status means in one sentence, it's either too vague or unnecessary.
Step 2: How do you turn delivery stages into custom statuses?
Open your project settings and create a status for each stage you listed. These become your board columns.
In Eigenfocus, statuses are per-project. You don't need an admin to set them up. You don't need to configure a global workflow that forces every project into the same pipeline. Each project gets its own set of statuses that match its own process.
For the web redesign example above, your statuses would be: Backlog, In Design, Design Review, In Development, Code Review, In QA, Done.
The key insight from the custom statuses guide applies here: think about statuses as handoff points, not activity labels. "In Progress" is an activity label. "In Code Review" is a handoff point. The second one tells your team what needs to happen next.
Step 3: Create a board view with your statuses as columns
Once your statuses are set, create a board view. Your statuses become columns automatically. Cards move left to right as work progresses through each stage.
This is your daily execution view. During standups, everyone can see what's in each column without explaining it verbally. The board does the communication work.
If your team includes a designer and two developers, you'll immediately see patterns. Design Review has three cards piling up? The developer assigned to reviews needs to catch up. Code Review is empty but In QA has five items? QA might be the bottleneck.
A board is enough to get started. Don't add more views yet. Use the board for a week, pay attention to what information you wish you had, then move on to the next steps.
Step 4: What structured data should you track per task?
After a few days of using your board, you'll notice you keep asking the same questions about your cards. "How important is this?" "How big is this task?" "Who requested it?" Those recurring questions are your custom fields.
Custom fields add structured data to every task in your project. Unlike descriptions or comments, fields are consistent across all tasks and visible on cards.
Here are practical starting points:
- Priority (single select: High, Medium, Low). Helps you decide what to work on next when multiple cards sit in the same status.
- Effort (single select: S, M, L, XL). Relative sizing avoids the false precision of hour estimates. It helps you spot when too many large tasks are in flight at once.
- Feature area (single select: Navigation, Dashboard, Checkout, etc.). Groups related work so you can see how much effort is going into each part of the product.
- Requested by (text field). Tracks who asked for the work. Useful for external projects where you need to report back to stakeholders.
Don't add fields you won't look at. Every field should help you make a decision or answer a question you regularly have. You can always add more later.
You can configure which fields appear on board cards for each view. Show priority on the daily board view, hide it on the QA-focused view where it's less relevant.
See all features to explore custom fields, statuses, views and more.
Step 5: When should you add a timeline view?
When your project has dates that matter. If you're working toward a launch, a client deadline or a release schedule, a timeline view helps you see how work fits into the calendar.
The board tells you what stage each piece of work is in. The timeline tells you when it's supposed to happen. These are two views of the same data. Move a card's dates on the timeline and its status stays the same on the board.
For the web redesign project, your timeline might show:
- Information architecture: Mar 3 - Mar 14
- Wireframes: Mar 10 - Mar 21 (overlapping with IA intentionally, because the wireframe designer can start on sections where IA is complete)
- Visual design: Mar 17 - Apr 4
- Frontend development: Mar 31 - Apr 25
- QA and launch prep: Apr 21 - May 2
Overlapping dates are normal. Work doesn't happen in neat sequential blocks. The timeline makes these overlaps visible so you can plan around them instead of discovering conflicts at the last minute.
Don't add a timeline on day one unless you already have firm dates. Start with the board. Add the timeline when scheduling becomes a real concern.
Step 6: How do you set up a project workflow from scratch for repeating projects?
Clone it. Once your workflow is dialed in, use project cloning to duplicate the entire setup, including statuses, custom fields and views, into a new project.
This is where your initial setup pays off. You spent an afternoon getting the web redesign project right. The next redesign project starts with that same structure. No rebuilding, no remembering what fields you used last time.
Project cloning in Eigenfocus copies the project structure, not the tasks. You get a clean slate with the right columns, fields and views already configured. Think of it as a template you create by doing, not by pre-planning.
If you run similar projects often, this is the biggest time saver. Get one project right, then reuse that structure. Read more in the project cloning guide.
Worked example: setting up a web redesign project from scratch
Let's walk through the full setup for a web redesign project with a four-person team: one designer, two developers and one QA engineer.
Statuses:
| Backlog | In Design | Design Review | In Development | Code Review | In QA | Done |
|---|
Custom fields:
| Field | Type | Options |
|---|---|---|
| Priority | Single select | High, Medium, Low |
| Effort | Single select | S, M, L, XL |
| Page section | Single select | Header, Homepage, Product page, Checkout, Footer |
| Requested by | Text | (free input) |
Board view: Default view grouped by status. Priority badges visible on each card. This is the daily standup view.
Timeline view: Created after the kickoff meeting when the team agrees on phase dates. Deliverables placed across calendar weeks. Used for weekly planning and client updates.
Total setup time: About 30 minutes. The team spends the rest of the afternoon adding tasks to the backlog instead of debating workflow theory.
After the project wraps, the team clones it for the next web project. They adjust a few statuses (maybe removing "Design Review" because the next project is developer-led) and add one new custom field. Five minutes and they're ready to go.
Common mistakes when setting up a workflow
A few patterns to watch for:
- Starting with too many statuses. You can always add more. You rarely need to remove them because nobody wants to be the person who deletes a column.
- Adding custom fields you never check. If a field doesn't influence a decision, it's just data entry. Remove it.
- Copying someone else's workflow. Blog posts (including this one) give you starting points. But your workflow should match your team's actual process, not someone else's ideal process.
- Waiting for the perfect setup. The best time to start is now. Adjust next week.
Frequently asked questions
How long does it take to set up a project workflow from scratch?
About 30 minutes if you follow the steps above. The biggest time cost is listing your delivery stages, which is thinking work rather than tool configuration. The tool setup, creating statuses, adding fields and configuring views, takes less time than most people expect.
Can I change my workflow after I start using it?
Yes. Statuses, custom fields and views can all be modified at any time. Add a new status when you discover a handoff point you missed. Remove a custom field that nobody fills in. Your workflow should evolve with your project, not stay frozen from day one.
Do I need a timeline view for every project?
No. Timelines are useful when you have deadlines, phase dependencies or need to communicate schedules to stakeholders. For internal projects without hard dates, a board view might be all you need. Add the timeline when scheduling questions start coming up.
Should all projects in my organization use the same workflow?
Not usually. Different projects have different processes. A software project has code review and QA stages that a marketing campaign doesn't need. Per-project statuses let each workflow reflect its own reality. Use project cloning to share structure between similar projects.
What's the difference between statuses and custom fields?
Statuses tell you where work is in your process, like "In Development" or "In Review." Custom fields tell you what the work is or how to prioritize it, like effort size or priority level. Statuses are your workflow stages. Custom fields are the metadata that helps you make decisions within those stages.
Start building your workflow
Pick a project. List the stages. Set up the board. You can have a working workflow in 30 minutes.
Explore how teams use Eigenfocus for software development or as a project management tool. For a dev-focused variant of this setup, see the anti-Jira dev project setup.