Bumalik sa blog
Pagmamapa sa mga stakeholder: hanapin ang mga taong maaaring malimutan ng proyekto
Guides6 min na pagbasa

Pagmamapa sa mga stakeholder: hanapin ang mga taong maaaring malimutan ng proyekto

Gumawa ng stakeholder map na kasama ang mga user na apektado, nagpapasiya, at katuwang sa delivery. May workshop, halimbawa, at tala ng pakikibahagi.

Tinutukoy ng pagmamapa sa mga stakeholder ang mga tao o grupong nakaaapekto o naaapektuhan ng proyekto, saka ipinakikita ang kanilang ugnayan at pangangailangan sa pakikilahok. Nakakatulong ang kapaki-pakinabang na mapa sa pagsagot kung sino ang kailangang marinig, sino ang maaaring magpasya, at sino ang dapat mag-ambag bago umusad ang trabaho. Hindi ito pagraranggo kung kaninong interes ang pinakamahalaga.

Kasama sa gabay sa pakikibahagi ng stakeholder ng Association for Project Management ang mga tao sa loob at labas ng organisasyong may interes, tungkulin, o exposure sa mga resulta ng proyekto. Binibigyang-diin ng praktikal na proseso ng pagmamapa sa ibaba ang exposure na iyon kasabay ng pormal na awtoridad.

Magsimula sa isang pasiya, hindi sa bakanteng canvas

Isulat sa itaas ng mapa ang resulta ng proyekto at ang susunod na mahalagang pasiya. Masyadong malawak ang “Maglunsad ng bagong serbisyo.” Mas madaling matukoy kung sino ang kailangang mag-ambag sa “Pagpasyahan kung paano lilipat ang mga kasalukuyang customer sa bagong proseso ng pagsingil.”

Itakda ang hangganan: buong programa, yugto ng delivery, o partikular na pagbabago. Maaaring mangailangan ng ibang detalye ang mapa para sa teknikal na migration kaysa sa pagbabago ng patakaran sa customer. Huwag piliting gawing panglahat ng gawain ang iisang napakalaking diagram.

Pagkatapos, itanong ang apat na tanong:

  1. Sino ang direktang makararanas ng pagbabago?
  2. Sino ang magpapatakbo, susuporta, o magpapanatili sa resulta?
  3. Sino ang makaaapruba, makahahadlang, makapagpopondo, o makapaglilimita sa pasiya?
  4. Sino ang may impormasyong wala pa sa team?

Isama ang mga taong kakaunti ang pormal na kapangyarihan. Maaaring may alam ang manggagawa sa frontline tungkol sa eksepsiyong magtatakda kung magagamit ang iminungkahing proseso.

Pumili ng mapang babagay sa tanong

Uri ng mapa Pinakamainam na tanong Limitasyon
Mapa ng mga ugnayan Sino ang umaasa sa kanino? Maaaring maging siksik sa paningin
Grid ng impluwensiya at interes Sino ang nangangailangan ng anong pakikibahagi? Maaaring mabigyan ng kulang na bigat ang kakaunti ang kapangyarihan
Mapang naka-ugnay sa journey Sino ang kalahok sa bawat yugto ng karanasan? Maaaring hindi makita ang pamamahala sa labas ng journey na iyon
Mapa ng tungkulin at pasiya Sino ang nagpapayo, nagpapasiya, at nagde-deliver? Hindi inilalarawan ang lahat ng di-pormal na ugnayan

Higit sa isang tanawin lang ang gamitin kapag sinusuportahan ng bawat isa ang magkaibang pasiya. Mas kapaki-pakinabang kadalasan ang maikling mapa ng ugnayan at maikling talahanayan sa pakikibahagi kaysa komplikadong modelong pang-score.

Magdaos ng workshop sa pagmamapa ng stakeholder

Anyayahan ang mga tao mula sa delivery, operations, at konteksto ng user na apektado. Bigyan ang mga kalahok ng ilang minuto para tahimik na magsulat ng mga posibleng stakeholder bago magtalakayan ng mga pangalan. Maiiwasan nitong maging tanging balangkas ng grupo ang listahan ng unang nagsalita.

Pangkatin ang mga posibleng stakeholder ayon sa tungkulin o ugnayan, saka kuwestiyunin ang mga grupo. Maaaring kabilang sa “mga customer” ang mga administrator, paminsan-minsang user, at mga nangangailangan ng tulong. Maaaring kabilang sa “operations” ang mga team na magkaiba ang shift, pananagutan, o access.

Iguhit lang ang mahahalagang ugnayan. Lagyan ng label ang palaso batay sa ipinapasa ng mga partido: pag-apruba, impormasyon, pera, serbisyo, o dependency. Maaaring magmukhang magkakaugnay ang walang label na mga linya nang hindi ipinapaliwanag ang ugnayan.

Tapusin sa pagmamarka kung kumpirmado o palagay ang bawat entry. Tukuyin kung sino ang magkukumpirma sa bawat mahalagang palagay. Dapat manatiling pansamantala ang mapang ginawa ng project team hanggang magkaroon ng pagkakataong itama ito ang mga taong apektado.

Kumpletong halimbawa: pagbabago sa proseso ng pagsasara ng account

Hipotetikal na halimbawa: planong pasimplehin ng team ang pagsasara ng account. Kasama sa unang listahan nito ang product, engineering, sponsor ng proyekto, at customer support. Ipinakikita ng listahang iyon ang organisasyong naghahatid pero may ilang bungang hindi nito nakikita.

Nadagdag sa pagdaan sa proseso ang mga account administrator, user na mawawalan ng access, finance team na humahawak sa hindi pa bayad na singil, at mga taong nagpapanatili ng retention rule. Ibinubunyag din nitong nakatatanggap ng event sa pagsasara ang isang panlabas na serbisyo at maaari pa ring magpadala ng notification kapag naantala ang event.

Binabago ng mapa ang pasiya sa disenyo. Sa halip na ituring ang pagsasara bilang iisang button at confirmation screen, kailangang maunawaan ng team ang magkakasunod na obligasyon at komunikasyon. Nagtatakda ito ng pag-uusap sa mga kaugnay na may-ari bago pagpasyahan ang saklaw ng implementasyon.

Hindi ipinagpapalagay ng team na kailangang dumalo ng bawat stakeholder sa bawat workshop. Kinukumpirma ng finance ang mga kundisyong nakaaapekto sa singil. Sinusubok ng support ang paliwanag na matatanggap ng mga user. Tinitiyak ng may-ari ng panlabas na serbisyo ang kontrata ng event. Iniuugnay ang bawat ambag sa partikular na pasiya.

Gawing tala ng pakikibahagi ang mapa

Nagiging kapaki-pakinabang ang stakeholder map kapag binabago nito ang paraan ng pagtatrabaho ng team. Panatilihin ang maikling tala:

Field Itatala
Stakeholder o tungkulin Sino ang kailangang makibahagi
Interes na apektado Ano ang maaaring bumuti o lumala para sa kanila
Pasiya o dependency Bakit mahalaga ngayon ang pakikibahagi nila
Paraan ng pakikibahagi Panayam, pagsusuri, pagsubok, pag-apruba, o update
May-ari Sino ang nagpapanatili ng ugnayan
Oras Bago ang aling pasiya o pangyayari
Beripikasyon Kailan huling sinuri ang entry

Iwasang mangalap ng personal na impormasyong hindi kailangan ng proyekto. Hindi dapat mapunta sa pampublikong collaboration board ang sensitibong pagtaya sa impluwensiya o alitan. Ilarawan nang walang kinikilingan ang usapin sa operasyon sa halip na lagyan ng label na “mahirap na stakeholder” ang isang tao.

Magtanong para makita ang mga nakaligtaang stakeholder

Sa pagtatapos ng bawat panayam, itanong kung sino pa ang gumagawa ng trabaho, tumatanggap ng output, o humahawak sa mga eksepsiyon. Ihambing ang mga sagot sa mapa. Palatandaan na maaaring sobrang makitid ang hangganan ng proyekto ang paulit-ulit na nawawalang tungkulin.

Itanong kung ano ang nangyayari sa labas ng karaniwang oras, kapag pumalya ang proseso, at kapag hindi magamit ng customer ang nilalayong channel. Madalas ilantad ng mga tanong na ito ang pangangailangan sa support, accessibility, procurement, o partner na hindi isinama sa planong maayos ang takbo.

Itanong din kung sino ang nagpapasiya kapag nagkakasalungat ang mga interes. Magkaiba ang konsultasyon at awtoridad sa pagpapasiya. Maaaring makinig nang malawak ang team habang nililinaw kung sino ang may-ari ng huling pagpili at paano itatala ang hindi pagsang-ayon.

Panatilihing napapanahon ang mapa habang nagde-deliver

Balikan ang mapa kapag nagbago ang saklaw, lumitaw ang dependency, umalis ang pangunahing tao, o may bagong grupong naapektuhan. Makakatulong ang regular na pagrerepaso sa kalendaryo, pero mas mahalaga ang mga update batay sa pangyayari kaysa petsa sa lipas nang diagram.

Gamitin ang agile retrospective para itanong kung sino ang nahuling naisama at anong palagay ang ginawa ng team tungkol sa availability. Pagbutihin ang proseso ng pakikibahagi nang hindi ginagawang paghatol sa mga indibidwal na stakeholder ang retrospective.

Maaaring maglaman ang simpleng format ng retrospective ng mga obserbasyon tungkol sa handoff. Itago ang opisyal na tala ng stakeholder sa pinagsasaluhang dokumentasyon ng proyekto at gamitin ang proseso ng follow-up sa pagpapahusay para suriin ang bagong gawi sa pakikibahagi.

Mga karaniwang pagkakamali sa pagmamapa

Magsimula at magtapos sa mga titulo sa trabaho. Nakakatulong ang mga titulo para matukoy ang awtoridad pero hindi nila ipinakikita kung sino ang makararanas ng pagbabago. Isama ang mga tungkuling apektado at kundisyon ng operasyon.

Ituring na hindi mahalaga ang mababang impluwensiya. Maaaring kakaunti ang kakayahan ng grupo na humarang sa proyekto pero malaki ang kahihinatnan para rito. Isama nang tahasan ang epekto sa pagsasaalang-alang.

Ipagpalagay na kumakatawan ang isang tagapagsalita sa lahat. Itala kung aling pananaw ang narinig at alin ang hindi pa nasusubok. Hindi mabeberipika ng isang administrator ang lahat ng sitwasyon ng customer.

Gumawa ng mapa nang walang susunod na aksiyon. Dapat humantong sa tiyak na pag-uusap, pasiya, o hakbang ng beripikasyon ang bawat mahalagang ugnayan.

Mga madalas itanong

Ano ang pagkakaiba ng pagmamapa at pagsusuri sa mga stakeholder?

Ipinakikita ng pagmamapa ang mga stakeholder at ugnayan. Sinusuri naman ng analysis ang mga interes, impluwensiya, exposure, at pangangailangan nila sa pakikibahagi. Sa gawain, madalas magpalitan ang team sa dalawa habang bumubuo ng plano sa pakikibahagi.

Dapat bang kasama sa stakeholder map ang mga customer?

Oo, kapag naaapektuhan ang mga customer o user. Ihiwalay ang mga kaugnay na grupo sa halip na ituring na pare-pareho ang gawain, limitasyon, o exposure ng lahat ng customer.

Gaano kadalas dapat i-update ang stakeholder map?

I-update ito kapag nagbago ang proyekto o mga ugnayan nito. Suriin bago ang mahahalagang pasiya at magsagawa ng pana-panahong pagrepaso para makita ang mga pagbabagong walang halatang pangyayaring nagpasimula nito.