IPD Symposium in Magdeburg 2004, Draft 20042005-0311-05-089

A comparison study on Reflections onStage-Gate™ vs.and DPD thein Software Development of Software Products Performed in two Different Ways

Stig Ottosson,

Information Technologies in Mechanical Engineering

Otto-von-Guericke University

Universitätsplatz 2

D-39106 Magdeburg

Germany

E-mail:

Tervix AB

Mårdvägen 34

S-44834 Floda

Sweden

Evastina Björk,

Halmstad University,

Box

S- Halmstad

Sweden

Abstract

Product Development is complex (Ottosson 1996, Björk 2003) and time dependent and many agents participate during the development process. Similar development situations to test different product development methods are difficult to set up and few comparingcomparison studies on development methods have been done. However, this article describes the development of two web based portals with the same mission using two different development methods. In Case 1 a Stage-gate view was used. In Case 2, which was a portal with more functionality than for Case 1, DPD – Dynamic Product Development was used.

When comparing the efficiency of development processes - measured e.g. in development time, cost and user satisfaction – the internal factors that should be considered are management principles, physical environment, tools & methods, financial resources, organisation & work, and the people doing the work.

To deepen the knowledge of product development, two software development cases (web portals) have been studied. Case 1 was performed in 2003 in Gothenburg, SwedenStage-Gate™. Case 2 was also performed in Gothenburg during January and February of 2004 principles. Both cases solved the same problem. Case 2 had more functionality than Case 1.

For Case 1 Time to Salesfor Case 1 was 30 weeks and3 weeks compared for Case 2to 3 weeks for Case 2. For Case 1 Time to ReleaseReady Productswasfor Case 1was 30 weeks and 10 weeks while fffor Case 2 it was 10 weeks. The pProgramming time in Case 1 was 400 360 - 500 hours in the first case while it wasand 250 hours in the second cCase 2. Thus, a modest conclustion is that DPD at least was not disadvatageous to use in the compared cases.Thus DPD showed to be as advantageous for software development as it was for the development of mechanical products, mecatronic products, and assistive products e.g. for disabled people.

A side conclusion from tThe investigationsalso is showed that the traditional outsider researacher position using interviews gave only gave rough information of (Case 1)while IAR gave andwhile detailed information and understanding was acquiredof Case 2when Insider Action Research (IAR) was used (Case 2).

Keywords:

Product development, Software development, Research methods

1Introduction

The main reason for conducting research in applied fields such as product development should be to better understand the development process and to improve the usability in methods and tools. In the case of product development case thatthis means to helping project managers and product developers to produce better products inwithin a wide perspective forin order that their companies and customers to bebecome more competitive, efficient and satisfied with the products.

Quite often the industrial relevance view in industrial applied fields is missing, whether it’s in conference papers, PhD Ttheses or scientific journals. This could be due to a variety of reasons, for example, the researchers may have no industrial experience, or they want fast results and so exclude qualitative studies, or perhaps they are simply not allowed inside real industrial processes. This at least is often the situation in the applied research field of Product dDevelopment.

Of different reasons, as that researchers often have no industrial experience, that they want fast results excluding qualitative studies, that they have an oldfashioned view of objectivity, and that they maybe are not let inside real industrial processes, unfortunately the industrial relevance view in industrial applied fields often is missing both in conference papers, PhD theses and scientific journals. At least that is the situation in the applied research field of Product Development.

Product Development is special as development projects/processes are complex (e.g. Blessing 2003, Dendsley et al 2003). This means that they change with time and often in an unplanned or unforeseen manner. Every development process also contains many complex interacting factors (see figure 1) which means that studying one factor separated from other factors giving rational conclusions for each of them often will not give expected results when they are combined to one unityinto one unit (Ottosson & Björk 2002). Furthermore, every development process is unique which is why two development processes cannot be directly compared. However tendencies can be studied if two similar development situations are studied within reasonably equal circumstanses whatwith regards to experience and skills of the team members, equipment, etc.


Fig. 1: Product development outcome is dependent on many factors that in turn are time dependent. Some important factors are shown in the figure (Ottosson 2005)Generally speaking, when comparing the efficiency of development processes - measured e.g. in development time, costs and user satisfaction – some important internal factors to consider are management principles, physical environment, tools & methods, financial resources, organisation & work, and the people doing the work (see figure 1). In this paper the shaddowed internal factors shown in the figure will be treated for two successful software development processes (Case 1 and Case 2). The way of performing reserach on complex processes will also be touched upon.


Fig. 1: The efficiency of a development process is dependent on many internal and external factors (Ottosson 2004). The shaddowed parts will be treated in the paper.

In Case 1 traditional development principles regarded as “best practise” were used and information on the development process was collected through interviews after the development process had ended. In Case 2 the principles of Dynamic Product Development – DPD - were used and Insider Action Research (IAR) as observer was used as the research method during the ten weeks the development lasted.

The term “Product Development” means all activities that go towards developing to develop a product and has as partswhich mainly are engineering design, process design, marketing, sales and management. Depending on what product to developthe product being developed the development time and cost will differ, which is why studies of the development of similar products is a way to getarrive at an understanding of what makes the differences in outcome. Further, an insider position of the researcher is needed to grasp the whole situation, which is accomplished by conducting Insider Action Research (IAR). Conduction IAR means that the researcher is or has been present more than 80 % of the time whenwhile the development is/was takestaking place part (Björk 2003, Björk & Ottosson 2006).

Making research based on interviews and enquiries not having lived or worked in an environment means that the researcher will get one view of the situation which dramatically can be changed if she/he gets the opportunity to be inside the environment performing IAR. One striking example on that is the view of the Toyota Production System (TPS) described in the well known book The Machine that Changed the World (Womack et al 1991) and the follower books about the Japanese system by different authors about lean production, TQM, Kaizen, etc., and the view of an American engineer working as a computer simulation engineer in TPS in Japan April 1996 – June 1999 (Mehri 2005).

Different products will have different commercsial life times,.or The less well chosen term “Product Life Cycle” (PLC) is often used to tellindicate the commercsial life time of a product or a product group. PLC in general is long for mechanical products at the same time as the research and development (R&D) cost in percentage of the turn over in the bransch is low (Ottosson 1998). Most extreme situations whatwith regards to PLC and R&D exist in the software bransch where the PLC is short (often less than two years) and the R&D is high (20 – 25 %) (Ottosson 1998).

Especially when PLC is short and R&D is high, Time to Marketing, Time to Sales and Time to Ready Products – often together called Time to Market - become extremely important for each company’s possibilities to make a profit on the product, especially when PLC is short and R&D is high as, as is Time-to-Volume in the case of consumer goods (Minderhoud and Fraser 2005). However, as the PLC is decreasing for all products due to globalisation, the use of IT, etc, andstudying the development of software products therefore should be of interest for the development of other types of products. Also, as production development is not part of the process when developing software products, it is easier to compare the early development process of software using different methods. in that case.

What characterises software products is that their commercial life time – the Product Life Cycle (PLC) - is short (often less than two years) and that the development time before release/launch can be in the range of 50 – 100 % of the PLC. When such relations reflect reality Time to Marketing, Time to Sales and Time to Release – often togther called Time to Market - of ready products becomes extremely important for each company’s possibilities to make a profit on the product. Studying development of software products can also be of interest for the development of other types of products with shorter PLC’s e.g. as more and more products inherit software and as PLC gets shorter and shorter for all types of products.

There are two principally different views on how to best make product development should be done in general. PThe traditional Stage-gate viewhilosophically they builds on the machine metaphor from Classical Newtonian Mechanics Classical Newtonian mechanicsin combination with Taylorism and the Bureaucratic School while the dynamic view builds on concepts from Quantum physics, Chaos Theory and cComplexity scienceTheory (Ottosson 2005) . They are traditional product development – asTo the class of Stage-gate methods belongsStage-Gate™ (Cooper 19942002, and Integrated Product Development (IPD) (Andreasen & Hein 1987, Concurrent Engineering ( and Simultaneous Engineering ( Stage-Gate™ (Cooper 2002) –To the class of dynamic devlopment methods, which is new, belongs so far and Quantum mechanics as dDynamic product Product development Development (DPD) (Ottosson 2004-c) and to some extent agile software development ( and flash development (Vandenbosch and Clift 2002).

The Stage-gate methods – which are technology-centered (letting people adapt) and “need” based methods - have in common have distinct decision points between different development phases. They seldom treat the topics on how to best carry out actual development work between the decision points. The research on the Stage-gate methods has, so far and with few excteptionsexceptions (e.g. Bragd 2003) been limited to survey studies and interviews offor reasons already describedstated. Stage-gate processes are today used in many larger companies in the western world although they may name them individually as e.g. the telephone company Ericsson, which calls their Stage-gate process for PROPS®. As the Stage-gate processes in practical use often become static and bureaucratic, the development turns out to be slow and costly when other developmentprinciples than re-engineering or reverced engineering is don. Managers in multi national companies tell that the Stage-gate processes often do not work well, even after many years of adaptionadaptation, which also is touched upon in reasont investigations (e.g. Minderhoud & Fraser 2004),as working welleffective.among

DPD – which is user-centered (fit capability of users) - differs not only in philosophy from the Stage-gate view but on how management is done and on how to best carry out the development work, which will be more touched upon below. The research on DPD is based mainly on Insider Action Research. The The closest methodolgymethodology used generally today in Sweden by in general used in smaller companies is DPD (Elving 2004) as it seems to be a natural way of working with little or no knowledge of formal development methods.

Stage-Gate™ processes are today used in most of the larger companies in the world although they name them individually as e.g. PROPRS® for Ericsson. As the Stage-Gate™ processes are static and bureaucratic, development turns out to be slow and costly why a growing interest is at hand for dynamic principles as DPD.For every branch there are in addition “best practises” that are commonly accepted as guide lines.

There are also two principally different views on how to do research on development processes. They also build on Newtonian mechanics with. They are; research done from an outsider position (classical research) and Quantum mechanics with research done from an insider position (action research). When the researcher is present in a process most of the time – in general more than 80 % - that is, it is called Insider Action Reserach – IAR (Ottosson & Björk 2002). IAR can be done as an observer, team member and/or project leader (Björk 2003).

In this paper two successful software development processes to develop two different web portals with the same mission (Case 1 and Case 2) will be used to compare effects of development methods. used. In Case 1 a Stage-gate methodology was used. In Case 2 Dynamic Product Development (DPD) was used. Case 2 covered the same functionality as Case 1 got extended functionality during the development process.

The background of Case 2 is that the customer of Case 1 was disappointed with the cooperation with the company developing the product as he felt his imput was reduced to dicussions at the gates. Adjustments after the gates meant more work done to change the product thenthan if the changes had been made during earlier testing and earlier customer involvement..were done when the customer found out problems earlier testing the outcome of the work In turn that had led to discussions on who was to pay for the changes whenonce the demands could bewere interpreted differently. He also was disappointed with the graphical interface and found the portal not user friendly for people with little computer experience. Therefore, instead of changing the completed product from Case 1 and extending it with new functionality, he decided to start over again with another company (Tervix AB) working with DPD. The shift of programming language from PHP (open source) to ASP (Microsoft©) became an important argument in the discussions although, it seen from a technical view, it was egala matter of indifference which language was used.

2Research set-up

In both cases the customer (Innovationsexpo AB) and the entrepreneur/owner, of the products Mr Anders Meiton was involved in setting up the demands and testing the outcome of the development activities for .also having set up the demands and making tests of the outcome of the development activitiesThe author followed Case 2 on a daily basis, sitting in the same room as the product developers although not taking part in the development other than asking questions now and then to controlecheck that he had grasped the development situation rightcorrectly. He also continously checked upthe time used. In addition he had weekly dialogues with Mr Meiton as well as he madehaving one interview with the project leader of Case 1. That interview took place when Case 2 was finished.

The research behind this paper had beenwas structured in such a way that the author Björk performed Action Research on Case 2 while author Ottosson performed IAR on development Case 2 as observer while the development took place in the Spring of 2004. After having got a deep insight into that Case he, in March 2004, interviewed the project leader of Case 1 on how that project went. During and after the development of Case 2, both authors held a number of dialogues to discuss the findings from their investigations.

During the development of Case 2 a number of dialogues were had with Anders Mejton, who was the initiative taker and customer of both the products. Mr Mejton is also the marketer and salesman of the products. In Case 1 Mr Mejtons position was that of an outsider, while in Case 2 he was deeply involved in the everyday development and testing of the programming results. He is managing director of InnovationsExpo AB. Figure 1 shows the relations beween the actors in and between the cases.


Fig. 2: The relations between actors and the cases in the investigation

3Dynamic Product Development -– DPD – in general

To be able to deal with complex situations Dynamic Product Development (DPD) has been continually developed since 1994. (e.g. Ottosson 19962005 & 2002, Björk 2003). DPD builds on the view that it is rather a waste of time to plan in detail for more than for one week, give or take a few days (Ottosson 2004-b) when new product development is done. Instead a clear vision, rough long term plans, and detailed short term plans are used until a stable situation is reached.

The start of the development of a “new-to-the-world product” is a wish in DPD, which is a future thing. It can also be a want (Godin 2005), which is a more near future thing or a need, which is a rather immediate thing. The more immediate or urgent a need is the more one feels under pressure to take an exisiting solution or to further develop an exisiting solution in order to meet the need. The stage-gate view is aimed at satisfying a need for which bench-marking, lean production, QFD, TQM and other tools have been developed. The more one moves towards creating a new-to-the-world product the less such tools can be used (e.g. Ottosson & Nordin 1996).

Asccording toDPD, complex situations are difficult to foresee and simulate, contionous situation awareness (SA) is of utter importance especially for the entrepreneur combined with which is why real tests are always needed to make good products. [SA means being aware of what is happening around you and understanding what the information means to you now and in the future (Endsly et al 2003)]. Recent It seems asthat information also tells that thethe more tests done per time unit, the more successful the company (Schrage 2000).