Suurempien projektien osalta suosittelen Vaatimusten jäljitettävyysmatriisin luomista. Lisätietoja täältä:

Vaatimusten jäljitettävyysmatriisi projektinhallinnassa (esimerkki + malli)

Prosessi # 2: Kuinka purkaa vaatimukset ja määritellä laajuus

Tässä on vaatimus :

”pmbasics101.com-verkkosivustolla pitäisi olla mahdollisuus kerätä sähköposteja ja lähettää vastineeksi PDF-asiakirja.”

Mitä tarvitaan tämän vaatimuksen täyttämiseen?

1. Valitse postituspalvelun tarjoaja.
2. Luo tili.
3. Suunnittele lomake sähköpostien keräämiseksi.
4. Ota suunniteltu lomake käyttöön.
5. Asenna laajennus postituspalvelun tarjoajalta.
6. Lataa PDF-dokumentti.
7. Aktivoi lomake.
8. Testaa lomake.

Se on vain luettelo vaadituista toimista. Jos laitan sen oikein toimitettavaksi ja työpaketiksi, se päätyisi:

1. sähköpostin valintaan -muodossa
   1.1-raportti postituspalvelun tarjoajista – 1.2 Hyväksytty lomakkeen suunnittelu
   1.3 Valinnainen lomake testausympäristössä
   1.4-testausraportti

Joten, miten pääset tuosta yhden lauseen vaatimuksesta työn todelliseen laajuuteen?

A) Voit löytää jonkun, jolla on merkityksellistä kokemusta tai tietoa

Se voi olla sidosryhmiä, asiakkaita tai ulkopuolisia konsultit, aihe-asiantuntijat tai muut osapuolet.

Joten, tavoitteesi on hankkia heidät projektitiimiltä tai vain ottaa yhteyttä kommunikoida. Heillä voi olla jo ratkaisu.

Muussa tapauksessa saat ohjeita tai neuvoja. Se on perustekniikka, jota käytät laajasti.

B) Suorita tuoteanalyysi

Sitä voidaan käyttää, kun sinun on luotava tuote palvelun tai tuloksen sijaan.

Tämä tekniikka keskittyy tuotteen arvon hajoamiseen. Aivan kuten WBS tekee laajuuden kanssa.

Lisäksi sinun on analysoitava tuotetta ergonomisista ja toiminnallisista näkökulmista; ja tee sitten päätöksiä materiaaleista tai prosesseista, jotka täyttävät suorituskykyvaatimukset.

25 Esimerkkejä tuoteanalyysista

Kaiken kaikkiaan tavoitteesi on määritellä konkreettisia suoritteita.

C) Käytä vaihtoehtojen luontitekniikkaa

Tämä tekniikka toimii hyvin, kun sinulla on asiantuntemusta projektin luonteesta.

Joten sinun on löydettävä paras ratkaisu täyttävät vaatimukset. Useimmissa tapauksissa käytät aivoriihiä saadaksesi vaihtoehtoja.

Mikä on tavoite?

Sinun on määriteltävä selvästi, mikä on ja mikä ei kuulu projektin laajuuteen.

Prosessi # 3: Projektin laajuuden hallinta PM-ohjelmistolla

Voit varmasti seurata projektin laajuutta missä tahansa käytettävissä olevassa sovelluksessa. Esimerkiksi Google Drive, Evernote tai MS Word tekevät.

Integroidun projektinhallintaohjelmiston käytöstä on kuitenkin vakavia etuja pitämään kaikki yhdessä paikassa.

Ihannetapauksessa täytyy pystyä linkittämään vaatimukset projektin suoritteisiin.

Sitten suoritteista tiettyihin tehtäviin arvioilla, niihin liittyvillä riskeillä ja puutteilla.

Voin esimerkiksi suositella Paymoa. Se on yksi parhaista sovelluksista henkilökohtaiseen käyttöön ja pieniin projekteihin. Lisäksi sillä on erinomaiset ajanseuranta- ja laskutusominaisuudet.

Prosessi # 4: Projektin laajuuden hallinta

Ei riitä tunnistamaan 100% projektin laajuudesta alussa . Se 100% muuttuu projektin elinkaaren aikana.

Tarvitset siis tavan seurata, hallita ja tehdä muutoksia laajuuteen.

Paranna on hyvin tiedossa. Se on työn erittelyrakenne.

No, tarvitset myös selkeän työnkulun muutosten tekemiseksi kaikille projektin alueille aina, kun työn määrä muuttuu.

Kyse on kuitenkin integroidusta muutoksenhallintaprosessista.

Joten mikä on saalis?

Tarvitset korkealaatuisen WBS: n. Lisäksi tarvitset ei-nerdy-tavan kuvata projektin laajuutta. Siksi tarvitset myös projektilaajennusselvityksen. Keskustelemme siitä alla.

Jos olet ketterässä projektissa, selkeästi määritelty lisäyksen tai iteraation laajuus on vieläkin tärkeämpää. Älä ajattele, että ketterä pelastaa sinut tekemisen perusteellisesta dokumentoinnista. Pidä Sprint Backlog ja Käyttäjätarinat siistinä. Käytä yksinkertaista sääntöä: ”Uuden tulijan on ymmärrettävä, mitä on tehtävä Käyttäjän tarinan kuvauksesta.”

Laajuuden vahvistaminen

Joskus sinun on hankittava virallinen allekirjoittaa, että suoritus täyttää sidosryhmien odotukset.

On tärkeää tehdä se jatkuvasti koko projektin ajan.Vaikka johtaisit suunnitelmapohjaista projektia, mikään ei estä sinua toimittamasta tuotekohtaisia lisäyksiä tarkistettavaksi.

Miksi tarvitset tätä?

Et halua saada kaikkia muutospyynnöt, kaikki virheet ja ”pienet muutokset projektiin” lopulta.

Vetät itseltäsi mahdollisuuden integroida muutos todella projektiin.

Mitä lähempänä olet projektin päättämistä, sitä vähemmän aikaa ja resursseja jää jäljelle. Lisäksi sidosryhmät ovat vähemmän alttiita neuvottelemaan muutosten laajuudesta, aikataulusta tai budjetista. Lisäksi ne painostavat tiimiä saat mitä tarvitset.

Pelkkä ilmeisen toteaminen:

On erittäin tärkeää, että projektin laajuus on alusta alkaen selkeästi kuvattu ja hyväksytty.

Kun toimitus ei vastaa odotuksia, korjauksia tapahtuu.

Sinun vastuullasi on todistaa, onko korjaus muutospyyntö ja siksi se tulisi integroida oikein. Muussa tapauksessa se on vika ja sinun on korvattava. Joskus omalla kustannuksellasi.

Kuinka todellakin validoit laajuuden asiakkaiden kanssa?

Missä tahansa projektissa voit käyttää Scrumin kaltaista esittelykokousta.

Vain valmistele lyhyt esitys tuotoksesta. Selitä projektin nykyinen tila ja edistyminen. Tämän jälkeen huomauta tunnetut viat ja keskeneräiset osat.

Kerää myös palautetta asiakkaalta. Myöhemmin voit antaa kaikki käytäntösi edellyttämät tukiasiakirjat ja raportit.

Alarivi:

Kerää palautetta sidosryhmiltä jatkuvasti. Neuvottele uusien muutospyyntöjen käyttöönoton ehdoista. Pidä projektin soveltamisalan lähtötaso ajan tasalla.

Hanki projektin laajuuden hallintamalli

Älä keksi pyörää! Se voi olla kallista sinulle.

Napsauta vain alla olevaa painiketta ja hae tyhjä täytemalli. Sen mukana tulee resurssiopas kaikesta, mitä sinun on tiedettävä laajuuden hallinnasta.

Miksi koko laajuus Perustaso on kriittinen projektillesi?

Yleensä projekti käynnistyy, ja saamme vaatimuksia eri muodoissa.

Esimerkiksi: sähköpostit, PDF-tiedostot, kokoukset, mallit, virheraportit, mikä tahansa .

Ja tietysti emme laadi projektikirjaa tai vastaavaa. Huono käytäntö!

Useimmissa tapauksissa emme edes keskustele projektin liiketoiminnasta.

Luomme yleensä työn erittelyrakenteen.

Sitä käytetään kuitenkin vain sisäisesti eikä koskaan mene asiakkaalle. Sitten hajotamme työn toimintoihin ja arvioimme projektin. Käytämme alhaalta ylöspäin suuntautuvaa arviointitekniikkaa.

Nyt tulee ensimmäinen odotusten tarkistus:

Esitämme arvioita projektille.

Näet, että ilmeisesti on avoimuuden puute tässä. Asiakas ei tiedä, minkä työn arvioimme.

Jos arvio on lähellä asiakkaan odotuksia, hän ei kaivaa yksityiskohtiin. Tämä johtuu siitä, että hän on valmis käyttämään jo niin paljon rahaa ja aikaa. Hän ei halua tuhlata heidän arvokasta aikaa.

Tässä on totuus:

Monet organisaatiot ja projektipäälliköt piilottavat tehottomuudet tällaisten hiljaisten sopimusten takana.

Se on erillisen viestin aihe, mutta se on monien ongelmiesi perimmäinen syy.

Mitä seuraavaksi tapahtuu?

Aloitamme projektin toteuttamisen! Ennemmin tai myöhemmin asiakas pyytää lisäämään uuden teoksen.

Sen jälkeen löydämme osan tuntemattomasta työstä. Myöhemmin ilmenee laatuongelmia. He syövät paljon aikaa.

Kaiken kaikkiaan luovutamme toimituksen saadaksemme selville, että teimme jotain väärin.

Ja silloin asiakas ilmoittaa meille tekevänsä jotain. unohdin jotain ja se on lisättävä heti.

Uskokaa, koette sen useammin kuin kerran.

Scope Baseline Definition

”Scope baseline on hyväksytty versio laajuuslausekkeen, työn erittelyrakenteen (WBS) ja siihen liittyvän WBS-sanakirjan, jota voidaan muuttaa vain muodollisella muutoksenhallintamenettelyllä ja jota käytetään vertailun perustana. ” -PMBOK®-opas

Mikä on Project Scope -lauseke?

Projektin laajuuslausekkeen määritelmä

Projektin laajuuslauseke on tuotteen ja projektin laajuuden kuvaus.

Sitä käytetään kirjallisena vahvistuksena siitä, mitä projektisi tuottaa ja miten.

Mikä on avain arvokkaaseen projektilaajuuslausuntoon?

Mielestäni sinun on käytettävä termejä ja kieltä, jonka kaikki sidosryhmät ymmärtävät. Tämä osa projektin laajuudesta on pääasiassa asiakkaalle.

OK, mitä pitäisi sisällyttää?

Projektin perustelut

Se on lyhyt kuvaus yrityksen tarpeisiin. Joskus yksi lause riittää. Lopun tulee pysyä projektin peruskirjassa.

Tuotteen laajuus

Se on kuvaus tuotamasi tuotteen tai palvelun ominaisuuksista, ominaisuuksista ja toiminnallisuudesta.

Muista, että keräsit vaatimuksia eri sidosryhmiltä. Joten, älä oleta, että ne kaikki pitävät kirjaa jokaisesta vaatimuksesta. Ei ole myöskään aina selvää, kuinka paljon työtä vaaditaan vaatimuksen täyttämiseksi.

Se on ensisijainen paikka sovittaa keskeisten sidosryhmien odotukset.

Sinun on osoitettava määrä ja monimutkaisuus erilaisten vaatimusten täyttämiseksi vaadittavasta työstä. Pistä siis eniten ponnisteluja tähän osioon.

Hyväksymiskriteerit

Ehdot, jotka on täytettävä ennen projektin suoritteiden hyväksymistä.

Voit lisätä hyväksyttävä taso ja vikojen määrä myös tässä.

Suoritettavat tuotteet

Se on kuvaus kaikista projektisi tuottamista tuotoksista.

Se voi sisältää tuotteen tai palvelu, projektidokumentaatio, tuotekäsikirjat, tuotteellesi tarkoitettu opetusmateriaali jne.

Projektin poissulkemiset

Tässä sinun on määritettävä, mikä ei kuulu projektin piiriin.

Melko usein osa sidosryhmistä haluaa jotain erityistä. Toinen osa sidosryhmiä tai asiakas ei tue sitä.

Siksi kyseessä on konfliktitilanne. Kun konflikti on ratkaistu ja päätetty poistaa jotain projektin laajuudesta, laita se tähän.

Ole tarkka ja selkeä siitä. Se säästää aikaa tulevaisuudessa.

Ensinnäkin sinun ei tarvitse tarkistaa näitä projektien poissulkemisia uudelleen. Sidosryhmät voivat yrittää sisällyttää ne myöhemmin projektin toteutuksen aikana.

Ellei jotain dramaattisesti muutu, sinun ei kuitenkaan tarvitse tuhlata aikaa poissulkemisten tarkistamiseen.

Toiseksi, ellei ole selvästi mainittu, joku voi odottaa silti, että toimit sen. Älä syötä vääriä odotuksia. Projektin luovuttaminen on helpompaa lopussa.

Rajoitukset

Kaikki, mikä rajoittaa sinua toimittamaan tuotetta tehokkaasti, on ilmoitettava tässä.

Oletukset

Epävarmuustekijöitä ei voitu selvittää tällä hetkellä.

Jotkut niistä on hyväksyttävä suunnittelun aikana. Jos oletus osoittautuu virheelliseksi, sinulla on oikeus muuttaa projektisuunnitelmaa.

Asiakkaan tulee hyväksyä projektin laajuuslausunto. Itse asiassa se on muodollinen ja molemminpuolinen sopimus.

Siinä todetaan myös, että olet sitoutunut tuottamaan kuvattuja tuloksia tarkalla oletuksella ja selkeillä rajoituksilla. Toisaalta asiakas suostuu hyväksymään määritetyn tuloksen.

Se ei tarkoita, ettemme voi muuttaa projektin laajuutta. Ei. Se tarkoittaa muutoksen tekemistä – meidän on muutettava sopimusta.

Järjestä projektialue WBS: llä

WBS on pakollinen osa kaikkien hankkeiden laajuutta. Suuri tai pieni. Ketterä tai suunnitelmavetoinen.

PM-perusteisiin sisältyy jo täydellinen opas työn erittelyrakenteesta. En toista sitä tässä.

Haluan painottaa vain yhtä ratkaisevaa asiaa:

Project Scope Statementissa kuvattujen toimitettavien tuotteiden tulisi päästä WBS: ään sellaisenaan. Pidä suoritteet yhdenmukaisina koko projektin ajan.

Lisää kaikki tietämäsi WBS-sanakirjaan

WBS-sanakirja on asiakirja, joka kuvaa jokaiselle työpaketille tehtävät työt.

Nykypäivän pääministerinä sanoisin, että sen pitäisi olla osa tehtävänseurantajärjestelmää. Suurin osa projektinhallintaohjelmistosta antaa sinulle mahdollisuuden pitää nämä tiedot yhdessä paikassa.

Siksi en suosittele sinun luomaan erillistä asiakirjaa. WBS-sanakirjan ylläpito on paljon työtä. Etsi integroituja ratkaisuja.

Voit sisällyttää WBS: ään tietoja, jotka määrittävät osan. Esimerkiksi WBS-sanakirja voi sisältää:

• työn kuvaus
• oletukset ja rajoitukset
• vastuulliset ihmiset tai organisaatiot
• Virstanpylväät
• Liittyvät toiminnot
• Vaaditut resurssit
• Kustannusarviot tai budjetti
• Hyväksymiskriteerit
• Viittaa muihin asiakirjoihin

Joten mikä sopii tarpeisiisi ja auttaa sinua integroimaan WBS: n muihin prosesseihin.

Johtopäätös

”Ei ole tuulta, joka puhaltaa oikein merimiehelle, joka ei tiedä sataman sijaintia.”

Et voi johtaa projektia onnistuneeseen tulokseen tietämättä, mitä on tehtävä.

Haluan vielä kerran korostaa sitä.

Vaikka olet ketterässä ympäristössä ja laajuutta ei ole määritelty selkeästi koko projektille, sinun on silti suunniteltava tapa määritellä, hallita, seurata ja muuttaa projektin laajuutta.

Molemmat iterointitasolle ja projektin lopullinen tulos.

Suosittelen myös lukemaan:

• Esitelty artikkeli: Kuinka tulla IT-projektipäälliköksi ilman kokemusta
• Seuraava sarja: Lopullinen opas vankan työn erittelyrakenteen luomiseen
• Edellinen sarjassa: Vaatimusten jäljitettävyysmatriisi projektinhallinnassa (Ex runsaasti + malli)