In my last demo of Planbox, I found myself spending more time than usual describing why we introduced two-level projects. So in this post, I’ll describe and show how you can leverage that in your organization.

The top level is called an initiative. It is akin to a product or service: it associates a team of individuals to one or many projects. At the second level are projects which contain to-do items (and items contain tasks). Let me refer to this picture pulled from the Features page.

It is a Gantt-chart-like depiction of how we setup the Planbox initiative to manage Planbox itself. Notice we have three projects; a first for development of the web application, a second for marketing and commerce, and a third for the regular run of business.

Why do we manage non-development activities in Planbox? Simply because management and marketing also have items which affect development of Planbox. So tracking items for everyone in the same tool allows us to plan a common iteration. It also allows us not to forget anything and it maintains open communication between departments.

The Power of Filtering

On the Plan page is where two-level projects come in handy. You can quickly filter to-do items to see one or multiple projects. For example:

Permissions

There are things which need to stay private. In Planbox, you can only see items for initiatives and projects you are involved in. For example, only allowed Planbox managers can see items in the Run of Business project. So I can manage employee confidential items directly in Planbox by putting those items in the Run of Business project, and be assured they remain unseen by employees.

Permissions are easy to setup in Planbox. Go to the Manage page, open your initiative and then the project. You simply include a person in your project to grant him/her access to those items. Remove a person from your project and he/she will no longer see those items.

Administrator

Of course, only administrators have the ability to add or remove projects and people. We provide administrator privileges at the initiative-level. And you can have many administrators on a same initiative. An administrator is able to create, modify and delete projects. An administrator can also add/remove people from projects. And administrators can see all items in all projects in the initiative, regardless of whether they are on a project or not.

Initiative or Project?

Now that these concepts are clear, how to decide whether to create two distinct initiatives, or two projects inside an initiative? Try to answer these questions:

Will there be overlap between team members? Do the two need to keep separate identities?

If the two involve different teams, create distinct initiatives. If the two involve the same teams, create one initiative with two projects. What overrides it all is if the two need to keep distinct identities (i.e. two clients in a consulting firm). In that case, create distinct initiatives.

For example, in Bolidea (Planbox’s incubator) each incubating company has its own initiative. Here’s a look at some of those I can see on my Manage page. Notice I even created myself a personal initiative. No one but me can see that one.

It would be the same for a larger company with distinct products; one initiative per product. A consulting firm could create one initiative per client. That allows you to personalize it by attaching the client’s logo. You can then grant the client access to see how his project is evolving. He would only see that one initiative.

And if you’re not sure because some resources will be shared, be assured that Planbox was built to support that.

So as you can see, Planbox provides all the means for an organization to manage their activities in one tool. So go ahead and give agility to your entire organization.