[RBM] - Case study - too good to be real!

Okay, today it's time for a second case study. This case is that good that in the first moment I thanked that it's successful. However, it's not!

Let's get down to the details. This will be about big FAANG company, you can imagine that they don't want transformation and modernization processes. It's not true - they want as any other. The story will be about project to standardize process of task management, it's an authentic story however names and subject of it was changed to anonymize it. Presently, company utilize mostly 15 different tools - from Jira, Trello by Github, Gitlab and some very specific tools built-in in some bigger systems, including few that they write on their own.

Problem with such arrived when company recognize need to analyze data included in those systems to find ways to optimize how processes looks and increase efficiency. Some tools have easy to use API, others have API, but that don't give custom data we set, others have limited API. And even others - including written internally - haven't any API at all, as it look like not needed. Numbers of methods to gather those data are numerous, and it's pretty hard to project to get them and unify to the same form that they can be useful.

The company recognize that cleaning up is needed in what tools were used and all the projects should be migrated together with data. It will require of course all the data operations, but only once. To conduct this migration, a new manager was hired. She conducts a massive set of workshops to gather information about how teams works, what are features they require, what information is important, and all other needed facts.

Based on analysis of this data, company decide to write an entirely new tool that will pass to their needs. Including part of analytical tools that they want to introduce on the start. This idea is signature and promoted by CEO. He also delivers budget for this project from the free hand.

Our Manager responsible for this project built a team to cover needs, both from internal people and new hires. Project took nearly 2 years, it includes multiple consultancies and changes based on teams feedback. Finally, team itself and one of the most active teams in consultations land with their projects in the brand-new system.

At this moment we can say - big success!

Not!

As usual, there is one small thing that has big impact that was not considered. Our success ends with new team in this new tool and migration of one of custom software team to this. Possible because they haven't capacity to maintain his system.

No one in this project assume space for migration tooling for used systems, budget and time planning in those teams for migration. Things related with integrations that give platforms current task managers was part of. No one think of things like access for users that doesn't work in company - like, for example, Open Source community engineers.

Then it happens, we got a beautiful new system that maybe some day in long future can be used by 40% of teams. Which at last will never solve the initial problem. Analytics of how team works in entire company.

Lesson learned from this project for me, it's to get paper commitment for each team that we consider will use this system. Paper commitment will obligate them to plan it, to budget it and really validate if they can use those tools. We can early after design sessions get information that it potentially will be 40%, and it will take 7 years. We will fail early with feedback that we can use to design a better solution - like potentially extension to current tools or something else. At minimum, we will to save these two years of work in this project.

Have you other cases to share with us of similar projects?