A software product company typically evolves from a product to a product line (SPL) due to expansion of base product functionally and technologically. This necessitates the company to apply a unique scientific approach towards change management. In this approach, the focus is on the impact assessment of entire product line with due consideration of the inter and intra-relationships between various artefacts of the product line. In the evolution of a software product line, the instances of changes that happen can be broadly categorized into technology changes, functional changes and corrective changes. A given change may impact a software product line in different fashion such as multiple modules impact, component impact or product framework impact. This concept of software product line change management is depicted in the adjacent diagram for ease of understanding.
Thus, in order to control the impact of a change, it is essential to create and maintain
- Core components base: a repository of all core components that make up a software product line
- Dependency base: a repository of relationships between the core components, modules and products within a software product line
So, how is Ms. Anita, in-charge of change management in ABC, going to apply these into the practical world of her own product company? Obviously, product development department (PDD) is a prime target for applying these change management principles. There are two product lines – CiniCare for small clinics and HospiCare for hospitals. Within each product line, there are products for each state based on the state regulations. However, PDD is organized with respect to functionality and there is no single owner for a product line in PDD. So, we suggest as a first step, that Ms. Anita appoint a single owner per product line for implementing the ‘Revolution with ABC’ (RWC) program.
The biggest task is to assess the impact of changes in this program viz. Social media, Mobile, Analytics and Cloud. The PDD maintains a central repository of all components of two product lines and it is up-to-date. However, there is no single knowledge base listing all inter dependencies. As this knowledge is scattered across architecture group and integration group, Ms. Anita is suggested to take a pragmatic approach of using interaction models and integration scripts to put together Dependency Snapshot in the form of an MS-Access database. She can achieve this by forming a SPL wise task force headed by SPL change owner and comprising of key architects and integration specialists. At the same time, she should set up a group of product functional analysts in PDD to document briefly the functional specs of each of the change drivers and identify the major UI and data components that need to be changed. With these basic channels set in motion, now she should turn her attention to the change management organization in PDD.
As a practice, PDD already has a Change Control Board (CCB) in place to manage routine change requests. The CCB has representatives from business, architecture, development, integration, testing and operations group. Anita should integrate RWC program with the CCB to avoid conflicts. In order to accommodate small tactical changes for customer needs while year-long RWC is on, Anita has to make CCB accept RWC as an overarching frame of reference in the working of CCB for any change request. Incidentally, Anita also discovers that the CCB has no representation from the outsourced product development (OPD) partner. After noting that the OPD partner has pretty high understanding of ABC product lines, Anita insists upon taking from them a representative into the CCB. Now, Anita is supposed to get two major inputs to drive RWC in PDD:
- List of direct impacted components from functional analysts
- Dependency Snapshot from the task force of each SPL
Once these are available, she needs to enable a discussion in the CCB to understand all impacted components and to plan for making necessary changes to them. Agile being the methodology, the product backlog will be updated based on prioritization done by CCB. Along with this, she also has to insist upon getting the RWC checklist to be agreed upon as a part of governance for any other change that comes in the way forward. With all the ground work done firmly, Anita can then step back and be an observer for RWC getting executed in PDD.
Here are some steps that Anita asked the Change Management Genie to perform in PDD:
The question that a startup product company PQR would ask here is, “what’s in it for us?” As a startup, PQR does not have so many products and components and configurations and operations. Is a startup company immune from this change management Genie? Not quite. The start-up company faces unique challenge of ‘first time recipe’ as their product specifications usually undergo changes. The cause might be market driven or technology driven, but the impact could reset the development progress several milestones back. It could mean redevelopment of many modules and re-verification or significant changes in the framework design of the product. The dilemma seen usually is how much can be reused.
In case the product idea itself undergoes a fundamental change, then all need to go back to the drawing board! For such a startup company, at times a change may pose a threat to very existence.
The visionary product owner, Ray, of startup PQR is wise enough about such future threats. While he has an expert and energized team of technologists and business analysts on board, Ray partners with a smart, light-weight OPD provider, HSPL early in the game. This enables PQR to benefit from the vast knowledgebase of domain and technology that HSPL has built over a period of time.
From his past experience, Ray decides to adopt Lean Business Model approach which prepares PQR to expect changes rather than get surprised by them. The lean approach involves drawing large picture on business model canvas but leading to the lightest meaningful business product as first version to hit the market. This not only saves the initial funds of PQR but also reduces the cost of changes when needed. On the product development side, an important handle in change management is to have logical models prepared early. This means having object model, entity relationship model and use case model. This is very important because irrespective of changes, the logical knowledge remains useful and it also provides an anchor point to start the rework.
The change management in a startup product company becomes controllable through these two handles – lean business model and logical knowledge models. Then the case of change can be handled through assessment of impact through models and leveraging all resources, including OPD provider for quick remedy. To summarize, a startup should:
