Kaikki olennaiset termit

Sivulle tehdään parhaillaan koostetta käytetyistä termeistä. Sivun sisältö kehittyy päivittäin ja se saattaa vielä sisältää puutteita tai virheitä.

 

Aikataulu (Gantt)

Graafinen esitys suunnitelmasta, joka kuvaa tehtävien järjestyksen ja resurssien kohdentamisen. Gantt menetelmälaarissa.

Arvio tietoturva- ja tietosuojatasosta

Arvio tietoturva- ja tietosuojatasosta koostaa yhteen vähimmäisvaatimukset ja noudattamistarpeet mm. tiedon julkisuudelle ja salassa pidettävyydelle. 

Asiakas

Henkilö tai ryhmä, joka hyötyy hankkeen lopputuloksista. Asiakkaita ovat kaupunkilaiset, kaupungissa toimivat yritykset ja näitä tukeva infrastruktuuri.

DevOps

DevOps on yhtä kuin kehitystiimin kehityskäytännöt ja yhteys jatkuviin IT-palveluihin: miten testi- ja tuotantopalvelimille julkaistaan ja miten varmistetaan, että eri ympäristöt ovat ajan tasalla. DevOps menetelmälaarissa.

Edellytykset

Mikä tahansa perustavaa laatua oleva näkökulma, jonka täytyy olla olemassa ja säilyä, jotta hanke voi onnistua. Edellytyksien tunnistamiseen sisältyy esimerkiksi ympäristön, nykytilan, tavoitetilan, reunaehtojen, ja puitesopimusten tunnistaminen. Edellytykset perinteisen hankemallin valmisteluvaiheessa.

Edistymisraportti

Aikaperusteinen, hankkeen edistymistä kuvaava raportti hankepäälliköltä hankkeen ohjaus/johtoryhmälle. Seuranta ja raportointi menetelmälaarissa.

Ehkäisevä ja korjaava toiminta

Riskin toteutumisen aiheuttaman vaikutuksen pienentämiseksi tehty suunnitelma, joka kirjataan riskilokiin. Riskien hallinta menetelmälaarissa.

Hanke, projekti

Tilapäinen organisaatio, joka on luotu yhden tai useamman tuotoksen aikaansaamiseksi. Hanke voidaan tarvittaessa jakaa projekteiksi, joiden suunnitteluun ja hallintaan käytetään samoja menettelyjä kuin hankkeissa. Roolit ja vastuut hankkeissa.

Hankehallinnan tuotos

Tuotos, joka tarvitaan osana hankkeenhallintaa ja ylläpitämään laatua, esimerkiksi edistymisraportti, loppuraportti jne. Hankehallinnan tuotokset ovat samoja riippumatta hankkeen tyypistä. Kehmetin dokumenttipohjia voidaan käyttää sellaisenaan, tai niitä voidaan muokata hankkeen tarpeiden mukaisiksi.

Hankehallinta

Hankehallintaan kuuluu kaikkien hankkeen osa-alueiden suunnittelu, delegointi, seuranta ja valvonta sekä mukana olevien motivointi, jotta hankkeen tavoitteet saavutetaan huomioiden aikataululle, kustannuksille, laadulle, hankkeen laajuudelle, hyödyille ja riskeille asetetut tavoitteet ja vaatimukset.

Hankeorganisaatio

Hallinnollinen rakenne, jonka muodostavat hankkeen johto/ohjausryhmä ja hankepäällikkö sekä muut hankkeen toteuttamisen kannalta olennaiset roolit, kuten tuoteomistaja, tiimin vetäjät, laadunvarmistus jne. Hankeorganisaation kuvauksessa kuvataan eri rooleissa toimivat henkilöt sekä heidän raportointisuhteensa. Roolit ja vastuut hankkeissa.

Hankepäällikkö

Hankepäälliköllä on vastuu ja valtuudet hankkeen päivittäisestä johtamisesta, jotta halutut tuotokset saadaan toteutettua johtoryhmän kanssa sovittujen rajausten puitteissa.

Hankesuunnitelma

Hankesuunnitelma konkretisoi tiekartan sisällön. Hankesuunnitelman ei ole tarkoitus olla tarkka toteutussuunnitelma. Toteutussuunnitelmat ovat yleensä hankesuunnitelman liitteitä. Itse hankesuunnitelma on kattodokumentti, joka kertoo hankkeen sen hetkisen tavoitteen ja sisällön (laajuus), aikataulun, budjetin, laatuolettaman, ohjaustavan, riippuvuudet ja sidonnaisuudet. Mahdollinen hankintamalli sisällytetään hankesuunnitelmaan. Hankesuunnitelma menetelmälaarissa.

Hanketoimeksiannon muistio

Ulkoinen tuotos, joka määrittelee hankkeen tavoitteet karkealla tasolla ja valtuuttaa käynnistämään hankkeen valmistelun. Kehitystarpeet menetelmälaarissa.

Hankinta-asiantuntija

Opastaa hanketta hankintalain mukaisen hankinnan valmistelun ja toimeenpanon läpiviennissä.

Hankintamalli

Hankintamalli määrittelee hankinnan kohteen (mitä hankitaan), hankinnan vaiheet (milloin hankitaan) ja hankinnan kokonaiskustannuksen eli hankinnan arvon sekä käytettävän hankintamenettelyn. Kun hankinta koskee tietojärjestelmää, hankintamalli määrittelee myös ratkaisun toteuttamistavan sekä ylläpidon järjestämistavan, sekä huomioi järjestelmän elinkaaren. Hankintamallin valinta menetelmälaarissa.

Hankintapäätös

Hankintapäätös on hankintayksikön viranhaltijan tekemä virallinen päätös hankkia (esimerkiksi hankintajohtaja). Hankintapäätös valmistellaan ja kirjataan yleensä Ahjo-päätöksentekojärjestelmään. Pienhankinnat voidaan joissain tapauksissa tehdä pelkästään Kosti-tilausjärjestelmällä. Hankintapäätöstä valmistellessa on aina syytä konsultoida hankinta-asiantuntijaa ja tarvittaessa myös oikeuspalveluita.

Hankintayksikkö

Hankintayksikkö on se toimielin, joka suorittaa hankinnan (esimerkiksi TASO, Hankinnat ja kilpailuttaminen).

Hankkeen elinkaari

Hankkeen elinkaari muodostuu hankkeen vaiheista. Ketterässä menetelmässä elinkaari sisältää kaikki vaiheet selvityksestä käytöstä poistoon ja perinteisessä mallissa valmistelusta käyttöönottoon. Ketterä malli voidaan myös päättää alfa-vaiheeseen, jos hankkeella ei ole tuotantotarkoitusta.

Hankkeen loppuraportti

Hankepäällikön johtoryhmälle toimittama raportti, joka vahvistaa kaikkien tuotosten luovuttamisen, ja sisältää päivitetyn kustannus-hyötyanalyysin ja arvion hankkeen onnistumisesta verrattuna alkuperäiseen suunnitelmaan. Loppuraportin pohja perinteisen mallin päätösvaiheessa.

Hankkeen omistaja

Hankkeen omistajalla on viranhaltijan mandaatti ohjata hanketta. Hän hyväksyy, päättää tai vie ylempään päätöksentekoon hankkeen tuloksenteon kannalta tärkeät asiat (esim. sisältöön, kustannuksiin, rahoitukseen, henkilöstö-, materiaali- ja muihin resursseihin liittyvät asiat). Hankkeen omistaja toimii hankkeen johtoryhmän puheenjohtajana. Roolit ja vastuut hankkeissa.

Hankkeen ositus

Hankkeen ositus on kuvaus hankkeessa toteutettavan järjestelmän tai palvelun osista. Osat ovat osajärjestelmiä, komponentteja ja ominaisuuksia. Isoissa hankkeissa, joissa on tarve pilkkoa hanke osiin, on todennäköisesti hyvä tehdä hankkeen osille ns. osaprojekteille omat suunnitelmansa ja nostaa hankesuunnitelmaan vain yhteenveto näistä. Hankkeen ositus menetelmälaarissa.

Henkilötieto

Henkilötietoja ovat sellaiset tiedot, joiden perusteella henkilö voidaan tunnistaa joko suoraan tai välillisesti yhdistämällä yksittäinen tieto johonkin toiseen tietoon. Henkilötietoja ovat esimerkiksi nimi, sähköpostiosoite, puhelinnumero, paikannustiedot, henkilötunnus, potilastiedot, IP-osoite ja auton rekisterinumero. Tietosuoja tarkoittaa henkilötietojen suojaamista. 

Henkilötietojen käsittely

Henkilötietojen käsittelyllä tarkoitetaan kaikkia toimia, joita kohdistetaan henkilötietoihin joko automaattista tietojenkäsittelyä käyttäen tai manuaalisesti. Käsittelyä ovat tietojen kerääminen, tallentaminen, järjestäminen, jäsentäminen, säilyttäminen, muokkaaminen tai muuttaminen, haku, kysely, käyttö, tietojen luovuttaminen siirtämällä, levittämällä tai asettamalla ne muutoin saataville, tietojen yhdistäminen, rajoittaminen, poistaminen ja tuhoaminen. Myös pelkkä tietojen katselu on niiden käsittelyä.

Hyväksyjä

Henkilö tai ryhmä (esimerkiksi johtoryhmä), joka on pätevä ja oikeutettu hyväksymään (hankehallinnan tai varsinaisen) tuotoksen valmiiksi ja tarkoituksenmukaiseksi. Roolit ja vastuut hankkeissa.

Hyväksymiskriteerit

Priorisoitu listaus vaatimuksista, jotka hankkeen lopputuotosten on täytettävä ennen kuin asiakas hyväksyy sen, eli mitattavissa olevat määritykset, jotka vaaditaan tuotoksilta, jotta avainsidosryhmät voivat hyväksyä ne. Laadunvarmistus menetelmälaarissa.

Hyväksyntä

Muodollinen vahvistus, että tuotos on valmis, ja täyttää sille määritellyt vaatimukset.

Hyöty

Mittavissa oleva parannus, mikä johtuu hankkeen tuloksesta, ja jota yksi tai useampi sidosryhmä pitää etuna. Hyödyt voivat olla joko aineellisia (rahalla mitattavia) tai aineettomia - esimerkiksi asiakastyytyväisyyden parantuminen.

Hyötyjen mittaamissuunnitelma

Suunnitelma, joka määrittelee, miten ja milloin hankkeen hyödyt voidaan mitata. Perinteisessä hankkeessa mittaaminen tapahtuu pääasiassa hankkeen päättymisen jälkeen, ketterässä jo hankkeen aikana. Hyötyjen mittaamissuunnitelman pohja perinteisen hankemallin päätösvaiheessa.

Jatkuva oppiminen

Jatkuvassa oppimisessa hankkeen työtapoja tarkastellaan jatkuvasti ja niitä kehitetään kokeiluilla sen sijaan, että jatkuvasti painiskeltaisiin samojen ongelmien kanssa. Tällä tavoin hankkeen työskententelystä saadaan pikku hiljaa tehokkaampaa, ja haaste jota hankkeessa ratkaistaan saadaan yhä paremmin haltuun. Jatkuva oppiminen menetelmälaarissa.

Julkaisu

Yksittäisen tuotantoonsiirron (version) sisältämät tuotokset. Julkaisun sisältöä hallitaan ja testataan, ja se käyttöönotetaan yhtenä kokonaisuutena. Kts. Myös "tuotantoon siirto".

Kanban

Täysin jatkuva prosessiohjausmalli. Tiimi ottaa jatkuvasyötteisesti uusia ominaisuuksia kehitettäväksi tuoteomistajan priorisoimasta kehitysjonosta, sitä mukaa, kun kaistaa vapautuu. Puhtaassa Kanbanissa ei siis ole sprinttejä. Kanban edellyttää Scrumia vähemmän formaalisuutta esimerkiksi valmiin määritelmän ja käyttäjätarinoiden suhteen. Tuoteomistajan ja kehittäjätiimin kollaboraatio korostuu. Kanban ja kaikki muutkin ketterät menetelmät edellyttävät riittävää kokonaissuunnittelua. Tarkka vaihesuunnittelu ei kuulu Kanbaniin, vaan samaa asiaa hoitaa Kanban-taulu.

Kehitysjono

Kehitysjono on prioriteetti- ja toteuttamisjärjestyksessä oleva työlista, jonka pohjalta kehitystyö tehdään. Se on lista kaikista järjestelmään tulevista ominaisuuksista, toiminnoista, vaatimuksista, parannuksista ja korjauksista. Lista on prioriteettijärjestyksessä, jotta kehittäjät voivat poimia siitä aina ylimmän tehtävän ja olla samaan aikaan varmoja, että tuottavat työllään palvelun kannalta parasta mahdollista arvoa.  Kehityksen aikana kehitysjonon tehtäviä poimitaan usein näkyville kanban-taululle (ks. Kanban) tai sprint backlogille. Kehitysjonon lisäksi on tärkeää pitää silmällä edistymistä suhteessa tuotteen kokonaisuuteen. Kehitysjono menetelmälaarissa.

Ketterä hankinta

Ketterä hankinta tarkoittaa hankintaa, jossa ostetaan resursseja palvelusta vastaavan organisaation käyttöön. Näin hankinnan kohdetta ei tarvitse lyödä yksityiskohtaisesti lukkoon etukäteen, vaan tarjoajilta vaadittava osaaminen määritellään visio-, teknologia- ja toimintatapatasolla ja palvelun tarkka toteutustapa ratkaistaan vasta hankkeen aikana kokeilujen ja jatkuvan oppimisen myötä.

Ketterä kokeilu

Ketterällä kokeilumallilla pyritään edullisiin käytännön selvityksiin, kuten prototyyppeihin, ennen isompaa hankintaa tai järjestelmään sitoutumista.

Ketterä toteutus

Ketterä toteutusmalli soveltuu erityisesti omaan ohjelmistokehitykseen tilanteessa, jossa markkinoilta ei löydy tarpeeseen sopivaa valmisratkaisua tai tuotetta räätälöitäväksi. Ketterää toteutusmallia voi käyttää myös hankittavaan valmisratkaisuun ja käytössä olevan järjestelmän jatkokehittämiseen.

Korjaava toimenpide

Toimenpiteet, joilla korjataan tuotoksen viat tai ratkaistaan suunnitelmaan kohdistuvat uhat. Riskienhallinta menetelmälaarissa.

Kokonaisarkkitehti

Kokonaisarkkitehti (kaupunki) / ICT-arkkitehti (toimiala) asettavat kehittämishankkeen raamit suhteessa koko Helsingin ja toimialan toiminta-, tieto- ja tietojärjestelmäkokonaisuuteen.

Kokonaiskustannusten arviointi

Hankintatermi, jolla tarkoitetaan tietyn hankinnan (esim. palvelun X sovelluskehitys) kokonaissumman arviointia sopimuskauden loppuun saakka. Vrt. kustannushyötylaskelma. Kokonaiskustannusten arviointi menetelmälaarissa.

Kustannushyötylaskelma

Vertailu hankkeen kaikista rahallisista kustannuksista ja toisaalta aineellisista ja aineettomista hyödyistä, jota käytetään perusteluna hankkeen toteuttamiskelpoisuudesta päätettäessä. Kustannushyötylaskelma menetelmälaarissa.

Käynnistysvaihe

Perinteisen mallin ajanjakso siitä, kun hankkeen ohjaus/johtoryhmä on antanut luvan hankkeen käynnistymiselle siihen kun he päättävät toteutuksen aloittamisesta. Käynnistysvaiheessa laaditaan hankinta-asiakirjat, toteutetaan kilpailutus ja tarkennetaan hankesuunnitelmaa sekä perustetaan hankkeenhallintaympäristöt. Käynnistysvaihe perinteisessä hankemallissa.

Käyttäjä

Henkilö tai ryhmä, joka käyttää yhtä tai useampaa hankkeen tuotosta.

Käyttäjäpalaute

Kehityksen aikana tehtävää jatkuvaa käyttäjäpalautteen keruuta käytetään ketterän hankkeen laadunvarmistusmenetelmänä. Käyttäjäpalautteen keruumenetelmiä ovat esimerkiksi kävijäkyselyt, käyttäjähaastattelut, prototestaus, betatestaus, klassinen käyttäjätestaus ja käyttäjästatistiikkojen keruu. Käyttäjien osallistaminen menetelmälaarissa.

Käyttäjätarina

Käyttäjätarina on tyypillisin vaatimusten kuvaustapa ketterässä kehityksessä. Siinä järjestelmän vaatimus kuvataan käyttäjän näkökulmasta - kuka ominaisuutta tarvitsee, mihin ja miksi. Käyttäjätarinoita hallitaan kehitysjonossa ja kanban-taululla. Löydät käyttäjätarinan määritelmän kehitysjono-sivulta. 

Laadunvarmistus

Riippumaton tarkistus, että tuotokset ovat tarkoituksenmukaisia tai vastaavat vaatimuksia. Laadunvarmistus menetelmälaarissa.

Laajuus

Hankkeen laajuus sisältää useita näkökulmia. Yksi on sisältö. Hankkeen sisällöllisellä laajuudella tarkoitetaan suunniteltujen tuotosten ja niiden vaatimusten kokonaisuutta. Se kuvataan tuotosten ositusmallilla ja siihen liittyvillä vaatimusmäärittelyillä. Toinen laajuusnäkökulma on organisatorinen laajuus. Se kertoo sen, mitkä organisaatiot käyttävät ja ylläpitävät hankkeen tuotoksia. Kolmas laajuusnäkökulma on asiaskunta. Se kertoo ne asiakasryhmät, jotka hankkeen kohteena ovat. Joskus voi tarvita myös ns. geografista laajuusmäärittelyä. Sillä kerrotaan kohdistuuko ratkaisu esim. EU-tasoiselle, valtakunnalliselle, kunnalliselle tai vaikkapa kuntayhteiselle tasolle.

Laatu

Perinteisessä hankemallissa laadulla tarkoitetaan vaatimuksenmukaisuutta, joka todennetaan hyväksyntäkriteerien täyttymisellä. Ketterässä mallissa pääasiallisina laadunvarmistuksen menetelminä käytetään valmiin määritelmää ja jatkuvaa käyttäjätyytyväisyyden mittaamista. Laadunvarmistus menetelmälaarissa.

Muutoshallinta

Menettely, jolla varmistetaan, että kaikki hankkeen tavoitteisiin vaikuttavat muutokset on tunnistettu, arvioitu ja joko hyväksytty, hylätty tai lykätty. Muutoshallinta menetelmälaarissa.

Muutostarve

Muutostarve kuvaa käytännössä tavoitetilan ja nykytilan erotuksen. Se on konkreettisesti visualisoitu muutos verrattuna nykytilaan. Muutostarve käsittää muutokset prosesseihin, tietojärjestelmiin, tietovarantoihin ja teknologioihin.

Muutosvastaava

Henkilö tai ryhmä, jolle ohjausryhmä voi delegoida muutospyyntöjen käsittelyn erikseen sovittavien reunaehtojen puitteissa. Suurista, hankkeen aikatauluun, kokonaiskustannuksiin ja laajuuteen merkittävästi vaikuttavista muutoksista päättää aina johtoryhmä.  Roolit ja vastuut hankkeissa.

MVP

MVP:llä (minimum viable product) tarkoitetaan juuri riittävää määrää (vähimmäismäärä) toiminnallisuutta, jolla palvelu on käytettävissä. Ideana on optimoida panos-hyötysuhdetta keskittyä käyttäjien kannalta oleellisimpiin toiminnallisuuksiin ja jättää pienten käyttäjäryhmien tarvitsemien tai vähän käytettyjen toiminnallisuuksien kehittäminen vähemmälle. MVP perinteisen hankemallin vaatimushallinnassa.

Nykytila ja tavoitetila

Nykytila on ajantasainen kuvaus juuri sillä hetkellä vallitsevaan prosessi/toimintakenttään, tietojärjestelmiin, tietovarantoihin ja teknologioihin. Tavoitetila kuvaa samoista kokonaisuuksista sen, missä tilassa niiden tulee kehityshankkeen tulosten käyttöönottamisen jälkeen olla. Kokeilun tapauksessa kehityshanke ei välttämättä tavoittele käyttöönottoa, mutta tavoitetila silti tulisi olla harkittuna käyttöönotto silmällä pitäen - ellei sitten kyse ole yleisestä tutkimisesta ilman hyötyvisiota. Nykytila ja tavoitetila menetelmälaarissa.

Ohjelma

Tilapäinen, joustava organisaatiorakenne, joka on luotu koordinoimaan, johtamaan ja valvomaan toisiinsa liittyvien hankkeiden ja toimintojen toteutumista. Ohjelman kesto on todennäköisesti useita vuosia.

Omistajuuden ja tuotantoon/käyttöön siirto

Tuotosten omistajuuden siirto palvelusta vastaavalle tapahtuu perinteisessä hankemallissa käyttöönottovaiheen aikana.  Hankkeeseen voi kuulua useampiakin tuotantoon siirtoja (vaiheistettu toimitus). Lopullinen tuotantoon siirto tapahtuu käyttööonottovaiheessa. Käyttöönottovaihe perinteisessä hankemallissa.

Palvelun omistaja

Henkilö, jolla on kokonaisvastuu siitä, että hanke saavuttaa tavoitteensa, ja että se tuottaa suunnitellut hyödyt. Omistaja varmistaa, että hanke keskittyy toiminnan kannalta lisäarvon tuottamiseen ja että sillä on selvä valtuutus. Hän varmistaa myös, että työ, riskit mukaan lukien, on johdettua. Omistaja voi johtoryhmän lisäksi olla myös ohjausryhmän puheenjohtaja. Hän on viime kädessä vastuussa asiakastarpeen määrittelystä ja toteutumisesta. Roolit ja vastuut hankkeissa.

Palvelusta vastaava

Ks. tuoteomistaja.

Palvelutasotavoitteet

Palvelutasotavoitteet (SLT) määrittävät, millaista käytössäoloa, tukea sekä reagointia palvelupyyntö- ja virhetilanteissa palvelulta ja sitä ylläpitävältä organisaatiolta odotetaan. Palvelutasotavoitteet määritellään palvelun kriittisyyden mukaan, ja niiden pohjalta tehdään palvelutasosopimus (SLA).

Perinteinen hankeohjaus

Hankepäällikkövetoinen suunnittelua korostava ohjaustapa. Johto/ohjausryhmä asettaa kokonaistavoitteen. Hankepäällikkö määrittelee tarkat etukäteissuunnitelmat vaiheittain. Vaiheet ovat huomattavasti suurempia ja pidempikestoisia kuin Scrum-ohjauksen sprintit. Sen vuoksi perinteinen ohjaustapa edellyttää vahvaa muutoshallintaa ja tarkemman tason päätöksen tekoa johto/ohjausryhmässä.

Perinteinen malli

Perinteinen malli sopii parhaiten sellaisiin hankkeisiin, joista tiedetään tarve ja haluttu lopputulos hyvällä varmuudella jo ennen toimeksiantoa. Perinteisen mallin tehtävänä on varmistaa, että tavoiteltu lopputuotos saadaan aikaiseksi ennalta määriteltyjen reunaehtojen puitteissa. Itse toteutus voidaan tehdä sekä iteratiivisesti että ns. vesiputouksena. Kyseessä on usein laaja investointihanke, jonka koko ja/tai monimutkaisuus vaatii selkeää hankejohtamista ja raportointia.

Prosessi

Määritelty joukko aktiviteetteja, jotka on suunniteltu tietyn tavoitteen saavuttamiseksi. Prosessi ottaa yhden tai useampia syötteitä, ja muuttaa ne määritellyiksi tuloksiksi.

Prototyyppi

Ketterässä hankkeessa palvelun alfaversio. Yksinkertainen mallinnus tulevasta palvelusta, jolla testataan toisaalta käyttäjätarpeiden täyttyminen ja toisaalta selviytyminen tärkeimmistä teknisistä riskeistä. Prototyypissä ei pyritä julkaisukelpoiseen palveluun, vaan se jää yleensä hyvin pienen testikäyttäjäryhmän piiriin. Alfaversio (prototyyppi) menetelmälaarissa.

Päätöspiste

Ajankohta, jolloin johto/ohjausryhmä tekee hanketta koskevia päätöksiä, esimerkiksi hankinnan käynnistämisestä, hankintapäätöksestä ja toteutuksen hyväksymisestä. Päätöspisteet merkitään suunnitelmiin ”salmiakkeina”.

Rahankäyttöpäätös

Rahankäyttöpäätös tehdään hankkeelle määrärahat myöntäneen viranhaltijan toimesta (esimerkiksi tietohallintopäällikkö). Vasta rahankäyttöpäätös mahdollistaa hankkeelle hankintapäätöksen toimeenpanon. Ilman rahankäyttöpäätöstä hankinnan toimeenpanoa ei ole kohdennettu vuosittaisiin määrärahoihin.

Ratkaisuarkkitehti

Asettaa ja tarkentaa ylätason hankkeen toteutuksen raamit kokonaisarkkitehtuurin linjauksen mukaisesti ja dokumentoi pääasialliset vaihtoehdot kehityshankkeen mahdollisiksi lähtötilanteiksi yhdessä kokonaisarkkitehdin/ICT-arkkitehdin kanssa.

Ratkaisulinjaus

Vaihtoehdoista tehdään johtopäätökset ja valitaan etenemistapa ja ratkaisulinjaus kehityshankkeelle. Ratkaisulinjaus siis karsii vaihtoehdot periaatteessa yhteen kokeiltavaan tai toteutettavaan vaihtoehtoon. Ratkaisulinjaukset menetelmälaarissa.

Reunaehdot

Ratkaisulla on aina ulkoa tulevia reunaehtoja, joihin pitää sopeutua. Tärkeimmät reunaehdot tulevat EU-asetuksista, EU-direktiiveistä ja kansallisista laeista. Kokonaisarkkitehtuurilinjaukset rajaavat valittavia teknologioita, tietovarantoja liittyviä järjestelmiä ja prosessimuutoksia. Toimittajahallinta rajaa toimittajakenttää. Ratkaisulle asetetaan yleensä saatavuus- ja suorituskykyreunaehtoja sekä käytettävyysreunaehtoja esimerkiksi liittyen esteettömyyteen. Reunaehdot menetelmälaarissa.

Riippuvuudet

Hankkeella voi olla ulkoisia tai sisäisiä riippuvuuksia. Ulkoiset riippuvuudet kuvataan tiekartassa. Näitä ovat esimerkiksi riippuvuudet eri asiakassegmentteihin, muihin järjestelmiin ja muihin prosesseihin ja muihin organisaatioihin. Sisäiset riippuvuudet tarkoittavat hankkeen osien tai tehtävien riippuvuutta toisistaan, esim. tuotoksen C tekeminen ei voi alkaa ennen kuin tuotokset A ja B ovat valmiit. Tuotosten välisiä riippuvuuksien kuvaamisessa voidaan käyttää esimerkiksi PERT -menetelmää. Hankepäällikkö kontrolloi sisäisiä riippuvuuksia. Ulkoiset riippuvuudet eivät ole hankepäällikön kontrollissa, esimerkiksi toisesta hankkeesta tarvittavien tuotosten tekeminen. Tiekartta ja riippuvuuskaavio (PERT) menetelmälaarissa.

Riski

Epävarma tapahtuma tai tapahtumien joukko, joka toteutuessaan vaikuttaa hankkeen tavoitteiden saavuttamiseen. Riskiä arvioidaan sekä havaitun uhan tai mahdollisuuden toteutumisen todennäköisyydellä, että vaikutuksen laajuudella tavoitteisiin nähden. Risken hallinta menetelmälaarissa.

Riskienhallinta

Periaatteiden, menettelytapojen ja prosessein systemaattinen käyttö riskejä tunnistettaessa ja arvioitaessa, sekä vastatoimenpiteitä suunniteltaessa ja käyttöönotettaessa. Risken hallinta menetelmälaarissa.

Riskiloki

Kooste tunnistetuista riskeistä ja niiden aiheuttajista, statuksista, riskinhallintatoimenpiteistä ja historiatiedoista. Risken hallinta menetelmälaarissa.

Riskin vaikutus

Tietyn uhan toteutunut tai ennakoitu seuraus. Riskien vaikutusta arvioidaan asteikolla matala/keskinkertainen/korkea. Risken hallinta menetelmälaarissa.

Riskin todennäköisyys

Arvioitu todennäköisyys sille, että kyseinen uhka tai mahdollisuus todella toteutuu sisältäen myös arvion sen yleisyydestä. Risken hallinta menetelmälaarissa.

Salkku, portfolio

Kaikki organisaation, organisaatioryhmän tai organisaatioyksikön toimeenpanemat ohjelmat ja yksittäiset hankkeet.

Scrum

Iteraatiomalli. Kehittäminen palastellaan 1-4 viikon mittaisiin peräkkäisiin minikokonaisuuksiin, eli sprintteihin. Scrum malli edellyttää Kanban-ohjausta enemmän formaalisuutta, kuten kattavan valmiin määritelmän jokaiselle kehitettävälle ominaisuudelle ja toimivalle tuoteversiolle ja kattavat käyttäjätarinat eli käytännössä ominaisuuskuvaukset. Scrum tuo jämäkkyyttä ominaisuuksien määrittelyyn ja rauhoittaa tiimille riittävän pituiset, mutta silti nopeasykliset kehitysjaksot. Tuoteomistajan ja kehittäjätiimin kollaboraatio korostuu. Scrum ja kaikki muutkin ketterät menetelmät edellyttävät riittävää kokonaissuunnittelua. Tarkka vaihesuunnittelu ei kuulu Scrumiin, vaan samaa asiaa hoitaa sprint backlog.

Sidosryhmä

Henkilö, ryhmä tai organisaatio, joka voi vaikuttaa ohjelmaan, hankkeeseen, sen tehtäviin tai riskeihin, tai johon jollain edellä mainituista on tai ao. sidosryhmä kokee olevan vaikutusta. Sidosryhmät menetelmälaarissa.

Suunnitelma

Yksityiskohtainen esitys jonkin tekemiseen tai saavuttamiseen. Se määrittelee mitä, milloin, miten ja kuka. Kehmetissä on seuraavat suunnitelmat: hankesuunnitelma, vaihesuunnitelma (käynnistys- ja käyttöönottovaiheille), toteutussuunnitelma, hyväksyntätestaussuunnitelma, suunnitelma tuotantoon siirtymisestä, suunnitelma käytöstä poistamisesta. 

Tiekartta

Hankkeen tiekartta on niin karkealla tasolla kuvattu hankkeen kulku riippuvuuksineen, että se sopii ohjaus-/johtoryhmän käyttöön sekä kommunikointikeinoksi sidosryhmille. Tiekartta menetelmälaarissa.

Tietosuojan alkukartoitus

Alkukartoitus tulee tehdä aina, kun ryhdytään suunnittelemaan uutta prosessia, järjestelmähankintaa tai järjestelmän rakentamista. Alkukartoituksen kysymyksiin vastaamalla selviää, käsitelläänkö uudessa palvelussa henkilötietoja ollenkaan ja jos käsitellään, tuleeko tehdä tietosuojan vaikutustenarviointi vai ottaa tietosuoja huomioon tietosuojan tarkistuslistan avulla.

Tietosuojan vaikutustenarviointi

Tietosuojan vaikutustenarviointi auttaa tunnistamaan ja hallitsemaan henkilötietojen käsittelystä aiheutuvia riskejä. Vaikutustenarvioinnissa arvioidaan henkilötietojen käsittelyn vaikutuksia henkilötietojen suojalle.

Tietosuojan tarkistuslista

Tietosuojan tarkistuslistaa käytetään siinä tapauksessa, että vaikutustenarviointia ei tarvitse tehdä. Tarkistuslistaan on listattu tietosuojavaatimuksia, jotka on aina otettava huomioon kehittämisessä, vaikka ei käsiteltäisi erityisen arkaluonteista tai muutoin riskialtista henkilötietoa.

Tietosuoja- ja salassapitoliite

Henkilötietojen käsittelystä on sovittava silloin, kun joku muu, esimerkiksi palveluntuottaja, käsittelee henkilötietoja kaupungin puolesta. Lähtökohtaisesti sopimisessa käytetään kaupungin tietosuoja- ja salassapitoliitettä, joka sisällytetään sopimuksiin. 

Tietoturva-asiantuntija

Määrittelee ja tarvittaessa dokumentoi tarvittavan tietoturvallisuuden tason sekä jatkuvuustarpeen käymällä läpi kohdealueeseen liittyvää lainsäädäntöä, käytäntöjä, prosesseja sekä niissä liikkuvia tietoja.

Tietoturvan riskianalyysi

Tietoturvan riskianalyysiä tehdään siksi, että olennaisimpiin toimintaan tai järjestelmään kohdistuviin tietoturvaan kohdistuviin uhkiin löydetään kehityksen aikana sopiva hallintakeino. Tietoturvan riskianalyysi menetelmälaarissa.

Tilaaja

Tilaaja tarkoittaa käytännössä samaa asiaa kuin hankintayksikkö, mutta viittaa kyseisestä hankinnasta vastuulliseen viranhaltijaan (esimerkiksi hankintajohtaja).

Toimittaja

Toimittaja on hankinnan toimittava osapuoli eli se yritys, yhteisö tai taho joka toimittaa hankinnan kohteen mukaisen tuotteen tai palvelun.

Tuoteomistaja (palvelusta vastaava)

Tuoteomistaja toimii palvelun omistajan ohjauksessa ja huolehtii siitä, että käyttäjien tarpeet on määritelty oikein, lopputulos on näiden vaatimusten mukainen ja tuotantokäytössä täyttyy palvelulta odotettu palvelutaso. Tuoteomistaja priorisoi tuotteen kehitysjonoa ketterässä hankkeessa suoraan.

Tuotos

Hankkeen tuotoksia ovat varsinaiset tuotokset, jotka toimitetaan asiakkaille/käyttäjille. Näiden lisäksi hankkeessa tuotetaan hankehalllinnan tuotoksia. Varsinainen tuotos voidaan kuvata etukäteen, toteuttaa ja testata.

Vaihtoehdot

Kehityshanketta ei tulisi edes kokeilun osalta käynnistää pidemmälle ilman, että erilaisia vaihtoehtoja olisi punnittu. Vaihtoehtojen punnitseminen edellyttää usein markkina-analyysiä, teknologiavaihtoehtojen tarkastelua sekä nykytilan ja tavoitetilan karkeaa määrittelyä. Kokeilun tapauksessa vaihtoehtotarkastelun tulisi kuitenkin olla lähinnä sen tunnistamista, mitä kannattaisi lähteä kokeilemaan. Tähän liittyen suoritetaan riittävä määrä erilaisia kokeiluja. Liian jäykkä ja raskas vaihtoehtotarkastelu voi tehdä kokeilut tarpeettomiksi. Vaihtoehtojen tunnistaminen menetelmälaarissa. Vaihtoehtotarkastelu menetelmälaarissa.

Valmiin määritelmä

Valmiin määritelmä (Definition of Done) kertoo ne laatuvaatimukset, jotka jokaisen toteutettavan järjestelmän osan (ominaisuuden tai julkaistavan tuoteinkrementin) tulee täyttää, ennen kuin se voidaan hyväksyä valmiiksi. Se on ketterän toteutuksen tärkein laadunhallinnan väline. Valmiin määritelmä menetelmälaarissa.

Valmisteluvaihe

Perinteisen mallin ajanjakso siitä, kun hankkeen valmistelulle on annettu lupa (hanketoimeksiannon muistio) siihen kun johtoryhmä on hyväksynyt hankintamallin ja ratkaisun linjaukset ja antanut luvan aloittaa hankinnan valmistelu. Valmisteluvaihe perinteisen mallin kuvauksessa.

Vesiputous

Vesiputous on lineaarinen ja vaiheesta toiseen etenevä menetelmä, jossa jokaisella kehittämisvaiheella on selvät tavoitteet ja ne seuraavat toisiaan etukäteen määritellyllä tavalla. Vesiputousmalli edellyttää koko hankkeen tarkkaa etukäteissuunnittelua ja ennustamista. Kehmet ei sisällä vesiputousmallia suoraan, koska vesiputousmalli harvoin soveltuu tietojärjestelmähankkeisiin. Kehmetin perinteistä hankemallia voi kuitenkin käyttää myös vesiputousmaisesti, jos se on tarpeen. Kehmetin perinteinen malli kuitenkin korostaa suunnittelun ja toteutuksen iteratiivisuutta ja toiminnan jatkuvaa parantamista jo hankkeen aikana.

Viestintäsuunnitelma

Viestintäsuunnitelmassa kuvataan, miten ja kuinka usein viestitään hankkeen ja sidosryhmien välillä.  Viestintäsuunnitelma on osa hankesuunnitelmaa.

Viranhaltija

Kunnallisesta viranhaltijasta annetussa laissa viranhaltijalla tarkoitetaan henkilöä, joka on virkasuhteessa kuntaan. Kuntalain mukaan tehtävää, jossa käytetään julkista valtaa, hoidetaan virkasuhteessa.

Visio

Kehittämishankkeella on oltava jokin visio, jota lähdetään tutkimaan ja toteuttamaan. Kehityshanketta ei yleensä ole tarkoituksenmukaista käynnistää ilman jonkinlaista visiota tai näkemystä siitä, mitä olisi tarkoitus lähteä tutkimaan, kokeilemaan tai toteuttamaan.

Visiolakana

Visiolakanalla kiteytetään selvityksen tai valmistelun aikana hankkeen visio. Visiolakana konkretisoi yhteen kuvaan visiosta tulkitun tarpeen ja ratkaisulinjauksen ja sen ainutlaatuisen arvoin, minkä vuoksi hanke kannattaa tehdä. Visiolakana konkretisoi asiakkaan, eli kenelle ratkaisua tehdään, sekä kertoo, miten käyttäjien palaute otetaan huomioon. Visiolakana myös listaa lyhyesti rajoittavat tekijät ja miten onnistumista mitataan. Visiolakana menetelmälaarissa.