How do Project Management tools work?
This is part 2 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 1 about the exact process of building your Products and their building blocks here.
If you’ve already set up your Product Stack’s Project Management structure, feel free to skip to the next part where I discuss how to structure your Product Stack’s Project Management and its Issue types.
I’ve not gone into the depth of selecting a Project Management tool since there are mostly 2 competitors that dominate this space and are able to fulfill most of the needs of users. For an in-depth comparison between these tools, please check out this link by Zapier.
Please note that I’ve taken the structure of Jira as an example. However, most Project Management tools provide their users with this granular ability to track their issues and the corresponding stages of those issues. I’d also recommend using Jira for its price and customizability and the level of granular control it can give to multiple types of users.
Before going into the best practices for structuring your Project Management of your entire Product stack, let’s first understand how Project Management tools are structured -
Plan
A plan is a representation or a collection of multiple Projects that gives its users the ability to track timelines, map dependencies between multiple deliverable streams, and plan the entire work stream of your organization.
A Plan can be used at an aggregate level to give a two-dimensional plot of all your work against time and further gives the ability to dynamically keep adding and removing work. It also gives you the capability of planning assignments and arriving at realistic timelines on the basis of how many personnel types are present against the required ones.
In the diagram example above, a central roadmap has been plotted by collecting together ‘Initiatives’ as discussed in the last part with their expected timelines.
Project
A Project is a collection of related work that can be used to group similar work together for planning, estimation, implementation, and deployment.
A Project should be used for aggregating streams of work that concern the same Product or the same user type, and for collating data related to all projects together.
Individually, a Project can also be plotted in the two-dimensional space against time that can be used to plan, estimate, implement, and deploy individual work streams pertaining to a single Product or user type.
From the above discussion, we can conclude the following Project Types that you should have in your Project Management toolkit -
Initiative Project
An Initiative Project type is a Project that’s created with the intent of mapping Initiatives that stand for a collection of Products. For Example — The Operations Team in an organization may have a Field Operations App as well as an Audit App for which the Initiatives should be grouped into Operations Project Board.
You should create one Project Board each for how your organization is structured. This should be either according to Business Units such as ‘Ride Sharing’, ‘Food Delivery’, etc., or by Functions such as ‘Demand’, ‘Supply’, ‘Operations’, etc.
Product Project
A Product Project type is a Project that’s created with the intent of mapping all Issue Types that you can have while building a Product that pertains to one Product.
You should create one Project Board for each Product or Product Type that your organization has. For Example — EasyRide would have a Product Project Board each for ‘EasyRide D2C App’, ‘EasyRide Agent App’, ‘EasyRide Admin Dashboard’, ‘EasyRide Partner App’, etc.
Collector Project
A Collector Project type is a Project that’s created with the intent of collating data from multiple projects so that all of the issues mapped in different projects can be displayed together under one board. This helps in creating boards that represent the issues ‘In Progress’ in the current sprint or your Kanban board.
You should create one Collector Project for your organization to visualize your sprints or visualize your entire Kanban process.
Board
A Board is a presentation in the two-dimensional space of actual work streams that individual personnel in your team work upon to complete a deliverable.
By default, each Project that you create comes associated with. a board by default. However, you can create multiple boards per project.
I’d recommend creating two boards per project that exist for a Product as follows -
- One Project Board for tracking the timeline and deliverables related to the development effort of the Product
- One Project Board for tracking the timeline and deliverables related to the design effort of the Product
Collectively, referring to these two boards mentioned above, any Product Owner/Product Manager responsible for this collection of work streams would be able to track and monitor progress.
A Board exists inside a Project and a Project combined with a Board can give the representation of all issues along with the time. In the diagram above, we can see that the unique combination of the Project and its Board gives us all the tasks that are currently ‘In Progress’ or ‘Completed’.
Requirement
A Requirement is the smallest functional unit of Project Management which is the actual work item assigned to personnel on your team for meeting their deliverables.
A requirement is described in terms of how an objective for a user would be achieved
A usual Product has the following types of requirements that need to be fulfilled for its end-to-end completion, delivery, and deployment -
Design
The effort that’s needed to create the user flow on the product, the user interactions, and the look and feel.
Copy Writing
Each Product may need information as well as static information such as labels to be displayed to the user usually provided by your copywriter.
Development
The actual front-end/client-side or back-end/server-side engineering implementation of your designs, and copy-writing. This may also include any third-party integration required for some of your user’s flows along with some business logic that needs to be applied to the data processed by your users.
Usability Testing
Usability Testing is done when your Product and Design teams may not be sure of which specific version of the design to select and may go to the field with your target customer segment to test which ones are preferred.
User Research
User Research is conducted when organizations have specific objectives like the launch of a new business unit, the launch of a new product, or for understanding the unfulfilled needs of existing customers.
Summary
Summarizing this section with the basic building blocks of a Project Management tool as ‘Plan’, ‘Project’, ‘Board’, and ‘Requirement’.
A ‘Plan’ is just a placeholder representation of bigger hierarchy issue types against a timeline of their delivery with estimates and other information.
A ‘Plan’ collates data from multiple ‘Projects’ which have three types of ‘Projects’ contributing their data. You should have a ‘Project’ for each Product as well as for each ‘Business Function’ or ‘Business Unit’ depending on how your organization is structured.
Each Project should have two ‘Boards’ which would display the development and design requirements corresponding to a Product. Only ‘Product’ Project types have two representation boards. Neither ‘Initiative’ nor ‘Collector’ project types need to have two ‘Boards’.
Each Requirement can be of different types and depending upon the type, it features on either of the boards mentioned above.
In the next section, we’ll learn about structuring your Project Management according to your Product Stack and Issue Types.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
