New article
Recently updated
Making the most of Ideagen Boards
Who is this article for?
Project Managers and Project Consultants
Access to the User Acceptance Testing (UAT) or Design Verification Test (DVT) is required.
See Using Ideageb Boards for step-by-step instructions on creating a Board Item, and the Ideagen Boards admin guide for full module details including installing the Boards modules.
This guide is about getting the underlying structure of Ideagen Boards right: how Projects, Board Titles, Items, Requirements, and Status relate to each other, and how to apply that structure at different levels of project complexity. The modules are built to flex across very different project types, which is the whole point, but nothing forces you to use them a particular way, so it's easy to end up with inconsistent setups or data in the wrong place. Treat this guide as guidance, not configuration to copy exactly.
The pieces, and how they relate
Project is the organizing container above everything else. A Project can have Project Phases underneath it (Project > Project Phase), and a Board (all items on the board), or an individual Board Item, can be tied to a Project.
Projects best practice:
Always create at least one Project and assign every board to it from the start. Adding more Projects later is easy; retrofitting one onto Items that never had one is not.
Board Title defines a board: its name, and which optional fields (Priority, Due Date, Category, Level of Effort, Releases, Requirement tracking, and so on) are turned on for Items created on it. Boards are usually created by module, by product, or by purpose, but nothing enforces that pattern. A Board Title can be pinned to a single Project, or left open so users pick the Project on each Item.
Board Item is the atomic unit of work: a bug, a configuration change, a scope change, or a task tied to a requirement. Every Item lives on exactly one Board, and can optionally be associated with a Project, a Category, a Release, and one or more Requirements.
Board Requirement documents a need, independent of any specific task required to deliver it.
A Requirement can be:
- decomposed into a hierarchy, from Business need through Stakeholder need, Solution detail, and Transition need, using Requirement Level and Parent Requirement
- classified by area (Category) and by kind (Requirement Type)
- scored for Priority, Criticality, and Complexity
- tracked through to Verification Status and Sign-off
A Board Item can link to one Primary Requirement and any number of Additional Requirements; a large requirement might take several Items to deliver.
Board Status defines the stages a Board Item moves through from creation to completion. Each status also carries a Responsibility value (Ideagen or Customer), showing who owns the Item while it sits in that stage.
One status can be marked Initial, the default applied to newly created Items, and any number of statuses can be marked Closed, which locks the Item so only admins can modify it further.
Every status change is recorded automatically in the Item's Activity Log.
Board Status best practice:
Statuses are meant to be shared across boards and projects wherever possible. One consistent list keeps reporting, including Responsibility, meaningful across an entire organization, not just one board. A Board Title can restrict which statuses are available, but that's for flexibility in unusual cases, not the normal setup.
Requirements are verified separately. That separation is intentional: an Item can close once its own work is finished, even if its Requirement hasn't completed verification or sign-off yet.
In short: Project answers "what initiative is this part of." Board Title answers "what board does this belong to." Board Item answers "what specific piece of work needs doing." Board Requirement answers "what need are we actually trying to satisfy," independent of how many tasks it takes to get there. Board Status answers "what stage this Item is at right now, and whether it's still open to change."
Four examples, by complexity
These map to a range of project types, from a single contained effort to a multi-project program with formal traceability. Treat the boundaries as fuzzy. Most real projects will sit somewhere between two of these.
Example 1: Simple project
A single, contained effort. Speed and low friction matter more than granular reporting.
| Piece | How it's used |
|---|---|
| Project | One Project, no Phases. Every board and item points to it. |
| Board Title | Several boards, usually split by module or product area (e.g., one board per product module being configured). |
| Board Requirement | Not used. Requirement tracking is disabled in Board Title settings. |
| Board Item | The only object anyone touches day to day. Bugs, configuration changes, and scope changes are all just Items. |
| Category | Optional, light use, mostly for filtering Items by type of work (e.g., Configuration vs Bug). |
| Release | Usually off. If the whole thing ships at once, there's nothing to group into sprints. |
| Board Status | The default status list, used as delivered, with no per-board restrictions. |
What this looks like in practice:
Someone requests a change, it becomes a Board Item directly, someone works it, it closes. There's no separate record of why the change was requested beyond what's in the Item's Details field. That's an acceptable tradeoff at this scale, as long as it's a deliberate choice and not an accident (see the common mistakes section).
Example 2: Mixed-complexity project
Enough scope that a single flat list of tasks stops being enough, but not enough to justify a full requirements hierarchy.
| Piece | How it's used |
|---|---|
| Project | One Project as the parent, with Project Phases underneath (e.g., Discovery, Configuration, UAT, Go-Live) as children. |
| Board Title | Multiple boards, typically split by product area, each tied to the Project (or left open so Items can be assigned to whichever Phase they belong to). |
| Board Requirement | Used, but flat. Requirements are created and linked to Items, but Parent Requirement and Requirement Level are mostly left blank, there's no real decomposition chain. |
| Board Item | Still the primary day-to-day object, but now each one is expected to link back to a Requirement rather than standing alone. |
| Category | Used with real structure on both sides: Item categories reflect the kind of work, Requirement categories reflect product/functional area. |
| Release | Often on, one Release per Phase or per planned release, so Items can be grouped and reported on by delivery wave. |
| Board Status | Same shared status list as every other board, no reason to customize it yet. Closed Status is still limited to admins. |
What this looks like in practice:
A customer need gets written up as a Board Requirement first, with Acceptance Criteria and a Priority, then one or more Board Items get created and linked to it to actually deliver it. Nobody's building a formal Business-to-Solution decomposition tree, but there's now a real distinction between "what was asked for" and "what work it took."
Example 3: Single project, full requirements rigor
A single, focused initiative where the requirements side still needs to be trustworthy, traceability, verification, sign-off, typically because something downstream (a customer contract, an audit, a go-live gate) depends on proof that what was built matches what was asked for. What stays simple is breadth, not depth: still one project, and boards are still organized primarily by product area rather than splintering by function the way they do at full Complex scale.
| Piece | How it's used |
|---|---|
| Project | One Project, with Phases underneath (same shape as the Mixed-complexity example). |
| Board Title | Multiple boards, still primarily split by product area. Maybe one board added specifically for UAT if verification needs its own tracking space, but not the wide function-based split of the Complex example below. |
| Board Requirement | Fully used, same rigor as the Complex example: Requirement Level and Parent Requirement build a real decomposition from Business need down through Solution detail, Requirement Type and Category are kept distinct, Verification Method and Verification Status are tracked to closure, and Sign-off is recorded. |
| Board Item | One of potentially several execution tasks under a given Requirement, same relationship as at full Complex scale. |
| Category | Structured on both Items and Requirements, same as the Mixed-complexity example. |
| Release | One Release per Phase, same as the Mixed-complexity example. |
| Board Status | Same shared status list as every other project. An Item's Closed status reflects that its own work is finished, it doesn't depend on whether the linked Requirement has passed verification, that's tracked separately on the Requirement itself. |
What this looks like in practice:
This is the point where a Requirements Traceability Matrix, a report tying each Requirement to its linked Items, their Status, and the Requirement's own Verification Status, becomes worth building, even though there's only one project. The difference between this and the Complex example below isn't how carefully requirements are tracked, it's whether that's happening once or across several projects at the same time.
Example 4: Complex, multi-project program
Multiple concurrent projects, each with real internal structure, and formal traceability matters, often because sign-off, verification, or audit requirements are in play.
| Piece | How it's used |
|---|---|
| Project | Multiple Projects, each with its own Phases. |
| Board Title | Numerous boards, split inconsistently on purpose, some by module, some by function (e.g., a dedicated UAT board, a dedicated Data Migration board), because a single dimension stops being enough to organize the volume of work. |
| Board Requirement | Fully used, including the hierarchy: Requirement Level and Parent Requirement build a real decomposition from Business need down through Solution detail, Requirement Type and Category are both populated and kept distinct, Verification Method and Verification Status are tracked to closure, and Sign-off is recorded. |
| Board Item | One of potentially several execution tasks under a given Requirement. |
| Category | Fully structured on both Items and Requirements, with a real Classification > Parent > Child hierarchy maintained deliberately, not organically. |
| Release | Used per Phase, often mapped to sprints, so Requirement-to-Release-to-Verification-Status reporting is possible end to end. |
| Board Status | Same shared status list as every other project, kept consistent on purpose so reporting works across all of them. A board can restrict which statuses are available, but that's used sparingly, for a genuinely distinct workflow, not as the default just because a project has grown complex. As always, an Item's Closed status is independent of its Requirement's verification status; the two are tracked separately. |
What this looks like in practice:
This is the setup where a Requirements Traceability Matrix and a Verification dashboard actually pay off at scale, because there's enough structure underneath them for those reports to mean something across multiple projects at once. The dividing line between this and the tier above it is breadth, not depth: this pattern exists because there are several concurrent projects to manage, not because any one of them needs to be tracked more carefully than a single-project effort would.
Where the flexibility causes problems
The examples above are all legitimate. The mistakes below happen when a project ends up somewhere by accident, not by choice.
Requirements get written as Board Items instead of created as a Board Requirement. Either the requirement text gets typed straight into an Item's Details field, or a whole Item gets created to hold it, with no real task attached. Both happen because the Item is already open, and that's faster than creating a separate Requirement record. The cost: no Acceptance Criteria, no Verification Status, no sign-off, and no way to see that several Items trace back to the same need. If a board has Requirement tracking on, a request describing a need belongs in Board Requirement first, with the Item linked to it.
Projects go unused, or get applied inconsistently. Because Project is optional on both Board Title and Board Item, boards often go live without one, especially Simple-style boards where it didn't seem to matter yet. As the project grows, there's no clean way to report on the whole initiative, since half the Items were never tagged. Decide at setup time whether Project is assigned per-board or per-item, and apply it consistently from the start.
Categories are misunderstood or left flat. Item categories and Requirement categories are entirely separate lists (same module, different Type), but people often duplicate structure across them or assume one Type's categories are available to the other. Within a Type, people also skip the Classification > Parent > Child hierarchy and create a flat list of Classifications, which defeats a Board Title's ability to restrict Items to one Classification's options. Decide the Classification structure for each Type before boards go live, rather than letting categories accumulate ad hoc.
Status ends up different from board to board for no real reason. Because a Board Title can restrict which statuses are available, it's tempting to tweak the list per board, dropping one status, adding a custom one. Do that enough and status stops meaning the same thing everywhere, breaking any reporting that spans more than one board. Keep one shared list as the default, and restrict it only when a board's workflow is genuinely different.
Quick reference: where does this go?
| If you have... | It belongs in... |
|---|---|
| A documented need, ask, or mandate | Board Requirement, not an Item's Details field |
| A specific piece of work to do (a bug, config change, task) | Board Item |
| Something reportable across an entire initiative | A Project, assigned consistently |
| A way to classify by product or functional area | Item or Requirement Categories |
| A way to classify what kind of requirement this is | Requirement Type, not Category |
| A way to show where a requirement sits from business need to solution | Requirement Level and Parent Requirement |
| How urgent something is | Priority |
| How bad it is if something fails or is missed | Criticality |
| How hard something will be to build | Complexity (Requirement) or Level of Effort (Item) |
| A way to group items into a sprint or delivery wave | Release |
| Proof a requirement was tested and approved | Verification Method, Verification Status, Sign-off By/Date |
| What stage an item is at, and a way to lock it once done | Board Item status, using a Closed status |
| Who owns an item at a given stage, Ideagen or the customer | Board Item status's Responsibility value |
| A finished task whose requirement is still being verified | Still fine to close, Item Status and Requirement Verification are tracked separately |
Picking a starting point
As a rough guide, not a rule:
- One team, one delivery date, no need to trace decisions later: start with the Simple pattern, and add more only once it's obviously necessary.
- Multiple phases or a known requirements list up front: start with the Mixed-complexity pattern.
- One project, but real traceability matters (a contract, an audit, a go-live gate): use the Example 3 pattern instead of jumping straight to a multi-project setup you don't need yet.
- Several concurrent projects needing sign-off, audit, or formal verification: start with the Complex pattern from day one. Retrofitting a requirements hierarchy onto hundreds of already-flat requirements is far more work than building it in from the start.