By Tom Gill, Senior Consultant, CIMdata Inc.
Much has been written about Product Innovation Platforms as solutions that enable a strategic, business approach to innovative products and services, as well as their end-to-end lifecycle processes (e.g. product development and support). Most of this material has been explanatory and a few benefits have been described. Less has been said about the implementation other than pointing out that innovation strategy is first and foremost a journey (not a destination) and that this journey is not a shrink-wrapped solution, e.g., commercial, out of the box software, or COTS.
However, just because innovation is an ongoing journey without a COTS solution, enterprises should not be deterred from developing a strategy for building a product innovation platform. Two development approaches make platform development practical on a do-it-yourself (DIY) basis.
They are Agile, team-based software development (and Agile’s “scrum” initiative in particular) and the “digital sandbox” development environment sometimes known as Greenhouse.
Agile and the digital sandbox won’t achieve anything, however, until product developers and PLM implementers join hands to push for a Product Innovation Platform. This push is Step 1 in the Product Innovation Platform journey; whether the push is at the enterprise level or in a business unit makes little difference.
Product Innovation Platforms seamlessly integrate many diverse tools, systems, and processes into environments for new product creation, and work especially well in addressing the complexities associated with smart connected products. As successes accumulate and experience grows, these capabilities can be expected to expand in breadth and depth within the enterprise. Eventually they will reach throughout the enterprise and transform the organization’s product lifecycle.
Product Innovation Platforms enable technically oriented teams working in multiple, overlapping lifecycles to capture the full product definition, which reaches from a product’s conception through its end of life years later. Information is shared as teams collaborate across departments, customer groups, supply chains, and all the business partners that make up the extended enterprise throughout the lifecycle.
The work of implementation teams coalesces into an environment that encompasses and optimizes portfolios, programs, reuse, optimization, quality assurance, profitability, maintenance and field service, compliance, risk management, and more.
A DIY Product Innovation Platform is a software development project that must be driven by the needs of the business. If time frames and skill sets dictate, the technology work can be outsourced, although it doesn’t have to be. More importantly, even though this is DIY, it still needs to follow acceptable practices. The project must encompass all elements of the software development lifecycle—requirements, planning, execution, testing, deployment, maintenance, etc.
This is a key part of the Product Innovation Platform story that has not been well told, but left to readers' imagination. Also, too frequently left to reader imaginations are the benefits of Product Innovation Platforms. They are summarized in a CIMdata Commentary that can be accessed at CIMdata.com.
Agile software development constitutes Step 2. It is built on the reality that change is not only constant but unpredictable. In implementing solutions, “customers” are often unable to spell out their needs until developers and programmers come up with some insights. This is especially true when the project will ultimately bring sweeping change to the ways in which new products have been created. And as with Product Innovation Platforms, Agile is not COTS.
Agile requires a high-level plan that incorporates the needs and objectives of the business unit / enterprise. A key part of Agile’s highly collaborative development is the scrum, as in a rugby scrum. The Agile scrum is a daily short, stand-up meeting when product owners, subject matter experts, programmers, and testers—the development team members—update one another on successes, changes in plans, and unforeseen snags.
Scrum teams are guided by user stories, which are functional requirements from an end user’s perspective, and which support the overall business objectives. These “stories” are informal but clearly understood narratives used by scrum team to configure or customize the elements of a Product Innovation Platform—for example, an underlying Product Data Management (PDM) solution. Each user story implementation requires a complexity assessment and a valuation for the anticipated effort for prioritization. User stories can be added or updated any time during the project if they clarify the current scope but do not extend that scope.
As in any project, getting anything done means establishing blocks of time. For an Agile scrum team, these blocks are usually two or three weeks, the time it takes to turn a user story into tested, working software. In Agile, these blocks of time are known as sprints. A sprint results in working software with incremental improvements leading into the high-level plan though not necessarily an immediate software release to end users and customers.
Sprints also drive the cadence of the release process; a good cadence balances project momentum against the risk of haste causing turmoil. Sprints are based on what Agile terms the Minimum Viable Product. This is the minimum functionality that will satisfy the user stories and enable product deployment. In short, no bells, no whistles, no nonfunctional requirements. This applies to documentation as well—only what is needed to keep the scrum team moving forward.
In sum, Agile is about incremental progress and quick hits that can be quickly put to use. Quick hits segue into Step 3, creating a software development environment, a digital nursery, if you will, that generates small, rapid successes that are tied to the business case.
The digital nursery is a low-risk, IT-sponsored, company-funded development environment. Developers can be assured that their prototypes meet enterprise IT standards while sidestepping the perennial bandwidth and backlog headaches. Developers can use data sets, formats, and coding tools that are aligned with and comply with enterprise architectures and governance rules.
Collaborating in a digital nursery, developers—and anyone with a good idea—can conjure up, code, and quickly test creative solutions. These solutions often include reaching into the data silos and spreadsheet hoards that litter every enterprise. Gnarly details can be worked out and tested with little risk and minimal overhead.
Digital nurseries align well with Agile’s “lightweight” approach to continuous improvement, helping:
- Keep the abilities of the enterprise's savviest developers focused on priority tasks and solvable problems.
- Ensure that risky but promising ideas aren't set aside and forgotten.
- Complement the traditional approaches for managing obsolescent “legacy” solutions—Rip & Replace (R&R), Embrace & Extend (E&E), and customization.
- Ensure that developments in any form are responsive to both challenges and opportunities, i.e., Agile.
The philosophy of the digital nurseries is Just Do It. Evaluate and wring out new capability, gain acceptance, and test it. If it works, productionize it within the context of the enterprise’s Product Innovation Platforms.
Product Innovation Platforms are a key element of digital transformation—the biggest upheaval in business, government, and everyday life since assembly lines and computers. As with every previous technological wave nearly all who scramble to get out in front, to seize the day, will prosper. We have spelled out these three steps as a DIY approach because we believe that very few of those who decide to wait a little longer will prosper.