Why software will always be too late!
For most businesses today, the software is not only an enabler for your business but a foundation. Often the software is where you can/must differentiate from your competitors. The right choices, e.g. process and features can accelerate your business.
Many organizations and managers see SW development as a discipline no different from electrical or mechanical engineering. As a result unconscious decisions which negatively affect the SW development speed and efficiency. Software is always the bottleneck and therefore should be a crucial pillar in your business foundation.
A long time ago, I read the book “The Goal” by Eliyahu M. Goldratt, which is about bottlenecks in manufacturing. This book describes how to optimize ‘good’ flows between production stations by optimizing maximum throughput and minimizing bottlenecks. While many businesses optimize for resource utilization versus a flow optimization.
Quote from the book:
“…furthermore, they identified processes at the heat treat, identified as their second bottleneck, that caused massive delays in their getting product through the heat-treat and which had also caused some products to be heat-treated multiple times instead of just once or not at all. …”.
If you replace “heat-treat” with SW development you can see how the same logic applies to R&D departments.
As a result I decided to use Goldratt’s approach to the R&D organization looking at the functional disciplines as ‘production stations’; mechanical engineering, electrical engineering, system engineering, and software engineering. By thinking about it in this way, it became clear to me that in some cases it would increase R&D output overall if we would slow down your mechanical and electronic engineering. In manufacturing terms: move from a ‘push’ model to a ‘pull’.
If mechanical and electrical engineering would do nothing, it could be more efficient for the organization than have these disciplines keep generating work for SW engineering. Those disciplines were allowed to do projects for quality improvement or COGS reduction if it did not require work for the software teams.
But SW is a different discipline, so I had to extend my model. In the end, I came up with the following picture. The mountain symbol represents a queue of work, ready to be processed by the next discipline
Electronic Engineering (EE) gets its requirements from Mechanical Engineering (ME) and System Engineering. System engineering from the Business Strategy (BS) e,.g. roadmaps.
See also the article:
The requirements are shown as mountains; the goods flow in Goldratt’s book. The image immediately shows the bottleneck at the end: SW and to according Goldratt will generate frustration at the spot of delivering machines. Departments: “they have never time for me.” The bottleneck SW engineering: “they slow me down as others show up on my desk, I often have to changes subjects, etc..”.
Note the two red mountains. All other departments generally forget these.
- The new software has to work on the installed base, which often needs to be supported for 10+ years in the capital equipment industry. PC’s can be replaced, but internal controllers, communication protocols, obsolete hardware often can’t be replaced. And who is willing to tell the customer their 15-year-old machine is not supported anymore? This should be the role of the service department, but they will lose revenue or a service contract. Who makes these decisions in your company? Many businesses lack a clear end of life strategy.
- Software requires maintenance, much like production equipment. Often code bases have 250-1000+ person-years invested in them. Who has time or money to re-write this? And who wants it except SW engineers? Does it add value? If you do not address this, your software code base will not be maintainable in 10-15 years and require an expensive rewrite. An excellent article to read is The hidden costs of software inventory. Software is an asset!
Back to the picture. What happens if:
- Too many Electronic Engineering (EE) RESULT additional work for SW
- Too many Mechanical Engineering (ME) RESULT additional work for SW
- Too much Innovation RESULT additional work for SW
- Too many Software Engineering RESULT additional work for SW
- Too much Market Requirements RESULT additional work for SW
- Too many Software Engineering RESULT there is always work
According to Goldratt, you must manage your good flow (your requirements) to manage your bottlenecks.
Are you not managing the resources?
Are you not managing the resources? Often your budget is limited, so adding SW resources is in most cases not possible. Reducing your EE / ME / SE resources can increase the speed of SW development (or replace them with SW engineers).
But large SW departments are also not efficient. Agile teams on teh other hand can resolve this. The workflow/requirements can be easily managed to have at least one agile team for every department delivering requirements; e.g. one team handling the EE requirements. However, those agile teams must have a product owner who can make decisions. Those product owners now manage the incoming goods/requirements. The product owner of the EE-agile-team could be the EE manager.
Downturn: In a downturn, the development budget is already reduced. In general terms: release the contractors, which in most cases are software engineers. So a downturn increases the problem, the software bottleneck.
What is needed during a downturn? Fast reaction to the market and competitor (Short ROI) to defend or gain market share. The software has the shortest development cycles. And we send them home! And it even gets worse. After the downturn, we can hire SW contractors again, but the mountains before the SW department have never been higher. ME and EE continued their development at full speed, and it will take some time until SW correctly supports this, so still no fast response to market changes.
So consider replacing part of your ME and EE staff (the “old disciplines”) with contractors and having more SW engineers on your payroll. Can software releases be on time? Yes, but for this read, “Releasing software on time is a choice.”
Why software will always be too late - Conclusion
Releasing software on time is a choice
-
- Optimize your R&D organization by looking into the software bottleneck.
- Manage the requirements coming from the different departments, including SW-maintenance and the installed base.
- Divide the SW requirements over different agile teams.
- Be more flexible with the “old disciplines” and have more SW engineers on the payroll.
- Creating a high performance team culture by empowering the team members (see also whitepaper High Performance Teams).
Why software will always be too late by Corné van Sommeren
‘Building Strategy and translating same into organisational reality
is a strength I would like to share with you’
Chief on Demand – Triceps Innovation & Technology
About Triceps
Triceps helps you achieve your goals. Thanks to our matching and coaching, you as a senior executive will switch to the next gear. At which management table do you really come to fruition? Or are you already at the right table and want to increase your effectiveness and creativity with support? With attention and strategic insight, Triceps gets you moving, both as human and as professional.
