Selecting the right method for the right project

Abstract

The development of information systems is constantly changing. As a background of the change, there is almost a traditional problem about the high failure rates of information systems development (ISD) projects, but it is no longer the only change-driving force. The role of information systems and their strategic significance has increased considerably due digitalization. This has happened also in the areas of business, which have not been traditionally thought as IT-oriented. Furthermore, the new agile development methods have forced ISD clients to take more responsibility for ISD than before. In practice, this means that completely outsourcing ISD is not as sensible nor as simple as before. ISD clients who acquire information systems must be aware of the different ISD methods and be able to compare and choose the most suitable for the business situation and the objectives in question.

ISD method selection is rarely studied, and the majority of publications concentrate on different selection criteria relating to the ISD method choice without a clear selection model. Only a few ISD method selection models were found in the literature. Furthermore, the earlier ISD method selection models are restricted by two factors: firstly, the recommendations behind the prior ISD selection models do not correspond to today’s thoughts about the ISD methods; secondly, prior ISD selection models concentrate only on the properties of the ISD pro-jects, and attention is not really given to the business environment or the business to be developed.

In a situation like this, it was considered necessary to develop and study an ISD selection framework which takes the business development and business environment into account as well. Furthermore, it was seen as necessary to study both the customer and supplier practices related to the ISD method choice. The objective was to understand the present situation and estimate how the developed ISD selection framework could be utilized in the future.

The study was carried out in several stages. Firstly, two unsuccessful ISD projects were studied in the case study, and it was found that the ISD method used in the projects did not correspond to the properties of the business environment in either case. After that, a contingency theory–motivated ISD selection framework was developed, and a systematic literature review was conducted to study earlier ISD method selection criteria and compare them with the developed ISD method selection framework. In the next stage, expert interviews were done. Altogether, 31 ISD experts working on the borderline between the IS sup-plier and client were interviewed and asked their opinions on existing ISD method selection practices by both the client and the supplier. Furthermore, the experts were asked for their opinions on the recommendations of earlier ISD method selection models and on the developed ISD method selection framework.

As a result of the study, it can be stated that the developed ISD method framework covers both the previous ISD method selection criteria, which mainly concentrates on ISD project factors, and the business environment factors. Whereas the majority of the interviewed experts considered the developed ISD method selection framework useful, the recommendations of earlier ISD method selection models were regarded as outdated. Furthermore, it was noticed that in IS client organizations, there was almost no discussion about the ISD methods, and in the supplier organizations, the discussion was very rare. Any systematic projectspecific ISD method selection practice had not been perceived in either organizations. Supplier organizations can justify their reasons for favouring a certain ISD method with the bounded rationality, whereas the operation of customer companies doing (or not doing) the ISD method selection seems to be filling the features of functional stupidity. In the future, it is important to study how to plant the ISD method selection as part of the starting stage of the ISD project. In addition, the developed ISD method selection framework should be tested in the practice.

Tietojärjestelmien kehittäminen on jatkuvassa murroksessa. Muutoksen taustalla on jo perinteiseksi muodostunut ongelma tietojärjestelmäprojektien epäonnistumisesta, mutta se ei ole enää ainoa syy. Digitalisaation myötä tietojärjestelmien rooli ja strateginen merkitys on kasvanut huomattavasti myös sellaisilla liiketoiminta-alueilla, joita ei ole ajateltu IT-orientoituneina. Lisäksi uudet ketterät tietojärjestelmien kehittämismenetelmät osallistavat tietojärjestelmäprojektien asiakkaat, jotka joutuvat entistä vastuullisempaan asemaan. Käytännössä tämä kaikki merkitsee sitä, että tietojärjestelmien kehittämisen täydellinen ulkoistaminen ei enää ole yhtä mielekästä, eikä myös yhtä yksinkertaista kuin ennen. Tässä tilanteessa myös tietojärjestelmiä hankkivan asiakkaan pitää tietää erilaisista kehittämismenetelmistä ja kyetä vertailemaan ja valitsemaan kyseiseen liiketoimintatilanteeseen ja tavoitteisiin parhaiten sopiva kehittämismenetelmä.

Tietojärjestelmien kehittämismenetelmien valintaa on tutkittu vähän ja suurin osa löydetyistä julkaisuista keskittyy listaamaan erilaisia menetelmävalintaan liittyviä kriteerejä. Varsinaisia tietojärjestelmien kehitysmenetelmien valintamalleja on esitetty vain muutamia. Aiempien valintamallien käyttökelpoisuutta rajoittaa kaksi tekijää: ensinnäkin mallien taustalla olevat olettamukset eivät välttämättä täsmää tämän päivän ajatuksiin kehittämismenetelmistä, ja toisekseen valintamallit keskittyvät tietojärjestelmien kehittämisprojektien ominaisuuksiin, kehitettävää liiketoimintaa tai liiketoimintaympäristöä ei aikaisemmissa valintamalleissa juurikaan huomioida.

Tilanteen ollessa tämä kehitimme ja tutkimme tietojärjestelmän kehittämismenetelmien valintamallia, joka ottaa huomioon myös samaan aikaan tapahtuvan liiketoiminnan kehittämisen ja liiketoimintaympäristön. Lisäksi tutkimme tietojärjestelmän kehittämismenetelmien valintaan liittyviä käytäntöjä sekä asiakkaan että toimittajan näkökulmasta. Tavoitteena oli ymmärtää menetelmävalinnan nykytilannetta ja arvioida miten valintamallia voisi jatkossa hyödyntää.

Tutkimus toteutettiin useammassa vaiheessa. Ensimmäiseksi tapaustutkimuksin tutkittiin kahta epäonnistunutta tietojärjestelmäkehitysprojektia, ja havaittiin että kummassakaan tapauksessa valittu tietojärjestelmän kehittämismalli ei vastannut liiketoimintaympäristön tarpeita. Sen jälkeen kehitimme kontingenssiteoreettisen tietojärjestelmän kehitysmenetelmän valintamallin, jota verrattiin systemaattisella kirjallisuuskatsauksella löydettyihin aikeisempiin valintasuosituksiin. Vertailun jälkeen haastateltiin 31 asiantuntijaa. Haastatteluilla selvitettiin nykyisiä tietojärjestelmän kehitysmenetelmien valintaan liittyviä käytäntöjä, niin tietojärjestelmäasiakkaan kuin toimittajan näkökulmasta. Lisäksi asiantuntijoilta kysyttiin heidän mielipidettään aiempien valintamallien taustalla olevista väittämistä sekä nyt kehitetystä valintamallista.

Tulos on, että ehdottamamme kontingessimalli kattaa sekä aiemmat, projektinominaisuuksiin keskittyvät valintakriteerit, että myös liiketoimintaympäristön epävarmuuteen liittyvät tekijät. Suurin osa haastatelluista asiantuntijoista (23 vastaajaa 31 haastatellusta) piti ehdotettua valintamallia käyttökelpoisena. Aiempien valintamallien taustalla olevat väittämät koettiin ajastaan jälkeen jääneiksi. Lisäksi havaittiin, että asiakasyrityksissä keskustelua tietojärjestelmän kehittämismenetelmistä ei käytännössä ollut juuri lainkaan, eikä myöskään suurimmassa osassa toimittajayrityksiä. Mitään säännöllistä projektikohtaista valintakäytäntöä ei kummissakaan yrityksissä oltu havaittu. Haastateltujen asiantuntijoiden mukaan kehittämisprojekteissa kuitenkin pääsääntöisesti käytetään jotain tietojärjestelmän kehittämismenetelmää, ja syyt menetelmän käyttöön vaihtelevat. Toimittajayritysten syyt tietyn menetelmän suosimiseen ovat pääosin perusteltavissa rajoitetulla rationaalisuudella (bounded rationality), kun taas asiakasyritysten toiminta menetelmän valinnassa näyttää täyttävän toiminnallisen typeryyden (functional stupidity) tunnuspiirteet. Jotta kehitetystä mallista tulee asiakasyrityksille hyödyllinen käytännön työkalu, on seuraavaksi syytä tutkia miten tietojärjestelmän kehittämismenetelmän valinta saadaan osaksi projektin käynnistämisvaiheen tehtäviä. Tärkeää on myös testata nyt esitetyn kontingenssimallin toimivuutta käytännön tilanteissa.