GitLab is best known as an all-in-one DevOps platform, but it is also an effective tool for project management. Non-technical teams at GitLab, such as the Marketing team, use the GitLab DevOps platform for project management, and recently the Alliances team learned that DevOps and project management work well for our purposes.
About the IBM partnership
GitLab recently launched a partnership with IBM to help the organization automate their DevOps platform. Since I work on the Alliances team, I needed an efficient, compatible, and high-performance project management application to manage the many moving parts of the GitLab and IBM partnership as well as other projects related to our partnerships.
My very first instinct was to test a few of the project management web applications on the market, but this would involve a tedious process of convincing my colleagues to join me on this journey to explore a sprawling new set of tools. Then I thought why not explore our own Gitlab DevOps platform as a project management tool? The beauty of GitLab is that it is a DevOps platform delivered as a single easy-to-use application.
Some of my early questions were:
- Can the GitLab DevOps platform work as a project management tool for the strategic Alliance team?
- Can GitLab manage and track business activities over a period of time?
- Can team members collaborate and manage various projects using a single application?
In the end, the journey to adopting GitLab as a DevOps platform and project management tool was similar to the journey many of our customers experience. In this blog post, I will dive deeper into how the Alliance team uses GitLab for project management, explain how we used GitLab to onboard a new strategic partner, and launched support of GitLab Ultimate for IBM Cloud Paks. All the pre- and post-onboarding activities in particular required collaboration and contributions from various teams across the organization.
Applying DevOps features to project management
About epics and roadmaps
Why organize work into a hierarchy? I began the strategic partnership effort by organizing the work into multi-level epics. The idea behind epics is to aggregate similar work (or issues) into epics and manage delivery of work. In the example below, you'll see the top-level epic was called "IBM cloud paks" which contained three child epics.
Work is divided into three time-bound levels for the IBM cloud paks project: Pre-launch, 0-90 days, and 90-180 days.
Another way to represent the epics is through a roadmap view. The main advantage of this feature is that it allows the collaborators on epics and issues to monitor project progress using a calendar timeline view.
The same IBM cloud paks project epic is depicted using the Roadmap view, which adopts a timeline view.
How issues are used to capture work
Click into any of the epics to find a set of issues that make up the epic. I use issues as the basic unit of work. Contained within the "IBM cloud paks: Pre-launch" epic are 33 issues.
Inside the "IBM cloud paks: Pre-launch" epic are 33 issues
One thing to note is that an issue can have a single assignee or owner, or it can have multiple assignees.
How to use issue boards
An agile board can help a user visualize work and manage all the open threads in a given epic and/or project. The board can help you move issues efficiently through various phases of work. On the Alliances team, we are always iterating on how to better track the status of issues. [Here is more information about the current status flows for the Alliances team](/handbook/alliances/#status-alliance
