barm.dev
FR

No! A data project is not managed like an IT project

Setting up a dashboard is not the same as building an application. A real example, four days before a visit from senior management.

No! An analytics project (data, BI, DWH, …) cannot be managed like an operational IT project (ERP, CRM, application, …). Even though they share many similarities, setting up a dashboard is not the same as building a mobile app or migrating a business application. One has to adapt to the entire technical landscape, to internal processes, to company strategy and to political decisions. The other imposes a certain structure on the company, brings its own concepts and forces users to think within its model.

For me there is no doubt about it. It’s visceral, I just know. That’s probably thanks to my 15 years of experience and all the projects I’ve delivered. And yet, surprisingly, when I’m asked a specific question, when someone tries to apply “application” concepts to a “data” project, it becomes hard to give a clear and structured answer.

Here is an example I faced a few weeks ago. After a reorg at a pharmaceutical company, the commercial organisation of one country changed completely: it moved from a single sales line to two distinct sales lines, each split by medical indication. The impact on the dashboards was clear: all the products sold without any distinction by indication now had to be clearly separated. One more dimension, one more level of granularity; business as usual! A new feature was added to the backlog, to be deployed with the next release. That was without counting on the politics… for the senior management visit planned the week after the reorg, we were asked to show this distinction clearly, in order to justify the benefits of the changes with figures, at any cost! Developing and deploying such a feature through the standard process would have taken two weeks (on the fast track!). We had four days (weekend included)! How do you explain that to the group’s IT architects, PMs and process owners? Nothing in a standard development process justifies that kind of urgency. “It’s not a critical bug fix, so why this level of urgency?” “Why didn’t you plan this feature earlier?” So I took a deep breath and launched into long justification emails…

That’s why I decided to lay it all out, to take the time to list these differences, to develop clear explanations and to give a structured answer for each case.

In the coming weeks, I will post articles on these topics! If this speaks to you, if you’re interested or would like to discuss it, feel free to get in touch. I’m curious to know whether I’m the only one running into these difficulties!