How one IT director got away from Word for incident management

About a year ago, clinical data company Cognivia needed an incident-management upgrade from their current system: A giant Word doc.

Cognivia has since gotten less Word-y, not from buying a new product, but by using a feature in a software-development tool already in the org. The economical decision had its growing pains, but demonstrates a common IT challenge for small, growing organizations: a need to expand capabilities while making the most of in-house resources.

“Sometimes we already have the system that we need available without knowing it,” Guillaume Bernard, IT and software engineering director at Cognivia, told us.

What’s up, .doc? Cognivia’s technologies identify variability within clinical trial data by predicting patient behavior and treatment response—essentially estimating the placebo effect, according to Bernard.

For Cognivia, a company of under 50 employees, an incident could mean a failure of a hard drive containing clinical data, system downtime, or a software bug in the firm’s new platform.

In the past, when an incident occurred:

• The quality assurance director assigned an incident number in Excel.
• The number would be placed into a templated Word doc for incident description.
• A developer or engineer determined root causes, impacts, and resolution tasks.
• Responders tracked updates and signed the doc after resolution.

“It was more and more difficult to use that to be reactive,” Bernard said.

Getting out of the Office. Many incident-management vendors support the challenge of reporting and resolving issues, tracking progress along the way.

Bernard and his team turned to a tool that company developers were already using: GitLab. Known mainly as a software development and collaboration tool, GitLab also has built-in capabilities for code-issue tracking, and more broadly speaking, incident-management capabilities.

With GitLab, Bernard now has a “living document” with pre-set fields to classify incidents with criticality, root-cause analysis, assignees, and deadlines.

Consolidata. For many companies, the IT toolbox is overflowing. A study from CrowdStrike, released in early 2024, found 90% of respondents use three or more technologies “to detect and prioritize application vulnerabilities and threats.”

The move from Office to GitLab doesn’t surprise David DeSanto, chief product officer at GitLab, as you might expect. “Tool consolidation starts to drive better efficiencies within the organization that you would have not gotten had you been using a brittle tool chain all stitched together with digital duct tape,” he told us.

Merge request. GitLab may be a good choice as an interim next step, according to Forrester principal analyst Julie Mohr, but cultural challenges may occur when incidents are placed in a developer tool. The IT team and software team, Mohr told us, often “speak a different language” that comes from “fundamentally different frameworks and different operating models and different performance models,” which complicates a choice to merge incident management and code.

“There have to be really good justifications for why you’re doing it and how it will fit in with the rest of what you should be tracking and managing from an IT perspective,” she said.

Mohr recommends companies review the full enterprise incident-management product space, including low-end options, for important capabilities like categorization, escalation, and timers for tracking service-level agreement countdowns.

Bernard had to train some employees, including the QA director, on the platform, which features “a lot of buttons that can do a lot of things.” “Merge request,” for example, may be familiar to a developer but not to a new user who’s never seen code.

“Having some noise in the platform can be difficult for users that are not used to that,” he said, while emphasizing the cost benefits of using a tool familiar to many in the company.

In its early years, Bernard said, Cognivia mainly collected study data using external platforms, but is now developing its own, and needs to track any potential bugs.

New systems inevitably introduce new potential incidents, and a Word doc can only hold so much.

GitLab’s “living” features are enough at the moment.

“It was difficult for us to say that we will pay a lot of money for something that will be too big for us,” Bernard said.