The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Traditional project management is a set of tools and techniques which help organizations plan, manage, and deliver unique outcomes. Projects are typically one-off efforts, constrained by time and resources, where teams collaborate to invent and create new business capabilities.
The discipline of product management has emerged as a new paradigm in enterprise IT organizations, which blends the practices of ‘project management’ and ‘service management’ or ‘operations’. Effectively product management is focused on optimizing the customer and business value of a specific product or service. Product management combines the three concepts of product creation, product operation/improvement, and product shutdown under one umbrella.
GitLab ‘Project Management’ must adequately support the needs of both Traditional Project Management and the emerging demands of “Product Management” which continues to ascend in many organizations.
|Project Management||Product Management|
|Fixed time frame||Unspecified end|
|Deliver on time/on budget||Optimize for business Value|
|Budget constraints||Budget constraints|
|Resource constraints||Resource constraints|
Project management in GitLab allows teams to plan, manage, and track work, usually software development work, to create potentially complex applications and services.
In particular, the primary object leveraged is the issue, which is the single source of truth for a given feature or any change in general, where team members collaborate on ideas and make decisions to move the process forward for that change. Attributes such as labels, milestones, assignees, and weights (story points) provide flexible ways for teams to do the otherwise difficult task of managing a large number of issues.
Boards are a powerful way to do that management as well, and it is its own product category. Agile portfolio management focuses on planning at a higher level work abstraction, and at longer time scales, and is also its own product category.
The future of project management is helping teams create and maintain long-lasting products that serve their customers. Traditional project management is very much focused on simply managing a project. A project is loosely defined as a set of requirements. And the purpose of project management here is to help teams ensure that the project is completed on time and on budget, based on the original agreed upon plan. (This concept will still be relevant for contracting scenarios. But GitLab is not focused on that use case.) The thinking used to be (and currently still is in many organizations), is that shipping product and features means completing a series of projects. This is an older mindset and GitLab is not focused on this way of helping teams, because we simply believe that there is a better way.
The project mindset suffers from being inward-focused, and puts too much emphasis on making sure plans are adhered to, for the sake of strategic planning and stability within an organization. The future that GitLab is participating in, and inventing, is product management. It is a focus on the customer and the business value delivered to them. It is outward-focused. If the process is focused on customers, then optimizations will be biased toward that instead. It gives room for Agile principles to breathe since the focus is not on strict constraints and change management. Nonetheless, we will still address the use cases of regulation, security, and compliance as needed in different industries. These will result in features that are targeted to meet those demands to mitigate business risk. But they will not be used to manage project management risk, which is the previous model. In summary, the project-to-product transition will allow customer needs and business concerns to pull feature development. GitLab is focused on inventing this future.
Naming-wise, we don't anticipate that the project management terminology to change because it is entrenched in the industry. This means we will have to continue educating our customers, and the industry at large and be intentional in explaining that GitLab project management is actually focused on developing products, and not on managing projects.
Custom fields and custom workflows are a powerful notion to allow teams to support their very unique specific workflows, especially in large enterprises. Our first minimum viable change to address this need was scoped labels; and we will continue on iterating on this concept to work towards a more native solution.
As well, a more powerful way to do backlog refinement and prioritization in general is also coming. This is somewhat possible right with issue boards, but we want to enable teams to manage even more issues' priorities altogether, even more easily. See Manual ordering of issue lists for backlog refinement prioritization.
Along with improved refinement capabilities, we are also focusing on providing more insight into a team's velocity..
The top competitor is Atlassian's Jira. It is by far the dominant and entrenched issue tracking system in the industry, and similar to GitLab, has expanded its offerings over the years. Interestingly to address Jira, we are not only offering competitive features, but also integration with Jira itself into GitLab merge requests, as a way to help customers to eventually make the transition to Jira, for example using an export/import migration strategy. See CSV import.
In recent years, there has been many smaller player to enter the project management space, to focus on more niche areas and solve more specific use cases. There are many. Some notable ones are Trello, Asana, Notion, Monday, and even Basecamp.
Analysts in software project management, and in particular enterprise software management, are going beyond basic project management, as it applies to the software world. It is not sufficient to address this singular space and goal anymore. Analysts are looking at the bigger picture of DevOps, Agile transformation, and delivering business value to customers. In many ways, project management has become a subset of the greater goals of shipping value to customers as fast as possible, being able to get feedback as quickly as possible. So the relevant analyst domains are really enterprise agile planning and value stream management, which are two additional categories:
More and more customers are asking for manual prioritization beyond priority labels. That's what Manual ordering of issue lists for backlog refinement prioritization addresses. Additionally, folks need a way to do their own custom workflows with boards. That's what Group board with custom workflow accomplishes.
Users in general have been asking for custom fields for a long time, and expect a mature project management tool to have such capability. That's what scoped labels.
Currently, Issue or MR description templates are scoped on a project level basis, but there is also a desire to have them on a group level so they can be shared across projects.
Teams are struggling with a way to manage priorities manually in GitLab. we have issue boards, but they are not sufficient. We need a way to manage a larger number of issues' priorities all at once, and that's what Manual ordering of issue lists for backlog refinement prioritization accomplishes.
Viewing a changelog of an Issue's description has been a long requested feature. We're addressing this in 12.3.
Other notable items:
Unifying multiple projects under a standardized workflow is incredibly important for efficient agile planning at scale. Managed workflows, adding better native support for widely adopted agile methodologies, exposing data to help teams make better planning decisions, and improving the exstensibility of GitLab via custom fields are top of mind. Underpinning this vision is the need to improve the ability to collaborate in a more real time and reactive manner within GitLab itself.