Adoption business change

Operations refers to the services and service management provided to the Software Development business and/or its customers. Operations includes services such as environment provisioning, networking, support, asset management, service management, estate management etc.

Product Adoption & Business Change

To gain Business Value from a new product or set of products it must be used effectively by its customers. Product Adoption and Business Change practices integrate a product into the users workflow to get the maximum return on investment.

This article is about adopting a new product or product family into the business workflow or with external customers, not Adoption of Holistic Software Development.

When a Project or Programme produces a viable Release of a Product, or Product Family, and it has reached the appropriate level of Done the Business may choose to adopt it, transitioning the Release to live User Environments for internal products or putting the release into Sales Channels (such as App Stores, Sales People, Partners, Sales Portals etc.) for external products.

In either case, despite a Release being ready, the Release may not always be adopted by users or sales channels as Business Change or Sales cycles might not be in sync with Release cycles. Releases that are not deployed carry latent quality and validation risks despite acceptance activities, so we recommend that adoption and release cycles are kept reasonably in sync. In Continuous Deployment environments Releases may be automatically transitioned User Environments or Sales Channels.

The impact of adopting a new Release may be significant requiring changes in business workflow, understanding of new services or sometimes abstraction of user activity as a business innovates leading to substantial learning curves for users. We recommend consideration is given to:

  • Support requirements being incorporated as part of product development all the way from Build or Buy decisions in Portfolio Selection through to Requirements decomposition.
  • Training and support for new services or changes in workflow
  • Business Change planning and activity for significant changes

Holistic Software Development promotes psychology based Business Change practices to aid in making effective changes in structure and behavior within organizations.

At the top right of the H-Model, and accordingly the big and small maps of HSD, we place Product Adoption and Business Change. The very top of the stack of our Definition of Done is “Business Acceptance” but to get there the Product needs to be not just operationally deployed, but used by its target customers.
Products are typically released to external markets, deployed directly to customer organizations, or deployed within an internal organization. In each case getting users to adopt the Product (or change) raises different challenges.
When a Product or Change has reached the appropriate level of Done the Business may choose to adopt it, transitioning the Release to live User Environments for internal products or putting the release into Sales Channels (such as App Stores, Sales People, Partners, Sales Portals etc.) for external products.
In either case, despite a Release being ready, the Release may not always be adopted by users or sales channels as Business Change or Sales cycles might not be in sync with Release cycles. Releases that are not deployed carry latent quality and validation risks despite acceptance activities, so we recommend that adoption and release cycles are kept reasonably in sync. In continuous deployment environments Releases may be automatically transitioned User Environments or Sales Channels. Late releases risk Business Value decay as the opportunities for use are missed.

External Products

Ideally, customers are pulling on a product eagerly awaiting it, or simply accepting regular updates (e.g. AppStore updates or a well marketed new game). In these cases, adoption is a function of marketing and need not take any significant effort other than deployment infrastructure.
However, an element of internal Business Change may still be necessary as a development Product becomes operational its support profile will change. Often a move from batched development workflow such as agile/iterative development to continuous flow makes sense to become more responsive to user feedback.
The ongoing maintenance and support of a product will come into Business As Usual costs for the organization and so will be part of the Portfolio Selection and Continuous Investment Review. When Business Value no longer justifies maintenance budgets Products should be retired.

Internal Products

Internal Products are those deployed within the developing organization, but we also include bespoke products deployed by suppliers directly into target customer organizations.
The adoption of internal products may be more challenging as the Business Change involved in using a new Product or change comes into scope of the work.
The impact of adopting a new Release may be significant requiring changes in business workflow, understanding of new services or sometimes abstraction of user activity as a business innovates leading to substantial learning curves for users. We recommend consideration is given to:
  • Training and support for new services or changes in workflow
  • Business Change planning and activity for significant changes
  • Clarity on support models, and the funding of them, for all new products and changes regardless of the development processes used

Holistic Software Development promotes psychology based Business Change practices to aid in making effective changes in structure and behavior within organizations.