Introduction
About Project Structure
When setting up TaskRay, one of the first decisions that needs to be made is how to approach project structure for a particular business process. This decision correlates with every stage of the project's lifecycle: it impacts how the project is created, how it is managed, visualized, as well as how it is reported on when finished. Throughout this article, we will go over the main ways to structure projects and review various considerations related to each option.
A project’s structure provides the framework within which work will be accomplished. It helps keep things organized and allows team members easily locate assigned work and update the records they need. A well-structured project also makes it easier to maintain and update over time. It's important to agree upon a project structure in a clear and transparent way for all stakeholders to ensure a smooth and successful project delivery.
When deciding on the approach to structure your projects, keep in mind that not every business process is the same. In other words, if your organization utilizes TaskRay for a variety of project types, each one of those project processes could correlate with a unique project structure.
After reading this article, you should have a good understanding of the different project structures available in TaskRay and which one will be the most suitable for your business process. Before diving into the options, it is helpful to understand the basic TaskRay object architecture, which can be found in the TaskRay Structure Basics article.
What are the options?
When deciding on the approach for project structure, it is important to consider various factors. For example, maybe your onboarding team needs distinct phases sectioned into task groups with tasks and specific checklist items. Meanwhile, perhaps your market team just needs tasks that are not grouped within the project, correlating with a flatter structure.
There are two main ways to approach project hierarchy. The first involves one main project consisting of sub phases or task groups. This is a flatter architecture with task groups as the main layer for organizing tasks within a project. The other structure approach involves a parent project with related sub-projects. This is a more complex architecture that incorporates an additional layer for organization (sub-projects). If necessary, each project layer can also utilize task groups to define structure further and keep the tasks organized.
For simplicity, the two types will be referred to as parent project and task group hierarchies throughout this article.
Example of a flatter project structure that only utilizes task groups
In the following screenshot, the sample project is constructed to include task groups that contain tasks. Depending on the business process, the task groups could be used to represent different phases or processes related to a particular initiative within a project.
Example of a more complex project structure that utilizes sub-projects
A parent-to-child hierarchical project structure supports complex project plan requirements. In this configuration, the parent project is the higher-level container that encompasses several related sub-projects, also known as child projects. Here, the parent project acts as a container for the child projects and is responsible for managing and coordinating the overall progress and delivery of the project. Child projects can be smaller, more specific projects that are part of the larger goal. They often have their own specific goals and objectives, but ultimately contribute to the success of the parent project and the larger shared goal.
Considerations
Now that you are thinking about your business process, which structure should you choose? To help you make the decision, let's go over some considerations related to each approach. We will do this by comparing the advantages and considerations of each approach, as well as illustrating through sample use cases.
Task Group Project Structure (Simple)
As a summary, here are the key advantages and considerations related to this approach for structuring projects:
| Advantages | Considerations |
|
|
Advantages
The benefits of the simpler/flatter structure that only uses task groups include simpler automations (such as for project creation), more straightforward reporting, as well as extensive options to roll up values from the task groups to the project.
When it comes to automations, if you are considering automating the process for creating projects in your org and you have requirements to make those projects dynamic based on criteria, the task group architecture might be more suitable. The main reason behind this is that TaskRay offers the project stitching functionality, which allows constructing projects from template "building blocks", which are task groups. Additionally, TaskRay provides an apex action for stitching that can be leveraged in custom Flow automations. For more information on this, see Automatically Stitch Projects Using Flow.
Considerations
One of the key considerations of the task group project structure is the more limited level of Project Hierarchy. With this structure, your organization of work is defined using the following layers: Task Groups, Tasks, and then Checklists.
Sample Use Case
Let’s say you work for a company that sells Software packages that include products and services in a variety of combinations and levels of complexity. You have tier one and tier two packages. Tier one projects are for smaller implementations that have a straightforward workflow that only involve the onboarding team. Additionally, these projects generally have a shorter timeframe, such as several weeks.
The screenshot below illustrates what the structure of such a Tier 1 project could look like. Here, the project is organized into phases using task groups, which contain tasks specific to those phases.
Another example where such an architecture could be useful is if you have a process where the project should be dynamically built from an automation. More specifically, a sample use case here could be a post-sale process where an Opportunity that contains Opportunity Products is marked as Closed Won, which then triggers an automation to create a dynamic project. In this example, the driving factor for how to construct the project could be driven by the Opportunity Products, which correlate with different processes within the post-sale project. When applied to the TaskRay project architecture, each task group could represent the process related to a particular product.
This exact use case and details about the automation are outlined in the following article: Automatically Stitch Projects Using Flow
Parent-Child Project Structure (More Complex)
As a summary, here are the key advantages and considerations related to this approach for structuring projects:
| Advantages | Considerations |
|
|
Advantages
Parent project structure allows you to have multiple levels of Project Hierarchy (up to 4 sub-projects). Within each of these layers, which are represented by sub-projects, it is possible to incorporate Task Groups as a way of organizing tasks within each sub-project. This is a good option for complex projects.
Considerations
Some considerations for this structure are that setting up automation for project (and hierarchy) creation is more custom (but still possible), and it requires additional criteria when running reports. More specifically, visualizing project hierarchies in a report can be challenging due to the object structure. While it is still possible to set up automations that build out the parent-child project structure, such an approach would require additional custom configurations incorporated into the automation. Reach out to TaskRay for further guidance on automaton, if needed!
Sample Use Case
As an example, let's take a look at a more complex onboarding process that is managed in TaskRay. In this case, the onboarding project is planned to take a long time, involve multiple teams, and drive multiple concurrent initiatives that have unique requirements.
In this example, you can have a Parent project that houses the primary onboarding project, which is used to track the overall progress of the onboarding. Beneath that parent project, you can use sub-projects to organize the work according to initiatives. Additionally, the sub-projects can be structured further to organize the tasks by phases or other groupings within each sub-project or initiative. As such, each sub-project operates independently, yet toward the same common goal of the overall onboarding plan.
In this example, Engineering and the Services team need their own separate but related projects to work within. They have different tasks and timelines, but ultimately their work needs to roll up to the parent, onboarding project.
Conclusion
There are benefits and considerations to each type of project structure. Now that you have an understanding of TaskRay project structure, you have the framework to understand how to best construct the work for your use case! Regardless of which option you choose, a well-structured project can help to ensure a smooth and successful project delivery, while reducing the risk of errors, delays, and confusion among stakeholders. And, if you ever need any help, get in touch with TaskRay for guidance!