| |JULY 20239CIOReviewsubject to a plan-do-check-act cycle and new requirements could be addressed by new projects. Now it is time for our friend reality hit us again as it is often quite difficult to win a project selection battle when what you are proposing are improvements to capabilities already in place. Put simply, new projects that create "new things" look more interesting than the ones that keep things running. How do you deal with technical debts of closed projects? How do you keep your talents engaged and up-to-date in the ever-changing data space? A Product-Oriented OrganizationI have joined AB InBev in 2021 to lead the Data and Analytics teams in our major digital transformation program. The program itself is focused on the standardization of core business The ultimate goal of defining an organizational structure like that is to build high-performance teams to ship products that will satisfy customers' needs throughout a long journey consistently and sustainablyprocesses and the modernization of the underlying technology platform. In that context, we have deployed product teams to take over entire knowledge areas and process groups of the business. We follow the same approach with our data teams. Once we have defined our data strategy ­ set the field game, targets, and reasons to win -- aligned with the program strategy, we arranged product teams to work on individual elements of it. While some teams are developing software as their products, others have been creating the building blocks for other data and functional product teams.The ultimate goal of defining an organizational structure like that is to build high-performance teams to ship products that will satisfy customers' needs throughout a long journey consistently and sustainably. Obviously, pressuring business needs are prioritized and addressed by MVPs (minimum viable products), but the teams will always keep in mind what the endgame products should look like. The mindset differs from what we see in project teams as they tend to be more concerned with delivering the project scope, not necessarily with the long-term vision. Hence, it also aligns quite well with executing data strategies and the implementation of data management functions ­ especially the foundational functions (sometimes called "defensive") like Data Governance, Data Quality, Reference and Master Data Management, etc.We found the communication with business stakeholders got a lot easier as they seemed to better understand that requirements not shipped in MVPs do not fall through the cracks as they have seen happening in projects, but are backlogged for future product releases instead. There is no fear of losing an important feature and this helped a great time while resolving conflicting priorities. As "Product Managers", our data professionals must be constantly checking the effectiveness of their data products, listening to the users' feedback, addressing technical debts, and maintaining alignment with industry best practices and trends.Implementing a successful data strategy in large organizations takes lots of time and effort. While it is possible to achieve the goals with a set of correlated projects in a program, I would rather recommend adopting a product approach. The data strategy becomes a powerful mantra for the product teams and the talents are more engaged in something they believe in. They "own" the products and will think twice before taking shortcuts to just deliver something. More importantly, the foundational building blocks of your data management framework are rarely at the desired stage, so data teams have to strike the right balance between groundwork and innovative initiatives. Having a product mindset will also keep the focus on the endgame solutions and avoid the pitfalls of short-tem implementations that are not properly maintained and lose value quickly.
< Page 8 | Page 10 >