Second-system effect ¶
I regularly see the Second-system effect when building products and introducing new technology. A simple, well-functioning system reaches its limits and is replaced by a much too large, bloated system due to over-expectations and over-confidence - and everyone is unhappy. :)
Maybe you know this. In my practice, for example, a small, hip social media agency is handed agency software designed for venerable, large, classic advertising agencies with print processes. Or, even more blatantly, an eCommerce startup introduces Microsoft’s Navision and subsequently uses only 20% of the initially introduced functionality at the end of the day and has replaced or supplemented 80% of it with its customizations.
Branch by Abstraction ¶ ¶
In software development, there is the principle of Branch by Abstraction. . However, this principle can also be applied to developing products and introducing software in the company.
In a Nutshell ¶ ¶
Never change a system at the same time and increase the range of functions!11
Introduce new features or other processes only after a new system (with old scope) is established!
Step by Step ¶ ¶
First, take stock. What is currently used, and what works? Is everything based on an Excel/spreadsheet? What are workarounds presently being done?
Based on this, lean software can be built or introduced, which, in terms of the feature set, but in version 1.0, first of all, precisely reflects the current use and which imports the current data. No more and no less. This can be implemented quickly. Then the existing processes and workflows can first get used to the new software.
Then, in short, sprints adapt the system to actual needs. A dual approach is recommended here:
- Which processes can be optimized in principle (in the department, synchronization with other systems, etc.)?
- How can this be mapped in the system?
Finally, I would like to empathize once again that one should think here more from the user than from the technology:
After all, a flawed process that has been digitized is still a lousy process truism from digitization consultants. (This entry is based on an email I wrote this week to a startup growing out of its spreadsheet).