The product elaboration subtheme contains those activities that will turn the concept into an actual market-ready product. There are many methodologies that prescribe how a product should be developed.

As contextual information, we provide some development methodologies here in the context of software development:

 

• Waterfall process: the waterfall process model is a sequential process model where the various steps of the process are executed in sequence.

 

 

The model was first described (and criticized at the same time) in the paper “Managing the development of large software systems” (Royce, 1970). Even though the sequential nature is often –rightfully- criticized, the definition of the various stages remains useful to this day. Royce identified the following steps:

• System requirements: the goal in this step is to gather the functional, financial and timing requirements of the software. This step details the purpose of the system.
• Software requirements: the goal of this step is to gather the software features required to satisfy the system requirements.
• Analysis: in this step the details of each software features are elaborated. For each feature we need a set of inputs, outputs and algorithm specifications.
• Program design: in this step the actual software is designed based on good software design principles (such as low coupling and high cohesion requirements).
• Coding: in this step the software is programmed.
• Testing: in this step the features of the software are tested.
• Operations: in this step systems management, maintenance and support are provided.

 

Even the initial paper of Royce already warned of the dangers of a purely linear approach :“I believe in this concept, but the implementation described above is risky and invites failure. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analysed. These phenomena are not precisely analysable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required.”

Later models, such as the ones described below, are characterized by a more iterative approach, allowing for faster feedback on design and implementation decisions.

 

• Unified Process: the unified process describes an iterative and incremental software development process (Wikipedia, 2014). There are various versions of this process, among others the Rational Unified Process (where the approach was pioneered), the Open Unified Process and the Agile Unified Process. The process was first described in 1999, as a unified version of several earlier methodologies proposed by the authors (Ivar Jacobson, 1999). The main philosophy behind the Unified Process is that the steps performed during a software development process can be plotted along two different axes, each representing a different aspect. Those axes are the time axis and the core process workflows axis.

The core process workflows axis represents the various activities (denoted as “workflows”) that are performed during a development process. These activities are identified as Core Process workflows:

• Business Modeling: the goal of business modeling is to document the business processes using business use cases (semi-formal descriptions of how the business works).
• Requirements: in the requirements workflow the analyst should describe what the software should do for the business in so called system use cases. The goal is for the business and the software engineers to agree on the functionality of the system.
• Analysis and Design: during Analysis and design we describe how the system should be realized during the implementation workflow.
• Implementation: during this workflow the solution is programmed using the software abstraction of “components”, self-contained modules of code.
• Test: during this workflow the system is tested on various levels, from lower level ‘unit-tests’ to higher-level ‘integration tests’.
• Deployment: during this workflow the software components are released to the customers.

These activities are identified as supporting workflows:

• Configuration and change management: this workflow takes care of handling the various versions of artifacts that are generated during a software project.
• Project Management: the Unified Process provides three frameworks for managing software projects – a framework for managing software projects (referring to the other sections of the Unified Process described here), framework for managing risk and practical guidelines for planning, staffing, executing and monitoring projects.
• Environment: the environment workflow takes care of providing the tools and the processes that software teams need to develop the software.

Figure 8: A visual representation of the Unified Process (Rational, 2003)

The time axis is divided in four different phases – inception, elaboration, construction and transition. The idea behind the two axes is that the intensity with which the various workflows are performed varies per stage, represented by the curves in Figure 8. The various phases, in their turn, are further divided in time-boxed iterations. An iteration is a time-period during which a set of actions are performed. The goal is to start with core functionality in the earlier iterations, and to progress to other functionality in later iterations, building on the foundation of the earlier iterations. In this way, the process is both iterative -during each iteration (potentially) all workflows are performed, albeit in varying levels of intensity depending on the phase – and incremental – each iteration builds on the previous. Because we get testing feedback much earlier in the process, vis a vis the pure sequential waterfall approach, the risks with respect to the fit between the software and the requirements are reduced.

•Scrum/Agile: Scrum is described by the Scrum Alliance as follows: “Scrum is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change. As the leading Agile development framework, Scrum has predominantly been used for software development, but it is also proving to be effective in efforts far beyond.” (Scrum Alliance, 2014) Although “Agile” is used for a variety of project management approaches, Scrum is by far the most popular approach in the family.

 

Figure : the anatomy of a sprint (Mountain Goat Software, 2005)

Similar to the Unified Process, Scrum focuses on iterative and incremental software development. The main difference is the philosophy regarding project management and documentation requirements between the two approaches. In Scrum, the emphasis lies on the delivery of working increments of software at the end of each iteration. To develop the complete software, a product backlog containing “user stories” which describe the features of the software needs to be implemented. The development process is time-boxed in iterations called “sprints”.
At the start of each iteration, during a sprint planning meeting, the set of items is estimated and ranked. Next, a workable subset of these user stories is defined as input for the next sprint (based on the development time available during the sprint and the estimations of the user stories). During the sprint development, each day is started with a stand-up meeting where each member of the scrum team can state what he has done the previous day and what he is going to do the next day. At the end of each sprint, a working increment of the software should be shippable to the client. If, during a sprint, issues pop up, sprint items are removed from the backlog to ensure timely delivery of the software rather than the delivery of all the functionality defined in the beginning of the sprint.

LEAN PROCESSES

In more recent years, “Lean” principles have been applied to other parts of industry and business outside of the production settings. A prime example is the “Lean Startup” movement pioneered by Eric Ries (which is presented in detail). The Build-Measure-Learn feedback loop forms the process that Ries envisions for a lean startup. In order to get to “Validated Learning” as quickly as possible, one must build a prototype (which can range from a pen and paper prototype to a working prototype), measure the response through qualitative or quantitative research methods such as experiments, and learn from the results. The result of a learning phase should be either to fine-tune the approach, or to “pivot” to a radically different approach.

 

Figure : the Build-Measure-Learn Cycle (Ries, THE LEAN STARTUP METHODOLOGY)

While Ries describes many of the important principles and corroborates them with examples, In (Maurya, Running Lean: Iterate from Plan A to a Plan That Works, 2012), the author of “Running Lean” (Maurya, Running Lean: Iterate from Plan A to a Plan That Works, 2012) gives a more practical approach to the “Lean Startup” process. There are three steps in the “Running Lean” process:

• Document your plan A.
• Identify the riskiest parts of your plan.
• Systematically test your plan.

For documenting the plan, Maurya advises to use the “Lean Canvas”. The Lean Canvas, which is based on the Business Model Canvas by Alex Osterwalder (Osterwalder A. , 2010), is a one page overview of the business plan. Figure 10 provides an overview of the Lean Canvas and its operationalisation is documented in subtheme Process Types.

Figure 10: the Lean Canvas (Maurya, Lean Canvas, 2012)

INTEGRATING PRODUCT AND SERVICES

More often than not, product and technical innovation alone does not produce sufficient, inimitable or sustained competitive advantage and growth and notes that major industry players are complementing their respective product offerings with service innovations for the purposes of generating enhanced customer value, cross selling, lock-in and improved brand preference. The increasing importance of service innovation can be credited to the realisation that innovation is broad and does not have to be limited to technology-based innovations.

As a discipline, service innovation is not limited to service sector companies as it is premised upon any innovation activity with service like attributes and as such, its importance has also materialised with the dominance of the service economy and the business impacts associated with a servitization agenda. In a service-dominant logic, service innovations are taking centre stage of manufacturer-consumer exchange whereby physical goods are increasingly become servitised, i.e. they can be seen as appliances which derive their value from their ability to provide service. In this vein, many companies are moving from business models where value comes solely from physical goods to models where value derives from intangible elements such as services, knowledge, experiences and relationships. While no universally accepted conceptualisation of service innovation exists, typologies in the field are largely grouped into domains concerning activities oriented towards the design and development of new service product offerings, creating or adapting business models and developing and/or innovating customer interface and delivery mechanisms.
(Shelton, 2009) notes that leading innovators add increasingly higher levels of services and advance through four stages of solution management maturity, incurring increased revenue returns as a result (Figure 11)

 

Figure : Solution Management Maturity (Shelton, 2009)

Product–service system (PSS) consisting of ‘tangible products and intangible services designed and combined so that they jointly are capable of fulfilling specific customer needs’ representing a vehicle to simultaneously enhance competitiveness and to foster sustainability. A PSS business model allows firms to create new sources of added value and competitiveness, via serving client needs in a solution orientated manner and relationship building with clients enhancing customer loyalty.

 

BIBLIOGRAPHY
Ivar Jacobson, G. B. (1999). The Unified Software Development Process. Addison-Wesley Professional.
Maurya, A. (2012). Lean Canvas. Opgeroepen op 10 30, 2014, van Practive Trumps Theory: http://practicetrumpstheory.com
Maurya, A. (2012). Running Lean: Iterate from Plan A to a Plan That Works. O'Reilly Media.
Mountain Goat Software. (2005). Topics in Scrum. Opgeroepen op 10 22, 2014, van Mountain Goat Software: http://www.mountaingoatsoftware.com/agile/scrum/overview
Osterwalder, A. (2010). Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. John Wiley and Sons.
Rational. (2003). Rational Unified Process - Best Practices for Software Development Teams. Rational.
Ries, E. (2011). The Lean Startup. Crown Business.
Ries, E. (sd). THE LEAN STARTUP METHODOLOGY. Opgeroepen op 10 30, 2014, van The Lean Startup: http://theleanstartup.com/principles
Royce, W. (1970, August 26). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, (pp. 1-9).
Scrum Alliance. (2014). What is Scrum. Opgeroepen op 10 22, 2014, van Scrum Alliance: https://www.scrumalliance.org/
Shelton, R., 2009. Integrating Product and Service Innovation. Research Technology Management, pp. 38-44.
Wikipedia. (2014). Unified Process. Opgeroepen op 10 22, 2014, van Wikipedia: http://en.wikipedia.org/wiki/Unified_Process