BUILDING A FOUNDATION FOR
AMBIDEXTERITY
Balancing Innovation and Consolidation
at a Software Development Firm
Graduation Thesis by:
Nicolaas Willem Mantel
S1937146
August 2012
University of Groningen / Faculty of Economics and Business
MSc Business Development
2
BUILDING A FOUNDATION FOR
AMBIDEXTERITY
Balancing Innovation and Consolidation
At A Software Development Firm
Student: N.W. Mantel Student ID: 1937146 Frieslandstraat 181 1082 TH Amsterdam Telephone: +31(0)6 44237875 Email: nathanmantel@gmail.com University of Groningen
Faculty of Economics and Business Nettelbosje 2
9747 AE Groningen
Degree programme: MSc Business Development Supervisors: M.W. Hillen and K.R.E. Huizing Client Organization:
The company name is called Company X because of confidentially reasons
Abstract:
This research determines the root causes why ambidexterity can contribute in being efficient in today’s activities and at the same time able to cope with tomorrows changing demands. This is done by
carrying out a research at a small software development firm. Where most research in focused on becoming more adaptable, we seek for determining the most satisfying way to implement more alignment by incorporating different software development and portfolio methods and to design a split in an adaptive sub-unit and an alignment sub-unit.
3
Table of Content
Chapter 1: Introduction...5
Chapter 2: The Environment...6
§ 2.1 Software Industry...6
§ 2.2 (Digital) Music Industry...6
§ 2.3 Company X ...7
§ 2.4 The Business Problem...8
§ 2.4.1 Research Question(s) ...10
Chapter 3: Methodology...11
§ 3.1 Research Method...11
§ 3.2 Research Approach...13
§ 3.3 Project Approach...13
Chapter 4: Theoretical Framework...14
§ 4.1 Ambidexterity ...14
§ 4.2 Structural and Contextual Ambidexterity...15
§ 4.3 Ambidexterity in Software Development...16
§ 4.3.1 Software Development Methods...17
§ 4.4 Ambidexterity- A Reflection on COMPANY X...18
§ 4.5 Portfolio Management...20
§ 4.6 Portfolio Management- A Reflection on COMPANY X...21
§ 4.7 Reflection to Other IT companies...22
Chapter 5: Solution Design...22
§ 5.1 Organizational Ambidexterity...22
4
§ 5.2.1 New Product Development Strategic buckets...25
§ 5.3 Portfolio management – “The Risk Matrix”………...26
§ 5.4 Prioritizing Projects and Most Critical Practices...26
§ 5.5 Expressing the strategy………...27
Chapter 6: Conclusions and Recommendations...27
Chapter 7: Discussion, Reflection and Limitations...28
Literature References...30
Appendix 1: Growth Model of Greiner ...36
Appendix 2: Management Team Members Company X, Organogram...37
Appendix 3: Impediments Noted From Meetings...38
Appendix 4: Example of MT Meeting Minutes...38
Appendix 5: Brainstorm Session “Fishbone Diagram” ...39
Appendix 6: Field Research...41
Appendix 7: Stages of (Traditional) Software Development Conde...43
Appendix 8: Importance of Portfolio management by Discipline...44
Appendix 9: Business Strategy Method as Best Performer...44
Appendix 10: Strategic Buckets for COMPANY X...45
Appendix 11: Risk Matrix...46
Appendix 12: Comparison Table Agile and Traditional Development Methods...48
Appendix 13: Objectives, Goals, Strategies, Measures and Tactics………..49
5
Chapter 1: Introduction
Growing a company from the ground up usually passes through similar stages such as those
determined by the classical Harvard study of Greiner (1972)(Appendix 1). A business starts based on creativity and an idea. The company is flexible and adapts to the customers wishes easily. This first phase ends with a leadership crisis. Professional management and delegation is needed. Growth continues in an environment of more formal communications, budgets and focusing on separate activities such as marketing and operations. The starting phases are typical in the way that an organization moves from mainly explorative orientation to involving more exploitative functions (Tushman, O’Reilly, 1996). One could say that an organization, or even a start-up, is directly involved in balancing these two opposing factors and to become ambidextrous; to be efficient in today’s
business and to be able to cope with market changes of tomorrow (Duncan , 1976). To be
ambidextrous organizations need to extensively consider and communicate their future vision and strategy (He and wong, 2004). However, younger organizations also challenge forming a base and infrastructure to actually create and develop future products and services successfully. More authors are studying the different concepts of organizational ambidexterity (Gibson and Birkinshaw, 2004; Smith and Tushman, 2004) , how to apply this (Cooper, 2001; Chao 2008) and what organizational strucuture is needed for this(Gibson and Birkinshaw 2004).
6 Chapter 2: The Environment
In order to create a better understanding of the situation and the causes of this research, I will introduce the environment where in this study was conducted.
§ 2.1 The Software Development Industry
Software can be developed for a variety of purposes: to meet specific client needs, to meet personal needs, or most commonly, to meet the needs of a perceived set of potential users. The software industry is a lucrative market. In 2010, the global software market reached a Global value of 265.4 billion and is forecasted to grow over 30% in by 2014 (Marketline Software Global Industry Guide, 2011).
The software industry is known for its unprecedented rate of change, since customer requirements constantly change and furthermore, there are continuous upgrades in internet platforms, software systems, and computer technology (Lee & Xia, 2010). However, reports in business journals have known that software innovation has a low success rate; close to a dismal four percent (Business week, 2005; Napier ,2011). Nevertheless, this constant change and the need for success improvement makes the software industry a very valuable market to study due to its many innovation in research and new developments (Nambisan, 2002; Bala., Hyon & Venkatraman, 2006., Jigeesh & Kandabolu, 2011). The reasons for the poor development is the use of current methods and the ad-hoc work environment, discussed in more detail later (Cockburn, 2002). From this, one could say that the exploitative
activities of the software industry are poorly organized (Napier, 2011). Regardless of poor organization of the software industry, more and more businesses need improved information technology and that is why the software market keeps growing and new markets are upcoming (Marketline, 2011). One of these upcoming industries involved in digitalizing products and information is the music industry.
§ 2.2 (Digital) Music Industry
In 2002, the physical distribution of music CD's was at its peak (Recording Industry Association of America, RIAA, 2010) and 95.5% of the music sold was through an actual disk. The last decade, hardcopy music sales have collapsed to nearly 50%. This is a result of the immense impact of internet piracy, which are causing the business models of the music industry to change quickly towards an online technology, where profits can be made through innovation.
The digital music industry is at a highly dynamic, disruptive and unstable stage. Music industry critics call the music business “terminally ill” (Kusek, 2005; RIAA 2010). From the consumer’s perspective, there are hundreds of digital services providing dozens of business models and fighting towards a
7 dominant design. Such examples are Apple iTunes, Spotify, Amazon MP3, and Google Music. From the label, also known as the content owner’s perspective, people are struggling to distribute all the digital music towards these Digital Service Providers (DSP’s). The primarily problem here is the distribution; all DSP's have different digital requirements for incoming content. This creates an enormous hassle in delivering the digital content from the labels to the various DSP’s. Many
employees assigned the simple task of adjusting the music data to each DSP’s delivery criteria. Due to these stipulations, the independent music industry, which is all music outside the major record
companies (e.g. Universal), is suffering from this problem. However, solutions to this problem started to rise up about half a decade ago. Some technology companies with a strong music industry
association created platforms that automate delivery of digital content from one source to multiple destinations, solving or minimizing the DSP’s delivery criteria problem.
Nevertheless, putting a CD in a rack and wait for the customer to come and get it is one thing, but putting a track on a web page and wait for a customer to come and download it is quite another. This is one of the reasons that distribution aggregators arose and offered labels to help them not only
distribute, but also market and promote their music online. This technology is the foundation of what has to become the ultimate portal for digital music, and eventually all media content. A place where content, marketing, sponsorships and sales of associated products and services come together. Having the distribution from music creators towards music consumers in place is one part of organizing this chaotic digital stream. Music royalties rights organizations, such as Buma/Stemra, need databases in order to transfer royalties back to the creators and performers of the content. This is another reason why the industry needs a platform where all music, (meta) data and royalties come together. One of the players in creating this digital platform is Company X.
§ 2.3 Introducing Company X
Company X is a Netherland based software development company within the music and
entertainment industry. As of 2012, COMPANY X currently employs 19 people working on software development, finance, marketing and customer sales all over the world (Appendix 2). Besides in the Netherlands, COMPANY X has two full-time employees in America and France who work with different outsourcing companies in India and Turkey. Recently they created an Internet platform which simplifies distributing and managing digital music. This Internet platform allows worldwide record labels, artist and aggregators to manage their content between different online shops or Digital Service Providers (DSP’s). This platform offers services like digital delivery, content and rights management. COMPANY X’s mission is to become the portal of all digital music and to ensure that the artist receives maximum pay for his/her creations.
The work environment of COMPANY X enables lots of freedom for its employees. The Firm allows all its employees to fully participate in the developing of new ideas and allows lots of flexibility in
8 their employees work. This “start-up” style environment creates a kind of family relationship amongst employees who become proud of what they achieve together. The mix of people working together could not be more diverse; ten different origins and lots of different backgrounds when it comes to studies and previous jobs. There are plenty of opportunities to discuss anything in an informal manner by having open workplaces, shared lunches, and Ping-Pong tables. In return for a “start up” style work environment, management expects and trusts employees to take on responsibilities and to perform accordingly.
The CEO of COMPANY X is a true visionary and serial entrepreneur who always brings in new ideas and opportunities. The Project Manager takes on the challenge of translating these external ideas and puts these into practice at the different disciplines internally. Company X wants to move fast and respond quickly to market requirements. There are lots of opportunities that are taken on and many new features and applications are added to the organizations core platform in order to answer to customers need.
Throughout the years, COMPANY X has been going through multiple reorganizations. Now it is the time to move from a “start-up” style to a more mature organization.
§ 2.4 The Business Problem at Company X
The assignment for this research at COMPANY X began to bring more structure in the development process and to build a new product development model. It is the purpose of this research to determine how I can contribute in solving the initial problem which spurred this research. In reaction to the issues of COMPANY X, I intend to find the root causes and provide a solution. In order to determine these root causes I conducted exploratory research.
Because the music industry is currently in a turbulent evolving state, lots of new ideas and business opportunities are coming into the market. COMPANY X is eager to keep up with market changes and wants to react fast and accurately. In a conversation with the CEO of COMPANY X,he says; “I have to lots of expectations from investors and I need to show that I am listening to their wishes”. Most resources are spend on working software and results, while COMPANY X is starting to recognize that they have not built a solid foundation to build on, a company which can quickly develop new ideas and innovate. The Project Manager believes, “Because of our need to answer the market we lacked in consolidating our current business. We can see this by the amount of ad-hoc work constantly blocking structural work”
I could say that the ability to innovate at COMPANY X is low, since there is no foundation to build on, yet. Many so called impediments block the way to a structured solution to the problems the developers run in too.
9
“Procedures still not being followed/retroactively applied”
“Support procedure is not clear”
“There is no clear testing process, test docs are incomplete”
“Issues and tasks need clearer user cases (descriptions) before developers take action”
“Unclear patching process is causing communication breakdown in deployment”
As seen in the above quotes, time and resource goals are not being met and structural development work is postponed continuously. Interviewees pointed out that the development process contains lots of workarounds that fixes a particular issue, but withholds employees to work on actual long-term solutions and a critical development infrastructure.
In order to dig deeper into these issues and to continue my research on these issues, I organized a brainstorm meeting where we could find out more about the causes. This meeting was organized around filling in a “fishbone diagram” (Ishikawa 1968). A “fishbone diagram” works with a central problem, since the research at COMPANY X was still at an exploratory state I chose to keep this problem rather broad. So the central problem in this fishbone diagram was; “ The low ability to innovate at COMPANY X” (Appendix 5).
We choose to discuss four general subjects including manpower, management, method and measurement. From this diagram, myself and COMPANY X could see that lots of issues of low innovation related to each other. For example, at the manpower section there is being said that employees are not disciplined to follow the tasks they are expected to do, because people are
interrupted with ad-hoc jobs. Continuing the why question on this topic provided answers such as, “If customers are reporting issues, bells start ringing and we want to fix things right away, although this keeps us from the work we are supposed to be doing”, and “There is no process in order to handle issues which are sometimes occurring daily, it seems we need an awareness and shared vision for us to prioritize what is important and take responsibility for it”.
COMPANY X’s project manager used a metaphor with this specific situation; “It is like a bike with a loose chain constantly falling off. You can fix it by simply putting it back on, having a big chance that it falls off again, or you remove one clasp and make sure the chain will hold longer”
The implementing of formal processes and procedures are often mentioned. Nevertheless , the CEO also says, “Together with setting these standards we need to be highly flexible towards market changes [and] we cannot focus solely on consolidating and close our eyes for our customers
demand”. This shows that COMPANY X is struggling with building up a structure where flexibility is possible to a big extent.
It appears that COMPANY X does not prioritize or group innovative (externally focused) and
10 Although this mixture in itself is not a problem, at COMPANY X I see that this creates confusion amongst management and employees. A reason for this I believe, could certainly be the fact that the current allocation of resources is not clear enough and is not shared company wide. COMPANY X primarily focuses on innovation, and with that, failed to consolidate and align necessary issues like standard processes and procedures. The workarounds, impediments, and short term unstructured problem solving shows that COMPANY X has problems balancing innovation and consolidation which is a problem in managing ambidextrous organization; an organization who is able to be efficient in their current business and also adaptable for coping with tomorrows changing demands. Actually implementing solutions for solving these workarounds and high priority processes is in the scope of the Project Manager and not for this study. This thesis intends to focus on a firm-level where I determine how to manage multiple projects and innovation efforts across the organization. This brings me to ask the following overarching research question;
How can COMPANY X balance innovation and consolidation?
Both literature and practitioners agree that consolidating and innovating requires a different organizational structure, culture and different use of human resource. Changing the organizational structure logically results in different cultures (Boehm & Turner, 2004). Nevertheless, instead of choosing between these options, software organizations should become ambidextrous (Napier, 2011). The truly successful organizations foster an environment that encourages the parallel presence of contradictory forces, such as differentiation versus integration (Lawrence & Lorsch, 1967), stability and change, alignment and adaptability (Gibson & Birkinshaw, 2004), and variation-reducing versus variation-increasing (Burgelman, 1991). To bring these opposing factors together is a challenging assignment and brings us to the following sub question:
What organizational culture is needed for ambidexterity?
A part of being able to innovate is constantly introducing new products and services which correspond to customer and market requirements (Clark & Fujitmoto, 1991). Having a system in place that offers a methodology for new product development control can clearly make the innovation process more successful and effective (Cooper, 2001). Software development is entirely a design event and therefore makes (product) development the central discipline within a software company (Napier, Mathiassen and Robey, 2011). Software companies constantly face contradictory choices as they develop software for a market with fast changing customer requirements. They need to improve efficiency of the development process while at the same time adapting to customer needs (Napier, 2011). While there are currently methods focusing in either efficiency and structure, or flexibility and change, tailoring of methods is started to become commonplace in the vast majority of software development projects and
11 organizations (Fitzgerald, Hartnett and Conboy 2006). Realizing the importance of the development team we first focus on the software development structure needed at COMPANY X, and then move to a more company-wide view. The cause and effect tree shows that the firmis looking for several methods and procedures to be implemented in order for the company to build a development infrastructure on which further new products can be added. I need to determine what COMPANY X needs to create this development structure. Processes for risk management, educating employees and testing are a few requirements mentioned in the cause and effect brainstorm meeting. This research needs to determine how COMPANY X can best prioritize and group critical innovative and consolidative activities in a clear portfolio. I need to determine what are the most critical practices COMPANY X needs to create the development structure they ask for. Practices in this case means a bundle of processes, methods, procedures, activities.
What are the most critical practices needed for ambidexterity at COMPANY X?
After determining what organizational culture fits best with ambidextrous organizations and what practices are most important to achieve this, I intend to find out how COMPANY X can structure and organize these activities by asking the following sub question;
How can COMPANY X best apply and implicate ambidextrous practices?
Answering these questions will determine the building blocks towards the solution and makes three contributions; first, I determine why COMPANY X needs both innovative and consolidative capabilities. Second, I elaborate on the organizational challenges in successfully operating these opposing cultures. Third, I suggest an ambidextrous form of organization using portfolio management in controlling both approaches.
Chapter 3: Methodology § 3.1 Research Method
In this thesis I will on focus on solving a business problem with the affect of improving a business’ performance. In order to improve business performance an organization needs to change. The process of change is organized in phases, such as the five-phase model of Kepner and Tregoe (1981), but as practice has shown, following a rigid phase to phase model does not always work successfully (Van Aken 2007). Therefore I will use a more descriptive and design focused type of research (Witte 1972), which is intended to show that the problem-solving process is not organized in a clear sequence of distinct phases, but in process steps. Processes steps may include, involving iterations and explorations throughout the research. What is key here is the flexibility in scheduling work around various process steps of the problem solving (Figure 1, Van Aken 2007).
12 Internal investigation into a business that presents such problems is the result of a five month
internship, which created and will continue to result in a close relationship and strong dialogue with the client organization. I will continue to receive information on the status of the problems, and collect feedback on proposed solutions.
Figure 1: Design process, Van Aken 2007
I propose to thoroughly investigate into the business’ problem and to develop a well formed solution for improving the clients business.“Building a foundation for ambidexterity” is focused on business development (BD), which means I am focusing on at least two points of the BD triangle
(Product/Service, Market/Client, and the Organization). This document will mainly cover the service and the organization sides of the triangle.
Since I am dealing with an actual business problem, I use the regulative cycle, which is part of the reflective research cycle by Van Aken (2007)(Figure 2).
13
§ 3.2 Research Approach
One can use quantitative, qualitative, or a mixture of the two as the research approach in solving the business problem. Quantitative research techniques were not applicable at COMPANY X. Almost all knowledge is tacit and quantifying this knowledge in such a small company as COMPANY X (e.g. using SPSS) would not generate valid information. Therefore, this research is built around qualitative research approaches. I use interviews, personal observations and organize meetings in order to determine COMPANY X’s problem areas and critical practices to be developed. Similarly techniques are used to substantiate my findings as well as the use of literature to compare them with the current practices and causes of the problems at COMPANY X. In addition, conclusions and recommendation are discussed with three comparable software development companies, operating in different
industries. These software development companies are: Firm A: a mid-sized company developing software for mainly educational institutions: Firm B: a consultant firm mediating in creating software for a conference call platform. And, Firm C: A small firm developing software for energy and technology companies (Appendix 6).
§ 3.3 Project Approach
For the conceptual construction of the project, I build upon the ideas of the authors Verschuren and Doorewaard (1999). As you can see in figure 3, the upper two elements of the conceptual project design are the subject of analysis and the theoretical perspective applied in the analyses. These two make a good comparison possible of the situation within Company X with the theory. The analyses of these two elements will result in diagnosis, conclusions and finally, the deliverable of the project.
14 The theoretical fields covered in this thesis are required from the cause and effect tree, observations, informal interviews and preliminary academic literature studied. Academic and professional literature of the software industry is needed to illustrate valid information on norms and facts in this specific environment. COMPANY X is growing from a start-up company to a more professional organization and is at the point of formalizing and implementing business processes. To find the right balance in innovation and consolidation, literature on ambidextrous organizations is crucial in this phase. I analyze both general and industry specific ambidexterity literature. Since COMPANY X has problems in allocating recourses, I intend to find solutions for this topic within portfolio management literature. The Project Plan
1. A literary research regarding the topics mentioned in the left-hand side of the conceptual project design (figure 3)
2. Reflect upon literature based on COMPANY X
3. Conclude the diagnosis and discuss with COMPANY X Management Team and comparable companies.
4. Develop solutions and alternative directions for the solutions
5. Discuss main lines in solutions with all supervisors, MT of COMPANY X and comparable companies to decide on the redesign direction
6. Search for literature to support the redesign and forecast possible risks
7. Present solution and create support for the object design and realization design
Chapter 4: Theoretical Framework § 4.1 Ambidexterity
An ambidextrous organizational approach proves to be successful within dynamic environments (March, 1991; Tushman & O’Reilly, 1996; Gibson and Birkinshaw 2004). Ambidexterity, the ability to be efficient in current business and also adaptable for coping with tomorrows changing demands, is studied by a variety of authors. Adler, Goldoftas and Levine (1999) studied the contradictory choices of efficiency and flexibility and concluded that managers must optimize the efficiency of existing development processes while simultaneously adapting them to individual customer needs. Tushman & O’Reilly (1996) studied the paradox of evolutionary verses revolutionary change and concluded that in the short run you must constantly increase the alignment of strategy, structure and culture but in the long run managers must be able to destroy the very alignment that has made the organization successful. Other contradictions that are often studied is exploitation verses exploration (March, 1991). Managing these contradictions requires the balancing and constant adaptation of competencies, strategies, structures, cultures and leadership skills (Tushman & O’reilly, 1996).
15 Gibson and Birkinshaw (2004). Alignment and adaptability can best be compared to consolidating and innovating at COMPANY X. Furthermore, many software specific literature uses Gibson’s terms the most (Vinekar, 2006; Napier, 2011), which is why I am using this contradiction as the main academic term for the situation at our client company.
The culture characterizing ambidextrous organizations is simultaneously aligned and adaptive. Aligned because the firms needs to stimulate characteristics for innovation such as openness,
autonomy, initiative and risk taking (March, 1991). Adaptive because the degree of these norms varies across the type of innovation (Tushman, O’Reilly 1996). Cross-functional teams consistently share information and people trust each other in their competences allowing for a lot of autonomy. However, this autonomy is measured by a strong focus on performance, therefore responsibility and
accountability are characteristics that must fit with the job and employees within the
organization(Gibson and Birkinshaw, 2004). For example, in most ambidextrous organizations it does not matter how much hours one makes during the week, the focus is the persons work being done in the time spend. This tight-loose aspect of the work culture is key for ambidextrous organizations. An ambidextrous organization stimulates opportunities for informal conversations and accessibility to knowledge sources within organizational units (Jaworski and Kohli 1993; Jansen, 2006). This “connectedness” in social relations also proves to positively influence both exploratory and exploitative innovation. Hewlett-Packard is an example of ambidexterity. They created a sub-unit environment and allowed a group of people to discover the possibilities of a small niche market at that time. They mention that their printer business did not emerge because of strategic foresight and planning, but through “the entrepreneurial flair of a small group of managers who had the freedom to pursue what was believed to be a small market”(Tushman & O’Reilly, 1996 p.27).
After discussing ambidexterity in general I now discuss ways to apply this type of organizational behavior. Literature determines different methods on how to manage and apply ambidexterity within an organization.
§ 4.2 Structural and Contextual Ambidexterity
Author Duncan (1976) described structural ambidexterity as having dual- organizational structures where one business unit would focus on alignment and the other unit would focus on adaption. Also, firms can choose to create a spin off business for radical innovations and create ties with the main firm. Instead of separating radical and incremental innovation in space, such as mentioned above, organizations can also choose to separate in time where business can focus on radical innovation first and then let the same new product development team focus on incremental innovations later (Duncan, 1976). This structured way allows for a clear split between consolidative and innovative activities and also supplies insight on balancing the resources spend on each sub-unit
16 Gibson and Birkinshaw (2004) introduced contextual ambidexterity, which stimulates to
simultaneously apply alignment and adaptability within and across business units, instead of splitting up types of business units. When to use what method depends on the fit with the firm and many companies balance different methods using hybrid approaches. However, an important implication managers look for are practices that can apply to all methods, a foundation for ambidexterity. Gibson and Birkinshaw (2004) extensively studied the antecedents of ambidexterity and argue that a combination of stretch, discipline, support and trust facilitates both alignment and adaptability. This is achieved by building a set of processes or systems that enable and encourage people to make their own judgments about how to divide their time between alignment and adaptability. They also mention that all business units studied used a customized implementation strategy. Since I think that a combination of stretch, discipline, support and trust is too vague, I want to clarify what is the set of processes or systems that can set a standard for the current situation at COMPANY X.
In order to determine the most satisfying balance for COMPANY X and to find out what the best set of processes or system is, I need to look further in to industry specific literature writing on
ambidexterity. Here I am able to investigate in-to both structural ambidextrous practices and contextual practices both contributing to this research.
§ 4.3 Ambidexterity in Software Development
Software development is a complex activity characterized by tasks and requirements that are known for their high degree of variability (Boehm and Turner, 2004). Napier (2011) describes that software managers lack in optimizing the alignment of existing development processes while simultaneously adapting them to individual customer’s needs, and: “Managers must exploit the organization’s current capabilities in relation to existing customers while at the same time exploring new technology and market opportunities”(p.675).
This problem might provoke the effect that the software industry is continuously struggling with a low rate of success (Business week, 2005; Mathiassen & Vainio, 2007). In order to attain improvement for this low success rate, developers, project managers and academics are striving for better methods two develop software products (Vinekar, 2006). Since there is not simply one best way to manage these activities, managers face a diverse set of challenges in customizing currently used practices towards the firm’s own situation (Carmel & Becker, 1995). Customizing the development methods often involves contradictory choices between short-term profit and long-term business for the future (Tushman & O’Reilly, 1996). A growing number of academics in the field of software development agree that it is detrimental for firms to accept the paradoxes as separate organizational phenomenon’s and to choose either long-term or short-term innovation (Vinekar, 2006; Batra, 2010; Napier, 2011). Instead, firms should be ambidextrous.
17
§ 4.3.1 Software Development Methods
Within the software industry the contradictions of alignment verses adaptability often goes hand in hand with two differing methods of software development. Traditional and agile software
development methods (Table 1).
The traditional approach originates from the manufacturing and construction industry and is highly structured and formalized in practice (Appendix 7)(Benington ,1983). In this approach, the traditional method advocates to build specifiable and predictable systems that can be built through precise planning, life-cycle models and process-centric control.
The agile development method is originally conducted from the Toyota production system and claims to better manage the paradoxes of efficiency and flexibility than the traditional approach (Adler, 1999). The Agile Alliance (2001) took this approach and started to create development methods around the four essential values of agile development: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to changes over following a plan (Agile Manifesto, 2001). Agile developers advocate that more flexibility, faster delivery of a working product and tighter customer involvement can increase the customer response efficiency and extensiveness, and thereby project success.
Where agile development promotes constant iterations and explorations towards customers changing needs, traditional methods believe in an upfront plan-driven process where structure and certainty are key (Cockburn, 2001). Most software development firms already use both methods and need to constantly reconsider what projects needs more agility and what project needs more structure
(Vinekar, 2006). To find the right balance between the two development methods, companies largely adapt their choice of traditional or agile methods on five factors (Vinekar, 2006):
-The size of the project and team
-The consequences of failure (i.e criticality)
-The degree of dynamism or vitality of the environment -The competence of personnel
-Compatibility with the prevailing culture
An interesting tool to use for considering these factors is the Risk Matrix (Day, 2008). The risk matrix rates projects based on the newness to the market and newness to the company, and can help firms to get a good idea of how much risk is involved for each project. Except for the first factor, the risk matrix covers most of the five factors Vinekar mentions.
18 Table 1: Characteristics of agile and traditional software development, Vinekar (2006)
Boehm and Turner (2004) have determined that traditional development is mostly used when the conditions of the projects are large, criticality is high, requirements are predictable, the competence of the personnel fits and if the project is of strategic importance. Agile, on the other hand, is best suited in a highly uncertain environment, with small projects where lots multidisciplinary skills are requested. Batra et al (2010) writes: “Agile without structure can cause chaos, particularly in large complex distributed projects where planning, control, and coordination are critical. Structure without agility can lead to rigidity, particularly when a project involved a great deal of learning, discovery, and changes” (p.379). One could say that agile development fits more with an adaptive sub-unit and that traditional development methods would better fit the alignment sub-unit within a firm.
§ 4.4 Ambidexterity – A Reflection to COMPANY X
Now that we reviewed ambidexterity literature we take a closer look at how some of the key characteristics of ambidexterity are found within COMPANY X.
Ambidexterity at COMPANY X has never been mentioned in the way I described this in theory here. What I can conclude from our empirical analyses though, is that the current balance between
adaptation and alignment is a problem. The ambidexterity literature above says that firms should focus on alignment in the short run but must be able to destroy the same alignment in the long run (Tushman and O’reilly 1996) Although this would make perfect sense for mature organizations with plenty of aligned business, COMPANY X is much more adaptive and is now focusing on increasing alignment instead of adaptability, something what Tushman and O’reilly (1996) are aiming at. One could say that while mature organizations are looking for ways to create adaptability, COMPANY X is looking for
19 alignment. This is not surprising though, firms that are relatively young are known for their
dependence on innovation and adapting to customers, and often there is not really a base on which the company can rely on yet (Greiner, 1972 Although they realize that adaption is still highly important for the future of COMPANY X and that one could not make a trade-off between either adapting or aligning, at COMPANY X this base is starting to get formed and therefore alignment needs to take place to create a balance between the two.
Gibson and Birkinshaw (2004) mentioned earlier in this report that an ambidextrous organization must implement performance management in order to work according to a tight/loose coupled culture. Unfortunately, since COMPANY X did not report actual processes yet, there is almost no strict performance management. Because lots of tasks are ad-hoc and incidental, it is hard to introduce routine and to build measurement points. Employees and management team (MT) members are trusted in that they do the best they can. If promised work isn’t done there are no consequences and the performance is not measured. This also means that there is currently no threat in getting fired.
COMPANY X rewards their employees evenly, although it is mentioned that management is keen on coming up with shares in the company. Other than that, it is not yet possible to do so because
performance is not measured at this moment.
COMPANY X is a very flat organization and people can easily discuss anything. Some employees actively participate in improving ways of working and come up with bright ideas that maybe left unnoticed by the MT. The connectedness between some employees is sound and COMPANY X stimulates this and wants this to grow all over the firm. In addition, most customers are satisfied with the products and the contact with the company. Company X’s MT now expects and trusts employees to work according to the characteristics of the contextual ambidexterity method, unfortunately they did not structure the organization to really work that way. There are no split in teams focusing on
adaptability and teams focusing on alignment. Employees must realize that the work they do contributes to the promises made to the customers. This also means that all employees have regular contact with customers. The software development department works according to the agile development method discussed earlier. Daily and weekly meetings are planned to discuss and prioritize tasks within specific projects. However, the agile methods need to be balanced with the traditional methods in order to create a development structure where performance management is better applicable. This is not the case at COMPANY X yet.
20
Conclusion
COMPANY X’s development methods need more structure and reached a stage where processes need to be introduced (Greiner,1972). Literature showed that firms can create two sub-units in the
organizational structure to balance adaptability and alignment by creating separate groups for both activities. This can be done either with structural ambidexterity or contextual ambidexterity, but what is important for COMPANY X is that in both cases the firms makes a clear separation between an adaptive sub-unit and a aligning sub-unit. Gibson and Birkinshaw (2004) recognized this by the fact that successful business units where aligning themselves around adaptability, where there is a
separation between alignment and adaptability and the unit managers knows how much the two should intervene on the different projects. The separation of these two opposing approaches is something essentially missing at COMPANY X and should be implemented.
Agile development methods needs traditional influences and vice versa (Batra, 2010). COMPANY X should be aware to use a hybrid approach and to apply both agile and traditional methods.
Currently, the development method at COMPANY X needs more influences from traditional methods. Adding more traditional development could contribute in bringing more structure to certain problem areas and increase consolidative projects where market changes are not the number one priority.
§ 4.5 Portfolio Management
Portfolio management has been recognized as one of the most important senior management functions (Miller and Morris, 1999; Roussel et al., 1999).Cooper (2001) shows that managers in technology are evaluated as giving portfolio management the highest importance ratings of all disciplines with a score of 4.1 out of a point scale (Appendix 8).Cooper (2001 p. 364) described eight key reasons why
portfolio management is so important:
1. Financial – to maximize return: to maximize R&D productivity: to achieve financial goals. 2. To maintain the competitive position of the business – to increase sales and market share. 3. To properly and efficiently allocate scarce resources.
4. To forge the link between project selection and business strategy the portfolio is the expression of strategy: it must support the strategy.
5. To achieve focus – not doing too many projects for the limited resources available: and to resource the ‘great’ projects
6. To achieve balance – the right balance between long and short term projects, and high risk and low risk ones, consistent with the business goals
7. To better communicate priorities within the organization, both vertically and horizontally. 8. To provide better objectivity in project selection – to weed out bad projects
21 In Cooper’s (2001) study in portfolio management for product innovation he discusses various popular methods on how to apply portfolio management. Not surprisingly, financial methods such as Net Present Value and Return on Investment are the most popular tools to decide which project to prioritize and to continue. However, further results show that best performing companies tend to rely less on financial models and methods as the dominant portfolio tool than the average business does (Cooper, 2001). In addition, the best performing companies let their “business strategy method” allocate resources and decide for the set-up of product portfolio much more so that the worst companies do (Appendix 9). Reasons for this are mainly due to predictability of the project (Lin, 2003). Radical innovations and projects are rarely supported by financial tools and therefore do not support this type of innovation. Nevertheless, companies must balance radical and incremental innovation and thereby balance portfolio methods.
§ 4.6
Portfolio Management - A Reflection to COMPANY XLooking at the key reasons on why portfolio management is so important, I can see that expressing the strategy, allocating scarce resources, prioritizing projects, achieving balance and better communication are important factors that very much align with the problems stated at COMPANY X. Project and product portfolio at COMPANY X is currently managed by the CEO and the project manager. They are the ones that discuss what needs the highest priority and where to put in resources. Unfortunately, lots of deviations take place because of the ad-hoc tasks, workarounds and missing performance measures which shows that the use of portfolio misses some degree of formality and discipline. Current projects are chosen on the basis of ideas from the CEO and are checked by the project manager for feasibility. The decision on how to organize the portfolio is largely based on intuition rather than on an actual business strategy or financial method as presented by Cooper (2001). Besides, financial methods are not applicable either, since there is too much uncertainty on the business environment. Although COMPANY X should always use a hybrid approach towards the portfolio tools, it is now best to focus more on strategic methods for portfolio management.
Although portfolio management by Cooper is a rather traditional new product development tool, I believe that this is the degree of traditionalism and structure I mentioned earlier in the ambidexterity reflections. It is key that COMPANY X allows for many iteration and flexibility since there
22
§ 4.7 Reflection to Other IT Companies
After the literature research and the reflection to COMPANY X I contacted comparable IT companies, operating in different industries (Appendix 6). Since the Firmis a rather small company with one project manager, I noticed the need to talk to more project managers in similar situations. I contacted 26 IT- companies, three firms were willing to have a telephone conversation. I interviewed the project managers and all three companies recognized the situation at COMPANY X and noted that alignment was becoming more important during the growth of the firm. The main findings where that all companies had clearly divided an adaptive and alignment subunit, most of the time with a separate budget. In addition, at Firm A, a mid-sized company developing software for mainly educational institutions, the project managers where in charge of both sub-units but also responsible for combining the two when needed. Further results from these interviews are discussed in the solution design.
Chapter 5: Solution Design
§ 5.1 Organizational Ambidexterity
Earlier in this report I discussed the two general ways of applying ambidexterity to the organization, namely: structural and contextual ambidexterity (Gibson and Birkinshaw, 2004). Structural
ambidexterity is typically viewed as a dual-structure approach, where certain business units focus on alignment and others focus on adaption (Duncan, 1976). However, contextual ambidexterity literature, such as Gibson and Birkinshaw (2004) proclaims an increasing importance in the focus from trade-off (either/or) to paradoxical (both/and) thinking, where the focus is more on the role of processes and systems present in a given context in achieving the desired balance between these opposing demands. Nevertheless, most of this literature is focused on case studies within established companies. Most of these companies have processes and procedures in place and there are clear structures and practices. COMPANY X, however, doesn’t have these processes in place and is currently in a phase where the company is asking for more structure and alignment in order for the company to be able to
successfully develop adaptive projects. Discussing contextual ambidexterity would be too early for COMPANY X since they first need to define the two opposing sides.
In addition, comparable companies determined that all three companies applied a clear separation between adaption and alignment (Appendix 6). Also, Govindarajan (2008) and Anthony et al (2008) claim to install a dedicated team or to institutionalize innovation. Therefore I believe that structural ambidexterity can provide COMPANY X with the initial development infrastructure COMPANY X is asking for.
To answer the first sub question, which is: What organizational culture is needed for ambidexterity?, I intend to explain this in more detail below.
23 loosely coupled (O’Reilly & Tushman, 2004). One sub-unit for alignment and one sub-unit for
adaption (Figure 4).
Figure 4: Adapted model of Vinekar, 2006
Each sub-units follows their own way of working and follows their own type of culture. However, COMPANY X should not view these sub-units as mutually exclusive. The MT is in charge of determining the right mixture of sub-unit collaboration and are tightly integrated in both sub-units. The alignment sub-unit would have a more hierarchical structure and would contain exploitative projects such as creating procedures and processes. This sub-unit is best suited to the traditional software development method (Fitzgerald, 2006; Batra et al 2010). In contrast, the adaptive sub-unit allocates most of its resources on new product development and innovative projects. This sub-unit is more in line with the agile software development method (Napier, 2011). Vinekar (2006) made a comparison of the characteristics of both agile and traditional development organizations, which is written about earlier in this report (Table 1). From this we can see that when dividing employees between sub-units, it requires matching them with the characteristics of that specific development method. Employees who are flexible, team orientated, multidisciplinary, and customer focused fit best within the adaptive sub-unit. In contrast, people who prefer discipline, individualism and preplanned work potentially perform to their fullest capability in the alignment unit.
Balancing the two sub-units by determining the amount of resources allocated on different projects requires a tool for management to communicate their vision and strategy to the whole organization. Cooper (2001) and Napier (2011) showed us that portfolio management can assist in allocating scarce resources, expressing the strategy, prioritizing projects, achieving balance and to increase
communication. In addition, Anthony, Johnson and Sinfield (2008) mention that the primary task for new business is to articulate what the organization wants to be and to allocate resources to achieve that vision.
Management team
24
§ 5.2
Portfolio Management Tools - Strategic Bucket ApproachThe strategic bucket approach is a strategic method often mentioned in portfolio management literature. (Metheson and Menke, 1994; Graves et al., 2000) The method begins with the business’s strategy, and requires senior management and R&D people to make forced choices. These choices mainly consider questions of where they want to allocate resources. Next, COMPANY X firms has to mirror their strategy towards the buckets to determine the split of resources. Development resources are split across categories on each dimension of the buckets. Some common dimensions are mentioned by studies of Cooper et al (2001, 2009):
Strategic goals: What percentage should be allocated on building the development
infrastructure of COMPANY X and how much resources are allocated towards new product development
Product line: Within the new products, how much is allocated on product A and how much on product B
Procurement: How much of the development work can be done by external developers? This can create more time for projects that require specific in-house knowledge
Knowing this, management can create the buckets where decisions are made per individual bucket e.g. developing a new platform technology at product development, or; creating specific services for new to enter countries. Next, the desired spending by bucket is determined. This should contain the strategy which the company stated in the beginning. The final step COMPANY X must do is ranking each bucket. The buckets are a collection of projects in line with a business strategy that may involve process creation, cost reductions, minor product modifications, radical next-generation technological research or groundbreaking R&D initiatives (Chao & Kavadias, 2008) As probably noticed, finding a balance in the chaos of these kinds of developments is highly required in order to successfully create a product portfolio (Loch, 2000). To support this, the buckets encourage management to structural divide resources into smaller, more focused budgets that differ from alignment to adaptive actions, short term to long term and low to high risk. It is important to first allocate money to buckets, then prioritize within a bucket” (Belliveau, Griffin, Somermeyer, 2002). Otherwise there could arise competition between the buckets. Prioritizing within buckets can be done by using the factors by Vinekar (2006), mentioned earlier (p.18).
In addition, different criteria should be used to rate and select projects in each bucket. Here technologic developments will be more criticized by more qualitative measures and marketing and sales by more financial criteria, since it is way more common to determine the increase in direct sales instead of a future, yet to launch products. The strategic bucket approach must allow a high level of
25 agility since I realize that COMPANY X is operating in a turbulent environment. Therefore,
COMPANY X must agree a to be flexible in adjusting the projects within the buckets. I think that COMPANY X should have the opportunity to change the lay-out of the buckets every three months. An example of a strategic bucket lay-out is provided in the appendix (Appendix 10). The company is split in an adaptive and alignment sub-unit, where 40% is allocated to the adaptive sub-unit and 60% to the alignment sub-unit. Taking in account that COMPANY X now focusses more on alignment. Within these bucket I made a split in the (new) products as an external activity and the company as an internal activity. From there I filled in the buckets with projects for COMPANY X. Implementing a content delivery network and the launch of song flow (both radical innovations) are two examples of new products being introduced, but as one can see, most resources are spend on the alignment bucket where processes like test infrastructure and reward systems are set. The amount of resources and there priority within the buckets is partly derived from the risk matrix discussed later in this chapter.
§ 5.2.1
New Product Development Strategic BucketsChao & Kavadias (2008) are the most recent authors of writing about strategic buckets. Lately they came up with some interesting findings how to balance new product development (NPD) portfolios. It is assumed by many that managers are often confounded by both environmental complexity and environmental instability (Chao & Kavadias, 2008), not knowing when to choose from one portfolio over the other when situations are rapidly changing or are very complex. Environmental complexity, meaning the number of unknown interdependencies among technology and market parameters that determine product performance, and environmental instability, meaning as the probability of changes to the underlying performance functions. Nevertheless, in the recent study of Chao & Kavadias (2008) I find that they have an actually clear effect on the NPD portfolio balance. “Environmental complexity shifts the balance toward radical innovation, and conversely, environmental instability shifts the balance toward incremental innovation (p.909) (Table 2).
Table 2: Chao & Kavadias (2008)
The environment COMPANY X is in can be described as both complex and instable(Kusek, 2005, RIAA 2011). These findings can make NPD decisions for COMPANY X more clear. When
COMPANY X chooses for maximizing expected return, they should improve incremental innovations, e.g. continue to developed the current products, like the music distribution platform introduced
26 earlier. In contrary, the best strategy to reduce risk would be a balance towards radical innovation. In practice this means that if COMPANY X chooses incremental innovations they should not develop brand new technologies and consolidate around the business as it is now. If COMPANY X chooses radical innovations, e.g. introducing brand new products , they reduce the risk of choosing the wrong environmental focus, and continuously innovate with radical new products in the unstable
environment, comparable with what COMPANY X does now. Table 2also shows us that when COMPANY X chooses to balance the NPD portfolio, decisions depend on the risk (U) of either radical or incremental innovation.
§ 5.3
Portfolio Management Tools - “The Risk Matrix”The risk matrix can be an effective decision tool to display portfolio balance. Using this tool can help COMPANY X to visualize and to reveal the distribution of risk by looking at the newness of project for the company as well as the market. Each innovation can be positioned on the matrix by
determining its score on two dimensions: how familiar to the company the intended market is and how familiar the product or technology is. I took the three product innovations from the adaptive sub-unit and rated them on the statements given by Day (2007).
An example of the rating and the total end result is shown in the appendix. (See appendix 11 for the risk matrix by Day, 2007). I took the three new products from the adaptive site of the strategic bucket scheme (appendix 10): implement product A, B, and C. The form in appendix 11 is filled in
considering the implementation of product A. Combining these results and the other projects shows us an overview of the probability of failure per individual project.
§ 5.4
Prioritizing Projects and Most Critical PracticesCurrently, COMPANY X’s employees are asking for the implementation of more structure and set processes as well as procedures. Therefore I can already determine that more resources need to be allocated on the alignment sub-unit (or bucket) instead of the adaptive sub-unit. Prioritizing within this bucket is the following step.
Results from interviewing comparable companies (appendix 6) showed us that there where similar practices mentioned when talking about ambidexterity and critical practices. All companies told us that testing processes, employee reward systems and customer involvement procedure are most mentioned alignment practices. Interestingly, I found that Vinekar (2006) also recognized that these practices are mentioned as characteristics in both agile and traditional software development (Appendix 12).
27
§ 5.5
Expressing the StrategyMany actions of change within on organization start with the vision and strategy of the firm (Gibson & Birkinshaw, 2004). It is the task of top management to develop and communicate a vision for the future and to translate this into a viable strategy (Puhlmann & Gouy, 1999). When the vision and strategy is clear, employees will better understand the reason for being of the firm, reas ons for change, and to create an awareness for future individual actions. “Companies seeking to boost their ability to growth through innovation need to be clear about their goals (what they want) and boundaries (what they won’t do). Companies should set goals and boundaries for wide range of strategic factors” (Anthony, et al, 2008 p.50.).
In Appendix 13 I used a table to describe and express the strategy for implementing the findings from this research. Be describing the objectives, goals, strategies, measurements and tactics I summarized what I conclude and recommend at the chapter below.
Chapter 6: Conclusion & Recommendations for COMPANY X
COMPANY X is getting themselves ready to move from a startup organization towards a professional company and within this change, finding a balance between innovation and consolidation. Finding a concrete problem for this research was the first and most challenging task. Since everybody at COMPANY X knows that there a lot of things not in place yet, it can be quite hard not to sound too negative and pessimistic. However, I believe that choosing a business problem research was needed in order for COMPANY X to increase their future performance. For this performance increase it was needed to create an infrastructure on which current business can be aligned and new business can be adapted. The need for structure from the employees proved that the alignment at COMPANY X was lacking and that a balance between consolidation and innovation needed to be found. This was the main research question for this report. COMPANY X can balance innovation and consolidation by changing the organizational structure and to focus on alignment first and to use structural
ambidexterity with using different development approaches for the two sub-units. Creating these two sub-units will result in a dual culture when it comes to development of COMPANY X. This brings us to the first sub-question. Splitting up these type of development infrastructures will help in naturally splitting more adaptive and aligned people and cultures. Making this split will help COMPANY X in recognizing the pros and cons of both sub-units and will make all employees more aware of when to use what sub-unit for a specific project. In addition, COMPANY X will become more aware of the allocation of recourses since they can track how much resources are allocated to consolidative projects and how much on innovative projects.
28 Both literature and interviews with comparable IT companies showed us a good answer on the second sub question, what are the most critical practices COMPANY X needs for ambidexterity. The most critical practices in attaining a balance between alignment and adaptability are: implementing rewards systems, testing procedures and customer involvement. To control the split up and to create balance in the type of projects, I suggest that applying portfolio management methods such as the strategic buckets approach and risk matrixes can help COMPANY X with structure and visualize its intentions for the future.
The combination of literature, interviews, and observations brought us to the following recommendations for COMPANY X:
Recommendations:-Start implementing structural ambidexterity: Create an adaptive and a alignment
sub-unit by splitting up employees and working styles. This will primarily result in a structure and a clear separation between innovation and consolidation. First only the MT and the project managers will know how to balance this. Later on the processes and systems decision making will become more clear and COMPANY X can switch to a more contextual kind of ambidexterity.
-Focus on the most critical practices first: we determined that testing, customer involvement
and rewards systems are the most critical systems when comparing both traditional and agile
development. Implementing these systems as the highest priority, will make COMPANY X
focus on practices considered important for an ambidextrous organization.
-Use strategic buckets project management method :this will create focus and consistency on the vision and strategy. Use the five factors from Vinekar (2006) to determine which sub-unit gets the ownership and how much support is needed from the other sub-unit.
-Use the Risk matrix to decide on what new developments COMPANY X should invest: Together with the table of Chao (2008) (Table 2) COMPANY X can then better discuss which new projects to choose. The example shows that implementing Product A is the most important project to allocate resources to.
Chapter 7: Discussion, Reflection and Limitations
This research determines the need for ambidexterity within COMPANY X and showed how this can contribute in in being efficient in today’s activities and at the same time be able to cope with
tomorrows changing demands. In order to create more alignment, I proposed to use clear separation between an adaptive sub-unit, focusing on explorative activities, and an alignment sub-unit, focusing more on exploitative activities. Also, I proposed to use different development strategies within these sub-units. Where the adaptability is better suited with agile software development, alignment is best
29 fitted with a traditional approach. While the sub-units both work in different ways and will both have their own culture, the project manager will have the knowledge on how much these two sub-units must collaborate. Allocating resources and setting priorities are derived from communicating the vision and strategy and by the use of portfolio methods such as the strategic bucket approach.
These findings for COMPANY X can also be applied for other companies. I believe that starting companies are involved in lots of adaptive activities in the beginning and as a firm grows, more and more alignment activities need to take place (Greiner, 1972). Since this research provides an
infrastructure for ambidexterity, which includes alignment, I believe that lots of young and starting IT organizations can benefit from the results of this research.
What is important to realize is that COMPANY X is rather young company. Therefore many processes and procedures are not in place yet. This means that one could mention many things missing at
COMPANY X. Nevertheless, I believe we selected the most important issues both in line with the business development literature as well as COMPANY X’s situation. Researching within the internal situation of a start-up company results in challenging data collection methods. This is specifically because in COMPANY X’s situation, there was very little reported data available. This resulted in a purely qualitative data gathering. The industry COMPANY X operates in is quite specific. The music industry is small, and the digital music industry is even smaller. However, the software development industry is growing fast and industry specific research will always contribute to increasing
performance. Further research on ambidexterity within the field of software development or other specific industries is requested by several authors (Gibson and Birkinshaw 2006; He and Wong, 2004). In addition, research on how to apply ambidexterity is lacking and will form a great contribution to both professionals and academics.
30
Literature
Adler, P., Goldoftas, B., & Levine, D. 1999. Flexibility versus efficiency? A case study of model changeovers in the Toyota production system. Organization Science, 10: 43–68.
Agile Alliance, 2001. “Manifesto for agile software development (www.agilemanifesto.org)
Agile Manifesto, 2001 (www.agilemanifesto.org)
Aken van, J.E., Berends, H., van der Bij, H. (2007) Problem solving in organizations. Cambridge University Press.
Akman, G., (2008) Innovative Capability, Innovation Strategy And Market Orientation: An Empirical Analysis In Turkish Software Industry, International Journal of Innovation Management, 12, 1, 69-111
Anthony, S., Johnson, M.W., Sinfield (2008) Institutionalizing Innovation, MIT Sloan management review, Vol. 49, 2, 45-53
Bala, I., Chy Hyon, L., Venkatraman, N., (2006) Managing in a small world ecosystem: Lessons learned
from the software sector, California Management Review, 48 (3), 28-47
Batra, D., Xia, W., VanderMeer, D., Dutta., K (2010) Balancing agile and structured development approached to successfully manage large distributed software projects: A case study form the cruise line industy. Communications of the Association for Information Systems. 27 (21) 379-394
Beck, K., and Andres, C. 2005. Extreme Programming Explained: Embrace Change, Boston: Addison Wesley.
Belliveau, P., Griffin, A., Sommermeyer, S., The PDMA toolbook for new product development, John Wiley & Sons, Inc (2002) New York
Benington, H. D. (1983) Production of Large Computer Programs. IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361.
31 Biazzo, S (2009): Flexibility, structuration, and Simultaneity in New Product Development. Journal of
product innovation management, (26) 336-353
Boehm, B. W., and Turner, R. 2004. Balancing Agility and Discipline: A Guide for the Perplexed, Boston: Addison-Wesley.
Business Week (2005). Special Report: Get Creative! August 1, 2005.
Burgelman, R (1991) "Intraorganizational Ecology of Strategy Making and Organizational Adaptation,"Organizational Science, 2/3, 239-262
Carmel, E., Becker, S (1995) A process model for packaged software development. IEEE Transactions on Engineering Management 42,50–61.
Chao, R.O., Kavadias, S. 2008; A theorectial framework of new product development portfolio; When and how to use strategic buckets, Management Science,54,5, 907-921
Clark, K. B., Fujimoto, T. (1991) Product development performance. Boston: Harvard Business School Press.
Conde, D. (2002) Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales, USA, Aspatore books
Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor, IEEE Computer (34)11, 131–133.
Cooper, R., Edgett, S., Kleinschmidt E., (2001) Portfolio management for new product development: results of an industry practices study, R&D management 31,4
Cooper, R; Perspective: The stage gate idea to launch process – Update, what’s new and Nexgen Systems. (2009) J. Product Innovation Management, 25 (3). 213-232.
Cooper, R., Edgett, S., (2010) Developing a product innovation and technology strategy for your business, Industrial research institute, May-June, 33-40
