Projects are common in any type of business. However, it’s important to recognize actual projects compared to other types of work you are managing. The easiest way to tell? Projects have a start and end date and contain a set of interrelated tasks.
That also means that a project will eventually be complete. Even if it goes past the due date or fails completely, it still has to finish.
Project - Planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.
http://www.businessdictionary.com/definition/project.html
Projects can be used for internal initiatives, such as rolling out a new software service, launching a new marketing initiative, or planning the next company holiday party. Projects can also be applied to external entities, such as clients, vendors, or strategic partners.
As we’ve already mentioned, in Rindle, a project equals a board. The main difference between a project and any other board is that it has a start and end date. A project can be a workflow in itself where tasks move step by step to completion, or it can be structured by phases or categories in which tasks don’t move. How you approach your project will depend on your preferences and needs.
The two types of project structures
- Workflow-based projects
- List-based projects
Workflow-based projects
When we say “workflow-based” projects, we are talking about projects that contain a sequential, state machine workflow, or a rules-driven workflow. The majority of the time, a workflow-based project will contain a state machine workflow (see chapter 1).
We can use Rindle’s Baseline Workflow as an example:
Here at Rindle, we heavily promote workflow-based projects for a couple of reasons:
- They offer a more visual understanding of the project, which leads to quicker comprehension.
- Tasks are always moving, so the team is more engaged with the work.
Since workflow-based projects typically move horizontally (left-to-right or right-to-left) between steps in a process, they immediately become more visual and paint a virtual picture of a project’s status. For example, you can quickly see which tasks haven’t been started yet; which are in progress; which, if any, are blocked with issues that need to be resolved; and how many have been completed.
This isn’t as easy to understand in a more list, or vertically, driven project. Think about an Excel sheet containing 50 lines of tasks. It takes your brain a lot longer to process 50 lines of text because it has to process each line, over and over again.
In fact, the human brain processes images 60,000 times faster than text, and 90 percent of information transmitted to the brain is visual. Since we are visual by nature, we can use this skill to enhance data processing and organizational effectiveness in projects by leveraging workflow-based projects.
In addition to the visual benefits, a workflow-driven project also has the advantage of tasks that are always moving. This means that the team is interacting with the tasks, and the project as a whole, at a much higher frequency.
List-Based Projects
When we say “list-based” projects, we are talking about projects that contain task lists typically representing phases or stages within a project. In this format, tasks do not move from step to step or list to list. They stay permanently in the task list throughout the project’s life cycle.
Here’s an example:
List-based projects are great for waterfall projects where each phase of a project has to be completed before the next phase begins. In the above example, the initiation phase will have to be complete before moving on to the planning phase, and so on.
Though the phased or waterfall approach to a project may be the best option for your project, organizing them in vertical lists does have its downsides: it won’t provide a virtual picture of your project. It also means that tasks don’t move, resulting in less engagement from your team. It can also prevent you from seeing where tasks are getting stuck, or where issues are commonly arising.
An alternative is to run your phased project as a workflow-based project. You can easily do this by using tags to identify which phase each task is in instead of lists, giving you the best of both worlds.
You can still run your project in phases but through a workflow that provides a better picture of your project and drives more engagement for the team. You can even use filters in Rindle to only show one phase on the board at a time.
The Rule of 10
When thinking about projects, a common question is:
“Should I have one board for all projects, or should each project be its own board?”
I answer that question with a question of my own:
“How many tasks do you have per project?”
If your projects typically have more than 10 tasks, then each project should have its own board. If they consistently have fewer than 10 tasks, you should use tasks with subtasks to manage many projects on a single board.
Earlier in the chapter you learned that a project is something that has a start and end date and will theoretically be completed. So based on those characteristics, a task that has a start and end date with five subtasks can also be a project. Since that’s true, a board can contain many tasks that are essentially projects.
For example, if we have five projects with five subtasks each, a single board named “Projects” would look like this:
This provides the flexibility to have many mini-projects running through one board instead of creating a bunch of separate boards with very few tasks on them.
If you have projects that are clearly larger than 10 tasks, each project should have it’s own board. For example, if the “Discussions Feature Release” task included more than 10 tasks, we could break it out into its own board like this:
Tip: Unless you already identified it as a project, treat everything as a task until it grows too big and naturally becomes a project.