Need advice? Call Now, Schedule a Meeting or Contact Us

Speak To An Advisor
Flag
  • FlagAfghanistan
  • FlagAlbania
  • FlagAlgeria
  • FlagAmerican Samoa
  • FlagAndorra
  • FlagAngola
  • FlagAnguilla
  • FlagAntarctica
  • FlagAntigua and Barbuda
  • FlagArgentina
  • FlagArmenia
  • FlagAruba
  • FlagAustralia
  • FlagAustria
  • FlagAzerbaijan
  • FlagBahamas
  • FlagBahrain
  • FlagBangladesh
  • FlagBarbados
  • FlagBelarus
  • FlagBelgium
  • FlagBelize
  • FlagBenin
  • FlagBermuda
  • FlagBhutan
  • FlagBolivia
  • FlagBosnia and Herzegovina
  • FlagBotswana
  • FlagBouvet Island
  • FlagBrazil
  • FlagBritish Indian Ocean Territory
  • FlagBritish Virgin Islands
  • FlagBrunei
  • FlagBulgaria
  • FlagBurkina Faso
  • FlagBurundi
  • FlagCambodia
  • FlagCameroon
  • FlagCanada
  • FlagCape Verde
  • FlagCaribbean Netherlands
  • FlagCayman Islands
  • FlagCentral African Republic
  • FlagChad
  • FlagChile
  • FlagChina
  • FlagChristmas Island
  • FlagCocos (Keeling) Islands
  • FlagColombia
  • FlagComoros
  • FlagCook Islands
  • FlagCosta Rica
  • FlagCroatia
  • FlagCuba
  • FlagCuraçao
  • FlagCyprus
  • FlagCzechia
  • FlagDR Congo
  • FlagDenmark
  • FlagDjibouti
  • FlagDominica
  • FlagDominican Republic
  • FlagEcuador
  • FlagEgypt
  • FlagEl Salvador
  • FlagEquatorial Guinea
  • FlagEritrea
  • FlagEstonia
  • FlagEswatini
  • FlagEthiopia
  • FlagFalkland Islands
  • FlagFaroe Islands
  • FlagFiji
  • FlagFinland
  • FlagFrance
  • FlagFrench Guiana
  • FlagFrench Polynesia
  • FlagFrench Southern and Antarctic Lands
  • FlagGabon
  • FlagGambia
  • FlagGeorgia
  • FlagGermany
  • FlagGhana
  • FlagGibraltar
  • FlagGreece
  • FlagGreenland
  • FlagGrenada
  • FlagGuadeloupe
  • FlagGuam
  • FlagGuatemala
  • FlagGuernsey
  • FlagGuinea
  • FlagGuinea-Bissau
  • FlagGuyana
  • FlagHaiti
  • FlagHeard Island and McDonald Islands
  • FlagHonduras
  • FlagHong Kong
  • FlagHungary
  • FlagIceland
  • FlagIndia
  • FlagIndonesia
  • FlagIran
  • FlagIraq
  • FlagIreland
  • FlagIsle of Man
  • FlagIsrael
  • FlagItaly
  • FlagIvory Coast
  • FlagJamaica
  • FlagJapan
  • FlagJersey
  • FlagJordan
  • FlagKazakhstan
  • FlagKenya
  • FlagKiribati
  • FlagKosovo
  • FlagKuwait
  • FlagKyrgyzstan
  • FlagLaos
  • FlagLatvia
  • FlagLebanon
  • FlagLesotho
  • FlagLiberia
  • FlagLibya
  • FlagLiechtenstein
  • FlagLithuania
  • FlagLuxembourg
  • FlagMacau
  • FlagMadagascar
  • FlagMalawi
  • FlagMalaysia
  • FlagMaldives
  • FlagMali
  • FlagMalta
  • FlagMarshall Islands
  • FlagMartinique
  • FlagMauritania
  • FlagMauritius
  • FlagMayotte
  • FlagMexico
  • FlagMicronesia
  • FlagMoldova
  • FlagMonaco
  • FlagMongolia
  • FlagMontenegro
  • FlagMontserrat
  • FlagMorocco
  • FlagMozambique
  • FlagMyanmar
  • FlagNamibia
  • FlagNauru
  • FlagNepal
  • FlagNetherlands
  • FlagNew Caledonia
  • FlagNew Zealand
  • FlagNicaragua
  • FlagNiger
  • FlagNigeria
  • FlagNiue
  • FlagNorfolk Island
  • FlagNorth Korea
  • FlagNorth Macedonia
  • FlagNorthern Mariana Islands
  • FlagNorway
  • FlagOman
  • FlagPakistan
  • FlagPalau
  • FlagPalestine
  • FlagPanama
  • FlagPapua New Guinea
  • FlagParaguay
  • FlagPeru
  • FlagPhilippines
  • FlagPitcairn Islands
  • FlagPoland
  • FlagPortugal
  • FlagPuerto Rico
  • FlagQatar
  • FlagRepublic of the Congo
  • FlagRomania
  • FlagRussia
  • FlagRwanda
  • FlagRéunion
  • FlagSaint Barthélemy
  • FlagSaint Helena, Ascension and Tristan da Cunha
  • FlagSaint Kitts and Nevis
  • FlagSaint Lucia
  • FlagSaint Martin
  • FlagSaint Pierre and Miquelon
  • FlagSaint Vincent and the Grenadines
  • FlagSamoa
  • FlagSan Marino
  • FlagSaudi Arabia
  • FlagSenegal
  • FlagSerbia
  • FlagSeychelles
  • FlagSierra Leone
  • FlagSingapore
  • FlagSint Maarten
  • FlagSlovakia
  • FlagSlovenia
  • FlagSolomon Islands
  • FlagSomalia
  • FlagSouth Africa
  • FlagSouth Georgia
  • FlagSouth Korea
  • FlagSouth Sudan
  • FlagSpain
  • FlagSri Lanka
  • FlagSudan
  • FlagSuriname
  • FlagSvalbard and Jan Mayen
  • FlagSweden
  • FlagSwitzerland
  • FlagSyria
  • FlagSão Tomé and Príncipe
  • FlagTaiwan
  • FlagTajikistan
  • FlagTanzania
  • FlagThailand
  • FlagTimor-Leste
  • FlagTogo
  • FlagTokelau
  • FlagTonga
  • FlagTrinidad and Tobago
  • FlagTunisia
  • FlagTurkey
  • FlagTurkmenistan
  • FlagTurks and Caicos Islands
  • FlagTuvalu
  • FlagUganda
  • FlagUkraine
  • FlagUnited Arab Emirates
  • FlagUnited Kingdom
  • FlagUnited States
  • FlagUnited States Minor Outlying Islands
  • FlagUnited States Virgin Islands
  • FlagUruguay
  • FlagUzbekistan
  • FlagVanuatu
  • FlagVatican City
  • FlagVenezuela
  • FlagVietnam
  • FlagWallis and Futuna
  • FlagWestern Sahara
  • FlagYemen
  • FlagZambia
  • FlagZimbabwe
  • FlagÅland Islands

Digital Transformation through Innovation in Projects and Products

By Curt Raschke 01 Aug 2024
Digital Transformation through Innovation in Projects and Products

Technology Transformation and Innovation

The phrase “Digital Transformation” has become so ubiquitous in so many different contexts that the only commonality seems to be its use as a marketing concept to sell computer hardware, software and / or consulting services. It seems to have become an all-purpose generic “transformation” encompassing “agile transformation,” “cloud transformation,” “IoT transformation,” “big data transformation,” “as a service transformation,” “mobile application transformation,” “business intelligence transformation,” “process automation transformation,” “DevOps transformation,” etc.

The multitude of white papers, presentations, advertisements, webinars and blogs on the subject generally assert that through the proper mix of digital technologies and capabilities, companies can “transform” their business models, business processes, organisational structures, employee engagement, customer experience, etc. This literature also, unfortunately, generally fails to give much actionable direction on how to accomplish these desired goals. So how, then, can a company or organisation decide how and when to utilise the many available digital tools to significantly grow its business and / or improve internal customer satisfaction?

Fortunately, while many digital technologies are indeed new, technology-driven “transformations” are not, and provide useful “lessons learnt” that can be applied to the question of how to best exploit the newest digital technologies. Examples of such “transforming” technologies in the last 200 years include steam, electricity, telegraphy, telephony, internal combustion, radio, powered flight, photography, television, computers, and the internet; each of which “transformed” businesses and eventually society.

While each of these transformational technologies were very different, in every case, the actual transformations occurred through the innovative products (goods and services) enabled by the technology that delivered services not previously available. The first lesson learnt, then, is that all technology transformations actually occur not directly through the technology but through the use of products (goods and services) enabled by the technology, and the transformational value is through the service experience provided. The second lesson learnt is that transformational products are very innovative either in how the product is used or in how the service is delivered; that is, transformation and innovation are inextricably linked.

Digital (Product) Transformation

Based on the history of these previous technology transformations, a simplified explanation of digital transformation might be along the lines of: Creation and widespread usage of innovative software-enabled products that provide valuable, previously unavailable services to a broad range of customers and end users. Looking at digital transformation in terms of software-enabled products and services makes it easier for businesses to choose which digital tools to invest in and estimate how their business models, organisational structures, employee engagement, etc. will have to change to accommodate the new products. This approach also allows a company to leverage the extensive body of knowledge on product development and product lifecycle management to achieve its specific goals.

The first question a company should ask, then, when contemplating digital “transformation”, is not what digital technologies it should embrace, but rather what customer base does it want to serve and what needs or desires do the customers and end users have that are not presently met by existing products? Once the first question is answered, the second question is to ask specifically which technologies should be developed or acquired to enable goods and services that satisfy the unmet customer and end user needs and for which the customer is willing to pay enough to generate adequate financial return.

Too often, when companies contemplate digital transformation by focusing primarily on technology options, rather than the customer and end user needs, they inevitably end up using the technology to lower costs, respond to competitive products, or extend existing product lines; all of which may make good business sense but are hardly transformational. No, meaningful business transformation requires the deployment of transformational products that are both significantly innovative in how the goods and services are used or delivered and provide significantly greater value than existing products. Such product innovation, in turn, drives changes to business processes, organisational structures, employee skill sets, etc., with the degree of change determined by the degree of innovation needed.

The third lesson learnt, then, is that innovative products by themselves are necessary but not sufficient. The innovation must be carefully identified and managed so that the product enabled by the innovation provides significant value to both the vendor and the customer; the customer must be willing to pay enough for the product to generate adequate financial return on investment for the vendor. As will be discussed, this innovation management has both a product dimension and a project dimension.

Product and Product Delivery Platform Design  

There is, however, one major difference between many digitally-enabled products and non-digital products; the decoupling of the design of the product from the design of the platform delivering the product. For example, in the case of air transport services, the design of both the service (product) and the design of the user experience are integrated in the design of the airframe (platform) used to deliver the service. This is not the case for many digitally-enabled products where the service and user experience are often designed separately from the delivery platform, which may already exist (e.g. PC, Smartphone, or Tablet with Wi-Fi enabled inter or intra net) and which is often used to deliver multiple services. (It should be noted that the existence of standardised software-enabled product delivery platforms is one reason why digitally-enabled products can be designed and deployed so much faster and inexpensively than non-digital products, which generally require customised delivery platforms.)

Customers and End Users

Any successful product (digital or non-digital) must provide value for both the customer (who pays for the product) and the end users who consume the service provided by the product. Unless the product is sold directly to the consumer, however, the customer and end users are generally not the same and have different needs which must be simultaneously met by the product. Using the air transport example again, the customers for an aeroplane are the airlines, but there are multiple end users of the aeroplane, such as passengers, flight crews, air traffic controllers, catering companies, etc. The airline customers desire low acquisition and operating costs while the end users want comfort, ease of operation, reliability, predictability, etc., all of which must be accommodated by the platform design.

Understanding the needs of both customers and end users is especially important in developing transformational digital products since the type and level of innovation may be very different for the two different categories. As an example, consider the transformational digital products, Facebook and Google Search, where the customers paying for the service are the advertisers but the end users are the individual consumers of the services.

It should be noted that meeting the needs of customers and end users is critical whether the product is being developed for sale externally or being deployed by a company for internal benefit. When the product is targeted at external customers / end users, organisations generally spend the time and money necessary to satisfy both customer and end user because of the need to make the sale. Unfortunately, when the product is to be used internally, organisations too often do not feel the need to fully satisfy both because the end users can be essentially forced to use the product.

Product Innovation

Once a new product opportunity has been identified, the company should explicitly choose the market strategy for the product. If the product is to be sold to external customers, should it be used to defend and / or maintain an existing market for similar products (e.g. through cost reductions, improved performance, improved customer experience, respond to competitive threat, etc.)? Should it be used to expand and / or enlarge the existing markets (e.g. product line extensions to reach new sets of customers)? Or should it be used to create a new market category not presently served by existing products?

As shown in Figure 1, the amount of product innovation required is directly related to which product market strategy is to be used.

Figure 1 – Correlation between product market strategy, product usage, and innovation  

As also shown in Figure 1, innovation is needed not only in the product itself, but also in how the customers / end users actually use the product. If the new product is similar to existing products, not much innovation is needed by the users relative to what they already do. As the product market strategy changes, the amount of innovation by both the product developer and the product user increases. (Note that while the product market strategy applies to externally sold products, understanding the degree of innovation / change needed on the part of the end users is important for both external and internally deployed products.)

While innovation is generally a benefit, increased innovation brings with it known consequences that must be proactively managed. For example, since the exact product attribute or feature innovation needed cannot be completely known prior to introducing a product, innovation brings requirement uncertainty with it. This uncertainty, along with the fact that there are generally multiple ways to implement the product vision, leads to market acceptance risk. If the strategy is to defend / maintain an existing market or to moderately expand an existing market, this risk can generally be mitigated by asking existing customers and end users familiar with existing products which of the possible innovations they prefer, either through focus groups, surveys, or evaluation of prototypes. However, these well-known product evaluation techniques do not work well if the strategy is to develop a transformational product that creates a new market category or greatly expands an existing market. In such situations, successful products always introduce attributes or features outside the experience of existing customers and end users. (Think of Henry Ford’s famous remark that if he asked his customers what they wanted they would have said a faster horse; or Steve Jobs's observation that customers don’t know what they want until you show it to them.) Development of such products involves techniques such as design thinking, rapid prototyping and / or actual observation of how customers and end users actually work to understand what they really need as opposed to what they may say that they want. Such products also often need multiple iterations to be successful.

Change management is also generally needed to ensure the success of transformational products and should be carefully planned and executed as part of the product development. If the product is sold externally, this change management is generally called marketing and there are many well-known management techniques for educating the target customers and end users both on the benefits of the product and on how to use the product to realise those benefits. Change management is also important for internally deployed products, even though it is too often overlooked. If the internal users are not engaged in the design and deployment of the product and carefully educated on the need for the product and how to benefit from using the product, realising the benefits will be delayed or not fully achieved.

Successful transformational product development, then, requires a thorough understanding of both what product innovations the customers and end users actually need and what kind of behaviour innovations will be required on their part for the product to succeed. The product development project plan should provide both for enough product iterations to identify the innovations and for enough management flexibility to adjust the project execution as needed to deliver the innovations. The greater the degree of product innovation needed, the greater the degree of project flexibility required to identify and implement the innovations, and the greater the degree of change management / marketing needed to realise the benefits of the innovations.

Project Innovation

Products are planned, designed and deployed through projects. The Project Management Institute PMBOK Guide® states, for example, that “A Project is a temporary endeavour undertaken to create a unique product or service.” Like most of the project management literature, however, the PMBOK Guide® discusses in detail the different ways the “temporary endeavour” can be organised and the different processes needed to create the “unique product or service” without considering how the degree of innovation required influences the choice of organisation and processes.

As indicated in Figure 2, successful projects require finding the proper balance between Predictability / Standardisation / Efficiency and Flexibility / Responsiveness / Effectiveness. When developing medical device products, for example, all standardised FDA requirements must be predictably and efficiently met, while meeting non-FDA requirements generally benefit from management flexibility and responsiveness. Similarly, when developing financial products, the user interface requirements can be flexible while the back-end processing of the financial payments should be standardised and predictable. In general, the higher the level of innovation required, the higher the level of project management flexibility / responsiveness needed and the lower the level of innovation needed, the higher the level of predictability / standardisation needed.

Figure 2 – Achieving and maintaining project balance  

An excellent method for understanding the level of innovation / flexibility needed for a project was developed by Steven Wheelwright and Kim Clark of the Harvard Business School1. Following their work, Figure 3 shows how projects can be analysed in terms of how much the product being created differs from previously created products and how much the process used to develop the product differs from the process used for previous products. The project can be characterised as a derivative project, platform project, breakthrough project or R&D project, depending on the amount of change relative to previous products on one or both of the product or process dimensions. The larger the amount of product or process change, the larger the innovation and flexibility required to manage the project.

Figure 3 – Project management innovation / flexibility dependency on degree of product change and degree of process change relative to previously developed products.

Examples of product and process attributes to be considered when analysing the degree of innovation and flexibility needed are shown in Table 1 for both hardware and software products. Note that any actual project analysis will necessarily be organisation specific as it is explicitly tied to the previous organisational product and process capabilities.  

PRODUCT CHANGE ATTRIBUTES PROCESS CHANGE ATTRIBUTES 
Hardware Software Hardware Software 
Product features Product features Manufacturing process Infrastructure 
Functionality Functionality Manufacturing site Operations 
Level of integration Level of integration Materials Development process 
Performance level Performance level Design process DevOps 
Quality/reliability Product architecture Design/test software Deployment process 
Etc. Etc. Etc. Etc. 

Table 1 – Product and process change attributes determining degree of innovation / flexibility for hardware and software projects.  

As the overall degree of innovation needed changes between the different project types, so does the need for project management and project team flexibility along with the level of project execution risk and product technical risk to be managed, as shown in Figure 4.

Figure 4 – Correlation of project type, project flexibility and risk  

Product Development Innovation Matrix

As discussed above, successful new product development requires innovation management of both the product and the product development project. Figure 5 combines these concepts into a Product Innovation Matrix to enable the simultaneous analysis of the degree of innovation management needed for both the product and development project dimensions.    

Product Development Innovation Matrix

Figure 5 – Product Development Innovation Matrix  

This matrix has been used to successfully identify the level and type of innovation management needed for many different types of products across many different industries. We have found that while the details of what constitutes the different project types and different levels of product usage differ between organisations and industries, after some discussion, each organisation generally reaches consensus on how to define the terms that are meaningful for them.

Analysing the product development innovation management needs in this way generally clarifies not only the level of needed innovation, but also the specific aspects of the development plan that will require proactive innovation management. For example, typical Scrum development processes assume that the Product Owner or Customer representative is able to effectively prioritise feature development and determine the acceptability of the results of individual sprints. Such an assumption is generally valid if there is low to moderate innovation required in how the product will be structured and used. However, if there is to be significant innovation in the product features or how the product will be used, this reliance on an individual product owner or customer representation may not be adequate and more thorough analysis of usability such as detailed prototype evaluation or customer usage analysis should be employed.

Likewise, Scrum processes typically assume that the project team has all the needed skills and tools to reliably develop and test the product features. If low to moderate innovation of the product features or development processes / tools relative to previous products is needed, this assumption is generally valid. However, if the project innovation requires significantly different features or tools, the team structure, staffing or training will generally have to be modified to implement the needed innovations.

Business Transformation

As mentioned above, the Product Development Innovation Matrix was used to analyse product development innovation needs for different development organisations in many different industries. In each organisation, when multiple product developments were analysed, it was found that the low innovation developments generally mapped to the core business products of the organisation, the moderate innovation developments mapped to products intended to grow the business, and the high and very high innovation development mapped to business transformational products, as shown in Figure 6.

Product development innovation matrix and business results  

Figure 6 – Product development innovation matrix and business results  

This mapping of the product portfolio to the Product Development Innovation Matrix was generally very “eye-opening” for the executive management of the organisations doing the mapping. It generally showed that almost all of their product development resources were going toward improving or cost reducing the core business products or toward growing the business by expanding the existing product line to new types of customers. In general, very little effort was being expended on highly innovative, highly risky transformational products that would be needed to sustainable long-term business success.   

A similar situation is seen when products used as “digital transformation” examples in the published white papers and web articles are analysed. In general, software product enhancements are being used to improve the user experience or reduce the cost of existing core business products or expand the existing business by making it easier to identify and order existing products. While such software enabled product enhancements generally make good business sense, often the only businesses actually being “transformed” are those providing the tools and consulting needed to implement the enhancements.  

To “digitally transform” a business, innovative software enabled products must be developed and marketed that provide valuable, previously unavailable services to broad range of customers and end users. The innovations, both in the product features and the product usage, should be carefully identified and proactively managed to ensure that the delivered services meet customer and end user needs not met by existing products. Because of the high level of innovation required, the processes and tools used for developing the previous products are generally inadequate to manage the new innovations and the company must be willing to take risks and make changes to their normal way of doing business if they are to succeed.


References

  1. Creating Project Plans to Focus Product Development, Steven C. Wheelwright and Kim B. Clark, Harvard Business Review, September 2003