We’ve been talking about challenges for incumbent manufacturers, and suggested in our last post that for manufacturers to thrive, they need to command privileged positions in at least some of the business ecosystems in which they participate.

A privileged position means:

  • Being core to or at the center of the ecosystem; or
  • Owning vital elements of the ecosystem (standards, technology, proprietary software, etc.)

We suggested some ways to achieve that, among them:

  • Ensuring that if there’s value in making your product ‘smart’, you play an important role in doing that — controlling or influencing the development of software, APIs, capabilities, standards, etc.
  • If your product has software in it, owning its design and development as much as possible, especially for controls.

But designing and developing software poses distinct challenges for incumbent manufacturers — even if they don’t try to do it themselves.

In particular, incumbents’ existing development processes for many industrial products (such as electro-mechanical devices ranging from valves to combine harvesters) are likely much slower than for software & electronics — and for good reason.  Such products (especially large ones) often comprise multiple integrated systems and components.  Changing one affects others, and can have unpredictable effects on the performance of the entire machine.  Moreover, a design change means changing manufactured parts and/or their fabrication — which, especially if it involves suppliers, can be slow, risky, and costly.  Accordingly, incumbent manufacturers have learned how to update their products carefully and with manageable pacing.

Software development cycles, on the other hand, are much shorter.  Software is easier to edit, test and replicate (even if the consequences are just as unpredictable, if not more so).  But precisely because it is easier to edit, software development processes have come to be dominated by modularity, agile methodology, and rapid development and deployment.

Harmonizing these differing development processes across a set of design projects for a specific product is not easy, even (or especially) if the software development is outsourced.  Except in cases of an entirely new product form, the physical product exists already, and the software project is about adding or upgrading sensors; adding communications in or out (from those sensors, for example); or automating (and/or optimizing) controls.  Hardware engineers do not generally write software, so the first challenge is setting and maintaining execution schedules between hardware and software engineering teams (coordination only between individual engineers is often insufficient).  A technical surprise or a shift in funding priorities can disrupt timelines, leading (in the worst case) to product delays or even incomplete (or buggy) solutions coming to market.  In addition, design changes to the physical product and the software can get out of sync, again requiring time and often-scarce resources to reconcile.  (Your software people may be spread thinner than you realize — especially if they must work with several product families.)

But there’s a deeper issue which may produce or exacerbate execution challenges:  it’s not uncommon for requirements to change (or to be too vague), leading to misalignment between hardware and software teams.  This especially plagues projects where the software component is outsourced or developed by a different unit of the company.   It may even be unclear who owns the user experience, or the entire solution’s architecture and requirements.

In addition to adding cost, time delays are a frequent outcome of these challenges; yet for a large industrial product, missing a competitive product upgrade cycle (or two!) can be fatal to market share and/or profit margin.

So, what can be done?

  1. Start upstream from execution, with a shared vision across hardware and software of the value proposition for what you’re doing. Are you adding software-enabled features because the competition has them, and you must keep up?  Ask yourself what the new capabilities will do for the customer, and whether/how that fits into your value proposition.  If you must catch up, you might as well leapfrog — but only so far as you are meeting a real customer need, and not just trying to “out spec” the competition. (Yet leapfrogging can be a dangerous temptation — you are likely to take on additional technical risk, as well as marketing / channel challenges.  And you had better be confident about profitability.)
  2. Ensure the product requirements are specific, measurable, and deliver the value proposition. Work together and be willing to listen to each other — often, the software team can suggest capabilities the hardware team didn’t realize were feasible.  Most important, when requirements change (as they often will over the course of a project), don’t assume everybody is aware.  Revisit the timeline and collaboratively make any needed adjustments.
  3. Consider developing a realistic, actionable product roadmap, incorporating some high-probability variants (e.g., funding cuts). This can align expectations and enable planning for contingencies. Perhaps most important, it enables you to be proactive — not re  And the roadmap needs to reflect — and reconcile — the differing challenges of hardware and software development (e.g., seasonal product testing).
  4. Establish program governance across all the participating organizations for the set of projects together delivering the product update. This doesn’t have to be extensive or bureaucratic, but it does need to include:
    • A joint repository of the project documents, including staffing, leadership, schedules, and requirements.
    • Who decides what, and how conflicts are managed (“decision rights” — especially over product architecture, standards, and shared systems). And not just in theory — the organization must honor the process and “walk the talk,” especially when it comes to balancing the interests of not only hardware and software, but of design, manufacturing, and sales & marketing.  (For example, who owns the specifications of the CAN bus on a vehicle?  Especially if it is the factory which must carry the cost of a better one?)
    • How communications between software and hardware teams will happen (e.g., when software teams change delivery dates for product features, how they will ensure the hardware teams know about it so they can plan).

Incorporating intelligence and connectivity into industrial products and components can be challenging, but it also opens new opportunities (as well as challenges) for incumbent manufacturers.  Failing to do so can mean eventual relegation to commodity status.  The manufacturing companies that will thrive in the future are likely to be “smart industrials.”

For more about operational governance, please see here.

Share This