Kuinka kirjoittaa projektin ongelmanmäärittely + esimerkkejä
Määritelmä: Ongelmanmäärittely kuvaa selkeästi projektin nykytilan ja tavoitellun lopputuloksen välisen kuilun.
Fokus: Ongelmanmäärittelyn laatiminen pitää projektit keskittyneinä, ehkäisee tavoitteiden ja laajuuden hallitsematonta kasvua sekä tukee päätöksentekoa.
Osat: Ongelmanmäärittelyn keskeisiä osia ovat ongelman kuvaus, konteksti, vaikutukset ja tavoitteet.
Vertailu: Ongelmanmäärittelyt eroavat projektien perustamiskirjoista, liiketoimintaperusteluista, hypoteeseista ja projektien laajuuden määrittelyistä.
Virheet: Vältä monimutkaisuutta, epämääräisyyttä, ennenaikaisia ratkaisuja, sidosryhmien sivuuttamista sekä oireiden sekoittamista syihin.
Projektin ongelman määrittely kuvaa nykytilan ja toivotun lopputuloksen välisen kuilun, jotta tiimin jäsenet voivat päästä yhteisymmärrykseen ennen kuin ratkaisut, budjetit ja aikataulut alkavat ohjata keskustelua. Olen nähnyt projektien menettävän viikkoja, koska sidosryhmät ratkoivat saman ongelman eri versioita tai ohjasivat sanamuotoa kohti ennalta valittua ratkaisua.
Tämä opas auttaa sinua kirjoittamaan kohdennetun ja näyttöön perustuvan määrittelyn, välttämään yleisiä sudenkuoppia, käyttämään käytännöllistä mallipohjaa ja tarkastelemaan vahvoja esimerkkejä todellisista projektikonteksteista.
Mikä on projektin ongelman määrittely?
Ongelman määrittely on selkeä ja tiivis kuvaus ongelmasta, johon projektisi pyrkii vastaamaan. Siinä nimetään tietty kuilu, kipukohta tai täyttämätön tarve ja selitetään, miksi sillä on merkitystä. Ajattele sitä ”miksi”-perusteluna kaiken sen takana, mitä projektisi tulee tekemään.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Hyvä ongelman määrittely auttaa tiimiäsi muodostamaan yhteisen käsityksen ongelmasta. Se määrittää työsi rajat, perustelee pyytämäsi resurssit ja antaa sidosryhmille syyn välittää asiasta.
Vahvalla ongelman määrittelyllä on muutamia keskeisiä ominaisuuksia:
- Täsmällinen: Siinä nimetään tarkka ongelma, ei epämääräistä ongelmien kategoriaa.
- Mitattava: Siinä viitataan mahdollisuuksien mukaan tietoihin, mittareihin tai havaittaviin tuloksiin.
- Kontekstuaalinen: Siinä selitetään, missä ja milloin ongelma ilmenee.
- Ratkaisuneutraali: Siinä kuvataan ongelma määräämättä, miten se pitäisi ratkaista.
- Sidosryhmät huomioiva: Siinä tunnistetaan, keihin ongelma vaikuttaa ja miten.
Miksi projektin ongelma kannattaa määritellä?
Tässä on muutamia keskeisiä syitä siihen, miksi projektille kannattaa kirjoittaa ongelman määrittely:
- Se pitää projektityön kohdennettuna: Ongelman määrittely toimii koko projektin ohjenuorana. Kun pyyntöjä tulee, voit palata määrittelyyn ja kysyä, auttaako kyseinen asia ratkaisemaan ongelman. Tämä ehkäisee projektin laajenemista hallitsemattomasti, terävöittää päätöksentekoa ja luo selkeän vastuunjaon. Projektit, joille ei ole laadittu kirjallista ongelman määrittelyä, jäävät todennäköisemmin jumiin.
- Se jäsentää tutkimusta ja innovointia: Ongelman määrittely määrittää tutkittavan kysymyksen, ohjaa menetelmiäsi ja auttaa muodostamaan testattavia hypoteeseja. Se myös perustaa ideoinnin käyttäjien kipukohtiin abstraktien ajatusten sijaan. Olen nähnyt tiimien tuottavan huomattavasti parempia ratkaisuja, kun ne käyttävät ensin enemmän aikaa ongelman määrittelyyn.
- Se vahvistaa sidosryhmien luottamusta: Sidosryhmät haluavat tietää, että heidän investointinsa kohdistuu johonkin todelliseen. Ongelman määrittely antaa heille läpinäkyvyyttä ja yhteisen ymmärryksen. Hyväksynnän saaminen helpottuu, koska arvioijat näkevät ongelman, sen vaikutukset ja kiireellisyyden. Se myös määrittää onnistumisen kriteerit heti alussa.
Ongelman määrittelyn keskeiset osat
Jokainen vahva ongelman määrittely kattaa nämä neljä osa-aluetta:
Ongelman kuvaus
Tämä on määrittelysi ydin. Nimeä se, mitä tapahtuu tai mitä pitäisi tapahtua mutta ei tapahdu. Ole suora ja täsmällinen. ”Asiakkaiden käyttöönotto kestää liian kauan” on alku, mutta ”Uudet yritysasiakkaat odottavat käyttöönoton valmistumista keskimäärin 23 päivää, kun alan vertailuarvo on 10 päivää” on paljon parempi.
Tausta ja konteksti
Selitä, miksi tämä ongelma on olemassa ja millaiset olosuhteet ympäröivät sitä. Tarjoa taustatiedot, joita lukija tarvitsee tilanteen ymmärtämiseen. Sisällytä historia, ympäristötekijät tai organisaation rajoitteet. Esimerkiksi käyttöönoton viive voi johtua siitä, että prosessi perustuu edelleen manuaaliseen tietojen syöttämiseen eri järjestelmissä, joita ei ole yhdistetty toisiinsa.
Vaikutukset ja merkitys
Tunnista, keihin ongelma vaikuttaa ja mitä tapahtuu, jos ongelman annetaan jatkua ilman toimenpiteitä. Määritä seuraukset määrällisesti aina kun mahdollista.
Menetetyt tulot, hukkaan heitetyt työtunnit, laskevat asiakastyytyväisyyspisteet ja myöhästyneet määräajat ovat kaikki mitattavia vaikutuksia. Tämä osio vastaa kysymykseen, jonka jokainen sidosryhmä esittää: ”Miksi tämän pitäisi kiinnostaa meitä juuri nyt?”
Tavoitteet tai ehdotettu suunta
Kuvaa ihanteellinen tuleva tila. Miltä onnistuminen näyttää, kun ongelma on ratkaistu? Tämä ei ole täydellinen ratkaisu, vaan suuntaa osoittava lausuma, joka kertoo lukijoille, mihin olet menossa.
Käyttöönottoesimerkissä tavoitteena voisi olla ”lyhentää käyttöönoton keskimääräinen kesto enintään 10 päivään kuuden kuukauden kuluessa”. Se antaa projektille tavoitteen määrittelemättä tarkkaa toteutustapaa.
Näin kirjoitat projektin ongelman määrittelyn
Seuraavassa vaiheittaisessa prosessissa kuvataan, kuinka tehokas ongelmanmäärittely laaditaan alusta alkaen.
1. Tunnista ja kuvaile ongelma
Aloita havainnoimalla. Kerää tietoja, käy läpi asiakaspalautetta, keskustele asiakasrajapinnassa työskentelevien työntekijöiden kanssa ja haastattele sidosryhmiä. Tavoitteesi on nimetä ongelma konkreettisin termein, ei arvailla sitä kokoushuoneessa. Parhaat ongelmanmäärittelyt tulevat ihmisiltä, jotka ovat lähimpänä ongelmaa.
2. Esitä oikeat kysymykset
Kun olet tunnistanut ongelman, testaa sitä kriittisesti kohdennettujen kysymysten avulla:
- Keneen tämä ongelma vaikuttaa?
- Missä ja milloin se ilmenee?
- Mikä on nykytilan ja tavoitetilan välinen kuilu?
- Miksi asialla on merkitystä juuri nyt?
Nämä kysymykset pakottavat sinut siirtymään yleisestä valituksesta täsmälliseen kuvaukseen. Jos et pysty vastaamaan niihin selkeästi, tarvitset lisää tietoa ennen kuin kirjoitat mitään.
3. Analysoi ongelma perusteellisesti
Hyödynnä juurisyyanalyysin menetelmiä ymmärtääksesi, mikä ongelmaa todellisuudessa aiheuttaa. Viiden miksi-kysymyksen menetelmä toimii tässä hyvin.
Otetaan aiempi asiakkuuden aloitusta koskeva esimerkki. Aloitat oireesta ja kysyt jatkuvasti miksi:
- Miksi asiakkuuden aloitus kestää 23 päivää? Koska asiakastiedot on syötettävä kolmeen erilliseen järjestelmään.
- Miksi siihen tarvitaan kolme erillistä järjestelmää? Koska CRM-järjestelmä, laskutusalusta ja käyttöönottotyökalu hankittiin itsenäisesti eikä niitä koskaan integroitu.
- Miksi niitä ei koskaan integroitu? Koska kukin osasto valitsi oman työkalunsa omien vaatimustensa perusteella.
- Miksi osastot valitsivat työkalut itsenäisesti? Koska teknologiahankintoja ei valvottu toiminnallisesti eri osastot yhdistävällä tavalla.
- Miksi tällaista eri osastot yhdistävää valvontaa ei ollut? Koska yritys kasvoi nopeammin kuin sen hallintoprosessit.
Viidenteen kysymykseen mennessä olet siirtynyt ongelmasta ”asiakkuuden aloitus kestää liian kauan” rakenteelliseen hallintaongelmaan. Tämä muuttaa suunnittelemasi projektin luonnetta. Ongelmanmäärittelyssäsi voidaan nyt viitata ongelman juurisyyhyn eikä vain oireeseen, mikä tekee siitä paljon hyödyllisemmän.
4. Laadi ongelmanmäärittely
Käytä tätä mallia lähtökohtana:
[Sidosryhmäryhmä] kohtaa [ongelman] [asiayhteydessä], mikä johtaa [vaikutukseen]. Tämän projektin tavoitteena on [tavoite].
Esimerkiksi: ”Uudet yritysasiakkaat käyvät läpi keskimäärin 23 päivää kestävän asiakkuuden aloituksen kolmessa toisistaan erillisessä järjestelmässä, minkä seurauksena 40 % asiakkaista keskeyttää ennen täyttä aktivointia. Tämän projektin tavoitteena on lyhentää asiakkuuden aloitus enintään 10 päivään kuuden kuukauden kuluessa.”
Ensimmäisen luonnoksen ei tarvitse olla täydellinen. Keskity ongelman, asiayhteyden, vaikutuksen ja tavoitteen tallentamiseen. Poista sen jälkeen kaikki, mikä ei ansaitse paikkaansa.
5. Tarkista ja viimeistele
Lue luonnos ääneen. Tarkista sen selkeys, ytimekkyys ja täsmällisyys. Poista kaikki ammattikieli, jota tiimisi ulkopuolinen henkilö ei ymmärtäisi. Varmista, että ongelmanmäärittely pysyy ratkaisusta riippumattomana. Jos siinä sanotaan ”meidän on otettava käyttöön X”, kyseessä on ratkaisu, ei ongelma. Palauta se takaisin itse ongelmaan.
6. Vahvista sidosryhmien kanssa
Jaa luonnos niiden ihmisten kanssa, jotka ovat lähimpänä ongelmaa, sekä niiden kanssa, jotka rahoittavat tai hyväksyvät hankkeen. Hyödynnä heidän palautteensa ennen viimeistelyä.
Tämä vaihe kuulostaa yksinkertaiselta, mutta juuri tässä useimmat ongelmanmäärittelyt joko vahvistuvat tai romahtavat. Näin voit käsitellä kaksi yleistä ongelmaa:
- Kaksi sidosryhmää on eri mieltä ongelmasta: Älä sorru yhdistämään näkökulmia yhdeksi epämääräiseksi määrittelyksi. Käsittele erimielisyyttä merkkinä siitä, että tarvitset lisää tietoa. Usein molemmat osapuolet kuvailevat syvemmän ongelman oireita, eivätkä kumpikaan ole vielä täysin sanoittanut sitä. Palaa viiden miksi-kysymyksen menetelmään.
- Johto haluaa määrittelyn oikeuttavan heidän ratkaisunsa: Tehokkain tapa, jonka olen löytänyt, on kysyä: "Minkä näytön pitäisi pitää paikkansa, jotta kyseinen ratkaisu olisi oikea?" Muotoile määrittely tämän näytön ympärille. Jos näyttöä on olemassa, määrittely ohjaa heidän ratkaisuunsa. Jos sitä ei ole, keskustelkaa oletuksista.
Validointi ei tarkoita hyväksynnän ja yksimielisyyden saavuttamista hinnalla millä hyvänsä. Se tarkoittaa sen varmistamista, että määrittely on täsmällinen eikä vain mukavalta tuntuva.
Esimerkkejä hankkeiden ongelmanmäärittelyistä
Tässä on viisi esimerkkiä eri toimialoilta. Huomaa, miten jokaisessa näytön esittämistapaa ja näkökulman rajausta mukautetaan toimialan vaatimuksiin.
IT ja ohjelmistokehitys
Esimerkki ongelmanmäärittelystä: Asiakastukihenkilöt käyttävät tällä hetkellä kolmea erillistä työkalua yhden tukipyynnön ratkaisemiseen, minkä seurauksena yhden pyynnön keskimääräinen käsittelyaika on 14 minuuttia. Alan keskiarvo on 7 minuuttia. Tämän hankkeen tavoitteena on lyhentää käsittelyaikaa yhdistämällä tukiprosessit yhdeksi alustaksi.
Tällaiset ongelmanmäärittelyt ovat tyypillisiä IT-alalla. Niissä hyödynnetään toiminnallisia mittareita ja vertailutietoja. Ketterä tiimi voisi tiivistää tämän vielä yhdeksi lauseeksi sprintin tavoitteeksi.
Terveydenhuolto ja kansanterveys
Esimerkki ongelmanmäärittelystä: Kolmen piirikunnan alueen maaseudulla asuvat potilaat matkustavat keskimäärin 45 mailia päästäkseen erikoissairaanhoitoon, minkä seurauksena seurantakäyntien väliin jättämisen osuus on 38 %. Tämän hankkeen tavoitteena on pienentää osuus alle 15 prosenttiin laajentamalla etävastaanottojen saatavuutta.
Terveydenhuollon ongelmanmäärittelyjen on täytettävä sääntelyviranomaisten arvioijien ja apurahalautakuntien vaatimukset. Jos kyseessä olisi apurahahakemus, lisäisit viittauksia julkaistuun tutkimukseen liikenteen esteistä ja terveysvaikutuksista.
Koulutus
Esimerkki ongelmanmäärittelystä: Yliopiston ensimmäisen sukupolven korkeakouluopiskelijat keskeyttävät opintonsa 22 % useammin kuin muut opiskelijat, useimmiten toisen lukukauden aikana. Tämän opiskelijaryhmän yhteydenotot opinto-ohjaukseen ovat keskimäärin 0,8 tapaamista lukukaudessa, kun taas korkeakoulutettujen vanhempien lapsilla vastaava luku on 2,4. Tämän hankkeen tavoitteena on kaventaa ohjauksen saatavuudessa olevaa eroa ja parantaa opintojen jatkamista toisella lukukaudella.
Koulutusalan määrittelyt hyötyvät eritellystä tiedosta. Kun nimetään tietty väestöryhmä ja tietty lukukausi, ongelmaan voidaan myös puuttua käytännössä.
Liiketoiminnan operatiivinen toiminta ja prosessien kehittäminen
Esimerkki ongelmanmäärittelystä: Kuukausittainen taloushallinnon tilinpäätösprosessi vie kirjanpitotiimiltä keskimäärin 12 työpäivää ja kuluttaa yli 400 henkilötyötuntia sykliä kohden. Täsmäytyksen aikana löydetyt virheet muodostavat 35 % tästä ajasta. Tämän hankkeen tavoitteena on lyhentää tilinpäätössykli seitsemään työpäivään puuttumalla virheiden perimmäisiin syihin.
Yhteisöt ja voittoa tavoittelemattomat organisaatiot
Esimerkki ongelmanmäärittelystä: Keskustan alueen ruokaturvattomilla kotitalouksilla on kahden mailin säteellä käytettävissään vain yksi ruokakauppa, ja 60 % asukkaista ei pysty liikkumaan omalla kuljetuksella. Hätäruoka-avun käyttö on kasvanut 40 % edellisvuodesta. Tämän hankkeen tavoitteena on laajentaa ruoan jakelua ja lyhentää matkaa tuoreiden elintarvikkeiden lähteille.
Voittoa tavoittelemattomien organisaatioiden ongelmanmäärittelyt toimivat usein myös varainhankinnan perusteluina. Tässä esitetyt tiedot on valittu luomaan kiireellisyyden tuntua. Yrityksen operatiivinen tiimi ei ehkä mainitsisi kuljetusta lainkaan, mutta yhteisön rahoittajalle tämä yksityiskohta tekee ongelmasta konkreettisen ja perustelee investoinnin.
Ongelmanmäärittely verrattuna muihin hankedokumentteihin
Ongelmanmäärittely sekoitetaan usein muihin hankedokumentteihin. Näin ne eroavat toisistaan.
| Asiakirja | Tarkoitus | Keskeinen ero ongelman kuvaukseen |
|---|---|---|
| Ongelman kuvaus | Määrittelee projektin ratkaistavan erityisen ongelman | Keskittyy yksinomaan ongelmaan ja sen vaikutuksiin |
| Projektin perustamiskirja | Valtuuttaa projektin ja määrittelee laajuuden, välitavoitteet ja budjetin | Laajempi asiakirja; ongelman kuvaus toimii sen lähtökohtana |
| Liiketoimintaperustelu | Perustelee investoinnin vertaamalla kustannuksia ja hyötyjä | Keskittyy taloudellisiin ja strategisiin perusteluihin |
| Hypoteesi | Esittää testattavan selityksen tai ennusteen | Tarjoaa mahdollisen vastauksen; ongelman kuvaus määrittelee kysymyksen |
| Projektin laajuus | Määrittelee tehtävän työn rajat | Kuvaa, mitä tehdään; ongelman kuvaus kertoo, miksi se tehdään |
Ongelman kuvaus vs. projektin perustamiskirja
Ongelman kuvaus toimii projektin perustamiskirjan lähtökohtana, mutta perustamiskirja on laajempi asiakirja. Perustamiskirja sisältää projektin laajuuden, välitavoitteet, budjetin, keskeiset sidosryhmät ja onnistumiskriteerit.
Ongelman kuvaus tarjoaa ”miksi”-perustelun, joka antaa lähtökohdan kaikille näille muille osa-alueille. Kirjoita ongelman kuvaus ensin ja käytä sitä sitten perustamiskirjan perustana.
Ongelman kuvaus vs. liiketoimintaperustelu
Liiketoimintaperustelu oikeuttaa investoinnin. Siinä verrataan kustannuksia, hyötyjä, riskejä ja vaihtoehtoja taloudellisen tai strategisen perustelun muodostamiseksi. Ongelman kuvaus määrittelee kipupisteen, jonka pohjalle liiketoimintaperustelu rakentuu.
Jos et pysty kuvailemaan ongelmaa, liiketoimintaperustelultasi puuttuu vakuuttava perusta. Kirjoita ongelman kuvaus ennen liiketoimintaperustelun laatimista.
Ongelman kuvaus vs. hypoteesi
Hypoteesi esittää testattavan vastauksen kysymykseen. Ongelman kuvaus määrittelee itse kysymyksen. Tutkimusprojekteissa kirjoitat ensin ongelman kuvauksen ja johdat siitä sitten yhden tai useamman hypoteesin.
Nämä kaksi toimivat yhdessä, mutta palvelevat eri tarkoituksia. Niiden sekoittaminen johtaa ongelman kuvauksiin, joissa tehdään johtopäätöksiä ennen kuin tutkimus on edes alkanut.
Ongelman kuvaus vs. projektin laajuus
Projektin laajuus määrittelee sen työn rajat, jonka tiimisi toimittaa. Se vastaa kysymykseen ”mitä teemme ja mitä emme tee?” Ongelman kuvaus vastaa kysymykseen ”miksi tällä työllä on merkitystä?” Ilman ongelman kuvausta laajuus voi vaikuttaa mielivaltaiselta.
Ilman laajuutta ongelman kuvaus voi vaikuttaa rajattomalta. Tarvitset molemmat, ja ongelman kuvauksen tulisi olla ensimmäinen.
Yleiset virheet, joita tulee välttää ongelman kuvauksia kirjoitettaessa
Seuraavassa on yleisiä sudenkuoppia, joita tulee välttää ongelman kuvausta laadittaessa:
- Kuvauksen tekeminen liian monimutkaiseksi: Vastusta kiusausta ahtaa kaikki asiaan liittyvät ongelmat yhteen kuvaukseen. Jos ongelman kuvauksesi tarvitsee sanaston, se on liian monimutkainen. Keskity yhteen tiettyyn ongelmaan. Käytä kieltä, jonka kuka tahansa ymmärtää ensimmäisellä lukukerralla.
- Liian epämääräinen tai laaja kuvaus: ”Asiakkaamme ovat tyytymättömiä” ei anna kenellekään riittävästi tietoa toimia. Hyödyllinen ongelman kuvaus määrittelee, keihin ongelma vaikuttaa, mikä ongelma on, missä ja milloin se ilmenee sekä millainen kuilu on kyseessä.
- Mahdollisten ratkaisujen esittäminen liian aikaisin: Usein ratkaisu ei päädy kuvaukseen vahingossa. Joku auktoriteettiasemassa oleva henkilö on jo päättänyt, mitä hän haluaa rakennettavan tai ostettavan, ja kuvaus laaditaan jälkikäteen tämän perustelemiseksi.
- Sidosryhmävaikutusten laiminlyönti: Ongelman kuvaus, jossa ei mainita, keihin ongelma vaikuttaa, tuntuu abstraktilta. Tunnista aina ongelmaa kokevat ihmiset tai ryhmät ja kuvaile seuraukset heille.
- Validoinnin ohittaminen: Ongelman kuvauksen kirjoittaminen yksin on riskialtista. Ongelmaa lähimpänä olevat ihmiset huomaavat asioita, jotka sinulta jäävät huomaamatta. Projektin hyväksyvät henkilöt haluavat nähdä oman näkökulmansa huomioituna. Jaa luonnoksesi varhain, pyydä palautetta ja muokkaa sitä.
- Oireiden sekoittaminen syihin: Oireet ovat asioita, jotka huomaat ensimmäisenä. Perimmäiset syyt aiheuttavat ne. ”Henkilöstön vaihtuvuus on suurta” on oire. ”Uudet työntekijät eivät saa jäsenneltyä perehdytystä, mikä johtaa sitoutumisen heikkenemiseen 90 päivän kuluessa” on lähempänä perimmäistä syytä. Jos ongelman kuvauksessa mainitaan vain oireet, käsittelet todennäköisesti väärää asiaa.
Mitä seuraavaksi?
Vahvimmat projektit alkavat selkeästä ajattelusta, käytännön työkaluista ja hyväksi havaituista viitekehyksistä. Rekisteröi ilmainen DPM-jäsentili ja saat käyttöösi malleja, resursseja ja asiantuntijoiden näkemyksiä, joiden avulla johdat projekteja luottavaisin mielin.
