Developing Innovative Integrated Business Solutions Using a Scrum Project Management Methodology

Abstract

Innovative manufacturers have used Integrated Business Solutions (IBSs) as a means to co-create products and services to solve diverse business problems and more effectively compete in their field of endeavour. However, the efficacy and benefits of IBSs have been diminished due to the rigid method in which project management has been applied. This paper provides a conceptual approach for manufacturers to create new revenue sources in collaboration with their customers by adopting an agile project methodology that accommodates the interactive and iterative nature of IBS development. The research findings highlight the lack of success in IBSs using traditional project management as the delivery method. It provides an alternative solution in the use of an agile project management approach with its customer-centred and iterative mindset. This paper provides a conceptual model of the agile method known as Scrum and describes how it better aligns with innovative IBS development. Though both IBSs and agile have been around for several decades, their development is still in a state of infancy. This research adds to the body of literature on the application of agile in IBSs and presents an argument for converting its conceptual model into a practice delivery.

1. Introduction

Manufacturing companies are moving downstream to develop new sources of revenue by co-creating value with their customers. They are creating value by delivering integrated business solutions (IBS) that either solve a customer’s problems or creates new value for the customer [1]. These solutions can be in the areas of increasing a customer’s asset effectiveness, competitiveness, enabling market expansion, or mitigating financial risk [2,3,4,5]. Such manufacturing firms are realizing that to compete effectively in today’s dynamic business environment, physical products of themselves no longer provide sufficient competitive advantage [4,6,7].

Increasingly, manufacturers have struggled to transition from making products to co-creating solutions and services with customers [8,9]. They have been additionally challenged to modify existing product development frameworks to address incorporating services’ needs [5]. The software development industry has predominantly transitioned from using tradition project management practices to agile project management as a more effective means to develop new products and services [10,11]. This paper proposes the adaptation of an agile Scrum approach for new product and service development models for manufacturers engaged in IBSs. It provides a conceptual approach organisations can practically apply in order to achieve IBS objectives.

2. Literature Review

The literature review undertaken in this study systematically identified the challenges facing firms developing IBSs. It highlighted one of the key problems—that customers and suppliers possess largely different views on how IBSs work, a primary contributor to the lack of success in IBS development. The literature has also provided insights and explanation into the cause of poor outcomes due to the way project management has been utilized in such development. The most common approach has been the application of traditional project management with its highly planned, inflexible and detached customer involvement approach. This is the antithesis to the requirements for effective IBS development: close multi-stakeholder interaction, dynamic flexible planning and combined with iterative learning. As a result, the literature points to an alternative approach applying agile project management, which is customer centred, incremental and iterative.

Researchers have identified a number of challenges manufacturing firms must address to successfully execute an IBS strategy. Extant literature contributions from four research streams (general management, marketing, operations and service management), and within this identified five broader themes (service offerings; strategy and structure; motivations and performance; resources and capabilities; service development, sales and delivery) have been summarised by [5]. However, no previous research has tackled the mode of delivery to a significant extent, which is a substantial gap in the primary cause of failure.

The literature recognises the need for firms to develop new organisational structures, processes, capabilities and mindsets to successfully transition from simply product-focused manufacturing to product- and business solution-focused organizations [1,12,13,14]. Drawing on in-depth interviews with both customer and supplier firms, Ref. [15] found that customers and suppliers view solutions differently. Suppliers tend to have a product-centric view of solutions, whereas customers have a relational perspective [15]. Ref. [16] analytically define these respective roles and conceptualise that supplier/customer value co-creation occurs in joint value creation spheres. They argue that service providers (supplier firms) must fundamentally find ways to access the customers’ value sphere.

While much of this discussion is conceptual, researchers are challenged to empirically observe actor engagement in the value co-creation process [16]. Refs. [12,17] conducted some of the first empirical studies to examine the dynamics of engagement among multiple actors in the value co-creation sphere. Their work highlighted the importance of taking a dynamic, iterative, multi-stakeholder perspective when examining value co-creation processes.

Despite the significant academic interest, there remains scarce guidance or frameworks to understand how, when or if firms should invest in IBSs [9,13,18]. Ref. [9] suggest that the literature has focused on the success stories of manufacturers transitioning to services but note that often manufacturers overstretch the service capabilities, while others abandon the services transition initiative altogether. Ref. [14] identify five challenges firms must address when attempting a service growth strategy. These are organisational structure, business model, development process, customer management and risk management. Ref. [13] find that firms can significantly improve return on sales performance with IBS initiatives in industries where there is higher buyer power, but the effect is weaker in technology-intensive industries.

Creating an IBS is a project in itself and requires a mindset that integrally seeks to involve the customers’ views and participation in the development. Firms facing such challenges best solve the problems they are trying to overcome through an iterative process that involves close customer collaboration [6]. Utilising traditional Project Management has not proved to be counterproductive due to its tendency to develop rigid plans and inherent inflexibility to adapt to rapid market or customer environment change [6].

The software development industry has provided a clue. The dynamic nature of the software industry has forced provider firms to become more adaptable and agile in regard to designing solutions for evolving customer needs, similar to the requirements of IBS. Since the early 1990s, the software development industry has created a number of agile project management methodologies, all based on close customer collaboration, and frequent engagement, with rapid product iterations and constant feedback [6,7,12,19,20,21].

Among the most commonly used agile project management methodologies is known as Scrum [22]. With Scrum, autonomous cross-functional teams from the provider firm work closely with the customer (or a team member who acts as the customer representative). In short, predetermined timeframes called Sprints enable teams to work incrementally to produce output that has been prioritized by the customer as having the highest value.

3. Methodology

This research combined the expertise of the authors in both the development of IBSs and project management, traditional and agile. Through an understanding of the extant literature on the topic and their many decades of experience, they synthesized the matching of the right project management method to IBS development. It is through this professional experience, with its deep knowledge and understanding of the disciplinary practice context, that they have been able to merge the literature findings in this study to achieve the conceptual model outlined in this paper.

This paper presents a conceptual model of how an IBS provider can adapt the agile project management methodology, Scrum, to co-create an innovative IBS with their customers. The method adopted for this research was a qualitative literature review on IBS to understand the interest of manufacturers towards this business approach, coupled with the various challenges in such ventures. It reflects on the theoretical framework of traditional project management, based on planning, to exemplify why it has not performed sufficiently due to a lack of alignment of IBS contextual needs. The research proposes an alternative framework in the application of agile project management that appears to overcome the typical problems encountered in traditional project management. Figure 1 shows a conceptual model using agile Scrum for manufacturing firms in developing innovative IBS solutions.

The research clearly recognizes the multi-variate challenges in IBS development. Every IBS is unique, and often complex in its numerous multi-stakeholder interactions. A conceptual model for IBS development is proposed in this research.

4. Integrated Business Solutions Defined

Various definitions for integrated business solutions have been used based in context. Ref. [1] described IBS projects as ‘projects (that) extend the traditional lifecycle to include pre-bid and post implementation activities requiring innovative approaches to creating value for customers and suppliers’ (p. 361). Ref. [24] argue that solutions are ‘individualized offers for complex customer problems that are interactively designed and whose components offer an integrative added value by combining products and, or, services so that the value is more than the sum of the components’ (p. 657).

Ref. [12] placed emphasis on the strategic importance of the customer, the firm and the problem to be solved for both parties. He defines integrated solutions as ‘longitudinal relational processes, during which a solution provider integrates goods, service and knowledge components into unique combinations that solve strategically important customer specific problems and is compensated on the basis of the customer’s value-in-use’ (p. 699).

Other researchers take the business model and process perspective and emphasize the importance of longitudinal customer relationship processes in developing integrated solutions [15,21]. From this perspective, the strategic importance of the client to the firm is of the highest relevance, and efforts to develop unique services and solutions should be focused on matching their needs.

Both the provider firm and client company have a motivation to invest in developing solutions. Increasing technological and regulatory complexity, cost pressures, risk management and competitive differentiation opportunities are some of the antecedents driving customer demand for solutions [25,26]. For the IBS providers, increasing the commoditization of their core product business forces them to look for opportunities to move further down the value chain to combat price erosion, or offset seasonal variations in sales cycles [27].

The literature on IBSs refers to business models for capital goods manufacturers based on the provision of a tailored combination of products and services [1,28]. The literature recognizes the need for firms to develop or acquire new organizational structures, processes, capabilities and mindsets to successfully transition from being solely a product-focused manufacturer to a product- and business solution-focused organization [1]. Brady et al. also recommended that integrated solution provider firms continually learn, change and renew their structures while at the same time deliver the solutions their customers expect. For many large established product manufacturing companies, the ability to continuously adapt and renew their organizational structures is challenging. These businesses have to balance the need for developing customer business solutions with the need to maintain the existing product customer base [7]. It is proposed that instead of continually changing and renewing a firm’s organizational structure, as recommended by [1], a non-hierarchical team-based approach could be used—a cross-functional team.

5. Delivery Options

5.1. Traditional Project Management Methodologies

Ref. [29] compared traditional project management processes as to a relay race, with one group of functional specialists passing on the baton to another team of experts. The project goes from phase to phase through concept development, product testing, development and pilot phase on to final production. Each specialized function is segmented and carries the baton at different stages of the race.

While project management (PM) has become a permanent feature in strategic planning and most organisations, it has been observed that a significant number, particularly obvious in the public sector, exceed their budgets and/or fall short on deadlines and thus, fail in achieving agreed objectives [30]. Some researchers suggest that project failure can be attributed to unrealistic milestones and timelines that place an undue focus on the delivery of tasks, which in turn forces project members to compromise on quality and output leading to the failure of overall objectives [31,32].

Refs. [30,33] identified several key common factors whose presence can support project completion within the framework of time, quality and resource usage: upper management support, project team competence, interdepartmental cooperation and clarity in goals and objectives of the project. These are also critical factors for effective enterprise resource planning implementation, and indeed IBSs, the absence of which would likely lead to project failure.

Effective project delivery relies on the competence of workers as well as the project managers, hence making human resources central to the success of PM. This requires continuous and congruous involvement and commitment from all team members associated with a project [34]. The project team clearly need to be aware of the project goals, timelines and other constraints to be able to contribute effectively to success. This makes a close relationship essential between the workers and the project manager almost on a daily basis [35]. Ref. [36] further qualified that team members need to understand and commit themselves to the project as a team and not simply as skilled individuals.

An empirical survey conducted by [37] revealed that projects are successful when team members are committed to their roles. It was also observed that when the team members are trained before the commencement of a project, they can handle adverse situations that arise during the implementation of the project much more effectively [37,38]. Furthermore, it has been observed that the creativity levels of team members can increase as a result of the ‘dynamic interplay between the individual and team’ [39] (p. 280). This is enhanced when unambiguous knowledge is shared among the team. Indeed, Ref. [40] suggests that team members should be provided with training before a project commences to fill gaps in competence and ensure all team members are familiar with the technical and non-technical characteristics of the project.

As alluded to earlier, despite advances in understanding PM processes, tools and systems, project success has not significantly improved in recent decades [41,42] suggested that even in spite of the popularity of critical success factor studies in the project management literature, few organizations or managers use these findings to improve managerial processes. Ref. [43] noted that projects have been studied as ’entities detached from their environments for a long time’ (p. 4).

In the private sector, project planning and control are a challenge for companies engaged in developing new products and or technologies [6]. Rigid project management planning and oversight processes are not compatible with increasingly dynamic business environments, and the authors suggest that establishing a more flexible approach to product/technology development similar to that used in the software development industry may be the solution to this challenge [44]. These flexible approaches to project management are collectively known as agile project management methodologies.

5.2. Agile Project Management Methodologies

Origins of agile project management (Agile PM) are disparate with many different perspectives contributing to the literature. The recent literature cites the application of agile in the software development industry of the early 1990s, while some authors view its genesis as arising out of complex adaptive theories [45].

Agile PM is an extension of the agile software development movement. While the origins of contemporary agile PM can be traced to ideas promulgated by [29], it was not until the 1995 OOPSLA conference that Sutherland and Schwaber discussed the first agile method for software development, which adopted what is now referred to as the Agile Manifesto [46]. Four of its core principles are as follows:

1.

Individuals and interactions over processes and tools.

2.

Working software over comprehensive documentation.

3.

Customer collaboration over contract negotiation.

4.

Responding to change over following a plan.

Agile PM is deeply rooted in these principles and contradicts many aspects of traditional project management. This can be seen in some of the features of the agile PM approach which concentrates on short iterations with defined deliverables, and flexibility in incorporating change. Direct communication with associates in the development process is stressed instead of generating extensive project documentation. These two concepts are emphasized as they both help a project team adapt rapidly to the changeable and varying requirements faced by most development projects [47].

There are now many different applications of agile PM methods, with some of the most popular methods being Scrum, Extreme PM, Adaptive PM and Dynamic PM Methods [46]. Within the agile PM techniques, a Scrum is an agile process for managing and controlling iterative, incremental activities that are grounded in a team-based approach. The Scrum method due to its adaptive nature has become popular in managing a diversity of projects, systems and organizations in today’s fast moving and fluid business environment [46,47].

5.3. Scrum Project Management Methodology

Scrum is an agile project management process that was specifically developed within the software industry [48]. By the late 1980s, software development teams realized that they were using project management techniques that had not evolved to deal with the increasingly dynamic environment in which software companies were operating [49]. To remain competitive and relevant in the software environment, both Sutherland and Schwaber realized they needed to change the process of how software was developed. An article published in the Harvard Business Review provided guidance for them. The article, entitled ‘The new product development game’ [29], described how leading companies in the United States and Japan were innovating and developing a fast and flexible process for new product development. They described a product development process that involved the constant interaction of hand-picked multi-disciplined team members working from start to finish on a project and performing many different iterations as new information developed. The team functioned similarly to a rugby team that works as a unit, passing the ball back and forth as it moves up the field. Hence, Sutherland and Schwaber called this new process Scrum.

Schwaber described the Scrum team as a self-organizing, autonomous team with three distinct operational roles: the Scrum master, product owner and developer. The Scrum master and product owner roles were usually held by an individual team member (not the same person), the remaining team members being developers. The Scrum master is the facilitator of the Scrum process and acts as a servant-leader to the team, but team members are not directly accountable for nor do they report to the Scrum master. In addition to facilitation, the Scrum master also protects the team from outside disruptions or distractions during the sprint cycle (a fixed time-box period in which the team members complete allocated tasks). The product owner brings the customer perspective into the team and prioritizes the team’s tasks based on the highest value to the end customer. In some cases, advanced Scrum teams may include the client to act as the product owner to guide the team to prioritize the highest value work in progress. The developers are the team members charged with producing the output of the work. With the exception of the product owner’s direction on customer value priority, they have the autonomy to determine how best to achieve the desired result.

As summarized by [47], Scrum’s major principles can be readily articulated as follows:

•

‘Work is organized in short cycles.

•

Management does not interrupt the team during a work cycle.

•

The team reports to the customer, not the manager.

•

The team estimates how much time work will take.

•

The team decides how much work it can do in an iteration.

•

The team measures its own performance.

•

Work goals are defined before each cycle starts.

•

Work goals are defined through user stories.

•

Impediments to getting the work done are systematically removed’ (p. 6).

Borrowing from concepts of lean manufacturing and continuous process improvement, Scrum teams develop products, features and services in an iterative method that incorporates frequent feedback and review. This approach serves to ensure that what the team members have learned is applied quickly; customer feedback is constant, and the team can pivot if the client requirements change. With a focus on a small team (5 to 9 members), intra-team communication is minimized, and output from the team increases. Each Scrum sprint cycle contains two review processes, the Stakeholder Review and the Retrospective, with the former focused on external stakeholders, ensuring output is aligned to customer objectives and the latter review process focuses on the internal Scrum team functioning, communication and process improvement.

6. Findings

The typical nature of IBSs requires a delivery system that is flexible in operating, accommodates change requirements throughout its development, embraces close customer interaction and engagement, recognizes the need for an emergent exploratory understanding of scope through iterations and works on projects that are not typically large (commonly less than AUD 20 million). These characteristics match with the processes of agile Scrum.

6.1. Findings That Led to the Concept Model

Ref. [7] studied the efforts of two manufacturing companies in developing IBSs with their customers. They stated that many of the problems stemmed from the fact that the manufacturing companies made two major mistakes: (1) assuming their customers all followed a common industry-specific business model, and (2) that the product development professionals in their organizations overlooked the fact that the practically driven technicians in the customers’ organization were a possible source of innovation. They stated that for a manufacturer to produce solutions that address customer needs, they must understand their customers’ processes and evaluate offerings and competitiveness from the perspective of the client. Ref. [7] concluded their study, stating that ’a well-functioning collaborative relationship including defined roles and responsibilities clearly is a prerequisite for an integrated solution provider’ (p. 551). It is proposed that Scrum could be used as a conceptual framework to build well-functioning collaborative relationships with the defined roles and responsibilities as referred to by [7]. Ref. [50] researching the applicability of Scrum in product-service systems, focused on four agile elements (application, management, technical and personnel). They found that it had beneficial applicability in overcoming some of the key challenges in the development of product-service systems.

The authors also specifically engaged in an industry study where a Scrum framework was used to overcome the historic problems experienced with traditional forms of project management. The businesses were involved in developing medical device products for hospitals and other medical institutions. The authors found that the agile project management approach was substantially more effective in synergising customer co-creation. Its exploratory, iterative and evolving approach helped contributing organisations to better understand and create customer needs.

6.2. Why a Scrum Framework

Scrum is a heuristic framework for achieving short-term endeavours. It is fundamentally a flexible but structured team-driven approach to completing work found to be directly applicable for use in IBS development, enabling the creation of business solutions to challenging customer problems. It has a number of principal characteristics, which include operationally working as self-managing teams that organize ‘short iterations of work with clearly defined deliverables’ and focus on ‘communication over documentation’ [51] (p. 10).

Scrum teams are set up with three specific roles: product owner, Scrum master and a cross-functional development team. Product owners are the lead persons in terms of understanding both the businesses and customer needs and market requirements. They are responsible for giving clear guidance on which features are prioritised. Their role is primarily focused on driving the product or service understanding so it achieves its vision, balancing any changes that need to occur in the process. In this proposed conceptual model, the role of the product owner would be filled by a senior manager member from the customer’s firm. They would directly interact with the provider firm’s IBS Scrum team. These individuals represent the stakeholders’ interests and are ultimately responsible for the product’s co-created value.

The Scrum master performs the role of team and product owner coach, seeking to optimize the whole team performance. They are also responsible for the governance of the Scrum process. They facilitate and schedule team resources for sprint activities. A sprint is an agreed set of activities worked on by the team over a short period, typically, 2 to 4 weeks.

The Scrum team in IBSs, being the manufacturer (provider), conducts the actual product or service development work. They commonly comprise 8 to 12 individuals with expert skills and the capacity to deliver the project. They identify possible concerns, problems, risks or delays early in sprint planning meetings so that they can be resolved quickly and do not hinder progress. They cultivate a ‘we together’ attitude, all helping one another to ensure a successful sprint completion.

The Scrum process itself has several different artifacts (tools) to guide the delivery of project goals. The first, known as a product (or service) backlog, involves developing a list of all the key work that needs to be carried out in a prioritised order. It is then further broken down into sprint cycles, commencing with those activities of the IBS that yield the highest return on investment. This artifact is maintained by the product owner and includes the main features and product or service requirements. It is regularly reviewed, and re-prioritised from time to time, by the product owner. The level of detail in planning an IBS in this phase would be significantly less than that of a similar type of IBS using a traditional project management approach.

Sprint planning is a process led by the Scrum master where the team meet and decide, with the agreement of the product owner, the sprint goals and timing. Team members then collaborate frequently over the period of the sprint. They usually hold daily stand-up meetings, typically, 15 min in duration. This enables all team members to align on activities and voice any concerns that need to be resolved. They usually briefly discuss what has been carried out, what needs to be carried out on the day, what is planned the next day and any bottlenecks.

A sprint retrospective is held at the end of the sprint period and discusses and documents the elements that worked and/or challenged the project, people, relationships, tools or the specific work activities themselves. The aim is to learn from each sprint and feed that learning back into the next sprint to improve the process and outcomes.

In an IBS setting, the Scrum concludes when the team has developed new value sources for both the provider (the manufacturer) and the customer.

7. Challenges with the Model

The strengths of the Scum IBS model in being a better fit for purpose over traditional project management were outlined. However, as with all systems and models, there are inherent weaknesses and challenges. Scrum has shown itself to work well in the right context, that is, where it is resourced appropriately by trained operators, an organizational culture that understands its use, it has executive buy-in and most importantly a supportive and engaged customer. The system and model could readily fail if such parameters are absent.

The challenge in applying the model, therefore, is to recognize the culture and context in which such a model will work successfully. It is a matter of ensuring that such organisational structures are in place to support its application. This is particularly the case where there has been a long history in the organisations of using traditional project management practices. If this is not carried out, it will likely lead to the IBS development being unsuccessful.

Limitations of the Research

This research is limited to a theoretical approach that needs to be applied and validated in practice. Although IBS delivery with customer satisfaction is a key point, the research did not focus on the time, cost and scalability of the successful development of the IBS, nor did it consider return on investment analysis for either the IBS customer or manufacturer.

8. Conclusions and Implications for Manufacturers

Developing an IBS is difficult for a manufacturer and requires a different set of management skills. A product-centred company has its value chain structured on research and develop, design, produce, market, deliver and support products. Designing, developing, delivering and supporting an IBS requires the manufacturer to develop a separate value chain, one that supports a more flexible approach to creating new revenue sources and that invariably involves close collaboration with their customers at every stage of development.

Scrum PM has been successful in the software industry in developing new products/services and lends itself to adaption to the IBS with its customer focus, frequent iterations and accommodation of changing requirements. A result of this can be a customizable product/service developed through the collaboration between the customer and providing firm. A manufacturer adapting Scrum methodology to create an IBS may well be able to create a competitive advantage deploying such an untraditional approach.

The application of Scrum to IBS development is novel. This research will contribute to the current body of literature in both theory and practice. The paper not only stresses the importance of how IBSs are developed through a customer-centred and iterative mindset; it provides a conceptual model, using Scrum, that could be applied, validated and streamlined in industry to support IBS development in the future.