A new software: project or product?
I was struck by this HBR article published some time ago. It seems to offer a concrete and interesting approach to maximizing the value extracted from digital assets: the "product approach ." This involves organizing IT projects as if they were products: a dedicated team, a profit and loss statement, a company positioning itself as an investor… a kind of business unit dedicated to the project over the long term. And that changes everything!
The idea is clear when the software is aimed at external clients: there will be direct monetization of the value for (and by) the users. It's a bit more complicated when installing an MES in factories, or an accounting software. Nevertheless, there is inspiration to be found there: the focus on the customer, but also the continuous adaptation to the market (users).
Imagine a company wanting to implement a Manufacturing Execution System (MES) to manage its production. The traditional approach is to assign the job to an IT team: meeting with the business users, gathering their requirements, writing specifications, purchasing (or programming), installing, and voilà, the project is finished. The project team is dissolved at GoLive: it's then handed over to support: another team, trained using the project documentation. And from then on, they troubleshoot: nothing is changed, neither in the processes described in the specifications, nor in the services provided.
With the "product approach," there would be a dedicated MES team: a clearly defined leader with significant autonomy, and a team working to win. This team would bring together business expertise (people with production experience) and IT specialists (solutions, infrastructure, etc.). This team views its users as customers: those who will transform their work into tangible value. It engages with them, meets with them, and understands their needs. It has the skills to understand. It deploys the MES and remains involved long-term to continuously adapt the tool to user needs and provide them with combined business and tool support to maximize its value. The team may be smaller once the project is complete, but it remains involved. And it is responsible for tracking the profits to demonstrate the economic viability of its product.
The agile approach is a step in this direction, but it often lacks economic logic. And the autonomy that goes with it.
While this organizational structure isn't always feasible due to practical reasons, such as team size or skill level, the inspiration remains. To maximize value, the key is to get users and software designers working together structurally, over the long term, with significant autonomy. And that requires organization!
Comments