Hive is a dynamic project management suite that offers customization to meet your organization's specific needs.

Like Lego blocks, Hive lets you build a custom environment to meet your needs. You will pick and choose the pieces that work for your team. As your team works in Hive, each user will have the option to customize their experience, whether that is custom-building their home screen, picking a preferred view in projects, or even determining how they access Hive and the notifications they receive.

It is important to start simple. Your team's first impression of a new tool will be made in a few seconds, and your first goal should be to excite rather than intimidate with features and processes.

Many teams are comfortable with the technical aspects of Hive following our Hive 101 University course, but the complexity comes as you add your own internal processes. Make sure to document your decisions and build out process flows for your team.

If your end goal is reporting, you will want to build standardized and repeatable processes.

Some questions you may be asked right away could include:

The most important part to have in place before beginning is an understanding of your teams and their workflows. Having workflows defined upfront can help you start fresh or best transition from other tools.

If you are transitioning from another tool, remember that Hive is an opportunity for a fresh start. Bringing years-old work into a new platform does not add much benefit, and can lock you into old processes that may not work well. Hive's Best Practice is to leave old work in your old tools and to start as fresh as possible.

Build Hive based on your workflows

Many teams choose to do whiteboarding sessions to define their workflows, while others gather feedback from each of their teams. Complexity, such as labeling systems or required data points, can be added later; however, the initial goal when introducing users to a new platform is to demonstrate how it can help them on a day-to-day basis.

Some questions to define in advance could be:

Hive differs from word processors and Excel files in the fact that it allows you to define and adhere to repeatable processes. Many teams coming into Hive don't struggle with the tool itself but rather with defining a process that has never been defined before.

Can you draw out how your organization or team manages work from start to finish?

At its core, Hive is made up of just two objects: Projects and Actions. Many of the Apps and additional pieces of functionality found in Hive, including reporting, center around these concepts. It is important to understand which of the two objects you are talking about when discussing Hive.

Even if you choose to call them something different internally, remember the formal nomenclature here.

Projects function like folders in the sense that they contain and organize all of your tasks, which are formally known as Action Cards in Hive. Projects are large initiatives or groups of initiatives that can be organized into hierarchies and will contain all the tasks your team needs to do.

These Projects are visible and accessible on your left-side panel under Project Navigator.

Each project has unique permissions, meaning that if a non-Admin user is not added, they do not see it, nor can they access its tasks. As you design your workspace, you will determine what each user can and cannot see. As you add your users, you can even determine whether they have full access rights to create and interact with tasks, or if they can only read them.

Each project also contains an Overview tab where you can define and track:

Projects traditionally fall into two categories for organizations:

Department-level projects are perpetual, meaning they do not have start/end dates, and they constantly ingest work.

Initiative-level projects have set due dates and deadlines. Think of a construction project in this case: all tasks are trending towards an end date, and many may be dependent on each other to begin.

Some examples of these can be seen in the images below. Many teams combine these methods or make their own:

Department Level Hierarchy:

Initiative Level Hierarchy:

Hierarchies, as seen above, help to organize your projects into an easily searchable format. As you build or edit your Project object, changing the Location will determine where the project falls in your hierarchy. Traditionally, Projects are only created under your hierarchy if they contain 15 or more tasks and run for more than 30 days.

Just because a user is added to a top level does not mean they have access to projects below and vice versa. In the example directly above, clicking Financial Systems Implementations will open a project showing all actions in the 9 projects below. Clicking on New Hampshire Healthcare, however, will only show actions from that specific project.

Best practice recommendation is to have no more than 3 layers in your hierarchy.

Many teams in their first year only have 15-30 projects, but hundreds of action cards.

Action Cards, also known as Actions, Cards, or Tasks, are the core element of Hive and the most important object you and your team will be creating. Many long-term teams only have 30 or so projects but thousands of cards.

Action Cards can be as simple or complex as needed. As seen in the example above, I have a relatively in-depth task with multiple assignees and subtasks with subtasks of their own. As a project manager, I add details like labels and dependencies while my employees review and complete their tasks, moving them through various statuses.

An average assignee will most likely only be viewing what they are being asked to do, moving tasks between statuses, and adding comments/attachments. Project Managers will be looking at the projects holistically and managing labels, task assignment, priority, dependencies, and more.

While a project manager may live in Hive, an average employee may only spend 30 minutes a day reviewing their tasks.

As you bring work into Hive, begin by asking yourself:

Hive is customizable, meaning each user can define how they view the tool. If you want to standardize the experience, make sure to document your decisions

Best practice guidance is to standardize your approach without restricting your users, even if multiple departments have different processes. Users respond best to guardrails rather than strict limitations.

Project hierarchy functions as a way to group your projects. A three-layer hierarchy has a grandparent-to-child relation as seen below:

Hive does not contain folders but rather projects inside projects like a nesting doll. Each project is unique in its permissions. Just because a user has access to a Grandparent level does not mean they have access to data in the Parent level and vice versa.

Each of these layers operates as it's own project and contain is own cards. Clicking the Grandparent level, for example, would show you every card in Project A, Project B1, and Project 1C.

However, if you click into Project 1C, you will only see tasks made in that project. Hierarchy helps prevent you from having to make multiple clicks when you just want to see all data in one go. Keep these permissions and views in mind when setting up.

As noted in previous sections, Hive, at its core, is just projects full of tasks. In this section, we will discuss how to best organize and view these tasks.

At this point, you may have created a project or two, which have a few tabs noting the various views (i.e, List, Status, Table, Gantt)

Each person in your organization learns and works differently. Hive accommodates this by letting teams choose from a large number of project views that users can toggle through to find and interact with their work.

Each Project View comes with its own benefits and many teams choose to standardize their views so users can find their way, no matter where they land using templates. The key takeaways and benefits of the views are listed below and will help you determine which to use for your team.

As you build your Hive environment, you will also be building and defining the lifecycle of your work. The visual below shows an example of a team's setup for work management.

They define that work comes in through a form submission into a triage project. The team reviews intake and moves the Action Card to an existing project or creates a new project.

Another team may decide that all work comes in via email and that Project Managers are responsible for inputting it into existing projects.

Once the projects or actions are in place, the team works toward completion while Management builds reports for monitoring progress.

At the end of the day, Hive can be as simple or as complex as you would like. It is important, however, to remember your end users.

End Users are often the ones juggling multiple tasks on top of updating Hive, so the goal should be making Hive as intuitive and simple as possible.

If you choose to implement a labeling system, make sure to define it. The same goes for Statuses, Custom Fields, Priorities, and more.

You may look to save your teams from themselves by restricting the use of the items above. If you have Enterprise Security, consider limiting the creation of Statuses or Labels to Admins under the Enterprise Security settings panel.

Keeping end-user experience in mind will keep your coworkers happy and your environment easy to use.

Looking for more best practice guidance not found here? Reach out to us through the ? icon in Hive or at Help@Hive.com.