‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﯾﻦ ﻓﺎﯾﻞ ﺑﻪ ﻃﻮر ﺧﻮدﮐﺎر ﺑﺮ اﺳﺎس آﺧﺮﯾﻦ وﯾﺮاﯾﺶ آﻧﻼﯾﻦ ﮐﺘﺎب ﺳﺎﺧﺘﻪ ﺷﺪه اﺳﺖ‪ .‬ﺑﺮای درﯾﺎﻓﺖ ﺟﺪﯾﺪﺗﺮﯾﻦ ﻧﺴﺨﻪ ﯾﺎ‬
‫ﻣﻄﺎﻟﻌﻪ آﻧﻼﯾﻦ ﮐﺘﺎب ﺑﻪ اﯾﻦ آدرس ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪https://khorramirad.com/ebooks/pmbok-7/ :‬‬

‫ﺗﺎﻟﯿﻒ ﻧﺎدر ﺧﺮﻣﯽ راد‬

‫وﯾﺮاﯾﺶ ﻧﺨﺴﺖ‪ :‬ﺑﻬﺎر ‪۱۴۰۲‬‬

‫اﯾﻦ ﮐﺘﺎب آزاد و راﯾﮕﺎن‪ ،‬ﺑﺎ ﭘﺮواﻧﻪ ‪ CC-BY‬ﻣﻨﺘﺸﺮ ﺷﺪه اﺳﺖ‪ .‬اﺳﺘﻔﺎده‪ ،‬ﭘﺨﺶ‪ ،‬ﺗﻐﯿﯿﺮ‪ ،‬و ﺑﺎزﻧﺸﺮ آن ﺑﺎ ﻧﺎم ﺑﺮدن‬
‫ﻧﻮﯾﺴﻨﺪه و آدرس ﺳﺎﯾﺖ و ذﮐﺮ دﺳﺖﺧﻮرده ﯾﺎ دﺳﺖﻧﺨﻮرده ﺑﻮدن ﻣﺤﺘﻮا ﺑﯽاﺷﮑﺎل و ﺑﺎﻋﺚ ﺧﻮﺷﻮﻗﺘﯽ ﻧﻮﯾﺴﻨﺪه‬
‫ﺧ ﻮ ا ﻫ ﺪ ﺑ ﻮ د‪.‬‬

‫درﺑﺎره ﻧﻮﯾﺴﻨﺪه‬

‫ﺳﺎل ‪ ۱۳۷۶‬ﮐﺎر ﺑﺮ روی ﭘﺮوژهﻫﺎ را آﻏﺎز ﮐﺮدم‪ .‬در آﻏﺎز ﻣﺸﻐﻮﻟﯿﺘﻢ ﺑﺮﻧﺎﻣﻪرﯾﺰی و ﮐﻨﺘﺮل ﭘﺮوژه ﺑﻮد و در ﮐﻨﺎر آن ﮐﺘﺎبﻫﺎی‬
‫ﻣﺘﻌﺪدی در اﯾﻦ ﺣﻮزه ﺗﺮﺟﻤﻪ و ﺗﺎﻟﯿﻒ ﮐﺮدم ﮐﻪ ﺗﺎ اﻣﺮوز ﺑﻪ ﺣﺪود ‪ ۵۰‬ﻋﻨﻮان رﺳﯿﺪه اﺳﺖ‪ .‬در اﯾﻦ ﻣﺪت ﺑﯿﺸﺘﺮ در‬
‫ﭘﺮوژهﻫﺎی ﮐﺎرﺧﺎﻧﻪﻫﺎی ﻓﺮآوری و ﺳﺎﺧﺘﻤﺎﻧﯽ ﻣﺸﻐﻮل ﺑﻮدم و در ﮐﻨﺎر آنﻫﺎ ﭼﻨﺪ ﭘﺮوژه ﻧﺮماﻓﺰاری را ﻫﻢ ﺗﺠﺮﺑﻪ ﮐﺮدم‪.‬‬

‫ﭘﺲ از ﭼﻨﺪی ﺑﻪ ﺟﻨﺒﻪﻫﺎی ﮐﻼنﺗﺮ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻋﻼﻗﻪﻣﻨﺪ ﺷﺪم و ﻓﻌﺎﻟﯿﺘﻢ را در آن ﺣﻮزه اداﻣﻪ دادم‪ .‬ﺳﺎل ‪ ۱۳۹۳‬ﺑﻪ‬
‫ﺑﻠﮋﯾﮏ ﻧﻘﻞﻣﮑﺎن ﮐﺮدم‪ .‬در اﯾﻨﺠﺎ ﻫﻤﺮاه ﺑﺎ ﻫﻤﮑﺎرم ﺷﺮﮐﺖ ﮐﻮﭼﮑﯽ ﺑﻪ ﻧﺎم ‪ Management Plaza‬دارﯾﻢ ﮐﻪ ﺳﺎزﻧﺪه‬
‫دورهﻫﺎی اﻟﮑﺘﺮوﻧﯿﮑﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﺑﺨﺶ ﺑﺰرﮔﯽ از زﻣﺎﻧﻢ ﺻﺮف ﻫﻤﮑﺎری در ﺗﻮﺳﻌﻪ اﺳﺘﺎﻧﺪاردﻫﺎ‬
‫و ر و ش ﻫ ﺎ ﺷ ﺪ ه ا ﺳ ﺖ ‪ ،‬ا ز ﺟ ﻤﻠ ﻪ ‪:‬‬

‫ﻋﻀﻮﯾﺖ در ﺗﯿﻢ دوازده ﻧﻔﺮه ﺗﺎﻟﯿﻒ ﭘﻢﺑﺎک ‪۷‬‬

‫ﻋﻀﻮﯾﺖ در ﺗﯿﻢ ﻣﺮﮐﺰی ﺗﺎﻟﯿﻒ ‪NUPP‬‬
‫ﻋﻀﻮﯾﺖ در ﺗﯿﻢ ﻣﺮﮐﺰی ﺗﺎﻟﯿﻒ ‪P3.express‬‬
‫ﻣﺸﺎور وﯾﺮاﯾﺶ ﺷﺸﻢ ‪PRINCE2‬‬
‫ﻣﺸﺎور وﯾﺮاﯾﺶ ﻧﺨﺴﺖ ‪PRINCE2 Agile‬‬
‫ﻣﺸﺎور وﯾﺮاﯾﺶ ‪ ۲۰۲۰‬اﺳﺘﺎﻧﺪارد ﻣﺪﯾﺮﯾﺖ ﻃﺮح ‪MSP‬‬

‫ﺑﺮای اﻃﻼﻋﺎت ﺑﯿﺸﺘﺮ ﺑﻪ ﺳﺎﯾﺖ ﻓﺎرﺳﯽام در ‪ https://khorramirad.com‬و درﺑﺎره ﻓﻌﺎﻟﯿﺖﻫﺎی ﺑﯿﻦاﻟﻤﻠﻠﯽام ﺑﻪ‬
‫‪ https://nader.pm‬ﯾﺎ ‪ gemini://nader.pm‬ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬

‫رﺳﻤﯿﺖ اﯾﻦ ﮐﺘﺎب‬

‫ﻫﻤﻪ ﻣﻄﺎﻟﺐ اﯾﻦ ﮐﺘﺎب دﯾﺪﮔﺎه ﺷﺨﺼﯽ ﻧﻮﯾﺴﻨﺪه اﺳﺖ و دﯾﺪﮔﺎه رﺳﻤﯽ ‪ PMI‬ﯾﺎ ﺗﯿﻢ ﺗﺎﻟﯿﻒ ﭘﻢﺑﺎک ‪ ۷‬ﻧﯿﺴﺖ‪ .‬ﺑﺮﺧﯽ از‬
‫ﻣﻔﺎﻫﯿﻢ ﻃﺮحﺷﺪه در اﯾﻦ ﮐﺘﺎب ﭼﺎﻟﺶﺑﺮاﻧﮕﯿﺰ ﺑﻮده‪ ،‬ﻫﻤﮕﺎن درﺑﺎرهﺷﺎن ﻫﻢرای ﻧﯿﺴﺘﻨﺪ‪.‬‬

‫—‪—2‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ . 1‬ﭘ ﻢﺑﺎ ک ﭼﯿ ﺴ ﺖ ؟‬

‫در دﻫﻪ ﻫﻔﺘﺎد ﻣﯿﻼدی ﻣﻔﻬﻮم ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺟﺪﯾﺖ ﺑﯿﺸﺘﺮی ﭘﯿﺪا ﮐﺮد و از ﺳﻮی ﺑﺴﯿﺎری ﺑﻪﻋﻨﻮان ﺣﺮﻓﻪای ﻣﺴﺘﻘﻞ ﺑﻪ‬
‫رﺳﻤﯿﺖ ﺷﻨﺎﺧﺘﻪ ﺷﺪ‪.‬‬

‫ﻋﺪهای از دﺳﺖاﻧﺪرﮐﺎران ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه در آﻣﺮﯾﮑﺎ آﻏﺎز ﺑﻪ ﺑﺮﮔﺰاری ﮔﺮدﻫﻤﺎﯾﯽﻫﺎ و ﮐﻨﻔﺮاﻧﺲﻫﺎﯾﯽ در اﯾﻦ ﺣﻮزه ﮐﺮدﻧﺪ‬
‫ﮐﻪ ﺑﻪﺗﺪرﯾﺞ روﻧﻖ ﺑﯿﺸﺘﺮی ﮔﺮﻓﺖ و ﺳﺮاﻧﺠﺎم ﻣﻨﺠﺮ ﺑﻪ ﺑﻨﯿﺎنﮔﺬاری ﻣﻮﺳﺴﻪای ﺑﻪ ﻧﺎم ‪Project Management‬‬
‫‪ Institute‬ﺷﺪ ﮐﻪ ﮐﻮﺗﺎهﺷﺪه ‪ PMI‬ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬

‫‪ .1.1‬ﮔﻮاﻫﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬

‫ﺗﻤﺮﮐﺰ اﺻﻠﯽ ‪ PMI‬ﺑﺮ ﺑﺮﮔﺰاری ﮐﻨﻔﺮاﻧﺲﻫﺎﯾﯽ ﺑﻮد ﮐﻪ دﺳﺖاﻧﺪرﮐﺎران را ﮔﺮد ﻫﻢ ﻣﯽآورد‪ .‬اﯾﻦ ﺳﻨﺖ ﻫﻤﭽﻨﺎن اداﻣﻪ دارد‬
‫و در ﻫﺮ ﺷﻬﺮ ﯾﺎ ﮐﺸﻮری ﮐﻪ ﺷﻌﺒﻪای از ‪ PMI‬وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ ﻣﻌﻤﻮﻻ ﯾﮏ ﮐﻨﻔﺮاﻧﺲ ﺑﺰرگ ﺳﺎﻻﻧﻪ و ﭼﻨﺪ ﮐﻨﻔﺮاﻧﺲ‬
‫ﮐﻮﭼﮏ ﻣﺤﻠﯽ ﺑﺮﮔﺰار ﻣﯽﺷﻮد‪.‬‬

‫ﻣﺪﺗﯽ ﭘﺲ از ﺑﻨﯿﺎنﮔﺬاری ‪ ، PMI‬اﯾﺪه راهاﻧﺪازی ﮔﻮاﻫﯽای ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺷﮑﻞ ﮔﺮﻓﺖ‪ .‬اﯾﻦ ﮔﻮاﻫﯽ‪ ،‬ﺑﺎ ﻧﺎم ‪Project‬‬
‫‪) Management Professional‬ﺣﺮﻓﻪای در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه(‪ ،‬ﮐﻪ ﮐﻮﺗﺎهﺷﺪه ‪ PMP‬ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪ ،‬در ‪ ۱۹۸۴‬ﺷﮑﻞ‬
‫ﮔﺮﻓﺖ‪ .‬ﮔﻮاﻫﯽ ﺑﻪﺳﺮﻋﺖ ﻣﺤﺒﻮﺑﯿﺖ ﻓﺮاواﻧﯽ ﭘﯿﺪا ﮐﺮد و ﻫﻤﭽﻨﺎن ﯾﮑﯽ از ﻣﻄﺮحﺗﺮﯾﻦ ﮔﻮاﻫﯽﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺟﻬﺎن ﺑﻪ‬
‫ﺷ ﻤ ﺎ ر ﻣ ﯽ ر و د‪.‬‬

‫‪ .2.1‬راﻫﻨﻤﺎی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ‬

‫آزﻣﻮن ‪ PMP‬درﺑﺎره اﻃﻼﻋﺎت ﻋﻤﻮﻣﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻮد‪ .‬ﭘﺲ از ﻣﺪﺗﯽ‪ PMI ،‬ﺑﺮآن ﺷﺪ ﮐﻪ اﯾﻦ اﻃﻼﻋﺎت را ﺳﺎزﻣﺎندﻫﯽ‬
‫و در ﻗﺎﻟﺐ راﻫﻨﻤﺎﯾﯽ ﻣﻨﺘﺸﺮ ﮐﻨﺪ‪ .‬ﻧﺨﺴﺘﯿﻦ ﭘﯿﺶﻧﻮﯾﺲ آن در ‪ ۱۹۸۷‬و وﯾﺮاﯾﺶ ﻧﻬﺎﯾﯽاش ﭘﺲ از اﺻﻼحﻫﺎی زﯾﺮﺑﻨﺎﯾﯽ‬
‫در ‪ ۱۹۹۶‬ﻣﻨﺘﺸﺮ ﺷﺪ‪ .‬ﭘﺲ از آن ﻫﺮ ﭼﻬﺎر ﺗﺎ ﭘﻨﺞ ﺳﺎل ﯾﮏﺑﺎر وﯾﺮاﯾﺶ ﺗﺎزهای ﺟﺎﻧﺸﯿﻦ ﭘﯿﺸﯿﻦ ﺷﺪ‪:‬‬

‫‪ – ۱۹۹۶‬ﻧﺨﺴﺘﯿﻦ وﯾﺮاﯾﺶ رﺳﻤﯽ‬

‫‪ – ۲۰۰۰‬وﯾﺮاﯾﺶ ‪۲۰۰۰‬‬
‫‪ – ۲۰۰۴‬وﯾﺮاﯾﺶ ‪۳‬‬
‫‪ – ۲۰۰۸‬وﯾﺮاﯾﺶ ‪۴‬‬
‫‪ – ۲۰۱۳‬وﯾﺮاﯾﺶ ‪۵‬‬
‫‪ – ۲۰۱۷‬وﯾﺮاﯾﺶ ‪۶‬‬
‫‪ – ۲۰۲۱‬وﯾﺮاﯾﺶ ‪۷‬‬

‫وﯾﺮاﯾﺶ ﻧﺨﺴﺖ ﭘﻢﺑﺎک ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺑﺎ ‪ ۳۷‬ﻓﺮآﯾﻨﺪ ﺗﻮﺿﯿﺢ ﻣﯽداد‪ .‬ﻫﺮ ﻓﺮآﯾﻨﺪ ﺷﻤﺎری ورودی‪ ،‬اﺑﺰار و روش‪ ،‬و‬
‫ﺧﺮوﺟﯽ داﺷﺖ‪ .‬ﻓﺮآﯾﻨﺪﻫﺎ ﺑﻪ دو ﺷﮑﻞ دﺳﺘﻪﺑﻨﺪی ﺷﺪه ﺑﻮدﻧﺪ‪:‬‬

‫—‪—3‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﮔﺮوهﻫﺎی ﻓﺮآﯾﻨﺪی‪ :‬دﺳﺘﻪﺑﻨﺪی ﺑﺮ ﭘﺎﯾﻪ ﺟﺎﯾﮕﺎه ﻓﺮآﯾﻨﺪ در ﭼﺮﺧﻪ ﺣﯿﺎت ﭘﺮوژه‬

‫آﻏﺎزش‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی‬
‫اﺟﺮا‬
‫ﮐﻨﺘﺮل‬
‫ﭘﺎﯾﺎ ن‬
‫ﺣﻮزهﻫﺎی داﻧﺶ‪ :‬دﺳﺘﻪﺑﻨﺪی ﺑﺮ ﭘﺎﯾﻪ ﻣﻮﺿﻮع ﻓﺮآﯾﻨﺪ‬
‫ﯾ ﮑﭙﺎ ر ﭼ ﮕ ﯽ‬
‫ﮔﺴﺘﺮه‬
‫زﻣﺎن‬
‫ﻫ ﺰﯾﻨ ﻪ‬
‫ﮐﯿ ﻔﯿ ﺖ‬
‫ﻣﻨﺎﺑ ﻊ اﻧ ﺴﺎﻧ ﯽ‬
‫ارﺗﺒﺎﻃﺎت‬
‫رﯾ ﺴ ﮏ‬
‫ﺗﺪارﮐﺎت‬

‫ﭘﻨﺞ وﯾﺮاﯾﺸﯽ ﮐﻪ ﭘﺲ از آن ﻣﻨﺘﺸﺮ ﺷﺪﻧﺪ ﻫﻤﮕﯽ ﺳﺎﺧﺘﺎر ﻧﺨﺴﺘﯿﻦ را ﺑﻬﺒﻮد ﻣﯽدادﻧﺪ‪ .‬ﺷﻤﺎر ﻓﺮآﯾﻨﺪﻫﺎ ﺑﻪﺗﺪرﯾﺞ از ‪۳۷‬‬
‫ﺑﻪ ‪ ۴۹‬رﺳﯿﺪ‪ .‬ﺣﻮزه داﻧﺶ ارﺗﺒﺎﻃﺎت ﺑﻪ ارﺗﺒﺎﻃﺎت و ذیﻧﻔﻌﺎن ﺗﻘﺴﯿﻢ ﺷﺪ و ﺑﺮﺧﯽ ﻋﻨﻮانﻫﺎ ﻧﯿﺰ اﺻﻼح ﺷﺪﻧﺪ‪ .‬ﺳﺮاﻧﺠﺎم‪،‬‬
‫ﮐﺘﺎب از ‪ ۱۷۶‬ﺻﻔﺤﻪ در وﯾﺮاﯾﺶ ﻧﺨﺴﺖ ﺑﻪ ‪ ۷۵۶‬ﺻﻔﺤﻪ در وﯾﺮاﯾﺶ ﺷﺸﻢ رﺳﯿﺪ‪.‬‬

‫ﺑﺮﺧﻼف وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ‪ ،‬ﻣﺤﺘﻮای وﯾﺮاﯾﺶ ﻫﻔﺘﻢ ﺑﻬﺒﻮدﯾﺎﻓﺘﻪ و دﻗﯿﻖﺷﺪه ﻣﺤﺘﻮای ﭘﯿﺸﯿﻦ ﻧﺒﻮد‪ ،‬ﺑﻠﮑﻪ ﮐﺎر را از ﺻﻔﺮ‬
‫آﻏﺎز ﮐﺮدﯾﻢ و ﺑﻪﺟﺎی روﻧﺪی ﻓﺮآﯾﻨﺪ ﻣﺤﻮر از روﻧﺪی اﺻﻞ ﻣﺤﻮر ﺑﻬﺮه ﺑﺮدﯾﻢ ﺗﺎ ﻫﻢ ﻣﺤﺘﻮا در ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﮐﺎرا ﺑﺎﺷﺪ و‬
‫ﻫﻢ ﺟﻠﻮی ﺑﺮﺧﯽ دﺷﻮاریﻫﺎی راﯾﺞ در روﯾﮑﺮد ﻓﺮآﯾﻨﺪ ﻣﺤﻮر را ﺑﮕﯿﺮد‪.‬‬

‫اﯾﻦ ﮐﺘﺎب ﺑﺮ ﻣﻔﻬﻮم ﭘﻢﺑﺎک ‪ ۷‬ﻣﺘﻤﺮﮐﺰ اﺳﺖ و ﻣﺒﺎﺣﺚ ﭼﻨﺪاﻧﯽ درﺑﺎره وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ ﯾﺎ ﺗﻔﺎوت آنﻫﺎ ﺑﺎ وﯾﺮاﯾﺶ‬
‫ﺗﺎزه ﻧﺪارد‪ .‬اﮔﺮ ﻋﻼﻗﻪﻣﻨﺪ ﺑﻪ ﯾﺎدﮔﯿﺮی ﻓﺮآﯾﻨﺪﻫﺎی ‪ PMI‬ﺑﺎﺷﯿﺪ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ ﭘﻢﺑﺎک ﯾﺎ ﺑﻪ ﮐﺘﺎب ﺗﺎزهای‬
‫ﮐﻪ ‪ PMI‬ﺑﺎ ﻧﺎم ‪ Process Groups: A Practice Guide‬ﻣﻨﺘﺸﺮ ﮐﺮده اﺳﺖ ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬

‫‪ .3.1‬اﻓﺰاﯾﺶ ﮔﻮاﻫﯽﻫﺎ و اﺳﺘﺎﻧﺪاردﻫﺎ‬

‫ﭘﺲ از ﻣﻮﻓﻘﯿﺖ ﭘﻢﺑﺎک و آزﻣﻮن ‪ ،PMP‬ﻓﻌﺎﻟﯿﺖﻫﺎی ‪ PMI‬ﺑﺎ اﻓﺰاﯾﺶ ﻣﻮارد زﯾﺮ اداﻣﻪ ﭘﯿﺪا ﮐﺮد‪:‬‬

‫ﮔ ﻮا ﻫ ﯽ ﻫﺎ‬

‫)‪Certified Associate in Project Management (CAPM‬‬

‫)‪Disciplined Agile Coach (DAC‬‬
‫)‪Disciplined Agile Scrum Master (DASM‬‬

‫—‪—4‬‬
 PMBOK 7 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ‬

Disciplined Agile Senior Scrum Master (DASSM)

Disciplined Agile Value Stream Consultant (DAVSC)
PMI Agile Certified Practitioner (PMI-ACP)
PMI Professional in Business Analysis (PMI-PBA)
PMI Project Management Ready
PMI Risk Management Professional (PMI-RMP)
PMI Scheduling Professional (PMI-SP)
Portfolio Management Professional (PfMP)
Program Management Professional (PgMP)

‫اﺳﺘﺎﻧﺪاردﻫﺎی زﯾﺮﺑﻨﺎﯾﯽ‬

The PMI Guide to Business Analysis

The Standard for Earned Value Management
The Standard for Organizational Project Management
The Standard for Portfolio Management
The Standard for Program Management
The Standard for Risk Management in Portfolios, Programs, and Projects

‫اﺳﺘﺎﻧﺪاردﻫﺎی ﻋﻤﻠﯽ‬

Practice Standard for Project Configuration Management

Practice Standard for Project Estimating
Practice Standard for Scheduling
Practice Standard for Work Breakdown Structures
Project Manager Competency Development Framework

‫راﻫﻨﻤﺎﻫﺎی ﮐﺎرﺑﺮدی‬

Agile Practice Guide

Benefits Realization Management: A Practice Guide
Business Analysis for Practitioners: A Practice Guide
Governance of Portfolios, Programs, and Projects: A Practice Guide
Managing Change in Organizations: A Practice Guide
Navigating Complexity: A Practice Guide
Process Groups: A Practice Guide
Requirements Management: A Practice Guide

.‫ ﻧﺮﺳﯿﺪ‬PMP ‫ ﻫﯿﭻﮐﺪام از ﻣﻮارد ﺑﺎﻻ ﺑﻪ درﺟﻪای از ﭘﺬﯾﺮش ﻫﻤﮕﺎﻧﯽ در ﺳﻄﺢ ﭘﻢﺑﺎک و‬،PMI-ACP ‫ﺑﻪﺟﺰ ﮔﻮاﻫﯽ‬

—5—
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ . 4 . 1‬ﻣﺎ ﻫﯿ ﺖ ﭘ ﻢﺑﺎ ک‬

‫ﻣﻨﺎﺑﻊ ﺳﺎﺧﺖﯾﺎﻓﺘﻪ درﺑﺎره ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺑﻪ دو دﺳﺘﻪ ﻣﯽﺗﻮان ﺗﻘﺴﯿﻢ ﮐﺮد‪:‬‬

‫ﻣﺘﺪوﻟﻮژیﻫﺎ راه ﻣﻨﺎﺳﺐ را در ﭘﺮوژه ﻧﺸﺎن ﻣﯽدﻫﻨﺪ‪.‬‬

‫راﻫﻨﻤﺎﻫﺎ ﺑﻪ ﺷﻤﺎ ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﮐﺎرآﺗﺮ ﮐﻨﯿﺪ‪.‬‬

‫ﻧﺨﺴﺘﯿﻦ ﻋﻨﺼﺮی ﮐﻪ ﻧﯿﺎز دارﯾﺪ ﻣﺘﺪوﻟﻮژی اﺳﺖ‪ .‬ﭘﺲ از اﺳﺘﻘﺮار ﻣﺘﺪوﻟﻮژی ﻣﻨﺎﺳﺐ‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ از راﻫﻨﻤﺎﻫﺎ ﺑﺮای‬
‫اﻓﺰاﯾﺶ ﮐﺎرآﯾﯽ ﺳﯿﺴﺘﻢ ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ‪.‬‬

‫ﭘﻢﺑﺎک راﻫﻨﻤﺎﺳﺖ و ﻧﻪ ﻣﺘﺪوﻟﻮژی‪ .‬ﻫﻤﻮاره ﮐﺴﺎن زﯾﺎدی ﮐﻮﺷﺶ ﮐﺮدهاﻧﺪ ﮐﻪ آن را ﺑﻪﺷﮑﻞ ﯾﮏ ﻣﺘﺪوﻟﻮژی ﺑﻪ ﮐﺎر ﺑﺒﺮﻧﺪ‬
‫و ﻫﯿﭻﮔﺎه ﻧﯿﺰ ﻣﻮﻓﻖ ﻧﺒﻮدهاﻧﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﭼﻨﺎن ﺣﺎد ﺑﻮد ﮐﻪ ﺗﻮﺿﯿﺤﯽ ﺑﻪ ﻣﻘﺪﻣﻪ وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ اﻓﺰوده ﺷﺪ و‬
‫ﻣﺘﺪوﻟﻮژی ﻧﺒﻮدن ﭘﻢﺑﺎک و ﻟﺰوم ﺑﻬﺮهﻣﻨﺪی از ﯾﮏ ﻣﺘﺪوﻟﻮژی در ﮐﻨﺎر آن را ﺗﻮﺿﯿﺢ داد‪ .‬ﺑﺎاﯾﻦﻫﻤﻪ‪ ،‬روﯾﮑﺮد ﻓﺮآﯾﻨﺪ ﻣﺤﻮر‬
‫ﭘﻢﺑﺎک ﻫﻤﭽﻨﺎن ﺳﻮﺗﻔﺎﻫﻢ اﯾﺠﺎد ﻣﯽﮐﺮد و ﮐﻤﺎﮐﺎن ﮐﺴﺎن زﯾﺎدی آن را ﺑﺎ ﯾﮏ ﻣﺘﺪوﻟﻮژی اﺷﺘﺒﺎه ﻣﯽﮔﺮﻓﺘﻨﺪ‪ .‬ﯾﮑﯽ از‬
‫اﻫﺪاف ﺗﺪوﯾﻦ ﻧﺴﺨﻪ ﻫﻔﺘﻢ اﯾﻦ ﺑﻮد ﮐﻪ ﺑﻪﮔﻮﻧﻪای زﯾﺮﺑﻨﺎﯾﯽ ﺟﻠﻮی اﯾﻦ اﺷﺘﺒﺎه ﮔﺮﻓﺘﻪ ﺷﻮد و ﮔﻤﺎن ﻣﯽﮐﻨﻢ در اﯾﻦ ﮐﺎر‬
‫ﻣﻮﻓﻖ ﺑﻮدهاﯾﻢ! ﺳﺎﺧﺘﺎر اﺻﻞ ﻣﺤﻮر ﻧﺴﺨﻪ ﻫﻔﺘﻢ را دﯾﮕﺮ ﻧﻤﯽﺗﻮان ﺑﺎ ﻣﺘﺪوﻟﻮژی اﺷﺘﺒﺎه ﮔﺮﻓﺖ‪.‬‬

‫ﭘ ﻢﺑﺎ ک ﺑ ﻪ د و ﺷ ﮑ ﻞ ﻣ ﯽﺗ ﻮاﻧ ﺪ ﺑ ﻪ ﺷ ﻤﺎ ﮐ ﻤ ﮏ ﮐﻨ ﺪ‪:‬‬

‫‪ .1‬اﺻﻞﻫﺎ ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﺗﻌﺒﯿﺮ و ﺗﻔﺴﯿﺮ ﺑﻬﺘﺮی از ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪.‬‬
‫‪ .2‬ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﮐﺎرآﺗﺮ ﮐﻨﯿﺪ‪.‬‬

‫از اﯾﻦ رو‪ ،‬در اداﻣﻪ ﮐﺘﺎب اﯾﻦ ﺳﻪ ﻓﺼﻞ اﺻﻠﯽ وﺟﻮد دارد‪:‬‬

‫»درک و ﺗﻔﺴﯿﺮ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه« درﺑﺎره اﯾﻦ اﺳﺖ ﮐﻪ ﭼﮕﻮﻧﻪ ﺑﺎ اﺻﻞﻫﺎی ﭘﻢﺑﺎک ﻣﯽﺗﻮاﻧﯿﺪ درک ﺑﻬﺘﺮی از ﻣﺪﯾﺮﯾﺖ‬
‫ﭘﺮوژه ﺑﻪ دﺳﺖ آورﯾﺪ‪ .‬اﯾﻦ ﻣﻬﺎرت در اﻧﺘﺨﺎب و ﭘﯿﺎدهﺳﺎزی ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه راﻫﮕﺸﺎ ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬
‫»اﻧﺘﺨﺎب ﻣﺘﺪوﻟﻮژی« ﺷﻤﺎری از ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺑﻪﮐﻮﺗﺎﻫﯽ ﻣﻌﺮﻓﯽ ﻣﯽﮐﻨﺪ ﺗﺎ درک ﮐﺎﻣﻞﺗﺮی از‬
‫ﻣ ﺒ ﺎ ﺣ ﺚ ﭘ ﯿ ﺶ ر و ﺑ ﻪ د ﺳ ﺖ آ و ر ﯾ ﺪ‪.‬‬
‫»ﺗﻘﻮﯾﺖ ﻣﺘﺪوﻟﻮژی« ﺗﻮﺿﯿﺢ ﻣﯽدﻫﺪ ﮐﻪ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﺎ ﮐﻤﮏ ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﭘﻢﺑﺎک ﻣﺘﺪوﻟﻮژی ﺧﻮد را‬
‫ﮐﺎرآﺗﺮ ﮐﻨﯿﺪ‪.‬‬

‫‪ .5.1‬ﻓﺮآﯾﻨﺪ ﺗﺪوﯾﻦ ﭘﻢﺑﺎک‬

‫ﭘﻢﺑﺎک و ﺳﺎﯾﺮ اﺳﺘﺎﻧﺪاردﻫﺎی ‪ PMI‬ﺑﺎ روﻧﺪی ﻣﻄﺎﺑﻖ ﺑﺎ آﻧﭽﻪ ﺑﺮای ﺗﺪوﯾﻦ اﺳﺘﺎﻧﺪاردﻫﺎ در ﻣﻮﺳﺴﻪ اﺳﺘﺎﻧﺪارد آﻣﺮﯾﮑﺎ‬
‫)‪ (ANSI‬ﺗﻌﺮﯾﻒ ﺷﺪه ﻣﺪﯾﺮﯾﺖ ﻣﯽﺷﻮﻧﺪ‪ .‬در وﯾﺮاﯾﺶﻫﺎی ﻧﺨﺴﺘﯿﻦ ﺗﻼش ﺑﺮ اﯾﻦ ﺑﻮد ﮐﻪ اﯾﻦ روﻧﺪ ﺗﺎ ﺟﺎی ﻣﻤﮑﻦ ﺑﺎ آﻧﭽﻪ‬
‫ﻣﻮﺳﺴﻪ ﺑﯿﻦاﻟﻤﻠﻠﯽ اﺳﺘﺎﻧﺪاردﺳﺎزی )‪ (ISO‬اﻧﺘﻈﺎر دارد ﻧﯿﺰ ﻫﻤﺨﻮان ﺑﺎﺷﺪ‪ ،‬وﻟﯽ ﻣﺘﺎﺳﻔﺎﻧﻪ اﯾﻦ ﺗﻮﺟﻪ در ﺳﺎلﻫﺎی اﺧﯿﺮ‬
‫ﮐ ﻤ ﺘ ﺮ ﺷ ﺪ ه ا ﺳ ﺖ‪.‬‬

‫—‪—6‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺘﺎﺳﻔﺎﻧﻪ ‪ PMI‬در ﻋﻤﻞ ﻣﻮﺳﺴﻪای ﺑﯿﻦاﻟﻤﻠﻠﯽ ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﻣﻮﺳﺴﻪاﯾﺴﺖ آﻣﺮﯾﮑﺎﯾﯽ ﮐﻪ ﺑﯿﺸﺘﺮ ﻧﻘﺎط ﺟﻬﺎن ﻓﻌﺎل و‬
‫ﺷﻨﺎﺧﺘﻪﺷﺪه اﺳﺖ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ از ﺳﻮی ﺑﺴﯿﺎری ﮐﻤﺒﻮدی زﯾﺮﺑﻨﺎﯾﯽ ﺑﻪ ﺷﻤﺎر ﻣﯽرود‪.‬‬

‫ﺗﯿﻢ ﺗﺎﻟﯿﻒ ﭘﻢﺑﺎک دوازده ﻋﻀﻮ داﺷﺖ و ﻣﻦ ﻫﻢ ﯾﮑﯽ از اﯾﻦ اﻓﺮاد ﺑﻮدم‪ .‬اﻋﻀﺎی ﺗﯿﻢ از ﻧﻘﺎط ﻣﺨﺘﻠﻒ ﺟﻬﺎن و ﺑﺎ‬
‫ﭘﺲزﻣﯿﻨﻪﻫﺎ و ﻣﻬﺎرتﻫﺎی ﮔﻮﻧﺎﮔﻮن اﻧﺘﺨﺎب ﺷﺪه ﺑﻮدﻧﺪ و ﺗﺪوﯾﻦ اﺳﺘﺎﻧﺪارد را ﺑﺮدوش داﺷﺘﻨﺪ‪ .‬ﺗﯿﻤﯽ ﻫﻢ ﺑﺮای رﻫﺒﺮی‬
‫ﭘﺮوژه وﺟﻮد داﺷﺖ ﮐﻪ ﻣﺴﺌﻮل ﻫﻤﺎﻫﻨﮕﯽﻫﺎ‪ ،‬ﻧﻈﺎرت ﺑﺮ ﻣﻄﺎﺑﻘﺖ ﮐﺎرﻫﺎ ﺑﺎ اﻟﺰاﻣﺎت ﻣﻮﺳﺴﻪ و ﻫﻤﺎﻧﻨﺪ آن ﺑﻮد‪.‬‬

‫ﮔﺮوﻫﯽ ﺣﺪودا ﻫﻔﺘﺎد ﻧﻔﺮه ﻣﺴﺌﻮﻟﯿﺖ ﻣﺮور ﺧﺮوﺟﯽﻫﺎی ﺗﯿﻢ ﺗﺎﻟﯿﻒ را در زﻣﺎن ﮐﺎر داﺷﺖ‪ .‬در ﭘﺎﯾﺎن‪ ،‬ﭘﯿﺶﻧﻮﯾﺴﯽ از‬
‫ﻣﺤﺘﻮا در اﺧﺘﯿﺎر ﻋﻤﻮم ﻗﺮار ﮔﺮﻓﺖ و ﺣﺪود ﺷﺸﺼﺪ ﻧﻔﺮ دﯾﺪﮔﺎهﻫﺎﯾﺸﺎن را در اﺧﺘﯿﺎرﻣﺎن ﻗﺮار دادﻧﺪ‪ .‬دﯾﺪﮔﺎهﻫﺎ ﮔﻮﻧﻪای‬
‫ﻣﯿﺎن اﻋﻀﺎی ﺗﯿﻢ ﺗﺎﻟﯿﻒ ﺑﺨﺶ ﺷﺪ ﮐﻪ ﻫﺮ دﯾﺪﮔﺎه را دو ﻧﻔﺮ ﻣﺴﺘﻘﻞ از ﻫﻢ ﺑﺮرﺳﯽ ﮐﻨﻨﺪ و درﺑﺎره آن ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮﻧﺪ‪ .‬اﮔﺮ‬
‫ﺗﺼﻤﯿﻢ آن دو ﻋﻀﻮ ﯾﮑﺴﺎن ﻧﻤﯽﺑﻮد‪ ،‬ﻧﻔﺮ ﺳﻮﻣﯽ ﻫﻢ دﯾﺪﮔﺎه را ﺑﺮرﺳﯽ ﻣﯽﮐﺮد و ﺑﺮ ﭘﺎﯾﻪ رای اﮐﺜﺮﯾﺖ در ﻣﯿﺎن اﯾﻦ ﺳﻪ‬
‫ﻋﻀﻮ درﺑﺎره اﻋﻤﺎل ﮐﺮدن ﯾﺎ ﻧﮑﺮدن دﯾﺪﮔﺎه درﯾﺎﻓﺘﯽ ﺗﺼﻤﯿﻢ ﮔﺮﻓﺘﻪ ﻣﯽﺷﺪ‪.‬‬

‫ﭘﺲ از ﺑﻬﺒﻮد ﭘﯿﺶﻧﻮﯾﺲ ﺑﺮ ﭘﺎﯾﻪ دﯾﺪﮔﺎهﻫﺎی درﯾﺎﻓﺘﯽ‪ ،‬ﻧﺴﺨﻪ ﻧﻬﺎﯾﯽ آﻣﺎده و در ‪ ۲۰۲۱‬ﻣﻨﺘﺸﺮ ﺷﺪ‪ .‬ﺑﺮ ﭘﺎﯾﻪ ﻗﻮاﻋﺪ ‪،ANSI‬‬
‫ﻣﺸﺎﺑﻪ اﯾﻦ روﻧﺪ ﺑﺎﯾﺪ ﺣﺪاﮐﺜﺮ ﺗﺎ ﭘﻨﺞ ﺳﺎل دﯾﮕﺮ ﺗﮑﺮار و وﯾﺮاﯾﺶ ﺗﺎزهای از اﺳﺘﺎﻧﺪارد ﻣﻨﺘﺸﺮ ﮔﺮدد‪.‬‬

‫—‪—7‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .2‬درک و ﺗﻔﺴﯿﺮ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬

‫ﭼﻨﺪ ﺳﺎل ﭘﯿﺶ ﻣﺠﻤﻮﻋﻪ ﻣﻘﺎﻟﻪای را از ﻓﯿﺰﯾﮑﺪان ﻧﺎﻣﺪار‪ ،‬رﯾﭽﺎرد ﻓﺎﯾﻨﻤﻦ‪ ،‬ﻣﻄﺎﻟﻌﻪ ﻣﯽﮐﺮدم‪ .‬در ﺑﺨﺸﯽ از ﻣﻘﺎﻟﻪ ﻣﺸﮑﻠﯽ‬
‫ﮐﻪ در ﻣﯿﺎن ﻓﯿﺰﯾﮑﺪاﻧﺎن ﻣﺸﺎﻫﺪه ﮐﺮده ﺑﻮد را ﺑﻪ ﻣﻔﻬﻮﻣﯽ ﺑﻪ ﻧﺎم ﺑﺎرﭘﺮﺳﺘﯽ )‪ (Cargo Cult‬ﺗﺸﺒﯿﻪ ﮐﺮد‪ .‬وﻗﺘﯽ در ﺣﺎل‬
‫ﻣﻄﺎﻟﻌﻪ ﺑﻮدم‪ ،‬ﻫﻤﻪ اﻧﺪﯾﺸﻪام اﯾﻦ ﺑﻮد ﮐﻪ اﯾﻦ ﻣﺸﮑﻞ ﺗﺎ ﭼﻪ اﻧﺪازه در ﭘﺮوژهﻫﺎ ﺟﺪﯾﺴﺖ‪.‬‬

‫ﺷﮑﻞﮔﯿﺮی ﻣﻔﻬﻮم ﺑﺎرﭘﺮﺳﺘﯽ ﺑﻪ ﺟﻨﮓﻫﺎی ﺟﻬﺎﻧﯽ اول و دوم ﺑﺎزﻣﯽﮔﺮدد‪ .‬ﮔﺮوﻫﯽ از ﻣﺮدﻣﺎن ﺑﺪوی ﮐﻪ در ﮔﯿﻨﻪﻧﻮ و ﺑﺮﺧﯽ‬
‫ﺟﺰﯾﺮهﻫﺎی دﯾﮕﺮ در ﺣﻮاﻟﯽ اﺳﺘﺮاﻟﯿﺎ ﻣﯽزﯾﺴﺘﻨﺪ و ﺑﺎ ﺟﻬﺎن ﺑﯿﺮون ارﺗﺒﺎط ﻧﺪاﺷﺘﻨﺪ ﻧﺎﮔﻬﺎن ﭘﺪﯾﺪه ﻋﺠﯿﺒﯽ ﻣﺸﺎﻫﺪه ﮐﺮدﻧﺪ‪:‬‬
‫ارﺗﺶﻫﺎی ژاﭘﻦ و آﻣﺮﯾﮑﺎ در ﺑﺮﺧﯽ از اﯾﻦ ﺟﺰﯾﺮهﻫﺎ ﭘﺎﯾﮕﺎهﻫﺎی ﻧﻈﺎﻣﯽ ﻣﻮﻗﺖ راهاﻧﺪازی ﮐﺮده ﺑﻮدﻧﺪ‪ .‬ﻫﺮ از ﭼﻨﺪی‪،‬‬
‫ﻫﻮاﭘﯿﻤﺎﻫﺎی ﺑﺎری در ﺟﺰﯾﺮه ﻓﺮود ﻣﯽآﻣﺪﻧﺪ‪ .‬ﻣﺸﺎﻫﺪه ﻣﺎﺷﯿﻦﻫﺎی ﺑﺰرﮔﯽ ﮐﻪ در ﻫﻮا ﭘﺮواز ﻣﯽﮐﻨﻨﺪ ﺑﺮای آن ﻣﺮدﻣﺎن‬
‫ﺑﺪوی ﺷﮕﻔﺖاﻧﮕﯿﺰ ﺑﻮد‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﺳﺮﺑﺎزان ﮔﺎﻫﯽ ﺑﺨﺸﯽ از ﮐﺎﻻﻫﺎی رﺳﯿﺪه ﮐﻪ ﻧﯿﺎز ﻧﺪاﺷﺘﻨﺪ را ﺑﻪ ﺑﺪوﯾﺎن ﻫﺪﯾﻪ‬
‫ﻣﯽداﻧﺪ ﯾﺎ ﺑﺎ آنﻫﺎ دادوﺳﺘﺪ ﻣﯽﮐﺮدﻧﺪ‪.‬‬

‫ﺑﺪوﯾﺎن ﺑﻪ ﮐﺎﻻﻫﺎی از ﻫﻮا رﺳﯿﺪه ﺑﺴﯿﺎر دﻟﺒﺴﺘﻪ ﺷﺪﻧﺪ‪ ،‬وﻟﯽ ﭘﺲ از ﭼﻨﺪی ﺟﻨﮓ ﭘﺎﯾﺎن ﮔﺮﻓﺖ و ارﺗﺶ ﺟﺰﯾﺮهﺷﺎن را‬
‫ﺗﺮک ﮐﺮد‪ .‬دﯾﮕﺮ ﺧﺒﺮی از ﻫﻮاﭘﯿﻤﺎﻫﺎی ﺑﺎری و ﮐﺎﻻﻫﺎی ﭼﺸﻤﮕﯿﺮﺷﺎن ﻧﺒﻮد‪ .‬ﺑﺪوﯾﺎن ﮐﻪ ﺷﯿﻔﺘﻪ آن ﮐﺎﻻﻫﺎ ﺷﺪه ﺑﻮدﻧﺪ‬
‫ﮐﻮﺷﯿﺪﻧﺪ ﺑﻪ ﺷﮑﻠﯽ ﻫﻮاﭘﯿﻤﺎﻫﺎی ﺑﺎری را ﺑﻪ ﺟﺰﯾﺮه ﺑﺎزﮔﺮداﻧﻨﺪ‪ .‬ﺑﺮای دﺳﺘﯿﺎﺑﯽ ﺑﻪ اﯾﻦ آرزو‪ ،‬ﭼﯿﺰی ﻫﻤﺎﻧﻨﺪ ﺑﺎﻧﺪ ﭘﺮواز‬
‫ﺳﺎﺧﺘﻨﺪ و در ﮐﻨﺎرش ﺑﺮجﻫﺎی ﻣﺮاﻗﺒﺖ ﭼﻮﺑﯽ و ﻣﺎﮐﺖﻫﺎی ﭼﻮﺑﯽ ﻫﻮاﭘﯿﻤﺎ‪ .‬ﻫﺮ از ﭼﻨﺪی ﻣﺮاﺳﻢ وﯾﮋهای داﺷﺘﻨﺪ و ﺑﺎ‬
‫ﻣﺸﻌﻞ دو ﺳﻮی ﺑﺎﻧﺪ ﭘﺮواز را ﻧﻮراﻧﯽ ﻣﯽﮐﺮدﻧﺪ و ﻣﺎﻧﻨﺪ ﺳﺮﺑﺎزان در ﮐﻨﺎرش رژه ﻣﯽرﻓﺘﻨﺪ و ﮔﺮوﻫﯽ دﯾﮕﺮ در اﻧﺘﻈﺎر ﻓﺮود‬
‫آ ﻣ ﺪ ن ﻫ ﻮ ا ﭘ ﯿ ﻤ ﺎ ی ﺑ ﺎ ر ی د ر ﮐ ﻨ ﺠ ﯽ ﻣ ﯽ ﻧ ﺸ ﺴ ﺘ ﻨ ﺪ‪.‬‬

‫آن ﺑﺪوﯾﺎن ﮔﻤﺎن ﻣﯽﮐﺮدﻧﺪ ﮐﻪ ﺑﺎزﺳﺎزی ﻇﺎﻫﺮ آﻧﭽﻪ دﯾﺪه ﺑﻮدﻧﺪ ﺑﺮای دﺳﺘﯿﺎﺑﯽ ﺑﻪ ﻧﺘﯿﺠﻪ ﮐﺎﻓﯿﺴﺖ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ ﺑﯽﮔﻤﺎن‬
‫اﯾﻦﭼﻨﯿﻦ ﻧﯿﺴﺖ‪ .‬اﮔﺮ ﺑﻪ آﻧﭽﻪ در ﭘﺮوژهﻫﺎ ﻣﯽﮔﺬرد ژرف ﺑﻨﮕﺮﯾﻢ‪ ،‬ﻣﺸﺎﻫﺪه ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﺑﺴﯿﺎری از اﻓﺮاد ﺗﻨﻬﺎ ﻇﺎﻫﺮ آﻧﭽﻪ‬
‫در ﭘﺮوژهﻫﺎی ﻣﻮﻓﻖ وﺟﻮد دارد را ﺑﺎزﺳﺎزی ﻣﯽﮐﻨﻨﺪ و اﻧﺘﻈﺎر دارﻧﺪ ﻣﻮﻓﻖ ﺑﺎﺷﻨﺪ‪ .‬ﭼﻨﯿﻦ ﮐﺴﺎﻧﯽ ﻫﻤﺎن اﻧﺪازه ﻣﻮﻓﻖ‬
‫ﻫﺴﺘﻨﺪ ﮐﻪ آن ﺑﺪوﯾﺎن ﺑﺎرﭘﺮﺳﺖ ﺑﻮدﻧﺪ‪.‬‬

‫ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ اﮔﺮ ﭼﯿﺰﻫﺎﯾﯽ ﻫﻤﺎﻧﻨﺪ ﺑﺮﻧﺎﻣﻪزﻣﺎﻧﯽ ‪ ،‬اﻧﮕﯿﺰه ﺗﺠﺎری )‪ (business case‬و ﻣﻨﺸﻮر ﭘﺮوژه )‪project‬‬
‫‪ (charter‬داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺧﻮﺑﯽ دارﻧﺪ و ﻣﻮﻓﻖ ﺧﻮاﻫﻨﺪ ﺷﺪ‪ .‬ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ )‪ ( Agile‬در اﯾﻦ زﻣﯿﻨﻪ‬
‫ﻣﺸﮑﻞﻫﺎی ﺑﺰرگﺗﺮی ﻫﻢ دارﻧﺪ و ﺑﺴﯿﺎری از ﮐﺴﺎﻧﯽ ﮐﻪ ﺧﻮد را »ﭼﺎﺑﮏﮐﺎر« ﻣﯽداﻧﻨﺪ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ داﺷﺘﻦ اﻧﺒﻮﻫﯽ از‬
‫ﺑﺮﮔﻪﻫﺎی رﻧﮓووارﻧﮓ روی ﺗﺨﺘﻪﻫﺎی ﺑﺰرگ‪ ،‬اﺳﺘﻔﺎده از ﺑﺮﭼﺴﺐﻫﺎی راﯾﺞ در اﺳﮑﺮام‪ ،‬و ﺑﺮﮔﺰاری ﻣﺮاﺳﻢ وﯾﮋه روزاﻧﻪ‬
‫ﺑﺮای ﭼﺎﺑﮏ ﺑﻮدن ﺑﺲ اﺳﺖ‪) .‬در اداﻣﻪ ﮐﺘﺎب ﻣﻔﻬﻮم ﭼﺎﺑﮑﯽ را ﺑﺮرﺳﯽ ﺧﻮاﻫﯿﻢ ﮐﺮد‪(.‬‬

‫آﻧﭽﻪ در ﻫﻤﻪ اﯾﻦ ﻣﻮارد‪ ،‬از ﺑﺪوﯾﺎن ﮔﺮﻓﺘﻪ ﺗﺎ ﭼﺎﺑﮏﮐﺎران ﻇﺎﻫﺮی و ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎی ﺳﻄﺤﯽ از ﻗﻠﻢ اﻓﺘﺎده اﺳﺖ‪ ،‬ﺗﻮﺟﻪ ﺑﻪ‬
‫ﻣﺎﻫﯿﺖ راﺳﺘﯿﻦ ﮐﺎرﻫﺎ و ﻓﺮآﯾﻨﺪﻫﺎی ﭘﺸﺖﭘﺮده اﺳﺖ‪ .‬اﺳﻨﺎد و ﻣﺮاﺳﻢ ﻓﻘﻂ اﺑﺰارﻫﺎﯾﯽ ﺑﺮای ﺑﻪ ﺟﺮﯾﺎن اﻧﺪاﺧﺘﻦ روﻧﺪ‬
‫وﯾﮋهای از ﮐﺎر ﻫﺴﺘﻨﺪ و ﻧﻪ ﻫﺪف ﻏﺎﯾﯽ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪.‬‬

‫ﺗﻮﺟﻪ ﺑﻪ اﺻﻞﻫﺎ راه ﺧﻮﺑﯽ ﺑﺮای ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺴﺎﯾﻞ واﻗﻌﯿﺴﺖ‪ .‬ﺗﺮﺟﯿﺢ ﻣﯽدﻫﯿﻢ ﮐﻪ روﻧﺪ اﻧﺪﯾﺸﻪﻣﺎن را ﺑﺎ اﺻﻞﻫﺎ آﻏﺎز‬
‫ﮐﻨﯿﻢ و ﺑﺮ ﭘﺎﯾﻪ آن ﺑﻪﺗﺪرﯾﺞ ﻓﺮآﯾﻨﺪ ﮐﺎر و ﺳﺮاﻧﺠﺎم اﺳﻨﺎد و ﻣﺮاﺳﻢ را ﺷﮑﻞ دﻫﯿﻢ ﺗﺎ ﮔﺮﻓﺘﺎر ﺑﺎرﭘﺮﺳﺘﯽ ﻧﺸﻮﯾﻢ‪ .‬از اﯾﻦ‬
‫ر و ﺳ ﺖ ﮐ ﻪ ﭘ ﻢ ﺑ ﺎ ک ‪ ۷‬ا ﺻ ﻞ ﻣ ﺤ ﻮ ر ﺷ ﺪ ه ا ﺳ ﺖ‪.‬‬

‫—‪—8‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺤﺘﻮای اﺻﻠﯽ ﭘﻢﺑﺎک ‪ ۷‬اﺻﻞﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه و ﻫﺪف آن‪ ،‬دﺳﺖﮐﻢ از دﯾﺪﮔﺎه ﻣﻦ‪ ،‬ﺟﻠﻮﮔﯿﺮی از ﺑﺎرﭘﺮﺳﺘﯽ در‬
‫ﭘﺮوژهﻫﺎﺳﺖ‪ .‬اﯾﻦ اﺻﻞﻫﺎ را در اداﻣﻪ اﯾﻦ ﻓﺼﻞ ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ و ﭘﯿﺶ از ﭘﺎﯾﺎن دادن ﺑﻪ اﯾﻦ ﻓﺼﻞ‪ ،‬ﭼﮑﯿﺪهای از ﺑﺮﺧﯽ‬
‫ﻣﺠﻤﻮﻋﻪ اﺻﻞﻫﺎی دﯾﮕﺮ را ﻫﻢ ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ ﺗﺎ دﯾﺪ ﺑﺎزﺗﺮی ﺑﻪ اﯾﻦ ﻣﻮﺿﻮع ﭘﯿﺪا ﮐﻨﯿﺪ‪.‬‬

‫‪ . 1 . 2‬ا ﺻ ﻞ ﻫﺎ ی ﭘ ﻢﺑﺎ ک‬

‫ﭘﻢﺑﺎک ‪ ۱۲‬اﺻﻞ دارد‪ .‬ﺑﺮﺧﯽ از اﯾﻦ اﺻﻞﻫﺎ درﺑﺎره ﻣﻔﺎﻫﯿﻤﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﻪﺳﺎدﮔﯽ ﻗﺎﺑﻞﻧﺎمﮔﺬاری ﻧﯿﺴﺘﻨﺪ و از اﯾﻦ رو‬
‫ﺷﺎﯾﺪ ﻧﺎم ﺑﺮﺧﯽ از آنﻫﺎ ﺑﺮاﯾﺘﺎن ﻧﺎﻣﻔﻬﻮم ﺑﺎﺷﺪ‪ .‬وﻟﯽ ﻧﮕﺮان ﻧﺒﺎﺷﯿﺪ‪ ،‬ﭼﻮن ﻫﻤﻪ آنﻫﺎ را ﺑﻪﺗﻔﺼﯿﻞ ﺑﺮرﺳﯽ ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫اﺻﻞﻫﺎی ﭘﻢﺑﺎک ازاﯾﻦﻗﺮارﻧﺪ‪:‬‬

‫‪ .1‬ﺧﺪﻣﺘﮕﺰاری ﮐﻮﺷﺎ‪ ،‬ﻓﺮﻫﯿﺨﺘﻪ و دﻟﺴﻮز ﺑﺎﺷﯿﺪ‪.‬‬

‫‪ .2‬ﺑﺴﺘﺮ ﻣﻨﺎﺳﺒﯽ ﺑﺮای ﻫﻤﮑﺎری در ﺗﯿﻢ ﭘﺮوژه ﻓﺮاﻫﻢ ﮐﻨﯿﺪ‪.‬‬
‫‪ .3‬ذیﻧﻔﻌﺎن را در ﭘﺮوژه ﻣﺸﺎرﮐﺖ دﻫﯿﺪ‪.‬‬
‫‪ .4‬ﺑﺮ ارزشآﻓﺮﯾﻨﯽ ﺗﻤﺮﮐﺰ ﮐﻨﯿﺪ‪.‬‬
‫‪ .5‬ﺑﺎ درک ﺑﺎﯾﺴﺘﻪ و ﻣﻮﺷﮑﺎﻓﺎﻧﻪ ﺑﻪ ﻫﻤﮑﻨﺶﻫﺎی ﺳﯿﺴﺘﻤﯽ واﮐﻨﺶ ﻧﺸﺎن دﻫﯿﺪ‪.‬‬
‫‪ .6‬رﻫﺒﺮی را دﺳﺖﮐﻢ ﻧﮕﯿﺮﯾﺪ‪.‬‬
‫‪ .7‬ﺳﯿﺴﺘﻢ را ﺑﺮای ﻣﺤﯿﻂ ﭘﺮوژه اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﻨﯿﺪ‪.‬‬
‫‪ .8‬ﮐﯿﻔﯿﺖ را در ﻓﺮآﯾﻨﺪﻫﺎ و ﻣﺤﺼﻮلﻫﺎ ﻧﻬﺎدﯾﻨﻪ ﮐﻨﯿﺪ‪.‬‬
‫‪ .9‬واﮐﻨﺶﻫﺎﯾﯽ درﺧﻮر ﺑﻪ رﯾﺴﮏﻫﺎ ﻧﺸﺎن دﻫﯿﺪ‪.‬‬
‫‪ .10‬راه ﺧﻮد را در ﭘﯿﭽﯿﺪﮔﯽﻫﺎ ﺑﯿﺎﺑﯿﺪ‪.‬‬
‫‪ .11‬اﺳﺘﻮار و ﺗﻄﺒﯿﻖﭘﺬﯾﺮ ﺑﺎﺷﯿﺪ‪.‬‬
‫‪ .12‬از ﺗﻐﯿﯿﺮﻫﺎﯾﯽ ﮐﻪ ﺑﺮای دﺳﺘﯿﺎﺑﯽ ﺑﻪ آﯾﻨﺪه دﻟﺨﻮاه ﻻزﻣﻨﺪ ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﯿﺪ‪.‬‬

‫ﻣﻮردی ﮐﻪ در اﯾﻦ ﻓﻬﺮﺳﺖ ﺑﻪ ﭼﺸﻢ ﻧﻤﯽﺧﻮرد‪ ،‬اﺧﻼق و رﻓﺘﺎر ﺣﺮﻓﻪای اﺳﺖ‪ .‬دﻟﯿﻠﺶ اﯾﻦ اﺳﺖ ﮐﻪ اﺧﻼق ﺑﻪﻣﻮازات اﯾﻦ‬
‫ﻣﻮارد ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ در ﺳﻄﺤﯽ ﺑﺎﻻﺗﺮ ﻗﺮار ﻣﯽﮔﯿﺮد و ﺑﺮ ﻫﻤﻪ اﯾﻦ اﺻﻞﻫﺎ اﺛﺮ ﻣﯽﮔﺬارد‪ .‬ﮔﺬﺷﺘﻪ از اﯾﻦﮐﻪ اﺧﻼق در ﭼﻪ‬
‫ﺟﺎﯾﮕﺎﻫﯽ ﻗﺮار ﻣﯽﮔﯿﺮد‪ ،‬ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ ﺑﻪ آن ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪.‬‬

‫ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﻢ درﺑﺎره اﯾﻦ ﻣﻮﺿﻮع آﯾﯿﻦﻧﺎﻣﻪ اﺧﻼق و رﻓﺘﺎر ﺣﺮﻓﻪای ‪ PMI‬را ﻣﻄﺎﻟﻌﻪ ﮐﻨﯿﺪ‪:‬‬
‫‪https://www.pmi.org/codeofethics‬‬

‫‪ .1.1.2‬ﺧﺪﻣﺘﮕﺰاری ﮐﻮﺷﺎ‪ ،‬ﻓﺮﻫﯿﺨﺘﻪ و دﻟﺴﻮز ﺑﺎﺷﯿﺪ‬

‫اﮔﺮ از ﺻﺪﻫﺎ ﻧﻔﺮ ﮐﻪ در ﭘﺮوژهﻫﺎ ﮐﺎر ﮐﺮدهاﻧﺪ ﺑﭙﺮﺳﯿﺪ ﮐﻪ ﭼﻪ ﺗﺠﺮﺑﻪای در ﮐﺎر ﺑﺎ ﻣﺪﯾﺮان ﭘﺮوژهﻫﺎ دارﻧﺪ‪ ،‬دﺳﺖﮐﻢ‬
‫ﺑﺮﺧﯽﺷﺎن ﻣﯽﺗﻮاﻧﻨﺪ داﺳﺘﺎنﻫﺎی ﻓﺮاواﻧﯽ ﺑﮕﻮﯾﻨﺪ از ﻣﺪﯾﺮان ﭘﺮوژه ﻧﺎﮐﺎرآﻣﺪی ﮐﻪ ﻫﯿﭻ درﮐﯽ از ﮐﺎر ﻧﺪارﻧﺪ و ﺑﺎاﯾﻦﻫﻤﻪ در‬
‫ﮐﺎرﻫﺎی ﻓﻨﯽ دﺧﺎﻟﺖ ﻣﯽﮐﻨﻨﺪ و از اﻓﺮاد اﻧﺘﻈﺎرﻫﺎی ﻏﯿﺮواﻗﻌﯽ دارﻧﺪ‪ .‬ﺑﻪ دﻻﯾﻠﯽ‪ ،‬اﯾﻦ ﭼﺎﻟﺶﻫﺎ در ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری‬
‫ﺣﺎدﺗﺮ ﺑﻮدهاﻧﺪ‪ ،‬ﺗﺎاﻧﺪازهای ﮐﻪ ﺑﺮﺧﯽ از روشﻫﺎی ﮐﻤﺎﺑﯿﺶ ﻧﻮﯾﻦ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﺑﺎ وﺟﻮد ﻧﻘﺶ ﻣﺪﯾﺮ‬

‫—‪—9‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﭘﺮوژه ﻣﺨﺎﻟﻔﺖ ﻣﯽﮐﻨﻨﺪ‪.‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﯿﺸﺘﺮ اﻓﺮاد ﺳﺎزﻣﺎنﻫﺎی ﺑﺴﯿﺎری را ﻣﯽﺷﻨﺎﺳﻨﺪ ﮐﻪ ﺧﺒﺮهﺗﺮﯾﻦ ﻣﺘﺨﺼﺼﺎن ﻓﻨﯽ ﺧﻮد را ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ‬
‫ﭘﺮوژه اﻧﺘﺨﺎب ﻣﯽﮐﻨﻨﺪ‪ .‬ﺑﺮﺧﯽ ﻫﻢ ﺑﺎور دارﻧﺪ ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﺷﺪن‪ ،‬ﯾﺎ ﺑﻪﻃﻮرﮐﻠﯽ ﻣﺪﯾﺮ ﺷﺪن‪ ،‬روﻧﺪ ﻃﺒﯿﻌﯽ رﺷﺪ ﺣﺮﻓﻪای‬
‫ﺑﺮای ﯾﮏ ﻣﺘﺨﺼﺺ ﻓﻨﯿﺴﺖ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ در اﯾﻦ روﻧﺪ ﺳﺎزﻣﺎنﻫﺎ ﻣﺘﺨﺼﺺﻫﺎی ﻓﻨﯽ ﺧﺒﺮه ﺧﻮد را از دﺳﺖ ﻣﯽدﻫﻨﺪ و‬
‫ﺑﻪﺟﺎﯾﺶ ﻣﺪﯾﺮاﻧﯽ ﻧﺎﮐﺎرآﻣﺪ ﺑﻪ دﺳﺖ ﻣﯽآورﻧﺪ‪.‬‬

‫‪ .1.1.1.2‬ارﺗﻘﺎی ﻣﻘﺎم ﯾﺎ ﺗﻐﯿﯿﺮ ﺣﺮﻓﻪ‬

‫ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﻣﺘﺨﺼﺼﯽ ﻓﻨﯽ ﺗﺒﺪﯾﻞ ﺑﻪ ﻣﺪﯾﺮ ﻣﯽﺷﻮد‪ ،‬ارﺗﻘﺎی ﻣﻘﺎم ﭘﯿﺪا ﻧﮑﺮده‪ ،‬ﺑﻠﮑﻪ ﺣﺮﻓﻪاش ﺗﻐﯿﯿﺮ ﮐﺮده اﺳﺖ‪ .‬ﺧﺒﺮﮔﯽ‬
‫در ﻣﺴﺎﯾﻞ ﻓﻨﯽ ﺗﻀﻤﯿﻨﯽ ﺑﺮای ﺧﺒﺮه ﺑﻮدن در ﻣﺴﺎﯾﻞ ﻣﺪﯾﺮﯾﺘﯽ ﻧﯿﺴﺖ‪ ،‬زﯾﺮا اﯾﻦ دو ﻧﯿﺎز ﺑﻪ ﻣﻬﺎرتﻫﺎ و ﺷﺨﺼﯿﺖﻫﺎی‬
‫ﮐﺎﻣﻼ ﻣﺘﻔﺎوﺗﯽ دارﻧﺪ‪ .‬ﻋﻼﻗﻪ واﻗﻌﯽ ﺑﺮﺧﯽ اﻓﺮاد ﺑﻪ اﻧﺠﺎم ﮐﺎرﻫﺎی ﻓﻨﯿﺴﺖ و ﻣﺪﯾﺮ ﺷﺪن‪ ،‬ﮐﻪ ﮔﺎﻫﯽ ﻧﺎﭼﺎرﻧﺪ ﺑﻪ دﻟﯿﻞ‬
‫ﻓﺸﺎرﻫﺎی ﻣﺤﯿﻄﯽ ﺑﭙﺬﯾﺮﻧﺪ‪ ،‬ﮐﺎر را ﺑﺮاﯾﺸﺎن ﺗﻠﺦ ﻣﯽﮐﻨﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﭼﻨﯿﻦ ﮐﺴﺎﻧﯽ ﺑﯿﺸﺘﺮ اوﻗﺎت ﻧﯿﺰ ﻣﺪﯾﺮان ﺧﻮﺑﯽ‬
‫ﻧﻤﯽﺷﻮﻧﺪ و ﺑﻪ ﻣﻮﻓﻘﯿﺖ ﭘﺮوژهﻫﺎ آﺳﯿﺐ ﻣﯽزﻧﻨﺪ‪.‬‬

‫روﯾﮑﺮد ﻣﻨﺎﺳﺐ اﯾﻦ اﺳﺖ ﮐﻪ اﻓﺮادی ﮐﻪ ﻋﻼﻗﻪ ﺑﻪ ﮐﺎر ﻓﻨﯽ دارﻧﺪ در ﺣﺮﻓﻪ ﺧﻮد ﺑﺎﻗﯽ ﺑﻤﺎﻧﻨﺪ و از راهﻫﺎی دﯾﮕﺮی ارﺗﻘﺎی‬
‫ﻣﻘﺎم ﭘﯿﺪا ﮐﻨﻨﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻫﺮ ﺳﺎزﻣﺎﻧﯽ ﺑﺎﯾﺪ ﺑﺮ ﯾﺎﻓﺘﻦ و ﭘﺮورش ﻣﺪﯾﺮ ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﻨﺪ‪ .‬وﺟﻮد رﺷﺘﻪﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ‬
‫ﻣ ﻨ ﺎ ﺳ ﺐ د ر د ا ﻧ ﺸ ﮕ ﺎ ه ﻫ ﺎ ﻧ ﯿ ﺰ ﺑ ﻪ د ﺳ ﺘ ﺎ ﺑ ﯽ ﺑ ﻪ ا ﯾ ﻦ ﻫ ﺪ ف ﮐ ﻤ ﮏ ﻣ ﯽ ﮐ ﻨ ﺪ‪.‬‬

‫‪ .2.1.1.2‬ﻣﺪﯾﺮ ﭘﺮوژه واﻗﻌﯽ‬

‫ﻣﺪﯾﺮ ﭘﺮوژه واﻗﻌﯽ رﺋﯿﺲ ﻧﯿﺴﺖ! ﻫﺮ ﭼﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﯿﺸﺘﺮ ﺳﺎزﻣﺎنﻫﺎ ﮐﻤﺒﻮد رﺋﯿﺲ ﻧﺪارﻧﺪ‪ .‬آﻧﭽﻪ ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژه ﻧﯿﺎز‬
‫دارﯾﻢ‪ ،‬ﮐﺴﺎﻧﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺘﻮاﻧﻨﺪ از ﺗﯿﻢ ﭘﺮوژه ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﻨﺪ و ﺑﺎ ﺗﺴﻬﯿﻞﮔﺮی و ﮔﺮهﮔﺸﺎﯾﯽ زﻣﯿﻨﻪای ﻓﺮاﻫﻢ ﮐﻨﻨﺪ ﮐﻪ‬
‫اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﺑﺘﻮاﻧﻨﺪ ﮐﺎرﻫﺎی ﺗﺨﺼﺼﯽ ﺧﻮد را ﺑﻪ ﺑﻬﺘﺮﯾﻦ ﺷﮑﻞ اﻧﺠﺎم دﻫﻨﺪ‪.‬‬

‫ﻫﺮ ﺑﺮﭼﺴﺒﯽ ﺑﺎر ﻣﻌﻨﺎﯾﯽ وﯾﮋه ﺧﻮد را دارد ﮐﻪ در ﻃﯽ ﺳﺎلﻫﺎ ﺑﺮ ﭘﺎﯾﻪ ﺗﺠﺮﺑﻪﻫﺎ و روﯾﺪادﻫﺎی ﻓﺮاوان ﺷﮑﻞ ﮔﺮﻓﺘﻪ اﺳﺖ‪.‬‬
‫اﮔﺮ ﮔﻤﺎن ﻣﯽﮐﻨﯿﺪ ﺑﺮﭼﺴﺐ »ﻣﺪﯾﺮ ﭘﺮوژه« ﺑﺎر ﻣﻌﻨﺎﯾﯽ ﻣﻨﺎﺳﺒﯽ در ﺳﺎزﻣﺎﻧﺘﺎن ﻧﺪارد‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪﺟﺎی آن از ﺑﺮﭼﺴﺐ‬
‫دﯾﮕﺮی اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪ .‬ﭘﯿﺸﻨﻬﺎد ﻫﻤﯿﺸﮕﯽ ﻣﻦ ﺑﺮای ﺟﺎﻧﺸﯿﻨﯽ اﯾﻦ ﺑﺮﭼﺴﺐ‪» ،‬ﺗﺴﻬﯿﻞﮔﺮ ارﺷﺪ ﭘﺮوژه« اﺳﺖ‪ .‬ﺑﻬﺮهﻣﻨﺪی‬
‫از ﭼﻨﯿﻦ ﺑﺮﭼﺴﺒﯽ داﯾﻤﺎ ﻣﻔﻬﻮم واﻗﻌﯽ ﻣﺪﯾﺮ ﭘﺮوژه را ﺑﻪ او و دﯾﮕﺮان ﯾﺎدآوری ﻣﯽﮐﻨﺪ‪ .‬اﻟﺒﺘﻪ ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ اﯾﻦ‬
‫ﭘﯿﺸﻨﻬﺎد ﻣﻦ ﺑﯿﺸﺘﺮ ﺑﺮای ﺷﺮﮐﺖﻫﺎی ﻧﺮماﻓﺰارﯾﺴﺖ ﮐﻪ ﺗﺼﻮﯾﺮ ﻧﺎﭘﺴﻨﺪی از ﻣﺪﯾﺮ ﭘﺮوژه دارﻧﺪ‪ ،‬وﮔﺮﻧﻪ ﻣﻔﻬﻮم ﻣﺪﯾﺮ ﭘﺮوژه‬
‫در ﺳﺎﯾﺮ ﭘﺮوژهﻫﺎ‪ ،‬ﺑﻪوﯾﮋه در اﯾﺮان‪ ،‬ﺑﺎر ﻣﻌﻨﺎﯾﯽ ﻣﻨﻔﯽ ﻧﺪارد )دﺳﺖﮐﻢ ﺗﺎ ﺟﺎﯾﯽ ﮐﻪ ﻣﻦ اﻃﻼع دارم( و ﺑﻨﺎﺑﺮاﯾﻦ ﻧﯿﺎزی ﺑﻪ‬
‫اﯾﻦ راﻫﮑﺎر ﻧﺨﻮاﻫﻨﺪ داﺷﺖ‪.‬‬

‫‪ .3.1.1.2‬درک ﻣﺴﺎﯾﻞ ﻓﻨﯽ‬

‫اﮔﺮ اﻧﺘﻈﺎرﻣﺎن از ﻣﺪﯾﺮ ﭘﺮوژه ﭘﺸﺘﯿﺒﺎﻧﯽ و ﺗﺴﻬﯿﻞﮔﺮی ﻏﯿﺮﻓﻨﯽ ﺑﺎﺷﺪ‪ ،‬ﻗﺎﻋﺪﺗﺎ ﺑﺴﯿﺎری از اﯾﻦ اﻓﺮاد اﻃﻼﻋﺎت ﻓﻨﯽ ﮐﺎﻓﯽ‬
‫ﺑﺮای ﺑﺮﻧﺎﻣﻪرﯾﺰی و ﮐﻨﺘﺮل ﭘﺮوژه ﯾﺎ ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﮐﻼن ﻓﻨﯽ ﻧﺨﻮاﻫﻨﺪ داﺷﺖ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﻪﺟﺎی اﯾﻦﮐﻪ ﺷﺨﺼﺎ ﭼﻨﯿﻦ‬
‫ﮐﺎرﻫﺎﯾﯽ را اﻧﺠﺎم دﻫﻨﺪ‪ ،‬ﺑﺎﯾﺪ از اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﮐﻤﮏ ﺑﮕﯿﺮﻧﺪ‪ .‬ﺑﺎﯾﺪ ﺑﺎ ﻣﻬﺎرﺗﯽ ﮐﻪ در ﺑﺮﻧﺎﻣﻪرﯾﺰی‪ ،‬ﺗﺴﻬﯿﻞﮔﺮی و ﺳﺎﯾﺮ‬

‫— ‪— 10‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﻮارد ﻣﺪﯾﺮﯾﺘﯽ دارﻧﺪ ﺑﻪ اﯾﻦ اﻓﺮاد ﮐﻤﮏ ﮐﻨﻨﺪ ﺗﺎ ﺧﻮدﺷﺎن ﭘﺮوژه را ﺑﻪ ﺷﮑﻞ ﻣﻨﺎﺳﺐ ﺑﺴﺎزﻧﺪ‪ .‬ﻣﻨﻈﻮر از ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬
‫و ا ﻗ ﻌ ﯽ ا ﯾ ﻦ ا ﺳ ﺖ‪.‬‬

‫آﯾﺎ ﺑﻪ ﻧﻈﺮﺗﺎن ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ اﻃﻼﻋﺎت ﻓﻨﯽ داﺷﺘﻪ ﺑﺎﺷﺪ؟‬

‫ﺳﻪ ﭘﺎﺳﺦ ﺑﺮای اﯾﻦ ﭘﺮﺳﺶ ﻣﻤﮑﻦ اﺳﺖ‪:‬‬

‫‪ .1‬ﺑﻠﻪ‪ ،‬ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ اﻃﻼﻋﺎت ﻓﻨﯽ داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫‪ .2‬اﻟﺰاﻣﯽ ﻧﯿﺴﺖ ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه اﻃﻼﻋﺎت ﻓﻨﯽ داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬وﻟﯽ اﮔﺮ داﺷﺘﻪ ﺑﺎﺷﺪ ﺷﺎﯾﺪ ﺑﻬﺘﺮ ﺑﺎﺷﺪ‪.‬‬
‫‪ .3‬ﺧﯿﺮ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه اﻃﻼﻋﺎت ﻓﻨﯽ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﻧﺨﺴﺘﯿﻦ ﭘﺎﺳﺦ روﯾﮑﺮدی ﺳﻨﺘﯿﺴﺖ ﮐﻪ ﭼﻪﺑﺴﺎ در ﺑﺴﯿﺎری از ﺳﺎزﻣﺎنﻫﺎ دﯾﺪه ﺑﺎﺷﯿﺪ‪ .‬اﯾﻦ روﯾﮑﺮد ﻣﺤﺪود ﺑﻪ اﯾﺮان ﻫﻢ‬
‫ﻧﯿﺴﺖ و در ﻫﻤﻪ ﮐﺸﻮرﻫﺎ وﺟﻮد دارد‪.‬‬

‫روﯾﮑﺮد دوم ﮐﻤﺎﺑﯿﺶ ﻧﻮﯾﻦ و ﺑﺎاﯾﻦﻫﻤﻪ ﮐﻤﯽ ﻣﺤﺎﻓﻈﻪﮐﺎراﻧﻪ اﺳﺖ‪ .‬اﯾﻦ روﯾﮑﺮد ﺑﺎ آﻧﭽﻪ ﺗﺎﮐﻨﻮن ﮔﻔﺘﻪ ﺷﺪ ﻫﻤﺎﻫﻨﮓ اﺳﺖ‬
‫و ﻣﯽﺗﻮان ﮔﻔﺖ ﮐﻪ ‪ PMI‬ﻫﻢ ﭼﻨﯿﻦ دﯾﺪﮔﺎﻫﯽ دارد‪.‬‬

‫ﺳﻮﻣﯿﻦ ﭘﺎﺳﺦ روﯾﮑﺮدی ﮐﺎﻣﻼ ﭘﯿﺸﺮوﺳﺖ ﮐﻪ درﮐﺶ ﺑﺮای ﺑﺴﯿﺎری از اﻓﺮاد ﭼﺎﻟﺶﺑﺮاﻧﮕﯿﺰ اﺳﺖ‪ .‬ﮔﺮوﻫﯽ‪ ،‬ازﺟﻤﻠﻪ ﻣﻦ‪ ،‬از‬
‫آن ﻃﺮﻓﺪاری ﻣﯽﮐﻨﻨﺪ‪.‬‬

‫ﻓﺮض ﮐﻨﯿﺪ ﻣﺪﯾﺮ ﭘﺮوژهای ﻫﺴﺘﯿﺪ ﮐﻪ در ﺟﻨﺒﻪﻫﺎی ﻓﻨﯽاش ﻧﯿﺰ ﺗﺨﺼﺺ دارﯾﺪ‪ .‬اﮔﺮ ﺑﺒﯿﻨﯿﺪ ﮐﻪ ﮐﺎری ﮐﻪ ﺗﯿﻢ ﭘﺮوژه اﻧﺠﺎم‬
‫داده اﺳﺖ از ﻧﻈﺮ ﻓﻨﯽ اﯾﺪهآل ﻧﯿﺴﺖ ﭼﻪ ﻣﯽﮐﻨﯿﺪ؟ آﯾﺎ ﻣﯽﺗﻮاﻧﯿﺪ ﺟﻠﻮی ﺧﻮد را ﺑﮕﯿﺮﯾﺪ و وارد ﻣﺴﺎﯾﻞ ﻓﻨﯽ ﻧﺸﻮﯾﺪ؟‬
‫ﺑﯿﺸﺘﺮ اﻓﺮاد ﻧﻤﯽﺗﻮاﻧﻨﺪ و ﺑﯿﺸﺘﺮ و ﺑﯿﺸﺘﺮ درﮔﯿﺮ ﮐﺎرﻫﺎی ﻓﻨﯽ ﭘﺮوژه ﻣﯽﺷﻮﻧﺪ‪ .‬در ﭘﺎﯾﺎن‪ ،‬ﻣﺴﺌﻠﻪ ﭼﻨﺎن ﮔﺴﺘﺮده ﻣﯽﺷﻮد‬
‫ﮐﻪ در ﻋﻤﻞ آن ﻓﺮد ﻧﻘﺶ ﯾﮏ ﻣﺘﺨﺼﺺ ارﺷﺪ را ﺑﺎزی ﻣﯽﮐﻨﺪ و ﺳﻤﺖ ﻣﺪﯾﺮ ﭘﺮوژه ﺑﻪ ﺣﺎل ﺧﻮد رﻫﺎ ﻣﯽﺷﻮد‪ .‬وﻗﺘﯽ از‬
‫اﯾﻦ زاوﯾﻪ ﺑﻪ ﻣﺴﺌﻠﻪ ﻧﮕﺎه ﮐﻨﯿﻢ روﺷﻦ ﻣﯽﺷﻮد ﮐﻪ ﺑﻬﺘﺮ اﺳﺖ آن ﻓﺮد را وادار ﺑﻪ ﭘﺬﯾﺮﻓﺘﻦ ﺳﻤﺖ ﻣﺪﯾﺮﯾﺘﯽ ﻧﮑﻨﯿﻢ ﺗﺎ ﮐﺎری‬
‫ﮐﻪ ﺑﺮاﯾﺶ ﺟﺬابﺗﺮ اﺳﺖ را اﻧﺠﺎم دﻫﺪ )ﻧﮑﺘﻪای ﮐﻪ ﭘﯿﺸﺘﺮ ﻣﻄﺮح ﺷﺪ( و ﻓﺮدی ﻗﺎﺑﻞ ﺑﺮای ﻫﻤﺎﻫﻨﮕﯽﻫﺎ و‬
‫ﺗﺴﻬﯿﻞﮔﺮیﻫﺎی ﭘﺮوژه اﻧﺘﺨﺎب ﮐﺮده‪ ،‬ﺑﻪ ﺳﻤﺖ ﻣﺪﯾﺮ ﭘﺮوژه ﻣﻨﺼﻮب ﮐﻨﯿﻢ‪.‬‬

‫اﮔﺮ ﻣﺪﯾﺮ ﭘﺮوژه در ﻣﺴﺎﯾﻞ ﻓﻨﯽ ﭘﺮوژه ﺧﺒﺮه ﻧﺒﺎﺷﺪ‪ ،‬ﭼﺎﻟﺸﯽ ﮐﻪ ﮔﻔﺘﻪ ﺷﺪ ﺑﻪ وﺟﻮد ﻧﺨﻮاﻫﺪ آﻣﺪ و آن ﻓﺮد ﺑﻪﺳﺎدﮔﯽ‬
‫ﻣﯽﺗﻮاﻧﺪ ﺑﺮ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ﺗﻤﺮﮐﺰ ﮐﻨﺪ‪ .‬از اﯾﻦ روﺳﺖ ﮐﻪ ﺑﺮﺧﯽ روﯾﮑﺮد ﺳﻮم را ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ‪.‬‬

‫‪ .4.1.1.2‬ﭘﺬﯾﺮش ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎی ﻏﯿﺮﻓﻨﯽ‬

‫اﮔﺮ اﺳﺘﺪﻻل ﺑﺨﺶ ﭘﯿﺸﯿﻦ ﺑﺮاﯾﺘﺎن ﭘﺬﯾﺮﻓﺘﻨﯽ ﺑﺎﺷﺪ‪ ،‬ﺑﺎز ﻫﻢ دو ﭼﺎﻟﺶ ﮐﻼن در ﻋﻤﻞ وﺟﻮد ﺧﻮاﻫﺪ داﺷﺖ‪ .‬ﻧﺨﺴﺘﯿﻦ‬
‫ﭼﺎﻟﺶ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺴﯿﺎری از ﮐﺴﺎﻧﯽ ﮐﻪ در ﭘﺮوژهﻫﺎ ﮐﺎر ﻣﯽﮐﻨﻨﺪ ﻣﺪﯾﺮ ﭘﺮوژهای ﮐﻪ ﻣﻬﺎرت ﻓﻨﯽ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ را‬
‫ﻧﻤﯽﭘﺬﯾﺮﻧﺪ‪ .‬اﮔﺮ ﭼﻨﯿﻦ ﻣﺪﯾﺮ ﭘﺮوژهای ﺑﺎﺷﯿﺪ‪ ،‬ﺑﺎﯾﺪ در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ رﯾﺸﻪ دﺷﻮاری اﯾﻦ اﺳﺖ ﮐﻪ اﯾﻦ اﻓﺮاد‬
‫ﭼﻪﺑﺴﺎ ﻫﯿﭻﮔﺎه ﻣﺪﯾﺮ ﭘﺮوژه واﻗﻌﯽ ﻧﺪﯾﺪهاﻧﺪ‪ .‬ﻫﻤﻪ ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ داﺷﺘﻪاﻧﺪ ﻣﺘﺨﺼﺺﻫﺎی ارﺷﺪی ﺑﻮدهاﻧﺪ ﮐﻪ‬
‫ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﮐﻼن ﻓﻨﯽ ﺑﺮ دوﺷﺸﺎن ﺑﻮده اﺳﺖ و ﺑﻪﺟﺎی ﮐﻞ ﺗﯿﻢ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻣﯽﮐﺮدهاﻧﺪ‪ .‬ﻗﺎﻋﺪﺗﺎ ﺑﺮای اﻧﺠﺎم ﭼﻨﯿﻦ‬
‫ﮐﺎری ﺑﺎﯾﺪ ﻣﻬﺎرت ﻓﻨﯽ داﺷﺖ و از اﯾﻦ روﺳﺖ ﮐﻪ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﻓﺮدی ﻏﯿﺮﻓﻨﯽ ﻧﻤﯽﺗﻮاﻧﺪ ﭘﺮوژهﺷﺎن را ﻣﺪﯾﺮﯾﺖ ﮐﻨﺪ‪.‬‬

‫— ‪— 11‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫راﻫﮑﺎر اﯾﻦ اﺳﺖ ﮐﻪ از آﻏﺎز ﺑﺎ ﺷﻔﺎﻓﯿﺖ ﻣﺴﺌﻠﻪ را ﺑﺮاﯾﺸﺎن روﺷﻦ ﮐﻨﯿﺪ‪ .‬ﺗﻮﺿﯿﺢ دﻫﯿﺪ ﮐﻪ ﻗﺮار ﻧﯿﺴﺖ ﺑﺮاﯾﺸﺎن‬
‫ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﻓﻨﯽ اﻧﺠﺎم دﻫﯿﺪ‪ ،‬ﺑﻠﮑﻪ ﻧﻘﺸﺘﺎن ﭘﺸﺘﯿﺒﺎﻧﯽ از ﺗﯿﻢ ﭘﺮوژه و ﻓﺮاﻫﻢ ﮐﺮدن ﻓﻀﺎی ﮐﺎری ﻣﻨﺎﺳﺐ اﺳﺖ‪.‬‬
‫ﺑﯽﮔﻤﺎن ﺳﺨﻦ ﮔﻔﺘﻦ در اﯾﻦ ﺑﺎره ﮐﺎﻓﯽ ﻧﯿﺴﺖ و ﻧﯿﺎز اﺳﺖ ﮐﻪ ﻫﺮ ﭼﻪ زودﺗﺮ آن را در ﻋﻤﻞ ﺑﻪ ﺗﯿﻢ ﻧﺸﺎن دﻫﯿﺪ ﺗﺎ‬
‫ﺑﺘﻮاﻧﯿﺪ اﻋﺘﻤﺎدﺷﺎن را ﺟﻠﺐ ﮐﻨﯿﺪ‪ .‬اﮔﺮ اﯾﻦ ﮐﺎر را ﺑﻪدرﺳﺘﯽ اﻧﺠﺎم دﻫﯿﺪ‪ ،‬ﭘﺲ از ﭼﻨﺪ ﻫﻔﺘﻪ ﺗﺎ ﭼﻨﺪ ﻣﺎه ﭘﺬﯾﺮﻓﺘﻪ ﺧﻮاﻫﯿﺪ‬
‫ﺷ ﺪ‪.‬‬

‫زﻣﺎﻧﯽ ﯾﮑﯽ از ﺑﻬﺘﺮﯾﻦ ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ ﻣﯽﺷﻨﺎﺧﺘﻢ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژهای ﻧﺮماﻓﺰاری اﻧﺘﺨﺎب ﺷﺪ و اﻋﻀﺎی ﺗﯿﻢ ﮐﺎﻣﻼ‬
‫در ﺑﺮاﺑﺮش ﺟﺒﻬﻪﮔﯿﺮی ﮐﺮده ﺑﻮدﻧﺪ زﯾﺮا او ﻫﻤﯿﺸﻪ در ﭘﺮوژهﻫﺎی ﺳﺎزﻣﺎﻧﯽ ﮐﺎر ﮐﺮده ﺑﻮد‪ .‬در آﻏﺎز ﮐﺎر آﻧﭽﻪ در ﺑﺎﻻ ﮔﻔﺘﻪ‬
‫ﺷﺪ را ﺑﻪ اﻋﻀﺎی ﺗﯿﻢ ﺗﻮﺿﯿﺢ دادم و از ﻫﻤﮕﯽ ﺧﻮاﻫﺶ ﮐﺮدم ﮐﻪ ﺑﻪ او ﻓﺮﺻﺘﯽ دﻫﻨﺪ ﮐﻪ ﭘﺮوژه را ﻣﺪﯾﺮﯾﺖ ﮐﻨﺪ و ﺑﺪون‬
‫ﭘﯿﺶداوری ﺑﺮﺧﻮرد ﮐﻨﻨﺪ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﭘﺲ از دو ﻫﻔﺘﻪ ﺑﻪ ﭘﺮوژه ﺑﺮﮔﺸﺘﻢ و از اﻓﺮاد ﺟﻮﯾﺎی ﺣﺎل ﺷﺪم‪ ،‬ﻫﻤﮕﯽ اﺑﺮاز‬
‫ﺧﺮﺳﻨﺪی ﮐﺮدﻧﺪ و ﮔﻔﺘﻨﺪ ﮐﻪ ﮔﻤﺎن ﻧﻤﯽﮐﺮدﻧﺪ ﮐﻪ ﮐﺎر ﮐﺮدن در ﭘﺮوژه ﺑﺘﻮاﻧﺪ ﺗﺎ اﯾﻦ اﻧﺪازه ﺳﺎده و ﺧﻮشآﯾﻨﺪ ﺑﺎﺷﺪ! ﯾﮑﯽ‬
‫از اﻋﻀﺎی ﺗﯿﻢ ﮔﻔﺖ ﮐﻪ ﻧﮕﺮان اﺳﺖ ﭼﮕﻮﻧﻪ ﭘﺲ از ﭘﺎﯾﺎن اﯾﻦ ﭘﺮوژه ﺑﻪ وﺿﻌﯿﺖ راﯾﺞ ﺑﺮﮔﺮدد و ﺑﺪون ﮐﻤﮏ ﭼﻨﯿﻦ ﻣﺪﯾﺮ‬
‫ﭘﺮوژهای ﮐﺎر ﮐﻨﺪ‪.‬‬

‫‪ .5.1.1.2‬اﻓﺮاد ﻓﻨﯽای ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﻣﯽﺷﻮﻧﺪ ﭼﻪ ﮐﻨﻨﺪ‬

‫در ﺑﺨﺶ ﭘﯿﺶ ﻧﺨﺴﺘﯿﻦ ﭼﺎﻟﺶ ﮐﻼن ﮐﻪ ﭘﺬﯾﺮش ﺗﯿﻢ ﺑﻮد را ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪ .‬ﭼﺎﻟﺶ دﯾﮕﺮی ﻫﻢ وﺟﻮد دارد‪ :‬ﺷﺎﯾﺪ ﻓﺮدی‬
‫ﻓﻨﯽ ﺑﺎﺷﯿﺪ ﮐﻪ ﺑﻪ دﻟﯿﻞ ﻋﻼﻗﻪ ﺑﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﭼﻨﯿﻦ ﺳﻤﺘﯽ را ﭘﺬﯾﺮﻓﺘﻪ اﺳﺖ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ رﯾﺴﮏﻫﺎﯾﯽ ﮐﻪ ﻣﺪﯾﺮﯾﺖ‬
‫ﭘﺮوژه ﺑﺮای اﻓﺮاد ﻓﻨﯽ دارد و ﭘﯿﺶازاﯾﻦ ﺑﺮرﺳﯽاش ﮐﺮدﯾﻢ‪ ،‬ﭼﻪ ﺑﺎﯾﺪ ﺑﮑﻨﯿﺪ؟‬

‫در ﭼﻨﯿﻦ ﺣﺎﻟﺘﯽ ﺑﺎﯾﺪ ﮐﺎﻣﻼ درﺑﺎره دوﮔﺎﻧﮕﯽ ﻣﺴﺎﯾﻞ ﻓﻨﯽ و ﻣﺪﯾﺮﯾﺘﯽ ﺧﻮدآﮔﺎه ﺑﺎﺷﯿﺪ‪ .‬ﻫﺮ زﻣﺎن ﮐﻪ ﻗﺮار اﺳﺖ ﺳﺨﻨﯽ‬
‫ﺑﮕﻮﯾﯿﺪ‪ ،‬ﮐﺎری اﻧﺠﺎم دﻫﯿﺪ‪ ،‬ﯾﺎ ﺗﺼﻤﯿﻤﯽ ﺑﮕﯿﺮﯾﺪ‪ ،‬از ﺧﻮد ﺑﭙﺮﺳﯿﺪ ﮐﻪ ﻣﻮﺿﻮع ﻓﻨﯿﺴﺖ ﯾﺎ ﻣﺪﯾﺮﯾﺘﯽ‪ ،‬و اﮔﺮ ﻣﺪﯾﺮﯾﺘﯽ ﻧﺒﻮد‪،‬‬
‫آن را ﺑﺮ دوش ﻓﺮد ﻣﺴﺌﻮﻟﺶ ﺑﮕﺬارﯾﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﺎ ﺗﻤﺮﯾﻦ دروﻧﯽ ﻣﯽﺷﻮد و ﭘﺲ از ﻣﺪﺗﯽ ﻧﺎﺧﻮدآﮔﺎه درﺳﺖ ﻋﻤﻞ‬
‫ﺧﻮاﻫﯿﺪ ﮐﺮد‪.‬‬

‫ﯾﮑﯽ از ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎی ﺧﺒﺮهای ﮐﻪ ﻣﯽﺷﻨﺎﺧﺘﻢ ﻣﻌﻤﺎر ﺑﻮد‪ .‬در ﯾﮑﯽ از ﭘﺮوژهﻫﺎ ﮐﻪ ﺟﻨﺒﻪﻫﺎی ﻣﻌﻤﺎراﻧﻪ ﺣﺴﺎﺳﯽ داﺷﺖ‬
‫ﻣﺪﯾﺮ ﭘﺮوژه ﺑﻮد‪ .‬در ﯾﮑﯽ از ﺟﻠﺴﻪﻫﺎ‪ ،‬دو ﺷﺮﮐﺖ ﻣﺸﺎور ﻣﺴﺌﻮل در ﭘﺮوژه درﮔﯿﺮ ﺑﺤﺜﯽ ﻃﻮﻻﻧﯽ درﺑﺎره ﯾﮑﯽ از ﺟﻨﺒﻪﻫﺎی‬
‫ﻣﻌﻤﺎری ﭘﺮوژه ﺷﺪه ﺑﻮدﻧﺪ‪ .‬ﺑﻪﯾﮑﺒﺎره ﯾﮑﯽ از اﻓﺮاد ﺟﻠﺴﻪ از ﻣﺪﯾﺮ ﭘﺮوژه ﭘﺮﺳﯿﺪ »آﻗﺎی دﮐﺘﺮ‪ ،‬دﯾﺪﮔﺎه ﺷﻤﺎ ﭼﯿﺴﺖ؟ ﻫﺮﭼﻪ‬
‫ﺑﺎﺷﺪ ﺷﻤﺎ ﻫﻢ ﻣﻌﻤﺎر ﻫﺴﺘﯿﺪ!« و او در ﭘﺎﺳﺦ ﮔﻔﺖ »ﻣﻦ اﯾﻨﺠﺎ ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژه در ﮐﻨﺎر ﺷﻤﺎ ﻫﺴﺘﻢ و ﻧﻪ ﺑﻪﻋﻨﻮان‬
‫ﻣﻌﻤﺎر‪ .‬در ﻧﻘﺶ ﻣﺪﯾﺮ ﭘﺮوژه ﻣﯽﺗﻮاﻧﻢ ﺑﻪ ﺷﻤﺎ ﺑﮕﻮﯾﻢ ﮐﻪ ﺑﻬﺘﺮ اﺳﺖ در اﯾﻦ ﺑﺎره ﺟﻠﺴﻪ ﺟﺪاﮔﺎﻧﻪای ﺑﺮﮔﺰار ﮐﻨﯿﺪ و ﺑﺎ‬
‫ﺳﻨﺠﺶ ﻫﻤﻪ ﻣﻮارد ﺑﻪ رای ﻧﻬﺎﯾﯽ ﺑﺮﺳﯿﺪ‪ .‬ﻧﮑﺎت ﻣﺜﺒﺖ و ﻣﻨﻔﯽ ﺗﺼﻤﯿﻢ را ﻫﻢ ﻣﮑﺘﻮب ﮐﺮده‪ ،‬ﺑﺮاﯾﻢ ﺑﻔﺮﺳﺘﯿﺪ‪ .‬اﮔﺮ‬
‫ﻧﺘﻮاﻧﺴﺘﯿﺪ ﺑﻪ ﺗﻮاﻓﻖ ﺑﺮﺳﯿﺪ‪ ،‬ﺗﺼﻤﯿﻢﮔﯿﺮی ﺑﺮ دوش …… ﺧﻮاﻫﺪ ﺑﻮد‪ ،‬زﯾﺮا اﯾﻦ ﺷﺮﮐﺖ ﻣﺴﺌﻮﻟﯿﺖ ﻃﺮاﺣﯽ ﭘﺎﯾﻪ ﭘﺮوژه را‬
‫دارد و اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﯿﺸﺘﺮ ﺑﻪ ﻃﺮاﺣﯽ ﭘﺎﯾﻪ ﻣﺮﺑﻮط ﻣﯽﺷﻮد‪ .‬ﻟﻄﻔﺎ اﯾﻦ ﻣﺴﺌﻠﻪ را ﺗﺎ ﭘﺎﯾﺎن ﻫﻔﺘﻪ ﺑﻪ ﻧﺘﯿﺠﻪ ﺑﺮﺳﺎﻧﯿﺪ‪ ،‬وﮔﺮﻧﻪ‬
‫ﺑﺎﻋﺚ ﺗﺎﺧﯿﺮ ﭘﺮوژه ﺧﻮاﻫﺪ ﺷﺪ‪«.‬‬

‫اﮔﺮ ﻓﺮدی ﻓﻨﯽ ﻫﺴﺘﯿﺪ و ﺳﻤﺖ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﻣﯽﭘﺬﯾﺮﯾﺪ‪ ،‬ﺑﺎﯾﺪ ﺑﻪ اﻧﺪازه اﯾﻦ ﻓﺮد ﺑﺮ ﺧﻮد ﺗﺴﻠﻂ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪.‬‬

‫ﻣﻦ زﻣﺎﻧﯽ ﻣﺪﯾﺮ ﭘﺮوژهای ﺑﺎ ﻫﺪف اﺳﺘﻘﺮار ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه در ﯾﮏ ﺳﺎزﻣﺎن ﺑﻮدم‪ .‬ﮐﺎر ﻣﻦ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه و ﺟﻨﺒﻪ‬

‫— ‪— 12‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻓﻨﯽ ﭘﺮوژه ﻫﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻮد‪ .‬ﺑﺎ ﺳﺎﯾﺮ اﻓﺮاد ﺗﯿﻢ در اﯾﻦ ﺑﺎره ﮔﻔﺘﮕﻮ ﮐﺮدم ﮐﻪ اﮔﺮ ﻗﺮار ﺑﺎﺷﺪ درﺑﺎره ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ‬
‫ﭘﺮوژهای ﮐﻪ ﻣﺴﺘﻘﺮ ﻣﯽﮐﻨﻨﺪ دﺧﺎﻟﺖ ﮐﻨﻢ‪ ،‬ﻣﺎﻧﻨﺪ ﻫﺮ دﺧﺎﻟﺖ ﻓﻨﯽ دﯾﮕﺮی‪ ،‬ﭼﻪﺑﺴﺎ از ﻣﺪﯾﺮﯾﺖ ﺧﻮد ﭘﺮوژه ﻏﺎﻓﻞ ﺧﻮاﻫﻢ‬
‫ﺷﺪ‪ .‬ﻫﻤﮕﯽ در اﯾﻦ ﺑﺎره ﺗﻮاﻓﻖ ﮐﺮدﯾﻢ‪ .‬ﺑﺎاﯾﻦﻫﻤﻪ‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ ﺣﺪس ﺑﺰﻧﯿﺪ ﮐﻪ ﺟﺪا ﮐﺮدن اﯾﻦ دو ﻣﻮرد ﺑﻪ دﻟﯿﻞ ﻫﻤﮕﻦ‬
‫ﺑﻮدﻧﺸﺎن ﭼﻪاﻧﺪازه ﺳﺨﺖ ﺑﻮد‪ .‬ﻗﺪر ﭘﺮوژهﻫﺎی ﻣﻌﻤﻮل ﮐﻪ ﺟﻨﺒﻪ ﻓﻨﯽﺷﺎن ﮔﻮﻧﻪ دﯾﮕﺮی دارد را ﺑﺪاﻧﯿﺪ‪.‬‬

‫‪ .6.1.1.2‬ﭼﻪ ﮐﺎری ﺑﺮای ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﻗﯽ ﻣﯽﻣﺎﻧﺪ؟‬

‫ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎی ﻓﻨﯽ ﺑﺮ دوش ﻣﺘﺨﺼﺼﺎن ﻓﻨﯽ ﭘﺮوژه ﮔﺬاﺷﺘﻪ ﺷﻮد‪ ،‬ﭼﻪ ﮐﺎری ﺑﺮای ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﻗﯽ‬
‫ﻣﯽﻣﺎﻧﺪ؟ ﻫﻤﺎﻫﻨﮕﯽ‪ ،‬ﺣﻞ اﺧﺘﻼف‪ ،‬ﻣﺬاﮐﺮه و ﺗﺴﻬﯿﻞﮔﺮی ﺑﺮﺧﯽ از ﻣﻮارد ﻧﺴﺒﺘﺎ ﺑﺪﯾﻬﯽ ﻫﺴﺘﻨﺪ‪ ،‬وﻟﯽ ﻣﺴﺌﻮﻟﯿﺖ ﻣﺪﯾﺮ‬
‫ﭘﺮوژه ﺑﻪ اﯾﻦ ﻣﻮارد ﻣﺤﺪود ﻧﻤﯽﺷﻮد‪.‬‬

‫ﯾﮑﯽ دﯾﮕﺮ از ﻣﺴﺌﻮﻟﯿﺖﻫﺎی ﻣﺪﯾﺮ ﭘﺮوژه اﯾﻦ اﺳﺖ ﮐﻪ ﻓﻀﺎی ﻣﻨﺎﺳﺒﯽ ﺑﺮای رﺷﺪ ﺣﺮﻓﻪای اﻋﻀﺎی ﺗﯿﻢ ﻓﺮاﻫﻢ ﮐﻨﺪ‪ .‬ﺑﻠﻪ‪،‬‬
‫ﻣﺪﯾﺮ ﭘﺮوژه در اﯾﻦ ﺑﺎره ﻣﺴﺌﻮل اﺳﺖ‪ .‬اﯾﻦ ﯾﮑﯽ از ﺟﻨﺒﻪﻫﺎی اﺧﻼق و رﻓﺘﺎر ﺣﺮﻓﻪاﯾﺴﺖ‪ .‬ﺑﺮای اﻃﻼﻋﺎت ﺑﯿﺸﺘﺮ ﻣﯽﺗﻮاﻧﯿﺪ‬
‫ﺑﻪ اﯾﻦ ﻣﻨﺎﺑﻊ ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪:‬‬

‫آﯾﯿﻦﻧﺎﻣﻪ اﺧﻼق و رﻓﺘﺎر ﺣﺮﻓﻪای ‪PMI‬‬

‫‪https://www.pmi.org/codeofethics‬‬
‫آﯾﯿﻦﻧﺎﻣﻪ اﺧﻼق ‪P3.express‬‬
‫‪https://p3.express/certification/code-of-conduct/‬‬
‫راﻫﻨﻤﺎی ﺷﺎﯾﺴﺘﮕﯽﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ‪IPMA‬‬
‫‪https://www.ipma.world/individuals/standard/‬‬

‫ﺧﻼﺻﻪ اﯾﻦﮐﻪ از اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه و ﻣﻨﺎﺑﻌﯽ ﮐﻪ در اﺧﺘﯿﺎر ﭘﺮوژه ﮔﺬاﺷﺘﻪ ﺷﺪه اﺳﺖ ﻣﺮاﻗﺒﺖ ﮐﻨﯿﺪ‪ .‬اﻣﺎﻧﺖدار و‬
‫ﻗﺎﺑﻞاﻋﺘﻤﺎد ﺑﺎﺷﯿﺪ و اﻟﺰاﻣﺎت و ﻗﻮاﻧﯿﻦ را ﺗﺎ ﺟﺎﯾﯽ ﮐﻪ ﺧﻼف اﺧﻼق ﻧﺒﺎﺷﻨﺪ ﭘﺎس دارﯾﺪ‪.‬‬

‫ﻧﮑﺘﻪ ﭘﺎﯾﺎﻧﯽ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺮای اﻧﺠﺎم ﻫﻤﻪ اﯾﻦ ﻣﻮارد ﺑﺎﯾﺪ ﺷﻨﻮﻧﺪه ﺧﻮﺑﯽ ﺑﺎﺷﯿﺪ‪ .‬ﺑﺮای ﭘﺎﺳﺦ دادن ﮔﻮش ﻧﮑﻨﯿﺪ‪ ،‬ﺑﻠﮑﻪ‬
‫ﺑﺮای ﻓﻬﻤﯿﺪن ﮔﻮش ﮐﻨﯿﺪ‪ .‬ﻣﻨﺘﻈﺮ ﻧﻤﺎﻧﯿﺪ ﮐﻪ ﺑﺮای ﮔﻔﺘﮕﻮ ﺑﻪ ﺷﻤﺎ رﺟﻮع ﮐﻨﻨﺪ‪ ،‬ﺑﻠﮑﻪ ﺑﺮاﯾﺶ ﭘﯿﺶﻗﺪم ﺷﻮﯾﺪ ﺗﺎ ﻫﺮ‬
‫دﺷﻮاری ﯾﺎ ﮐﻤﺒﻮدی را در زودﺗﺮﯾﻦ زﻣﺎن و ﭘﯿﺶ از آنﮐﻪ ﭘﯿﭽﯿﺪهﺗﺮ ﺷﻮد ﺣﻞ ﮐﻨﯿﺪ‪.‬‬

‫‪ .2.1.2‬ﺑﺴﺘﺮ ﻣﻨﺎﺳﺒﯽ ﺑﺮای ﻫﻤﮑﺎری در ﺗﯿﻢ ﭘﺮوژه ﻓﺮاﻫﻢ ﮐﻨﯿﺪ‬

‫آﻧﭽﻪ ﺑﺎﻋﺚ ﻣﻮﻓﻘﯿﺖ ﭘﺮوژه ﻣﯽﺷﻮد اﻓﺮاد ﺗﻮاﻧﻤﻨﺪ ﻧﯿﺴﺘﻨﺪ‪ ،‬ﺑﻠﮑﻪ ﺗﯿﻤﯽ ﺗﻮاﻧﻤﻨﺪ اﺳﺖ‪.‬‬

‫ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮان ﺗﯿﻤﯽ ﺗﻮاﻧﻤﻨﺪ و ﮐﺎرآﻣﺪ ﺳﺎﺧﺖ؟‬

‫‪ .1 . 2 . 1 . 2‬ﺗ ﯿ ﻢ ﺳ ﺎ ز ی ﻧ ﺎ ﻣ ﺤ ﺴ ﻮ س‬

‫ﺑﻪ ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ ﮐﻪ وﺿﻌﯿﺖ ﺗﯿﻢ را ﺑﻬﺒﻮد ﻣﯽدﻫﻨﺪ »ﺗﯿﻢﺳﺎزی« )‪ (team building‬ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪ .‬ﺑﺮﺧﯽ ﺳﺎزﻣﺎنﻫﺎ‬
‫ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ وﯾﮋه اﯾﻦ ﮐﺎر ﺗﺮﺗﯿﺐ ﻣﯽدﻫﻨﺪ‪ .‬اﯾﻦ ﻓﻌﺎﻟﯿﺖﻫﺎ ﻣﻌﻤﻮﻻ ﺑﺎ ﮐﻤﮏ ﻣﺮﺑﯽﻫﺎﯾﯽ اﻧﺠﺎم ﻣﯽﺷﻮد ﮐﻪ در ﺗﯿﻢﺳﺎزی‬

‫— ‪— 13‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺧﺒﺮه ﻫﺴﺘﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻫﻤﻪ اﻓﺮاد ﺗﯿﻢ ﺑﻪ ﯾﮏ ﺑﺎزی دﺳﺖ ﺟﻤﻌﯽ ﯾﺎ ﺑﺮﻧﺎﻣﻪای آﻣﻮزﺷﯽ ﻣﺎﻧﻨﺪ آﺷﭙﺰی دﻋﻮت ﻣﯽﺷﻮﻧﺪ‬
‫و ﺗ ﯿ ﻢ ﺳ ﺎ ز ی د ر ﺧ ﻼ ل ا ﯾ ﻦ ﮐ ﺎ ر ا ﻧ ﺠ ﺎ م ﺷ ﻮ د‪.‬‬

‫ﺑﻬﺘﺮ اﺳﺖ ﺑﻪﺟﺎی ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﺨﺘﺺ ﺗﯿﻢﺳﺎزی ﺗﺎ ﺣﺪ اﻣﮑﺎن آن را ﺑﺎ ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﻌﻤﻮل ﭘﺮوژه ﺗﺮﮐﯿﺐ ﮐﻨﯿﺪ ﺗﺎ‬
‫ﮐﺎرآﻣﺪﺗﺮ ﺷﻮد‪ .‬ﻫﺮﮔﺎه درﮔﯿﺮ ﺗﺮﺗﯿﺐ دادن ﻓﻌﺎﻟﯿﺘﯽ ﻫﺴﺘﯿﺪ‪ ،‬از ﺧﻮد ﺑﭙﺮﺳﯿﺪ ﮐﻪ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﯿﺪ از آن ﻓﻌﺎﻟﯿﺖ ﺑﺮای‬
‫ﺗ ﯿ ﻢ ﺳ ﺎ ز ی ﻧ ﯿ ﺰ ﮐ ﻤ ﮏ ﺑ ﮕ ﯿ ﺮ ﯾ ﺪ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻓﺮض ﮐﻨﯿﺪ درﮔﯿﺮ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻋﻨﺼﺮی در ﭘﺮوژه ﻫﺴﺘﯿﺪ‪ .‬ﻣﯽﺗﻮاﻧﯿﺪ ﺑﺮای اﯾﻦ ﮐﺎر ﺑﺎ ﭘﻨﺞ ﻋﻀﻮ ﺗﯿﻢ ﺟﺪاﮔﺎﻧﻪ‬
‫ﻣﻼﻗﺎت ﮐﻨﯿﺪ‪ ،‬اﻃﻼﻋﺎت ﻻزم را ﮔﺮدآوری ﮐﺮده‪ ،‬ﺑﺮﻧﺎﻣﻪ را ﺑﺮ آن ﭘﺎﯾﻪ آﻣﺎده ﮐﻨﯿﺪ‪ .‬ﮔﺰﯾﻨﻪ دﯾﮕﺮ اﯾﻦ اﺳﺖ ﮐﻪ ﮐﺎرﮔﺎﻫﯽ‬
‫ﺗﺴﻬﯿﻞﺷﺪه ﺗﺮﺗﯿﺐ دﻫﯿﺪ و آن ﭘﻨﺞ ﻧﻔﺮ را دﻋﻮت ﮐﻨﯿﺪ ﺗﺎ ﺑﺎ ﻫﻢ ﻫﻤﻔﮑﺮی ﮐﺮده‪ ،‬ﺑﺮﻧﺎﻣﻪ را آﻣﺎده ﮐﻨﻨﺪ‪ .‬ﮔﺰﯾﻨﻪ دوم‪،‬‬
‫ﻫﻨﮕﺎﻣﯽﮐﻪ ﺑﻪ ﺧﻮﺑﯽ اﻧﺠﺎم ﺷﻮد‪ ،‬ﻓﺮﺻﺖ ﺧﻮﺑﯽ ﺑﺮای ﺗﻘﻮﯾﺖ ﮐﺎر ﮔﺮوﻫﯽ‪ ،‬ﺑﻬﺒﻮد رواﺑﻂ ﻣﯿﺎن اﻓﺮاد‪ ،‬و ﺣﺮﮐﺖ ﺑﻪ ﺳﻮی‬
‫ﺷ ﮑ ﻞ د ﻫ ﯽ ﺗ ﯿ ﻤ ﯽ ﺗ ﻮ ا ﻧ ﻤ ﻨ ﺪ ا ﺳ ﺖ‪.‬‬

‫اﻣﺘﯿﺎز اﺻﻠﯽ ﺗﺮﮐﯿﺐ ﺗﯿﻢﺳﺎزی ﺑﺎ ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﻌﻤﻮل اﯾﻦ اﺳﺖ ﮐﻪ آﻫﺴﺘﻪ و ﭘﯿﻮﺳﺘﻪ اﻧﺠﺎم ﻣﯽﺷﻮد‪.‬‬

‫‪ .2.2.1.2‬ارزﯾﺎﺑﯽ رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن‬

‫در ﻣﺘﺪوﻟﻮژی ‪ P3.express‬ﭼﺮﺧﻪﻫﺎﯾﯽ ﻣﺎﻫﺎﻧﻪ ﺑﺮای ﮐﺎر ﭘﺮوژه وﺟﻮد دارد‪ .‬ﻫﺮ ﭼﺮﺧﻪ ﺷﻤﺎری ﻓﻌﺎﻟﯿﺖ ﭘﺎﯾﺎﻧﯽ دارد و ﯾﮑﯽ‬
‫از اﯾﻦ ﻓﻌﺎﻟﯿﺖﻫﺎ ارزﯾﺎﺑﯽ رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن اﺳﺖ‪ .‬ﺑﺮای اﯾﻦ ﮐﺎر رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن دروﻧﯽ )اﻋﻀﺎی ﺗﯿﻢ( و ﺑﯿﺮوﻧﯽ ﭘﺮوژه ﺑﺎ‬
‫ﻧﻈﺮﺳﻨﺠﯽﻫﺎی ﺑﯽﻧﺎم ارزﯾﺎﺑﯽ ﻣﯽﺷﻮﻧﺪ‪ .‬ﭘﺲازآن‪ ،‬ﻓﻌﺎﻟﯿﺖ دﯾﮕﺮی وﺟﻮد دارد ﺗﺎ ﺑﺎ ﮐﻤﮏ اﯾﻦ اﻃﻼﻋﺎت ﺑﺮﻧﺎﻣﻪای ﺑﺮای‬
‫ﺑﻬﺒﻮد ﭘﺮوژه در ﭼﺮﺧﻪ ﺑﻌﺪ ﻃﺮاﺣﯽ ﺷﻮد‪.‬‬

‫ﭘﯿﺸﻨﻬﺎد ‪ P3.express‬اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺮای ﺳﺎﺧﺖ ﺑﺮﻧﺎﻣﻪ ﺑﻬﺒﻮد اﻋﻀﺎی ﺗﯿﻢ را ﮔﺮد ﻫﻢ آورﯾﺪ‪ ،‬اﻃﻼﻋﺎت را در اﺧﺘﯿﺎرﺷﺎن‬
‫ﺑﮕﺬارﯾﺪ و ﺑﺎ ﺗﺴﻬﯿﻞﮔﺮی ﺑﺎ روشﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ دﻟﻔﯽ )‪ (Delphi technique‬از اﯾﺸﺎن درﺧﻮاﺳﺖ ﮐﻨﯿﺪ ﮐﻪ ﺑﺮﻧﺎﻣﻪﻫﺎی‬
‫ﺑﻬﺒﻮد را ﻃﺮاﺣﯽ ﮐﻨﻨﺪ‪.‬‬

‫ﭼﻨﯿﻦ ﮐﺎری اﻣﺘﯿﺎزﻫﺎی ﻓﺮاواﻧﯽ دارد‪ ،‬ازﺟﻤﻠﻪ‪:‬‬

‫ﭼﻨﯿﻦ ﺟﻤﻌﯽ ﻣﯽﺗﻮاﻧﺪ اﯾﺪهﻫﺎی ﺟﺎﻟﺒﯽ ﺑﯿﺎﻓﺮﯾﻨﺪ‪ ،‬ﻓﺮاﺗﺮ از آﻧﭽﻪ ﺑﻪﺗﻨﻬﺎﯾﯽ ﯾﺎ ﺑﺎ ﮐﻤﮏ ﮔﺮوﻫﯽ ﮐﻮﭼﮏ ﺷﺪﻧﯿﺴﺖ‪.‬‬
‫ﺑﺎ اﯾﻦ ﮐﺎر ﻧﺸﺎن ﻣﯽدﻫﯿﺪ ﮐﻪ دﯾﺪﮔﺎه اﻋﻀﺎی ﺗﯿﻢ ﺑﺮاﯾﺘﺎن ﺑﺎارزش اﺳﺖ و از آنﺟﺎﯾﯽ ﮐﻪ ﺧﻮدﺷﺎن ﺑﺮﻧﺎﻣﻪﻫﺎی‬
‫ﺑﻬﺒﻮد را ﻃﺮاﺣﯽ ﮐﺮدهاﻧﺪ‪ ،‬ﺑﻪ آن ﭘﺎﯾﺒﻨﺪﺗﺮ ﺧﻮاﻫﻨﺪ ﺑﻮد و اﻣﮑﺎن ﻣﻮﻓﻘﯿﺖ ﺑﺮﻧﺎﻣﻪﻫﺎ ﺑﺎﻻﺗﺮ ﻣﯽرود‪.‬‬
‫اﯾﻦ ﮐﺎر ﺣﺲ ﻫﻤﮑﺎری را در ﺗﯿﻢ ﺑﻬﺒﻮد ﻣﯽدﻫﺪ‪.‬‬

‫‪ .3.2.1.2‬درک ﻣﺸﺘﺮک‬

‫ﺑﺴﺘﻪ ﺑﻪ ﺷﺮاﯾﻂ‪ ،‬ﺷﺎﯾﺪ ﮐﺎرﻫﺎی دﯾﮕﺮی ﻫﻢ ﺑﺮای ﺑﻬﺒﻮد وﺿﻌﯿﺖ ﺗﯿﻢ ﻧﯿﺎز ﺑﺎﺷﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬وﻗﺘﯽ ﺗﯿﻢ زﯾﺎد از ﺣﺪ ﮐﻮﭼﮏ‬
‫ﻧﺒﺎﺷﺪ ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ اﻧﺘﻈﺎرﻫﺎﯾﯽ ﮐﻪ از ﻫﺮﮐﺲ ﻣﯽرود و اﻧﺘﻈﺎرﻫﺎﯾﯽ ﮐﻪ آن ﻓﺮد از دﯾﮕﺮان ﻣﯽﺗﻮاﻧﺪ داﺷﺘﻪ ﺑﺎﺷﺪ‬
‫ﻣﺸﺨﺺ و ﺷﻔﺎف ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ﺑﺎﯾﺪ ﻧﻘﺶﻫﺎ و ﻣﺴﺌﻮﻟﯿﺖﻫﺎ را ﺑﻪﺧﻮﺑﯽ ﺗﻌﺮﯾﻒ ﮐﻨﯿﺪ‪ .‬اﯾﻦ ﻧﮑﺘﻪ ﯾﮑﯽ از‬
‫اﺻﻞﻫﺎی ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﭘﺮﯾﻨﺲ‪ (PRINCE2) ۲‬ﻧﯿﺰ ﻫﺴﺖ‪.‬‬

‫— ‪— 14‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﻓﺰون ﺑﺮ ﻧﻘﺶ و ﻣﺴﺌﻮﻟﯿﺖﻫﺎ‪ ،‬ﺷﺎﯾﺪ ﻧﯿﺎز ﺑﺎﺷﺪ ﮐﻪ ﻓﺮآﯾﻨﺪﻫﺎی ﮐﺎرﻫﺎی راﯾﺞ ﭘﺮوژه را ﻧﯿﺰ ﺗﺪوﯾﻦ ﮐﻨﯿﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪» :‬ﻫﺮ‬
‫ﺳﻨﺪی ﮐﻪ ﻃﺮاﺣﯽ ﻣﯽﺷﻮد ﺑﺎﯾﺪ ﺑﺮای ﺑﺮرﺳﯽ ﻧﺨﺴﺘﯿﻦ ﺑﻪ …… ﻓﺮﺳﺘﺎده ﺷﻮد‪ ،‬اﯾﻦ ﺑﺮرﺳﯽ ﺑﺎﯾﺪ در …… روز ﮐﺎﻣﻞ ﺷﺪه و‬
‫ﭘ ﺲ از آ ن … «‬

‫ﻧﮑﺘﻪ دﯾﮕﺮی ﮐﻪ ﺷﺎﯾﺪ ﻧﯿﺎز ﺑﺎﺷﺪ ﺗﺪوﯾﻦ ﻗﻮاﻋﺪ رﻓﺘﺎری )‪ (ground rules‬اﺳﺖ ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪» ،‬ﺑﺎ ﺻﺪای ﺑﻠﻨﺪ ﭘﺸﺖ ﺗﻠﻔﻦ‬
‫ﺻ ﺤ ﺒ ﺖ ﻧ ﮑ ﻨ ﯿ ﺪ‪« .‬‬

‫ﺷﺎﯾﺪ ﺑﻪ اﯾﻦ ﺑﯿﻨﺪﯾﺸﯿﺪ ﮐﻪ ﺗﺪوﯾﻦ و اﺑﻼغ ﭼﻨﯿﻦ ﻗﻮاﻋﺪی ﺗﺤﮑﻤﯽ و ﺑﺮﺧﻼف آﻧﭽﻪ در اﺻﻞ ﭘﯿﺶ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ اﺳﺖ‪.‬‬
‫وﺿﻌﯿﺖ اﯾﻦﮔﻮﻧﻪ ﺧﻮاﻫﺪ ﺑﻮد اﮔﺮ اﯾﻦ ﻣﻮارد را ﺑﻪ ﺗﻨﻬﺎﯾﯽ ﯾﺎ ﻫﻤﺮاه ﺑﺎ ﻋﺪهای اﻧﮕﺸﺖﺷﻤﺎر آﻣﺎده ﮐﺮده‪ ،‬ﺑﻪ ﻫﻤﮕﯽ ﺣﮑﻢ‬
‫ﮐﻨﯿﺪ‪ .‬راه ﻣﻨﺎﺳﺐ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎ ﺗﺴﻬﯿﻞﮔﺮی ﻣﻨﺎﺳﺐ از ﺧﻮد اﻋﻀﺎی ﺗﯿﻢ درﺧﻮاﺳﺖ ﮐﻨﯿﺪ ﮐﻪ ﭼﻨﯿﻦ ﻣﻮاردی را ﺑﺮای‬
‫ﺧﻮدﺷﺎن ﺗﺪوﯾﻦ ﮐﻨﻨﺪ‪ .‬اﯾﻨﮕﻮﻧﻪ‪ ،‬ﻫﻢ ﻗﻮاﻋﺪ واﻗﻊﺑﯿﻨﺎﻧﻪﺗﺮ و ﮐﺎراﺗﺮ ﺧﻮاﻫﻨﺪ ﺑﻮد و ﻫﻢ اﻣﮑﺎن ﻣﻮﻓﻘﯿﺖ ﺑﯿﺸﺘﺮی ﺧﻮاﻫﻨﺪ‬
‫داﺷﺖ ﭼﻮن ﺑﻪ اﻓﺮاد ﺗﺤﻤﯿﻞ ﻧﺸﺪهاﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬آﯾﯿﻦﻧﺎﻣﻪ اﺧﻼق ‪ P3.express‬ﺑﻪ ﮐﻤﮏ ﻫﻤﮕﺎن ﺳﺎﺧﺘﻪ ﺷﺪه اﺳﺖ و‬
‫ﻧ ﻪ ﮔ ﺮ و ﻫ ﯽ ا ﻧ ﮕ ﺸ ﺖ ﺷ ﻤ ﺎ ر‪.‬‬

‫‪ .3.1.2‬ذیﻧﻔﻌﺎن را در ﭘﺮوژه ﻣﺸﺎرﮐﺖ دﻫﯿﺪ‬

‫ﺑﺮﺧﯽ واژه »ذیﻧﻔﻊ« )‪ ( stakeholder‬را ﺑﺮاﺑﺮ »ﮐﺎرﻓﺮﻣﺎ« ﻣﯽداﻧﻨﺪ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ در ادﺑﯿﺎت ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻪ ﻫﺮ ﻓﺮد ﯾﺎ‬
‫ﻣﺠﻤﻮﻋﻪای ﮐﻪ ﺑﺎ ﭘﺮوژه ﺳﺮ و ﮐﺎر داﺷﺘﻪ ﺑﺎﺷﺪ و ﺑﺘﻮاﻧﺪ ﺑﺮ آن اﺛﺮ ﺑﮕﺬارد »ذیﻧﻔﻊ« ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪ .‬اﻋﻀﺎی ﺗﯿﻢ‪ ،‬ﮐﺎرﻓﺮﻣﺎ‪،‬‬
‫ﭘﯿﻤﺎﻧﮑﺎران‪ ،‬ﻓﺮوﺷﻨﺪﮔﺎن ﻣﺼﺎﻟﺢ و ﺗﺠﻬﯿﺰات‪ ،‬رﻗﺒﺎ‪ ،‬و ﻗﺎﻧﻮنﮔﺬاران ﻧﻤﻮﻧﻪﻫﺎﯾﯽ از ذیﻧﻔﻌﺎن ﭘﺮوژه ﻫﺴﺘﻨﺪ‪.‬‬

‫‪ .1.3.1.2‬ذیﻧﻔﻌﺎن ﻧﺎﻣﺮﺋﯽ‬

‫زﻣﺎﻧﯽ ﺑﺎ ﺳﺎزﻣﺎﻧﯽ ﻫﻤﮑﺎری ﻣﯽﮐﺮدم ﮐﻪ در ﮐﻨﺎر ﭘﺮوژهﻫﺎی ﺧﻮدش از ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎی ﻏﯿﺮاﻧﺘﻔﺎﻋﯽ ﻫﻢ ﭘﺸﺘﯿﺒﺎﻧﯽ ﻣﺎﻟﯽ‬
‫ﻣﯽﮐﺮد‪ .‬ﯾﮑﯽ از اﯾﻦ ﭘﺮوژهﻫﺎ ﺳﺎﺧﺖ ﭘﻨﺎﻫﮕﺎﻫﯽ ﮐﻮﻫﺴﺘﺎﻧﯽ ﺑﻮد‪ .‬ﻫﺮ از ﭼﻨﺪی ﻧﻤﺎﯾﻨﺪهای از آن ﭘﺮوژه ﺑﻪ دﻓﺘﺮ ﻣﺎ ﻣﯽآﻣﺪ‪،‬‬
‫ﮔﺰارﺷﯽ از ﮐﺎرﻫﺎی اﻧﺠﺎم ﺷﺪه و ﭘﯿﺶ رو و ﺑﺮآوردی از ﺑﻮدﺟﻪ ﻻزم ﺑﺮای دوره ﺑﻌﺪ اراﺋﻪ ﻣﯽﮐﺮد‪ .‬زﻣﺎﻧﯽ ﻣﺘﻮﺟﻪ ﺷﺪم ﮐﻪ‬
‫ﻣﺪت زﯾﺎدی ﻣﯽﮔﺬرد و ﺧﺒﺮی از ﻧﻤﺎﯾﻨﺪﮔﺎن آن ﭘﺮوژه ﻧﯿﺴﺖ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺑﺎ آنﻫﺎ ﺗﻤﺎس ﮔﺮﻓﺘﯿﻢ‪ ،‬ﺑﺎﺧﺒﺮ ﺷﺪﯾﻢ ﮐﻪ‬
‫ﺳﺎزﻣﺎن ﻣﯿﺮاث ﻓﺮﻫﻨﮕﯽ ﭘﺮوژه را ﻣﺘﻮﻗﻒ ﮐﺮده اﺳﺖ‪ ،‬زﯾﺮا ﭘﻨﺎﻫﮕﺎه ﺑﺮ روی ﺟﺎدهای ﺑﺎﺳﺘﺎﻧﯽ ﻗﺮار ﮔﺮﻓﺘﻪ ﺑﻮد‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ‬
‫ﻫﺰﯾﻨﻪ ﻓﺮاواﻧﯽ ﮐﻪ ﺻﺮف ﺳﺎﺧﺖ ﺑﺨﺸﯽ از ﭘﻨﺎﻫﮕﺎه ﺷﺪه ﺑﻮد از دﺳﺖ رﻓﺘﻪ )ﻫﺰﯾﻨﻪ ﺳﺎﺧﺖ در ﮐﻮﻫﺴﺘﺎن ﺑﺴﯿﺎر زﯾﺎد‬
‫ا ﺳ ﺖ ( و ﺟ ﺎ د ه ا ی ﺑ ﺎ ﺳ ﺘ ﺎ ﻧ ﯽ ﻫ ﻢ آ ﺳ ﯿ ﺐ د ﯾ ﺪ ه ﺑ ﻮ د‪.‬‬

‫ﺟﺎده ﺑﺎﺳﺘﺎﻧﯽ را ﺑﻪﺳﺨﺘﯽ ﻣﯽﺷﺪ ﺗﺸﺨﯿﺺ داد و ﺗﻔﺎوت ﭼﻨﺪاﻧﯽ ﺑﺎ ﭘﺎﮐﻮﺑﻪﻫﺎﯾﯽ ﮐﻪ ﺑﻪﺗﺪرﯾﺞ ﺑﺎ رﻓﺖ و آﻣﺪ ﮐﻮﻫﻨﻮردان‬
‫ﺑﻪ وﺟﻮد ﻣﯽآﻣﺪ ﻧﺪاﺷﺖ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﻫﻤﺎن اﺛﺮ ﺟﺰﺋﯽ از ﺟﺎده ﻫﻢ ﺑﺎزﺗﺎب ﺗﺎرﯾﺨﯽ ﻃﻮﻻﻧﯽ ﺑﻮد و ﻣﯿﺮاﺛﯽ ﻓﺮﻫﻨﮕﯽ ﮐﻪ ﻧﯿﺎز‬
‫ﺑ ﻪ ﺣ ﻔ ﺎ ﻇ ﺖ د ا ﺷ ﺖ‪.‬‬

‫ﭼﮕﻮﻧﻪ ﻣﯽﺷﺪ از ﺑﺮوز ﭼﻨﯿﻦ ﭼﺎﻟﺸﯽ در ﭘﺮوژه ﺟﻠﻮﮔﯿﺮی ﮐﺮد؟‬

‫ﭘﯿﺶ از اﺟﺮای ﭼﻨﯿﻦ ﭘﺮوژهای‪ ،‬ﻣﯽﺗﻮان ﻣﺪﺗﯽ ﺑﻪ ﻣﺤﻞ رﻓﺖ و ﺑﺎ ﮐﻮﻫﻨﻮردان ﺧﺒﺮهای ﮐﻪ در آﻧﺠﺎ رﻓﺖ و آﻣﺪ ﻣﯽﮐﻨﻨﺪ‬
‫ﮔﻔﺘﮕﻮ ﮐﺮد و دﯾﺪﮔﺎﻫﺸﺎن را ﺟﻮﯾﺎ ﺷﺪ‪ .‬ﺑﯽﮔﻤﺎن ﺑﺮﺧﯽ از ﮐﻮﻫﻨﻮردان از ﺟﺎده اﻃﻼع داﺷﺘﻨﺪ و ﻣﯽﺗﻮاﻧﺴﺘﻨﺪ در آن ﺑﺎره‬

‫— ‪— 15‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﻃﻼعرﺳﺎﻧﯽ ﮐﻨﻨﺪ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮان اﻃﻼﻋﺎت ﻣﻔﯿﺪ دﯾﮕﺮی ﻫﻢ ﺑﺮای ﺳﺎﺧﺖ ﭘﻨﺎﻫﮕﺎه از ﭼﻨﯿﻦ ﮐﺴﺎﻧﯽ ﮔﺮﻓﺖ‪.‬‬
‫ﻣﯽﺷﺪ ﭘﯿﺶ از آﻏﺎز ﮐﺎر ﺗﺎﺑﻠﻮﯾﯽ ﻫﻢ در ﻣﺤﻞ ﻧﺼﺐ ﮐﺮد‪ ،‬ﺑﺮﻧﺎﻣﻪ ﺳﺎﺧﺖ ﭘﻨﺎﻫﮕﺎه را اﻃﻼع داد و از ﻫﻤﮕﺎن درﺧﻮاﺳﺖ‬
‫ﮐﺮد ﮐﻪ ﭘﯿﺸﻨﻬﺎدﻫﺎﯾﺸﺎن را ﺑﻔﺮﺳﺘﻨﺪ‪.‬‬

‫ﭼﻨﯿﻦ اﻗﺪامﻫﺎﯾﯽ آﻏﺎز ﭘﺮوژه را ﺑﻪ ﺗﺎﺧﯿﺮ ﻣﯽاﻧﺪازﻧﺪ‪ ،‬وﻟﯽ ﺟﻠﻮی ﺑﺮوز ﺑﺴﯿﺎری از ﭼﺎﻟﺶﻫﺎ را ﻣﯽﮔﯿﺮﻧﺪ‪ .‬ﺗﻮﺟﻪ ﮐﺮدن ﺑﻪ‬
‫ﭼﻨﯿﻦ ﻣﺴﺎﯾﻠﯽ ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎی ﺑﺮﺟﺴﺘﻪ را از ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎی ﻣﻌﻤﻮﻟﯽ ﻣﺘﻤﺎﯾﺰ ﻣﯽﮐﻨﺪ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻫﺪف آﻏﺎز زودﺗﺮ ﭘﺮوژه ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ زودﺗﺮ ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن ﮐﺎر ﺑﺎ ﮐﯿﻔﯿﺖ و ﻫﺰﯾﻨﻪ ﻣﻨﺎﺳﺐ‬
‫ا ﺳ ﺖ‪.‬‬

‫‪ .2.3.1.2‬ارﺗﺒﺎﻃﺎت‬

‫ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ زﻣﺎن و ﺗﻮان ﺑﺎﯾﺴﺘﻪ ﺻﺮف ﺷﻨﺎﺳﺎﯾﯽ و ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن ﭘﺮوژه ﮐﻨﯿﻢ‪ .‬ﮔﺎم ﻧﺨﺴﺖ‪ ،‬ﯾﻌﻨﯽ ﺷﻨﺎﺳﺎﯾﯽ‬
‫ذیﻧﻔﻌﺎن‪ ،‬ﮐﺎر ﺳﺎدهای ﻧﯿﺴﺖ و ﺑﺎﯾﺪ ﺑﺮاﯾﺶ از اﻋﻀﺎی ﺗﯿﻢ ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ‪ .‬ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ در اﺻﻞ ﭘﯿﺶ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪،‬‬
‫اﯾﻦ ﮐﺎر را ﺑﻪ ﺷﮑﻠﯽ اﻧﺠﺎم دﻫﯿﺪ ﮐﻪ ﮐﺎرﮐﺮد ﺗﯿﻢﺳﺎزی ﻫﻢ داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﺑﺎﯾﺪ ﺑﺎ ذیﻧﻔﻌﺎن ﺷﻨﺎﺳﺎﯾﯽﺷﺪه ﺑﻪ ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻒ ارﺗﺒﺎط ﺑﺮﻗﺮار ﮐﺮد‪ .‬ﻧﻮع ﻣﻨﺎﺳﺐ ارﺗﺒﺎط ﺑﺴﺘﮕﯽ ﺑﻪ ﻧﻮع ذیﻧﻔﻊ‬
‫دارد‪ .‬ﮔﺎﻫﯽ ارﺗﺒﺎط رﺳﻤﯽ ﻣﻨﺎﺳﺐﺗﺮ اﺳﺖ و ﮔﺎﻫﯽ ﻏﯿﺮرﺳﻤﯽ‪ .‬ﮔﺎﻫﯽ ارﺗﺒﺎط ﺑﺎﯾﺪ ﺑﺎ ﺟﺰﺋﯿﺎت ﻓﺮاوان ﺑﺎﺷﺪ و ﮔﺎﻫﯽ ﮐﻼن‪.‬‬
‫ﮔﺎﻫﯽ ﺑﺎﯾﺪ ﺟﻨﺒﻪﻫﺎی ﭘﯿﭽﯿﺪه ﻓﻨﯽ را در ارﺗﺒﺎط وارد ﮐﻨﯿﺪ و ﮔﺎﻫﯽ ﺑﺎﯾﺪ از آن ﺧﻮدداری ﮐﻨﯿﺪ‪.‬‬

‫ﯾﮑﯽ از راهﻫﺎی ارﺗﺒﺎط ﮐﻪ ﺑﺮای ﺑﺴﯿﺎری از ذیﻧﻔﻌﺎن ﮐﺎرﺑﺮد دارد‪ ،‬ﻓﺮﺳﺘﺎدن ﮔﺰارش اﺳﺖ‪ .‬ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ‬
‫ﮔﻮﻧﺎﮔﻮﻧﯽ اﻓﺮاد ﺑﯿﺶ از آن اﺳﺖ ﮐﻪ ﯾﮏ ﻧﻮع ﮔﺰارش ﺑﺮای ﻫﻤﻪ آنﻫﺎ ﻣﻨﺎﺳﺐ ﺑﺎﺷﺪ و درﻧﺘﯿﺠﻪ ﺑﻬﺘﺮ اﺳﺖ ﺑﯿﺸﺘﺮ از ﯾﮏ‬
‫ﻧﻮع ﮔﺰارش ﻃﺮاﺣﯽ ﮐﻨﯿﺪ‪.‬‬

‫ﻓﺮدی آﻏﺎز ﺑﻪ ﺳﺎﺧﺖ و ﭘﯿﺶﻓﺮوش ﻣﺠﻤﻮﻋﻪ آﭘﺎرﺗﻤﺎﻧﯽ ﺑﺰرگ و ﮐﻤﺎﺑﯿﺶ ﮐﻢﻫﺰﯾﻨﻪای ﮐﺮده ﺑﻮد‪ .‬ﭘﺲ از ﻓﺮاری ﺷﺪن‬
‫ﺳﺎزﻧﺪه ﻣﺸﺨﺺ ﺷﺪ ﮐﻪ ﺣﺪود ‪ ۵۰۰‬آﭘﺎرﺗﻤﺎﻧﯽ ﮐﻪ در ﺣﺎل ﺳﺎﺧﺖ ﺑﻮد )اﮔﺮ ﺷﻤﺎرﺷﺎن را درﺳﺖ ﺑﻪ ﯾﺎد ﺑﯿﺎورم( ﺑﻪ‬
‫ﻫﺰاران ﻧﻔﺮ ﭘﯿﺶﻓﺮوش ﺷﺪه ﺑﻮد! ﺧﺮﯾﺪاراﻧﯽ ﮐﻪ ﺑﯿﺸﺘﺮ اﻧﺪوﺧﺘﻪ ﻣﺎﻟﯽ ﺧﻮد را در اﺧﺘﯿﺎر اﯾﻦ ﮐﻼهﺑﺮدار ﻗﺮار داده ﺑﻮدﻧﺪ‬
‫ﺑﺴﯿﺎر آزرده و ﺧﺸﻤﮕﯿﻦ ﺑﻮدﻧﺪ و ﺑﻪﺗﺪرﯾﺞ درﮔﯿﺮ ﺗﺤﺼﻦ و اﻋﺘﺮاض ﺷﺪﻧﺪ‪ .‬ﻗﻮه ﻗﻀﺎﺋﯿﻪ ﺑﺮآن ﺷﺪ ﮐﻪ ﭘﺎدرﻣﯿﺎﻧﯽ ﮐﻨﺪ‪.‬‬
‫ﺑﺮﻧﺎﻣﻪ اﯾﻦ ﺑﻮد ﮐﻪ ﺑﻮدﺟﻪ ﻻزم ﻓﺮاﻫﻢ ﺷﻮد و ﺑﻪ ﺷﻤﺎر ﭘﯿﺶﻓﺮوش ﺷﺪه آﭘﺎرﺗﻤﺎنﻫﺎﯾﯽ ﺳﺎﺧﺘﻪ ﺷﺪه‪ ،‬در اﺧﺘﯿﺎر ﺧﺮﯾﺪاران‬
‫ﻗﺮار ﺑﮕﯿﺮد‪ .‬ﺑﺮای اﯾﻦ ﮐﺎر ﻣﻨﺎﻗﺼﻪای ﻋﻤﻮﻣﯽ ﺑﺮﮔﺰار ﺷﺪ و ﭘﯿﻤﺎﻧﮑﺎران ﺧﺼﻮﺻﯽ رﺗﺒﻪ ﺑﺎﻻ ﺑﻪ آن دﻋﻮت ﺷﺪﻧﺪ‪.‬‬

‫ﯾﮑﯽ از ﺷﺮﮐﺖﻫﺎی ﻫﻤﮑﺎرم ﺑﺮﻧﺪه ﻣﻨﺎﻗﺼﻪ ﺷﺪ‪ .‬از آﻏﺎز‪ ،‬ﻧﮕﺮاﻧﯽ اﺻﻠﯽ ﻣﻦ ﻣﺪﯾﺮﯾﺖ ﻫﺰاران ذیﻧﻔﻊ زﺧﻢﺧﻮرده و‬
‫ﺧﺸﻤﮕﯿﻦ ﭘﺮوژه ﺑﻮد! ﺑﺮﻧﺎﻣﻪای ﮐﻪ در ﻧﻈﺮ ﮔﺮﻓﺘﯿﻢ اﯾﻦ ﺑﻮد ﮐﻪ ﺳﺎﯾﺘﯽ اﯾﻨﺘﺮﻧﺘﯽ ﺳﺎﺧﺘﻪ ﺷﻮد ﮐﻪ ﺧﺮﯾﺪاران ﻫﺮ زﻣﺎن ﮐﻪ‬
‫ﻣﺎﯾﻞ ﺑﻮدﻧﺪ ﺑﺘﻮاﻧﻨﺪ وﺿﻌﯿﺖ ﭘﯿﺸﺮﻓﺖ آﭘﺎرﺗﻤﺎن ﺧﻮد را در آن ﺑﺒﯿﻨﻨﺪ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﻗﺮار ﺷﺪ اﺗﺎﻗﮑﯽ در ورودی ﭘﺮوژه‬
‫ﺳﺎﺧﺘﻪ ﺷﻮد‪ ،‬ﻫﻤﺮاه ﺑﺎ ﻓﺮدی ﮐﻪ ﻣﺴﺌﻮل ﭘﺎﺳﺦﮔﻮﯾﯽ ﺑﻪ ﺗﻤﺎسﻫﺎی ﺗﻠﻔﻨﯽ و ﻣﺮاﺟﻌﻪﮐﻨﻨﺪهﻫﺎی ﺣﻀﻮری ﺑﺎﺷﺪ‪ .‬ﻫﻤﭽﻨﯿﻦ‪،‬‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺮدﯾﻢ ﮐﻪ ﻣﺎﻫﯽ ﯾﮏﺑﺎر اﻣﮑﺎن ﺑﺎزدﯾﺪ از ﭘﺮوژه ﻧﯿﺰ ﺑﺮای ﻫﻤﮕﺎن ﻓﺮاﻫﻢ ﺑﺎﺷﺪ‪.‬‬

‫اﯾﻦ ﻣﻮارد از اﯾﻦ رو ﻟﺤﺎظ ﺷﺪﻧﺪ ﮐﻪ ﻫﻤﯿﺸﻪ اﯾﻦ رﯾﺴﮏ وﺟﻮد داﺷﺖ ﮐﻪ ﺑﺎ وﺟﻮدی ﮐﻪ ﭘﯿﻤﺎﻧﮑﺎر ﺷﺮﮐﺘﯽ ﻣﻌﺘﺒﺮ ﺑﻮد و در‬
‫اﯾﻦ ﭘﺮوژه زﯾﺮﻧﻈﺮ ﻗﻮه ﻗﻀﺎﺋﯿﻪ ﮐﺎر ﻣﯽﮐﺮد‪ ،‬ﺧﺮﯾﺪاران ﺧﺸﻢ ﺧﻮد را ﻣﻌﻄﻮف ﺑﻪ او ﮐﻨﻨﺪ ﯾﺎ ﺣﺘﯽ او را ﻫﻢ ﺑﻪ ﮐﻼهﺑﺮداری‬

‫— ‪— 16‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣ ﺘ ﻬ ﻢ ﮐ ﻨ ﻨ ﺪ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺧﻮب ﮐﺎر ﮐﺮدن ﮐﺎﻓﯽ ﻧﯿﺴﺖ و ﺑﺎﯾﺪ ﺑﻪ ذیﻧﻔﻌﺎن ﻧﺸﺎن دﻫﯿﺪ ﮐﻪ ﺧﻮب ﮐﺎر ﻣﯽﮐﻨﯿﺪ‪.‬‬

‫‪ .3.3.1.2‬ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن‬

‫ﺑﺮ ﭘﺎﯾﻪ اﺻﻞﻫﺎی ‪ ،NUPP‬ﺑﺎﯾﺪ ﺑﺮای ﻫﺮ ﮐﺎری ﮐﻪ اﻧﺠﺎم ﻣﯽدﻫﯿﻢ ﻫﺪﻓﯽ داﺷﺘﻪ ﺑﺎﺷﯿﻢ‪ .‬ﻫﺪف از ﻣﺸﺎرﮐﺖ دادن‬
‫ذ یﻧ ﻔ ﻌﺎ ن ﭼﯿ ﺴ ﺖ ؟‬

‫ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن ﭼﻨﺪﯾﻦ ﻫﺪف دارد‪:‬‬

‫ﻣﯽﺧﻮاﻫﯿﻢ ﻫﻤﻪ اﻟﺰاﻣﺎت ﭘﺮوژه را در زﻣﺎن ﻣﻨﺎﺳﺐ ﮐﺸﻒ ﮐﻨﯿﻢ )ﻧﻤﻮﻧﻪ ﭘﻨﺎﻫﮕﺎه ﮐﻮﻫﺴﺘﺎﻧﯽ(‪.‬‬
‫ﻣﯽﺧﻮاﻫﯿﻢ اﻋﺘﺒﺎر ﺧﻮد را ﺣﻔﻆ ﮐﻨﯿﻢ و ﮔﺮﻓﺘﺎر ﻧﺸﻮﯾﻢ )ﻧﻤﻮﻧﻪ ﭘﯿﺸﯿﻦ درﺑﺎره ﺧﺮﯾﺪاران ﺧﺸﻤﮕﯿﻦ(‪.‬‬
‫ﻣﯽﺧﻮاﻫﯿﻢ از ﭘﺸﺘﯿﺒﺎﻧﯽ ذیﻧﻔﻌﺎن ﺑﻬﺮه ﺑﺒﺮﯾﻢ‪.‬‬
‫و…‬

‫ﺑﺮﺧﯽ ذیﻧﻔﻌﺎن از آﻏﺎز ﺟﺒﻬﻪﮔﯿﺮی ﻣﺜﺒﺘﯽ ﻧﺴﺒﺖ ﺑﻪ ﭘﺮوژه دارﻧﺪ‪ ،‬وﻟﯽ ﺑﺎزﻫﻢ ﺑﺎﯾﺪ از آنﻫﺎ ﻣﺮاﻗﺒﺖ ﮐﺮد ﮐﻪ ﻫﻤﭽﻨﺎن‬
‫ﻣﺜﺒﺖ ﺑﺎﻗﯽ ﺑﻤﺎﻧﻨﺪ‪ .‬ﺑﺮﺧﯽ دﯾﮕﺮ ﺟﺒﻬﻪﮔﯿﺮی ﻣﻨﻔﯽ دارﻧﺪ و ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﻢ ﺑﺎ اﻗﺪامﻫﺎی ﺳﻨﺠﯿﺪه ﺗﻐﯿﯿﺮﺷﺎن دﻫﯿﻢ‪.‬‬

‫زﻣﺎﻧﯽ ﻣﺴﺌﻮل ﭘﯿﺎدهﺳﺎزی ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ در ﺳﺎزﻣﺎﻧﯽ ﺑﺰرگ ﺑﻮدم‪ .‬در ﻣﯿﺎﻧﻪ ﮐﺎر ﺑﺎﺧﺒﺮ ﺷﺪم ﮐﻪ ﯾﮑﯽ از‬
‫ﻣﺪﯾﺮان ارﺷﺪ ﺑﺎ ﮐﺎرﻣﺎن ﻣﻮاﻓﻖ ﻧﯿﺴﺖ و ﺑﺎ آن دﺷﻤﻨﯽ ﻣﯽﮐﻨﺪ‪ .‬درﺑﺎرهاش ﭘﺮس و ﺟﻮ ﮐﺮدم و ﺑﻪ ﻣﻦ ﺗﻮﺿﯿﺢ دادﻧﺪ ﮐﻪ او‬
‫ﻫﻤﯿﺸﻪ ﻓﺮدی ﻣﻨﻔﯽﻧﮕﺮ اﺳﺖ و ﺑﺎ ﺑﯿﺸﺘﺮ ﮐﺎرﻫﺎ ﻣﺨﺎﻟﻔﺖ ﻣﯽﮐﻨﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﺮﺧﻼف ﺑﺴﯿﺎری از ﻣﺪﯾﺮان و ﮐﺎرﮐﻨﺎن‬
‫دﯾﮕﺮ ﮐﻪ ﭘﺲزﻣﯿﻨﻪ ﻓﻨﯽ ﯾﺎ ﮐﺴﺐ و ﮐﺎر داﺷﺘﻨﺪ‪ ،‬ﭘﺲزﻣﯿﻨﻪای ﺳﯿﺎﺳﯽ داﺷﺖ و ﭘﺲ از ﺳﺎلﻫﺎ ﮐﺎر در ﭘﺎرﻟﻤﺎن اروﭘﺎ‬
‫ﺟﺬب اﯾﻦ ﺳﺎزﻣﺎن ﺷﺪه ﺑﻮد ﮐﻪ در ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﺑﯿﻦاﻟﻤﻠﻠﯽ و ﺳﯿﺎﺳﯽ ﮐﻤﮏ ﮐﻨﺪ‪ .‬ﺑﻪ دﻟﯿﻞ ﭘﺲزﻣﯿﻨﻪاش‪ ،‬از ﺳﺎﯾﺮ‬
‫اﻓﺮاد ﺷﺮﮐﺖ ﺟﺪا اﻓﺘﺎده ﺑﻮد‪.‬‬

‫ﺑﺎ اﯾﻦﮐﻪ دﯾﺪﮔﺎه ﻫﻤﮕﯽ اﯾﻦ ﺑﻮد ﮐﻪ ﻧﺒﺎﯾﺪ ﺑﻪ دﺷﻤﻨﯽاش اﻫﻤﯿﺖ داد‪ ،‬ﺑﺎ او ﺗﻤﺎس ﮔﺮﻓﺘﻢ و درﺧﻮاﺳﺖ ﺟﻠﺴﻪ ﮐﺮدم‪ .‬در‬
‫آﻏﺎز ﺟﻠﺴﻪ ﺑﻪ او ﮔﻔﺘﻢ ﮐﻪ ﻣﺎ در ﺣﺎل ﮔﺮدآوری ﻓﻬﺮﺳﺘﯽ از ﻣﻮاردی ﻫﺴﺘﯿﻢ ﮐﻪ ﻣﯽﺗﻮاﻧﻨﺪ ﺑﻪ ﻣﻮﻓﻘﯿﺖ ﭘﺮوژه آﺳﯿﺐ ﺑﺰﻧﻨﺪ‬
‫و اﯾﻦﮐﻪ اﮔﺮ ﻣﯽﺗﻮاﻧﺪ ﻣﻮارد ﺑﯿﺸﺘﺮی در اﺧﺘﯿﺎرﻣﺎن ﺑﮕﺬارد‪ .‬در ﻃﻮل ﺟﻠﺴﻪ ﺑﻪدﻗﺖ ﺑﻪ ﮔﻔﺘﻪﻫﺎﯾﺶ ﮔﻮش ﮐﺮدم و‬
‫ﯾﺎدداﺷﺖ ﺑﺮداﺷﺘﻢ و ﺑﺎاﯾﻦﮐﻪ ﺑﺮﺧﯽ از رﯾﺴﮏﻫﺎﯾﯽ ﮐﻪ ﻣﻄﺮح ﻣﯽﮐﺮد ﭘﺎﺳﺦﻫﺎﯾﯽ داﺷﺘﻨﺪ‪ ،‬ﻫﯿﭻ ﭼﯿﺰ ﻧﮕﻔﺘﻢ‪ .‬ﻓﻘﻂ ﮔﺎﻫﯽ‬
‫ﺑﺮای ﺑﺮﺧﯽ ﻣﻮارد درﺧﻮاﺳﺖ ﺗﻮﺿﯿﺢ ﺑﯿﺸﺘﺮ ﻣﯽﮐﺮدم‪ .‬در ﭘﺎﯾﺎن ﺳﭙﺎﺳﮕﺰاری و ﺟﻠﺴﻪ را ﺗﺮک ﮐﺮدم‪ .‬در اﯾﻦ ﺟﻠﺴﻪ‬
‫ﺗﻮاﻧﺴﺘﻢ دو رﯾﺴﮏ ﺗﺎزه ﺑﻪ ﮐﻤﮏ او ﭘﯿﺪا ﮐﻨﻢ ﮐﻪ ﺧﻮد ﻧﺘﯿﺠﻪای ﺑﺎ ارزش ﺑﻮد‪ ،‬وﻟﯽ ﻫﺪف اﺻﻠﯽ ﻣﻦ ﺑﻬﺒﻮد رواﺑﻂ ﺑﻮد‪.‬‬

‫ﻫﻔﺘﻪ ﺑﻌﺪ درﺧﻮاﺳﺖ ﺟﻠﺴﻪ دﯾﮕﺮی ﮐﺮدم‪ .‬در ﺟﻠﺴﻪ ﺗﻮﺿﯿﺢ دادم ﮐﻪ ﺑﻪ ﻫﻤﺮاه ﺗﯿﻢ واﮐﻨﺶﻫﺎﯾﯽ ﺑﺮای رﯾﺴﮏﻫﺎی‬
‫ﻓﻬﺮﺳﺖ ﺷﺪه ﺗﻌﺮﯾﻒ ﮐﺮدهاﯾﻢ‪ ،‬وﻟﯽ ﻣﻄﻤﺌﻦ ﻧﯿﺴﺘﻢ ﮐﻪ ﮐﺎراﯾﯽ درﺧﻮر داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﮔﻔﺘﻢ ﮐﻪ اﮔﺮ اﻣﮑﺎنﭘﺬﯾﺮ ﺑﺎﺷﺪ‬
‫واﮐﻨﺶﻫﺎی رﯾﺴﮏ را ﻫﻤﺮاه ﻫﻢ ﻣﺮور ﮐﻨﯿﻢ و ﻧﻈﺮش را درﺑﺎره آنﻫﺎ ﺑﮕﻮﯾﺪ‪ .‬اﯾﻦ ﺑﺎر وﺿﻌﯿﺖ ﮔﻔﺘﮕﻮ واروﻧﻪ ﺷﺪ و‬
‫ﺗﻤﺮﮐﺰش ﻣﻌﻄﻮف اراﺋﻪ اﻧﻮاع راﻫﮑﺎر ﺑﺮای رﯾﺴﮏﻫﺎ ﺷﺪ‪.‬‬

‫اﯾﻦ روﻧﺪ ﺑﻪ ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻒ اداﻣﻪ ﭘﯿﺪا ﮐﺮد و او ﭘﺲ از ﯾﮏ ﻣﺎه ﺗﺒﺪﯾﻞ ﺑﻪ ﯾﮑﯽ از ﺑﺰرگﺗﺮﯾﻦ ﭘﺸﺘﯿﺒﺎﻧﺎن ﭘﺮوژه ﺷﺪ‪ .‬ﺑﺎ‬
‫ﭘﺸﺘﯿﺒﺎﻧﯽﻫﺎﯾﺶ ﻣﻨﺎﺑﻊ ﻓﺮاواﻧﯽ در اﺧﺘﯿﺎر ﭘﺮوژه ﻗﺮار ﮔﺮﻓﺖ و ﮐﻤﮏ ﺑﺰرﮔﯽ ﺑﻪ ﭘﯿﺮوزی ﭘﺮوژه ﮐﺮد‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬اﯾﻦ‬

‫— ‪— 17‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﻮﻓﻘﯿﺖ از ﺳﻮی او ﺑﻪ ﮔﻮش ﺑﺮﺧﯽ از اﻋﻀﺎی ﭘﺎرﻟﻤﺎن اروﭘﺎ ﻫﻢ رﺳﯿﺪ و ﻓﺮﺻﺖﻫﺎی ﺑﯿﺸﺘﺮی ﺑﺮای ﭘﺮوژهﻫﺎی ﻣﺸﺎﺑﻪ‬
‫ﻓﺮاﻫﻢ ﮐﺮد‪.‬‬

‫‪ .4.3.1.2‬ارﺗﺒﺎط ﻣﺘﻤﺮﮐﺰ‬

‫ﺑﺎﯾﺪ داﯾﻤﺎ ﺑﺎ ذیﻧﻔﻌﺎن در ارﺗﺒﺎط ﺑﻮد‪ .‬ﻣﻨﺘﻈﺮ ﻧﻤﺎﻧﯿﺪ ﮐﻪ ﺑﻪ ﺷﻤﺎ ﻣﺮاﺟﻌﻪ ﮐﻨﻨﺪ‪ ،‬ﭼﻮن آن زﻣﺎن ﺷﺎﯾﺪ دﯾﺮ ﺑﺎﺷﺪ و ﻫﺮ ﭼﻪ‬
‫زودﺗﺮ اﻧﺘﻈﺎرﻫﺎ و ﻣﺸﮑﻞﻫﺎ را ﮐﺸﻒ ﮐﻨﯿﺪ آﺳﺎنﺗﺮ ﻣﯽﺗﻮاﻧﯿﺪ در ﭘﺮوژه ﻟﺤﺎﻇﺸﺎن ﮐﻨﯿﺪ‪ .‬ﯾﮏ راﻫﮑﺎر ﮐﻪ در ﻣﺘﺪوﻟﻮژی‬
‫‪ P3.express‬ﺑﻪﮐﺎر ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮد ارزﯾﺎﺑﯽ ﻣﺎﻫﺎﻧﻪ رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن اﺳﺖ‪ .‬اﯾﻦ ارزﯾﺎﺑﯽ ﺳﺮﻧﺦﻫﺎی ﻓﺮاواﻧﯽ ﺑﺮای ﯾﺎﻓﺘﻦ‬
‫ﻣﺸﮑﻞﻫﺎ در اﺧﺘﯿﺎرﺗﺎن ﻣﯽﮔﺬارد‪.‬‬

‫راﻫﮑﺎر دﯾﮕﺮی ﮐﻪ در ‪ P3.express‬وﺟﻮد دارد ارﺗﺒﺎط ﻣﺘﻤﺮﮐﺰ اﺳﺖ‪ .‬اﯾﻦ ﻓﻌﺎﻟﯿﺖ در ﭘﺎﯾﺎن ﻫﺮﮐﺪام از ﮔﺮوهﻫﺎی ﻓﻌﺎﻟﯿﺘﯽ‬
‫اﺟﺮا ﻣﯽﺷﻮد و در ﻫﺮ زﻣﺎن ﭘﯿﺎم وﯾﮋهای را ﺑﺮای ﻣﺨﺎﻃﺒﺎن از ﭘﯿﺶﺗﻌﯿﯿﻦ ﺷﺪه ﻣﯽﻓﺮﺳﺘﺪ‪ .‬اﻃﻼﻋﺎﺗﯽ ﮐﻪ اﯾﻨﮕﻮﻧﻪ ﻣﮑﺎﺗﺒﻪ‬
‫ﻣ ﯽ ﺷ ﻮ د ا ز ﺑ ﺮ و ز ﺑ ﺴ ﯿ ﺎ ر ی ﻣ ﺸ ﮑ ﻞ ﻫ ﺎ ﺟﻠ ﻮ ﮔ ﯿ ﺮ ی ﻣ ﯽ ﮐ ﻨ ﺪ‪.‬‬

‫‪ .5 . 3 . 1 . 2‬ﺗ ﻔ ﻮ ﯾ ﺾ ا ﺧ ﺘ ﯿ ﺎ ر‬

‫وﻗﺘﯽ اﻓﺮاد ﻗﺪرت ﺗﺼﻤﯿﻢﮔﯿﺮی داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﺑﯿﺸﺘﺮ ﻣﺸﺎرﮐﺖ و ﻫﻤﮑﺎری ﻣﯽﮐﻨﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﻧﯿﺎز اﺳﺖ ﮐﻪ ﺳﯿﺴﺘﻢ‬
‫ﺗﻔﻮﯾﺾ اﺧﺘﯿﺎر ﻣﻨﺎﺳﺒﯽ در ﭘﺮوژه داﺷﺖ‪ .‬ﻣﺘﺪوﻟﻮژی ﭘﺮﯾﻨﺲ‪ ۲‬ﺳﺎﺧﺘﺎر ﺟﺎﻟﺐ و ﻣﻨﺎﺳﺒﯽ ﺑﺮای اﯾﻦ ﻣﻨﻈﻮر دارد‪ :‬ﭼﻨﺪﯾﻦ‬
‫ﺳﻄﺢ ﺗﺼﻤﯿﻢﮔﯿﺮی در ﭘﺮوژه وﺟﻮد دارد و ﻫﺮ ﺳﻄﺢ اﺧﺘﯿﺎر ﺗﺼﻤﯿﻢﮔﯿﺮی وﯾﮋه ﺧﻮد را دارد‪ .‬ﺑﺮای اﯾﻦ ﻣﻨﻈﻮر ﺣﺪی از اﺛﺮ‬
‫ﺗﺼﻤﯿﻢ ﺑﺮ زﻣﺎن‪ ،‬ﻫﺰﯾﻨﻪ‪ ،‬ﮐﯿﻔﯿﺖ‪ ،‬رﯾﺴﮏ و ﻣﻨﺎﻓﻊ ﺑﺮای ﻫﺮ ﺳﻄﺢ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮد‪ .‬اﮔﺮ اﺛﺮ از ﺣﺪ ﺗﻌﯿﯿﻦ ﺷﺪه‬
‫ﭘﺎﯾﯿﻦﺗﺮ ﺑﺎﺷﺪ‪ ،‬اﻓﺮاد ﺳﻄﺢ ﺑﺎﻻﺗﺮ ﻧﺒﺎﯾﺪ در ﺗﺼﻤﯿﻢﮔﯿﺮی دﺧﺎﻟﺖ ﮐﻨﻨﺪ‪ ،‬و اﮔﺮ اﺛﺮ ﺑﺰرﮔﺘﺮ ﺑﺎﺷﺪ‪ ،‬ﺑﺎﯾﺪ ﺗﺼﻤﯿﻢ را ﺑﻪ ﺳﻄﺢ‬
‫ﺑﺎﻻﺗﺮ ﻓﺮﺳﺘﺎد‪.‬‬

‫در ﯾﮑﯽ از ﭘﺮوژهﻫﺎ ﭘﯿﭽﯿﺪﮔﯽﻫﺎی وﯾﮋهای در ﺳﺎزه ﺑﺘﻨﯽ وﺟﻮد داﺷﺖ‪ .‬ﺑﺮای ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن ﺑﻬﻨﮕﺎم ﭘﺮوژه ﻧﯿﺎز ﺑﻮد ﮐﻪ‬
‫ﺑﺘﻦرﯾﺰیﻫﺎ ﺑﺴﯿﺎر ﺑﻬﯿﻨﻪ اﻧﺠﺎم ﺷﻮﻧﺪ‪ .‬ﯾﮏﺑﺎر ﮐﻪ ﺑﺮای ﺑﺎزدﯾﺪ ﺑﻪ ﭘﺮوژه رﻓﺘﻪ ﺑﻮدم دﯾﺪم ﮐﻪ ﻫﻤﻪ ﻗﺎﻟﺐﻫﺎی ﺑﺘﻦ ﺑﺴﺘﻪ‬
‫ﺷﺪه‪ ،‬آﻣﺎده ﺑﺘﻦرﯾﺰیاﻧﺪ‪ .‬در آن ﭘﺮوژه اﻧﺘﻈﺎر داﺷﺘﯿﻢ ﮐﻪ ﺑﺘﻦرﯾﺰی ﺑﯽدرﻧﮓ اﻧﺠﺎم ﺷﻮد ﺗﺎ ﻗﺎﻟﺐﻫﺎ در زودﺗﺮﯾﻦ زﻣﺎن‬
‫ﻣﻤﮑﻦ آزاد ﺷﺪه‪ ،‬در ﻧﺎﺣﯿﻪ ﺑﻌﺪی ﺑﻪﮐﺎر ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪ .‬ﺑﺎ اﯾﻦ ﺣﺎل‪ ،‬اﺛﺮی از ﺑﺘﻦرﯾﺰی ﻧﺒﻮد‪ .‬وﻗﺘﯽ ﭘﺮﺳﯿﺪم‪ ،‬ﺑﻪ ﻣﻦ ﮔﻔﺘﻨﺪ‬
‫ﮐﻪ ﻗﺎﻟﺐﻫﺎ ﺳﻪ روز ﭘﯿﺶ ﺑﺴﺘﻪ ﺷﺪهاﻧﺪ‪ ،‬وﻟﯽ ﻧﻤﯽﺗﻮاﻧﻨﺪ ﺑﺘﻦرﯾﺰی ﮐﻨﻨﺪ ﭼﻮن ﻧﯿﺎز ﺑﻪ ﻣﺼﺎﻟﺢ ﺗﮑﻤﯿﻠﯽ ﺳﺎدهای دارﻧﺪ ﮐﻪ‬
‫ﻓﻌﻼ در ﮐﺎرﮔﺎه ﻣﻮﺟﻮد ﻧﯿﺴﺖ‪.‬‬

‫ﻣﺪﯾﺮ ﭘﺮوژه‪ ،‬ﮐﻪ در ﮐﺎرﮔﺎه ﻣﺴﺘﻘﺮ ﺑﻮد‪ ،‬اﺧﺘﯿﺎر ﺧﺮﯾﺪ ﻣﺼﺎﻟﺢ ﻧﺪاﺷﺖ و ﺑﺎﯾﺪ درﺧﻮاﺳﺖ را ﺑﻪ دﻓﺘﺮ ﻣﺮﮐﺰی ﻣﯽﻓﺮﺳﺘﺎد و در‬
‫اﯾﻦ ﺑﺎره ﻫﻢ درﺧﻮاﺳﺖ دﯾﺮ ﻓﺮﺳﺘﺎده ﺷﺪه ﺑﻮد و ﻫﻢ دﻓﺘﺮ ﻣﺮﮐﺰی ﺗﺎﺧﯿﺮ داﺷﺖ‪ .‬وﻗﺘﯽ درﺑﺎره ﻗﯿﻤﺖ آن ﻣﺼﺎﻟﺢ ﭘﺮﺳﯿﺪم‪،‬‬
‫ﻣﺘﻮﺟﻪ ﺷﺪم ﮐﻪ ﺑﺴﯿﺎر ارزان اﺳﺖ؛ ﻣﻌﺎدل ﻗﯿﻤﺖ ده ﭘﯿﺘﺰا ﺑﺮای ﺑﺘﻦرﯾﺰی آن ﻣﺤﺪوده )ﺑﻪ دﻟﯿﻞ ﺗﻐﯿﯿﺮ ﺷﺪﯾﺪ ارزش‬
‫رﯾﺎل‪ ،‬از »ﭘﯿﺘﺰا« ﺑﻪ ﻋﻨﻮان واﺣﺪ ﻣﺎﻟﯽ اﺳﺘﻔﺎده ﺧﻮاﻫﻢ ﮐﺮد!( ﺑﺎاﯾﻦﮐﻪ ﻫﺰﯾﻨﻪ ﻫﺮ روز ﺗﺎﺧﯿﺮ در ﭘﺮوژه ﺣﺪود ﻫﺰار ﭘﯿﺘﺰا‬
‫ﺑﻮد‪ .‬از ﺟﯿﺒﻢ ﭘﻮﻟﯽ ﻣﻌﺎدل ﺑﯿﺴﺖ ﭘﯿﺘﺰا درآوردم و ﺑﻪ ﻣﺪﯾﺮ ﭘﺮوژه دادم ﮐﻪ ﮐﺴﯽ را ﺑﺮای ﺧﺮﯾﺪ آن ﻣﺼﺎﻟﺢ ﺑﻪ ﺷﻬﺮ‬
‫ﺑﻔﺮﺳﺘﺪ‪ .‬ﺑﻪ ﻣﻦ ﮔﻔﺖ »وﻟﯽ ﺷﺎﯾﺪ ﺷﺮﮐﺖ ﭘﻮﻟﺖ را ﭘﺲ ﻧﺪﻫﺪ« و ﭘﺎﺳﺦ ﻣﻦ اﯾﻦ ﺑﻮد ﮐﻪ »اﮔﺮ ﺷﺮﮐﺖ آﻧﻘﺪر ﺑﯽﻣﻨﻄﻖ‬
‫ﺑﺎﺷﺪ‪ ،‬ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻢ ﻫﻤﮑﺎریام را ﺑﺎ آن ﻣﺘﻮﻗﻒ ﮐﻨﻢ‪«.‬‬

‫— ‪— 18‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﮔﺮ ﻣﺪﯾﺮ ﭘﺮوژه ﯾﺎ ﻫﺮ ﻓﺮد دﯾﮕﺮی ﺑﻪاﻧﺪازه اﺧﺘﯿﺎر ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﮐﺎرﻫﺎ ﺑﻪ ﺧﻮﺑﯽ ﭘﯿﺶ ﻧﺨﻮاﻫﻨﺪ رﻓﺖ‪.‬‬

‫‪ .4.1.2‬ﺑﺮ ارزشآﻓﺮﯾﻨﯽ ﺗﻤﺮﮐﺰ ﮐﻨﯿﺪ‬

‫ﻓﺮض ﮐﻨﯿﺪ درﮔﯿﺮ اﺟﺮای ﭘﺮوژهای ﻫﺴﺘﯿﺪ ﮐﻪ ﺣﺘﻤﺎ ﺑﺎﯾﺪ در ﺗﺎرﯾﺦ ﺧﺎﺻﯽ ﭘﺎﯾﺎن ﯾﺎﺑﺪ ﺗﺎ در ﻣﺮاﺳﻤﯽ ﻣﺎﻧﻨﺪ ﻣﺴﺎﺑﻘﻪ ورزﺷﯽ‬
‫ﺑﻪﮐﺎر رود‪ .‬در ﺗﺎزهﺗﺮﯾﻦ ارزﯾﺎﺑﯽ ﭘﯿﺸﺮﻓﺖ ﻣﺘﻮﺟﻪ ﻣﯽﺷﻮﯾﺪ ﮐﻪ ﭘﺮوژه دو ﻣﺎه ﺗﺎﺧﯿﺮ ﺧﻮاﻫﺪ داﺷﺖ‪ .‬ﭘﺲ از ﺑﺮرﺳﯽ ﻫﻤﻪ‬
‫ﺟﻮاﻧﺐ‪ ،‬ﺑﻪ دو راﻫﮑﺎر ﻣﯽرﺳﯿﺪ‪:‬‬

‫‪ .1‬ﻣﯽﺗﻮاﻧﯿﺪ ﮐﯿﻔﯿﺖ ﮐﺎر را ﺗﺎ ﺣﺪاﻗﻠﯽ ﮐﻪ ﭘﺬﯾﺮﻓﺘﻨﯿﺴﺖ ﮐﺎﻫﺶ دﻫﯿﺪ ﺗﺎ ﮐﺎر ﺳﺮﯾﻊﺗﺮ ﺷﺪه‪ ،‬ﺑﻬﻨﮕﺎم ﭘﺎﯾﺎن ﯾﺎﺑﺪ‪.‬‬
‫‪ .2‬ﻣﯽﺗﻮاﻧﯿﺪ ﺑﯿﺸﺘﺮ ﻫﺰﯾﻨﻪ ﮐﻨﯿﺪ و ﻣﻨﺎﺑﻊ ﭘﺮوژه را اﻓﺰاﯾﺶ داده‪ ،‬آن را ﺑﻬﻨﮕﺎم ﺑﻪ ﭘﺎﯾﺎن ﺑﺮﺳﺎﻧﯿﺪ‪.‬‬

‫ﮐﺪام راه را اﻧﺘﺨﺎب ﻣﯽﮐﻨﯿﺪ؟‬

‫ﺑﺎ اﻃﻼﻋﺎت ﻣﻮﺟﻮد ﻧﻤﯽﺗﻮان ﭘﺎﺳﺦ ﻣﻨﺎﺳﺒﯽ ﺑﻪ اﯾﻦ ﭘﺮﺳﺶ داد زﯾﺮا ﻧﻤﯽداﻧﯿﻢ ﮐﻪ ﻫﺪف از اﺟﺮای ﭘﺮوژه ﭼﯿﺴﺖ‪ .‬اﮔﺮ‬
‫ﻫﺪف اﻓﺰاﯾﺶ اﻋﺘﺒﺎر ﺷﺮﮐﺖ و ورود ﺑﻪ ﺑﺎزاری ﺗﺎزه ﺑﺎﺷﺪ‪ ،‬ﺷﺎﯾﺪ ﺑﺎﯾﺪ ﮔﺰﯾﻨﻪ دوم را اﻧﺘﺨﺎب ﮐﺮد زﯾﺮا دﯾﮕﺮی ﻧﻘﺾ ﻏﺮض‬
‫اﺳﺖ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬اﮔﺮ ﭘﺮوژه ﻓﻘﻂ ﺑﺎ ﻫﺪف ﻣﺎﻟﯽ اﻧﺠﺎم ﻣﯽﺷﻮد‪ ،‬ﺷﺎﯾﺪ ﮔﺰﯾﻨﻪ ﻧﺨﺴﺖ ﻣﻨﺎﺳﺐﺗﺮ ﺑﺎﺷﺪ‪.‬‬

‫‪ .1.4.1.2‬ﭼﺮاﯾﯽ‬

‫ﭘﯿﺶ از اﺟﺮای ﻫﺮ ﭘﺮوژهای ﺑﺎﯾﺪ ﭼﺮاﯾﯽ اﻧﺠﺎم آن را ﺑﻪﺧﻮﺑﯽ درک ﮐﺮد زﯾﺮا ﻫﺮآنﭼﻪ در ﭘﺮوژه اﻧﺠﺎم ﻣﯽﺷﻮد ﺑﺎﯾﺪ ﺑﺎ آن‬
‫ﻫﻤﺴﻮ ﺑﺎﺷﺪ و ﺗﺼﻤﯿﻢﻫﺎی ﮐﻼن ﺑﺮ آن ﭘﺎﯾﻪ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪ .‬اﯾﻦ درک ﻣﺤﺪود ﺑﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﻧﯿﺴﺖ و ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ ﺑﻪ‬
‫آن ﻧﯿﺎز دارﻧﺪ‪.‬‬

‫ﭼﻨﺪی ﭘﺲ از آﻏﺎز ﭘﺮوژه ﻧﺎﺳﺎ ﺑﺮای ﻓﺮﺳﺘﺎدن اوﻟﯿﻦ ﻓﻀﺎﻧﻮرد ﺑﻪ ﻣﺎه‪ ،‬رﯾﯿﺲ ﺟﻤﻬﻮر وﻗﺖ آﻣﺮﯾﮑﺎ‪ ،‬ﮐﻨﺪی‪ ،‬از ﻧﺎﺳﺎ ﺑﺎزدﯾﺪ‬
‫ﮐﺮد‪ .‬در ﻫﻨﮕﺎم ﺑﺎزدﯾﺪ‪ ،‬ﯾﮑﯽ از ﻣﺴﺘﺨﺪمﻫﺎی ﻧﺎﺳﺎ را ﺟﺎرو ﺑﻪ دﺳﺖ دﯾﺪ و ﻣﺎﻧﻨﺪ ﻫﺮ رﯾﯿﺲ ﺟﻤﻬﻮر دﯾﮕﺮی ﮐﻪ ﻫﻤﯿﺸﻪ‬
‫ﮐﻮﺷﺶ ﻣﯽﮐﻨﺪ ﺧﻮد را ﻣﺮدﻣﯽ ﺟﻠﻮه دﻫﺪ‪ ،‬ﺑﺎ او ﺳﻼم و اﺣﻮالﭘﺮﺳﯽ ﮐﺮد‪ .‬از ﻣﺴﺘﺨﺪم ﭘﺮﺳﯿﺪ ﮐﻪ ﮐﺎرش ﭼﯿﺴﺖ و او در‬
‫ﭘﺎﺳﺦ ﮔﻔﺖ »ﮐﻤﮏ ﻣﯽﮐﻨﻢ ﮐﻪ ﻓﻀﺎﻧﻮرد ﺑﻪ ﻣﺎه ﺑﻔﺮﺳﺘﯿﻢ!«‬

‫اﮔﺮ ﺑﺘﻮاﻧﯿﺪ ﺑﺴﺘﺮی در ﭘﺮوژه ﺑﻪ وﺟﻮد آورﯾﺪ ﮐﻪ ﻫﻤﻪ ﺑﺮﺧﻮردی ﻫﻤﺎﻧﻨﺪ آن ﻣﺴﺘﺨﺪم داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ ،‬اﺣﺘﻤﺎل ﻣﻮﻓﻘﯿﺘﺘﺎن‬
‫ﺑﻪﻣﺮاﺗﺐ ﺑﺎﻻﺗﺮ ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬

‫‪ .2 . 4 . 1 . 2‬ﺗ ﻮ ﺟ ﯿ ﻪ ﭘ ﺬ ﯾ ﺮ ی‬

‫ﻫﻤﻪ راﻫﻨﻤﺎﻫﺎ و ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺮ اﻫﻤﯿﺖ درک ﭼﺮاﯾﯽ ﭘﺮوژهﻫﺎ ﭘﺎﻓﺸﺎری ﻣﯽﮐﻨﻨﺪ‪ ،‬وﻟﯽ آن را ﺑﻪ ﺷﮑﻞ‬
‫ﯾﮑﺴﺎﻧﯽ در ﺳﯿﺴﺘﻢ ﺧﻮد ﺑﺎزﺗﺎب ﻧﻤﯽدﻫﻨﺪ‪ .‬راه ﻣﺘﺪاول اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺮ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه ﺗﻤﺮﮐﺰ ﮐﻨﯿﻢ ﮐﻪ ﯾﮑﯽ از‬
‫اﺻﻞﻫﺎی ﭘﺮﯾﻨﺲ‪ ۲‬ﻫﻢ ﻫﺴﺖ‪ .‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه ﻣﻌﻤﻮﻻ در ﺳﻨﺪی ﺑﺎ ﻧﺎم اﻧﮕﯿﺰه ﺗﺠﺎری )‪ ( business case‬ﺛﺒﺖ‬
‫ﻣﯽﺷﻮد‪ .‬اﯾﻦ ﺳﻨﺪ ﺑﺎﯾﺪ داﯾﻤﺎ ﺑﺮ ﭘﺎﯾﻪ ﺗﺎزهﺗﺮﯾﻦ ﭘﯿﺶﺑﯿﻨﯽﻫﺎی زﻣﺎن و ﻫﺰﯾﻨﻪ و دﯾﮕﺮ ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﺑﺎزﺑﯿﻨﯽ و ﺳﭙﺲ‬
‫ﺑﺮای ﻣﺪﯾﺮان ارﺷﺪ ﻓﺮﺳﺘﺎده ﺷﻮد ﺗﺎ درﺑﺎره ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮﻧﺪ‪.‬‬

‫— ‪— 19‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .3.4.1.2‬ارزش‬

‫ﻧﺴﺨﻪ ﻫﻔﺘﻢ ﭘﻢﺑﺎک ﺑﻪ ﺟﺎی »ﺗﻮﺟﯿﻪﭘﺬﯾﺮی« ﺑﺮ ارزش ﯾﺎ ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ ارزشآﻓﺮﯾﻨﯽ ﻣﺘﻤﺮﮐﺰ اﺳﺖ و ﺗﻮﺟﯿﻪﭘﺬﯾﺮی را‬
‫ﻣﻘﻮﻟﻪای زﯾﺮﻣﺠﻤﻮﻋﻪ آن ﻣﯽداﻧﺪ‪.‬‬

‫ارزش ﺗﻌﺮﯾﻔﯽ ﯾﮑﻪ ﻧﺪارد‪ ،‬وﻟﯽ ﺑﻬﺘﺮﯾﻦ ﺗﻌﺮﯾﻒ ﺑﺮای آن ﮐﻪ ﺑﺎ ﻣﻨﺎﺑﻊ ﺗﺨﺼﺼﯽ ﻧﯿﺰ ﺳﺎزﮔﺎر اﺳﺖ‪ ،‬ﻧﺴﺒﺖ ﻣﻨﺎﻓﻊ ﺑﻪ ﻫﺰﯾﻨﻪ‬
‫اﺳﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪:‬‬

‫ﭘﺮوژه ‪ – ۱‬ﻣﻨﺎﻓﻊ‪ :‬ﻣﻌﺎدل ده ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا‪ ،‬ﻫﺰﯾﻨﻪ‪ :‬ﻣﻌﺎدل ﭼﻬﺎر ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا‬
‫ﭘﺮوژه ‪ – ۲‬ﻣﻨﺎﻓﻊ‪ :‬ﻣﻌﺎدل ده ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا‪ ،‬ﻫﺰﯾﻨﻪ‪ :‬ﻣﻌﺎدل دو ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا‬

‫در اﯾﻦ ﺣﺎﻟﺖ ارزش ﭘﺮوژه دوم دو ﺑﺮاﺑﺮ ﭘﺮوژه ﻧﺨﺴﺖ اﺳﺖ و ﻣﯽﺗﻮان ﮔﻔﺖ ﮐﻪ ﭘﺮوژه دوم ﺑﺎارزشﺗﺮ اﺳﺖ‪.‬‬

‫ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ در ﮔﻔﺘﺎر روزﻣﺮه ﺑﺴﯿﺎری از اﻓﺮاد‪» ،‬ارزش« ﺑﺮاﺑﺮ »ﻣﻨﻔﻌﺖ« اﺳﺖ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ ﺣﺘﯽ در ﺑﺮﺧﯽ از‬
‫ﻣﻨﺎﺑﻊ ﻣﺮﺑﻮط ﺑﻪ ﭘﺮوژه‪ ،‬ﺑﻪوﯾﮋه ﻣﻨﺎﺑﻊ ﭼﺎﺑﮏ‪ ،‬ارزش ﺑﻪ ﻫﺮ دو ﻣﻌﻨﯽ ﺑﻪ ﮐﺎر ﻣﯽرود و ﺑﺎﻋﺚ ﺳﺮدرﮔﻤﯽ ﻓﺮاوان ﻣﯽﺷﻮد‪ .‬در‬
‫اﯾﻦ ﮐﺘﺎب ارزش ﺑﻪ ﻣﻌﻨﯽ ﻧﺴﺒﺖ ﻣﻨﺎﻓﻊ ﺑﻪ ﻫﺰﯾﻨﻪﻫﺎ ﺑﻪ ﮐﺎر ﻣﯽرود‪.‬‬

‫‪ .4 . 4 . 1 . 2‬ﻣ ﻨ ﺎ ﻓ ﻊ‬

‫ﻣﻨﻈﻮر از ارزش‪ ،‬ﻧﺴﺒﺖ ﻣﻨﺎﻓﻊ ﺑﻪ ﻫﺰﯾﻨﻪ اﺳﺖ‪ .‬ﻫﺰﯾﻨﻪ ﻣﻘﻮﻟﻪ ﮐﻤﺎﺑﯿﺶ ﺳﺮراﺳﺘﯽ اﺳﺖ‪ ،‬وﻟﯽ ﻣﻔﻬﻮم ﻣﻨﻔﻌﺖ را ﺑﺎﯾﺪ‬
‫ﺑﯿﺸﺘﺮ ﺑﺮرﺳﯽ ﮐﺮد‪.‬‬

‫ﭘﻮﻟﯽ ﮐﻪ ﺑﺮای ﮐﺎری درﯾﺎﻓﺖ ﻣﯽﮐﻨﯿﺪ ﻧﻤﻮﻧﻪای از ﻣﻨﻔﻌﺖ اﺳﺖ‪ ،‬وﻟﯽ ﻣﻨﻔﻌﺖ ﺑﻪ اﯾﻦ ﻣﻮرد ﺳﺎده ﻣﺤﺪود ﻧﻤﯽﺷﻮد‪ .‬ﺑﺮﺧﯽ‬
‫ﭘﺮوژهﻫﺎ ﻣﻨﻔﻌﺖﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﻧﺠﺎت دادن ﺟﺎن اﻓﺮاد‪ ،‬ﺑﻬﺒﻮد وﺿﻌﯿﺖ زﻧﺪﮔﯽ‪ ،‬و ﮐﻤﮏ ﺑﻪ ﻣﺤﯿﻂ زﯾﺴﺖ دارﻧﺪ‪ .‬ﻫﻤﻪ اﯾﻦ‬
‫ﻣﻮارد‪ ،‬ﯾﺎ دﺳﺖﮐﻢ ﺷﮑﻞ ﮐﻤﯽ ﺷﺪه آنﻫﺎ‪ ،‬ﻣﻨﻔﻌﺖ ﺑﻪ ﺷﻤﺎر ﻣﯽرود‪ .‬اﮔﺮ اﻋﺘﺒﺎر ﺷﺮﮐﺘﺘﺎن ﺑﺎ اﻧﺠﺎم ﭘﺮوژه ﺑﻬﺒﻮد ﭘﯿﺪا ﮐﻨﺪ‪،‬‬
‫آ ن ﻫ ﻢ ﻧ ﻮ ﻋ ﯽ ﻣ ﻨ ﻔ ﻌ ﺖ ا ﺳ ﺖ ‪ ،‬ﯾ ﺎ د ﺳ ﺖ ﮐ ﻢ ﻧ ﺘ ﯿ ﺠ ﻪ ا ی ﮐ ﻪ ﻣ ﯽ ﺗ ﻮ ا ﻧ ﺪ ﻣ ﻨ ﺠ ﺮ ﺑ ﻪ ﻣ ﻨ ﻔ ﻌ ﺖ ﺷ ﻮ د‪.‬‬

‫ﻫﺮ ﺳﺎزﻣﺎن ﻣﺠﻤﻮﻋﻪای از ﻣﻌﯿﺎرﻫﺎی ارزش )‪ (value drivers‬دارد‪ .‬اﯾﻦ ﻣﻌﯿﺎرﻫﺎ در ﺳﺎزﻣﺎنﻫﺎی ﻣﺘﻔﺎوت ﯾﮑﺴﺎن‬
‫ﻧﯿﺴﺘﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺑﻬﺒﻮد وﺿﻌﯿﺖ زﻧﺪﮔﯽ را در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪:‬‬

‫ﻣﯽﺗﻮاﻧﺪ ﻣﻌﯿﺎر ارزش اﺻﻠﯽ ﺑﺮای ﻣﻮﺳﺴﻪای ﻏﯿﺮاﻧﺘﻔﺎﻋﯽ ﺑﺎﺷﺪ‪.‬‬

‫ﻣﯽﺗﻮاﻧﺪ ﻣﻌﯿﺎری ﻓﺮﻋﯽ ﺑﺮای ﯾﮏ ﺷﺮﮐﺖ ﺧﺼﻮﺻﯽ ﺑﺎﺷﺪ ﮐﻪ ﻣﻌﯿﺎر اﺻﻠﯽاش درآﻣﺪزاﯾﯿﺴﺖ‪.‬‬
‫ﻣﯽﺗﻮاﻧﺪ ﻫﯿﭻ ارزﺷﯽ ﺑﺮای ﺑﺮﺧﯽ ﺷﺮﮐﺖﻫﺎ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ارزش و ﻣﻨﻔﻌﺖ ﻋﯿﻨﯽ ﻧﯿﺴﺘﻨﺪ‪.‬‬

‫‪ .5 . 4 . 1 . 2‬د ﯾ ﺪ ﻫ ﻤ ﻪ ﺟ ﺎ ﻧ ﺒ ﻪ‬

‫از آﻧﺠﺎﯾﯽ ﮐﻪ ارزش ﻋﯿﻨﯽ ﻧﯿﺴﺖ و ﺑﺮای ﻫﺮﮐﺲ ﻣﺘﻔﺎوت اﺳﺖ‪ ،‬ﺑﺮای ارزﯾﺎﺑﯽ ارزش ﭘﺮوژه ﺑﺎﯾﺪ دﯾﺪی ﻫﻤﻪﺟﺎﻧﺒﻪ داﺷﺖ‬
‫و آن را در ﺑﺴﺘﺮ ﮐﻠﯽ ﺳﺎزﻣﺎن ﺳﻨﺠﯿﺪ و ﻧﻪ ﺗﻨﻬﺎ درون ﭘﺮوژه‪.‬‬

‫— ‪— 20‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ارزش ﻫﺮ ﭘﺮوژهای‪ ،‬ﮔﺬﺷﺘﻪ از ﻣﺸﺨﺼﺎت ﺧﻮد ﭘﺮوژه‪ ،‬ﺑﺴﺘﮕﯽ ﺑﻪ دﯾﮕﺮ ﭘﺮوژهﻫﺎ و ﻋﻤﻠﯿﺎت ﺳﺎزﻣﺎن ﻧﯿﺰ دارد‪ ،‬ﻫﻢ ﻣﻮارد‬
‫ﮐﻨﻮﻧﯽ و ﻫﻢ ﻣﻮاردی ﮐﻪ ﺷﺎﯾﺪ در آﯾﻨﺪه ﺑﻪ وﺟﻮد آﯾﻨﺪ‪ .‬ﮔﺎﻫﯽ ﺳﯿﺎﺳﺖﻫﺎی ﮐﺸﻮر و ﻣﺴﺎﯾﻞ ﺟﻬﺎﻧﯽ ﻫﻢ ﺑﺮ ارزش ﭘﺮوژه‬
‫اﺛﺮ ﻣﯽﮔﺬارﻧﺪ‪ .‬ﺷﺎﯾﺪ ﺑﺮای ﭘﺮوژهﺗﺎن در آﻏﺎز ارزﺷﯽ ﭘﯿﺶﺑﯿﻨﯽ ﮐﻨﯿﺪ‪ ،‬وﻟﯽ ﮐﻤﯽ ﺑﻌﺪ ﺑﺎ اﻓﺰوده ﺷﺪن ﭘﺮوژهای ﺗﺎزه‬
‫ﺑﺮﻫﻤﮑﻨﺸﯽ رخ دﻫﺪ ﮐﻪ ارزش ﭘﺮوژه ﭘﯿﺸﯿﻦ ﻧﯿﺰ ﺑﯿﺸﺘﺮ ﺷﻮد‪.‬‬

‫ﺳﺎلﻫﺎی آﻏﺎزﯾﻨﯽ ﮐﻪ ﺗﺮﺟﻤﻪ و ﺗﺎﻟﯿﻒ ﻣﯽﮐﺮدم ﺑﺎ دو ﻧﺎﺷﺮ ﺑﺴﯿﺎر ﺧﻮب ﮐﺎر ﻣﯽﮐﺮدم‪ .‬از روﻧﺪ ﮐﺎر ﺧﺮﺳﻨﺪ ﺑﻮدم‪ ،‬وﻟﯽ‬
‫ﻣﺤﺪودﯾﺖﻫﺎی ﻃﺒﯿﻌﯽ ﻧﺸﺮ ﺳﻨﺘﯽ‪ ،‬از ﺟﻤﻠﻪ اﯾﻦﮐﻪ دﺳﺘﺮﺳﯽ ﺑﻪ ﮐﺘﺎبﻫﺎ در ﺑﺮﺧﯽ ﺷﻬﺮﻫﺎ دﺷﻮار ﺑﻮد‪ ،‬ﺑﺎﻋﺚ ﺷﺪ ﮐﻪ‬
‫ﮐﻢﮐﻢ ﺑﻪ ﻓﮑﺮ ﻧﺸﺮ اﻟﮑﺘﺮوﻧﯿﮑﯽ ﮐﺘﺎبﻫﺎﯾﻢ ﺑﯿﻔﺘﻢ‪ .‬اﯾﻦ ﮔﺰﯾﻨﻪ ﺑﻪ ﻧﻈﺮ ﺧﯿﻠﯽﻫﺎ ﺗﺮﺳﻨﺎک ﺑﻮد‪ ،‬وﻟﯽ در ﻋﻤﻞ ﻧﺘﯿﺠﻪ ﺑﺴﯿﺎر‬
‫ﺧﻮﺑﯽ داﺷﺖ و ﻣﻨﺎﻓﻊ ﺑﺮآﻣﺪه از ﻧﺸﺮ اﻟﮑﺘﺮوﻧﯿﮑﯽ ﺑﺮاﯾﻢ ﺣﺪود ‪ ۲۰‬ﺑﺮاﺑﺮ ﺑﯿﺸﺘﺮ از ﻧﺸﺮ ﺳﻨﺘﯽ ﺷﺪ‪ .‬ﺳﺎلﻫﺎ ﻣﺎﺟﺮا اﯾﻨﮕﻮﻧﻪ‬
‫ﭘﯿﺶ رﻓﺖ ﺗﺎ اﯾﻦﮐﻪ ارزش ﻓﺮﺻﺖ و ﻣﻌﯿﺎرﻫﺎی ارزﺷﻢ ﺑﻪﮔﻮﻧﻪای ﺗﻐﯿﯿﺮ ﮐﺮد ﮐﻪ درآﻣﺪزاﯾﯽ از ﻧﺸﺮ ﮐﺘﺎب دﯾﮕﺮ ﮔﺰﯾﻨﻪ‬
‫ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺑﺮاﯾﻢ ﻧﯿﺴﺖ و از اﯾﻦ رو اﮐﻨﻮن ﮐﺘﺎبﻫﺎ را آزاد و راﯾﮕﺎن ﻣﻨﺘﺸﺮ ﻣﯽﮐﻨﻢ‪.‬‬

‫از ﻫﻤﻪ اﯾﻦ ﻣﺴﺎﯾﻞ ﮐﻪ ﺑﮕﺬرﯾﻢ‪ ،‬ﻫﺪﻓﻢ اراﺋﻪ ﻧﻤﻮﻧﻪای ﺟﺎﻟﺐ از ﺑﺮﻫﻤﮑﻨﺶﻫﺎ ﺑﻮد‪ :‬ﺑﻪ ازای ﻫﺮ ﮐﺘﺎب ﺗﺎزهای ﮐﻪ ﻣﻨﺘﺸﺮ‬
‫ﻣﯽﮐﺮدم ﻓﺮوش دﯾﮕﺮ ﮐﺘﺎبﻫﺎ از ‪ ۵‬ﺗﺎ ‪ ۱۵‬درﺻﺪ اﻓﺰاﯾﺶ ﭘﯿﺪا ﻣﯽﮐﺮد! ﯾﮑﯽ از ﮐﺘﺎبﻫﺎ را در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ و ﺗﺼﻮر ﮐﻨﯿﺪ‬
‫ﭘﺮوژه ﺑﺰرﮔﯿﺴﺖ ﮐﻪ ﺻﺪﻫﺎ ﻧﻔﺮ در آن ﻓﻌﺎﻟﯿﺖ ﻣﯽﮐﻨﻨﺪ‪ .‬آﯾﺎ ﻣﯽﺗﻮاﻧﯿﻢ ارزش اﯾﻦ ﭘﺮوژه را ﺗﻨﻬﺎ درون ﻣﺮزﻫﺎی ﭘﺮوژه‬
‫ارزﯾﺎﺑﯽ و درک ﮐﻨﯿﻢ ﯾﺎ ﻧﯿﺎز اﺳﺖ دﯾﺪی ﮐﻼن و ﻫﻤﻪﺟﺎﻧﺒﻪ در ﺳﻄﺢ ﺳﺎزﻣﺎن داﺷﺘﻪ ﺑﺎﺷﯿﻢ؟‬

‫‪ .6.4.1.2‬ﺑﺎزﮔﺸﺖ ﮐﻮﺗﺎهﻣﺪت ﯾﺎ ﺑﻠﻨﺪﻣﺪت‬

‫ﻓﺮض ﮐﻨﯿﺪ ﻣﻨﺒﻊﻫﺎﯾﯽ ﮐﻪ دارﯾﺪ ﺗﻨﻬﺎ ﺑﺮای اﻧﺠﺎم ﯾﮑﯽ از دو ﭘﺮوژه زﯾﺮ ﺑﺴﻨﺪه ﻣﯽﮐﻨﺪ‪:‬‬

‫‪ .1‬ﭘﺮوژه ‪ – ۱‬ﺑﺎ ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن ﭘﺮوژه ﻣﻌﺎدل ﯾﮏ ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا ﭘﻮل ﺑﻪ دﺳﺖ ﺧﻮاﻫﯿﺪ آورد‪.‬‬
‫‪ .2‬ﭘﺮوژه ‪ – ۲‬ﭘﺲ از ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن ﭘﺮوژه‪ ،‬ﺑﻪ ﻣﺪت ﺑﯿﺴﺖ ﺳﺎل‪ ،‬ﻫﺮ ﺳﺎل ﻣﻌﺎدل ﺳﯿﺼﺪ ﻫﺰار ﭘﯿﺘﺰا ﺑﻪ دﺳﺖ‬
‫ﺧﻮاﻫﯿﺪ آورد‪.‬‬

‫ﮐﺪام ﭘﺮوژه را اﻧﺘﺨﺎب ﻣﯽﮐﻨﯿﺪ؟‬

‫اﮔﺮ ﭘﯿﺶ از اﯾﻦ ﺗﻨﻬﺎ روی ﭘﺮوژهﻫﺎی ﺑﻠﻨﺪﻣﺪت ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﺮده ﺑﺎﺷﯿﺪ ﻧﯿﺎز ﺑﻪ درآﻣﺪ ﮐﻮﺗﺎهﻣﺪت ﺧﻮاﻫﯿﺪ داﺷﺖ و از‬
‫اﯾﻦ رو ﺷﺎﯾﺪ ﮔﺰﯾﻨﻪ ﻧﺨﺴﺖ ﺑﻬﺘﺮ ﺑﺎﺷﺪ‪ .‬اﮔﺮ ﺷﺮﮐﺖ دﭼﺎر ﭼﺎﻟﺶ ﻣﺎﻟﯽ و در ﺷﺮف ورﺷﮑﺴﺘﮕﯽ ﺑﺎﺷﺪ‪ ،‬ﺑﯽﮔﻤﺎن ﮔﺰﯾﻨﻪ‬
‫ﻧﺨﺴﺖ ﺑﻬﺘﺮ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬اﮔﺮ ﭼﺎﻟﺸﯽ در درآﻣﺪﻫﺎی ﮐﻮﺗﺎهﻣﺪت وﺟﻮد ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﺷﺎﯾﺪ ﮔﺰﯾﻨﻪ دوم را ﺗﺮﺟﯿﺢ دﻫﯿﺪ‪.‬‬

‫اﯾﻦ ﻧﻤﻮﻧﻪ دﯾﮕﺮی از ﻣﻮاردﯾﺴﺖ ﮐﻪ ارزﯾﺎﺑﯽ ارزش ﭘﺮوژه ﺑﺴﺘﮕﯽ ﺑﻪ وﺿﻌﯿﺖ ﮐﻼن ﺳﺎزﻣﺎن ﭘﯿﺪا ﻣﯽﮐﻨﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﻧﯿﺎز‬
‫ا ﺳ ﺖ ﮐ ﻪ ا ر ز ﯾ ﺎ ﺑ ﯽ د ر آ ن ﺳ ﻄ ﺢ ا ﻧ ﺠ ﺎ م ﺷ ﻮ د‪.‬‬

‫ﮐﺴﺎﻧﯽ ﮐﻪ در ﭼﻨﯿﻦ ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎﯾﯽ ﻣﺸﺎرﮐﺖ ﻣﯽﮐﻨﻨﺪ ﻫﻢ ﺑﺎﯾﺪ ﺑﺎ دﻗﺖ اﻧﺘﺨﺎب ﺷﻮﻧﺪ‪ .‬ﻣﺸﮑﻠﯽ راﯾﺞ در ﺑﺮﺧﯽ‬
‫ﺳﺎزﻣﺎنﻫﺎی ﺑﺰرگ اﯾﻦ اﺳﺖ ﮐﻪ ﻓﺮدی ﻣﺸﻬﻮر را ﺑﻪ ﻃﻮر ﮐﻮﺗﺎهﻣﺪت ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮﻋﺎﻣﻞ اﻧﺘﺨﺎب ﻣﯽﮐﻨﻨﺪ‪ .‬او ﮐﻪ ﻣﯽداﻧﺪ‬
‫ﺑﯿﺶ از ﭼﻨﺪ ﺳﺎل ﻣﺪﯾﺮﻋﺎﻣﻞ ﻧﺨﻮاﻫﺪ ﺑﻮد‪ ،‬ﺗﻨﻬﺎ ﻫﺪﻓﺶ اﯾﺠﺎد ﺳﺎﺑﻘﻪ ﺑﻬﺘﺮ ﺑﺮای ﺧﻮدش ﺧﻮاﻫﺪ ﺑﻮد و درﻧﺘﯿﺠﻪ ﺑﻪ ﺟﺎی‬
‫اﯾﻦﮐﻪ ﺗﺮﮐﯿﺒﯽ از ﺑﻬﺘﺮﯾﻦ ﭘﺮوژهﻫﺎ را اﻧﺘﺨﺎب ﮐﻨﺪ‪ ،‬ﻓﻘﻂ روی ﭘﺮوژهﻫﺎﯾﯽ ﺑﺎ ﺑﺎزﮔﺸﺖ ﮐﻮﺗﺎهﻣﺪت ﺗﻤﺮﮐﺰ ﻣﯽﮐﻨﺪ‪ .‬ﺑﺮﺧﯽ از‬
‫آنﻫﺎ ﺣﺘﯽ آﯾﻨﺪه ﺑﻠﻨﺪﻣﺪت ﺳﺎزﻣﺎن را ﻓﺪای درﺧﺸﺶ ﺑﯿﺸﺘﺮ ﮐﻮﺗﺎهﻣﺪت ﻣﯽﮐﻨﻨﺪ‪ .‬ﭘﺲ از ﭼﻨﺪی‪ ،‬ارزﯾﺎﺑﯽﻫﺎی ﻧﺎﺷﯿﺎﻧﻪ‬

‫— ‪— 21‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻧﺸﺎن ﻣﯽدﻫﻨﺪ ﮐﻪ در زﻣﺎن ﻣﺪﯾﺮﯾﺖ آن ﻓﺮد ﻣﻨﺎﻓﻊ ﺳﺎزﻣﺎن ﭼﻨﺪﯾﻦ ﺑﺮاﺑﺮ ﺷﺪه ﺑﻮد و ﭘﺲ از اﯾﻦﮐﻪ ﺳﺎزﻣﺎن را ﺗﺮک ﮐﺮد‬
‫ﻫﻤﻪﭼﯿﺰ اﻓﺖ ﮐﺮد و از اﯾﻦ ﻣﺴﺌﻠﻪ ﻧﺘﯿﺠﻪ ﻣﯽﮔﯿﺮﻧﺪ ﮐﻪ ﻣﺪﯾﺮﯾﺖ وی ﺑﺴﯿﺎر ﺧﻮب ﺑﻮده اﺳﺖ‪ ،‬در ﺣﺎﻟﯽ ﮐﻪ اﯾﻦﭼﻨﯿﻦ‬
‫ﻧ ﯿ ﺴ ﺖ‪.‬‬

‫‪ .7.4.1.2‬ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ‬

‫دﻟﯿﻞ از ﻃﺮح ﻣﺴﺎﯾﻞ و ﭘﯿﭽﯿﺪﮔﯽﻫﺎی ﺑﺨﺶ ﭘﯿﺶ اﯾﻦ ﺑﻮد ﮐﻪ ﻣﺸﺨﺺ ﺷﻮد ﺑﺮرﺳﯽ ارزش‪ ،‬ﻣﻨﺎﻓﻊ و ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه‬
‫را ﻧﻤﯽﺗﻮان ﺗﻤﺎﻣﺎ درون ﻣﺮزﻫﺎی ﭘﺮوژه اﻧﺠﺎم داد‪ .‬اﯾﻦ ﮐﺎر ﺑﺎﯾﺪ در ﺳﻄﺢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ اﻧﺠﺎم ﺷﻮد‪ .‬اﯾﻦ ﺳﻄﺢ‬
‫ﻣﺴﺌﻮل اﻧﺘﺨﺎب و اوﻟﯿﺖدﻫﯽ ﭘﺮوژهﻫﺎﺳﺖ و اﻋﻀﺎی آن ﻣﻌﻤﻮﻻ از ﻣﺪﯾﺮان ارﺷﺪ و ﺳﻬﺎمداران ﺳﺎزﻣﺎن ﻫﺴﺘﻨﺪ‪.‬‬

‫ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﭼﺮا در ﭘﻢﺑﺎک و ﺳﺎﯾﺮ ﻣﻨﺎﺑﻊ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﭼﻨﯿﻦ ﻣﺴﺎﯾﻠﯽ را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ؟ دﻟﯿﻠﺶ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎ‬
‫اﯾﻦﮐﻪ ارزﯾﺎﺑﯽﻫﺎ و ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی اﺻﻠﯽ ﺑﺎﯾﺪ در ﻻﯾﻪﻫﺎی ﺑﺎﻻﺗﺮ ﺳﺎزﻣﺎن اﻧﺠﺎم ﺷﻮﻧﺪ‪ ،‬واﺑﺴﺘﻪ ﺑﻪ اﻃﻼﻋﺎﺗﯽ ﻫﺴﺘﻨﺪ ﮐﻪ‬
‫از ﺳﻮی ﭘﺮوژهﻫﺎ ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮﻧﺪ و ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ ﺑﺘﻮاﻧﺪ ﺑﺎ اراﺋﻪ اﻃﻼﻋﺎت ﻣﻨﺎﺳﺐ ﺑﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﮐﻤﮏ ﮐﻨﺪ‪ .‬از‬
‫ﺳﻮی دﯾﮕﺮ‪ ،‬ﻫﻤﻪ اﻓﺮاد دﺳﺖاﻧﺪرﮐﺎر ﭘﺮوژه ﺑﺎﯾﺪ ﺑﺎ اﯾﻦ ﻣﻮارد آﺷﻨﺎ ﺑﺎﺷﻨﺪ و ﺧﻮد را ﺑﺎ آن ﻫﻤﺴﻮ ﮐﻨﻨﺪ‪.‬‬

‫‪ .5.1.2‬ﺑﺎ درک ﺑﺎﯾﺴﺘﻪ و ﻣﻮﺷﮑﺎﻓﺎﻧﻪ ﺑﻪ ﻫﻤﮑﻨﺶﻫﺎی ﺳﯿﺴﺘﻤﯽ واﮐﻨﺶ ﻧﺸﺎن دﻫﯿﺪ‬

‫ﻓﺮﺻﺘﯽ در اﺧﺘﯿﺎرﺗﺎن ﻗﺮار ﮔﺮﻓﺘﻪ اﺳﺖ ﮐﻪ ﯾﮑﯽ از دو ﺑﺎزی زﯾﺮ را اﻧﺘﺨﺎب ﮐﺮده‪ ،‬ﻓﻘﻂ ﯾﮏﺑﺎر ﺑﺎزی ﮐﻨﯿﺪ‪ .‬در ﻫﺮ دو ﺑﺎزی‪،‬‬
‫ﺧﻮدﺗﺎن ﺳﮑﻪای اﻧﺘﺨﺎب ﻣﯽﮐﻨﯿﺪ و آن را ﻣﯽاﻧﺪازﯾﺪ‪.‬‬

‫‪ .1‬اﮔﺮ ﺷﯿﺮ ﺑﯿﺎﯾﺪ‪ ،‬ﻣﻌﺎدل ده ﭘﯿﺘﺰا ﭘﻮل ﻣﯽﺑﺮﯾﺪ‪ .‬اﮔﺮ ﺧﻂ ﺑﯿﺎﯾﺪ ﭘﻮﻟﯽ رد و ﺑﺪل ﻧﻤﯽﺷﻮد‪.‬‬
‫‪ .2‬اﮔﺮ ﺷﯿﺮ ﺑﯿﺎﯾﺪ‪ ،‬ﻣﻌﺎدل ﺳﯽ ﭘﯿﺘﺰا ﭘﻮل ﻣﯽﺑﺮﯾﺪ‪ .‬اﮔﺮ ﺧﻂ ﺑﯿﺎﯾﺪ ﻣﻌﺎدل ده ﭘﯿﺘﺰا ﭘﻮل ﻣﯽﺑﺎزﯾﺪ‪.‬‬

‫ﮐﺪام ﺑﺎزی را اﻧﺘﺨﺎب ﺧﻮاﻫﯿﺪ ﮐﺮد؟‬

‫‪ .1.5.1.2‬ﺗﺮس از دﺳﺖ دادن‬

‫ﻣﺴﺌﻠﻪ ﭘﯿﺶ از دوره راﯾﮕﺎﻧﯽ ﮐﻪ درﺑﺎره ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ ﻣﻨﺘﺸﺮ ﮐﺮدهام آﻣﺎده اﺳﺖ‪ .‬در زﻣﺎن ﻧﻮﺷﺘﻦ اﯾﻦ ﮐﺘﺎب ﺣﺪودا‬
‫ﺳﻪ ﻫﺰار ﻧﻔﺮ اﯾﻦ دوره را ﮔﺬراﻧﺪهاﻧﺪ و از ﻣﯿﺎن اﯾﻦ اﻓﺮاد ‪ ٪۷۸‬ﺑﺎزی ﻧﺨﺴﺖ را اﻧﺘﺨﺎب ﮐﺮدهاﻧﺪ‪ .‬آﯾﺎ ﺑﻪ ﻧﻈﺮ ﺷﻤﺎ اﯾﻦ‬
‫ﺑﺎ ز ی ﺑ ﻬﺘ ﺮﯾ ﻦ ﮔ ﺰﯾﻨ ﻪ ا ﺳ ﺖ ؟‬

‫ﺑﺮای ﭘﺎﺳﺦ دادن ﺑﻪ ﭘﺮﺳﺶ ﺑﺎﯾﺪ اﻣﯿﺪ رﯾﺎﺿﯽ )‪ (expected value‬ﺑﺎزیﻫﺎ را ﻣﺤﺎﺳﺒﻪ ﮐﻨﯿﻢ‪:‬‬

‫‪1. 50% × 10¤ = 5¤‬‬

‫‪2. 50% × 30¤ + 50% × -10¤ = 10¤‬‬

‫ﻣﺎﻧﻨﺪ ‪ $‬و ‪ ¥‬و ‪ ،€‬ﻧﺸﺎن ‪ ¤‬ﻫﻢ ﺑﺮای ﻣﻘﺎدﯾﺮ ﻣﺎﻟﯿﺴﺖ‪ ،‬وﻟﯽ ﺑﺮﺧﻼف آنﻫﺎ اﺷﺎره ﺑﻪ ارز ﺧﺎﺻﯽ ﻧﻤﯽﮐﻨﺪ و در ﻧﻤﻮﻧﻪ ﻣﺎ‬
‫ﻣﻌﺎدل ﻗﯿﻤﺖ ﭘﯿﺘﺰا ﺑﻪ ﮐﺎر ﻣﯽرود‪.‬‬

‫— ‪— 22‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﻣﯿﺪ رﯾﺎﺿﯽ ﺑﺎزی دوم دو ﺑﺮاﺑﺮ ﺑﺎزی ﻧﺨﺴﺖ اﺳﺖ‪ ،‬ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﮐﻪ اﮔﺮ اﯾﻦ دو ﺑﺎزی را ﻫﺰاران ﺑﺎر اﻧﺠﺎم دﻫﯿﻢ‪ ،‬درآﻣﺪ‬
‫ﺑﺎزی دوم ﺑﻪ اﺣﺘﻤﺎل زﯾﺎد دو ﺑﺮاﺑﺮ ﺑﺎزی ﻧﺨﺴﺖ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬ﺑﻨﺎﺑﺮ اﯾﻦ اﮔﺮ ﻗﺮار ﺑﺎﺷﺪ ﺑﺎزی را ﻫﺰاران ﺑﺎر اﻧﺠﺎم دﻫﯿﻢ‪،‬‬
‫ﺑ ﯽ ﮔ ﻤ ﺎ ن ﺑ ﺎ ز ی د و م ﺑ ﻬ ﺘ ﺮ ﺧ ﻮ ا ﻫ ﺪ ﺑ ﻮ د‪.‬‬

‫ﺗﺎ اﯾﻨﺠﺎی اﺳﺘﺪﻻل ﺳﺎده اﺳﺖ‪ ،‬وﻟﯽ درﺑﺎره اﯾﻦ ﻣﺴﺌﻠﻪ ﮐﻪ ﻗﺮار اﺳﺖ ﺑﺎزی را ﻓﻘﻂ ﯾﮏﺑﺎر اﻧﺠﺎم دﻫﯿﻢ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮان‬
‫اﺳﺘﺪﻻل ﮐﺮد؟‬

‫اﯾﻦ ﺑﺎزی را ﯾﮏﺑﺎر اﻧﺠﺎم ﺧﻮاﻫﯿﻢ داد‪ ،‬وﻟﯽ در ﮐﺎر و زﻧﺪﮔﯽ ﺷﺨﺼﯽ ﻫﺰاران ﻫﺰار ﺑﺎزی اﯾﻨﭽﻨﯿﻨﯽ ﻣﯽﮐﻨﯿﻢ‪ .‬اﮔﺮ اﺳﺘﺮاﺗﮋی‬
‫ﻫﻤﯿﺸﮕﯽﻣﺎن اﯾﻦ ﺑﺎﺷﺪ ﮐﻪ ﮔﺰﯾﻨﻪﻫﺎی ﺑﺎ اﻣﯿﺪ رﯾﺎﺿﯽ ﺑﺎﻻﺗﺮ را اﻧﺘﺨﺎب ﮐﻨﯿﻢ‪ ،‬درﻣﺠﻤﻮع ﺑﺮﻧﺪه ﺧﻮاﻫﯿﻢ ﺑﻮد‪ .‬از اﯾﻦ رو‪،‬‬
‫ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ در اﯾﻦ ﺑﺎزی ﻫﻢ ﮔﺰﯾﻨﻪ دوم را اﻧﺘﺨﺎب ﮐﻨﯿﻢ‪.‬‬

‫آﻧﭽﻪ در ﺑﺎﻻ ﮔﻔﺘﻪ ﺷﺪ روﻧﺪی ﮐﻠﯿﺴﺖ‪ ،‬وﻟﯽ ﺑﺮای آن ﺗﺒﺼﺮهﻫﺎی ﮔﻮﻧﺎﮔﻮﻧﯽ ﻫﻢ ﺑﺴﺘﻪ ﺑﻪ ﺗﻮان رﯾﺴﮏ ﮐﺮدن )‪risk‬‬
‫‪ ( capacity‬ﻓﺮد وﺟﻮد دارد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﮐﻞ داراﯾﯿﺘﺎن ﻣﻌﺎدل ده ﻫﺰار ﭘﯿﺘﺰا ﺑﺎﺷﺪ‪ ،‬ﻧﺒﺎﯾﺪ ﮔﺰﯾﻨﻪای ﮐﻪ اﺣﺘﻤﺎل ﺑﺎﺧﺖ‬
‫ﻧﺰدﯾﮏ ﺑﻪ ده ﻫﺰار ﭘﯿﺘﺰا دارد را اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪ ،‬ﺣﺘﯽ اﮔﺮ اﻣﯿﺪ رﯾﺎﺿﯽ ﺑﺎﻻﺗﺮی داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬دﻟﯿﻠﺶ اﯾﻦ اﺳﺖ ﮐﻪ ﮐﺎرﺑﺮد‬
‫ﭘﻮل ﺑﺮای ﻓﺮد در آﺳﺘﺎﻧﻪﻫﺎ ﻣﻘﺪار ﺧﻄﯽ ﻧﺪارد‪.‬‬

‫‪ .2 . 5 . 1 . 2‬ﻓ ﺮ ﯾ ﺐ ﻫ ﺎ ی ذ ﻫ ﻨ ﯽ‬

‫ﺑﺎوﺟﻮد اﺳﺘﺪﻻلﻫﺎی ﺑﺨﺶ ﭘﯿﺶ‪ ،‬ﭼﻪﺑﺴﺎ ﻫﻨﻮز ﻫﻢ اﺣﺴﺎس ﺑﻬﺘﺮی درﺑﺎره ﺑﺎزی ﻧﺨﺴﺖ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻃﺒﯿﻌﯿﺴﺖ‬
‫و ﺗﺮس از دﺳﺖ دادن )‪ (loss aversion‬ﻧﺎم دارد‪ .‬ﺑﺎر اﺣﺴﺎﺳﯽ از دﺳﺖ دادن ﺑﯿﺸﺘﺮ از ﺑﻪ دﺳﺖ آوردن اﺳﺖ‪ .‬اﯾﻦ‬
‫ﻧﺴﺒﺖ در ﻓﺮﻫﻨﮓﻫﺎ و اﻓﺮاد ﻣﺨﺘﻠﻒ ﯾﮑﺴﺎن ﻧﯿﺴﺖ‪ ،‬وﻟﯽ اﯾﻦ ﻣﻘﺪار ﺑﺮای ﺑﺴﯿﺎری اﻓﺮاد ﺣﺪود دو و ﻧﯿﻢ اﺳﺖ‪ .‬در ﻧﻤﻮﻧﻪ‬
‫ﭘﯿﺸﯿﻦ‪ ،‬اﻣﯿﺪ رﯾﺎﺿﯽ ﮔﺰﯾﻨﻪ دوم دو ﺑﺮاﺑﺮ ﮔﺰﯾﻨﻪ ﻧﺨﺴﺖ ﺑﻮد ﮐﻪ ﮐﻤﺘﺮ از آﺳﺘﺎﻧﻪ دو و ﻧﯿﻢ ﺑﺮاﺑﺮ اﺳﺖ و از اﯾﻦ رو‪،‬‬
‫ﺑﺴﯿﺎری از اﻓﺮاد ﮔﺰﯾﻨﻪ ﻧﺨﺴﺖ را ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ‪.‬‬

‫ﺗﺮس از دﺳﺖ دادن ﮔﺮاﯾﺸﯽ ﻃﺒﯿﻌﯿﺴﺖ ﮐﻪ در ﻫﻤﻪ ﻣﺎ وﺟﻮد دارد‪ .‬اﯾﻦ ﮔﺮاﯾﺶ ﺑﻪ ﺷﮑﻞ ﺗﮑﺎﻣﻠﯽ در اﺟﺪادﻣﺎن ﮐﻪ در‬
‫ﺟﻨﮕﻞ و ﻏﺎر زﻧﺪﮔﯽ ﻣﯽﮐﺮدﻧﺪ و ﺟﺎﻧﺸﺎن داﯾﻤﺎ درﺧﻄﺮ ﺑﻮد ﺷﮑﻞ ﮔﺮﻓﺘﻪ اﺳﺖ و در دﻧﯿﺎی اﻣﺮوزی ﮐﺎرﺑﺮد ﮐﻤﺘﺮی دارد‪.‬‬
‫اﯾﻦ ﮔﺮاﯾﺶ ﯾﮑﯽ از ﻓﺮﯾﺐﻫﺎی ذﻫﻨﯽ )‪ (cognitive bias‬اﺳﺖ‪ .‬ﻣﻮارد زﯾﺮ ﻧﻤﻮﻧﻪﻫﺎی دﯾﮕﺮی از ﻓﺮﯾﺐﻫﺎی ذﻫﻨﯽاﻧﺪ‪:‬‬

‫ﮔﺎﻫﯽ ﻫﻨﮕﺎﻣﯽ ﮐﻪ اﯾﺪهای دارﯾﻢ و درﺳﺘﯽ آن را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﯿﻢ‪ ،‬ﻧﺎﺧﻮدآﮔﺎه ﺗﻨﻬﺎ ﺷﻮاﻫﺪ ﺗﺎﯾﯿﺪ ﮐﻨﻨﺪه را ﻣﯽﺑﯿﻨﯿﻢ‬
‫)‪.(confirmation bias‬‬
‫ﮔﺎﻫﯽ ﮐﺎرﻫﺎﯾﯽ ﮐﻪ آﻏﺎز ﮐﺮدهاﯾﻢ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺧﻮد را از دﺳﺖ ﻣﯽدﻫﻨﺪ‪ ،‬وﻟﯽ ﺑﻪ دﻟﯿﻞ ﻫﺰﯾﻨﻪ ﯾﺎ ﮐﻮﺷﺸﯽ ﮐﻪ‬
‫ﭘﯿﺸﺘﺮ ﺑﺮاﯾﺸﺎن ﮐﺮدهاﯾﻢ اداﻣﻪﺷﺎن ﻣﯽدﻫﯿﻢ ﺗﺎ ﺑﻪ ﭘﺎﯾﺎن ﺑﺮﺳﻨﺪ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ اﯾﻦ ﮐﺎر ﻓﻘﻂ ﺑﺎﻋﺚ اﺗﻼف ﻫﺰﯾﻨﻪ و ﺗﻮان‬
‫ﺑﯿﺸﺘﺮ ﻣﯽﺷﻮد ) ‪.(sunk cost effect‬‬
‫ﮔﺎﻫﯽ اﻓﺮاد و ﺷﺮاﯾﻂ را ﻓﻘﻂ ﺑﺮ ﭘﺎﯾﻪ ﮐﻠﯿﺸﻪﻫﺎﯾﯽ ﮐﻪ درﺑﺎرهﺷﺎن وﺟﻮد دارد ﻗﻀﺎوت ﻣﯽﮐﻨﯿﻢ )‪.(stereotyping‬‬

‫اﮔﺮ ﻋﻼﻗﻪﻣﻨﺪ ﺑﺎﺷﯿﺪ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ ﻓﻬﺮﺳﺖ ﻓﺮﯾﺐﻫﺎی ذﻫﻨﯽ در وﯾﮑﯽﭘﺪﯾﺎ ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ ﺗﺎ اﯾﻦ ﻣﻮارد ﺑﯿﺸﺘﺮ آﺷﻨﺎ ﺷﻮﯾﺪ‪.‬‬
‫در اﯾﻦ ﺑﺎره ﮐﺘﺎبﻫﺎی ارزﺷﻤﻨﺪی ﻧﯿﺰ وﺟﻮد دارد‪.‬‬

‫— ‪— 23‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .3 . 5 . 1 . 2‬ا ﻧ ﺪ ﯾ ﺸ ﻪ ا ﻧ ﺘ ﻘ ﺎ د ی‬

‫اﻧﺪﯾﺸﻪ اﻧﺘﻘﺎدی ﺣﻮزهای درﺑﺎره ﺗﺼﻤﯿﻢﮔﯿﺮی و اﯾﺪهﭘﺮدازی ﺳﻨﺠﯿﺪه و ﺑﻪدور از ﻓﺮﯾﺐﻫﺎی ذﻫﻨﯿﺴﺖ‪ .‬اﮔﺮ ﻗﺮار ﺑﺎﺷﺪ اﯾﻦ‬
‫ﮐﺘﺎب ﻓﻘﻂ ﯾﮏ اﺛﺮ ﺑﺮ ﺷﻤﺎ داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬اﻣﯿﺪوارم اﯾﻦ اﺛﺮ ﻋﻼﻗﻪﻣﻨﺪ ﮐﺮدﻧﺘﺎن ﺑﻪ ﻣﻄﺎﻟﻌﻪ درﺑﺎره اﻧﺪﯾﺸﻪ اﻧﺘﻘﺎدی ﺑﺎﺷﺪ!‬
‫اﯾﻦ ﻣﻬﺎرت ﮐﻤﮏﻫﺎی ﻓﺮاواﻧﯽ ﺑﻪ ﭘﺮوژهﻫﺎﯾﺘﺎن ﺧﻮاﻫﺪ ﮐﺮد و اﻓﺰون ﺑﺮ آن در زﻧﺪﮔﯽ ﺷﺨﺼﯽﺗﺎن ﻫﻢ ﮐﺎرآﻣﺪ ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬

‫اﻧﺪﯾﺸﻪ اﻧﺘﻘﺎدی ﯾﮑﯽ از ﺟﻨﺒﻪﻫﺎی اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ اﺳﺖ؛ دﺳﺖﮐﻢ‪ ،‬ﭘﻢﺑﺎک آن را اﯾﻦﮔﻮﻧﻪ ﻣﺪل ﻣﯽﮐﻨﺪ‪.‬‬

‫‪ .4 . 5 . 1 . 2‬ا ﻧ ﺪ ﯾ ﺸ ﻪ ﺳ ﯿ ﺴ ﺘ ﻤ ﯽ‬

‫ﻋﻨﻮان ﻧﺨﺴﺘﯿﻦ اﯾﻦ اﺻﻞ اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ ﺑﻮد‪ ،‬وﻟﯽ ﺑﺮای ﯾﮑﺴﺎنﺳﺎزی ﻋﻨﻮانﻫﺎ و ﺗﺒﺪﯾﻞ آنﻫﺎ از ﺣﺎﻟﺖ اﺳﻤﯽ ﺑﻪ‬
‫اﻣﺮی‪ ،‬ﺑﻪ ﺟﻤﻠﻪ ﺑﻠﻨﺪی ﮐﻪ ﻫﻢاﮐﻨﻮن وﺟﻮد دارد ﺗﺒﺪﯾﻞ ﺷﺪ‪ .‬از آن ﮔﺬﺷﺘﻪ‪ ،‬ﻣﻮﺿﻮع اﯾﻦ اﺻﻞ ﻫﻤﭽﻨﺎن اﻧﺪﯾﺸﻪ‬
‫ﺳ ﯿ ﺴ ﺘ ﻤ ﯿ ﺴ ﺖ‪.‬‬

‫اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ درﺑﺎره اﻧﺪﯾﺸﻪورزی ﻫﻤﻪﺟﺎﻧﺒﻪ درﺑﺎره ﭘﯿﭽﯿﺪﮔﯽﻫﺎﺳﺖ‪ .‬ﺑﺮرﺳﯽ ﻫﻤﻪﺟﺎﻧﺒﻪ ﻣﻔﻬﻮم ﭘﯿﭽﯿﺪه »ارزش«‬
‫د ر ﺑ ﺨ ﺶ ﻫ ﺎ ی ﭘ ﯿ ﺸ ﯿ ﻦ ﻧ ﻤ ﻮ ﻧ ﻪ ا ی ا ز ا ﻧ ﺪ ﯾ ﺸ ﻪ ﺳ ﯿ ﺴ ﺘ ﻤ ﯿ ﺴ ﺖ‪.‬‬

‫اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ ﺣﻮزهای ﮔﺴﺘﺮده و ﮐﻤﺎﺑﯿﺶ ﭘﯿﭽﯿﺪه اﺳﺖ‪ .‬ﻣﻬﻢﺗﺮﯾﻦ ﻣﺴﺎﯾﻞ در اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬
‫از اﯾﻦ ﻗﺮارﻧﺪ‪:‬‬

‫ﻣﺮاﻗﺐ ﻓﺮﯾﺐﻫﺎی ذﻫﻨﯽ ﺑﻮده‪ ،‬اﻧﺪﯾﺸﻤﻨﺪی اﻧﺘﻘﺎدی ﺑﺎﺷﯿﺪ‪.‬‬

‫ﻣﺴﺎﯾﻞ را ﻫﻤﻪﺟﺎﻧﺒﻪ ﺑﺴﻨﺠﯿﺪ‪.‬‬

‫‪ .6.1.2‬رﻫﺒﺮی را دﺳﺖﮐﻢ ﻧﮕﯿﺮﯾﺪ‬

‫ﺧﺎﻧﻢ ﻣﯿﺎنﺳﺎﻟﯽ در ﯾﮑﯽ از ﺷﺮﮐﺖﻫﺎﯾﯽ ﮐﻪ ﻣﯽﺷﻨﺎﺧﺘﻢ ﮐﺎر ﻣﯽﮐﺮد؛ ﻓﺮدی ﺑﺎﺷﺨﺼﯿﺖ‪ ،‬ﺑﺎ رﻓﺘﺎری ﻣﺎدراﻧﻪ‪ .‬ﺳﻤﺖ‬
‫رﺳﻤﯽاش »ﻣﻨﺸﯽ« ﺑﻮد‪ ،‬وﻟﯽ در ﻋﻤﻞ ﺑﺴﯿﺎری از ﮐﺎرﻫﺎی ﺷﺮﮐﺖ را ﺗﺴﻬﯿﻞ ﻣﯽﮐﺮد‪.‬‬

‫ﭘﺲ از ﺳﺎلﻫﺎ ﮐﺎر در ﺷﺮﮐﺖ‪ ،‬ﺑﻪﯾﮏﺑﺎره آن را ﺗﺮک ﮐﺮد‪ .‬ﻇﺎﻫﺮا ﻣﺸﮑﻞ اﯾﻦ ﺑﻮد ﮐﻪ ﺑﺎوﺟﻮد ﮐﺎر ﺧﻮﺑﯽ ﮐﻪ اﻧﺠﺎم ﻣﯽداد‬
‫ﻣﺪتﻫﺎ ﺑﻮد ﮐﻪ اﻓﺰاﯾﺶ ﺣﻘﻮق ﻧﺪاﺷﺖ و ﺷﺮﮐﺖﻫﺎی دﯾﮕﺮی آﻣﺎده ﺑﻮدﻧﺪ ﺗﺎ دو ﺑﺮاﺑﺮ ﺑﻪ او ﺣﻘﻮق ﭘﺮداﺧﺖ ﮐﻨﻨﺪ‪.‬‬
‫ﻣﺪﯾﺮﯾﺖ ﺷﺮﮐﺖ ﺣﺴﺎﺳﯿﺖ وﯾﮋهای در اﯾﻦ ﺑﺎره ﺑﻪ ﺧﺮج ﻧﺪاد و او را از دﺳﺖ داد؛ ﻫﺮ ﭼﻪ ﺑﺎﺷﺪ‪ ،‬از دﯾﺪﺷﺎن ﻓﻘﻂ ﯾﮏ‬
‫» ﻣ ﻨ ﺸ ﯽ « ﺑ ﻮ د‪.‬‬

‫ﮐﻤﯽ ﭘﺲ از رﻓﺘﻨﺶ ﺑﻪﺗﺪرﯾﺞ ﮐﺎرﻫﺎی ﮔﻮﻧﺎﮔﻮﻧﯽ ﮐﻪ ﭘﯿﺶﺗﺮ ﺑﻪ ﺧﻮﺑﯽ اﻧﺠﺎم ﻣﯽﺷﺪﻧﺪ ﮔﺮه ﺧﻮردﻧﺪ‪ ،‬ازﺟﻤﻠﻪ ﮐﺎرﻫﺎﯾﯽ ﮐﻪ‬
‫در ﻇﺎﻫﺮا ﻫﯿﭻ ارﺗﺒﺎﻃﯽ ﺑﻪ او ﻧﺪاﺷﺖ‪ .‬ﮐﻢﮐﻢ ﺑﻪ ﺟﺎی آن ﯾﮏ ﻧﻔﺮ ﭘﻨﺞ ﻧﻔﺮ اﺳﺘﺨﺪام ﮐﺮدﻧﺪ وﻟﯽ آن ﭘﻨﺞ ﻧﻔﺮ ﻫﻤﺮاه ﻫﻢ‬
‫ﻧﻤﯽﺗﻮاﻧﺴﺘﻨﺪ ﺟﺎی ﺧﺎﻟﯽ او را ﭘﺮ ﮐﻨﻨﺪ‪.‬‬

‫آن ﺧﺎﻧﻢ ﻫﻢ در ﮔﺮهﮔﺸﺎﯾﯽ ﺧﺒﺮه ﺑﻮد و ﻫﻢ ﺑﺎ ﻋﻼﻗﻪ دروﻧﯽ در ﻫﺮ زﻣﯿﻨﻪای ﮐﻪ ﻣﯽﺗﻮاﻧﺴﺖ ﺑﻪ ﻫﻤﻪ ﮐﻤﮏ ﻣﯽﮐﺮد؛ ﺧﯿﻠﯽ‬
‫ﻓﺮاﺗﺮ از آﻧﭽﻪ رﺳﻤﺎ ﻣﺴﺌﻮﻟﯿﺘﺶ ﺑﻮد‪ .‬ﭼﻨﯿﻦ رﻓﺘﺎری را رﻫﺒﺮی ﻣﯽﻧﺎﻣﯿﻢ‪.‬‬

‫— ‪— 24‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .1.6.1.2‬رﻫﺒﺮان ﻧﺎﻣﺮﺋﯽ‬

‫ﺑﺴﯿﺎری رﻫﺒﺮی را از وﯾﮋﮔﯽﻫﺎی ﻣﺪﯾﺮان ﻣﯽداﻧﻨﺪ‪ ،‬وﻟﯽ در ادﺑﯿﺎت ﻣﺪرن ﺑﻪ ﻫﺮﮐﺴﯽ ﮐﻪ اﻓﺮاد را ﺑﻪ ﺳﻤﺖ ﻧﺘﺎﯾﺞ ﻣﻄﻠﻮب‬
‫ﻫﺪاﯾﺖ ﮐﻨﺪ رﻫﺒﺮ ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪.‬‬

‫اﯾﻦ ﺗﻌﺮﯾﻒ ﻧﻮﯾﻦ از اﯾﻦ رو اﻫﻤﯿﺖ دارد ﮐﻪ در ﻫﺮ ﮔﺮوﻫﯽ ﻋﺪهای ﻋﻼﻗﻪﻣﻨﺪ ﺑﻪ رﻫﺒﺮی وﺟﻮد دارد ﮐﻪ ﮔﺬﺷﺘﻪ از ﺳﻤﺖ و‬
‫ﻣﺴﺌﻮﻟﯿﺖ ﺧﻮد ﺑﻪ ﻫﻤﮕﯽ ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ زﯾﺮا اﯾﻦ رﻓﺘﺎر ﺑﺮاﯾﺸﺎن ﺧﻮﺷﺎﯾﻨﺪ اﺳﺖ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ اﯾﻦ اﻓﺮاد در ﺑﺴﯿﺎری از‬
‫ﺳﺎزﻣﺎنﻫﺎ ﻧﺎدﯾﺪه ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮﻧﺪ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ اﮔﺮ از آنﻫﺎ ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﯿﻢ و ﻗﺪرت ﺑﯿﺸﺘﺮی در اﺧﺘﯿﺎرﺷﺎن ﺑﮕﺬارﯾﻢ‬
‫ﻣﯽﺗﻮاﻧﻨﺪ ﺑﯿﺶ از ﭘﯿﺶ ﺑﻪ ﺳﺎزﻣﺎن ﯾﺎ ﭘﺮوژه ﮐﻤﮏ ﮐﻨﻨﺪ‪ .‬دﺳﺖﮐﻢ‪ ،‬اﮔﺮ از آنﻫﺎ ﭘﺸﺘﯿﺒﺎﻧﯽ ﻧﻤﯽﮐﻨﯿﺪ‪ ،‬ﭼﻨﺎن زﯾﺮ ﻓﺸﺎرﺷﺎن‬
‫ﻧﮕﺬارﯾﺪ ﮐﻪ ﻣﺎﻧﻨﺪ ﺧﺎﻧﻤﯽ ﮐﻪ در ﻧﻤﻮﻧﻪ ﭘﯿﺸﯿﻦ ﮔﻔﺘﻪ ﺷﺪ ﺑﮕﺬارﻧﺪ و ﺑﺮوﻧﺪ‪.‬‬

‫‪ .2.6.1.2‬ﻣﺪﯾﺮ ﭘﺮوژه در ﻧﻘﺶ رﻫﺒﺮ‬

‫ﭘﺸﺘﯿﺒﺎﻧﯽ از رﻫﺒﺮان ﻧﺎﻣﺮﺋﯽ ﮐﻪ در ﺑﺨﺶ ﭘﯿﺶ ﻣﻄﺮح ﺷﺪ ﻣﺒﺤﺚ ﻣﻬﻤﯽ در ﺣﻮزه رﻫﺒﺮﯾﺴﺖ‪ ،‬وﻟﯽ از آن ﮔﺬﺷﺘﻪ‪ ،‬ﺑﺎﯾﺪ ﺑﺮ‬
‫رﺷﺪ ﺗﻮاﻧﺎﯾﯽﻫﺎی رﻫﺒﺮی ﺧﻮدﺗﺎن ﻧﯿﺰ ﺗﻤﺮﮐﺰ ﮐﻨﯿﺪ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺑﻪﻋﻨﻮان ﯾﮏ رﻫﺒﺮ‪ ،‬ﺑﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ در اﻓﺮاد اﻧﮕﯿﺰه اﯾﺠﺎد ﮐﻨﯿﺪ‪ .‬ﻓﺮض ﮐﻨﯿﺪ ﯾﮑﯽ از اﻋﻀﺎی ﺗﯿﻢ ﮐﺎر درﺧﺸﺎﻧﯽ‬
‫در ﭘﺮوژه اﻧﺠﺎم داده اﺳﺖ و ﻣﯽﺧﻮاﻫﯿﺪ از او ﻗﺪرداﻧﯽ ﮐﻨﯿﺪ‪ .‬ﭼﮕﻮﻧﻪ اﯾﻦ ﮐﺎر را ﺧﻮاﻫﯿﺪ ﮐﺮد؟ ﺑﺎ ﭘﺮداﺧﺖ ﭘﺎداش ﻣﺎﻟﯽ؟‬

‫ﭘﺎﺳﺦ ﺑﺴﺘﮕﯽ ﺑﻪ ﻣﺴﺎﯾﻞ ﻓﺮاواﻧﯽ دارد‪ .‬ﭘﺎداش ﻣﺎﻟﯽ ﻫﻨﮕﺎﻣﯽ ﮐﺎرآﻣﺪ اﺳﺖ ﮐﻪ ﻣﻘﺪارش ﻧﺴﺒﺖ ﺑﻪ ﻧﯿﺎز ﻣﺎﻟﯽ ﻓﺮد ﻣﻨﺎﺳﺐ‬
‫ﺑﺎﺷﺪ‪ ،‬وﮔﺮﻧﻪ اﺛﺮ ﻣﻌﮑﻮس ﺧﻮاﻫﺪ داﺷﺖ‪ ،‬زﯾﺮا ﮐﻢ ﺑﻮدن ﭘﺎداش ﺑﻪ ﻣﻌﻨﯽ دﺳﺖﮐﻢ ﮔﺮﻓﺘﻦ ﮐﺎر ﻓﺮد ﺑﻪ ﺷﻤﺎر ﺧﻮاﻫﺪ رﻓﺖ‪.‬‬
‫ﻓﺮض ﮐﻨﯿﺪ ﺑﻮدﺟﻪ ﺑﺴﯿﺎر ﻣﺤﺪودی دارﯾﺪ و ﻓﻘﻂ ﻣﯽﺗﻮاﻧﯿﺪ ﻣﻌﺎدل ﭼﻬﺎر ﭘﯿﺘﺰا ﺑﺮای ﻗﺪرداﻧﯽ از آن ﻓﺮد ﻫﺰﯾﻨﻪ ﮐﻨﯿﺪ‪.‬‬
‫ﭘﺮداﺧﺖ ﭼﻨﯿﻦ ﭘﺎداﺷﯽ ﺷﺎﯾﺴﺘﻪ ﻧﯿﺴﺖ‪ ،‬وﻟﯽ ﺑﺎ ﻫﻤﺎن ﺑﻮدﺟﻪ ﻣﯽﺗﻮاﻧﯿﺪ ﺧﻮدﮐﺎری ﺑﺮازﻧﺪه ﺳﻔﺎرش دﻫﯿﺪ ﮐﻪ ﻧﺎم آن ﻓﺮد‬
‫روﯾﺶ ﺣﮏ ﺷﺪه ﺑﺎﺷﺪ‪ ،‬آن را ﻫﺪﯾﻪ دﻫﯿﺪ و ﺑﺎ ﭼﻨﺪ ﺟﻤﻠﻪ زﯾﺒﺎ ﻗﺪرداﻧﯽ ﺧﻮد را ﻧﺸﺎن دﻫﯿﺪ‪.‬‬

‫ﺳﻮﺗﻔﺎﻫﻢﻫﺎی ﻓﺮاواﻧﯽ درﺑﺎره ﻣﻔﻬﻮم رﻫﺒﺮی وﺟﻮد دارد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬داﺷﺘﻦ ﮐﺎرﯾﺰﻣﺎ ﺑﺮای رﻫﺒﺮان ﺳﻮدﻣﻨﺪ اﺳﺖ‪ ،‬وﻟﯽ‬
‫ﮐﺎرﯾﺰﻣﺎ ﻣﺤﺪود ﺑﻪ داﺷﺘﻦ ﺷﺨﺼﯿﺘﯽ ﺳﺮﺳﺨﺖ‪ ،‬ﭘﺮاﺑﻬﺖ و ﮔﺎﻫﯽ ﺑﺪاﺧﻼق ﻧﯿﺴﺖ‪ .‬ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻔﯽ از ﮐﺎرﯾﺰﻣﺎ وﺟﻮد‬
‫دارد و ﺑﺮﺧﯽ از آنﻫﺎ واﺑﺴﺘﻪ ﺑﻪ داﻧﺶ‪ ،‬ﻣﻬﺮﺑﺎﻧﯽ‪ ،‬دﻟﺴﻮزی و ﻫﻤﺎﻫﻨﻨﺪ آنﻫﺎ ﻫﺴﺘﻨﺪ‪ .‬ﺑﻬﺘﺮ اﺳﺖ ﺑﻪ ﺟﺎی اﻟﮕﻮﺑﺮداری از‬
‫ﺷﺨﺼﯿﺖﻫﺎی ﮐﺎرﯾﺰﻣﺎﺗﯿﮏ ﻓﯿﻠﻢﻫﺎ‪ ،‬ﻧﻮع ﮐﺎرﯾﺰﻣﺎی ﻣﻨﺎﺳﺐ ﺷﺨﺼﯿﺖ ﺧﻮد را ﺑﯿﺎﺑﯿﺪ و روی آن ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﻨﯿﺪ‪.‬‬

‫‪ .3.6.1.2‬ﻣﻬﺎرتﻫﺎی رﻫﺒﺮی‬

‫ﻣﺪﯾﺮ ﭘﺮوژه ﻧﯿﺎز ﺑﻪ ﻣﻬﺎرتﻫﺎی اﻧﺴﺎﻧﯽ ﮔﻮﻧﺎﮔﻮﻧﯽ دارد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،APMbok ،‬ﮐﻪ راﻫﻨﻤﺎﯾﯽ ﻫﻤﺎﻧﻨﺪ ﭘﻢﺑﺎک اﺳﺖ‪،‬‬
‫ﭼﻨﯿﻦ دﺳﺘﻪﺑﻨﺪیای اراﺋﻪ ﻣﯽﮐﻨﺪ‪:‬‬

‫ﻣﻬﺎرتﻫﺎی ارﺗﺒﺎﻃﯽ‬
‫ﻣﻬﺎرتﻫﺎی رﻓﻊ اﺧﺘﻼف‬
‫ﻣﻬﺎرتﻫﺎی ﺗﻔﻮﯾﺾ اﺧﺘﯿﺎر‬

‫— ‪— 25‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﻬﺎرتﻫﺎی ﺗﺎﺛﯿﺮﮔﺬاری‬
‫ﻣﻬﺎرتﻫﺎی رﻫﺒﺮی‬
‫ﻣﻬﺎرتﻫﺎی ﻣﺬاﮐﺮه‬
‫ﻣﻬﺎرتﻫﺎی ﮐﺎر ﺗﯿﻤﯽ‬

‫دﺳﺘﻪﺑﻨﺪی ﻣﻬﺎرتﻫﺎی اﻧﺴﺎﻧﯽ ﮐﺎر ﺳﺎدهای ﻧﯿﺴﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪» ،‬ﺗﺎﺛﯿﺮﮔﺬاری« در دﺳﺘﻪﺑﻨﺪی ﺑﺎﻻ از »رﻫﺒﺮی«‬
‫ﺟﺪاﺳﺖ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ ﺑﺮﺧﯽ آن را زﯾﺮﻣﺠﻤﻮﻋﻪای از ﻣﻬﺎرتﻫﺎی رﻫﺒﺮی ﻣﯽداﻧﻨﺪ‪ .‬ﮔﺬﺷﺘﻪ از اﯾﻦﮐﻪ ﭼﮕﻮﻧﻪ ﻣﻬﺎرتﻫﺎی‬
‫اﻧﺴﺎﻧﯽ را دﺳﺘﻪﺑﻨﺪی ﮐﻨﯿﺪ‪ ،‬ﻣﻬﺎرت داﺷﺘﻦ در ﻫﻤﻪ آنﻫﺎ ﺑﺮای رﻫﺒﺮان ﻻزم اﺳﺖ‪.‬‬

‫ﺑﺮای ﻫﻤﻪ اﯾﻦ ﻣﻮارد ﮐﺘﺎبﻫﺎی ﻓﺮاواﻧﯽ وﺟﻮد دارد‪ .‬اﮔﺮﭼﻪ ﻣﺘﺎﺳﻔﺎﻧﻪ اﯾﻦ داﻣﻨﻪ ﻋﯿﻨﯽ ﻧﯿﺴﺖ و از اﯾﻦ رو ﻣﺘﺨﺼﺺﻫﺎی‬
‫دروﻏﯿﻦ ﻓﺮاوان دارد و ﺑﺎﯾﺪ در اﻧﺘﺨﺎب ﻣﻨﺎﺑﻊ دﻗﺖ ﮐﻨﯿﺪ‪.‬‬

‫‪ .7.1.2‬ﺳﯿﺴﺘﻢ را ﺑﺮای ﻣﺤﯿﻂ ﭘﺮوژه اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﻨﯿﺪ‬

‫ﺷﺮﮐﺘﯽ ﺑﺎ اﻧﺪازه ﻣﺘﻮﺳﻂ ﻣﯽﺷﻨﺎﺧﺘﻢ ﮐﻪ زﻣﺎﻧﯽ ﻣﺪﯾﺮ ﻣﻮﻓﻘﯽ را از ﺷﺮﮐﺘﯽ ﻧﺎﻣﺪار و ﺑﺰرگ ﮐﻪ در زﻣﯿﻨﻪ ﻣﺸﺎﺑﻬﯽ ﮐﺎر‬
‫ﻣﯽﮐﺮد ﺟﺬب ﮐﺮد‪ .‬آن ﻓﺮد ﺑﯽدرﻧﮓ آﻏﺎز ﺑﻪ ﭘﯿﺎدهﺳﺎزی ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺘﯽای ﮐﺮد ﮐﻪ در ﺷﺮﮐﺖ ﭘﯿﺸﯿﻦ ﺷﻨﺎﺧﺘﻪ ﺑﻮد و ﺑﻪ‬
‫ﻫﻤﺎن ﺳﺮﻋﺘﯽ ﮐﻪ ﮐﺎر را آﻏﺎز ﮐﺮد ﺷﮑﺴﺖ ﺧﻮرد‪.‬‬

‫ﮐﺎری ﮐﻪ ﮐﺮده ﺑﻮد دو ﻣﺸﮑﻞ ﮐﻼن داﺷﺖ‪:‬‬

‫‪ .1‬او ﻣﯽﮐﻮﺷﯿﺪ ﺳﯿﺴﺘﻤﯽ ﮐﻪ ﺑﺮای ﺷﺮﮐﺘﯽ ﺑﺎ اﻧﺪازه‪ ،‬ﻓﺮﻫﻨﮓ و ﭘﺲزﻣﯿﻨﻪ ﻣﺘﻔﺎوت ﺳﺎﺧﺘﻪ ﺷﺪه ﺑﻮد را ﻋﯿﻨﺎ ﺟﺎی‬
‫د ﯾ ﮕ ﺮ ی ﭘ ﯿ ﺎ د ه ﺳ ﺎ ز ی ﮐ ﻨ ﺪ‪.‬‬
‫‪ .2‬ﭼﻪﺑﺴﺎ آن ﺳﯿﺴﺘﻢ ﺑﻪﺗﺪرﯾﺞ و در روﻧﺪی ارﮔﺎﻧﯿﮏ در ﺷﺮﮐﺖ ﭘﯿﺸﯿﻦ ﺷﮑﻞ ﮔﺮﻓﺘﻪ ﺑﻮد‪ ،‬وﻟﯽ او ﺑﺮ آن ﺑﻮد ﮐﻪ آن را‬
‫ﯾﮏﺑﺎره در ﺷﺮﮐﺖ دوم ﭘﯿﺎدهﺳﺎزی ﮐﻨﺪ‪.‬‬

‫ﻣﺸﮑﻞ دوم ﺑﻪ ﺷﯿﻮه ﭘﯿﺎدهﺳﺎزی ﺗﻐﯿﯿﺮ ﺳﺎزﻣﺎﻧﯽ ﺑﺮﻣﯽﮔﺮدد ﮐﻪ ﻣﻮﺿﻮﻋﯽ در ﻣﺪﯾﺮﯾﺖ ﻃﺮح اﺳﺖ و ارﺗﺒﺎط ﻣﺴﺘﻘﯿﻤﯽ ﺑﻪ‬
‫ﻣﻮﺿﻮع ﻓﻌﻠﯽ ﻣﺎ ﻧﺪارد‪ .‬ﻣﺸﮑﻞ ﻧﺨﺴﺖ‪ ،‬ﻧﺒﻮد اﺧﺘﺼﺎﺻﯽﺳﺎزی ) ‪ (tailoring‬اﺳﺖ ﮐﻪ ﻣﻮﺿﻮع اﯾﻦ اﺻﻞ اﺳﺖ‪.‬‬

‫‪ .1.7.1.2‬وﻗﺘﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﭘﺮﻫﺰﯾﻨﻪ ﻣﯽﺷﻮد‬

‫آﯾﺎ ﺗﺎ ﮐﻨﻮن ﭼﯿﺰی ﻫﻤﺎﻧﻨﺪ »ﻧﻪ‪ ،‬ﻣﺎ از ﭘﺮﯾﻨﺲ‪ ۲‬اﺳﺘﻔﺎده ﻧﻤﯽﮐﻨﯿﻢ ﭼﻮن ﺑﺮای ﺷﺮﮐﺖ ﻣﺎ زﯾﺎد از ﺣﺪ ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ«‬
‫ﺷﻨﯿ ﺪ هاﯾ ﺪ ؟‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬و ﻫﻤﻪ ﻣﺘﺪوﻟﻮژیﻫﺎی دﯾﮕﺮ ﺳﺎﺧﺘﻪ ﺷﺪهاﻧﺪ ﺗﺎ ﺑﻪ ﺷﮑﻞﻫﺎی ﮔﻮﻧﺎﮔﻮن‪ ،‬از ﺟﻤﻠﻪ ﮐﺎﻫﺶ ﻫﺰﯾﻨﻪ‪ ،‬ﺑﻪ ﺷﺮﮐﺖﻫﺎ‬
‫ﮐﻤﮏ ﮐﻨﻨﺪ‪ .‬اﮔﺮ ﺳﯿﺴﺘﻤﯽ اﯾﻦﭼﻨﯿﻨﯽ ﭘﯿﺎدهﺳﺎزی ﮐﻨﯿﺪ و ﺑﻪ ﻧﻈﺮﺗﺎن ﺳﺮﺑﺎرش ﺑﯿﺸﺘﺮ از ﻧﺘﯿﺠﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ‬
‫ﮐﻪ آن را ﺑﻪ ﺧﻮﺑﯽ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﮑﺮدهاﯾﺪ‪.‬‬

‫ا ﺧﺘ ﺼﺎ ﺻ ﯽ ﺳﺎ ز ی ﭼﯿ ﺴ ﺖ ؟‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﭘﺮﯾﻨﺲ‪ ۲‬ﮔﺰارﺷﯽ ﺑﻪ ﻧﺎم ‪ checkpoint report‬دارد ﮐﻪ در دورهﻫﺎی زﻣﺎﻧﯽ از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷﺪه از ﺳﻮی‬

‫— ‪— 26‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺪﯾﺮان ﺗﯿﻢﻫﺎ ﺑﺮای ﻣﺪﯾﺮ ﭘﺮوژه ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮد‪ .‬ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﺮای آن و دﯾﮕﺮ ﻣﻮارد ﺑﻪﺟﺎی ﻋﺒﺎرت »ﺳﻨﺪ« از ﻋﺒﺎرت‬
‫ﻣﺤﺼﻮل ﻣﺪﯾﺮﯾﺘﯽ اﺳﺘﻔﺎده ﻣﯽﮐﻨﺪ‪ ،‬زﯾﺮا اﻟﺰاﻣﯽ ﻧﯿﺴﺖ ﮐﻪ آنﻫﺎ را در ﻗﺎﻟﺐ ﺳﻨﺪ ﺑﺴﺎزﯾﺪ‪ .‬اﮔﺮ ﭘﺮوژه ﭘﯿﭽﯿﺪه و ﺑﺰرگ‬
‫ﺑﺎﺷﺪ‪ ،‬ﺷﺎﯾﺪ آن را ﻣﺴﺘﻨﺪ ﮐﻨﯿﺪ‪ ،‬وﻟﯽ در ﭘﺮوژهﻫﺎی ﮐﻮﭼﮏﺗﺮ ﺣﺘﯽ ﯾﮏ ﺗﻤﺎس ﺗﻠﻔﻨﯽ ﻣﯿﺎن ﻣﺪﯾﺮ ﺗﯿﻢ و ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺮای‬
‫اﯾﻦ ﻣﻨﻈﻮر ﮐﻔﺎﯾﺖ ﻣﯽﮐﻨﺪ‪ .‬ﺗﻨﻬﺎ اﻟﺰام اﯾﻦ اﺳﺖ ﮐﻪ ﺗﻤﺎس ﺗﻠﻔﻨﯽ در ﺑﺎزهﻫﺎی زﻣﺎﻧﯽ از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷﺪه ﮔﺮﻓﺘﻪ ﺷﻮد و‬
‫در ﻃﯽ ﮔﻔﺘﮕﻮ ﻣﻮﺿﻮعﻫﺎی اﯾﻦ ﮔﺰارش ﺑﺮرﺳﯽ ﺷﻮﻧﺪ‪ .‬ﻫﻨﮕﺎﻣﯽﮐﻪ ﻧﻮع ﮔﺰارش را ﺗﻌﯿﯿﻦ ﻣﯽﮐﻨﯿﺪ‪ ،‬در ﻋﻤﻞ ﭘﺮﯾﻨﺲ‪ ۲‬را‬
‫اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﺮدهاﯾﺪ‪.‬‬

‫‪ .2.7.1.2‬ﻓﺮآﯾﻨﺪ اﺧﺘﺼﺎﺻﯽﺳﺎزی‬

‫اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺳﯿﺴﺘﻢ ﺑﺤﺜﯽ ﮐﻤﺎﺑﯿﺶ ﻃﻮﻻﻧﯿﺴﺖ و در ﻓﺼﻞ ﭼﻬﺎرم ﺑﺎ ﺗﻔﺼﯿﻞ ﺑﯿﺸﺘﺮی ﺑﻪ آن ﺧﻮاﻫﯿﻢ ﭘﺮداﺧﺖ‪.‬‬
‫اﮐﻨﻮن ﺑﺮ ﻣﻮﺿﻮع دﯾﮕﺮی ﺗﻤﺮﮐﺰ ﻣﯽﮐﻨﯿﻢ‪ :‬ﻓﺮآﯾﻨﺪ و روش اﺧﺘﺼﺎﺻﯽﺳﺎزی‪.‬‬

‫در ﭘﻢﺑﺎک ‪ ۷‬روﺷﯽ دوﻣﺮﺣﻠﻪای ﺑﺮای اﺧﺘﺼﺎﺻﯽﺳﺎزی ﭘﯿﺸﻨﻬﺎد ﮐﺮدهاﯾﻢ‪:‬‬

‫‪ .1‬ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ در ﯾﮏ ﺳﺎزﻣﺎن اﺟﺮا ﻣﯽﺷﻮﻧﺪ ﻫﻤﺎﻧﻨﺪیﻫﺎی ﻓﺮاواﻧﯽ دارﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﻪﺟﺎی اﯾﻦﮐﻪ ﻫﺮﺑﺎر‬
‫ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را درون ﭘﺮوژه اﺧﺘﺼﺎﺻﯽ ﮐﻨﯿﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﯾﮏﺑﺎر آن را ﮐﻼن و ﻧﯿﻤﻪﮐﺎره در ﺳﻄﺢ‬
‫ﺳﺎزﻣﺎن و ﺑﺮای ﺟﻨﺒﻪﻫﺎی ﻣﺸﺘﺮک ﭘﺮوژهﻫﺎ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﻨﯿﺪ‪ .‬اﮔﺮ ﻧﯿﺎز ﺑﺎﺷﺪ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﯿﺸﺘﺮ از ﯾﮏ ﺣﺎﻟﺖ‬
‫ﻧﯿﻤﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺷﺪه در ﺳﻄﺢ ﺳﺎزﻣﺎن داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﺗﺎ اﻧﻮاع ﻣﺨﺘﻠﻔﯽ از ﭘﺮوژه را ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﻨﺪ‪.‬‬
‫‪ .2‬ﻫﺮﭼﻪ ﻫﻢ ﮐﻪ ﭘﺮوژهﻫﺎی ﺳﺎزﻣﺎن ﻫﻤﺎﻧﻨﺪ ﺑﺎﺷﻨﺪ‪ ،‬ﺑﺎز ﻫﻢ دﻗﯿﻘﺎ ﯾﮑﺴﺎن ﻧﯿﺴﺘﻨﺪ و ﺑﺎﯾﺪ ﺣﺪی از اﺧﺘﺼﺎﺻﯽﺳﺎزی‬
‫درون ﭘﺮوژه اﻧﺠﺎم ﺷﻮد‪ .‬از اﯾﻦ رو‪ ،‬اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺳﺎزﻣﺎﻧﯽ ﻧﯿﻤﻪﮐﺎره اﺳﺖ و ﻗﺴﻤﺖ دوم آن ﺟﺪاﮔﺎﻧﻪ در ﻫﺮ‬
‫ﭘﺮوژه اﻧﺠﺎم ﻣﯽﺷﻮد‪.‬‬

‫ﺑﺮای ﻧﺨﺴﺘﯿﻦ ﻣﺮﺣﻠﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﯿﺎز ﺑﻪ ﻣﺮﮐﺰی در ﺳﺎزﻣﺎن دارﯾﺪ‪ .‬اﯾﻦ ﻣﺮﮐﺰ را ﻣﯽﺗﻮان ﻣﺮﮐﺰ ﺗﻌﺎﻟﯽ )‪center of‬‬
‫‪ ( excellence‬ﻧﺎﻣﯿﺪ‪ .‬ﺑﺴﯿﺎری ﻋﻼﻗﻪ واﻓﺮ ﺑﻪ ﻋﺒﺎرت ‪ PMO‬دارﻧﺪ )ﻣﺨﻔﻒ ‪ project management office‬ﯾﺎ ﻋﺒﺎرتﻫﺎی‬
‫دﯾﮕﺮ(‪ .‬اﮔﺮ ﺳﺎزﻣﺎن ‪ PMO‬داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻣﺪﯾﺮﯾﺖ ﻧﺨﺴﺘﯿﻦ ﻣﺮﺣﻠﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻣﯽﺗﻮاﻧﺪ از وﻇﺎﯾﻒ اﺻﻠﯽ آن ﺑﻪ‬
‫ﺷ ﻤ ﺎ ر ﺑ ﺮ و د‪.‬‬

‫‪ .3 . 7 . 1 . 2‬ﭘ ﯿ ﭽ ﯿ ﺪ ﮔ ﯽ ا ﺧ ﺘ ﺼ ﺎ ﺻ ﯽ ﺳ ﺎ ز ی‬

‫ﻣﺘﺎﺳﻔﺎﻧﻪ واﻗﻌﯿﺖ اﯾﻦ اﺳﺖ ﮐﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﺎر ﺳﺎدهای ﻧﯿﺴﺖ‪ .‬ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺑﻪ‬
‫ﻣﻌﻨﯽ اﻧﺘﺨﺎب ﻫﯿﺠﺎناﻧﮕﯿﺰﺗﺮﯾﻦ ﻋﻨﺎﺻﺮ از ﺳﯿﺴﺘﻢﻫﺎی ﻣﺨﺘﻠﻒ و ﮐﻨﺎر ﻫﻢ ﻗﺮار دادن آنﻫﺎﺳﺖ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ ﭼﻨﯿﻦ ﮐﺎری‬
‫ﺳﺎزﮔﺎری دروﻧﯽ ﺳﯿﺴﺘﻢ و ﺑﻨﺎﺑﺮاﯾﻦ ﮐﺎرآﯾﯽ آن را از ﺑﯿﻦ ﻣﯽﺑﺮد‪ .‬اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﻮﻋﯽ ﺳﺎﺧﺖ ﺳﯿﺴﺘﻢ اﺳﺖ و ﻫﻤﭽﻮن‬
‫ﻫ ﺮ ﺳ ﺎ ﺧ ﺖ ﺳ ﯿ ﺴ ﺘ ﻢ د ﯾ ﮕ ﺮ ی ﺑ ﺎ ﯾ ﺪ ﺑ ﺎ د ﯾ ﺪ ی ﻫ ﻤ ﻪ ﺟ ﺎ ﻧ ﺒ ﻪ و ﻣ ﻮ ﺷ ﮑ ﺎ ﻓ ﺎ ﻧ ﻪ ا ﻧ ﺠ ﺎ م ﺷ ﻮ د‪.‬‬

‫در ﺑﯿﺸﺘﺮ ﺳﯿﺴﺘﻢﻫﺎ ﻣﺴﺌﻮﻟﯿﺖ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺑﺎ ﻣﺪﯾﺮ ﭘﺮوژه اﺳﺖ‪ ،‬وﻟﯽ ﮐﺴﯽ ﮐﻪ از ﻫﺮ ﺟﻬﺖ دﯾﮕﺮ ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺴﯿﺎر‬
‫ﺧﻮﺑﯽ ﺑﺎﺷﺪ ﺷﺎﯾﺪ ﺗﻮاﻧﺎﯾﯽ ﺳﺎﺧﺖ ﺳﯿﺴﺘﻢ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬اﯾﻦﮐﻪ از ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎ اﻧﺘﻈﺎر داﺷﺘﻪ ﺑﺎﺷﯿﻢ ﮐﻪ ﺑﺘﻮاﻧﻨﺪ‬
‫ﺳﯿﺴﺘﻢﻫﺎ را اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﻨﻨﺪ ﻫﻤﯿﺸﻪ واﻗﻊﺑﯿﻨﺎﻧﻪ و ﻣﻨﺼﻔﺎﻧﻪ ﻧﯿﺴﺖ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ در ‪ DSDM‬ﮐﻪ ﯾﮑﯽ از‬
‫ﻣﺘﺪوﻟﻮژیﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ ﻧﺨﺴﺖ اﺳﺖ ﺑﻪ رﺳﻤﯿﺖ ﺷﻨﺎﺧﺘﻪ ﺷﺪه اﺳﺖ‪ ،‬و از اﯾﻦ رو‪ ،‬در اﻧﺘﺨﺎﺑﯽ ﻫﻮﺷﻤﻨﺪاﻧﻪ‪ ،‬ﻧﻘﺸﯽ‬

‫— ‪— 27‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺎ ﻧﺎم ﻣﺮﺑﯽ ‪ DSDM‬ﺑﻪ ﻣﺘﺪوﻟﻮژی اﻓﺰودهاﻧﺪ ﮐﻪ ﻣﺴﺌﻮﻟﯿﺖ اﺧﺘﺼﺎﺻﯽﺳﺎزی و ﺑﺮﺧﯽ ﻣﺴﺎﯾﻞ دﯾﮕﺮ را ﺑﺮ دوش دارد‪.‬‬

‫‪ .4.7.1.2‬زﻣﺎن اﺧﺘﺼﺎﺻﯽﺳﺎزی‬

‫ﭼﻪ زﻣﺎﻧﯽ ﺑﺎﯾﺪ ﺳﯿﺴﺘﻢ را اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﺮد؟ ﭘﺎﺳﺦ ﺑﺴﺘﮕﯽ ﺑﻪ ﻣﺘﺪوﻟﻮژیای دارد ﮐﻪ اﻧﺘﺨﺎب ﮐﺮدهاﯾﺪ‪:‬‬

‫در ﺳﯿﺴﺘﻢﻫﺎی ﻣﺎﮐﺴﯿﻤﺎﻟﯿﺴﺘﯽ‪ ،‬ﻣﺎﻧﻨﺪ ﭘﺮﯾﻨﺲ‪ ،۲‬ﻋﻨﺎﺻﺮ ﻓﺮاواﻧﯽ وﺟﻮد دارد ﮐﻪ ﮐﻤﺎﺑﯿﺶ ﻫﺮ ﻧﻮع ﭘﺮوژهای را‬
‫ﭘﻮﺷﺶ ﻣﯽدﻫﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﻻزم اﺳﺖ ﮐﻪ در آﻏﺎز و ﭘﯿﺶ از ﺑﻪ ﮐﺎرﮔﯿﺮی ﺳﯿﺴﺘﻢ آن را اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﺮد‪.‬‬
‫ﺳﯿﺴﺘﻢﻫﺎی ﻣﯿﻨﯿﻤﺎﻟﯿﺴﺘﯽ‪ ،‬ﻣﺎﻧﻨﺪ ‪ ،P3.express‬ﺣﺪاﻗﻞ ﻋﻨﺎﺻﺮی ﮐﻪ در ﭘﺮوژهﻫﺎی ﻣﺨﺎﻃﺒﺸﺎن ﮐﻠﯿﺪی و ﻣﺸﺘﺮک‬
‫ﺑﺎﺷﻨﺪ را ﭘﻮﺷﺶ ﻣﯽدﻫﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﻧﯿﺎزی ﻧﯿﺴﺖ ﮐﻪ در آﻏﺎز ﺳﯿﺴﺘﻢ را اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﺮد و ﺑﻪﺟﺎی آن ﺑﺎﯾﺪ‬
‫ﭘﺲ از ﻣﺮور زﻣﺎن و ﺑﺮ ﭘﺎﯾﻪ ﺑﺎزﺧﻮرد ﻣﺤﯿﻄﯽ ﺑﻪ ﺗﺪرﯾﺞ دﺳﺖﺑﻪﮐﺎر اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺷﺪ‪.‬‬

‫ﺣﺘﯽ زﻣﺎﻧﯽ ﮐﻪ ﺳﯿﺴﺘﻢ ﻧﯿﺎز ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی آﻏﺎزﯾﻦ داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﺎز ﻫﻢ ﻻزم اﺳﺖ ﮐﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺗﺪرﯾﺠﯽ‬
‫در ﻫﻨﮕﺎم ﮐﺎر داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬اﺧﺘﺼﺎﺻﯽﺳﺎزی آﻏﺎزﯾﻦ ﮐﺎر ﭘﺮ رﯾﺴﮑﯽ اﺳﺖ؛ ﭼﺎﻟﺶ راﯾﺞ اﯾﻦ اﺳﺖ ﮐﻪ‬
‫اﺧﺘﺼﺎﺻﯽﺳﺎزیﻫﺎی ﻧﺨﺴﺘﯿﻦ ﻏﯿﺮواﻗﻊﺑﯿﻨﺎﻧﻪ و زﯾﺎد از ﺣﺪ ﭘﯿﭽﯿﺪه و ﺳﻨﮕﯿﻦ ﻣﯽﺷﻮﻧﺪ و ﮐﺎرﮐﺮد ﺳﯿﺴﺘﻢ را ﻣﺨﺘﻞ‬
‫ﻣﯽﮐﻨﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ اﮔﺮ ﻧﯿﺎز ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی آﻏﺎزﯾﻦ دارﯾﺪ‪ ،‬آن را ﺳﺎده و ﺣﺪاﻗﻠﯽ اﻧﺠﺎم دﻫﯿﺪ و‬
‫ﺑﺎﻗﯿﻤﺎﻧﺪه آن را در ﻫﻨﮕﺎم ﮐﺎر ﭘﯿﺶ ﺑﺒﺮﯾﺪ‪.‬‬

‫‪ .8.1.2‬ﮐﯿﻔﯿﺖ را در ﻓﺮآﯾﻨﺪﻫﺎ و ﻣﺤﺼﻮلﻫﺎ ﻧﻬﺎدﯾﻨﻪ ﮐﻨﯿﺪ‬

‫آﯾﺎ ﺗﺎﮐﻨﻮن از ﮐﺴﯽ ﺷﻨﯿﺪهاﯾﺪ ﮐﻪ ﺑﮕﻮﯾﺪ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ زﯾﺎد از ﺣﺪ ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ؟‬

‫ﭼﻨﯿﻦ ﻣﺴﺌﻠﻪای ﻧﻤﻮﻧﻪ دﯾﮕﺮی از اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺎﻣﻨﺎﺳﺐ در ﭘﺮوژه اﺳﺖ‪ .‬اﻧﺠﺎم ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻫﺰﯾﻨﻪ‬
‫و ﮐﻮﺷﺸﯽ ﻧﯿﺎزی دارد و در ازاﯾﺶ ﺑﺎ ﮐﻢ ﮐﺮدن اﯾﺮادﻫﺎ ﺑﻪ ﮐﺎﻫﺶ ﻫﺰﯾﻨﻪ ﮐﻤﮏ ﻣﯽﮐﻨﺪ‪ .‬ﻣﺎﻧﻨﺪ ﻫﺮ ﻋﻨﺼﺮ دﯾﮕﺮی در‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﺑﺎﯾﺪ ﺑﺎزﮔﺸﺘﯽ ﮐﻪ از آن درﯾﺎﻓﺖ ﻣﯽﮐﻨﯿﺪ ﺑﯿﺸﺘﺮ از ﺳﺮﻣﺎﯾﻪای ﺑﺎﺷﺪ ﮐﻪ ﺻﺮﻓﺶ ﻣﯽﮐﻨﯿﺪ‪ .‬اﮔﺮ زﻣﺎﻧﯽ‬
‫ﻣﺘﻮﺟﻪ ﺷﺪﯾﺪ ﮐﻪ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ زﯾﺎد از ﺣﺪ ﭘﺮﻫﺰﯾﻨﻪ ﯾﺎ ﭘﺮدردﺳﺮ اﺳﺖ‪ ،‬ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ آن را ﺑﻪﺧﻮﺑﯽ‬
‫اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﮑﺮدهاﯾﺪ‪.‬‬

‫‪ .1.8.1.2‬آزﻣﺎﯾﺶ‬

‫ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻓﻘﻂ ﺑﻪ ﻣﻌﻨﯽ آزﻣﺎﯾﺶ ﺧﺮوﺟﯽﻫﺎی ﭘﺮوژه و ﻣﻄﻤﺌﻦ ﺷﺪن از درﺳﺘﯽ‬
‫آنﻫﺎﺳﺖ‪ .‬آزﻣﺎﯾﺶﻫﺎ ﺑﺨﺸﯽ از ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻫﺴﺘﻨﺪ‪ ،‬وﻟﯽ ﻓﻘﻂ واﭘﺴﯿﻦ ﮔﺎم‪ .‬ﻫﺪف اﺻﻠﯽ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ اﯾﻦ‬
‫اﺳﺖ ﮐﻪ ﮐﺎر را ﺑﻪ ﮔﻮﻧﻪای اﻧﺠﺎم دﻫﯿﻢ ﮐﻪ اﺣﺘﻤﺎل ﻧﺎﻣﻨﺎﺳﺐ ﺑﻮدن ﺧﺮوﺟﯽ ﺗﺎ ﺣﺪ ﻣﻌﻘﻮﻟﯽ ﮐﻢ ﺷﻮد‪ .‬ﻫﺪف اﺻﻠﯽ‬
‫ﭘﯿﺸﮕﯿﺮﯾﺴﺖ و ﻧﻪ درﻣﺎن و ﺟﻨﺒﻪای ﮐﻪ ﺑﻪ ﮐﺎﻫﺶ ﻫﺰﯾﻨﻪﻫﺎ ﮐﻤﮏ ﻣﯽﮐﻨﺪ ﻧﯿﺰ ﻫﻤﺎن ﺑﺨﺶ ﭘﯿﺸﮕﯿﺮﯾﺴﺖ‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ‪ ،‬ﻣﺎﻧﻨﺪ ﻫﻤﻪ ﺣﻮزهﻫﺎی دﯾﮕﺮ در ﻣﺪﯾﺮﯾﺖ‪ ،‬ﺑﺎﯾﺪ ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ اﻧﺠﺎم ﺷﻮد ﺗﺎ ﮐﺎرآﻣﺪ ﺑﺎﺷﺪ‪ .‬ﺑﺮﺧﻮرد‬
‫ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ ﺑﺎ ﮐﺎر ﯾﮑﯽ از اﺻﻞﻫﺎی ‪ NUPP‬ﻧﯿﺰ ﻫﺴﺖ ﮐﻪ در اداﻣﻪ اﯾﻦ ﻓﺼﻞ ﺑﻪﮐﻮﺗﺎﻫﯽ ﺑﺮرﺳﯽ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫— ‪— 28‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .2 . 8 . 1 . 2‬ﻟ ﺤ ﺎ ظ ﺷ ﺪ ن ا ز آ ﻏ ﺎ ز ﮐ ﺎ ر‬

‫اﮔﺮ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺧﻮد را ﺷﮑﻞ دﻫﯿﺪ و ﺳﭙﺲ ﺑﻪ اﯾﻦ ﺑﯿﻨﺪﯾﺸﯿﺪ ﮐﻪ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮان ﻋﻨﺎﺻﺮی ﺑﺮای ﻣﺪﯾﺮﯾﺖ‬
‫ﮐ ﯿ ﻔ ﯿ ﺖ ﺑ ﻪ آ ن ا ﻓ ﺰ و د ‪ ،‬ا ﺣ ﺘ ﻤ ﺎ ﻻ ﭼ ﻨ ﺪ ا ن ﻣ ﻮ ﻓ ﻖ ﻧ ﺨ ﻮ ا ﻫ ﯿ ﺪ ﺑ ﻮ د‪ .‬ﻣ ﺪ ﯾ ﺮ ﯾ ﺖ ﮐ ﯿ ﻔ ﯿ ﺖ ﺑ ﺎ ﯾ ﺪ ﻋ ﻨ ﺼ ﺮ ی ﯾ ﮑ ﭙ ﺎ ر ﭼ ﻪ د ر ﺳ ﯿ ﺴ ﺘ ﻢ ﺑ ﻮ د ه ‪ ،‬ا ز‬
‫آ ﻏ ﺎ ز د ر ﺷ ﮑ ﻞ د ﻫ ﯽ آ ن ﻟ ﺤ ﺎ ظ ﺷ ﺪ ه ﺑ ﺎ ﺷ ﺪ‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﺑﺎﯾﺪ دو ﻣﻮﺿﻮع ﻣﺘﻔﺎوت را ﭘﻮﺷﺶ دﻫﺪ‪:‬‬

‫ﮐﯿ ﻔﯿ ﺖ ﻣ ﺤ ﺼ ﻮ ل و ﺷﯿ ﻮه ﺳﺎ ﺧ ﺖ آ ن‬
‫ﮐﯿﻔﯿﺖ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬

‫‪ .3 . 8 . 1 . 2‬ﮐ ﯿ ﻔ ﯿ ﺖ ﻣ ﺤ ﺼ ﻮ ل و ﺷ ﯿ ﻮ ه ﺳ ﺎ ﺧ ﺖ‬

‫ﯾ ﮑ ﯽ ا ز د و ﻣ ﻮ ﺿ ﻮ ع ﻣ ﺪﯾ ﺮﯾ ﺖ ﮐﯿ ﻔﯿ ﺖ ‪ ،‬ﻣ ﺤ ﺼ ﻮ ل و ﺷﯿ ﻮ ه ﺳﺎ ﺧ ﺖ آ ن ا ﺳ ﺖ ﮐ ﻪ ﻣ ﻮ ﺿ ﻮ ﻋ ﯽ ﻓﻨﯿ ﺴ ﺖ واﺑ ﺴﺘ ﻪ ﺑ ﻪ ﻧ ﻮ ع ﻣ ﺤ ﺼ ﻮ ل ؛‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪:‬‬

‫ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری آزﻣﺎﯾﺶﻫﺎی ﺧﻮدﮐﺎر و دﺳﺘﯽ ﻓﺮاواﻧﯽ دارﻧﺪ ﮐﻪ ﻣﻄﻤﺌﻦ ﺷﻮﻧﺪ ﻧﺮماﻓﺰاری ﮐﻪ در اﺧﺘﯿﺎر ﮐﺎرﺑﺮ‬
‫ﻗﺮار ﻣﯽﮔﯿﺮد ﮐﺎرﮐﺮد درﺳﺘﯽ ﺧﻮاﻫﺪ داﺷﺖ‪ .‬در ﮐﻨﺎر آن ﻣﯽﺗﻮان از روﺷﯽ ﻣﺎﻧﻨﺪ ‪ pair programming‬ﻧﯿﺰ ﺑﺮای‬
‫ﺑﻬﺒﻮد ﮐﯿﻔﯿﺖ ﺑﻬﺮه ﺑﺮد‪ .‬در اﯾﻦ روش ﻫﺮروز اﻋﻀﺎی ﺗﯿﻢ ﺑﻪ ﮔﺮوهﻫﺎی دوﻧﻔﺮه ﺗﻘﺴﯿﻢ ﻣﯽﺷﻮﻧﺪ‪ .‬ﻫﺮ ﮔﺮوه روی‬
‫ﻗﺎﺑﻠﯿﺘﯽ ﮐﺎر ﻣﯽﮐﻨﺪ؛ ﯾﮑﯽ از آن دو ﻧﻔﺮ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﻣﯽﮐﻨﺪ و ﻧﻔﺮ دﯾﮕﺮ ﻧﻈﺎرهﮔﺮ اﺳﺖ و در ﻫﻨﮕﺎم ﮐﺎر‬
‫ﭘﯿﺸﻨﻬﺎدﻫﺎﯾﯽ ﻣﯽدﻫﺪ‪ .‬ﻫﺮ ﻧﯿﻢ ﺳﺎﻋﺖ ﺗﺎ ﯾﮏ ﺳﺎﻋﺖ اﯾﻦ دو ﻧﻔﺮ ﺟﺎﯾﺸﺎن را ﺑﺎ ﯾﮑﺪﯾﮕﺮ ﻋﻮض ﻣﯽﮐﻨﻨﺪ‪.‬‬
‫در ﭘﺮوژهﻫﺎی ﺳﺎﺧﺘﯽ ﮐﻪ ﺑﺘﻨﯽ ﺑﺎﺷﻨﺪ روشﻫﺎی آزﻣﺎﯾﺶ ﻣﺨﺮب و ﻧﺎﻣﺨﺮب ﮔﻮﻧﺎﮔﻮﻧﯽ ﺑﺮای ﺑﺘﻦ وﺟﻮد دارد‪ ،‬وﻟﯽ‬
‫اﻓﺰون ﺑﺮ آن آﯾﯿﻦﻧﺎﻣﻪﻫﺎ و اﺳﺘﺎﻧﺪاردﻫﺎﯾﯽ ﻫﻢ درﺑﺎره ﻧﻮع ﺷﻦ و آب‪ ،‬ﻧﮕﻬﺪاری ﺳﯿﻤﺎن‪ ،‬ﺷﯿﻮه ﻣﺨﻠﻮط ﮐﺮدن‬
‫ﻣﻮاد‪ ،‬ﺷﯿﻮه ﻧﮕﻬﺪاری از ﺑﺘﻦ ﭘﺲ از ﺑﺘﻦرﯾﺰی و ﻫﻤﺎﻧﻨﺪ آن وﺟﻮد دارد ﮐﻪ رﻋﺎﯾﺘﺸﺎن اﺣﺘﻤﺎل رﺧﺪاد ﻣﺸﮑﻞ را‬
‫ﮐ ﻤ ﺘ ﺮ ﻣ ﯽ ﮐ ﻨ ﺪ‪.‬‬

‫ﺑﻪ ﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژهای ﮐﻪ اﻟﺰاﻣﺎ ﻓﻨﯽ ﻫﻢ ﻧﯿﺴﺖ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﯿﺪ از اﯾﻦ ﺟﻨﺒﻪﻫﺎی ﻓﻨﯽ اﻃﻼع داﺷﺘﻪ ﺑﺎﺷﯿﺪ؟‬

‫ﻣﺎﻧﻨﺪ ﻫﻤﯿﺸﻪ‪ ،‬ﻧﯿﺎزی ﻧﯿﺴﺖ ﮐﻪ ﺷﺨﺼﺎ ﻫﻤﻪ اﯾﻦ ﻣﻮارد را ﺑﺸﻨﺎﺳﯿﺪ‪ ،‬ﺑﻠﮑﻪ ﺑﺎﯾﺪ از ﺗﯿﻢ ﻣﺘﺨﺼﺼﯽ ﮐﻪ در ﮐﻨﺎر ﺧﻮد دارﯾﺪ‬
‫ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ‪ .‬آﻧﭽﻪ ﺑﺮای ﺷﻤﺎ ﻻزم اﺳﺖ اﯾﻦ اﺳﺖ ﮐﻪ ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ روﻧﺪ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻓﻨﯽ ﺑﻪﺧﻮﺑﯽ ﺷﻨﺎﺳﺎﯾﯽ‪،‬‬
‫ﻣﺴﺘﻨﺪ‪ ،‬و اﺟﺮا ﺷﺪه اﺳﺖ‪ .‬آﯾﺎ ﮐﺎرﻓﺮﻣﺎ اﻧﺘﻈﺎرﻫﺎی ﮐﯿﻔﯽ وﯾﮋهای از ﭘﺮوژه دارد؟ آﯾﺎ آﯾﯿﻦﻧﺎﻣﻪﻫﺎﯾﯽ وﺟﻮد دارد ﮐﻪ ﻣﻠﺰم ﺑﻪ‬
‫رﻋﺎﯾﺘﺸﺎن ﺑﺎﺷﯿﺪ؟ آﯾﺎ اﺳﺘﺎﻧﺪاردﻫﺎﯾﯽ وﺟﻮد دارد ﮐﻪ رﻋﺎﯾﺘﺸﺎن ﺑﻪ ﻧﻔﻌﺘﺎن ﺑﺎﺷﺪ؟ آﯾﺎ ﺳﺎزﻣﺎن دﺳﺘﻮراﻟﻌﻤﻞﻫﺎﯾﯽ درﺑﺎره‬
‫ﮐﯿﻔﯿﺖ دارد و اﻧﺘﻈﺎر دارد ﮐﻪ ﻫﻤﻪ ﭘﺮوژهﻫﺎ رﻋﺎﯾﺘﺸﺎن ﮐﻨﻨﺪ؟ ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ اﯾﻦ ﻣﻮارد را ﮐﻨﺘﺮل ﮐﻨﯿﺪ و ﭘﺎﺳﺦ‬
‫ﻣﻨﺎﺳﺒﯽ ﺑﺮاﯾﺸﺎن داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪.‬‬

‫‪ .4.8.1.2‬ﮐﯿﻔﯿﺖ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬

‫ﮐﯿﻔﯿﺖ ﻣﺤﺼﻮل و ﺷﯿﻮه ﺳﺎﺧﺖ آن را ﺑﻪﮐﻮﺗﺎﻫﯽ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪ .‬ﻋﻨﺼﺮ دﯾﮕﺮی ﮐﻪ ﺑﺎﯾﺪ در ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻣﺪ ﻧﻈﺮ‬

‫— ‪— 29‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺎﺷﺪ‪ ،‬ﮐﯿﻔﯿﺖ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ‪ .‬ﺑﻠﻪ‪ ،‬اﯾﻦ ﻣﺴﺌﻠﻪ ﺣﺘﯽ درﺑﺮﮔﯿﺮﻧﺪه ﮐﯿﻔﯿﺖ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻫﻢ‬
‫ﻣ ﯽ ﺷ ﻮ د!‬

‫ﻧﻤﻮﻧﻪ ﺧﻮﺑﯽ از ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه در ‪ P3.express‬ﻫﻤﺘﺎداوری )‪ (peer review‬دورهاﯾﺴﺖ‪ .‬در آﻏﺎز ﻫﺮ‬
‫ﻣﺎه‪ ،‬ﭘﺲ از اﯾﻦﮐﻪ ﺑﺮﻧﺎﻣﻪﻫﺎی ﮐﻼن ﺑﺎزﺑﯿﻨﯽ و ﺑﺮﻧﺎﻣﻪ ﺗﻔﺼﯿﻠﯽ ﻣﺎه ﭘﯿﺶ رو آﻣﺎده ﺷﻮد‪ ،‬ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ از ﯾﮑﯽ دﯾﮕﺮ از‬
‫ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ در ﺳﺎزﻣﺎن وﺟﻮد دارد درﺧﻮاﺳﺖ ﻫﻤﺘﺎداوری ﮐﻨﺪ‪ .‬ﻣﺪﯾﺮ ﭘﺮوژه دوم زﻣﺎﻧﯽ را ﺻﺮف ﻣﯽﮐﻨﺪ و ﻫﻤﺮاه‬
‫ﻫﻢ ﮐﺎرﻫﺎی اﻧﺠﺎم ﺷﺪه را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﻨﺪ ﺗﺎ اﮔﺮ ﻣﺸﮑﻠﯽ وﺟﻮد داﺷﺖ ﮐﺸﻒ ﺷﻮد‪ .‬ﭘﯿﺸﻨﻬﺎد ‪ P3.express‬اﯾﻦ اﺳﺖ‬
‫ﮐﻪ در ﺻﻮرت اﻣﮑﺎن ﻫﺮ ﻣﺎه از ﻓﺮد ﺗﺎزهای ﺑﺮای ﻫﻤﺘﺎداوری دﻋﻮت ﮐﻨﯿﺪ‪.‬‬

‫ﯾﮑﯽ از اﻣﺘﯿﺎزﻫﺎی ﻫﻤﺘﺎداوری ﮐﺸﻒ زودﻫﻨﮕﺎم ﻣﺸﮑﻞﻫﺎی اﺣﺘﻤﺎﻟﯿﺴﺖ‪ ،‬وﻟﯽ اﻓﺰون ﺑﺮ آن‪ ،‬در ﻃﯽ اﯾﻦ ﻓﺮآﯾﻨﺪ ﻫﺮ دو‬
‫ﻓﺮد از ﯾﮑﺪﯾﮕﺮ ﻧﮑﺘﻪﻫﺎی ﺟﺎﻟﺒﯽ ﻣﯽآﻣﻮزﻧﺪ‪ .‬اﯾﻦ ﻓﺮﺻﺖ ﻃﻼﯾﯽ را ﺑﻪ ﻫﯿﭻ وﺟﻪ ﻧﺒﺎﯾﺪ از دﺳﺖ ﺑﺪﻫﯿﺪ‪ .‬ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﻢ‬
‫ﮐﻪ ﺑﻪ ﻫﺮ ﻣﺘﺪوﻟﻮژیای ﮐﻪ دارﯾﺪ ﻫﻤﺘﺎداوری ﻫﻢ ﺑﯿﻔﺰاﯾﯿﺪ‪.‬‬

‫‪ .9.1.2‬واﮐﻨﺶﻫﺎﯾﯽ درﺧﻮر ﺑﻪ رﯾﺴﮏﻫﺎ ﻧﺸﺎن دﻫﯿﺪ‬

‫در ﯾﮑﯽ از ﭘﺮوژهﻫﺎی ﺳﺎﺧﺘﻤﺎﻧﯽای ﮐﻪ ﻫﻤﮑﺎری ﻣﯽﮐﺮدم ﮐﺎرﮔﺮ آرﻣﺎﺗﻮرﺑﻨﺪ ﺧﻮشروﯾﯽ ﮐﺎر ﻣﯽﮐﺮد‪ .‬ﮔﺎﻫﯽ ﺳﻼم و‬
‫اﺣﻮالﭘﺮﺳﯽ ﻣﯽﮐﺮدﯾﻢ‪ .‬ﺑﺎ اﯾﻦﮐﻪ ﮐﻤﺎﺑﯿﺶ ﺟﻮان ﺑﻮد‪ ،‬ﻫﻤﺴﺮ و دو ﻓﺮزﻧﺪ داﺷﺖ ﮐﻪ در ﺷﻬﺮ دوری زﻧﺪﮔﯽ ﻣﯽﮐﺮدﻧﺪ‪.‬‬
‫ﻫﻤﯿﺸﻪ ﭼﺸﻢ اﻧﺘﻈﺎر ﺗﻌﻄﯿﻼت ﺑﻮد ﮐﻪ ﺑﻪ ﺷﻬﺮش ﺑﺮود و ﻣﺪﺗﯽ در ﮐﻨﺎر اﻋﻀﺎی ﺧﺎﻧﻮادهاش ﺑﺎﺷﺪ‪.‬‬

‫ﯾﮏ روز ﮐﻪ ﺑﻪ ﮐﺎرﮔﺎه رﻓﺘﻢ دﯾﺪم ﮐﻪ ﻫﻤﻪ ﺑﻪ ﺳﻤﺘﯽ ﻣﯽدوﻧﺪ‪ .‬ﻣﻦ ﻫﻢ ﺑﻪ آﻧﺠﺎ رﻓﺘﻢ و ﯾﮑﯽ از اﻧﺪوهﺑﺎرﺗﺮﯾﻦ ﺻﺤﻨﻪﻫﺎی‬
‫زﻧﺪﮔﯽام را دﯾﺪم‪ :‬آن ﮐﺎرﮔﺮ در زﻣﺎن ﮐﺎر در ﻃﺒﻘﻪ ﭼﻬﺎرم‪ ،‬ﮐﻪ ﻫﻨﻮز دﯾﻮار ﻧﺪاﺷﺖ‪ ،‬ﻟﻐﺰﯾﺪه و ﺑﻪ ﭘﺎﯾﯿﻦ اﻓﺘﺎده ﺑﻮد‪ .‬دهﻫﺎ‬
‫آرﻣﺎﺗﻮر ﺧﻢﺷﺪه ﮐﻪ ﺑﺮ روی زﻣﯿﻦ ﭘﺮاﮐﻨﺪه ﺑﻮد در ﺑﺪن ﺑﯽﺟﺎﻧﺶ ﻓﺮو رﻓﺘﻪ ﺑﻮد و اﺳﺘﺨﺮی از ﺧﻮن ﺳﺎﺧﺘﻪ ﺑﻮد‪.‬‬

‫‪ .1 . 9 . 1 . 2‬ر ﯾ ﺴ ﮏ‬

‫داﺳﺘﺎن ﺗﺎﺳﻒآوری ﮐﻪ ﺗﻌﺮﯾﻒ ﮐﺮدم ﻧﺘﯿﺠﻪ ﯾﮑﯽ از ﻋﺪمﻗﻄﻌﯿﺖﻫﺎی ﭘﺮوژه ﺑﻮد؛ اﯾﻦﮐﻪ در ﻣﺪﺗﯽ ﮐﻪ دﯾﻮار ﺑﯿﺮوﻧﯽ‬
‫ﻃﺒﻘﻪای ﺳﺎﺧﺘﻪ ﻧﺸﺪه ﺑﺎﺷﺪ‪ ،‬اﺣﺘﻤﺎل دارد ﮐﺴﺎﻧﯽ ﮐﻪ در آن ﻃﺒﻘﻪ ﮐﺎر ﻣﯽﮐﻨﻨﺪ ﺑﻪ ﭘﺎﯾﯿﻦ ﭘﺮت ﺷﻮﻧﺪ‪.‬‬

‫ﻋﺪمﻗﻄﻌﯿﺖﻫﺎﯾﯽ ﮐﻪ ﻣﯽﺗﻮاﻧﻨﺪ ﺑﺮ ﭘﺮوژه اﺛﺮ ﻣﺜﺒﺖ ﯾﺎ ﻣﻨﻔﯽ ﺑﮕﺬارﻧﺪ رﯾﺴﮏ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮﻧﺪ‪ .‬ﺷﯿﻮه ﻣﺪﯾﺮﯾﺖ اﯾﻦ ﻣﻮارد ﺑﺎ‬
‫آﻧﭽﻪ ﻗﻄﻌﯿﺖ دارد )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﯾﻦﮐﻪ ﻣﯽداﻧﯿﻢ ﺣﺘﻤﺎ ﺑﺎﯾﺪ دﯾﻮار ﺑﯿﺮوﻧﯽ آن ﻃﺒﻘﻪ را ﺑﺴﺎزﯾﻢ( ﺗﻔﺎوت دارد و از اﯾﻦ رو‬
‫ﻣﺒﺤﺜﯽ ﺑﺮای ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ وﺟﻮد دارد‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ ﻣﺎﻧﻨﺪ ﻣﺪﯾﺮﯾﺖ ﮐﯿﻔﯿﺖ و ﺳﺎﯾﺮ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ﻣﻨﺎﻓﻊ ﻓﺮاواﻧﯽ دارد‪ ،‬وﻟﯽ ﻫﺮﮔﺎه ﺑﻪ ﻟﺰوم ﻣﺪﯾﺮﯾﺖ‬
‫رﯾﺴﮏ ﺷﮏ ﮐﺮدﯾﺪ‪ ،‬آن ﺟﻮاﻧﯽ ﮐﻪ ﮔﻔﺘﻪ ﺷﺪ را ﺑﻪ ﯾﺎد ﺑﯿﺎورﯾﺪ و ﺑﻪ اﯾﻦ ﻧﮑﺘﻪ ﺑﯿﻨﺪﯾﺸﯿﺪ ﮐﻪ اﮔﺮ ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ ﺑﻬﺘﺮ‬
‫اﻧﺠﺎم ﺷﺪه ﺑﻮد ﺷﺎﯾﺪ ﻫﻨﻮز زﻧﺪه ﻣﯽﺑﻮد و در ﮐﻨﺎر ﻫﻤﺴﺮ و دو ﻓﺮزﻧﺪش زﻧﺪﮔﯽ ﻣﯽﮐﺮد‪.‬‬

‫‪ .2 . 9 . 1 . 2‬ﺷ ﻨ ﺎ ﺳ ﺎ ﯾ ﯽ ر ﯾ ﺴ ﮏ ﻫ ﺎ‬

‫ﻧﺨﺴﺘﯿﻦ ﮔﺎم ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ‪ ،‬ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎﺳﺖ‪ .‬ﺑﺎﯾﺪ در آﻏﺎز ﭘﺮوژه ﮐﺎرﮔﺎهﻫﺎﯾﯽ ﺑﺮﮔﺰار ﮐﺮد و ﺑﺎ ﮐﻤﮏ اﻋﻀﺎی‬

‫— ‪— 30‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺗﯿﻢ ﭘﺮوژه ﺑﻪ ﻋﺪمﻗﻄﻌﯿﺖﻫﺎ اﻧﺪﯾﺸﯿﺪ‪ .‬ﺑﺎ اﯾﻦ ﻫﻤﻪ‪ ،‬ﻫﺮﭼﻪ ﻫﻢ ﮐﻪ در آﻏﺎز ﮐﺎر زﻣﺎن ﺻﺮف ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎ ﮐﻨﯿﻢ‪ ،‬ﺑﺎز‬
‫ﻫﻢ ﻣﻮاردی ﺷﻨﺎﺳﺎﯾﯽ ﻧﺸﺪه ﺑﺎﻗﯽ ﻣﯽﻣﺎﻧﻨﺪ و ﻓﻘﻂ ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺑﻪ آنﻫﺎ ﻧﺰدﯾﮏﺗﺮ ﺷﻮﯾﻢ از آنﻫﺎ آﮔﺎه ﻣﯽﺷﻮﯾﻢ‪ .‬ﮔﺎﻫﯽ‬
‫ﻫﻢ رﯾﺴﮏﻫﺎی ﺗﺎزهای ﺑﻪ دﻟﯿﻞ ﺗﻐﯿﯿﺮ ﺷﺮاﯾﻂ ﻣﺤﯿﻄﯽ ﺑﻪ وﺟﻮد ﻣﯽآﯾﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﻻزم اﺳﺖ ﮐﻪ روﻧﺪ ﺷﻨﺎﺳﺎﯾﯽ‬
‫رﯾﺴﮏﻫﺎ داﯾﻤﺎ ﺗﮑﺮار ﺷﻮد‪.‬‬

‫ﯾﮏ راه ﺧﻮب اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺨﺶ ﮐﻮﭼﮑﯽ ﺑﺮای ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎی ﺗﺎزه ﺑﻪ اﻧﺘﻬﺎی ﺑﯿﺸﺘﺮ ﺟﻠﺴﻪﻫﺎ و ﮐﺎرﮔﺎهﻫﺎ‬
‫ﺑﯿﻔﺰاﯾﯿﺪ‪.‬‬

‫‪ .3 . 9 . 1 . 2‬و ا ﮐ ﻨ ﺶ د ا د ن ﺑ ﻪ ر ﯾ ﺴ ﮏ ﻫ ﺎ‬

‫ﭘﺲ از ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎ ﺑﺎﯾﺪ ﺑﺮﻧﺎﻣﻪﻫﺎی واﮐﻨﺸﯽ ﺑﺮاﯾﺸﺎن ﻃﺮاﺣﯽ ﮐﻨﯿﻢ‪ .‬اﮔﺮ ﻣﯽداﻧﯿﻢ ﮐﻪ ﻧﺒﻮد دﯾﻮار ﺑﯿﺮوﻧﯽ در‬
‫ﻃﺒﻘﻪﻫﺎﯾﯽ ﮐﻪ ﺑﻪ ﺗﺎزﮔﯽ ﺳﺎﺧﺘﻪ ﺷﺪهاﻧﺪ رﯾﺴﮏ ﺣﺎدﺛﻪ ﺑﻪ وﺟﻮد ﻣﯽآورد‪ ،‬ﭼﻪ ﮐﺎری ﺑﺎﯾﺪ ﺑﺮاﯾﺶ ﺑﮑﻨﯿﻢ؟‬

‫ﯾﮏ واﮐﻨﺶ اﯾﻦ اﺳﺖ ﮐﻪ ﻓﻌﺎﻟﯿﺖ ﺗﺎزهای ﺑﻪ ﭘﺮوژه اﺿﺎﻓﻪ ﮐﻨﯿﻢ و ﺑﯽدرﻧﮓ ﭘﺲ از ﺳﺎﺧﺘﻪ ﺷﺪن ﮐﻒ ﻫﺮ ﻃﺒﻘﻪ ﻧﺮدهﻫﺎﯾﯽ‬
‫ﻣﻮﻗﺖ در ﺣﺎﺷﯿﻪ آن ﻧﺼﺐ ﮐﻨﯿﻢ‪ .‬اﯾﻦ ﮐﺎر اﺣﺘﻤﺎل ﺣﺎدﺛﻪ را ﮐﻤﺘﺮ ﻣﯽﮐﻨﺪ‪ ،‬وﻟﯽ ﮐﺎﻓﯽ ﻧﯿﺴﺖ‪ .‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﻢ روﻧﺪ ﮐﺎرﻫﺎ را‬
‫ﮐﻤﯽ ﺗﻐﯿﯿﺮ دﻫﯿﻢ ﮐﻪ ﺳﺎﺧﺖ دﯾﻮارﻫﺎی ﺑﯿﺮوﻧﯽ در زودﺗﺮﯾﻦ زﻣﺎن ﻣﻤﮑﻦ اﻧﺠﺎم ﺷﻮﻧﺪ‪ .‬اﯾﻦ ﮐﺎر ﺑﺎز ﻫﻢ اﺣﺘﻤﺎل رﺧﺪاد‬
‫رﯾﺴﮏ را ﮐﻤﺘﺮ ﻣﯽﮐﻨﺪ‪ .‬ﺷﺎﯾﺪ ﺣﺘﯽ ﺑﺘﻮاﻧﯿﻢ ﻓﻌﺎﻟﯿﺖﻫﺎی دﯾﮕﺮ را ﮐﻤﯽ ﺟﺎﺑﺠﺎ ﮐﻨﯿﻢ ﮐﻪ ﺗﺎ وﻗﺘﯽ ﮐﻪ دﯾﻮارﻫﺎی ﺑﯿﺮوﻧﯽ‬
‫ﺳﺎﺧﺘﻪ ﻧﺸﺪهاﻧﺪ رﻓﺖ و آﻣﺪ در ﻃﺒﻘﻪ ﺣﺪاﻗﻞ ﺷﻮد‪.‬‬

‫ﺑﻪ ﻣﻮازات اﯾﻦ ﻣﺴﺎﯾﻞ‪ ،‬ﻓﮑﺮ ﺧﻮﺑﯿﺴﺖ ﮐﻪ اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه آﻣﻮزش اﯾﻤﻨﯽ ﻫﻢ ﺑﺒﯿﻨﻨﺪ‪ .‬اﯾﻦ واﮐﻨﺶ اﻓﺰون ﺑﺮ رﯾﺴﮏ‬
‫ﻣﺪﻧﻈﺮﻣﺎن ﺑﺮ ﺑﺴﯿﺎری رﯾﺴﮏﻫﺎی دﯾﮕﺮ ﻫﻢ اﺛﺮ ﻣﯽﮔﺬارد و از اﯾﻦ رو ﺑﺴﯿﺎر ﻣﻔﯿﺪ اﺳﺖ‪ .‬اﮔﺮ ﭘﺮوژه ﺑﺰرگ و دوراﻓﺘﺎده‬
‫ﺑﺎﺷﺪ‪ ،‬ﻓﮑﺮ ﺧﻮﺑﯿﺴﺖ ﮐﻪ اﻣﮑﺎﻧﺎﺗﯽ ﺑﺮای ﮐﻤﮏﻫﺎی اوﻟﯿﻪ و ﺣﺘﯽ ﭘﺮﺳﺘﺎری ﻣﻘﯿﻢ ﻫﻢ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮد ﺗﺎ ﻫﻨﮕﺎﻣﯽﮐﻪ‬
‫ﺣﺎدﺛﻪای رخ ﻣﯽدﻫﺪ اﺛﺮش ﮐﺎﻫﺶ ﯾﺎﺑﺪ‪.‬‬

‫اﻓﺰون ﺑﺮ اﺛﺮ ﻣﺎﻟﯽ و زﻣﺎﻧﯽ ﺣﺎدﺛﻪﻫﺎ‪ ،‬ﻣﺴﺌﻮﻟﯿﺖ اﺟﺘﻤﺎﻋﯽ ﻣﺎ ﻧﯿﺰ ﺣﮑﻢ ﻣﯽﮐﻨﺪ ﮐﻪ ﺑﺎ رﯾﺴﮏ ﺣﺎدﺛﻪ ﺑﺎ ﺟﺪﯾﺖ ﺑﺮﺧﻮرد‬
‫ﮐﻨﯿﻢ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬وﻗﺘﯽ ﻫﻤﻪ واﮐﻨﺶﻫﺎی ﻣﻨﻄﻘﯽ را اﻧﺠﺎم دﻫﯿﺪ ﺑﺎز ﻫﻢ اﺣﺘﻤﺎل ﺣﺎدﺛﻪ وﺟﻮد دارد‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺮای‬
‫ﺣﻔﺎﻇﺖ از ﭘﺮوژه در ﺑﺮاﺑﺮ آﺳﯿﺐ ﻣﺎﻟﯽ‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ آن را ﺑﯿﻤﻪ ﻧﯿﺰ ﺑﮑﻨﯿﺪ‪.‬‬

‫آﻧ ﭽ ﻪ ﺗ ﻮ ﺿﯿ ﺢ دا د ه ﺷ ﺪ ‪ ،‬ﻣ ﺪﯾ ﺮﯾ ﺖ رﯾ ﺴ ﮏ ا ﺳ ﺖ ؛ اﯾ ﻦ ﮐ ﻪ ا ﻓ ﺰ و ن ﺑ ﺮ آﻧ ﭽ ﻪ ﻣ ﯽ داﻧﯿ ﻢ ﺑﺎﯾ ﺪ ر و ی د ﻫ ﺪ ‪ ،‬ﺑ ﻪ آﻧ ﭽ ﻪ ﺷﺎﯾ ﺪ ر و ی د ﻫ ﺪ‬

‫ﻧﯿﺰ ﺑﯿﻨﺪﯾﺸﯿﻢ و ﺑﻪ ﺟﺎی اﯾﻦﮐﻪ دﺳﺖ روی دﺳﺖ ﺑﮕﺬارﯾﻢ‪ ،‬ﺑﺮاﯾﺸﺎن ﻓﮑﺮی ﮐﻨﯿﻢ‪.‬‬

‫‪ .10.1.2‬راه ﺧﻮد را در ﭘﯿﭽﯿﺪﮔﯽﻫﺎ ﺑﯿﺎﺑﯿﺪ‬

‫ﺑﻪ ﻧﻈﺮ ﺷﻤﺎ ﺑﺰرگﺗﺮﯾﻦ ﻋﺎﻣﻞ ﭘﯿﭽﯿﺪﮔﯽ در ﭘﺮوژه ﭼﯿﺴﺖ؟‬

‫ﻧﻤﯽداﻧﻢ ﻧﻈﺮ ﺷﻤﺎ ﭼﯿﺴﺖ‪ ،‬وﻟﯽ ﺑﻪ ﻧﻈﺮ ﻣﻦ ﺑﺰرگﺗﺮﯾﻦ ﻋﺎﻣﻞ ﭘﯿﭽﯿﺪﮔﯽ وﺟﻮد اﻧﺴﺎن در ﭘﺮوژه اﺳﺖ! اﻧﺴﺎنﻫﺎ‬
‫ﭘﯿﭽﯿﺪهاﻧﺪ و ﻫﻨﮕﺎﻣﯽﮐﻪ در ﮐﻨﺎر ﻫﻢ ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ ﭘﯿﭽﯿﺪﮔﯽﻫﺎﯾﺸﺎن ﭼﻨﺪ ﺑﺮاﺑﺮ ﻣﯽﺷﻮد‪ .‬اﯾﻦ ﭼﺎﻟﺸﯿﺴﺖ ﮐﻪ از زاوﯾﻪ‬
‫دﯾﺪﻫﺎی ﻣﺨﺘﻠﻒ در ﺳﻪ اﺻﻞ ﻧﺨﺴﺘﯿﻦ ﺑﺮرﺳﯽ ﺷﺪ‪.‬‬

‫— ‪— 31‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫رواﺑﻂ ﻏﯿﺮﺧﻄﯽ ﻋﻨﺎﺻﺮ ﭘﺮوژه ﻋﺎﻣﻞ دﯾﮕﺮی در ﭘﯿﭽﯿﺪﮔﯽﻫﺎی ﭘﺮوژه اﺳﺖ‪ .‬از اﯾﻦ روﺳﺖ ﮐﻪ ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ ﺑﺎ دﯾﺪی‬
‫ﻫﻤﻪﺟﺎﻧﺒﻪ و ﻣﻮﺷﮑﺎﻓﺎﻧﻪ ﺑﺎ ﻣﺴﺎﯾﻞ ﺑﺮﺧﻮرد ﮐﻨﯿﻢ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ را در اﺻﻞ اﻧﺪﯾﺸﻪ ﺳﯿﺴﺘﻤﯽ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪.‬‬

‫ﻋﻨﺼﺮ دﯾﮕﺮی ﮐﻪ ﻣﺎﯾﻪ ﭘﯿﭽﯿﺪﮔﯽ ﭘﺮوژه ﻣﯽﺷﻮد ﻋﺪمﻗﻄﻌﯿﺖﻫﺎی آن اﺳﺖ ﮐﻪ ﻣﻮﺿﻮع اﺻﻞ ﭘﯿﺸﯿﻦ ﺑﻮد‪.‬‬

‫درواﻗﻊ ﻫﻤﻪ اﺻﻞﻫﺎ راهﻫﺎﯾﯽ ﺑﺮای ﮐﻨﺎر آﻣﺪن ﺑﺎ ﭘﯿﭽﯿﺪﮔﯽﻫﺎی ﭘﺮوژه ﻫﺴﺘﻨﺪ و از اﯾﻦ رو ﺷﺨﺼﺎ ﺑﺎ اﻓﺰودن اﯾﻦ اﺻﻞ ﺑﻪ‬
‫ﭘﻢﺑﺎک ﻣﻮاﻓﻖ ﻧﺒﻮدم‪ .‬ﺑﺎ اﯾﻦ ﻫﻤﻪ‪ ،‬ﺳﺎﯾﺮ اﻋﻀﺎی ﺗﯿﻢ ﺑﺎور داﺷﺘﻨﺪ ﮐﻪ اﯾﻦ ﻣﻮﺿﻮع اﻫﻤﯿﺖ ﻓﺮاوان دارد و ﺑﻬﺘﺮ اﺳﺖ ﺑﺮای‬
‫ﺗ ﺎ ﮐ ﯿ ﺪ د ر ﻗ ﺎﻟ ﺐ ا ﺻﻠ ﯽ ﺟ ﺪ ا ﮔ ﺎ ﻧ ﻪ ا ﻓ ﺰ و د ه ﺷ ﻮ د‪.‬‬

‫اﯾﻨﮕﻮﻧﻪ‪ ،‬ﭼﻨﺪ ﺳﺎل ﭘﺲ از آن ﻣﺬاﮐﺮه ﻧﺎﻣﻮﻓﻖ در ﺣﺎل ﻧﻮﺷﺘﻦ ﮐﺘﺎﺑﯽ درﺑﺎره ﭘﻢﺑﺎک ﻫﺴﺘﻢ‪ ،‬ﺑﻪ اﯾﻦ اﺻﻞ رﺳﯿﺪهام‪ ،‬و‬
‫ﻫﯿﭻ ﻣﻄﻠﺐ ﺗﺎزهای ﻧﺪارم ﮐﻪ ﺑﺮاﯾﺶ اراﺋﻪ ﮐﻨﻢ!‬

‫‪ .11.1.2‬اﺳﺘﻮار و ﺗﻄﺒﯿﻖﭘﺬﯾﺮ ﺑﺎﺷﯿﺪ‬

‫ﺳﺎلﻫﺎی اﺧﯿﺮ ﻫﻤﮕﯽ از ﭼﺎﺑﮑﯽ )‪ (Agility‬ﺳﺨﻦ ﻣﯽﮔﻮﯾﻨﺪ‪ .‬اﻟﺒﺘﻪ ﺗﺐ ﭼﺎﺑﮑﯽ در دﻧﯿﺎ ﮐﻤﺎﺑﯿﺶ رو ﺑﻪ ﻓﺮوﮐﺶ اﺳﺖ‪ ،‬وﻟﯽ‬
‫ﻫ ﻤ ﭽ ﻨ ﺎ ن ﻣ ﺒ ﺤ ﺚ ﻣ ﻬ ﻤ ﯿ ﺴ ﺖ‪ .‬ﺑ ﻪ ﻧ ﻈ ﺮ ﺷ ﻤ ﺎ ﭼ ﺎ ﺑ ﮑ ﯽ ﭼ ﯿ ﺴ ﺖ ؟‬

‫ﺑﯿﺸﺘﺮ اﻓﺮاد‪ ،‬ﺑﻪوﯾﮋه ﮐﺴﺎﻧﯽ ﮐﻪ در ﺣﻮزه ﭼﺎﺑﮑﯽ ﮐﺎر ﻣﯽﮐﻨﻨﺪ‪ ،‬ﭘﺎﺳﺦ درﺧﻮری ﺑﺮای اﯾﻦ ﭘﺮﺳﺶ ﻧﺪارﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﻬﺘﺮ‬
‫اﺳﺖ ﭘﯿﺶ از اداﻣﻪ دادن ﻣﺒﺤﺚ ﮐﻤﯽ ﻣﻌﻨﺎی واﻗﻌﯽ ﭼﺎﺑﮑﯽ را ﺑﺮرﺳﯽ ﮐﻨﯿﻢ‪.‬‬

‫‪ .1.11.1.2‬ﻣﺘﻌﯿﻦ ﯾﺎ ﺗﻄﺒﯿﻘﯽ‬

‫دو راه ﮐﻠﯽ ﺑﺮای ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﭘﺮوژه وﺟﻮد دارد‪ ،‬ﻣﺘﻌﯿﻦ )‪ (predictive‬و ﺗﻄﺒﯿﻘﯽ )‪:(adaptive‬‬

‫در روش ﻣﺘﻌﯿﻦ‪ ،‬در آﻏﺎز ﭘﺮوژه ﺑﻪ ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎ ﻣﯽاﻧﺪﯾﺸﯿﻢ‪ ،‬ﻣﺤﺼﻮل را ﺑﻪدﻗﺖ ﻃﺮاﺣﯽ ﻣﯽﮐﻨﯿﻢ و ﺳﭙﺲ آن را‬
‫ﻣﯽﺳﺎزﯾﻢ‪ .‬ﭘﺮوژهای ﺑﺮای ﺳﺎﺧﺖ و ﻓﺮﺳﺘﺎدن ﯾﮏ ﻣﺮﯾﺦﻧﻮرد را در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪ .‬ﻣﺮﯾﺦﻧﻮرد ﺑﺎﯾﺪ در ﻣﺤﯿﻄﯽ ﮐﺎﻣﻼ‬
‫ﻣﺘﻔﺎوت ﺑﺎ ﻣﺤﯿﻂ ﻋﺎدی ﻣﺎ ﮐﺎر ﮐﻨﺪ‪ ،‬ﺑﺎ ﮔﺮاﻧﺶ‪ ،‬ﻧﻮع اﺗﻤﺴﻔﺮ و ﺑﺴﯿﺎری از ﺷﺎﺧﺺﻫﺎﯾﯽ ﮐﻪ ﻣﺎﻧﻨﺪ زﻣﯿﻦ ﻧﯿﺴﺘﻨﺪ‪.‬‬
‫ﭼﻨﯿﻦ ﭘﺮوژهای ﺑﺴﯿﺎر ﭘﺮﻫﺰﯾﻨﻪ ﻫﻢ ﻫﺴﺖ و ﻧﻤﯽﺗﻮان ﺑﺎ آزﻣﺎﯾﺶ و ﺧﻄﺎی ﻓﺮاوان ﺑﻪ ﻧﺘﯿﺠﻪ رﺳﯿﺪ‪ ،‬ﺑﻠﮑﻪ ﺑﺎﯾﺪ ﺑﺎ‬
‫ﺑﻬﺮهﻣﻨﺪی ﺑﻬﯿﻨﻪ از داﻧﺶ ﻣﻮﺟﻮد ﭘﯿﺶﺑﯿﻨﯽ ﻫﻤﻪ ﻣﺴﺎﯾﻞ را در آﻏﺎز ﮐﺮد و ﺳﭙﺲ ﻣﺤﺼﻮل را ﺳﺎﺧﺖ‪ .‬ﺑﻪﻋﻨﻮان‬
‫ﻧﻤﻮﻧﻪای ﺳﺎدهﺗﺮ‪ ،‬ﺳﺎﺧﺖ ﯾﮏ ﭘﻞ را در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪ :‬ﭼﻨﯿﻦ ﻣﺤﺼﻮﻟﯽ ﻫﻢ ﺑﺎﯾﺪ ﺑﻪ ﺷﮑﻞ ﻣﺘﻌﯿﻦ ﺳﺎﺧﺘﻪ ﺷﻮد‪.‬‬
‫در ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﮐﻪ ﺑﻪ ﺷﺪت واﺑﺴﺘﻪ ﺑﻪ ﺑﺮداﺷﺖ و ﺳﻠﯿﻘﻪ ﻣﺸﺘﺮی ﻫﺴﺘﻨﺪ ﻧﻤﯽﺗﻮان ﻣﺤﺼﻮل ﻣﻨﺎﺳﺐ را‬
‫ﭘﯿﺶﺑﯿﻨﯽ ﮐﺮد‪ ،‬ﭼﻮن رﻓﺘﺎر اﻧﺴﺎنﻫﺎ ﭘﯿﺶﺑﯿﻨﯽﻧﺎﭘﺬﯾﺮﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﻪﺟﺎی ﺷﯿﻮه ﻣﺘﻌﯿﻦ از ﺷﯿﻮه ﺗﻄﺒﯿﻘﯽ‬
‫اﺳﺘﻔﺎده ﻣﯽﮐﻨﯿﻢ‪ .‬در اﯾﻦ ﺷﯿﻮه ﺑﻪﺟﺎی اﯾﻦﮐﻪ ﻫﻤﻪﭼﯿﺰ را در آﻏﺎز ﻃﺮاﺣﯽ ﮐﻨﯿﻢ و ﺳﭙﺲ ﺑﺴﺎزﯾﻢ‪ ،‬ﺗﺮﺗﯿﺒﯽ ﻓﺮاﻫﻢ‬
‫ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﺑﺘﻮان ﺑﺨﺸﯽ ﮐﻮﭼﮏ و در ﻋﯿﻦ ﺣﺎل ﻣﻌﻨﺎدار از ﻣﺤﺼﻮل را ﺳﺎﺧﺖ و ﺑﻪ ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﯾﺎ ﮔﺰﯾﺪهﻫﺎﯾﯽ‬
‫از آنﻫﺎ اراﺋﻪ ﮐﺮد و از رﻓﺘﺎر و ﺑﺮﺧﻮردﺷﺎن ﺑﺎزﺧﻮرد ﮔﺮﻓﺖ‪ .‬ﺑﺎ ﮐﻤﮏ آن ﺑﺎزﺧﻮرد ﺣﺪس ﻣﯽزﻧﯿﻢ ﮐﻪ ﺑﻬﺘﺮﯾﻦ ﮔﺎم‬
‫ﺑﻌﺪی ﺑﺮای ﻣﺤﺼﻮل ﭼﯿﺴﺖ و ﺑﺎ آن داﻧﺶ ﻧﺴﺨﻪ ﺑﻌﺪی را ﻣﯽﺳﺎزﯾﻢ‪ .‬ﺑﻪ ﻫﻤﯿﻦ ﺗﺮﺗﯿﺐ ﭘﯿﺶ ﻣﯽروﯾﻢ ﺗﺎ ﺑﻪﺗﺪرﯾﺞ‬
‫ﺑﺮ ﭘﺎﯾﻪ آزﻣﺎﯾﺶ و ﺧﻄﺎﻫﺎی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ ﺑﻪ ﻣﺤﺼﻮﻟﯽ ﺑﺮﺳﯿﻢ ﮐﻪ ﺑﺮای ﮐﺎرﺑﺮ ﻧﻬﺎﯾﯽ ﺟﺬاب ﺑﺎﺷﺪ‪.‬‬

‫ﻧﺎم راﯾﺞ ﺑﺮای روش ﺗﻄﺒﯿﻘﯽ‪» ،‬ﭼﺎﺑﮏ« )‪ (Agile‬اﺳﺖ‪ .‬ﮐﺴﺎﻧﯽ ﮐﻪ ﺑﺎ روشﻫﺎی ﭼﺎﺑﮏ ﺳﺮ و ﮐﺎر دارﻧﺪ ﺷﯿﻮه ﻣﺘﻌﯿﻦ را‬

‫— ‪— 32‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫»آﺑﺸﺎری« )‪ (waterfall‬و »ﺳﻨﺘﯽ« ﻣﯽﻧﺎﻣﻨﺪ‪.‬‬

‫ﻫﺮﮐﺪام از اﯾﻦ دو روش ﺑﺮای ﻧﻮﻋﯽ از ﻣﺤﺼﻮل ﻣﻨﺎﺳﺐ اﺳﺖ‪ .‬از اﯾﻦ رو‪ ،‬در ﭘﻢﺑﺎک ﻫﺮدو را ﺑﻪ رﺳﻤﯿﺖ ﺷﻨﺎﺧﺘﻪاﯾﻢ و‬
‫آن را ﮔﻮﻧﻪای ﻃﺮاﺣﯽ ﮐﺮدهاﯾﻢ ﮐﻪ ﺑﺎ ﻫﺮدو ﺳﺎزﮔﺎر ﺑﺎﺷﺪ‪ .‬از اﺻﻄﻼحﻫﺎی »آﺑﺸﺎری« و »ﺳﻨﺘﯽ« ﻫﻢ ﺑﺮای اﺷﺎره ﮐﺮدن ﺑﻪ‬
‫روش ﻣﺘﻌﯿﻦ اﺳﺘﻔﺎده ﻧﻤﯽﮐﻨﯿﻢ ﭼﻮن ﺑﺎر ﻣﻌﻨﺎﯾﯽ ﻣﻨﻔﯽ دارﻧﺪ‪.‬‬

‫‪ .2.11.1.2‬ﭘﻢﺑﺎک و ﭼﺎﺑﮑﯽ‬

‫ﻧﺴﺨﻪﻫﺎی ﻧﺨﺴﺘﯿﻦ ﭘﻢﺑﺎک ﺑﺮای ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﺗﺪوﯾﻦ ﺷﺪه ﺑﻮدﻧﺪ‪ .‬ﭘﺲ از اﯾﻦﮐﻪ ﺷﯿﻮهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﭘﺬﯾﺮش‬
‫ﻫﻤﮕﺎﻧﯽ ﭘﯿﺪا ﮐﺮدﻧﺪ‪ ،‬ﺑﻪﺗﺪرﯾﺞ ﻣﻄﺎﻟﺒﯽ درﺑﺎرهﺷﺎن ﺑﻪ ﭘﻢﺑﺎک اﻓﺰوده ﺷﺪ‪ ،‬وﻟﯽ اﯾﻦ ﻣﻮارد ﻫﯿﭻﮔﺎه ﺑﺎ ﺑﺪﻧﻪ اﺻﻠﯽ ﭘﻢﺑﺎک‬
‫ﯾﮑﭙﺎرﭼﻪ ﻧﺸﺪه ﺑﻮدﻧﺪ‪ ،‬ﺑﻠﮑﻪ ﺑﻪ آن ﺗﺤﻤﯿﻞ ﺷﺪه ﺑﻮدﻧﺪ‪ .‬از آنﺟﺎﯾﯽ ﮐﻪ ﻧﺴﺨﻪ ﻫﻔﺘﻢ ﭘﻢﺑﺎک را از آﻏﺎز ﺗﺪوﯾﻦ ﮐﺮدﯾﻢ و‬
‫ﺑﻪروزرﺳﺎﻧﯽ ﻣﺤﺘﻮای ﭘﯿﺸﯿﻦ ﻧﯿﺴﺖ‪ ،‬آن را از ﺑﻨﯿﺎن ﺑﻪﮔﻮﻧﻪای ﺳﺎﺧﺘﯿﻢ ﮐﻪ ﺑﺎ ﻫﺮدو روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺳﺎزﮔﺎر‬
‫ﺑ ﺎ ﺷ ﺪ‪.‬‬

‫ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ »ﭘﻢﺑﺎک ‪ ۷‬ﭼﺎﺑﮏ ﺷﺪه اﺳﺖ«‪ ،‬ﮐﻪ ﮐﺎﻣﻼ اﺷﺘﺒﺎه اﺳﺖ‪ .‬ﭘﻢﺑﺎک ‪ ۷‬ﺑﺎ ﻫﺮدو روش ﺳﺎزﮔﺎر اﺳﺖ و‬
‫ﺣﺘﯽ ﺑﻬﺘﺮ اﺳﺖ ﺑﮕﻮﯾﯿﻢ روﯾﮑﺮدش ﺑﻪ ﻣﺴﺎﯾﻠﯿﺴﺖ ﮐﻪ ﺗﺎﺛﯿﺮ ﭼﻨﺪاﻧﯽ از ﺗﻄﺒﯿﻘﯽ ﯾﺎ ﻣﺘﻌﯿﻦ ﺑﻮدن ﻧﻤﯽﮔﯿﺮﻧﺪ‪.‬‬

‫‪ .3.11.1.2‬ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﺑﻪﻋﻨﻮان اﺻﻞ‬

‫ﺷﺎﯾﺪ ﺗﻌﺠﺐ ﮐﻨﯿﺪ ﮐﻪ ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﭘﻢﺑﺎک ﺑﺎ ﻫﺮ دو روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺗﻄﺒﯿﻘﯽ و ﻣﺘﻌﯿﻦ ﺳﺎزﮔﺎر اﺳﺖ‪ ،‬ﺑﺎز ﻫﻢ اﺻﻠﯽ‬
‫درﺑﺎره ﺗﻄﺒﯿﻖﭘﺬﯾﺮی دارد‪ .‬دﻟﯿﻠﺶ اﯾﻦ اﺳﺖ ﮐﻪ ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﺑﻪ دو ﻣﻘﻮﻟﻪ ﻗﺎﺑﻞ ﺣﻤﻞ اﺳﺖ‪:‬‬

‫ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﺑﺮای ﻣﺤﺼﻮﻟﯽ ﮐﻪ در ﭘﺮوژه ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮد‬

‫ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﺑﺮای ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‬

‫ﺑﺮﺧﯽ ﻣﺤﺼﻮلﻫﺎ را ﺑﻬﺘﺮ اﺳﺖ ﺗﻄﺒﯿﻘﯽ ﺳﺎﺧﺖ و ﺑﺮﺧﯽ را ﺑﺎﯾﺪ ﻣﺘﻌﯿﻦ ﺳﺎﺧﺖ‪ ،‬وﻟﯽ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻫﻤﯿﺸﻪ‬
‫ﺑﺎﯾﺪ ﺗﻄﺒﯿﻘﯽ ﺑﺎﺷﺪ زﯾﺮا ﺑﺎ رﻓﺘﺎرﻫﺎ و ﺑﺮداﺷﺖﻫﺎی ﭘﯿﭽﯿﺪه اﻧﺴﺎﻧﯽ ﺳﺮ و ﮐﺎر دارد‪ .‬ﻣﻮﺿﻮع واﻗﻌﯽ اﯾﻦ اﺻﻞ ﺳﯿﺴﺘﻢ‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ‪.‬‬

‫اﯾﻦ اﺻﻞ ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ ﺑﻪﺟﺎی ﺳﺎﺧﺖ ﯾﮏ ﺳﯿﺴﺘﻢ ﺗﻔﺼﯿﻠﯽ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﺳﯿﺴﺘﻤﯽ ﺳﺎده و‬
‫ﺣﺪاﻗﻠﯽ ﺑﺴﺎزﯾﺪ و ﮐﺎر را ﺑﺎ آن آﻏﺎز ﮐﻨﯿﺪ‪ .‬ﭘﺲ از آن ﺑﻪﺗﺪرﯾﺞ ﺟﺰﺋﯿﺎت ﺑﯿﺸﺘﺮ را ﺑﺮای ﺗﻄﺒﯿﻖ دادن آن ﺑﺎ ﻣﺤﯿﻄﺶ‬
‫ﺑﯿﻔﺰاﯾﯿﺪ‪.‬‬

‫‪ .12.1.2‬از ﺗﻐﯿﯿﺮﻫﺎﯾﯽ ﮐﻪ ﺑﺮای دﺳﺘﯿﺎﺑﯽ ﺑﻪ آﯾﻨﺪه دﻟﺨﻮاه ﻻزﻣﻨﺪ ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﯿﺪ‬

‫ﻓﺮض ﮐﻨﯿﺪ در ﺳﺎزﻣﺎﻧﯽ ﮐﺎر ﻣﯽﮐﻨﯿﺪ ﮐﻪ ﺑﻮدﺟﻪای ﺛﺎﺑﺖ ﺑﺮای ﺳﺎﺧﺖ ده درﻣﺎﻧﮕﺎه در ﻧﻘﺎط دوراﻓﺘﺎده دارد‪ .‬اﮔﺮ ﭘﺮوژهﻫﺎ را‬
‫ﺑﻪﺧﻮﺑﯽ ﻣﺪﯾﺮﯾﺖ ﮐﻨﯿﺪ‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ ﺑﻪ اﻧﺪازهای در ﻫﺰﯾﻨﻪﻫﺎ ﺻﺮﻓﻪﺟﻮﯾﯽ ﮐﻨﯿﺪ ﮐﻪ ﺑﻪﺟﺎی ده درﻣﺎﻧﮕﺎه‪ ،‬ﯾﺎزده درﻣﺎﻧﮕﺎه‬
‫ﺑﺴﺎزﯾﺪ‪ .‬درﻣﺎﻧﮕﺎه ﯾﺎزدﻫﻢ ﺑﻪ دﻟﯿﻞ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻣﻮﻓﻖ وﺟﻮد دارد و اﮔﺮ زﻣﺎﻧﯽ ﺟﺎن ﮐﺴﯽ را ﻧﺠﺎت دﻫﺪ‪ ،‬ﺑﺨﺸﯽ از آن‬
‫ﻣﺪﯾﻮن ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬

‫— ‪— 33‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫در ﺳﺎلﻫﺎی اﺧﯿﺮ‪ ،‬ﺑﻪ وﯾﮋه در ﺣﻮزه ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ‪ ،‬ﻫﻤﻪ ﺗﻮﺟﻪﻫﺎ ﺑﻪ ﭘﺮوژهﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ آﻧﭽﻪ در ‪ Netflix‬و ‪Spotify‬‬
‫اﻧﺠﺎم ﻣﯽﺷﻮد ﺟﻠﺐ ﺷﺪه اﺳﺖ‪ .‬اﯾﻦ ﺷﺮﮐﺖﻫﺎ ﻣﺤﺼﻮلﻫﺎﯾﯽ ﺗﻔﺮﯾﺤﯽ دارﻧﺪ ﮐﻪ ﺑﯽﮔﻤﺎن ﺟﺎﯾﮕﺎه و ارزش ﺧﻮد را دارد‪،‬‬
‫وﻟﯽ ﻧﺒﺎﯾﺪ ﻓﺮاﻣﻮش ﮐﻨﯿﻢ ﮐﻪ ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﺟﺪیﺗﺮی ﻫﻢ ﺑﺮای ﺑﻬﺒﻮد ﮐﯿﻔﯿﺖ زﻧﺪﮔﯽ‪ ،‬ﻓﺮاﻫﻢ ﮐﺮدن اﻣﮑﺎن آﻣﻮزش ﺑﺮای‬
‫ﮐﻮدﮐﺎن‪ ،‬ﯾﺎﻓﺘﻦ راﻫﮑﺎر ﺑﺮای ﺑﯿﻤﺎریﻫﺎی ﮐﺸﻨﺪه و ﻫﻤﺎﻧﻨﺪ آنﻫﺎ وﺟﻮد دارد‪ .‬ﺗﺴﺮی دادن ﮐﻮرﮐﻮراﻧﻪ روشﻫﺎی‬
‫ﺷﮑﻞﮔﺮﻓﺘﻪ در ﭘﺮوژهﻫﺎی ﻏﯿﺮﺣﺴﺎس ﺑﻪ ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﺑﺴﯿﺎر ﭘﺮرﯾﺴﮏ اﺳﺖ‪.‬‬

‫‪ .1.12.1.2‬ﺗﻐﯿﯿﺮ ﯾﺎ ﻧﺘﯿﺠﻪ‬

‫ﻫﺮ ﭘﺮوژه ﻣﺤﺼﻮل ﺗﺎزهای ﻣﯽﺳﺎزد ﯾﺎ ﻣﺤﺼﻮﻟﯽ ﮐﻪ وﺟﻮد دارد را دﮔﺮﮔﻮن ﻣﯽﮐﻨﺪ‪ .‬ﻫﺮ ﭘﺮوژه ﺗﻐﯿﯿﺮی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ اﺳﺖ‪.‬‬
‫ﺑﺎ اﯾﻦ ﺣﺎل‪ ،‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ درﺑﺎره ﺗﻐﯿﯿﺮ ﺳﺨﻦ ﻣﯽﮔﻮﯾﯿﻢ‪ ،‬ﺑﯿﺸﺘﺮ ﻣﻨﻈﻮرﻣﺎن ﻧﺘﯿﺠﻪ ﺗﻐﯿﯿﺮ اﺳﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﺳﯿﺴﺘﻤﯽ‬
‫ﺑﺮای ﻣﺪﯾﺮﯾﺖ اﺳﻨﺎد در ﺳﺎزﻣﺎﻧﺘﺎن راهاﻧﺪازی ﮐﻨﯿﺪ‪ ،‬ﺧﺮوﺟﯽ ﯾﺎ ﻣﺤﺼﻮل ﭘﺮوژه ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ اﺳﻨﺎد ﺧﻮاﻫﺪ ﺑﻮد ﮐﻪ‬
‫ﺗﻐﯿﯿﺮی در وﺿﻌﯿﺖ ﺷﺮﮐﺖ ﺑﻪ ﺷﻤﺎر ﻣﯽرود )زﻣﺎﻧﯽ اﯾﻦ ﺳﯿﺴﺘﻢ وﺟﻮد ﻧﺪاﺷﺖ و ﺗﻐﯿﯿﺮ اﯾﻦ اﺳﺖ ﮐﻪ اﮐﻨﻮن وﺟﻮد‬
‫دارد(‪ .‬ﻧﺘﯿﺠﻪ اﯾﻦ ﺗﻐﯿﯿﺮ‪ ،‬اﮔﺮ ﻫﻤﻪﭼﯿﺰ ﺑﻪﺧﻮﺑﯽ ﭘﯿﺶ ﺑﺮود‪ ،‬دﺳﺘﺮﺳﯽ آﺳﺎنﺗﺮ و ﺳﺮﯾﻊﺗﺮ ﺑﻪ اﺳﻨﺎد‪ ،‬ﮐﺎﻫﺶ اﺷﺘﺒﺎهﻫﺎ و‬
‫ﻣ ﺎ ﻧ ﻨ ﺪ آ ن ﺧ ﻮ ا ﻫ ﺪ ﺑ ﻮ د‪.‬‬

‫آﻧﭽﻪ اﻧﺘﻈﺎر دارﯾﻢ ﻧﺘﯿﺠﻪ ﻣﻄﻠﻮب اﺳﺖ و ﻧﻪ ﺗﻨﻬﺎ ﺗﻐﯿﯿﺮ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬اﯾﻦ دو ﻣﻔﻬﻮم ﻫﻤﯿﺸﻪ ﺑﺎ ﻫﻢ اﺷﺘﺒﺎه ﮔﺮﻓﺘﻪ‬
‫ﻣﯽﺷﻮﻧﺪ ﮐﻪ ﺧﻮد ﻣﻨﺸﺎ ﭼﺎﻟﺶﻫﺎی ﻓﺮاواﻧﯿﺴﺖ‪.‬‬

‫‪ .2.12.1.2‬ﻣﺪﯾﺮﯾﺖ ﻧﺘﺎﯾﺞ‬

‫در ﺑﺨﺶ ﭘﯿﺸﯿﻦ‪ ،‬دوﮔﺎﻧﮕﯽ ﺗﻐﯿﯿﺮ و ﻧﺘﯿﺠﻪ را ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪ :‬آﻧﭽﻪ واﻗﻌﺎ اﻧﺘﻈﺎر دارﯾﻢ ﻧﺘﯿﺠﻪ اﺳﺖ و ﻧﻪ ﺗﻐﯿﯿﺮ‪ .‬ﺑﯿﺸﺘﺮ‬
‫ﻣﻨﺎﺑﻌﯽ ﮐﻪ درﺑﺎره ﺗﻐﯿﯿﺮ ﺳﺨﻦ ﻣﯽﮔﻮﯾﻨﺪ درواﻗﻊ ﻣﻨﻈﻮرﺷﺎن ﻧﺘﯿﺠﻪ ﺗﻐﯿﯿﺮ اﺳﺖ و ﻧﻪ ﺧﻮد ﺗﻐﯿﯿﺮ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ ﭘﻢﺑﺎک ﻫﻢ‬
‫ﻣ ﺴ ﺘ ﺜ ﻨ ﺎ ﻧ ﯿ ﺴ ﺖ‪ .‬ﻣ ﻮ ﺿ ﻮ ع و ا ﻗ ﻌ ﯽ ا ﯾ ﻦ ا ﺻ ﻞ ﻧ ﺘ ﺎ ﯾ ﺞ ﺗ ﻐ ﯿ ﯿ ﺮ ا ﺳ ﺖ و ﻧ ﻪ ﺧ ﻮ د ﺗ ﻐ ﯿ ﯿ ﺮ‪.‬‬

‫آﻧﭽﻪ در ﭘﺮوژه ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮد ﻣﺤﺼﻮل ﯾﺎ ﺧﺮوﺟﯽ آن اﺳﺖ‪ .‬ﺧﺮوﺟﯽ ﭘﺮوژه ﭘﺘﺎﻧﺴﯿﻠﯽ ﺑﺮای اﯾﺠﺎد ﻧﺘﺎﯾﺞ دارد‪ ،‬وﻟﯽ‬
‫ﺗﺤﻘﻖ ﻧﺘﺎﯾﺞ ﻣﻌﻤﻮﻻ ﺑﻪ ﻣﺴﺎﯾﻞ ﻓﺮاواﻧﯽ‪ ،‬ﮔﺎﻫﯽ ﺑﯿﺮون ﻣﺤﺪوده ﭘﺮوژه‪ ،‬واﺑﺴﺘﻪ اﺳﺖ )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬آﻣﻮزش ﻣﻨﺎﺳﺐ ﺑﺮای‬
‫اﺳﺘﻔﺎده از ﺳﯿﺴﺘﻤﯽ ﮐﻪ در ﭘﺮوژه ﺳﺎﺧﺘﻪ ﺷﺪه اﺳﺖ(‪ .‬ﺑﺮای ﺗﺤﻘﻖ ﻧﺘﺎﯾﺞ ﻣﻌﻤﻮﻻ ﺑﺎﯾﺪ ﺑﯿﺸﺘﺮ از ﯾﮏ ﭘﺮوژه اﻧﺠﺎم داد و‬
‫ﺑﯿﺸﺘﺮ از ﯾﮏ ﺧﺮوﺟﯽ اﯾﺠﺎد ﮐﺮد‪ .‬در ﺑﺴﯿﺎری از ﻣﻮارد‪ ،‬ﯾﮑﯽ از ﭘﺮوژهﻫﺎ ﺑﻪﻣﺮاﺗﺐ ﺑﺰرگﺗﺮ از ﭘﺮوژهﻫﺎی دﯾﮕﺮ اﺳﺖ‪ ،‬در‬
‫ﺣﺪی ﮐﻪ ﭘﺮوژهﻫﺎی دﯾﮕﺮ در ﺳﺎﯾﻪ آن ﭘﺮوژه اﺻﻠﯽ ﮔﻢ ﻣﯽﺷﻮﻧﺪ و ﺧﯿﻠﯽ اوﻗﺎت ﻏﯿﺮرﺳﻤﯽ و ﺑﺪون ﭘﺮوژه ﻧﺎﻣﯿﺪه ﺷﺪن‬
‫اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ‪ .‬از آنﺟﺎﯾﯽ ﮐﻪ دﺳﺘﯿﺎﺑﯽ ﺑﻪ ﻧﺘﺎﯾﺞ واﺑﺴﺘﻪ ﺑﻪ اﻧﺠﺎم ﭼﻨﺪ ﭘﺮوژه اﺳﺖ‪ ،‬ﺗﺤﻘﻖ ﻧﺘﺎﯾﺞ ﻧﯿﺰ ﻣﻮﺿﻮع اﺻﻠﯽ‬
‫ﻣﺪﯾﺮﯾﺖ ﻃﺮح اﺳﺖ و ﻧﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪.‬‬

‫ﭘﯿﺶ از اﯾﻦ ﻣﺒﺤﺚ دﯾﮕﺮی درﺑﺎره ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه داﺷﺘﯿﻢ و اﯾﻦﮐﻪ ارزﯾﺎﺑﯽ و ﻣﺪﯾﺮﯾﺖ ارزش‪ ،‬ﻣﻨﺎﻓﻊ و ﺗﻮﺟﯿﻪﭘﺬﯾﺮی‬
‫ﭘﺮوژهﻫﺎ را ﺑﺎﯾﺪ در ﺳﻄﺢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ اﻧﺠﺎم داد و ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺮای اﯾﻦ ﮐﺎر ﮐﺎﻓﯽ ﻧﯿﺴﺖ را ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪.‬‬
‫ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺎﯾﺪ در اﯾﻦ ﻓﺮآﯾﻨﺪ ﺑﺎ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﻫﻤﮑﺎری ﮐﻨﺪ و اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﻧﯿﺰ ﺑﺎ اﯾﻦ‬
‫ﻣﻮارد آﺷﻨﺎ ﺑﺎﺷﻨﺪ و ﺧﻮد را ﻫﻤﺴﻮ ﮐﻨﻨﺪ‪ .‬ﻫﻤﺎﻧﻨﺪ اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﺮای ﺗﺤﻘﻖ ﻧﺘﺎﯾﺞ ﻧﯿﺰ وﺟﻮد دارد‪ :‬اﯾﻦ ﮐﺎر وﻇﯿﻔﻪ اﺻﻠﯽ‬
‫ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﻃﺮح اﺳﺖ‪ ،‬وﻟﯽ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺎﯾﺪ ﺑﺎ آن ﻫﻤﮑﺎری ﮐﻨﺪ و اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﻧﯿﺰ ﺑﺎﯾﺪ ﺑﺮای‬

‫— ‪— 34‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺗ ﺤ ﻘ ﻖ ﻧ ﺘ ﺎ ﯾ ﺞ ﮐ ﻮ ﺷ ﺶ ﮐ ﻨ ﻨ ﺪ‪.‬‬

‫‪ .2.2‬اﺻﻞﻫﺎی ‪NUPP‬‬

‫در ﺑﺨﺶ ﭘﯿﺶ اﺻﻞﻫﺎی ﭘﻢﺑﺎک را ﻣﺮور ﮐﺮدﯾﻢ‪ .‬ﺑﺮای ﺑﻪ دﺳﺖ آوردن دﯾﺪی ﺑﺎزﺗﺮ ﺑﻪ ﻣﻔﻬﻮم و ﺟﺎﯾﮕﺎه اﺻﻞﻫﺎ در‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬اﺻﻞﻫﺎی ﻣﻨﺒﻊ دﯾﮕﺮی ﺑﺎ ﻧﺎم ‪ NUPP‬را در اﯾﻦ ﺑﺨﺶ ﻣﺮور ﺧﻮاﻫﯿﻢ ﮐﺮد‪ NUPP .‬ﻣﺨﻔﻒ ‪Nearly‬‬
‫‪) Universal Principles of Projects‬اﺻﻞﻫﺎی ﮐﻤﺎﺑﯿﺶ ﻓﺮاﮔﯿﺮ ﭘﺮوژهﻫﺎ( و ﻣﺠﻤﻮﻋﻪای از اﺻﻞﻫﺎﺳﺖ ﮐﻪ ﮐﻤﺎﺑﯿﺶ ﺑﻪ‬
‫ﻫﻤﻪ ﭘﺮوژهﻫﺎ‪ ،‬ﻣﺴﺘﻘﻞ از ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژهﺷﺎن‪ ،‬ﻗﺎﺑﻞ ﺗﺴﺮﯾﺴﺖ‪.‬‬

‫اﯾﻦ ﻣﺠﻤﻮﻋﻪ ﻣﻨﺒﻌﯽ آزاد و راﯾﮕﺎن ﺑﻮده‪ ،‬ﺗﺮﺟﻤﻪ آن ﺑﻪ زﺑﺎنﻫﺎی ﻣﺘﻌﺪد‪ ،‬ازﺟﻤﻠﻪ ﻓﺎرﺳﯽ‪ ،‬در ‪ https://nupp.guide‬وﺟﻮد‬
‫دارد‪.‬‬

‫اﺻﻞﻫﺎی ‪ NUPP‬از اﯾﻦ ﻗﺮارﻧﺪ‪:‬‬

‫‪ .1‬ﺣﻘﯿﻘﺖ و ﻧﺘﺎﯾﺞ را ﺑﺮ ﺗﻌﺼﺐﻫﺎ و واﺑﺴﺘﮕﯽﻫﺎی ﺷﺨﺼﯽ ﺗﺮﺟﯿﺢ دﻫﯿﺪ‪.‬‬

‫‪ .2‬از ﺗﻮان و ﻣﻨﺎﺑﻊ ﺑﻬﯿﻨﻪ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬
‫‪ .3‬ﻫﻤﯿﺸﻪ ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ رﻓﺘﺎر ﮐﻨﯿﺪ‪.‬‬
‫‪ .4‬ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻗﺪرت ﻫﺮ زﻧﺠﯿﺮ ﺑﻪ اﻧﺪازه ﻗﺪرت ﺿﻌﯿﻒﺗﺮﯾﻦ ﺣﻠﻘﻪاش اﺳﺖ‪.‬‬
‫‪ .5‬ﻫﯿﭻ ﮐﺎری را ﺑﺪون ﻫﺪف ﻣﺸﺨﺺ اﻧﺠﺎم ﻧﺪﻫﯿﺪ‪.‬‬
‫‪ .6‬از ﻋﻨﺎﺻﺮ ﺗﮑﺮارﭘﺬﯾﺮ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫در اداﻣﻪ ﻧﮕﺎﻫﯽ ﮐﻮﺗﺎﻫﯽ ﺑﻪ ﻫﺮﯾﮏ از اﯾﻦ اﺻﻞﻫﺎ ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫‪ .1.2.2‬ﺣﻘﯿﻘﺖ و ﻧﺘﺎﯾﺞ را ﺑﺮ ﺗﻌﺼﺐﻫﺎ و واﺑﺴﺘﮕﯽﻫﺎی ﺷﺨﺼﯽ ﺗﺮﺟﯿﺢ دﻫﯿﺪ‬

‫ﺑﺮﺧﯽ ﺣﯿﻮاﻧﺎت ﻣﯽﺗﻮاﻧﻨﺪ ﺑﻪﺗﻨﻬﺎﯾﯽ زﻧﺪﮔﯽ ﮐﻨﻨﺪ‪ ،‬وﻟﯽ ﺑﺮﺧﯽ دﯾﮕﺮ‪ ،‬ﻣﺎﻧﻨﺪ اﻧﺴﺎنﻫﺎ‪ ،‬ﻧﻤﯽﺗﻮاﻧﻨﺪ ﺑﻪﺗﻨﻬﺎﯾﯽ از ﭘﺲ ﻧﯿﺎزﻫﺎی‬
‫زﻧﺪﮔﯽ ﺑﺮآﯾﻨﺪ و ﻧﯿﺎز دارﻧﺪ ﮐﻪ در ﮔﺮوﻫﯽ از ﻣﻮﺟﻮدات ﻫﻤﺎﻧﻨﺪ ﺧﻮد ﺑﺎﺷﻨﺪ‪ .‬اﻧﺴﺎنﻫﺎی ﻧﺨﺴﺘﯿﻨﯽ ﮐﻪ ﮔﺮاﯾﺶ ﮐﻤﺘﺮی ﺑﻪ‬
‫ﺗﻌﻠﻖ در ﮔﺮوهﻫﺎ داﺷﺘﻨﺪ ﺷﺎﻧﺲ ﺑﻘﺎی ﮐﻤﺘﺮی داﺷﺘﻨﺪ و آنﻫﺎﯾﯽ ﮐﻪ ﺑﻪ زﻧﺪﮔﯽ ﺧﻮد اداﻣﻪ دادﻧﺪ و ﺗﻮﻟﯿﺪﻣﺜﻞ ﺑﯿﺸﺘﺮی‬
‫ﮐﺮدﻧﺪ اﯾﻦ ﮔﺮاﯾﺶ را ﺑﻪ ﻧﺴﻞﻫﺎی ﺑﻌﺪی ﺧﻮد ﻣﻨﺘﻘﻞ ﮐﺮدﻧﺪ‪ .‬اﯾﻦ اﻧﺘﺨﺎب ﻃﺒﯿﻌﯽ ﺑﺎﻋﺚ ﺷﺪه اﺳﺖ ﮐﻪ ﮔﻮﻧﻪ اﻧﺴﺎﻧﯽ‬
‫ﺣﺴﯽ ﻗﻮی ﺑﺮای ﺗﻌﻠﻖ ﺑﻪ ﮔﺮوهﻫﺎی ﻣﺨﺘﻠﻒ داﺷﺘﻪ ﺑﺎﺷﺪ و ﺗﺮد ﺷﺪن را ﺑﻪﻣﺜﺎﺑﻪ ﻣﺮگ ﺑﭙﻨﺪارد‪.‬‬

‫اﯾﻦ ﻣﻮرد‪ ،‬ﻣﺎﻧﻨﺪ ﻫﺮ ﮔﺮاﯾﺶ ﻃﺒﯿﻌﯽ دﯾﮕﺮی‪ ،‬از ﻣﺤﺪوده ﺧﻮد ﻓﺮاﺗﺮ ﻣﯽرود و ﺑﺎﻋﺚ ﻣﯽﺷﻮد اﻧﺴﺎنﻫﺎ ارزشﻫﺎی ﻓﺮاواﻧﯽ‬
‫را ﻗﺮﺑﺎﻧﯽ ﻋﻀﻮﯾﺖ در ﮔﺮوهﻫﺎ ﮐﻨﻨﺪ‪ .‬در ﺑﺴﯿﺎری از اﯾﻦ ﻣﻮارد‪ ،‬آﻧﭽﻪ ﻓﺮد از ﺗﻌﻠﻖ ﺷﺪﯾﺪ ﺑﻪ ﮔﺮوه ﺑﻪ دﺳﺖ ﻣﯽآورد ﺑﺴﯿﺎر‬
‫ﮐﻤﺘﺮ از آن اﺳﺖ ﮐﻪ ﻗﺮﺑﺎﻧﯽ ﻣﯽﮐﻨﺪ‪.‬‬

‫اﯾﻦ ﮔﺮاﯾﺶ دروﻧﯽ در ﺣﻮزه ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﮐﻪ اﻓﺮاد ﺧﻮد را واﺑﺴﺘﻪ ﺑﻪ ﮔﺮوﻫﯽ ﺑﺪاﻧﻨﺪ ﮐﻪ از روﺷﯽ‬
‫وﯾﮋهای ﺑﺮای اﺟﺮای ﭘﺮوژه اﺳﺘﻔﺎده ﻣﯽﮐﻨﺪ و ﺑﻪﺗﺪرﯾﺞ آن را ﺗﺒﺪﯾﻞ ﺑﻪ ﺗﻌﺼﺐ و دﺷﻤﻦﺗﺮاﺷﯽ ﮐﻨﻨﺪ‪ .‬ﻣﺪﯾﺮ ﭘﺮوژهای ﮐﻪ‬
‫ﺧﻮد را وارد ﭼﻨﯿﻦ ﺑﺎزیﻫﺎی اﯾﺪﺋﻮﻟﻮژﯾﮑﯽای ﻧﮑﻨﺪ و اﻧﺪﯾﺸﻪاش را ﺑﻪ روی ﻫﻤﻪ ﻣﻨﺎﺑﻊ و اﯾﺪهﻫﺎ ﺑﺎز ﺑﮕﺬارد‪ ،‬از آنﻫﺎ‬

‫— ‪— 35‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﯿﺎﻣﻮزد و در ﻫﺮ ﺷﺮاﯾﻄﯽ ﺑﺴﺘﻪ ﺑﻪ ﻧﯿﺎز از آﻣﻮﺧﺘﻪﻫﺎی ﺧﻮد ﺑﻬﺮه ﮔﯿﺮد‪ ،‬ﺑﻪﻣﺮاﺗﺐ ﻣﻮﻓﻖﺗﺮ ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬

‫‪ .2.2.2‬از ﺗﻮان و ﻣﻨﺎﺑﻊ ﺑﻪ ﺷﮑﻞ ﺑﻬﯿﻨﻪ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‬

‫ﻫﻤﺎﻧﻨﺪ ﻣﻨﺎﺑﻊ ﭘﺮوژه ﮐﻪ ﻣﺤﺪودﻧﺪ‪ ،‬ﺗﻮان اﻧﺪﯾﺸﯿﺪﻧﻤﺎن ﻫﻢ ﻣﺤﺪود اﺳﺖ‪ .‬ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ ﮐﻮﺷﺶ ﻣﯽﮐﻨﯿﻢ از ﻣﻨﺎﺑﻊ ﭘﺮوژه‬
‫ﺑﻬﯿﻨﻪ اﺳﺘﻔﺎده ﮐﻨﯿﻢ‪ ،‬ﺑﺎﯾﺪ ﻣﺮاﻗﺐ اﺳﺘﻔﺎده از ﺗﻮان اﻧﺪﯾﺸﯿﺪﻧﻤﺎن ﻫﻢ ﺑﺎﺷﯿﻢ‪ .‬در ﻧﻘﺶ ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﯾﺪ ﺑﻪ اﻋﻀﺎی ﺗﯿﻢ‬
‫ﭘﺮوژه ﻧﯿﺰ ﮐﻤﮏ ﮐﻨﯿﺪ ﺗﺎ از ﺗﻮان ذﻫﻨﯽ ﺧﻮد ﺑﻬﯿﻨﻪ اﺳﺘﻔﺎده ﮐﻨﻨﺪ‪.‬‬

‫اﮔﺮ ﺧﻮد را درﮔﯿﺮ رﯾﺰهﮐﺎریﻫﺎی ﭘﺮوژه و ﺟﻨﺒﻪﻫﺎی ﻓﻨﯽ ﮐﻨﯿﺪ‪ ،‬ﺑﺨﺸﯽ از ﺗﻮان اﻧﺪﯾﺸﯿﺪﻧﺘﺎن ﺻﺮف ﺧﻮاﻫﺪ ﺷﺪ و ﺗﻮان‬
‫ﮐﻤﺘﺮی ﺑﺮای وﻇﺎﯾﻒ واﻗﻌﯿﺘﺎن ﺑﺎﻗﯽ ﻣﯽﻣﺎﻧﺪ‪ .‬اﻟﺒﺘﻪ ﺑﻪ ﺟﺰ آن دﺷﻮاریﻫﺎی دﯾﮕﺮی ﻫﻢ اﯾﺠﺎد ﻣﯽﺷﻮد ﮐﻪ ﭘﯿﺶ از اﯾﻦ‬
‫ﺑﺮرﺳﯿﺸﺎن ﮐﺮدﯾﻢ‪ .‬ﻓﺮض ﮐﻨﯿﺪ ﺗﻮان اﻧﺪﯾﺸﯿﺪﻧﺘﺎن ﻣﺒﻠﻎ ﻣﺤﺪودﯾﺴﺖ و ﺑﺮآﻧﯿﺪ ﮐﻪ آن را در ﺑﻬﺘﺮﯾﻦ ﺣﻮزهﻫﺎ‬
‫ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﻨﯿﺪ‪.‬‬

‫آﯾﺎ ﻗﺎﻋﺪه ‪ ۸۰/۲۰‬را ﻣﯽﺷﻨﺎﺳﯿﺪ؟ ﺑﺮ ﭘﺎﯾﻪ اﯾﻦ ﻗﺎﻋﺪه‪ ،‬ﺣﺪود ‪ ۸۰‬درﺻﺪ ﻣﻨﺎﻓﻊ ﺑﺴﯿﺎری از داﻣﻨﻪﻫﺎ ﺑﺎ ﺣﺪود ‪ ۲۰‬درﺻﺪ‬
‫ﻋﻨﺎﺻﺮش ﺑﻪ وﺟﻮد ﻣﯽآﯾﻨﺪ‪ .‬ﺑﻪ آﻧﭽﻪ ﺷﺨﺼﺎ در ﭘﺮوژهﻫﺎ اﻧﺠﺎم ﻣﯽدﻫﯿﺪ ﺑﯿﻨﺪﯾﺸﯿﺪ‪ :‬اﺣﺘﻤﺎﻻ ﺣﺪود ‪ ۸۰‬درﺻﺪ ﻧﺘﺎﯾﺞ‬
‫ﻣﻨﺎﺳﺒﯽ ﮐﻪ ﻣﯽﮔﯿﺮﯾﺪ ﺑﺎ ‪ ۲۰‬درﺻﺪ از ﮐﺎرﻫﺎﯾﯽ ﮐﻪ ﮐﺮدهاﯾﺪ ﺑﻪ دﺳﺖ آﻣﺪهاﻧﺪ‪ .‬ﺑﻨﺎ ﺑﺮ اﯾﻦ‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ در ﻓﻌﺎﻟﯿﺖﻫﺎی‬
‫ﺧﻮد ﺑﺎزﺑﯿﻨﯽ ﮐﻨﯿﺪ و ﺑﺎ ﺣﺬف ﺑﺮﺧﯽ از آنﻫﺎ ﮐﻪ ﻧﺘﯿﺠﻪ ﭼﻨﺪاﻧﯽ در ﺑﺮ ﻧﺪارﻧﺪ‪ ،‬ﻋﻨﺎﺻﺮ ﭘﺮﺑﺎر را ﺗﻘﻮﯾﺖ ﮐﻨﯿﺪ‪.‬‬

‫ﻗﺎﻋﺪه ‪ ۸۰/۲۰‬ﯾﮑﯽ از راﻫﻨﻤﺎﻫﺎی ﺗﺪوﯾﻦ ﻣﺘﺪوﻟﻮژی ‪ P3.express‬ﻫﻢ ﺑﻮده اﺳﺖ‪ .‬ﺑﻪﺟﺎی ﻫﺪف ﻗﺮار دادن ‪ ۱۰۰‬درﺻﺪ‬
‫ﻣﻨﺎﻓﻊ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺳﺎﺧﺖﯾﺎﻓﺘﻪ ﺑﺎ ‪ ۱۰۰‬درﺻﺪ ﮐﻮﺷﺶ‪ ،‬ﺳﯿﺴﺘﻤﯽ ﺳﺎﺧﺘﻪ ﺷﺪه اﺳﺖ ﮐﻪ ﺑﺎ ﮐﻤﮏ آن ﺑﺘﻮاﻧﯿﺪ ‪ ۸۰‬درﺻﺪ‬
‫ﻣﻨﺎﻓﻊ را ﺑﺎ ﺻﺮف ‪ ۲۰‬درﺻﺪ ﮐﻮﺷﺶ ﺑﻪ دﺳﺖ آورﯾﺪ‪ .‬از اﯾﻦ روﺳﺖ ﮐﻪ اﺳﺘﻔﺎده از ‪ P3.express‬ﺑﺴﯿﺎر ﺳﺎدهﺗﺮ از‬
‫ﺑ ﺴ ﯿ ﺎ ر ی ﻣ ﺘ ﺪ وﻟ ﻮ ژ ی ﻫ ﺎ ی د ﯾ ﮕ ﺮ ا ﺳ ﺖ‪.‬‬

‫‪ .3.2.2‬ﻫﻤﯿﺸﻪ ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ رﻓﺘﺎر ﮐﻨﯿﺪ‬

‫ﻣﺎ روزاﻧﻪ ﺑﺎ ﻣﺴﺎﯾﻞ ﻓﺮاواﻧﯽ ﺳﺮ و ﮐﺎر دارﯾﻢ و ﻫﯿﭻﮐﺲ ﺗﻮان ﺑﺎﯾﺴﺘﻪ ﺑﺮای واﮐﻨﺶ ﻧﺸﺎن دادن ﺑﻪ ﻫﻤﻪ آنﻫﺎ ﻧﺪارد‪ .‬در‬
‫ﻋﻤﻞ ﺑﺎ ﺑﺴﯿﺎری از ﻣﺴﺎﯾﻞ اﻃﺮاف ﺧﻮد اﻧﻔﻌﺎﻟﯽ ﺑﺮﺧﻮرد ﻣﯽﮐﻨﯿﻢ‪ ،‬ﯾﻌﻨﯽ ﮐﺎری در ﺑﺮاﺑﺮ آنﻫﺎ ﻧﻤﯽﮐﻨﯿﻢ‪ ،‬ﻣﮕﺮ اﯾﻦﮐﻪ ﺑﻪ‬
‫درﺟﻪای ﺑﺮﺳﻨﺪ ﮐﻪ ﻧﯿﺎز ﺑﻪ ﭘﺎدرﻣﯿﺎﻧﯽ ﻣﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬اﯾﻦ ﺑﺮﺧﻮرد ﻃﺒﯿﻌﯿﺴﺖ و ﺗﻨﻬﺎ راﻫﮑﺎر ﺑﺮای زﻧﺪﮔﯽ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪،‬‬
‫ﻣﺎﻧﻨﺪ ﻫﻤﯿﺸﻪ‪ ،‬ذﻫﻨﻤﺎن آن را ﺑﻪ ﻫﻤﻪ ﻣﺴﺎﯾﻞ ﺗﺴﺮی ﻣﯽدﻫﺪ و در ﭘﺮوژهﻫﺎ ﻧﯿﺰ اﯾﻦﭼﻨﯿﻦ ﺑﺮﺧﻮرد ﻣﯽﮐﻨﯿﻢ‪ ،‬وﻟﯽ وﻗﺘﯽ‬
‫ﻣﺪﯾﺮﯾﺖ ﻣﻮﺿﻮﻋﯽ ﺑﺮ دوش ﻣﺎ ﺑﺎﺷﺪ ﺑﺎﯾﺪ ﺑﺎ آن ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ ﺑﺮﺧﻮرد ﮐﻨﯿﻢ‪.‬‬

‫ﺑﺮﺧﻮرد ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ اﻟﺰاﻣﺎ ﺑﻪ ﻣﻌﻨﯽ اﻗﺪام ﮐﺮدن ﻧﯿﺴﺖ‪ .‬ﺑﺮﺧﻮرد ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ اﯾﻦ اﺳﺖ ﮐﻪ ﻫﺮﮔﺎه ﺑﺎ ﻣﺴﺌﻠﻪای روﺑﺮو‬
‫ﻣﯽﺷﻮﯾﺪ ﺑﻪﺟﺎی اﯾﻦﮐﻪ از آن ﭼﺸﻢﭘﻮﺷﯽ ﮐﻨﯿﺪ‪ ،‬ﺑﻪ آن ﺑﯿﻨﺪﯾﺸﯿﺪ و ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮﯾﺪ ﮐﻪ اﻗﺪاﻣﯽ ﻧﯿﺎز دارد ﯾﺎ ﻧﻪ‪ .‬ﻣﺪﯾﺮﯾﺖ‬
‫رﯾﺴﮏ ﻧﻤﻮﻧﻪای از ﺑﺮﺧﻮرد ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ در ﭘﺮوژه اﺳﺖ‪.‬‬

‫اﯾﻦ اﺻﻞ ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ در ﻫﻤﻪ ﮐﺎرﻫﺎﯾﯽ ﮐﻪ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﻧﺠﺎم ﻣﯽدﻫﯿﺪ ﻏﯿﺮاﻧﻔﻌﺎﻟﯽ ﺑﺮﺧﻮرد ﮐﻨﯿﺪ‪.‬‬

‫‪ .4.2.2‬ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻗﺪرت ﻫﺮ زﻧﺠﯿﺮ ﺑﻪ اﻧﺪازه ﻗﺪرت ﺿﻌﯿﻒﺗﺮﯾﻦ‬

‫— ‪— 36‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺣﻠ ﻘ ﻪا ش ا ﺳ ﺖ‬

‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺟﻨﺒﻪﻫﺎی ﻓﺮاواﻧﯽ دارد ﮐﻪ دﺳﺖ ﺑﻪ دﺳﺖ ﻫﻢ ﮐﺎر ﻣﯽﮐﻨﻨﺪ‪ .‬اﮔﺮ ﻓﻘﻂ ﯾﮑﯽ از اﯾﻦ ﺟﻨﺒﻪﻫﺎ ﻧﺎدﯾﺪه ﮔﺮﻓﺘﻪ‬
‫ﺷﻮد‪ ،‬ﺟﻨﺒﻪﻫﺎی دﯾﮕﺮ ﻧﯿﺰ ﮐﺎراﯾﯽ ﺧﻮد را از دﺳﺖ ﻣﯽدﻫﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﺎﯾﺪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژهﺗﺎن ﻫﻤﻪﺟﺎﻧﺒﻪ ﺑﺎﺷﺪ و ﻧﻪ‬
‫ﻣﺤﺪود ﺑﻪ ﯾﮏ ﯾﺎ ﭼﻨﺪ ﺟﻨﺒﻪ ﺑﻪ ﻇﺎﻫﺮ ﻣﻬﻢﺗﺮ ﻣﺎﻧﻨﺪ زﻣﺎنﺑﻨﺪی‪.‬‬

‫در ﻓﺼﻞ آﯾﻨﺪه‪ ،‬ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی )‪ (performance domains‬ﭘﻢﺑﺎک را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﻧﻮﻋﯽ دﺳﺘﻪﺑﻨﺪی از‬
‫اﻧﻮاع ﺟﻨﺒﻪﻫﺎﯾﯿﺴﺖ ﮐﻪ ﺑﺎﯾﺪ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻟﺤﺎظ ﺷﻮد‪:‬‬

‫ذ یﻧ ﻔ ﻌﺎ ن‬
‫ﺗﯿ ﻢ‬
‫ﭼﺮﺧﻪ ﺣﯿﺎت و ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی‬
‫اﺟﺮا‬
‫ارزﯾﺎﺑ ﯽ‬
‫ﺗ ﺤ ﻮﯾ ﻞ‬
‫ﻋ ﺪ م ﻗ ﻄ ﻌﯿ ﺖ‬

‫زاوﯾﻪ دﯾﺪﻫﺎی ﮔﻮﻧﺎﮔﻮﻧﯽ ﺑﺮای دﺳﺘﻪﺑﻨﺪی ﺣﻮزهﻫﺎ وﺟﻮد دارد و ﺑﻬﺘﺮ اﺳﺖ ﻣﺴﺌﻠﻪ را از ﭼﻨﺪ زاوﯾﻪ ﺑﺒﯿﻨﯿﺪ ﺗﺎ ﻧﻘﺎط ﮐﻮر‬
‫ﺑﺮاﯾﺘﺎن ﻣﺸﺨﺺ ﺷﻮﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﯾﺰو ‪ ۲۱۵۰۰‬و ﻧﺴﺨﻪﻫﺎی ﭘﯿﺸﯿﻦ ﭘﻢﺑﺎک ﭼﻨﯿﻦ دﺳﺘﻪﺑﻨﺪیای دارﻧﺪ‪:‬‬

‫ﯾ ﮑﭙﺎ ر ﭼ ﮕ ﯽ‬
‫ﮔﺴﺘﺮه‬
‫زﻣﺎن‬
‫ﻫ ﺰﯾﻨ ﻪ‬
‫ﮐﯿ ﻔﯿ ﺖ‬
‫ﻣﻨﺎﺑ ﻊ‬
‫ارﺗﺒﺎﻃﺎت‬
‫رﯾ ﺴ ﮏ‬
‫ﺗﺪارﮐﺎت‬
‫ذ یﻧ ﻔ ﻌﺎ ن‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬ﭼﻨﯿﻦ دﺳﺘﻪﺑﻨﺪیای دارد‪:‬‬

‫ﺗ ﻮ ﺟﯿ ﻪﭘ ﺬﯾ ﺮ ی‬
‫ﺳﺎزﻣﺎندﻫﯽ‬
‫ﮐﯿ ﻔﯿ ﺖ‬
‫ﺑﺮﻧﺎﻣﻪ‬
‫رﯾ ﺴ ﮏ‬

‫— ‪— 37‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺗ ﻐﯿﯿ ﺮ‬
‫ﭘﯿﺸﺮﻓﺖ‬

‫راﻫﻨﻤﺎی ‪ APMbok‬ﻣﺴﺎﯾﻞ را اﯾﻦﮔﻮﻧﻪ ﺗﻘﺴﯿﻢﺑﻨﺪی ﻣﯽﮐﻨﺪ‪:‬‬

‫ﻣ ﺴﺎﯾ ﻞ اﻧ ﺴﺎﻧ ﯽ‬
‫ﻣﺴﺎﯾﻞ ﻣﺮﺑﻮط ﺑﻪ ﺗﻮﻟﯿﺪ و ﺗﺤﻮﯾﻞ‬
‫ﯾ ﮑﭙﺎ ر ﭼ ﮕ ﯽ‬
‫ﮔﺴﺘﺮه‬
‫زﻣﺎن‬
‫ﻫ ﺰﯾﻨ ﻪ‬
‫رﯾ ﺴ ﮏ‬
‫ﮐﯿ ﻔﯿ ﺖ‬
‫ﻣﻨﺎﺑ ﻊ‬
‫ارﺗﺒﺎط ﺑﺎ ﺳﺎﯾﺮ ﻻﯾﻪﻫﺎ‬
‫ﺣ ﺴﺎﺑ ﺪا ر ی‬
‫اﯾ ﻤﻨ ﯽ و ﺳ ﻼ ﻣ ﺖ‬
‫ﻣﻨﺎﺑ ﻊ اﻧ ﺴﺎﻧ ﯽ‬
‫ﻗﺎﻧ ﻮ ن‬
‫ا ﻣﻨﯿ ﺖ‬
‫ﭘﺎﯾ ﺪا ر ی‬

‫آﯾﺎ ﺑﻪ ﻫﻤﻪ اﯾﻦ ﺟﻮاﻧﺐ در ﭘﺮوژهﻫﺎی ﺧﻮد ﺗﻮﺟﻪ ﻣﯽﮐﻨﯿﺪ؟‬

‫‪ .5.2.2‬ﻫﯿﭻ ﮐﺎری را ﺑﺪون ﻫﺪف ﻣﺸﺨﺺ اﻧﺠﺎم ﻧﺪﻫﯿﺪ‬

‫ﻫﺮ ﮐﺎری ﮐﻪ در ﭘﺮوژه اﻧﺠﺎم ﻣﯽدﻫﯿﺪ ﺑﺎﯾﺪ ﻫﺪﻓﯽ ﺗﻮﺟﯿﻪﭘﺬﯾﺮ داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬اﯾﻦﮐﻪ دﯾﮕﺮان ﮐﺎری را اﻧﺠﺎم ﻣﯽدﻫﻨﺪ دﻟﯿﻠﯽ‬
‫ﺑﺮای اﻧﺠﺎﻣﺶ ﻧﯿﺴﺖ‪ .‬اﮔﺮ ﻣﻨﺎﺑﻌﯽ ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک ﯾﺎ ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه آنﻫﺎ را ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﻨﺪ ﻧﯿﺰ دﻟﯿﻠﯽ‬
‫ﺑﺮای اﻧﺠﺎﻣﺸﺎن ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﺑﺎﯾﺪ ﺑﺎ ﻣﻄﺎﻟﻌﻪ دﻗﯿﻖ آن ﻣﻨﺎﺑﻊ درک ﮐﻨﯿﺪ ﮐﻪ ﭼﺮا آن اﻗﺪام ﭘﯿﺸﻨﻬﺎد ﺷﺪه اﺳﺖ و آن را‬
‫ﻫ ﺪ ﻓ ﻤ ﻨ ﺪ ا ﻧ ﺠ ﺎ م د ﻫ ﯿ ﺪ‪.‬‬

‫در زﻣﺎن ﺗﺼﻤﯿﻢﮔﯿﺮی ﭼﻨﯿﻦ روﻧﺪی را ﻃﯽ ﮐﻨﯿﺪ‪ :‬دو ﺟﻬﺎن ﻣﻮازی ﺗﺠﺴﻢ ﮐﻨﯿﺪ ﮐﻪ ﻓﻘﻂ در ﯾﮑﯽ از آنﻫﺎ اﻗﺪام ﻣﺪﻧﻈﺮ را‬
‫اﻧﺠﺎم ﻣﯽدﻫﯿﺪ‪ .‬ﺑﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ ﺗﻮﺿﯿﺢ دﻫﯿﺪ ﮐﻪ ﻧﺘﺎﯾﺞ ﭘﺮوژه ﺑﻪ ﭼﻪ ﺷﮑﻞ در اﯾﻦ دو ﺟﻬﺎن ﻣﻮازی ﻣﺘﻔﺎوت ﺧﻮاﻫﻨﺪ ﺑﻮد‪.‬‬
‫ﭘ ﺲ ا ز آ ن ‪ ،‬ﺑ ﻪ اﯾ ﻦ ﺑﯿﻨ ﺪﯾ ﺸﯿ ﺪ ﮐ ﻪ ﻧﺘﯿ ﺠ ﻪ ﻣﺜﺒﺘ ﯽ ﮐ ﻪ د ر ﯾ ﮑ ﯽ ا ز اﯾ ﻦ د و ﺟ ﻬﺎ ن ﺑ ﻪ د ﺳ ﺖ ﻣ ﯽآﯾ ﺪ ﺗ ﻮ ﺟﯿ ﻪ ﮐﻨﻨ ﺪ ه ﮐﺎ ر ا ﺿﺎ ﻓ ﻪا ی‬
‫ﮐﻪ ﻗﺮار اﺳﺖ اﻧﺠﺎم دﻫﯿﺪ ﻫﺴﺖ ﯾﺎ ﺧﯿﺮ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﭘﺮﯾﻨﺲ‪ ۲‬ﮔﺰارﺷﯽ ﺑﺎ ﻧﺎم ‪ highlights report‬دارد‪ .‬ﻣﯽﺗﻮاﻧﯿﺪ ﺑﺎ ﮐﻤﯽ ﺟﺴﺘﺠﻮ در اﯾﻨﺘﺮﻧﺖ ﺗﻤﭙﻠﯿﺖﻫﺎﯾﯽ‬
‫ﺑﺮاﯾﺶ ﺑﯿﺎﺑﯿﺪ‪ ،‬آنﻫﺎ را ﭘﺮ ﮐﺮده‪ ،‬ﺑﺮای ﮔﯿﺮﻧﺪﮔﺎن ﺑﻔﺮﺳﺘﯿﺪ‪ .‬اﯾﻦ ﮐﺎر ﻧﻤﻮﻧﻪای از ﺑﺎرﭘﺮﺳﺘﯽ اﺳﺖ ﮐﻪ در آﻏﺎز ﮐﺘﺎب ﺑﺮرﺳﯽ‬

‫— ‪— 38‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﮐﺮدﯾﻢ‪ .‬راه درﺳﺖ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎ ﻣﻄﺎﻟﻌﻪ ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﯿﺎﻣﻮزﯾﺪ ﮐﻪ اﯾﻦ ﮔﺰارش ﭼﻪ ﻫﺪﻓﯽ دارد و ﭼﮕﻮﻧﻪ ﺑﺎ دﯾﮕﺮ ﻋﻨﺎﺻﺮ‬
‫ﯾﮑﭙﺎرﭼﻪ ﻣﯽﺷﻮد‪ .‬ﺳﭙﺲ‪ ،‬ﺑﺪون ﻧﯿﺎز ﺑﻪ ﺗﻤﭙﻠﯿﺖ‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﮔﺰارش ﻣﻨﺎﺳﺒﯽ آﻣﺎده ﮐﻨﯿﺪ ﮐﻪ اﻫﺪاف را ﻣﺤﻘﻖ ﮐﻨﺪ‪.‬‬

‫‪ .6.2.2‬از ﻋﻨﺎﺻﺮ ﺗﮑﺮارﭘﺬﯾﺮ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‬

‫اﮔﺮ ﻫﺮ ﺑﺎر ﮐﻪ ﻗﺮار اﺳﺖ ﮐﺎری اﻧﺠﺎم دﻫﯿﺪ روﻧﺪ آن را دوﺑﺎره ﮐﺸﻒ و ﺗﺪوﯾﻦ ﮐﻨﯿﺪ‪ ،‬اﻧﺮژی ﻓﺮاواﻧﯽ ﻻزم ﺧﻮاﻫﺪ ﺑﻮد و‬
‫اﺣﺘﻤﺎل اﺷﺘﺒﺎه ﻧﯿﺰ ﺑﺎﻻ ﻣﯽرود‪ .‬ﺑﻪ ﺟﺎی آن ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﺟﻨﺒﻪﻫﺎی ﻣﺸﺘﺮک ﮐﺎرﻫﺎ را ﺑﺎ ﻋﻨﺎﺻﺮ ﺗﮑﺮارﭘﺬﯾﺮ ﻣﺴﺘﻨﺪ ﮐﺮده‪،‬‬
‫ﺑ ﻪ ﺗ ﺪ ر ﯾ ﺞ ﺑ ﻬ ﺒ ﻮ د د ﻫ ﯿ ﺪ‪.‬‬

‫ﻧﻤﻮﻧﻪ ﺧﻮﺑﯽ ﺑﺮای ﻋﻨﺎﺻﺮ ﺗﮑﺮارﭘﺬﯾﺮ‪ ،‬ﭼﮏﻟﯿﺴﺖ اﺳﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﻗﺮار اﺳﺖ اﺳﻨﺎد ﻣﻬﻨﺪﺳﯽ ﻓﺮاواﻧﯽ در ﺷﺮﮐﺖ‬
‫ارزﯾﺎﺑﯽ ﺷﻮﻧﺪ‪ ،‬ﻫﺮآﻧﭽﻪ ﺑﺎﯾﺪ ﭼﮏ ﺷﻮد را در ﭼﮏﻟﯿﺴﺘﯽ ﻣﺴﺘﻨﺪ ﮐﻨﯿﺪ و ﻫﺮ ﺑﺎر ﮐﻪ ﻓﺮآﯾﻨﺪ ﺗﮑﺮار ﻣﯽﺷﻮد ﺑﻪﺟﺎی‬
‫اﻧﺪﯾﺸﯿﺪن ﺑﻪ اﻟﺰاﻣﺎت ﮐﻨﺘﺮﻟﯽ‪ ،‬از آن ﻟﯿﺴﺖ ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ‪ .‬در زﻣﺎن ﺑﻪ ﮐﺎرﮔﯿﺮی ﻟﯿﺴﺖ‪ ،‬ﭼﻪﺑﺴﺎ ﻣﻮارد ﺑﻬﺒﻮدی ﻧﯿﺰ ﺑﻪ‬
‫ذﻫﻨﺘﺎن ﺑﺮﺳﺪ ﮐﻪ ﻣﯽﺗﻮاﻧﯿﺪ در ﭼﮏﻟﯿﺴﺖ اﻋﻤﺎل ﮐﺮده‪ ،‬ﻫﻢ ﺑﺮای ﻣﻮرد در دﺳﺖ اﻗﺪام و ﻫﻢ ﺑﺮای ﻣﻮارد آﯾﻨﺪه ﺑﻪ ﮐﺎر‬
‫ﺑ ﺒ ﺮ ﯾ ﺪ‪.‬‬

‫ﻧﻤﻮﻧﻪ دﯾﮕﺮ وﺟﻮد ﭼﺮﺧﻪﻫﺎی ﺗﮑﺮارﭘﺬﯾﺮ در ﻣﺘﺪوﻟﻮژیﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ‪ P3.express‬اﺳﺖ‪ .‬ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ ﮐﻪ ﻫﺮ ﻣﺎه ﯾﺎ ﻫﺮ‬
‫ﻫﻔﺘﻪ ﺑﺎ روﻧﺪ وﯾﮋهای ﺗﮑﺮار ﻣﯽﺷﻮﻧﺪ ﺑﻪﺗﺪرﯾﺞ ﺗﺒﺪﯾﻞ ﺑﻪ ﻋﺎدت ﻣﯽﺷﻮﻧﺪ و ﺗﻮان ذﻫﻨﯽ ﮐﻤﺘﺮی ﻧﯿﺎز ﺧﻮاﻫﻨﺪ داﺷﺖ‪.‬‬
‫ﺗﻮاﻧﯽ ﮐﻪ اﯾﻨﮕﻮﻧﻪ ﺻﺮﻓﻪﺟﻮﯾﯽ ﮐﺮدهاﯾﺪ را ﻣﯽﺗﻮاﻧﯿﺪ ﺻﺮف ﺣﻞ ﻣﺴﺎﯾﻞ دﯾﮕﺮ ﮐﻨﯿﺪ‪.‬‬

‫‪ .3.2‬اﺻﻞﻫﺎی ﭘﺮﯾﻨﺲ‪۲‬‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬ﻣﺘﺪوﻟﻮژیای ﺧﻮشﺳﺎﺧﺖ و ﭘﺮﻗﺪﻣﺖ اﺳﺖ و در ﺑﯿﺸﺘﺮ ﭘﺮوژهﻫﺎ ﮐﺎرﺑﺮد دارد‪ .‬در ﻓﺼﻞ ﺑﻌﺪ ﭘﺮﯾﻨﺲ‪ ۲‬را‬
‫ﺑﻪﮐﻮﺗﺎﻫﯽ ﻣﺮور ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬ﻫﻢ ﻣﺠﻤﻮﻋﻪای از اﺻﻞﻫﺎ دارد‪:‬‬

‫‪ .1‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮی داﯾﻤﯽ ﭘﺮوژه‬

‫‪ .2‬آﻣﻮﺧﺘﻦ از درسﻫﺎی ﮔﺬﺷﺘﻪ‬
‫‪ .3‬ﻧﻘﺶﻫﺎ و ﻣﺴﺌﻮﻟﯿﺖﻫﺎی ﺗﻌﺮﯾﻒ ﺷﺪه‬
‫‪ .4‬ﻣﺪﯾﺮﯾﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﺮﺣﻠﻪ‬
‫‪ .5‬ﻣﺪﯾﺮﯾﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ﺷﺮاﯾﻂ وﯾﮋه‬
‫‪ .6‬ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺤﺼﻮل‬
‫‪ .7‬اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺑﺮای ﺷﺮاﯾﻂ ﭘﺮوژه‬

‫اﯾﻦ اﺻﻞﻫﺎ ﮐﻤﺎﺑﯿﺶ در ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﮐﺎرﺑﺮد دارﻧﺪ‪ ،‬وﻟﯽ ﻫﺪف از ﺗﺪوﯾﻦ آنﻫﺎ‪ ،‬ﺑﺮﺧﻼف اﺻﻞﻫﺎی ﭘﻢﺑﺎک و ‪،NUPP‬‬
‫ﺳﺎﺧﺖ ﻣﺠﻤﻮﻋﻪای ﮐﻪ راﻫﻨﻤﺎی ﻫﻤﻪ ﻧﻮع ﭘﺮوژه ﺑﺎﺷﺪ ﻧﺒﻮده اﺳﺖ‪ .‬ﺑﻪ ﺟﺎی آن‪ ،‬ﻫﺪف از اﯾﻦ اﺻﻞﻫﺎ ﭘﺸﺘﯿﺒﺎﻧﯽ از روﻧﺪ‬
‫وﯾﮋه اﺟﺮای ﭘﺮوژه در ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﻮده اﺳﺖ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﺮﺧﯽ از اﯾﻦ اﺻﻞﻫﺎ ﺑﻪﺳﺎدﮔﯽ در ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﺑﻪ ﮐﺎر ﻧﺨﻮاﻫﻨﺪ‬
‫رﻓﺖ‪.‬‬

‫— ‪— 39‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .1.3.2‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮی داﯾﻤﯽ ﭘﺮوژه‬

‫ﻓﻘﻂ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﺑﺎﺷﻨﺪ را ﺑﺎﯾﺪ آﻏﺎز ﮐﺮد‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﺑﻮدن در آﻏﺎز ﭘﺮوژه ﮐﺎﻓﯽ ﻧﯿﺴﺖ‪ ،‬زﯾﺮا‬
‫ﮔﺎﻫﯽ ﺑﺎ ﺷﻨﺎﺧﺖ ﺑﻬﺘﺮ ﭘﺮوژه ﻣﯽﺗﻮان ﺑﺮداﺷﺖ واﻗﻊﺑﯿﻨﺎﻧﻪﺗﺮی از ﺑﺎزﮔﺸﺖ ﺳﺮﻣﺎﯾﻪ آن ﺑﻪ دﺳﺖ آورد و ﮔﺎﻫﯽ ﻫﻢ ﺑﻪ‬
‫دﻟﯿﻞ ﺗﻐﯿﯿﺮ ﺷﺮاﯾﻂ ﺑﯿﺮوﻧﯽ ﭘﺮوژه ﺗﻮﺟﯿﻪﭘﺬﯾﺮیاش ﺗﻐﯿﯿﺮ ﻣﯽﮐﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﺎﯾﺪ داﯾﻤﺎ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه را ﺑﺎزﻧﮕﺮی‬
‫ﮐﺮده‪ ،‬ﺑﺴﺘﻪ ﺑﻪ ﻧﯿﺎز ﭘﺮوژه را ﻣﺘﻮﻗﻒ ﮐﺮد‪.‬‬

‫ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎی در ﺣﺎل اﻧﺠﺎﻣﯽ ﮐﻪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺧﻮد را از دﺳﺖ ﻣﯽدﻫﻨﺪ ﺑﻪ دو دﻟﯿﻞ ﻣﺘﻮﻗﻒ ﻧﻤﯽﺷﻮﻧﺪ‪:‬‬

‫‪ .1‬ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻣﻨﺎﺳﺒﯽ ﻧﺪارﻧﺪ ﮐﻪ ﻣﺘﻮﺟﻪ ﺗﻐﯿﯿﺮ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺑﺸﻮد‪ .‬از اﯾﻦرو‪ ،‬ﻣﯽﮔﻮﯾﯿﻢ ﮐﻪ ﻣﺘﻮﻗﻒ‬
‫ﮐﺮدن ﭘﺮوژهﻫﺎی ﻧﯿﻤﻪﮐﺎره ﻧﺸﺎﻧﻪای از ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه و ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮی ﻗﻮﯾﺴﺖ‪.‬‬
‫‪ .2‬ﮔﺎﻫﯽ ﺳﺎزﻣﺎنﻫﺎ ﻣﺘﻮﺟﻪ از ﺑﯿﻦ رﻓﺘﻦ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﻣﯽﺷﻮﻧﺪ‪ ،‬وﻟﯽ ﺑﻪ دﻟﯿﻞ ﻫﺰﯾﻨﻪ و ﮐﻮﺷﺸﯽ ﮐﻪ ﺗﺎ آن زﻣﺎن ﺻﺮف‬
‫ﭘﺮوژه ﺷﺪه اﺳﺖ ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ ﮐﺎر را اداﻣﻪ دﻫﻨﺪ ﮐﻪ در ﻋﻤﻞ ﺑﺎﻋﺚ ﺗﺒﺎﻫﯽ ﮐﻮﺷﺶ و ﭘﻮل ﺑﯿﺸﺘﺮ ﻣﯽﺷﻮد‪ .‬اﯾﻦ‬
‫ﺿﻌﻒ ﻧﺎﺷﯽ از ﻓﺮﯾﺒﯽ ذﻫﻨﯽ ﺑﻪ ﻧﺎم ‪ sunk cost effect‬اﺳﺖ‪.‬‬

‫ﺑﺎﯾﺪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﻫﺮ ﭘﺮوژهای را دورهای ﮐﻨﺘﺮل ﮐﺮد‪ .‬اﯾﻦ ﮐﺎر ﻫﻢ ﺑﻪ ﯾﺎﻓﺘﻦ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮﯾﺸﺎن را از دﺳﺖ‬
‫دادهاﻧﺪ ﮐﻤﮏ ﻣﯽﮐﻨﺪ و ﻫﻢ ﺑﻪ ﻫﻤﮕﺎن داﯾﻤﺎ ﻫﺪف ﭘﺮوژه و ﻟﺰوم ﻫﻢراﺳﺘﺎ ﺷﺪن ﺑﺎ آن را ﯾﺎدآوری ﻣﯽﮐﻨﺪ‪.‬‬

‫‪ .2.3.2‬آﻣﻮﺧﺘﻦ از درسﻫﺎی ﮔﺬﺷﺘﻪ‬

‫ﺗﻤﺪن ﺑﺸﺮی واﺑﺴﺘﻪ ﺑﻪ اﻧﺘﻘﺎل آﻣﻮﺧﺘﻪﻫﺎﺳﺖ‪ .‬اﮔﺮ ﻗﺮار ﺑﻮد ﻫﺮ داﻧﺸﻤﻨﺪی ﻫﻤﻪ ﻋﻠﻮم را از آﻏﺎز ﺑﻪ ﺗﻨﻬﺎﯾﯽ ﮐﺸﻒ ﮐﻨﺪ‪،‬‬
‫ﻫﯿﭻﮔﺎه ﻧﻤﯽﺗﻮاﻧﺴﺖ از ﺣﺪی ﺟﻠﻮﺗﺮ ﺑﺮود‪ .‬ﺑﻪﺟﺎی ﺗﮑﺮار آﻧﭽﻪ دﯾﮕﺮان ﺑﻪ دﺳﺖ آوردهاﻧﺪ‪ ،‬ﻫﺮ داﻧﺸﻤﻨﺪی ﯾﺎﻓﺘﻪﻫﺎی‬
‫ﭘﯿﺸﯿﻦ را ﻣﯽآﻣﻮزد و ﺳﭙﺲ ﮔﺎﻣﯽ ﺟﻠﻮﺗﺮ ﻣﯽرود‪ .‬ﻫﻤﯿﻦ ﻣﺴﺌﻠﻪ ﺑﺎﯾﺪ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻫﻢ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪:‬‬

‫ﺑﻪﺟﺎی اﯾﻦﮐﻪ ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺷﻬﻮدی و ﺑﺮ ﭘﺎﯾﻪ ﺗﺠﺮﺑﻪ ﺷﺨﺼﯽ ﭘﯿﺶ ﺑﺒﺮﯾﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ از‬
‫اﻧﺒﻮه ﺗﺠﺮﺑﻪﻫﺎی دﯾﮕﺮان ﮐﻪ در ﻗﺎﻟﺐ اﺳﺘﺎﻧﺪاردﻫﺎ و ﻣﺘﺪوﻟﻮژیﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک‪ ،‬ﭘﺮﯾﻨﺲ‪ ۲‬و ‪P3.express‬‬
‫ﻣﺴﺘﻨﺪ ﺷﺪهاﻧﺪ اﺳﺘﻔﺎده ﮐﻨﯿﺪ و ﺳﭙﺲ‪ ،‬ﻣﺎﻧﻨﺪ ﯾﮏ داﻧﺸﻤﻨﺪ‪ ،‬آن را ﮔﺎﻣﯽ ﺟﻠﻮﺗﺮ ﺑﺒﺮﯾﺪ‪.‬‬
‫ﺑﻪﺟﺎی اﯾﻦﮐﻪ ﮐﺎرﺗﺎن را در ﻫﺮ ﭘﺮوژه از ﺻﻔﺮ آﻏﺎز ﮐﻨﯿﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ از درسآﻣﻮﺧﺘﻪﻫﺎ و اﻃﻼﻋﺎت ﮔﺮدآوری ﺷﺪه‬
‫در ﭘﺮوژهﻫﺎی ﻣﺸﺎﺑﻬﯽ ﮐﻪ ﭘﯿﺸﺘﺮ در ﺳﺎزﻣﺎن اﻧﺠﺎم ﺷﺪه اﺳﺖ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﺛﺒﺖ درس آﻣﻮﺧﺘﻪ ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ در ﭘﺎﯾﺎن ﭘﺮوژه اﻧﺪﮐﯽ ﺑﻪ ﺧﺎﻃﺮات ﮔﺬﺷﺘﻪ ﺑﯿﻨﺪﯾﺸﻨﺪ و‬
‫از آن ﯾﺎدداﺷﺖ ﺑﺮدارﻧﺪ‪ .‬ﭼﻨﯿﻦ ﮐﺎری ﺑﻪ ﻫﯿﭻ وﺟﻪ ﮐﺎرا ﻧﯿﺴﺖ‪ .‬ﺑﻪ ﺟﺎی آن‪ ،‬ﺛﺒﺖ درس آﻣﻮﺧﺘﻪ ﺑﺎﯾﺪ داﯾﻤﯽ و ﺗﺪرﯾﺠﯽ‬
‫ﺑ ﺎ ﺷ ﺪ‪.‬‬

‫‪ .3.3.2‬ﻧﻘﺶﻫﺎ و ﻣﺴﺌﻮﻟﯿﺖﻫﺎی ﺗﻌﺮﯾﻒ ﺷﺪه‬

‫اﮔﺮ ﭘﺮوژه ﮐﻮﭼﮏ و ﺳﺎده ﻧﺒﺎﺷﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﻫﺮ ﻋﻀﻮی از ﺗﯿﻢ ﭘﺮوژه دﻗﯿﻘﺎ ﺑﺪاﻧﺪ ﮐﻪ ﭼﻪ اﻧﺘﻈﺎری از او ﻣﯽرود و ﭼﻪ‬
‫اﻧﺘﻈﺎری ﻣﯽﺗﻮاﻧﺪ از دﯾﮕﺮان داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬اﯾﻨﮕﻮﻧﻪ‪ ،‬ﺟﻠﻮی ﺑﺴﯿﺎری از ﺳﻮﺗﻔﺎﻫﻢﻫﺎ و ﻣﺸﮑﻞﻫﺎ ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮد و از اﯾﻦ‬

‫— ‪— 40‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ر و ﺳ ﺖ ﮐ ﻪ ﺗ ﻌ ﯿ ﯿ ﻦ ﻧ ﻘ ﺶ ﻫ ﺎ و ﻣ ﺴ ﺌ ﻮ ﻟ ﯿ ﺖ ﻫ ﺎ ﯾ ﮑ ﯽ ا ز ا ﺻ ﻞ ﻫ ﺎ د ر ﭘ ﺮ ﯾ ﻨ ﺲ‪ ۲‬ﺑ ﻪ ﺷ ﻤ ﺎ ر ﻣ ﯽ ر و د ‪.‬‬

‫‪ .4.3.2‬ﻣﺪﯾﺮﯾﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﺮﺣﻠﻪ‬

‫ﻣﻌﻤﻮﻻ ﻧﻤﯽﺗﻮان ﭘﺮوژهﻫﺎی ﻃﻮﻻﻧﯽ را از آﻏﺎز ﺑﻪﺗﻔﺼﯿﻞ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺮد‪ ،‬زﯾﺮا ﺑﺮﺧﯽ ﺟﺰﺋﯿﺎت را ﻓﻘﻂ زﻣﺎﻧﯽ ﻣﯽﺗﻮان‬
‫داﻧﺴﺖ ﮐﻪ ﺑﻪ آنﻫﺎ ﻧﺰدﯾﮏ ﺷﺪه ﺑﺎﺷﯿﻢ‪ .‬از اﯾﻦ رو‪ ،‬روﻧﺪ ﻣﻌﻤﻮل ﺑﺮﻧﺎﻣﻪرﯾﺰی در ﭘﺮﯾﻨﺲ‪ ۲‬اﯾﻦ اﺳﺖ ﮐﻪ در آﻏﺎز ﭘﺮوژه‬
‫ﺑﺮﻧﺎﻣﻪای ﮐﻼن و ﭘﯿﺶ از آﻏﺎز ﻫﺮ دوره ﺑﺮﻧﺎﻣﻪای ﺗﻔﺼﯿﻠﯽ ﺑﺮای آن دوره آﻣﺎده ﺷﻮد‪.‬‬

‫ﺑﺮﺧﻼف آﻧﭽﻪ ﺑﺮﺧﯽ ﻣﯽﭘﻨﺪارﻧﺪ‪ ،‬اﯾﻦ ﺷﯿﻮه ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺑﺴﯿﺎر راﯾﺞ و ﻓﺮاﮔﯿﺮ اﺳﺖ‪ .‬ﺑﺮﻧﺎﻣﻪرﯾﺰی در ‪ P3.express‬ﻧﯿﺰ ﺑﻪ‬
‫ﻫﻤﯿﻦ ﺗﺮﺗﯿﺐ اﺳﺖ‪ P3.express .‬ﭼﺮﺧﻪﻫﺎی ﺛﺎﺑﺖ ﻣﺎﻫﺎﻧﻪ دارد‪ ،‬وﻟﯽ ﻣﺪت زﻣﺎن دورهﻫﺎی ﭘﺮﯾﻨﺲ‪ ۲‬ﻣﺘﻐﯿﺮﻧﺪ‪.‬‬

‫‪ .5.3.2‬ﻣﺪﯾﺮﯾﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ﺷﺮاﯾﻂ وﯾﮋه‬

‫ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ ﺑﻪ ﺷﮑﻞ ﻣﻨﺎﺳﺐ ﺗﻔﻮﯾﺾ اﺧﺘﯿﺎر ﮐﻨﯿﺪ‪ ،‬وﮔﺮﻧﻪ ﻫﻢ ﺣﺠﻢ ﮐﺎرﺗﺎن ﺑﯽدﻟﯿﻞ ﺑﺎﻻ ﻣﯽرود و ﻫﻢ ﻣﺸﺎرﮐﺖ اﻋﻀﺎی‬
‫ﺗﯿﻢ و درﻧﺘﯿﺠﻪ اﺣﺘﻤﺎل ﻣﻮﻓﻘﯿﺖ ﮐﺎﻫﺶ ﻣﯽﯾﺎﺑﺪ‪.‬‬

‫در ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﺮای ﻫﺮ ﺳﻄﺢ ﻣﺪﯾﺮﯾﺘﯽ ﻣﺠﻤﻮﻋﻪای از ﺣﺪود ﺗﺼﻤﯿﻢﮔﯿﺮی ﺑﺮ ﭘﺎﯾﻪ زﻣﺎن‪ ،‬ﻫﺰﯾﻨﻪ‪ ،‬ﮔﺴﺘﺮه‪ ،‬ﮐﯿﻔﯿﺖ‪ ،‬رﯾﺴﮏ و‬
‫ﻣﻨﺎﻓﻊ ﻧﺎﺷﯽ از ﺗﺼﻤﯿﻢ ﻟﺤﺎظ ﻣﯽﺷﻮد‪ .‬ﭘﺲ از آن‪ ،‬اﮔﺮ اﺛﺮ ﺗﺼﻤﯿﻢ ﮐﻤﺘﺮ از آن ﺣﺪ ﺑﺎﺷﺪ‪ ،‬ﻓﺮد ﭘﺎﯾﯿﻦدﺳﺖ ﻣﺴﺌﻮل‬
‫ﺗﺼﻤﯿﻢﮔﯿﺮی ﺧﻮاﻫﺪ ﺑﻮد‪ ،‬وﮔﺮﻧﻪ ﺑﺎﯾﺪ ﻣﺴﺌﻠﻪ را ﺑﻪﻋﻨﻮان ﻣﻮردی وﯾﮋه )‪ ( exception‬ﺑﻪ ﻓﺮد ﺑﺎﻻدﺳﺖ ارﺟﺎع داد‪.‬‬

‫‪ .6.3.2‬ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺤﺼﻮل‬

‫ﺑﺴﯿﺎری ﻓﻘﻂ ﺑﺮ ﻓﻌﺎﻟﯿﺖﻫﺎ ﺗﻤﺮﮐﺰ دارﻧﺪ‪ ،‬وﻟﯽ ﺑﻬﺘﺮ اﺳﺖ ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺤﺼﻮل و ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﭘﺮوژه ﺑﺎﺷﺪ‪ .‬اﯾﻦ اﺻﻞ از‬
‫اﯾﻦ روﺳﺖ ﮐﻪ راهﻫﺎی ﻓﺮاواﻧﯽ ﺑﺮای ﺳﺎﺧﺖ ﻫﺮ ﺗﺤﻮﯾﻞﺷﺪﻧﯽ وﺟﻮد دارد و ﺑﻬﺘﺮ اﺳﺖ ﮔﺰﯾﻨﻪﻫﺎی ﺧﻮد را ﺑﯽدرﻧﮓ‬
‫ﻣﺤﺪود ﻧﮑﻨﯿﻢ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺤﺼﻮل و ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﺑﺎﺷﺪ‪ ،‬دﯾﺪ ﺑﻬﺘﺮی ﺑﺮ راﻫﮑﺎرﻫﺎ ﺧﻮاﻫﯿﻢ داﺷﺖ و‬
‫ﻣﯽﺗﻮاﻧﯿﻢ ﺑﻬﺘﺮﯾﻦ را اﻧﺘﺨﺎب ﮐﻨﯿﻢ‪ ،‬وﻟﯽ اﮔﺮ ﺗﻤﺮﮐﺰﻣﺎن ﺑﺮ ﻓﻌﺎﻟﯿﺖﻫﺎ ﺑﺎﺷﺪ در ﻋﻤﻞ ﺗﺴﻠﯿﻢ ﮔﺰﯾﻨﻪ ﭘﯿﺶﻓﺮﺿﯽ ﮐﻪ در‬
‫ﻓ ﻌ ﺎﻟ ﯿ ﺖ ﻫ ﺎ ﭘ ﻨ ﻬ ﺎ ن ا ﺳ ﺖ ﺧ ﻮ ا ﻫ ﯿ ﻢ ﺷ ﺪ‪.‬‬

‫‪ .7.3.2‬اﺧﺘﺼﺎﺻﯽﺳﺎزی ﺑﺮای ﺷﺮاﯾﻂ ﭘﺮوژه‬

‫ﺳﯿﺴﺘﻢﻫﺎی ﻣﺎﮐﺴﯿﻤﺎﻟﯿﺴﺘﯽ‪ ،‬ازﺟﻤﻠﻪ ﭘﺮﯾﻨﺲ‪ ،۲‬ﺑﺪون اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺨﺴﺘﯿﻦ ﮐﺎرﺑﺮدی ﻧﯿﺴﺘﻨﺪ و ﮐﺴﺎﻧﯽ ﮐﻪ‬
‫ﻣﯽﮐﻮﺷﻨﺪ ﭘﺮوژه ﺧﻮد را ﻋﯿﻨﺎ ﻫﻤﺎﻧﻨﺪ ﻇﻮاﻫﺮ آﻧﭽﻪ در ﻣﻨﻮآل ﭘﺮﯾﻨﺲ‪ ۲‬ﮔﻔﺘﻪ ﺷﺪه اﺳﺖ ﭘﯿﺶ ﺑﺒﺮﻧﺪ ﺑﻪ ﻧﺘﯿﺠﻪ ﻣﻄﻠﻮﺑﯽ‬
‫ﻧﺨﻮاﻫﻨﺪ رﺳﯿﺪ‪.‬‬

‫ﮔ ﺬ ﺷﺘ ﻪ ا ز ا ﺧﺘ ﺼﺎ ﺻ ﯽ ﺳﺎ ز ی ﻧ ﺨ ﺴﺘﯿ ﻦ ‪ ،‬ﺑﺎﯾ ﺪ داﯾ ﻤﺎ د ر ﻃ ﻮ ل ﮐﺎ ر ﻫ ﻢ ﻣ ﺸ ﻐ ﻮ ل ا ﺧﺘ ﺼﺎ ﺻ ﯽ ﺳﺎ ز ی ﺗ ﺪ رﯾ ﺠ ﯽ ﺑﺎ ﺷﯿ ﺪ ﺗﺎ ﺳﯿ ﺴﺘ ﻢ‬

‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺎ ﺷﺮاﯾﻂ ﻣﺤﯿﻄﯽ اﻧﻄﺒﺎق ﭘﯿﺪا ﮐﻨﺪ‪.‬‬

‫— ‪— 41‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ . 3‬اﻧﺘ ﺨﺎ ب ﻣﺘ ﺪ وﻟ ﻮژ ی‬

‫ﭘﻢﺑﺎک ﻣﺘﺪوﻟﻮژی ﻧﯿﺴﺖ‪ ،‬ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﮐﻪ ﻣﺴﯿﺮﺗﺎن را در ﭘﺮوژه ﻣﺸﺨﺺ ﻧﻤﯽﮐﻨﺪ‪ .‬ﺑﻪﺟﺎی آن ﺑﻪ دو ﺷﮑﻞ زﯾﺮ ﮐﻤﮑﺘﺎن‬
‫ﻣ ﯽ ﮐﻨ ﺪ‪:‬‬

‫درک و ﺗﻔﺴﯿﺮ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻪ ﮐﻤﮏ اﺻﻞﻫﺎ‬

‫ﺗﻘﻮﯾﺖ ﻣﺘﺪوﻟﻮژی ﺑﻪ ﮐﻤﮏ ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی‬

‫ﻣﻮرد ﻧﺨﺴﺖ را در ﻓﺼﻞ ﮔﺬﺷﺘﻪ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ و دوﻣﯽ ﻣﻮﺿﻮع ﻓﺼﻞ ﺑﻌﺪﯾﺴﺖ‪ .‬در اﯾﻦ ﻓﺼﻞ ﺑﺮﺧﯽ از ﻣﺘﺪوﻟﻮژیﻫﺎی‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﯾﻌﻨﯽ ‪ ،P3.express‬ﭘﺮﯾﻨﺲ‪ DSDM ،۲‬و اﺳﮑﺮام را ﺑﻪﮐﻮﺗﺎﻫﯽ ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ ﺗﺎ درک ﺑﻬﺘﺮی از ﻫﺪف‬
‫ﻓ ﺼ ﻞ آ ﯾ ﻨ ﺪ ه د ا ﺷ ﺘ ﻪ ﺑ ﺎ ﺷ ﯿ ﻢ‪.‬‬

‫درﺑﺎره واژه »ﻣﺘﺪوﻟﻮژی« ﺑﺎﯾﺪ اﯾﻦ ﻣﻮارد را در ﻧﻈﺮ داﺷﺖ‪:‬‬

‫واژه »ﻣﺘﺪوﻟﻮژی« در ﺟﺎﻣﻌﻪ ﭼﺎﺑﮏ ﮐﻤﺎﺑﯿﺶ ﺗﺎﺑﻮﺳﺖ و ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ روشﻫﺎی ﺧﻮد را ﭼﻬﺎرﭼﻮب‬
‫)‪ (framework‬ﺑﻨﺎﻣﻨﺪ‪ .‬ﻋﺒﺎرت »ﭼﻬﺎرﭼﻮب« اﻓﺰون ﺑﺮ ﺳﯿﺴﺘﻢﻫﺎﯾﯽ ﮐﻪ ﻣﺴﯿﺮ را ﻧﺸﺎن ﻣﯽدﻫﻨﺪ ﺑﻪ ﻣﻌﻨﺎﻫﺎی‬
‫د ﯾ ﮕ ﺮ ﻧ ﯿ ﺰ ﺑ ﻪ ﮐ ﺎ ر ﻣ ﯽ ر و د‪.‬‬
‫ﺑﺮﺧﯽ ﻣﻨﺎﺑﻊ ﻣﺎﻧﻨﺪ ‪) PM²‬راﻫﻨﻤﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺗﺤﺎدﯾﻪ اروﭘﺎ( ﺧﻮد را ﻣﺘﺪوﻟﻮژی ﻣﻌﺮﻓﯽ ﻣﯽﮐﻨﻨﺪ‪ ،‬وﻟﯽ در ﻋﻤﻞ‬
‫راﻫﻨﻤﺎﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک ﻫﺴﺘﻨﺪ و ﻧﻪ ﺳﯿﺴﺘﻢﻫﺎﯾﯽ ﮐﻪ ﻣﺎﻧﻨﺪ ﻣﻮارد اﯾﻦ ﻓﺼﻞ ﻣﺴﯿﺮ را ﻧﺸﺎن دﻫﻨﺪ‪.‬‬
‫‪ P3.express‬ﺑﻪﺟﺎی واژﮔﺎﻧﯽ ﻣﺎﻧﻨﺪ ﻣﺘﺪوﻟﻮژی و ﭼﻬﺎرﭼﻮب‪ ،‬واژه »ﺳﯿﺴﺘﻢ« را ﺑﻪ ﮐﺎر ﻣﯽﺑﺮد ﺗﺎ ﺑﻪ ﻣﺠﺎدﻟﻪﻫﺎی‬
‫ﺑﯿﻬﻮدهای ﮐﻪ درﺑﺎره ﻣﻔﻬﻮم و ﺗﻔﺎوت آن ﻋﺒﺎرتﻫﺎ ﻣﯽﺷﻮد داﻣﻦ ﻧﺰﻧﺪ‪.‬‬

‫ﮔﺬﺷﺘﻪ از اﯾﻦﮐﻪ ﭼﻪ ﻋﺒﺎرﺗﯽ ﺑﻪ ﮐﺎر ﻣﯽرود‪ ،‬ﺗﻤﺮﮐﺰﻣﺎن در اﯾﻦ ﻓﺼﻞ ﺑﺮ ﺳﯿﺴﺘﻢﻫﺎﯾﯿﺴﺖ ﮐﻪ ﻣﺴﯿﺮ ﭘﺮوژه را ﻧﺸﺎن‬
‫ﻣﯽدﻫﻨﺪ و ﺑﺮای ﺳﺎدﮔﯽ آنﻫﺎ را ﻣﺘﺪوﻟﻮژی ﺧﻄﺎب ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫درﺑﺎره ﺳﯿﺴﺘﻢﻫﺎﯾﯽ ﮐﻪ در اﯾﻦ ﻓﺼﻞ ﻣﻄﺮح ﻣﯽﺷﻮﻧﺪ ﻧﯿﺰ ﺑﻪ اﯾﻦ ﻣﻮارد دﻗﺖ ﮐﻨﯿﺪ‪:‬‬

‫اﺳﮑﺮام ﺑﺮای ﭘﺮوژهﻫﺎی ﮐﻮﭼﮏ ﺑﺎ ﺗﯿﻢ ﻣﺤﺪود ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ‪ .‬اﮔﺮ ﭘﺮوژهﺗﺎن ﺑﺰرگﺗﺮ ﺑﺎﺷﺪ ﻧﻤﯽﺗﻮاﻧﯿﺪ ﺑﺪون‬
‫اﺧﺘﺼﺎﺻﯽﺳﺎزی زﯾﺎد از اﺳﮑﺮام اﺳﺘﻔﺎده ﮐﻨﯿﺪ و ﭼﻪﺑﺴﺎ ﺑﻬﺘﺮ ﺑﺎﺷﺪ ﮐﻪ ﺑﻪﺟﺎی آن ﺳﯿﺴﺘﻤﯽ را ﺑﺮﮔﺰﯾﻨﯿﺪ ﮐﻪ ﺑﺮای‬
‫ﭘﺮوژهﻫﺎی ﺑﺰرگﺗﺮ ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ‪.‬‬
‫اﺳﮑﺮام و ‪ DSDM‬ﺑﺮای ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﻃﺮاﺣﯽ ﺷﺪهاﻧﺪ و از آن رو ﺑﻪﮐﺎر ﮔﯿﺮی آنﻫﺎ در ﺳﺎﯾﺮ ﭘﺮوژهﻫﺎ ﻧﯿﺎز‬
‫ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی زﯾﺎد دارد‪ .‬اﮔﺮ ﭘﺮوژهﺗﺎن ﻧﺮماﻓﺰاری ﻧﺒﺎﺷﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﺑﻪﺟﺎی اﺧﺘﺼﺎﺻﯽﺳﺎزی اﯾﻦ دو‪،‬‬
‫ﻣﺘﺪوﻟﻮژیای ﺑﺮﮔﺰﯾﻨﯿﺪ ﮐﻪ ﭼﻨﯿﻦ ﻣﺤﺪودﯾﺘﯽ ﻧﺪارد‪.‬‬
‫اﺳﮑﺮام‪ ،‬ﺑﺮﺧﻼف ﺳﺎﯾﺮ ﻣﻮاردی ﮐﻪ در اﯾﻦ ﻓﺼﻞ ﺑﺮرﺳﯽ ﻣﯽﺷﻮﻧﺪ‪ ،‬ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﭘﻮﺷﺶ‬
‫ﻧﻤﯽدﻫﺪ و ﻧﻤﯽﺗﻮان آن را از اﯾﻦ زاوﯾﻪ ﺳﯿﺴﺘﻢ ﮐﺎﻣﻠﯽ داﻧﺴﺖ‪ .‬اﻓﺰودن ﺟﻨﺒﻪﻫﺎی ﭘﻮﺷﺶ داده ﻧﺸﺪه ﭘﯿﭽﯿﺪه‬
‫اﺳﺖ و اﮔﺮ ﺣﺴﺎﺳﯿﺖﻫﺎی ﭘﺮوژهﺗﺎن ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﻧﯿﺎز ﺑﻪ ﺳﯿﺴﺘﻤﯽ ﮐﺎﻣﻞ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ از ﮔﺰﯾﻨﻪ‬
‫دﯾﮕﺮی ﺑﻬﺮه ﮔﯿﺮﯾﺪ ﮐﻪ ﺧﻮد آن ﻣﻮارد را ﭘﻮﺷﺶ داده ﺑﺎﺷﺪ‪.‬‬

‫ﺳﺮاﻧﺠﺎم‪ ،‬اﯾﻦ را ﻫﻢ در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻣﻄﺎﻟﺐ اﯾﻦ ﻓﺼﻞ ﺑﺴﯿﺎر ﮐﻮﺗﺎه اﺳﺖ و ﻓﻘﻂ ﺑﺮای آﺷﻨﺎﯾﯽ ﻣﺨﺘﺼﺮ ﺑﺎ‬

‫— ‪— 42‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺘﺪوﻟﻮژیﻫﺎ‪ ،‬در ﺣﺪی ﮐﻪ ﺑﺮای درک ﺑﻬﺘﺮ ﻣﻄﺎﻟﺐ ﻓﺼﻞ ﺑﻌﺪ ﮐﻔﺎﯾﺖ ﮐﻨﺪ‪ ،‬وﮔﺮﻧﻪ ﯾﺎدﮔﯿﺮی ﻫﺮﯾﮏ از اﯾﻦ ﻣﺘﺪوﻟﻮژیﻫﺎ ﻧﯿﺎز‬
‫ﺑﻪ ﺗﻔﺼﯿﻞ ﺑﺴﯿﺎر ﺑﯿﺸﺘﺮی دارد‪.‬‬

‫‪P3.express .1.3‬‬

‫‪ P3.express‬ﻣﺘﺪوﻟﻮژیای ﻣﯿﻨﯿﻤﺎﻟﯿﺴﺘﯽ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ ﮐﻪ ﺑﺮای ﭘﺮوژهﻫﺎی ﮐﻮﭼﮏ‪ ،‬ﻣﺘﻮﺳﻂ‪ ،‬و ﺑﺰرگ ﻃﺮاﺣﯽ‬
‫ﺷﺪه اﺳﺖ‪ .‬ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ و ﺑﺴﯿﺎر ﺑﺰرگ ﻣﺨﺎﻃﺐ اﺻﻠﯽ ﺳﯿﺴﺘﻢ ﻧﯿﺴﺘﻨﺪ و ﻧﯿﺎزﻣﻨﺪ اﺧﺘﺼﺎﺻﯽﺳﺎزیﻫﺎی‬
‫ﻓﺮاوان ﺧﻮاﻫﻨﺪ ﺑﻮد‪ .‬اﻟﺒﺘﻪ ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ ﻧﻮع وﯾﮋهای از آن ﺑﺎ ﻧﺎم ‪ micro.P3.express‬ﻃﺮاﺣﯽ و اراﺋﻪ‬
‫ﺷ ﺪ ه ا ﺳ ﺖ‪.‬‬

‫ﯾﮑﯽ از ﺗﻤﺎﯾﺰﻫﺎی ‪ P3.express‬ﺑﺎ ﮔﺰﯾﻨﻪﻫﺎی دﯾﮕﺮی ﻣﺜﻞ ﭘﺮﯾﻨﺲ‪ ۲‬اﯾﻦ اﺳﺖ ﮐﻪ ﻧﯿﺎز ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺨﺴﺘﯿﻦ‬
‫ﻧﺪارد‪ .‬ﺑﻪﺟﺎﯾﺶ‪ ،‬ﮐﺎرﺑﺮان ﻣﯽﺗﻮاﻧﻨﺪ از آن ﺑﻪ ﻫﻤﺎن ﺷﮑﻠﯽ ﮐﻪ ﻫﺴﺖ در ﭘﺮوژهﻫﺎی ﺧﻮد اﺳﺘﻔﺎده ﮐﻨﻨﺪ و ﻓﻘﻂ ﭘﺲ از‬
‫ﭘ ﯿ ﺎ د ه ﺳ ﺎ ز ی ﮐ ﺎ ﻣ ﻞ و ﺟ ﺎ ا ﻓ ﺘ ﺎ د ن ﺳ ﯿ ﺴ ﺘ ﻢ آ ﻏ ﺎ ز ﺑ ﻪ ا ﺧ ﺘ ﺼ ﺎ ﺻ ﯽ ﺳ ﺎ ز ی ﺗ ﺪ ر ﯾ ﺠ ﯽ آ ن ﮐ ﻨ ﻨ ﺪ‪.‬‬

‫‪ P3.express‬ﺑﺮﺧﻼف ﺑﺮﺧﯽ ﻣﻨﺎﺑﻊ دﯾﮕﺮ‪ ،‬ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک و ﭘﺮﯾﻨﺲ‪ ، ۲‬ﻣﻨﺒﻌﯽ آزاد اﺳﺖ و ﻋﻼﻗﻪﻣﻨﺪان ﻣﯽﺗﻮاﻧﻨﺪ ﺑﺪون‬
‫ﻣﺤﺪودﯾﺖ ﮐﭙﯽراﯾﺖ از آن ﺑﻬﺮهﻣﻨﺪ ﺷﻮﻧﺪ‪ .‬اﯾﻦ ﻣﻨﺒﻊ ﺑﻪ ﯾﺎری داوﻃﻠﺒﺎن ﺑﻪ ﺑﯿﺶ از ﺑﯿﺴﺖ زﺑﺎن ﺗﺮﺟﻤﻪ ﺷﺪه اﺳﺖ و در‬
‫آن ﻣﯿﺎن ﺗﺮﺟﻤﻪ ﻓﺎرﺳﯽ ﻧﯿﺰ وﺟﻮد دارد‪https://p3.express :‬‬

‫‪ .1.1.3‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‬

‫ﻧﻘﺶﻫﺎی ﺗﻌﺮﯾﻒ ﺷﺪه در ‪ P3.express‬از اﯾﻦ ﻗﺮارﻧﺪ‪:‬‬

‫ﺣﺎﻣﯽ ﭘﺮوژه‪ :‬اﯾﻦ ﻓﺮد ﯾﮑﯽ از ﻣﺪﯾﺮان ارﺷﺪ ﺳﺎزﻣﺎن ﺑﺎ روﯾﮑﺮد ﮐﺴﺐ و ﮐﺎر اﺳﺖ ﮐﻪ ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﮐﻼن و‬
‫ﻣﺴﺌﻮﻟﯿﺖ ﻓﺮاﻫﻢ ﮐﺮدن ﻣﻨﺎﺑﻊ را ﺑﺮ دوش دارد‪.‬‬
‫ﻣﺪﯾﺮ ﭘﺮوژه‪ :‬اﯾﻦ ﻓﺮد ﻣﺴﺌﻮل ﻣﺪﯾﺮﯾﺖ ﻣﺴﺎﯾﻞ روزﻣﺮه اﺳﺖ‪.‬‬
‫رﻫﺒﺮان ﺗﯿﻢﻫﺎ‪ :‬ﭼﻨﺎﻧﭽﻪ ﭘﺮوژه ﺗﯿﻢﻫﺎﯾﯽ ﻣﺘﺸﮑﻞ از اﻓﺮاد دروﻧﯽ ﺳﺎزﻣﺎن داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﺮای ﻫﺮ ﺗﯿﻢ رﻫﺒﺮی‬
‫اﻧﺘﺨﺎب ﻣﯽﺷﻮد ﮐﻪ در ﻣﺴﺎﯾﻞ ﻣﺪﯾﺮﯾﺘﯽ ﺑﺎ ﻣﺪﯾﺮ ﭘﺮوژه ﻫﻤﺎﻫﻨﮓ ﺷﻮد‪.‬‬
‫ﻣﺪﯾﺮان ﭘﺮوژه ﭘﯿﻤﺎﻧﮑﺎر‪ :‬اﮔﺮ ﭘﺮوژه ﭘﯿﻤﺎﻧﮑﺎراﻧﯽ داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻫﺮ ﭘﯿﻤﺎﻧﮑﺎر ﺟﺰ ﻣﺎﻧﻨﺪ ﯾﮏ ﺗﯿﻢ ﻋﻤﻞ ﺧﻮاﻫﺪ ﮐﺮد و‬
‫ﻓﺮدی ﮐﻪ در راس آن ﺗﯿﻢ ﺑﺎﺷﺪ ﻣﺪﯾﺮ ﭘﺮوژه ﭘﯿﻤﺎﻧﮑﺎر ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬

‫ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻫﺮﮐﺪام از ارﮐﺎن ﭘﺮوژه ﮐﻪ از ‪ P3.express‬اﺳﺘﻔﺎده ﮐﻨﻨﺪ زاوﯾﻪ دﯾﺪ ﺧﻮد را ﺧﻮاﻫﻨﺪ داﺷﺖ و‬
‫ﺳﺎﺧﺘﺎر‪ ،‬اﺳﻨﺎد‪ ،‬و ﻓﺮآﯾﻨﺪﻫﺎﯾﺶ ﻧﯿﺰ ﺑﺮ ﻫﻤﺎن ﭘﺎﯾﻪ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬ﺑﺮﺧﻼف آن‪ ،‬در ﺣﺎﻟﺖ ﭘﯿﺶﻓﺮض ﭘﺮﯾﻨﺲ‪ ،۲‬ﺳﺎﺧﺘﺎری‬
‫ﯾﮑﻪ ﺑﺮای ﺗﺮﮐﯿﺐ ﻫﻤﻪ ارﮐﺎن ﭘﺮوژه وﺟﻮد دارد‪.‬‬

‫اﮔﺮ ﻻزم ﺑﺎﺷﺪ ﻣﯽﺗﻮاﻧﯿﺪ ﻧﻘﺶﻫﺎی ﺑﯿﺸﺘﺮی ﺑﻪ ﺳﯿﺴﺘﻢ ﺑﯿﻔﺰاﯾﯿﺪ‪ ،‬وﻟﯽ ﻣﺮاﻗﺐ ﺑﺎﺷﯿﺪ ﮐﻪ اﯾﻦ ﮐﺎر را ﺑﻪ ﺗﺪرﯾﺞ‪ ،‬ﺑﺮ ﭘﺎﯾﻪ‬
‫ﺑﺎزﺧﻮردﻫﺎﯾﯽ ﮐﻪ از ﻣﺤﯿﻂ درﯾﺎﻓﺖ ﻣﯽﮐﻨﯿﺪ و ﺑﺪون ﭘﯿﭽﯿﺪه ﮐﺮدن ﺳﯿﺴﺘﻢ اﻧﺠﺎم دﻫﯿﺪ‪.‬‬

‫— ‪— 43‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .2.1.3‬ﻓﺮآﯾﻨﺪ‬

‫در ‪ P3.express‬ﻣﺠﻤﻮﻋﻪ ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ ﺑﺮای آﻏﺎزش ﭘﺮوژه و ﭘﺎﯾﺎن ﭘﺮوژه وﺟﻮد دارد‪ .‬در ﻣﯿﺎن اﯾﻦ دو‪ ،‬ﭼﺮﺧﻪﻫﺎﯾﯽ‬
‫ﻣﺎﻫﺎﻧﻪ ﺑﺮای اﻧﺠﺎم ﮐﺎر ﭘﺮوژه وﺟﻮد دارد‪ ،‬ﺑﺎ ﮔﺮوه ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ ﺑﺮای آﻏﺎزش ﻣﺎﻫﺎﻧﻪ و ﭘﺎﯾﺎن ﻣﺎﻫﺎﻧﻪ‪ .‬درون ﭼﺮﺧﻪﻫﺎی‬
‫ﻣﺎﻫﺎﻧﻪ ﻧﯿﺰ ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﻫﻔﺘﮕﯽ و ﻣﺪﯾﺮﯾﺖ روزاﻧﻪ وﺟﻮد دارد‪ .‬ﭘﺲ از ﭘﺎﯾﺎن ﭘﺮوژه ﺷﻤﺎری ﻓﻌﺎﻟﯿﺖ‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺴﺎﭘﺮوژه ﺑﺮای ارزﯾﺎﺑﯽ ﻣﻨﺎﻓﻊ ﭘﺮوژه و ﻃﺮاﺣﯽ اﻗﺪامﻫﺎی ﺗﺎزه وﺟﻮد دارد‪.‬‬

‫ﺑﺮای آﻏﺎزش ﭘﺮوژه ﺑﺎﯾﺪ اﻋﻀﺎی ﮐﻠﯿﺪی ﺗﯿﻢ ﻣﻨﺼﻮب و ﺑﻪ ﮐﻤﮏ آنﻫﺎ ﺑﺮﻧﺎﻣﻪای ﮐﻼن آﻣﺎده ﺷﻮد‪ .‬ﺑﺮﻧﺎﻣﻪ ﺑﺮای ﺣﺎﻣﯽ ﭘﺮوژه‬
‫ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮد ﺗﺎ درﺑﺎره اﺟﺮا ﮐﺮدن ﯾﺎ ﻧﮑﺮدن ﭘﺮوژه ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮد‪.‬‬

‫ﺗﺮﺟﯿﺢ ﺑﺮ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻧﺨﺴﺘﯿﻦ ﮐﻼن ﺑﺎﺷﺪ و ﺳﭙﺲ در ﻫﺮ آﻏﺎزش ﻣﺎﻫﺎﻧﻪ ﺑﺎزﺑﯿﻨﯽ ﺷﺪه‪ ،‬ﺑﺮای ﻣﺎه ﭘﯿﺶ رو‬
‫ﺗﻔﺼﯿﻠﯽ ﺷﻮد‪ .‬اﻃﻼﻋﺎت ﺑﺎزﺑﯿﻨﯽ و ﺗﻔﺼﯿﻠﯽ ﺷﺪه در ﭘﺎﯾﺎن آﻏﺎزش ﻣﺎﻫﺎﻧﻪ ﺑﺮای ﺣﺎﻣﯽ ﭘﺮوژه ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮﻧﺪ ﺗﺎ درﺑﺎره‬
‫اداﻣﻪ دادن ﯾﺎ ﻣﺘﻮﻗﻒ ﮐﺮدن ﭘﺮوژه ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮد‪.‬‬

‫در ﻃﻮل ﻣﺎه ﺑﺮ روی ﻣﺤﺼﻮل ﭘﺮوژه ﮐﺎر ﻣﯽﮐﻨﯿﻢ و ﻫﺮ ﻫﻔﺘﻪ ﭘﯿﺸﺮﻓﺖ آن را ارزﯾﺎﺑﯽ ﮐﺮده‪ ،‬ﺑﻪ اﻧﺤﺮافﻫﺎ واﮐﻨﺶ ﻧﺸﺎن‬
‫ﻣﯽدﻫﯿﻢ‪ .‬ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ روزاﻧﻪ ﻧﯿﺰ ﺑﺮای ﺗﺎﯾﯿﺪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﮐﺎﻣﻞ ﺷﺪه و ﭘﯿﮕﯿﺮی اﻗﻼم ﻗﺎﺑﻞﭘﯿﮕﯿﺮی )رﯾﺴﮏﻫﺎ‪،‬‬
‫ﻣﺴﺎﯾﻞ‪ ،‬درﺧﻮاﺳﺖﻫﺎی ﺗﻐﯿﯿﺮ‪ ،‬ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻬﺒﻮد‪ ،‬و درس آﻣﻮﺧﺘﻪﻫﺎ( وﺟﻮد دارد‪.‬‬

‫در زﻣﺎن ﭘﺎﯾﺎن ﻣﺎﻫﺎﻧﻪ‪ ،‬رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن را ارزﯾﺎﺑﯽ ﮐﺮده‪ ،‬ﺑﺮ آن ﭘﺎﯾﻪ ﺑﺮﻧﺎﻣﻪﻫﺎﯾﯽ ﺑﺮای ﺑﻬﺒﻮد ﭘﺮوژه در ﻣﺎه ﺑﻌﺪ ﻃﺮاﺣﯽ‬
‫ﻣ ﯽ ﮐ ﻨ ﯿ ﻢ‪.‬‬

‫وﻗﺘﯽ ﻣﺤﺼﻮل ﭘﺮوژه ﮐﺎﻣﻞ ﺷﻮد ﯾﺎ ﻗﺮار ﺑﺎﺷﺪ آن را ﻣﺘﻮﻗﻒ ﮐﻨﯿﻢ‪ ،‬ﻓﻌﺎﻟﯿﺖﻫﺎی ﭘﺎﯾﺎن ﭘﺮوژه را اﺟﺮا ﻣﯽﮐﻨﯿﻢ ﺗﺎ ﺗﺸﺮﯾﻔﺎت‬
‫ﭘﺎﯾﺎﻧﯽ را اﻧﺠﺎم دﻫﻨﺪ‪ ،‬رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن را ارزﯾﺎﺑﯽ ﮐﻨﻨﺪ‪ ،‬ﻣﺤﺼﻮل را ﺑﻪ ﮐﺎرﻓﺮﻣﺎ ﺗﺤﻮﯾﻞ دﻫﻨﺪ‪ ،‬اﺳﻨﺎد را ﺑﺎﯾﮕﺎﻧﯽ ﮐﻨﻨﺪ و‬
‫…‬

‫ﭼﺮﺧﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺴﺎﭘﺮوژه ﺑﺴﺘﻪ ﺑﻪ ﻧﻮع ﻣﺤﺼﻮل و ﻣﺤﯿﻂ آن ﻫﺮ ‪ ۳‬ﺗﺎ ‪ ۶‬ﻣﺎه ﺑﻪ ﻣﺪت ‪ ۱‬ﺗﺎ ‪ ۵‬ﺳﺎل ﺗﮑﺮار ﻣﯽﺷﻮد‪ .‬در اﯾﻦ‬
‫ﭼﺮﺧﻪ ﻣﻨﺎﻓﻊ ﺑﺮآﻣﺪه از ﻣﺤﺼﻮل ﭘﺮوژه را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﯿﻢ و ﺑﺮ آن ﭘﺎﯾﻪ ﮐﺎرﻫﺎی اﺿﺎﻓﻪای ﮐﻪ ﺷﺎﯾﺪ ﻣﻨﺎﻓﻊ را اﻓﺰاﯾﺶ‬
‫دﻫﻨﺪ ﺷﻨﺎﺳﺎﯾﯽ ﻣﯽﮐﻨﯿﻢ‪ .‬اﻧﺠﺎم ﻓﻌﺎﻟﯿﺖﻫﺎی ﺧﺮد ﺑﺮ دوش ﺗﯿﻢﻫﺎی ﻋﻤﻠﯿﺎﺗﯽ ﮔﺬاﺷﺘﻪ ﻣﯽﺷﻮد و ﺑﺮای ﻓﻌﺎﻟﯿﺖﻫﺎی‬
‫ﺑﺰرگﺗﺮ ﭘﺮوژهﻫﺎی ﺗﺎزه ﻣﯽﺳﺎزﯾﻢ‪.‬‬

‫ﻫﺮﮐﺪام از ﻫﻔﺖ ﮔﺮوه ﻓﺮآﯾﻨﺪی ﮔﻔﺘﻪ ﺷﺪه ﺑﻪﺟﺰ ﻣﺪﯾﺮﯾﺖ روزاﻧﻪ ﺑﺎ ﻓﻌﺎﻟﯿﺘﯽ ﺑﻪ ﻧﺎم ارﺗﺒﺎط ﻣﺘﻤﺮﮐﺰ ﭘﺎﯾﺎن ﻣﯽﯾﺎﺑﺪ‪ .‬در اﯾﻦ‬
‫ﻓﻌﺎﻟﯿﺖ ﭘﯿﺎﻣﯽ ﺣﺎوی اﻃﻼﻋﺎت وﯾﮋه ﺑﺮای ذیﻧﻔﻌﺎن از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷﺪه ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮد ﺗﺎ ﻫﻤﮕﺎن از وﺿﻌﯿﺖ ﭘﺮوژه‬
‫آ ﮔ ﺎ ه ﺑ ﺎ ﺷ ﻨ ﺪ‪.‬‬

‫در آﻏﺎزش ﭘﺮوژه و آﻏﺎزش ﻣﺎﻫﺎﻧﻪ ﻓﻌﺎﻟﯿﺘﯽ ﺑﺎ ﻧﺎم ﻫﻤﺘﺎداوری )‪ (peer review‬وﺟﻮد دارد ﮐﻪ ﻧﻘﺸﯽ ﮐﻠﯿﺪی در‬
‫‪ P3.express‬دارد‪ .‬در اﯾﻦ ﻓﻌﺎﻟﯿﺖ از ﯾﮑﯽ دﯾﮕﺮ از ﻣﺪﯾﺮان ﭘﺮوژهﻫﺎی ﺳﺎزﻣﺎن درﺧﻮاﺳﺖ ﻣﯽﮐﻨﯿﺪ ﮐﻪ ﮐﺎرﻫﺎﯾﯽ را ﮐﻪ در‬
‫ﻃﯽ آن ﻣﺪت اﻧﺠﺎم دادهاﯾﺪ ﺑﺮرﺳﯽ ﮐﺮده‪ ،‬ﻧﻈﺮ ﺑﺪﻫﺪ‪ .‬اﮔﺮ ﻣﯽﺗﻮاﻧﯿﺪ‪ ،‬ﻫﺮ ﺑﺎر از ﻓﺮد ﻣﺘﻔﺎوﺗﯽ ﺑﺮای ﻫﻤﺘﺎداوری ﮐﻤﮏ‬
‫ﺑﮕﯿﺮﯾﺪ‪ .‬اﯾﻦ ﻓﻌﺎﻟﯿﺖ ﻫﻢ اﺣﺘﻤﺎل رخ دادن اﺷﺘﺒﺎه را ﮐﺎﻫﺶ ﻣﯽدﻫﺪ و ﻫﻢ روش ﺑﺴﯿﺎر ﺧﻮﺑﯿﺴﺖ ﺑﺮای اﯾﻦﮐﻪ اﯾﻦ دو‬
‫ﻧﻔﺮ از ﯾﮑﺪﯾﮕﺮ ﺑﯿﺎﻣﻮزﻧﺪ‪.‬‬

‫— ‪— 44‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺤﺼﻮلﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ‪ P3.express‬از اﯾﻦ ﻗﺮارﻧﺪ‪:‬‬

‫ﺷﺮح ﭘﺮوژه‪ :‬اﻃﻼﻋﺎت ﭘﺎﯾﻪای ﭘﺮوژه ازﺟﻤﻠﻪ دﻟﯿﻞ اﻧﺠﺎم‪ ،‬ﺑﻮدﺟﻪ‪ ،‬ﻓﺮﺟﻪ‪ ،‬اﻟﺰاﻣﺎت‪ ،‬و ﻓﻬﺮﺳﺖ ذیﻧﻔﻌﺎن در آن ﻗﺮار‬
‫دارﻧﺪ‪.‬‬
‫ﻧﻘﺸﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ‪ :‬اﯾﻦ ﻣﺤﺼﻮل ﻓﻬﺮﺳﺘﯽ ﺳﻠﺴﻠﻪﻣﺮاﺗﺒﯽ از اﺟﺰای ﺳﺎزﻧﺪه ﻣﺤﺼﻮل ﭘﺮوژه )ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ(‬
‫اﺳﺖ‪ .‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ اﯾﻦ ﻧﻘﺸﻪ در ﻗﺎﻟﺐ ‪ mind map‬ﺳﺎﺧﺘﻪ ﺷﻮد‪ .‬ﻫﺮ ﺗﺤﻮﯾﻞﺷﺪﻧﯽ ﻧﯿﺰ ﺑﺎﯾﺪ ﯾﮏ ﻣﺘﻮﻟﯽ‬
‫)‪ (custodian‬داﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ وﺿﻌﯿﺖ آن را ﭘﯿﮕﯿﺮی ﮐﻨﺪ‪.‬‬
‫ﻓﻬﺮﺳﺖ ﭘﯿﮕﯿﺮی‪ :‬ﻫﻤﻪ رﯾﺴﮏﻫﺎ‪ ،‬ﻣﺴﺎﯾﻞ‪ ،‬درﺧﻮاﺳﺖﻫﺎی ﺗﻐﯿﯿﺮ‪ ،‬ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻬﺒﻮد‪ ،‬و درس آﻣﻮﺧﺘﻪﻫﺎ در اﯾﻦ‬
‫ﻓﻬﺮﺳﺖ ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ‪ ،‬ﺑﻪ آنﻫﺎ ﻣﺘﻮﻟﯽ اﺧﺘﺼﺎص داده ﻣﯽﺷﻮد‪ ،‬و وﺿﻌﯿﺘﺸﺎن ﭘﯿﮕﯿﺮی ﻣﯽﺷﻮد ﺗﺎ زﻣﺎﻧﯽ ﮐﻪ ﺑﻪ‬
‫ﺳﺮاﻧﺠﺎم ﺑﺮﺳﻨﺪ‪.‬‬
‫ﻓﻬﺮﺳﺖ ﺳﻼﻣﺖ‪ :‬اﯾﻦ ﺳﻨﺪ ﻧﺘﯿﺠﻪ ﻫﻤﺘﺎداوریﻫﺎ و ارزﯾﺎﺑﯽﻫﺎی رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن را در ﺧﻮد ﺟﺎی ﻣﯽدﻫﺪ‪.‬‬

‫‪ .2.3‬ﭘﺮﯾﻨﺲ‪۲‬‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬ﻣﺘﺪوﻟﻮژیای ﺧﻮشﺳﺎﺧﺖ‪ ،‬ﭘﯿﺸﺮﻓﺘﻪ و ﭘﯿﭽﯿﺪه اﺳﺖ و از آن ﻣﯽﺗﻮان در ﺑﯿﺸﺘﺮ ﭘﺮوژهﻫﺎ اﺳﺘﻔﺎده ﮐﺮد‪.‬‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬را ﺑﺪون اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺨﺴﺘﯿﻦ ﻧﺒﺎﯾﺪ ﺑﻪ ﮐﺎر ﺑﺮد‪ .‬از آنﺟﺎﯾﯽ ﮐﻪ ﺑﯿﺸﺘﺮ ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺰرگ و ﺑﺴﯿﺎر ﺑﺰرگ‬
‫ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ‪ ،‬اﺧﺘﺼﺎﺻﯽﺳﺎزی آن ﺑﺮای ﭘﺮوژهﻫﺎی ﻣﺘﻮﺳﻂ و ﮐﻮﭼﮏ ﻧﯿﺎز ﺑﻪ ﮐﻮﺷﺶ ﺑﯿﺸﺘﺮی دارد‪.‬‬

‫‪ .1.2.3‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‬

‫در ﭘﺮﯾﻨﺲ‪ ۲‬ﺳﻪ ﺳﻄﺢ ﻣﺪﯾﺮﯾﺘﯽ درون ﭘﺮوژه‪ ،‬ﭘﺎﯾﯿﻦﺗﺮ از ﺳﻄﺢ ﻣﺪﯾﺮﯾﺘﯽ ﺳﺎزﻣﺎن وﺟﻮد دارد‪ .‬ﻧﻘﺶﻫﺎی ﻣﺘﻌﺪدی در اﯾﻦ‬
‫ﻻﯾﻪﻫﺎ ﺗﻌﺮﯾﻒ ﺷﺪه اﺳﺖ‪ ،‬ازﺟﻤﻠﻪ‪:‬‬

‫ﻻﯾ ﻪ ﻫ ﺪاﯾ ﺖ‬
‫ﻫﯿﺌﺖ ﭘﺮوژه‬
‫ﻣﺪﯾﺮ ارﺷﺪ‪ :‬ﯾﮑﯽ از ﻣﺪﯾﺮان ارﺷﺪ ﺳﺎزﻣﺎن ﺑﺎ ﮔﺮاﯾﺶ ﮐﺴﺐ و ﮐﺎر اﺳﺖ ﮐﻪ ﻣﺴﺌﻮﻟﯿﺖ ﺗﺼﻤﯿﻢﻫﺎی‬
‫ﮐﻼن ﭘﺮوژه و ﻓﺮاﻫﻢآوری ﻣﻨﺎﺑﻊ را ﺑﺮ دوش دارد‪.‬‬
‫ﮐﺎرﺑﺮان ارﺷﺪ‪ :‬اﯾﻦ اﻓﺮاد ﻧﻤﺎﯾﻨﺪﮔﺎﻧﯽ از ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﻣﺤﺼﻮل ﭘﺮوژه ﻫﺴﺘﻨﺪ ﯾﺎ ﮐﺴﺎﻧﯽ ﮐﻪ درک‬
‫ﮐﺎﻣﻠﯽ از ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ دارﻧﺪ و اﯾﻦ اﻃﻼﻋﺎت را ﺑﻪ ﻫﯿﺌﺖ ﭘﺮوژه ﻣﯽآورﻧﺪ‪.‬‬
‫ﺗﺎﻣﯿﻦﮐﻨﻨﺪﮔﺎن ارﺷﺪ‪ :‬اﯾﻦ اﻓﺮاد ﯾﺎ ﻧﻤﺎﯾﻨﺪﮔﺎن ﮐﺴﺎﻧﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﺤﺼﻮل ﭘﺮوژه را ﻣﯽﺳﺎزﻧﺪ‪ ،‬ﯾﺎ‬
‫ﮐﺴﺎﻧﯽ ﮐﻪ درک ﮐﺎﻣﻠﯽ از آنﻫﺎ دارﻧﺪ و اﯾﻦ اﻃﻼﻋﺎت را ﺑﻪ ﻫﯿﺌﺖ ﭘﺮوژه ﻣﯽآورﻧﺪ‪.‬‬
‫ﻻﯾ ﻪ ﻣ ﺪﯾ ﺮﯾ ﺖ‬
‫ﻣﺪﯾﺮ ﭘﺮوژه‪ :‬اﯾﻦ ﻓﺮد ﻣﺴﺌﻮل ﻣﺪﯾﺮﯾﺖ ﻣﺴﺎﯾﻞ روزﻣﺮه ﭘﺮوژه اﺳﺖ‪.‬‬
‫ﭘﺸﺘﯿﺒﺎﻧﯽ ﭘﺮوژه‪ :‬اﯾﻦ اﻓﺮاد در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ‪.‬‬
‫ﻻﯾ ﻪ ﺳﺎ ﺧ ﺖ‬
‫رﻫﺒﺮان ﺗﯿﻢﻫﺎ‪ :‬اﯾﻦ اﻓﺮاد ﺗﯿﻢﻫﺎی اﺟﺮاﯾﯽ دروﻧﯽ و ﺑﯿﺮوﻧﯽ را رﻫﺒﺮی ﻣﯽﮐﻨﻨﺪ و ﺑﺎ ﻣﺪﯾﺮ ﭘﺮوژه در ارﺗﺒﺎط‬

‫— ‪— 45‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻫ ﺴ ﺘ ﻨ ﺪ‪.‬‬

‫ﻣﯽﺗﻮاﻧﯿﺪ ﺑﺎ ﺷﮑﺴﺘﻦ ﻫﺮﮐﺪام از ﻧﻘﺸﻬﺎ‪ ،‬ﻧﻘﺶﻫﺎی ﺗﺎزهای ﺑﻪ وﺟﻮد آورﯾﺪ ﯾﺎ ﺑﺎ ادﻏﺎم ﮐﺮدن آنﻫﺎ در ﻫﻢ ﺳﯿﺴﺘﻢ‬
‫ﺳﯿﺴﺘﻢ را ﺳﺎدهﺗﺮ ﮐﻨﯿﺪ‪ .‬ﺑﺮای اﯾﻦ ﮐﺎر ﻣﺤﺪودﯾﺖﻫﺎﯾﯽ ﻧﯿﺰ وﺟﻮد دارد؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻧﺒﺎﯾﺪ ﻧﻘﺶ ﻣﺪﯾﺮ ﭘﺮوژه و ﻣﺪﯾﺮ ارﺷﺪ‬
‫در ﻫﻢ ادﻏﺎم ﺷﻮﻧﺪ زﯾﺮا ﻫﻢ ﺗﻀﺎد ﻣﻨﺎﻓﻊ ﺑﻪ وﺟﻮد ﻣﯽآﯾﺪ و ﻫﻢ اﯾﻦﮐﻪ ﺑﺮای ﯾﮏ ﻧﻔﺮ دﺷﻮار اﺳﺖ ﮐﻪ ﻫﻢ ﺑﻪ ﺟﻨﺒﻪﻫﺎی‬
‫ﺑﺴﯿﺎر ﮐﻼن ﺗﻮﺟﻪ ﮐﻨﺪ و ﻫﻢ ﻣﺴﺎﯾﻞ روزﻣﺮه‪.‬‬

‫ﻣﻨﻮآل ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﺮای ﻫﺮﮐﺪام از ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ﺟﺪوﻟﯽ از ﻣﺴﺌﻮﻟﯿﺖﻫﺎ ﻧﯿﺰ دارد ﮐﻪ ﻋﻤﻠﮑﺮد ﻫﺮ ﻧﻘﺶ را در ازای‬
‫ﻓ ﻌ ﺎﻟ ﯿ ﺖ ﻣ ﺸ ﺨ ﺺ ﻣ ﯽ ﮐ ﻨ ﺪ‪.‬‬

‫‪ .2.2.3‬ﻓﺮآﯾﻨﺪ‬

‫وﻗﺘﯽ اﯾﺪه ﭘﺮوژهای ﺷﮑﻞ ﻣﯽﮔﯿﺮد و ﺑﻪ ﻧﻈﺮ ﺟﺎﻟﺐ ﻣﯽرﺳﺪ و ﭘﯿﺶ از آنﮐﻪ ﺗﺼﻤﯿﻢ ﻧﻬﺎﯾﯽ درﺑﺎره آن ﮔﺮﻓﺘﻪ ﺷﻮد‪ ،‬ﻓﺮآﯾﻨﺪ‬
‫راهاﻧﺪازی ﭘﺮوژه اﺟﺮا ﻣﯽﺷﻮد‪ .‬در اﯾﻦ ﻓﺮآﯾﻨﺪ ﺑﺮﺧﯽ اﻋﻀﺎی ﮐﻠﯿﺪی ﺗﯿﻢ ﻣﻨﺼﻮب ﻣﯽﺷﻮﻧﺪ و ﻫﻤﺮاه ﻫﻢ اﻃﻼﻋﺎﺗﯽ ﮐﻼن‬
‫ﮔﺮدآوری ﻣﯽﮐﻨﻨﺪ ﮐﻪ در ﭘﺎﯾﺎن در ﺳﻨﺪی ﺑﺎ ﻧﺎم ﺧﻼﺻﻪ ﭘﺮوژه )‪ (project brief‬ذﺧﯿﺮه ﺧﻮاﻫﻨﺪ ﺷﺪ‪ .‬اﯾﻦ ﺳﻨﺪ اﻃﻼﻋﺎﺗﯽ‬
‫ﺗﻘﺮﯾﺒﯽ درﺑﺎره ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه و ﺷﯿﻮه اﺟﺮای ﻣﻨﺎﺳﺐ آن دارد‪.‬‬

‫ﻣﺪﯾﺮ ارﺷﺪ و ﺳﺎﯾﺮ اﻓﺮاد ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪه ﺑﺮ ﭘﺎﯾﻪ اﻃﻼﻋﺎت ﮔﺮدآوری ﺷﺪه ﺗﺼﻤﯿﻢ ﻣﯽﮔﯿﺮﻧﺪ ﮐﻪ ﭘﺮوژه ارزش ﺑﺮرﺳﯽ دﻗﯿﻖﺗﺮ‬
‫دارد ﯾﺎ ﺧﯿﺮ‪ .‬اﮔﺮ داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻓﺮآﯾﻨﺪ آﻏﺎزش ﭘﺮوژه اﺟﺮا ﻣﯽﺷﻮد‪.‬‬

‫در آﻏﺎزش ﭘﺮوژه ﺑﺮﻧﺎﻣﻪ ﮐﻼن آﻣﺎده ﻣﯽﺷﻮد و ﺑﺮ آن ﭘﺎﯾﻪ ﻣﯽﺗﻮان ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه را ﺑﺎ اﻃﻤﯿﻨﺎن ﺑﯿﺸﺘﺮ ﺑﺮآورد ﮐﺮد‪.‬‬
‫اﯾﻦ اﻃﻼﻋﺎت در ﺳﻨﺪی ﺑﺎ ﻧﺎم ﺳﻨﺪ آﻏﺎزش ﭘﺮوژه )‪ (project initiation documentation‬ذﺧﯿﺮه ﻣﯽﺷﻮد‪ .‬اﯾﻦ ﺳﻨﺪ ﻧﯿﺰ‬
‫در اﺧﺘﯿﺎر ﻣﺪﯾﺮ ارﺷﺪ و ﺳﺎﯾﺮ ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪﮔﺎن ﮔﺬاﺷﺘﻪ ﻣﯽﺷﻮد ﮐﻪ ﺗﺼﻤﯿﻢ ﻧﻬﺎﯾﯽ را ﺑﺮای آﻏﺎز ﮐﺮدن ﯾﺎ ﻧﮑﺮدن ﮐﺎر‬
‫اﺟﺮاﯾﯽ ﭘﺮوژه ﺑﮕﯿﺮﻧﺪ‪.‬‬

‫ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ ﻣﯽﺑﯿﻨﯿﺪ‪ ،‬ﭘﺮوژه در دو ﻣﺮﺣﻠﻪ ارزﯾﺎﺑﯽ ﻣﯽﺷﻮد‪ .‬در ﻣﺮﺣﻠﻪ ﻧﺨﺴﺖ ﺑﻪﺳﺮﻋﺖ و ﺑﺎ ﺻﺮف ﺗﻮان ﻣﺤﺪود آن را‬
‫ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ ﺗﺎ ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ اﺻﻼ ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﻧﯿﺴﺘﻨﺪ ﺣﺬف ﺷﻮﻧﺪ‪ .‬در ﻣﺮﺣﻠﻪ دوم‪ ،‬ﺑﺎ ﺻﺮف زﻣﺎن و اﻧﺮژی ﺑﯿﺸﺘﺮ‪،‬‬
‫ﭘﺮوژه را ﺑﻪ دﻗﺖ ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ و ﺑﺮ آن ﭘﺎﯾﻪ ﺗﺼﻤﯿﻢ ﻧﻬﺎﯾﯽ را ﻣﯽﮔﯿﺮﯾﻢ‪.‬‬

‫ﭘﺮوژهﻫﺎ در ﭘﺮﯾﻨﺲ‪ ۲‬ﻣﺮﺣﻠﻪ ﺑﻪ ﻣﺮﺣﻠﻪ اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ‪ .‬ﭘﯿﺶ از اﺟﺮای ﻫﺮ ﻣﺮﺣﻠﻪ ﻓﺮآﯾﻨﺪ ﻣﺪﯾﺮﯾﺖ ﺷﺮاﯾﻂ ﺣﺪی اﺟﺮا‬
‫ﻣﯽﺷﻮد ﺗﺎ ﺑﺮﻧﺎﻣﻪ ﮐﻼن را ﺑﺎزﺑﯿﻨﯽ ﮐﺮده‪ ،‬ﺑﺮﻧﺎﻣﻪای ﺗﻔﺼﯿﻠﯽ ﺑﺮای ﻣﺮﺣﻠﻪ ﭘﯿﺶ رو ﺑﺴﺎزد‪ .‬ﺑﺮ ﭘﺎﯾﻪ اﯾﻦ ﺗﻐﯿﯿﺮﻫﺎ‪،‬‬
‫ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه ﺑﺎزﺑﯿﻨﯽ و ﺑﺮای درﯾﺎﻓﺖ اﺟﺎزه اﺟﺮای ﻣﺮﺣﻠﻪ ﺑﻌﺪ ﺑﺮای ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪﮔﺎن ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮد‪.‬‬

‫ﻫﻤﻪ ﺗﺼﻤﯿﻢﻫﺎی ﮐﻼن ﭘﺮوژه ﮐﻪ ﻣﺴﺘﻘﯿﻢ ﯾﺎ ﻏﯿﺮﻣﺴﺘﻘﯿﻢ از ﺳﻮی ﻣﺪﯾﺮ ارﺷﺪ ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮﻧﺪ در ﻓﺮآﯾﻨﺪی ﮐﻠﯽ ﺑﻪ ﻧﺎم‬
‫ﻫﺪاﯾﺖ ﭘﺮوژه ﻗﺮار دارﻧﺪ‪.‬‬

‫در ﻃﻮل ﻣﺮﺣﻠﻪ‪ ،‬ﻓﺮآﯾﻨﺪی ﺑﻪ ﻧﺎم ﮐﻨﺘﺮل ﻣﺮﺣﻠﻪ ﮐﺎرﻫﺎی روزاﻧﻪ را اﻧﺠﺎم ﻣﯽدﻫﺪ‪ .‬در اﯾﻦ ﻓﺮآﯾﻨﺪ ﮐﺎرﻫﺎﯾﯽ ﮐﻪ ﻻزم اﺳﺖ‬
‫ﺗﯿﻢﻫﺎ اﻧﺠﺎم دﻫﻨﺪ را ﺑﺮاﯾﺸﺎن ﻣﯽﻓﺮﺳﺘﯿﻢ و در ﻻﯾﻪ ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﻧﯿﺰ ﻓﺮآﯾﻨﺪی ﺑﺎ ﻧﺎم ﻣﺪﯾﺮﯾﺖ ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺑﺮای‬
‫رﻫﺒﺮان ﺗﯿﻢﻫﺎ وﺟﻮد دارد ﮐﻪ ﺑﺎ ﻓﺮآﯾﻨﺪ ﻻﯾﻪ ﻣﺪﯾﺮﯾﺘﯽ ﺗﻌﺎﻣﻞ ﻣﯽﮐﻨﺪ‪.‬‬

‫— ‪— 46‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻓﺮآﯾﻨﺪ ﮐﻨﺘﺮل ﻣﺮﺣﻠﻪ وﺿﻌﯿﺖ ﭘﺮوژه را ﻧﯿﺰ ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﺪ‪ ،‬ﮔﺰارشﻫﺎی ﭘﯿﺸﺮﻓﺖ آﻣﺎده ﻣﯽﮐﻨﺪ‪ ،‬و ﺑﺮای اﺻﻼح اﻧﺤﺮافﻫﺎ‬
‫ﻧﯿﺰ ﺗﺼﻤﯿﻢ ﻣﯽﮔﯿﺮد‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ اﻧﺤﺮاﻓﯽ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ اﺛﺮش ﮐﻤﺘﺮ از ﺣﺪ ﺗﺼﻤﯿﻢﮔﯿﺮی ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎﺷﺪ‪،‬‬
‫ﺧﻮدش ﺗﺼﻤﯿﻢ ﻣﯽﮔﯿﺮد‪ ،‬وﮔﺮﻧﻪ آن را ﺑﺮای ﻻﯾﻪ ﻫﺪاﯾﺖ ﻣﯽﻓﺮﺳﺘﺪ‪.‬‬

‫ﻫﺮوﻗﺖ ﻣﺤﺼﻮل ﭘﺮوژه ﮐﺎﻣﻞ ﺷﻮد ﯾﺎ ﻻزم ﺑﺎﺷﺪ ﮐﻪ ﭘﺮوژه ﻣﺘﻮﻗﻒ ﮔﺮدد‪ ،‬ﻓﺮآﯾﻨﺪ ﭘﺎﯾﺎن ﭘﺮوژه اﺟﺮا ﻣﯽﺷﻮد ﺗﺎ ﺗﺸﺮﯾﻔﺎت‬
‫ﻧﻬﺎﯾﯽ را اﻧﺠﺎم داده‪ ،‬ﻣﺤﺼﻮل را ﺑﻪ ﮐﺎرﻓﺮﻣﺎ ﺗﺤﻮﯾﻞ دﻫﺪ‪.‬‬

‫‪ .3.3‬اﺳﮑﺮام‬

‫اﺳﮑﺮام ﯾﮑﯽ از ﺳﯿﺴﺘﻢﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ ﻧﺨﺴﺖ اﺳﺖ ﮐﻪ ﺑﺮای ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﺑﺎ ﺣﺪاﮐﺜﺮ ‪ ۱۰‬ﻧﻔﺮ ﻃﺮاﺣﯽ ﺷﺪه‬
‫اﺳﺖ‪ .‬ﻣﯽﺗﻮان ادﻋﺎ ﮐﺮد ﮐﻪ اﯾﻦ ﺳﯿﺴﺘﻢ ﺑﯿﺸﺘﺮ ﻻﯾﻪای ﻣﺪﯾﺮﯾﺘﯽ ﺑﻮد ﮐﻪ ﺑﺮای ﻫﺪاﯾﺖ ﺳﯿﺴﺘﻢ ‪eXtreme‬‬
‫‪ (Programming (XP‬ﮐﻪ ﻣﺤﺒﻮبﺗﺮﯾﻦ ﺳﯿﺴﺘﻢ ﭼﺎﺑﮏ زﻣﺎن ﺧﻮد ﺑﻮد ﺳﺎﺧﺘﻪ ﺷﺪه ﺑﻮد‪ ،‬زﯾﺮا ‪ XP‬ﻓﻘﻂ در ﻻﯾﻪ ﻓﻨﯽ ﺑﻮد و‬
‫ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ﭼﻨﺪاﻧﯽ ﻧﺪاﺷﺖ‪ .‬اﺳﮑﺮام ﺑﻪﺗﺪرﯾﺞ دﮔﺮﮔﻮن و در ﻗﺎﻟﺐ ﺳﯿﺴﺘﻤﯽ ﻣﺴﺘﻘﻞ اراﺋﻪ ﺷﺪ‪.‬‬

‫اﺳﮑﺮام ﺳﯿﺴﺘﻤﯽ ﺳﺎده و ﺧﻮشﺳﺎﺧﺖ اﺳﺖ ﮐﻪ ﺣﺪ ﻣﺨﺘﺼﺮی از ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﮐﻪ ﺑﺮای ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﮐﺎﻓﯿﺴﺖ‬
‫اراﺋﻪ ﻣﯽﮐﻨﺪ‪ .‬از اﯾﻦرو‪ ،‬ﺑﺎﯾﺪ ﻫﻤﻮاره در ﻧﻈﺮ داﺷﺖ ﮐﻪ اﺳﮑﺮام ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﭘﻮﺷﺶ ﻧﻤﯽدﻫﺪ‪.‬‬

‫وﯾﮋﮔﯽﻫﺎی ﺟﺎﻟﺐ اﺳﮑﺮام و ﺑﺮﺧﯽ ﻣﺴﺎﯾﻞ ﻣﺤﯿﻄﯽ دﺳﺖ در دﺳﺖ ﻫﻢ آن را ﺑﻪ راﯾﺞﺗﺮﯾﻦ ﺳﯿﺴﺘﻢ ﭼﺎﺑﮏ ﺗﺒﺪﯾﻞ‬
‫ﮐﺮدهاﻧﺪ‪ .‬اﮐﻨﻮن ﮐﻤﺎﺑﯿﺶ ﻫﻤﻪ ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﯾﺎ ﺑﺎ اﺳﮑﺮام اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ ﯾﺎ ﺑﺎ ﺳﯿﺴﺘﻢﻫﺎی ﻧﺴﻞ دوﻣﯽ ﮐﻪ ﺑﻪ ﺷﺪت‬
‫ﺗﺤﺖ ﺗﺎﺛﯿﺮ اﺳﮑﺮام ﺑﻮدهاﻧﺪ‪.‬‬

‫‪ .1.3.3‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‬

‫ﺳﻪ ﻧﻘﺶ در اﺳﮑﺮام وﺟﻮد دارد‪:‬‬

‫اﺳﮑﺮام ﻣﺴﺘﺮ‪ :‬اﯾﻦ ﻓﺮد ﺷﯿﻮه ﮐﺎرﮐﺮد ﺗﯿﻢ را زﯾﺮ ﻧﻈﺮ دارد و آنﻫﺎ را ﻫﺪاﯾﺖ ﻣﯽﮐﻨﺪ ﮐﻪ از اﺳﮑﺮام ﺑﻪدرﺳﺘﯽ‬
‫اﺳﺘﻔﺎده ﮐﻨﻨﺪ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﻣﺴﺌﻮﻟﯿﺖ ﺗﺴﻬﯿﻞﮔﺮی و رﻓﻊ ﭼﺎﻟﺶﻫﺎ را ﻧﯿﺰ ﺑﺮ دوش دارد‪.‬‬
‫ﻣﺎﻟﮏ ﻣﺤﺼﻮل‪ :‬اﯾﻦ ﻓﺮد درک ﮐﺎﻣﻠﯽ از ﮐﺴﺐ و ﮐﺎر دارد و از ﯾﮏ ﺳﻮ ﺑﺎ دﯾﮕﺮ اﻋﻀﺎی ﺗﯿﻢ در ﺗﻤﺎس اﺳﺖ و از‬
‫ﺳﻮی دﯾﮕﺮ ﺑﺎ ذیﻧﻔﻌﺎن ﺑﯿﺮوﻧﯽ ﺗﯿﻢ‪ .‬ﺑﺎ ﭘﯿﮕﯿﺮیﻫﺎﯾﺶ ﻧﯿﺎزﻫﺎی ﮐﺎرﻓﺮﻣﺎ را درک ﮐﺮده‪ ،‬در ﺗﯿﻢ ﺑﺎزﺗﺎب ﻣﯽدﻫﺪ‪.‬‬
‫اﻓﺰون ﺑﺮ آن‪ ،‬ﻧﯿﺎزﻫﺎ را ﺑﺮ ﭘﺎﯾﻪ ﭘﺘﺎﻧﺴﯿﻞ ارزﺷﺸﺎن اوﻟﻮﯾﺖﺑﻨﺪی ﻣﯽﮐﻨﺪ ﺗﺎ ﺗﯿﻢ ﻫﻤﯿﺸﻪ ﺑﺮ ﺑﺎارزشﺗﺮﯾﻦ ﻗﺎﺑﻠﯿﺖﻫﺎ‬
‫ﻣﺘﻤﺮﮐﺰ ﺷﻮد‪.‬‬
‫ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن‪ :‬اﯾﻦ اﻓﺮاد ﮐﺴﺎﻧﯽ ﻣﺎﻧﻨﺪ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن‪ ،‬ﻃﺮاﺣﺎن راﺑﻂ ﮐﺎرﺑﺮی‪ ،‬و ﻣﻌﻤﺎران ﻧﺮماﻓﺰار ﻫﺴﺘﻨﺪ ﮐﻪ‬
‫ﺳﺎﺧﺖ ﻣﺤﺼﻮل را ﺑﺮ دوش دارﻧﺪ‪ .‬اﻟﺒﺘﻪ در ﮐﻨﺎر ﮐﺎر ﻓﻨﯽ‪ ،‬ﻣﺴﺌﻮﻟﯿﺖﻫﺎﯾﯽ ﻣﺪﯾﺮﯾﺘﯽ ﻧﯿﺰ دارﻧﺪ‪.‬‬

‫ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺘﯽ اﺳﮑﺮام ﻏﯿﺮﻣﺘﻤﺮﮐﺰ اﺳﺖ؛ ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﮐﻪ ﺑﻪﺟﺎی داﺷﺘﻦ ﻓﺮد و ﮔﺮوﻫﯽ ﮐﻪ ﻣﺴﺌﻮﻟﯿﺖ اﺻﻠﯽ‬
‫ﻫﻤﺎﻫﻨﮕﯽﻫﺎ و ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺑﺮ دوش داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ ،‬اﯾﻦ ﻣﺴﺌﻮﻟﯿﺖﻫﺎ در ﻣﯿﺎن ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ ﭘﺨﺶ ﺷﺪه اﺳﺖ‪.‬‬

‫ﺑﻪ دﻟﯿﻞ ﺳﺎﺧﺘﺎری ﮐﻪ اﺳﮑﺮام دارد‪ ،‬اﻓﺰودن ﻧﻘﺶﻫﺎی دﯾﮕﺮ ﺑﻪ ﺳﺎزﮔﺎری دروﻧﯽ آن آﺳﯿﺐ ﻣﯽزﻧﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﻣﺠﺎز‬

‫— ‪— 47‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻧ ﯿ ﺴ ﺖ‪.‬‬

‫‪ .2.3.3‬ﻓﺮآﯾﻨﺪ‬

‫ﺑﺮﺧﻼف ﺑﯿﺸﺘﺮ ﺳﯿﺴﺘﻢﻫﺎ‪ ،‬اﺳﮑﺮام آﻏﺎزش و ﭘﺎﯾﺎﻧﯽ رﺳﻤﯽ و ﺳﺎﺧﺖﯾﺎﻓﺘﻪ ﺗﻌﺮﯾﻒ ﻧﮑﺮده اﺳﺖ و ﻓﻘﻂ ﺑﺮ روﻧﺪ ﻣﻨﺎﺳﺐ‬
‫ﺑﺮای زﻣﺎن اﺟﺮای ﭘﺮوژه ﺗﻤﺮﮐﺰ دارد‪ .‬دﻟﯿﻞ اﯾﻦ ﻣﺴﺌﻠﻪ اﯾﻦ اﺳﺖ ﮐﻪ اﺳﮑﺮام ﺑﺮآن ﻧﯿﺴﺖ ﮐﻪ ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ‬
‫ﭘﺮوژه را ﭘﻮﺷﺶ دﻫﺪ‪.‬‬

‫در آﻏﺎز ﭘﺮوژه‪ ،‬ﻣﺎﻟﮏ ﻣﺤﺼﻮل ﺑﺎ ذیﻧﻔﻌﺎن ﮔﻔﺘﮕﻮ ﻣﯽﮐﻨﺪ و ﻓﻬﺮﺳﺘﯽ ﺳﺎده و ﻧﺨﺴﺘﯿﻦ از ﻗﺎﺑﻠﯿﺖﻫﺎی ﻣﺪﻧﻈﺮﺷﺎن ﻓﺮاﻫﻢ‬
‫ﻣﯽﮐﻨﺪ‪ .‬ﻓﻬﺮﺳﺖ ﻣﺤﺼﻮل )‪ (product backlog‬ﺑﻪ ﻫﯿﭻ وﺟﻪ ﮐﺎﻣﻞ ﻧﯿﺴﺖ و در ﻃﻮل اﺟﺮای ﭘﺮوژه دﺳﺘﺨﻮش‬
‫دﮔﺮﮔﻮﻧﯽﻫﺎی ﻓﺮاواﻧﯽ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫ﻣﺎﻟﮏ ﻣﺤﺼﻮل ﻫﻢ ﻣﺴﺌﻮل ﺗﺪوﯾﻦ آﯾﺘﻢﻫﺎی ﻓﻬﺮﺳﺖ اﺳﺖ و ﻫﻢ ﻣﺮﺗﺐ ﮐﺮدن آنﻫﺎ ﺑﺮ ﭘﺎﯾﻪ ارزﺷﺸﺎن‪ .‬آﯾﺘﻢﻫﺎی‬
‫ﺑﺎارزشﺗﺮ و ﻣﻬﻢﺗﺮ در ﺑﺎﻻی ﻓﻬﺮﺳﺖ ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ‪.‬‬

‫اﺳﮑﺮام ﻧﯿﺰ ﻣﺎﻧﻨﺪ ﭘﺮﯾﻨﺲ‪ ۲‬و ‪ P3.express‬ﭼﺮﺧﻪاﯾﺴﺖ و ﭼﺮﺧﻪﻫﺎﯾﺶ ‪ Sprint‬ﻧﺎم دارﻧﺪ‪ .‬اﯾﻦ ﭼﺮﺧﻪﻫﺎ ﻣﺪتزﻣﺎن ﺛﺎﺑﺘﯽ‬
‫دارﻧﺪ و ﻫﻤﯿﺸﻪ در زﻣﺎن ﻣﻌﯿﻦ ﭘﺎﯾﺎن ﻣﯽﭘﺬﯾﺮﻧﺪ‪ ،‬ﺣﺘﯽ اﮔﺮ ﮐﺎر ﭼﺮﺧﻪ ﮐﺎﻣﻞ ﻧﺸﺪه ﺑﺎﺷﺪ‪ .‬ﺗﻌﯿﯿﻦ ﻣﺪتزﻣﺎن ﭼﺮﺧﻪﻫﺎ ﺑﺮ‬
‫دوش ﺗﯿﻢ اﺳﺖ‪ ،‬وﻟﯽ اﯾﻦ ﻣﺪت ﻧﺒﺎﯾﺪ ﺑﯿﺸﺘﺮ از ﯾﮏ ﻣﺎه ﺑﺎﺷﺪ‪ .‬ﺑﺮای ﻣﺪتزﻣﺎن ﭼﺮﺧﻪﻫﺎ ﻫﺮ ﺑﺎر ﺗﺼﻤﯿﻢﮔﯿﺮی ﻧﻤﯽﮐﻨﯿﻢ‪،‬‬
‫ﺑﻠﮑﻪ ﻫﻤﻪ ﭼﺮﺧﻪﻫﺎ را ﺑﺎ ﻣﺪت ﯾﮑﺴﺎن اﺟﺮا ﻣﯽﮐﻨﯿﻢ‪ ،‬ﻣﮕﺮ اﯾﻦﮐﻪ ﭘﺲ از ﻣﺪﺗﯽ ﻣﺘﻮﺟﻪ ﺷﻮﯾﻢ ﮐﻪ ﻣﺪت ﺗﻌﯿﯿﻦ ﺷﺪه ﺑﺮای‬
‫ﻧﻮع ﭘﺮوژه ﻣﻨﺎﺳﺐ ﻧﯿﺴﺖ و ﺑﻬﺘﺮ اﺳﺖ آن را ﺑﺮای ﭼﺮﺧﻪﻫﺎی ﺑﻌﺪ اﺻﻼح ﮐﻨﯿﻢ‪.‬‬

‫ﻫﺮ ﭼﺮﺧﻪ ﺑﺎ ﺟﻠﺴﻪای ﺣﺪاﮐﺜﺮ ‪ ۸‬ﺳﺎﻋﺘﻪ ﺑﺮای ﺑﺮﻧﺎﻣﻪرﯾﺰی ﭼﺮﺧﻪ آﻏﺎز ﻣﯽﺷﻮد‪ .‬اﻋﻀﺎی ﺗﯿﻢ ﮔﺮد ﻫﻢ ﻣﯽآﯾﻨﺪ و درﺑﺎره‬
‫آﯾﺘﻢﻫﺎﯾﯽ ﮐﻪ در ﺑﺎﻻی ﻓﻬﺮﺳﺖ ﻗﺮار دارﻧﺪ ﮔﻔﺘﮕﻮ ﻣﯽﮐﻨﻨﺪ ﺗﺎ ﻣﻄﻤﺌﻦ ﺷﻮﻧﺪ ﮐﻪ درک ﻣﻨﺎﺳﺒﯽ از آنﻫﺎ دارﻧﺪ‪ .‬ﭘﺲ از آن‬
‫ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﺑﺮآورد ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﭼﻨﺪ آﯾﺘﻢ از ﺑﺎﻻی ﻓﻬﺮﺳﺖ ﻣﺤﺼﻮل را ﻣﯽﺗﻮاﻧﻨﺪ در ﻃﻮل ﭼﺮﺧﻪ اﻧﺠﺎم دﻫﻨﺪ و‬
‫آنﻫﺎ را ﺟﺪا ﮐﺮده‪ ،‬در ﻓﻬﺮﺳﺖ ﭼﺮﺧﻪ )‪ (Sprint Backlog‬ﻗﺮار ﻣﯽدﻫﻨﺪ‪ .‬اﯾﻦ ﮐﺎر ﺑﺴﯿﺎر ﻣﻔﯿﺪ اﺳﺖ‪ ،‬زﯾﺮا ﻓﻬﺮﺳﺖ‬
‫ﻣﺤﺼﻮل ﻣﻌﻤﻮﻻ ﺑﺴﯿﺎر ﺑﻠﻨﺪ اﺳﺖ‪ ،‬وﻟﯽ ﻓﻬﺮﺳﺖ ﭼﺮﺧﻪ ﮐﻮﺗﺎه و ﻣﺘﻤﺮﮐﺰ ﺑﺮ آنﭼﻪ ﻗﺮار اﺳﺖ در ﻃﻮل ﭼﺮﺧﻪ اﻧﺠﺎم ﺷﻮد‪.‬‬

‫ﺑﺮای ﭼﺮﺧﻪ ﻫﺪﻓﯽ ﻧﯿﺰ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮد ﺗﺎ ﺑﻪ ﺷﮑﻠﯽ ﮐﻼن اﻗﺪاﻣﺎت را ﻫﻤﺴﻮ ﮐﻨﺪ‪ .‬اﯾﻦ ﻫﺪف در ﻓﻬﺮﺳﺖ ﭼﺮﺧﻪ‬
‫ﺛﺒﺖ ﻣﯽﺷﻮد‪ .‬ﻫﻤﺎﻫﻨﻨﺪ آن‪ ،‬ﻫﺪف ﮐﻠﯽ ﻣﺤﺼﻮل ﻧﯿﺰ در ﻓﻬﺮﺳﺖ ﻣﺤﺼﻮل ﺛﺒﺖ ﻣﯽﺷﻮد‪.‬‬

‫ﭘﺲ از ﭘﺎﯾﺎن ﺑﺮﻧﺎﻣﻪرﯾﺰی ﭼﺮﺧﻪ‪ ،‬ﮐﺎر ﺳﺎﺧﺖ ﻣﺤﺼﻮل آﻏﺎز ﻣﯽﺷﻮد‪ .‬ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﻗﺎﺑﻠﯿﺖﻫﺎی ﺗﺎزه را ﻣﯽﺳﺎزﻧﺪ‪،‬‬
‫اﺳﮑﺮام ﻣﺴﺘﺮ ﺑﻪ ﺣﻞ ﭼﺎﻟﺶﻫﺎﯾﺸﺎن ﮐﻤﮏ ﻣﯽﮐﻨﺪ‪ ،‬و ﻣﺪﯾﺮ ﻣﺤﺼﻮل ﻫﻢ ﺗﻮﺿﯿﺢﻫﺎی ﺗﮑﻤﯿﻠﯽ اراﻳﻪ ﻣﯽﮐﻨﺪ‪ .‬در ﻃﻮل ﮐﺎر‬
‫ﻧﯿﺰ ﺟﻠﺴﻪﻫﺎی ‪ ۱۵‬دﻗﯿﻘﻪای روزاﻧﻪای ﺑﻪ ﻧﺎم ‪ Daily Scrum‬وﺟﻮد دارد ﮐﻪ در آن اﻋﻀﺎی ﺗﯿﻢ ﮔﺮد ﻫﻢ ﻣﯽآﯾﻨﺪ و ﺗﮏﺗﮏ‬
‫ﺑﻪﮐﻮﺗﺎﻫﯽ ﺗﻮﺿﯿﺢ ﻣﯽدﻫﻨﺪ ﮐﻪ در روز ﮔﺬﺷﺘﻪ ﭼﻪ ﮐﺮدهاﻧﺪ‪ ،‬در روز ﭘﯿﺶ رو ﭼﻪ ﺧﻮاﻫﻨﺪ ﮐﺮد‪ ،‬و ﺑﺎ ﭼﻪ دﺷﻮاریﻫﺎﯾﯽ‬
‫ﻣ ﻤ ﮑ ﻦ ا ﺳ ﺖ ر و ﺑ ﺮ و ﺷ ﻮ ﻧ ﺪ‪.‬‬

‫وﻗﺘﯽ ﻣﺪت ﻣﻘﺮر ﭼﺮﺧﻪ ﺑﻪ ﭘﺎﯾﺎن ﺑﺮﺳﺪ‪ ،‬از ﮐﺎر دﺳﺖ ﻣﯽﮐﺸﯿﻢ‪ ،‬ﺣﺘﯽ اﮔﺮ ﻫﻤﻪ ﻗﺎﺑﻠﯿﺖﻫﺎی ﻓﻬﺮﺳﺖ ﭼﺮﺧﻪ ﺑﻪ ﭘﺎﯾﺎن‬
‫ﻧﺮﺳﯿﺪه ﺑﺎﺷﻨﺪ‪ .‬درﺑﺎره ﭘﺎﯾﺎن ﯾﺎﻓﺘﻦ آﯾﺘﻢﻫﺎ ﻧﯿﺰ ﺑﺎﯾﺪ ﺣﺴﺎس ﺑﻮد‪ ،‬زﯾﺮا اﮔﺮ آﯾﺘﻤﯽ واﻗﻌﺎ ﺗﮑﻤﯿﻞ ﻧﺸﺪه ﺑﺎﺷﺪ ﻧﻤﯽﺗﻮاﻧﺪ‬
‫ﺑﺎزﺧﻮرد ﻣﻨﺎﺳﺒﯽ اﯾﺠﺎد ﮐﻨﺪ و ﺑﺮای ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﭘﺮوژه ﻣﺎﻧﻊ اﯾﺠﺎد ﺧﻮاﻫﺪ ﮐﺮد‪ .‬از اﯾﻦ رو‪ ،‬آﻧﭽﻪ از آﯾﺘﻢﻫﺎی ﮐﺎﻣﻞ ﺷﺪه‬

‫— ‪— 48‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﻧﺘﻈﺎر دارﯾﻢ را در ﺳﻨﺪی ﺑﺎ ﻧﺎم ‪ Definition of Done‬ﻣﺴﺘﻨﺪ ﮐﺮده‪ ،‬ﻫﻤﻮاره از آن ﮐﻤﮏ ﻣﯽﮔﯿﺮﯾﻢ‪ .‬ﻫﺮ آﯾﺘﻤﯽ ﮐﻪ ﮐﺎﻣﻼ‬
‫ﺑﻪ ﭘﺎﯾﺎن ﻧﺮﺳﯿﺪه ﺑﺎﺷﺪ را ﺑﻪ ﻓﻬﺮﺳﺖ ﻣﺤﺼﻮل ﺑﺎزﻣﯽﮔﺮداﻧﯿﻢ ﺗﺎ در ﭼﺮﺧﻪﻫﺎی ﺑﻌﺪی ﮐﺎﻣﻞ ﺷﻮد و ﭘﺲ از آن ﺑﻪ ﺳﺮاغ دو‬
‫ﺟﻠﺴﻪ ﭘﺎﯾﺎﻧﯽ ﭼﺮﺧﻪ ﻣﯽروﯾﻢ‪.‬‬

‫ﺑﺮای ﻧﺨﺴﺘﯿﻦ ﺟﻠﺴﻪ ﭘﺎﯾﺎن ﭼﺮﺧﻪ‪ ،‬ﮐﻪ ﺣﺪاﮐﺜﺮ ‪ ۴‬ﺳﺎﻋﺖ اﺳﺖ‪ ،‬از ذیﻧﻔﻌﺎن ﺑﯿﺮوﻧﯽ دﻋﻮت ﻣﯽﮐﻨﯿﻢ و ﻫﻤﺮاﻫﺸﺎن‬
‫ﻣﺤﺼﻮل ﭼﺮﺧﻪ را ﻣﺮور ﮐﺮده‪ ،‬ﺑﺎزﺧﻮردی ﻧﺨﺴﺘﯿﻦ درﯾﺎﻓﺖ ﻣﯽﮐﻨﯿﻢ‪ .‬اﯾﻦ ﺑﺎزﺧﻮرد ﺑﺴﯿﺎر ﻣﺤﺪود اﺳﺖ و ﻻزم اﺳﺖ ﮐﻪ‬
‫اﻓﺰون ﺑﺮ آن ﻣﺤﺼﻮل ﺑﻪ ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻒ در اﺧﺘﯿﺎر ﻧﻤﺎﯾﻨﺪﮔﺎن ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﻫﻢ ﻗﺮار ﺑﮕﯿﺮد ﺗﺎ در ﻓﺮﺻﺖ ﺑﯿﺸﺘﺮ ﺑﺎ‬
‫آن ﮐﺎر ﮐﻨﻨﺪ و ﺑﺎزﺧﻮردﻫﺎی ﻣﺴﺘﻘﯿﻢ و ﻏﯿﺮﻣﺴﺘﻘﯿﻢ آن را ﮔﺮدآوری ﮐﻨﯿﻢ‪.‬‬

‫در ﺟﻠﺴﻪ دوم ﭘﺎﯾﺎن ﭼﺮﺧﻪ‪ ،‬ﮐﻪ ﺣﺪاﮐﺜﺮ ‪ ۳‬ﺳﺎﻋﺖ اﺳﺖ‪ ،‬ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ ﮔﺮد ﻫﻢ ﻣﯽآﯾﻨﺪ و ﭘﺲ از ﺑﺮرﺳﯽ روﻧﺪ ﮐﺎر‬
‫ﺧﻮد در ﻃﻮل ﭼﺮﺧﻪ‪ ،‬ﻣﯽﮐﻮﺷﻨﺪ راﻫﯽ ﺑﺮای ﺑﻬﺒﻮد ﭘﺮوژه در ﭼﺮﺧﻪ ﺑﻌﺪ ﭘﯿﺪا ﮐﻨﻨﺪ‪.‬‬

‫‪DSDM .4.3‬‬

‫ﻣﺘﺪوﻟﻮژی ‪ DSDM‬ﻧﯿﺰ ﯾﮑﯽ از روشﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ ﻧﺨﺴﺖ اﺳﺖ‪ .‬اﯾﻦ ﺳﯿﺴﺘﻢ‪ ،‬ﺑﺮﺧﻼف ﺑﯿﺸﺘﺮ روشﻫﺎی ﭼﺎﺑﮏ‪،‬‬
‫ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺰرگ و ﭘﯿﭽﯿﺪه ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ و ﺳﺎﺧﺘﺎر آن ﻧﯿﺰ از ﭘﺮﯾﻨﺲ‪ ۲‬اﻟﻬﺎم ﮔﺮﻓﺘﻪ اﺳﺖ‪.‬‬

‫‪ DSDM‬ﺑﺮای ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ‪ .‬ﻣﯽﺗﻮاﻧﯿﺪ آن را ﺑﺮای ﺳﺎﯾﺮ ﭘﺮوژهﻫﺎ ﻧﯿﺰ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﮐﻨﯿﺪ‪،‬‬
‫وﻟ ﯽ ا ﯾ ﻦ ﮐ ﺎ ر ﭼ ﻨ ﺪ ا ن ﺳ ﺎ د ه ﻧ ﺨ ﻮ ا ﻫ ﺪ ﺑ ﻮ د‪.‬‬

‫‪ .1.4.3‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‬

‫ﺳﺎﺧﺘﺎر ﺗﯿﻢ ‪ DSDM‬ﺑﺴﯿﺎر ﺟﺎﻟﺐ‪ ،‬وﻟﯽ ﭘﯿﭽﯿﺪه اﺳﺖ‪:‬‬

‫ﺳﻄﺢ ﭘﺮوژه‪ :‬ﻧﻘﺶﻫﺎﯾﯽ ﮐﻪ ﺑﺮ ﺟﻨﺒﻪﻫﺎی ﮐﻼن ﭘﺮوژه و ﯾﮑﭙﺎرﭼﮕﯽ آن ﻣﺘﻤﺮﮐﺰ ﻫﺴﺘﻨﺪ در اﯾﻦ ﺳﻄﺢ ﻗﺮار دارﻧﺪ‪.‬‬
‫ﺣﺎﻣﯽ ﮐﺴﺐ و ﮐﺎر‪ :‬اﯾﻦ ﻓﺮد ﻣﺪﯾﺮی ارﺷﺪ اﺳﺖ ﮐﻪ ﻣﺴﺌﻮﻟﯿﺖﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ اﻃﻤﯿﻨﺎن داﺷﺘﻦ از ﺗﻮﺟﯿﻪﭘﺬﯾﺮی‬
‫ﭘﺮوژه و ﻓﺮاﻫﻢ ﮐﺮدن ﻣﻨﺎﺑﻊ ﻣﺎﻟﯽ را ﺑﺮ دوش دارد‪.‬‬
‫اﯾﺪهﭘﺮداز ﮐﺴﺐ و ﮐﺎر‪ :‬اﯾﻦ ﻓﺮد ﻧﯿﺎزﻫﺎی ﮐﺴﺐ و ﮐﺎر را ﺑﺮای ﺳﻄﺢ ﭘﺮوژه ﺗﻔﺴﯿﺮ ﻣﯽﮐﻨﺪ‪.‬‬
‫ﻣﺪﯾﺮ ﭘﺮوژه‪ :‬اﯾﻦ ﻓﺮد ﻣﺴﺌﻮل ﻣﺪﯾﺮﯾﺖ روزﻣﺮه ﭘﺮوژه اﺳﺖ‪.‬‬
‫ﻫﻤﺎﻫﻨﮓﮐﻨﻨﺪه ﻣﺴﺎﯾﻞ ﻓﻨﯽ‪ :‬اﯾﻦ ﻓﺮد ﺑﺎ ﺗﯿﻢﻫﺎ در ﺗﻤﺎس اﺳﺖ و ﺑﻪ آنﻫﺎ ﮐﻤﮏ ﻣﯽﮐﻨﺪ ﮐﻪ ﻣﻌﻤﺎری ﺳﺎزﮔﺎر‬
‫و ﮐﺎرآﻣﺪی داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﺳﻄﺢ ﺗﯿﻢ‪ :‬در اﯾﻦ ﺳﻄﺢ ﭼﻨﺪﯾﻦ ﺗﯿﻢ اﺟﺮاﯾﯽ وﺟﻮد دارد ﮐﻪ ﺳﺎﺧﺖ ﻣﺤﺼﻮل را ﺑﺮ دوش دارﻧﺪ‪.‬‬
‫رﻫﺒﺮ ﺗﯿﻢ‪ :‬اﯾﻦ ﻓﺮد رﻫﺒﺮی و ﻫﻤﺎﻫﻨﮕﯽﻫﺎی ﺗﯿﻢ را ﺑﺮ دوش دارد و ﺑﺎ ﻣﺪﯾﺮ ﭘﺮوژه در ﺗﻤﺎس اﺳﺖ‪.‬‬
‫ﺳﻔﯿﺮ ﮐﺴﺐ و ﮐﺎر‪ :‬اﯾﻦ ﻓﺮد ﺟﻨﺒﻪﻫﺎی ﮐﺴﺐ و ﮐﺎر ﻣﺤﺼﻮل را ﺑﺮای اﻋﻀﺎی ﺗﯿﻢ ﺗﻔﺴﯿﺮ ﻣﯽﮐﻨﺪ و ﺑﺎ‬
‫اﯾﺪهﭘﺮداز ﮐﺴﺐ و ﮐﺎر در ﺗﻤﺎس اﺳﺖ‪.‬‬
‫ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن‪ :‬اﯾﻦ اﻓﺮاد ﻣﺤﺼﻮل ﭘﺮوژه را ﻣﯽﺳﺎزﻧﺪ‪.‬‬
‫آزﻣﺎﯾﺶﮐﻨﻨﺪه ﻣﺤﺼﻮل‪ :‬اﯾﻦ اﻓﺮاد ﻣﺴﺌﻮﻟﯿﺖ آزﻣﺎﯾﺶ ﻣﺤﺼﻮل و ﮐﻨﺘﺮل ﮐﯿﻔﯿﺖ آن را ﺑﺮ دوش دارﻧﺪ‪.‬‬

‫— ‪— 49‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺳﻄﺢ ﭘﺸﺘﯿﺒﺎﻧﯽ‪ :‬در اﯾﻦ ﺳﻄﺢ ﻧﻘﺶﻫﺎﯾﯽ وﺟﻮد دارﻧﺪ ﮐﻪ ﺑﻪ ﻫﻤﻪ ﺗﯿﻢﻫﺎ ﺧﺪﻣﺎت ﻣﯽدﻫﻨﺪ‪.‬‬
‫ﻣﺸﺎور ﻓﻨﯽ‪ :‬اﯾﻦ اﻓﺮاد درﺑﺎره ﻣﺴﺎﯾﻞ ﻓﻨﯽ وﯾﮋه )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﻣﻨﯿﺖ ﻧﺮماﻓﺰار( ﺑﻪ ﺗﯿﻢﻫﺎ ﻣﺸﺎوره ﻣﯽدﻫﻨﺪ‪.‬‬
‫ﻣﺸﺎور ﮐﺴﺐ و ﮐﺎر‪ :‬اﯾﻦ اﻓﺮاد درﺑﺎره ﻣﺴﺎﯾﻞ وﯾﮋه در ﮐﺴﺐ و ﮐﺎر )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻫﻤﺎﻫﻨﮕﯽ ﺑﺎ ﻗﻮاﻧﯿﻦ( ﺑﻪ‬
‫ﺗﯿﻢﻫﺎ ﻣﺸﺎوره ﻣﯽدﻫﻨﺪ‪.‬‬
‫ﻣﺮﺑﯽ ‪ :DSDM‬اﯾﻦ ﻓﺮد ﺑﻪ ﺗﯿﻢﻫﺎ ﮐﻤﮏ ﻣﯽﮐﻨﺪ ﮐﻪ از ‪ DSDM‬ﺑﻪدرﺳﺘﯽ اﺳﺘﻔﺎده ﮐﻨﻨﺪ‪.‬‬
‫ﺗﺴﻬﯿﻞﮐﻨﻨﺪه‪ :‬اﯾﻦ ﻓﺮد ﮐﺎرﮔﺎهﻫﺎ و ﺟﻠﺴﻪﻫﺎی ﺗﯿﻢﻫﺎ را ﺗﺴﻬﯿﻞﮔﺮی ﻣﯽﮐﻨﺪ‪.‬‬

‫اﻓﺰون ﺑﺮ ﻧﻘﺶﻫﺎی ﮔﻔﺘﻪ ﺷﺪه‪ ،‬ﻧﻘﺸﯽ ﺑﺎ ﻧﺎم ﺗﺤﻠﯿﻞﮔﺮ ﮐﺴﺐ و ﮐﺎر ﻧﯿﺰ وﺟﻮد دارد ﮐﻪ ﻫﻢ ﻋﻀﻮی از ﺳﻄﺢ ﭘﺮوژه اﺳﺖ‬
‫و ﻫﻢ ﺳﻄﺢ ﺗﯿﻢ‪ ،‬ﻫﻢ ﺗﺨﺼﺺ ﮐﺴﺐ و ﮐﺎر دارد و ﻫﻢ ﺗﺨﺼﺺ ﻓﻨﯽ‪ .‬اﯾﻦ ﻧﻘﺶ ﺟﻨﺒﻪﻫﺎی ﻣﺨﺘﻠﻒ ﭘﺮوژه را ﺑﻪ ﻫﻢ ﭘﯿﻮﻧﺪ‬
‫ﻣﯽزﻧﺪ‪.‬‬

‫‪ .2.4.3‬ﻓﺮآﯾﻨﺪ‬

‫ﮐﺎر در ‪ DSDM‬ﺑﺎ ﻓﺎز ﭘﯿﺸﺎﭘﺮوژه آﻏﺎز ﻣﯽﺷﻮد‪ .‬در اﯾﻦ ﻓﺎز ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه را ﺑﻪﮐﻮﺗﺎﻫﯽ ﺑﺮرﺳﯽ و ﻧﺘﯿﺠﻪ را ﻫﻤﺮاه ﺑﺎ‬
‫اﻃﻼﻋﺎت ﺗﮑﻤﯿﻠﯽ در ﺳﻨﺪی ﺑﺎ ﻧﺎم ‪ terms of reference‬ذﺧﯿﺮه ﻣﯽﮐﻨﯿﻢ‪ .‬ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪﮔﺎن ﺑﺎ ﮐﻤﮏ اﯾﻦ اﻃﻼﻋﺎت ﻓﺮﻣﺎن‬
‫ﺗﻮﻗﻒ ﮐﺎر ﯾﺎ اﺟﺮای ﻓﺎز ﺑﻌﺪی را ﻣﯽدﻫﻨﺪ‪.‬‬

‫ﻓﺎز ﺑﻌﺪی‪ ،‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮی اﺳﺖ‪ .‬در اﯾﻦ ﻓﺎز زﻣﺎن ﺑﯿﺸﺘﺮی ﺻﺮف ﺷﻨﺎﺳﺎﯾﯽ ﭘﺮوژه و ﺟﻨﺒﻪﻫﺎی ﮐﺴﺐ و ﮐﺎر‪ ،‬ﻓﻨﯽ‪ ،‬و‬
‫ﻣﺪﯾﺮﯾﺘﯽ آن ﻣﯽﮐﻨﯿﻢ‪ .‬اﻃﻼﻋﺎت ﮔﺮدآوری ﺷﺪه در ﺳﻨﺪ ارزﯾﺎﺑﯽ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ذﺧﯿﺮه ﻣﯽﺷﻮﻧﺪ و ﺑﺮای ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪﮔﺎن‬
‫ﻓﺮﺳﺘﺎده ﻣﯽﺷﻮﻧﺪ ﺗﺎ ﻓﺮﻣﺎن ﺗﻮﻗﻒ ﭘﺮوژه ﯾﺎ اﺟﺮای ﻓﺎز ﺑﻌﺪ را ﺑﺪﻫﻨﺪ‪.‬‬

‫ﻓﺎز ﺳﻮم ﺷﺎﻟﻮده اﺳﺖ‪ .‬در اﯾﻦ ﻓﺎز ﺑﺮﻧﺎﻣﻪ ﮐﻼن ﭘﺮوژه را آﻣﺎده ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﺷﺎﻟﻮده ﭘﺮوژه ﺑﻪ ﺷﻤﺎر ﺧﻮاﻫﺪ رﻓﺖ‪ .‬ﺑﺮ ﭘﺎﯾﻪ‬
‫ﺑﺮﻧﺎﻣﻪ ﮐﻼن ﻣﯽﺗﻮان درک ﺑﻬﺘﺮی از ﺗﻮﺟﯿﻪﭘﺬﯾﺮی آن ﻧﯿﺰ ﭘﯿﺪا ﮐﺮد و ﻫﻤﻪ اﯾﻦ اﻃﻼﻋﺎت در ﻗﺎﻟﺐ ﺳﻨﺪی ﺑﺎ ﻧﺎم ﭼﮑﯿﺪه‬
‫ﺷﺎﻟﻮده در اﺧﺘﯿﺎر ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪﮔﺎن ﻗﺮار ﻣﯽﮔﯿﺮد‪.‬‬

‫اﮔﺮ ﭘﺮوژه ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﺑﺎﺷﺪ‪ ،‬آن را در ﻓﺎزی ﺗﮑﺮار ﺷﻮﻧﺪه ﺑﺎ ﻧﺎم ﺗﻮﺳﻌﻪ ﺗﮑﺎﻣﻠﯽ اﺟﺮا ﺧﻮاﻫﯿﻢ ﮐﺮد‪ .‬در ﻫﺮ ﭼﺮﺧﻪ اﯾﻦ ﻓﺎز‬
‫ﻧﺴﺨﻪ ﺗﺎزهای از ﻣﺤﺼﻮل ﭘﺮوژه آﻣﺎده ﻣﯽﺷﻮد و ﻣﺎﻧﻨﺪ ﻫﻤﻪ ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﺑﺮای ﮔﺮدآوری ﺑﺎزﺧﻮرد و روﺷﻦ ﮐﺮدن‬
‫ﻣ ﺴ ﯿ ﺮ ﭘ ﯿ ﺶ ر و ﺑ ﻪ ﮐ ﺎ ر ﻣ ﯽ ر و د‪.‬‬

‫ﻓﺎز دﯾﮕﺮ‪ ،‬اﻧﺘﺸﺎر اﺳﺖ‪ .‬اﯾﻦ ﻓﺎز را ﻣﯽﺗﻮان ﭘﺲ از ﻫﺮ ﭼﺮﺧﻪ ﺗﻮﺳﻌﻪ ﺗﮑﺎﻣﻠﯽ ﯾﺎ ﺑﺎ ﺑﺴﺎﻣﺪی ﮐﻤﺘﺮ ﺗﮑﺮار ﮐﺮد‪ .‬در ﻫﺮ ﺗﮑﺮار‪،‬‬
‫ﺗﺎزهﺗﺮﯾﻦ ﻧﺴﺨﻪ ﻧﺮماﻓﺰار در اﺧﺘﯿﺎر ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﻗﺮار ﻣﯽﮔﯿﺮد‪.‬‬

‫در ‪ DSDM‬ﻓﺎز ﺟﺪاﮔﺎﻧﻪای ﺑﺮای ﭘﺎﯾﺎن ﭘﺮوژه وﺟﻮد ﻧﺪارد و ﺑﺨﺸﯽ از آن از اﯾﻦ روﺳﺖ ﮐﻪ ﺑﺴﯿﺎری از ﮐﺎرﻫﺎی ﭘﺎﯾﺎﻧﯽ ﺑﻪ‬
‫ﺗ ﺪ ر ﯾ ﺞ د ر ﻓ ﺎ ز ا ﻧ ﺘ ﺸ ﺎ ر ا ﻧ ﺠ ﺎ م ﻣ ﯽ ﺷ ﻮ ﻧ ﺪ‪.‬‬

‫واﭘﺴﯿﻦ ﻓﺎز‪ ،‬ﭘﺴﺎﭘﺮوژه اﺳﺖ ﮐﻪ در آن ﻣﻨﺎﻓﻊ ﻣﺤﺼﻮل ﭘﺲ از ﭘﺎﯾﺎن ﭘﺮوژه رﺻﺪ ﻣﯽﺷﻮﻧﺪ‪.‬‬

‫ﻣﺪتزﻣﺎن ﭘﺮوژه در ‪ DSDM‬ﺛﺎﺑﺖ اﺳﺖ و ﺣﺘﯽ ﯾﮏ روز ﻫﻢ ﻃﻮﻻﻧﯽﺗﺮ ﻧﻤﯽﺷﻮد‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ﭘﺮوژه را ﺗﺎ زﻣﺎﻧﯽ ﮐﻪ‬
‫ﻫﻤﻪ ﻗﺎﺑﻠﯿﺖﻫﺎ ﺳﺎﺧﺘﻪ ﺷﻮﻧﺪ اداﻣﻪ ﻧﻤﯽدﻫﯿﻢ‪ ،‬ﺑﻠﮑﻪ آن را ﺗﺎ زﻣﺎن ﻣﻘﺮر اداﻣﻪ داده‪ ،‬ﺣﺪاﮐﺜﺮ ﻗﺎﺑﻠﯿﺖﻫﺎﯾﯽ ﮐﻪ اﻣﮑﺎنﭘﺬﯾﺮ‬

‫— ‪— 50‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺎﺷﺪ را ﻣﯽﺳﺎزﯾﻢ‪ .‬ﺑﺮای ﺳﺎﺧﺖ ﻣﺤﺼﻮل در ﭼﻨﯿﻦ ﺳﯿﺴﺘﻤﯽ از ﺗﮑﻨﯿﮏ اوﻟﻮﻟﯿﺖﺑﻨﺪی ﻣﺴﮑﻮ )‪ (MoSCoW‬اﺳﺘﻔﺎده‬
‫ﻣﯽﺷﻮد‪ .‬ﻋﺒﺎرت ‪ MoSCoW‬در اﯾﻦ ﺗﮑﻨﯿﮏ ﻣﺨﻔﻒ اﯾﻦ ﻣﻮارد اﺳﺖ‪:‬‬

‫‪ :(M)ust-have‬ﻗﺎﺑﻠﯿﺖﻫﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﻧﺎﮔﺰﯾﺮ ﺑﺎﯾﺪ در ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﺑﺎﺷﻨﺪ و ﺑﺪون آنﻫﺎ اﻣﮑﺎن اﺳﺘﻔﺎده از‬
‫ﻣﺤﺼﻮل وﺟﻮد ﻧﺨﻮاﻫﺪ داﺷﺖ‪ .‬ﻣﻮارد اﻣﻨﯿﺘﯽ در ﯾﮏ ﻧﺮماﻓﺰار ﺑﺎﻧﮑﯽ ﻧﻤﻮﻧﻪای از اﯾﻦﮔﻮﻧﻪ ﻗﺎﺑﻠﯿﺖ اﺳﺖ‪.‬‬
‫‪ :(S)hould-have‬ﻗﺎﺑﻠﯿﺖﻫﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺮای ﻣﺤﺼﻮل ﮐﺎﻣﻼ ﻻزم ﻫﺴﺘﻨﺪ و ﺑﺪون آنﻫﺎ ﺑﻪ ﻣﺸﮑﻞ ﺑﺮﺧﻮاﻫﯿﻢ‬
‫ﺧﻮرد‪ ،‬وﻟﯽ ﻣﯽﺗﻮان ﺑﺮای آن ﻣﺸﮑﻞﻫﺎ راﻫﮑﺎرﻫﺎﯾﯽ ﯾﺎﻓﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮان ﺑﻪ روﺷﯽ دﺳﺘﯽ ﺑﻪ ﻫﺪف‬
‫د ﺳ ﺖ ﯾ ﺎ ﻓ ﺖ‪.‬‬
‫‪ : (C)ould-have‬اﯾﻦﻫﺎ ﻗﺎﺑﻠﯿﺖﻫﺎی ﺟﺎﻟﺒﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﯽﺗﻮاﻧﻨﺪ ارزش ﻣﺤﺼﻮل را اﻓﺰاﯾﺶ دﻫﻨﺪ‪ ،‬وﻟﯽ ﺑﺪون‬
‫آنﻫﺎ ﻣﺸﮑﻠﯽ ﻧﯿﺰ ﺑﻪ وﺟﻮد ﻧﺨﻮاﻫﺪ آﻣﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﻣﮑﺎن اﻧﺘﺨﺎب ﻣﯿﺎن ﺗﻢ رﻧﮓ روﺷﻦ و ﺗﯿﺮه در ﻧﺮماﻓﺰار ﺑﺎﻧﮑﯽ‬
‫ا ﯾ ﻦ ﭼ ﻨ ﯿ ﻦ ا ﺳ ﺖ‪.‬‬
‫‪ :(W)on’t-have‬ﻋﻨﺎﺻﺮی ﮐﻪ ارزﺷﯽ اﺿﺎﻓﻪ ﻧﻤﯽﮐﻨﻨﺪ ﯾﺎ ﺑﻪ ﻫﺮ دﻟﯿﻞ دﯾﮕﺮ ﻣﺎﯾﻞ ﻧﯿﺴﺘﯿﻢ در ﻧﺮماﻓﺰار وﺟﻮد داﺷﺘﻪ‬
‫ﺑ ﺎ ﺷ ﻨ ﺪ‪.‬‬

‫در ﻓﺎزﻫﺎی ﺗﻮﺟﯿﻪﭘﺬﯾﺮی و ﺷﺎﻟﻮده‪ ،‬ﻓﻬﺮﺳﺘﯽ از ﻗﺎﺑﻠﯿﺖﻫﺎی ﮐﻠﯽ ﻧﺮماﻓﺰار ﻓﺮاﻫﻢ ﮐﺮده‪ ،‬ﺑﺎ ﮐﻤﮏ روش ﻣﺴﮑﻮ‬
‫اوﻟﻮﻟﯿﺖﺑﻨﺪی ﻣﯽﮐﻨﯿﻢ‪ .‬اﯾﻦ ﻓﻬﺮﺳﺖ اوﻟﻮﯾﺖﺑﻨﺪی ﺷﺪه ﻗﺎﺑﻠﯿﺖﻫﺎ ﺑﻪﺗﺪرﯾﺞ در ﻫﻨﮕﺎم ﮐﺎر ﺗﻔﺼﯿﻠﯽﺗﺮ ﻣﯽﺷﻮد‪.‬‬

‫ﺑﺮای اﯾﻦﮐﻪ ﭘﺮوژه اﻧﻌﻄﺎفﭘﺬﯾﺮی ﺑﻪاﻧﺪازه داﺷﺘﻪ ﺑﺎﺷﺪ ﻻزم اﺳﺖ ﮐﻪ ﺣﺠﻢ ﻗﺎﺑﻠﯿﺖﻫﺎی )‪ (M‬ﮐﻤﺘﺮ از ‪ ٪۶۰‬ﺑﺎﺷﺪ و‬
‫ﺣﺪاﻗﻞ ‪ ٪۲۰‬از آﯾﺘﻢﻫﺎ از ﻧﻮع )‪ ( C‬ﺑﺎﺷﻨﺪ‪ .‬وﻗﺘﯽ ﻣﺪتزﻣﺎن ﻻزم ﺑﺮای ﭘﺮوژه ﺑﺮآورد ﻣﯽﺷﻮد‪،‬‬

‫ﺑﺎﯾﺪ در ﺣﺎﻟﺖ ﺧﻮشﺑﯿﻨﺎﻧﻪ ﺑﺮای ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن ﻫﻤﻪ آﯾﺘﻢﻫﺎ ﮐﺎﻓﯽ ﺑﺎﺷﺪ‪ ،‬و‬
‫در ﺣﺎﻟﺖ ﺑﺪﺑﯿﻨﺎﻧﻪ ﺑﺮای ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن آﯾﺘﻢﻫﺎی )‪ (M‬ﮐﺎﻓﯽ ﺑﺎﺷﺪ‪.‬‬

‫در ﻫﻨﮕﺎم ﮐﺎر‪ ،‬وﺿﻌﯿﺖ ﭘﺮوژه داﯾﻤﺎ ارزﯾﺎﺑﯽ ﻣﯽﺷﻮد و ﭘﯿﺶﺑﯿﻨﯽ ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﺗﺎ زﻣﺎن ﭘﺎﯾﺎن ﭘﺮوژه ﭼﻪ آﯾﺘﻢﻫﺎﯾﯽ ﺗﮑﻤﯿﻞ‬
‫ﺧﻮاﻫﻨﺪ ﺷﺪ‪ .‬اﮔﺮ ﭘﯿﺶﺑﯿﻨﯽ ﮐﻨﯿﻢ ﮐﻪ ﺗﺎ ﭘﺎﯾﺎن ﭘﺮوژه اﻣﮑﺎن ﺗﮑﻤﯿﻞ ﻫﻤﻪ )‪(M‬ﻫﺎ وﺟﻮد ﻧﺨﻮاﻫﺪ داﺷﺖ‪ ،‬ﺑﺎﯾﺪ ﻣﺴﺌﻠﻪ را ﺑﻪ‬
‫ﻣﺪﯾﺮان ارﺷﺪ اﻋﻼم ﮐﻨﯿﻢ ﮐﻪ ﯾﺎ ﭘﺮوژه را ﻟﻐﻮ ﮐﻨﻨﺪ ﯾﺎ ﺗﻐﯿﯿﺮﻫﺎﯾﯽ ﺑﻨﯿﺎدﯾﻦ در آن ﺑﺪﻫﻨﺪ‪.‬‬

‫ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬در ﭼﻨﯿﻦ ﭘﺮوژهﻫﺎﯾﯽ ﺗﻀﻤﯿﻦ ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﻫﻤﻪ )‪(M‬ﻫﺎ ﺗﮑﻤﯿﻞ ﺧﻮاﻫﻨﺪ ﺷﺪ‪ ،‬ﮐﻮﺷﺶ ﻣﯽﮐﻨﯿﻢ )‪(S‬ﻫﺎ را‬
‫ﻧﯿﺰ ﮐﺎﻣﻞ ﮐﻨﯿﻢ‪ ،‬و اﮔﺮ ﺗﻮاﻧﺴﺘﯿﻢ )‪(C‬ﻫﺎ را ﻫﻢ ﺧﻮاﻫﯿﻢ ﺳﺎﺧﺖ‪.‬‬

‫— ‪— 51‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ . 4‬ﺗ ﻘ ﻮﯾ ﺖ ﻣﺘ ﺪ وﻟ ﻮژ ی‬

‫ﺑﺮﺧﯽ از ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را در ﻓﺼﻞ ﭘﯿﺶ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪ .‬ﻣﺘﺪوﻟﻮژیﻫﺎ ﺑﺎ ﻫﺪف ﻧﺸﺎن دادن ﻣﺴﯿﺮ در‬
‫ﭘﺮوژه ﺳﺎﺧﺘﻪ ﺷﺪهاﻧﺪ‪ ،‬ﮐﻪ ﺑﺎ ﻫﺪف راﻫﻨﻤﺎﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک ﻣﺘﻔﺎوت اﺳﺖ‪ .‬ﯾﮑﯽ از ﻫﺪفﻫﺎی اﺻﻠﯽ راﻫﻨﻤﺎﻫﺎ ﮐﻤﮏ ﺑﻪ‬
‫ﺗ ﻘ ﻮ ﯾ ﺖ ﻣ ﺘ ﺪ وﻟ ﻮ ژ ی ﻫ ﺎ ﺳ ﺖ ‪ ،‬ﮐ ﻪ ﻣ ﻮ ﺿ ﻮ ع ا ﯾ ﻦ ﻓ ﺼ ﻞ ا ﺳ ﺖ‪.‬‬

‫ﭘﻢﺑﺎک ‪ ۷‬ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﻣﺘﻌﺪدی دارد ﮐﻪ ﻫﺮﮐﺪام ﯾﮑﯽ از ﻣﻮﺿﻮعﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﺪ‪:‬‬

‫ذ یﻧ ﻔ ﻌﺎ ن‬
‫ﺗﯿ ﻢ‬
‫ﭼﺮﺧﻪ ﺣﯿﺎت و روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی‬
‫اﺟﺮا‬
‫ارزﯾﺎﺑﯽ ﭘﯿﺸﺮﻓﺖ‬
‫ﺗ ﺤ ﻮﯾ ﻞ‬
‫ﻋ ﺪ م ﻗ ﻄ ﻌﯿ ﺖ‬

‫ﻣﺘﺪوﻟﻮژیﻫﺎ ﻣﻌﻤﻮﻻ ﻫﻤﻪ اﯾﻦ ﺣﻮزهﻫﺎ را ﭘﻮﺷﺶ ﻣﯽدﻫﻨﺪ‪ ،‬ﻫﺮﭼﻨﺪ ﮔﺎﻫﯽ ﺿﻤﻨﯽ و ﺑﺎ ﺣﺪاﻗﻞﻫﺎﯾﯽ ﮐﻪ از دﯾﺪﺷﺎن در‬
‫ﺑﯿﺸﺘﺮ ﭘﺮوژهﻫﺎ ﻻزم اﺳﺖ‪ .‬از اﯾﻦ رو‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﻫﺮﯾﮏ از اﯾﻦ ﺣﻮزهﻫﺎ را ﺑﺮرﺳﯽ ﮐﺮده‪ ،‬ﺷﯿﻮه ﭘﯿﺎدهﺳﺎزی آن را ﺑﺎ‬
‫ﻧﯿﺎزﻫﺎی ﭘﺮوژه ﺳﻨﺠﯿﺪه‪ ،‬ﺑﺴﺘﻪ ﺑﻪ ﻧﯿﺎز ﺗﻘﻮﯾﺘﺶ ﮐﻨﯿﺪ‪.‬‬

‫در زﻣﺎن ﺗﻐﯿﯿﺮ دادن ﻣﺘﺪوﻟﻮژی )اﺧﺘﺼﺎﺻﯽﺳﺎزی( ﻣﺮاﻗﺐ ﻣﻮارد زﯾﺮ ﺑﺎﺷﯿﺪ‪:‬‬

‫ﺳﯿﺴﺘﻢ را ﺑﯿﺶ از اﻧﺪازه ﭘﯿﭽﯿﺪه ﻧﮑﻨﯿﺪ‪ .‬ﻫﯿﭻ ﻋﻨﺼﺮی ﺑﻪ آن ﻧﯿﻔﺰاﯾﯿﺪ‪ ،‬ﻣﮕﺮ اﯾﻦﮐﻪ ﺗﻮﺟﯿﻪ ﺧﻮﺑﯽ ﺑﺮاﯾﺶ داﺷﺘﻪ‬
‫ﺑ ﺎ ﺷ ﯿ ﺪ‪.‬‬
‫ﻣﺮاﻗﺐ ﺑﺎﺷﯿﺪ ﮐﻪ ﺳﯿﺴﺘﻢ ﺳﺎزﮔﺎری دروﻧﯽ ﺧﻮد را از دﺳﺖ ﻧﺪﻫﺪ‪ .‬ﻋﻨﺼﺮی ﮐﻪ ﺑﻪ ﺧﻮدی ﺧﻮد ﺟﺎﻟﺐ ﺑﻪ ﻧﻈﺮ‬
‫ﻣﯽرﺳﺪ ﻣﻤﮑﻦ اﺳﺖ ﺑﺎ ﻋﻨﺎﺻﺮ ﻣﻮﺟﻮد در ﻣﺘﺪوﻟﻮژی ﺳﺎزﮔﺎر ﻧﺒﺎﺷﺪ‪.‬‬
‫ﻫﻤﻪ ﭼﯿﺰ را ﯾﮑﭙﺎرﭼﻪ ﮐﻨﯿﺪ‪ .‬ﻫﺮ ﻋﻨﺼﺮی ﮐﻪ ﺑﻪ ﺳﯿﺴﺘﻢ ﻣﯽاﻓﺰاﯾﯿﺪ ﺑﺎﯾﺪ ﻣﺴﺘﻘﯿﻢ ﯾﺎ ﻏﯿﺮﻣﺴﺘﻘﯿﻢ ﺑﺎ ﻫﻤﻪ ﻋﻨﺎﺻﺮ‬
‫دﯾﮕﺮ در ارﺗﺒﺎط ﺑﺎﺷﺪ‪ ،‬از آنﻫﺎ اﺛﺮ ﺑﮕﯿﺮد‪ ،‬و ﺑﺮ آنﻫﺎ اﺛﺮ ﺑﮕﺬارد‪.‬‬

‫در اداﻣﻪ اﯾﻦ ﻓﺼﻞ ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﭘﻢﺑﺎک را ﺑﻪﺗﻔﺼﯿﻞ ﺑﺮرﺳﯽ ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫‪ . 1 . 4‬ذ یﻧ ﻔ ﻌﺎ ن‬

‫»ذیﻧﻔﻊ« ﺑﻪ ﻓﺮد ﯾﺎ ﮔﺮوﻫﯽ ﮔﻔﺘﻪ ﻣﯽﺷﻮد ﮐﻪ ﺑﻪ ﻧﻮﻋﯽ ﺑﺎ ﭘﺮوژه ﺳﺮ و ﮐﺎر دارد و ﻣﯽﺗﻮاﻧﺪ ﺑﺮ آن اﺛﺮ ﺑﮕﺬارد‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ‪،‬‬
‫اﻋﻀﺎی ﺗﯿﻢ‪ ،‬ﺳﺎزﻣﺎن‪ ،‬ﮐﺎرﻓﺮﻣﺎ‪ ،‬ﭘﯿﻤﺎﻧﮑﺎران‪ ،‬ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ‪ ،‬رﻗﺒﺎ‪ ،‬ﻗﺎﻧﻮنﮔﺬاران و ﻫﻤﺎﻧﻨﺪ آنﻫﺎ ذیﻧﻔﻊ ﺑﻪ ﺷﻤﺎر ﻣﯽروﻧﺪ‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن ﻧﻘﺸﯽ ﮐﻠﯿﺪی در ﻣﻮﻓﻘﯿﺖ ﭘﺮوژه دارد و ﭘﯿﺶ از اﯾﻦ ﺑﺮﺧﯽ ﺟﻨﺒﻪﻫﺎی آن را ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ‪ .‬ﻫﻤﻪ‬

‫— ‪— 52‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺘﺪوﻟﻮژیﻫﺎ ﺑﻪ ﮔﻮﻧﻪﻫﺎی ﻣﺨﺘﻠﻒ ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن را ﭘﻮﺷﺶ ﻣﯽدﻫﻨﺪ‪ ،‬ﺑﻪﮔﻮﻧﻪای ﮐﻪ ﺑﺮای ﻋﻤﻮم ﭘﺮوژهﻫﺎ و در‬
‫ﺷﺮاﯾﻂ ﻋﺎدی ﺑﺎﯾﺴﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫در دﯾﺪﮔﺎه ﺳﻨﺘﯽ‪ ،‬ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن ﻋﻤﻮﻣﺎ ﺑﺮ ذیﻧﻔﻌﺎن ﺑﯿﺮوﻧﯽ )ﻏﯿﺮ از اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه( ﻣﺘﻤﺮﮐﺰ اﺳﺖ‪ .‬روشﻫﺎی‬
‫ﭼﺎﺑﮏ ﺑﺮﺧﻮردی واروﻧﻪ دارﻧﺪ و ﺑﯿﺸﺘﺮ ﺗﻮﺟﻬﺸﺎن ﺑﻪ ذیﻧﻔﻌﺎن دروﻧﯿﺴﺖ‪ .‬روشﻫﺎی ﻧﻮﯾﻦ ﮐﻮﺷﺶ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﺑﻪ ﻫﺮ‬
‫دو ﮔﺮوه ذیﻧﻔﻊ ﺑﻪ اﻧﺪازه ﺗﻮﺟﻪ ﮐﻨﻨﺪ‪.‬‬

‫ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﻣﻨﺎﺳﺐ ذیﻧﻔﻌﺎن ﺑﺎﯾﺪ ﻫﻤﻪ ﻣﻮارد زﯾﺮ ﺑﻪ ﻧﻮﻋﯽ ﻟﺤﺎظ ﺷﻮﻧﺪ‪:‬‬

‫‪ .1‬ﺷﻨﺎﺳﺎﯾﯽ‬
‫‪ .2‬درک و ﺗﺤﻠﯿﻞ‬
‫‪ .3‬اوﻟﻮﯾﺖﺑﻨﺪی‬
‫‪ .4‬ﻣﺸﺎرﮐﺖ دادن‬
‫‪ .5‬ارزﯾﺎﺑﯽ‬

‫اﯾﻦ ﻣﺮاﺣﻞ ﺑﺎﯾﺪ در ﻣﺘﺪوﻟﻮژی ﻟﺤﺎظ ﺷﺪه‪ ،‬داﯾﻤﺎ ﺗﮑﺮار ﺷﻮﻧﺪ‪.‬‬

‫‪ .1.1.4‬ﺷﻨﺎﺳﺎﯾﯽ‬

‫ﮔ ﺎ ﻫ ﯽ ﺷ ﻨ ﺎ ﺳ ﺎ ﯾ ﯽ ذ ی ﻧ ﻔ ﻌ ﺎ ن ﮐ ﺎ ر ﺳ ﺎ د ه ا ی ﻧ ﯿ ﺴ ﺖ‪ .‬ﻧ ﻤ ﻮ ﻧ ﻪ ا ش ﭘ ﻨ ﺎ ﻫ ﮕ ﺎ ه ﮐ ﻮ ﻫ ﺴ ﺘ ﺎ ﻧ ﯿ ﺴ ﺖ ﮐ ﻪ ﭘ ﯿ ﺶ ا ز ا ﯾ ﻦ ﻃ ﺮ ح ﺷ ﺪ ه ﺑ ﻮ د‪.‬‬

‫ﺑﺎﯾﺪ در آﻏﺎز ﮐﺎر زﻣﺎن ﮐﺎﻓﯽ ﺻﺮف ﺷﻨﺎﺳﺎﯾﯽ ذیﻧﻔﻌﺎن ﮐﻠﯿﺪی ﮐﺮد‪ ،‬زﯾﺮا ﺑﺮﺧﯽ از ذیﻧﻔﻌﺎن‪ ،‬ﻣﺎﻧﻨﺪ ﻗﺎﻧﻮنﮔﺬاران‪ ،‬ﭼﻨﺎن‬
‫ﺗﺎﺛﯿﺮﻫﺎی ﮐﻼﻧﯽ ﺑﺮ ﭘﺮوژه ﻣﯽﮔﺬارﻧﺪ ﮐﻪ ﻣﻤﮑﻦ اﺳﺖ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی آن را از ﺑﯿﻦ ﺑﺒﺮﻧﺪ‪ .‬اﮔﺮ اﯾﻦ ذیﻧﻔﻌﺎن در آﻏﺎز ﮐﺎر‬
‫ﺷﻨﺎﺳﺎﯾﯽ ﺷﻮﻧﺪ‪ ،‬ﺷﺎﯾﺪ ﻣﺘﻮﺟﻪ ﺷﻮﯾﺪ ﮐﻪ ﺑﻬﺘﺮ اﺳﺖ زﻣﺎن و ﻫﺰﯾﻨﻪای ﺻﺮف ﭘﺮوژه ﻧﺸﺪه‪ ،‬ﻟﻐﻮ ﺷﻮد‪.‬‬

‫ﮔﺬﺷﺘﻪ از ﺷﻨﺎﺳﺎﯾﯽ ﻧﺨﺴﺘﯿﻦ‪ ،‬ﺑﺎﯾﺪ داﯾﻤﺎ در ﻫﻨﮕﺎم اﺟﺮای ﭘﺮوژه ﻧﯿﺰ ﺑﻪ ﻓﮑﺮ ﺷﻨﺎﺳﺎﯾﯽ ذیﻧﻔﻌﺎن ﺗﺎزه ﺑﺎﺷﯿﺪ‪ ،‬زﯾﺮا‬

‫ﺷﺎﯾﺪ ﺑﺮﺧﯽ از ذیﻧﻔﻌﺎن را از ﻗﻠﻢ اﻧﺪاﺧﺘﻪ ﺑﺎﺷﯿﺪ‪ ،‬و‬

‫ﺷﺎﯾﺪ ﺗﻐﯿﯿﺮﻫﺎﯾﯽ در ﻣﺤﯿﻂ ﭘﺮوژه ﺑﻪ وﺟﻮد آﻣﺪه‪ ،‬ذیﻧﻔﻌﺎن ﺗﺎزهای ﺑﻪ وﺟﻮد آورده ﺑﺎﺷﺪ‪.‬‬

‫ﻣﺎﻧﻨﺪ ﺑﺴﯿﺎری دﯾﮕﺮ از ﺣﻮزهﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﺑﻪ اﺳﻨﺎد ﭘﺮوژهﻫﺎی ﻫﻤﺎﻧﻨﺪ ﮐﻪ در ﮔﺬﺷﺘﻪ اﺟﺮا ﮐﺮدهاﯾﺪ ﻧﯿﺰ‬
‫ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ ﺗﺎ ﺑﺒﯿﻨﯿﺪ ﭼﻪ ﮐﺴﺎﻧﯽ ﺑﺮ آن اﺛﺮ ﮔﺬاﺷﺘﻪاﻧﺪ‪ .‬اﯾﻨﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﯿﺪ ذیﻧﻔﻌﺎن ﺑﯿﺸﺘﺮی ﺷﻨﺎﺳﺎﯾﯽ ﮐﻨﯿﺪ ﮐﻪ ﺷﺎﯾﺪ‬
‫ﺑﺪون آن از ﻗﻠﻢ ﺑﯿﻔﺘﻨﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﯾﮑﯽ از دﻻﯾﻞ ﻓﺮاواﻧﯿﺴﺖ ﮐﻪ ﺑﺮ ﻟﺰوم ﻣﺴﺘﻨﺪﺳﺎزی و ﺑﺎﯾﮕﺎﻧﯽ ﻣﻨﺎﺳﺐ اﺳﻨﺎد‬
‫ﭘﺮوژهﻫﺎ ﭘﺎﻓﺸﺎری ﻣﯽﮐﻨﯿﻢ‪.‬‬

‫ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﺑﺮرﺳﯽ ﮐﻨﯿﺪ ﺗﺎ ﺑﺒﯿﻨﯿﺪ ﮐﻪ روﻧﺪی ﮐﻪ ﺑﺮای ﺷﻨﺎﺳﺎﯾﯽ ذیﻧﻔﻌﺎن دارد ﺑﺮای ﺷﺮاﯾﻂ ﭘﺮوژهﺗﺎن ﻣﻨﺎﺳﺐ‬
‫اﺳﺖ ﯾﺎ ﻧﻪ‪ ،‬و اﮔﺮ ﻻزم اﺳﺖ‪ ،‬ﻓﻌﺎﻟﯿﺖﻫﺎی ﺳﺎﺧﺖﯾﺎﻓﺘﻪﺗﺮی ﺑﺮای اﯾﻦ ﻣﻨﻈﻮر ﺑﻪ آن ﺑﯿﻔﺰاﯾﯿﺪ‪.‬‬

‫‪ .2.1.4‬درک و ﺗﺤﻠﯿﻞ‬

‫— ‪— 53‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﭘ ﺲ ا ز ﺷ ﻨ ﺎ ﺳ ﺎ ﯾ ﯽ ﻫ ﺮ ذ ی ﻧ ﻔ ﻊ ‪ ،‬ﺑ ﺎ ﯾ ﺪ ﺗ ﺤﻠ ﯿﻠ ﺶ ﮐ ﻨ ﯿ ﺪ ‪:‬‬

‫ﭼﮕﻮﻧﻪ و ﺗﺎ ﭼﻪ اﻧﺪازه ﻣﯽﺗﻮاﻧﺪ ﺑﺮ ﭘﺮوژه اﺛﺮ ﺑﮕﺬارد؟‬

‫ﺟﺒﻪﮔﯿﺮیاش در ﺑﺮاﺑﺮ ﭘﺮوژه ﻣﺜﺒﺖ اﺳﺖ ﯾﺎ ﻣﻨﻔﯽ؟‬
‫ﭼﻪ اﻧﺘﻈﺎری از ﭘﺮوژه دارد؟ ﭼﻪ ﻣﺴﺎﯾﻠﯽ ﺑﺮاﯾﺶ ﺧﻮشآﯾﻨﺪ و ﭼﻪ ﻣﺴﺎﯾﻠﯽ آزاردﻫﻨﺪه اﺳﺖ؟‬
‫و…‬

‫وﻗﺘﯽ در ﺟﺴﺘﺠﻮی ﭘﺎﺳﺦ ﺑﻪ ﭼﻨﯿﻦ ﭘﺮﺳﺶﻫﺎﯾﯽ ﻫﺴﺘﯿﺪ‪ ،‬ﺑﻪﺗﺪرﯾﺞ ﺑﺮﻧﺎﻣﻪای ﻫﻢ ﺑﺮای ﻣﺸﺎرﮐﺖدادن و ﺟﻠﺐ ﺣﻤﺎﯾﺖ‬
‫آنﻫﺎ ﺗﺪوﯾﻦ ﮐﻨﯿﺪ‪ .‬وﻗﺘﯽ ﭼﻨﯿﻦ ﮐﺎری ﻣﯽﮐﻨﯿﺪ ﻣﺮاﻗﺐ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺑﺮﻧﺎﻣﻪ ﻧﯿﺰ ﺑﺎﺷﯿﺪ‪ :‬آﯾﺎ ﻣﻨﺎﻓﻌﯽ ﮐﻪ از ﻣﺸﺎرﮐﺖ و‬
‫ﺣﻤﺎﯾﺖ ذیﻧﻔﻊ درﯾﺎﻓﺖ ﻣﯽﮐﻨﯿﺪ ﺑﯿﺶ از ﺗﻮاﻧﯽ ﮐﻪ ﺻﺮف ﻣﯽﮐﻨﯿﺪ ﻫﺴﺖ؟ آﯾﺎ ﺑﺎزﮔﺸﺖ ﺳﺮﻣﺎﯾﻪ در اﯾﻦ ﻓﺮآﯾﻨﺪ ﺑﯿﺸﺘﺮ از‬
‫ﻫﺰﯾﻨﻪ ﻓﺮﺻﺖ )‪ (opportunity cost‬ﺷﻤﺎ ﻫﺴﺖ ﯾﺎ ﺧﯿﺮ؟ ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬آﯾﺎ ﮐﺎر دﯾﮕﺮی ﺑﺎ ﺑﺎزﮔﺸﺖ ﺑﺎﻻﺗﺮ ﻫﺴﺖ ﮐﻪ‬
‫ﺑﺘ ﻮا ن ﺑ ﻪ ﺟﺎ ی آ ن اﻧ ﺠﺎ م دا د ؟‬

‫اﺳﺘﺜﻨﺎﯾﯽ ﮐﻪ در ﺗﺤﻠﯿﻞ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﻣﺸﺎرﮐﺖ ذیﻧﻔﻌﺎن وﺟﻮد دارد‪ ،‬ﻣﺴﺎﯾﻞ اﺧﻼﻗﯿﺴﺖ‪ .‬ﻓﺮض ﮐﻨﯿﺪ ﻗﺮار اﺳﺖ‬
‫ﺳﺎﺧﺘﻤﺎن ﮐﻮﭼﮑﯽ در ﻫﻤﺴﺎﯾﮕﯽ ﭘﯿﺮزﻧﯽ ﺑﺴﺎزﯾﺪ‪ .‬ﭘﯿﺮزن ﻧﻤﯽداﻧﺪ ﮐﻪ ﭼﻨﺎﻧﭽﻪ ﺳﺮ و ﺻﺪا و ﻣﺰاﺣﻤﺖ ﮐﺎر ﺑﯿﺶ از اﻧﺪازه ﯾﺎ‬
‫ﺑﯽﻣﻮﻗﻊ ﺑﺎﺷﺪ ﻣﯽﺗﻮاﻧﺪ از ﺷﻤﺎ ﺷﮑﺎﯾﺖ ﮐﻨﺪ و ﺷﺎﯾﺪ ﺗﻮان و ﺣﻮﺻﻠﻪ اﯾﻦ ﮐﺎر را ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬آﯾﺎ اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﻪ اﯾﻦ‬
‫ﻣﻌﻨﯿﺴﺖ ﮐﻪ ﻧﯿﺎزی ﺑﻪ ﻣﺤﺪود ﮐﺮدن آﻟﻮدﮔﯽ ﺻﻮﺗﯽ ﮐﺎرﮔﺎه ﻧﺪارﯾﺪ؟ ﻧﻪ؛ ﺑﺎﯾﺪ ﺟﻨﺒﻪ اﺧﻼﻗﯽ ﻣﺴﺌﻠﻪ را ﻫﻢ در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪.‬‬

‫اﻃﻼﻋﺎﺗﯽ ﮐﻪ درﺑﺎره ﺗﺤﻠﯿﻞ و ﺑﺮﻧﺎﻣﻪرﯾﺰی ذیﻧﻔﻌﺎن ﮔﺮدآوری ﮐﺮدهاﯾﺪ را ﺑﺮای ارﺟﺎعﻫﺎی ﺑﻌﺪی ﻣﺴﺘﻨﺪ ﮐﻨﯿﺪ‪ .‬ﺑﺮﺧﯽ‬
‫ﻣﺘﺪوﻟﻮژیﻫﺎ ﺳﻨﺪی ﺑﺮای اﯾﻦ ﮐﺎر دارﻧﺪ ﮐﻪ ﻣﯽﺗﻮاﻧﺪ ﻧﺎﻣﯽ ﻣﺎﻧﻨﺪ ﻓﻬﺮﺳﺖ ذیﻧﻔﻌﺎن )‪ (stakeholder register‬داﺷﺘﻪ‬
‫ﺑﺎﺷﺪ‪ .‬ﺑﺮﺧﯽ دﯾﮕﺮ اﯾﻦ اﻃﻼﻋﺎت را در دل اﺳﻨﺎدی ﮐﻼنﺗﺮ ذﺧﯿﺮه ﻣﯽﮐﻨﻨﺪ‪ .‬اﮔﺮ ﺳﻨﺪ ﺟﺪاﮔﺎﻧﻪای ﺑﺮای اﯾﻦ ﮐﺎر ﻧﺪارﯾﺪ و‬
‫ﺑﺎور دارﯾﺪ ﮐﻪ ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن ﭘﺮوژهﺗﺎن ﭘﯿﭽﯿﺪﮔﯽﻫﺎی ﻓﺮاواﻧﯽ دارد‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﺳﻨﺪی ﻣﺴﺘﻘﻞ ﺑﺮاﯾﺶ ﺑﺴﺎزﯾﺪ‪.‬‬

‫ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن واﺑﺴﺘﮕﯽ ﻓﺮاواﻧﯽ ﺑﻪ ارﺗﺒﺎﻃﺎت دارد و در اﯾﻦ ﺑﺎره ﺑﺎﯾﺪ ﺑﻪ اﯾﻦ دو ﺟﻨﺒﻪ ﺗﻮﺟﻪ ﮐﻨﯿﺪ‪:‬‬

‫اﻧﺘﻘﺎل اﻃﻼﻋﺎت از ﺷﻤﺎ ﺑﻪ آنﻫﺎ‪ :‬ﺑﺎﯾﺪ ﺑﺴﯿﺎری از ذیﻧﻔﻌﺎن را از وﺿﻌﯿﺖ ﭘﺮوژه آﮔﺎه ﮐﺮد‪ ،‬زﯾﺮا ﺷﺎﯾﺪ ﻧﻘﻄﻪﻧﻈﺮی‬
‫درﺑﺎره وﺿﻌﯿﺖ داﺷﺘﻪ ﺑﺎﺷﺪ و ﭼﻨﯿﻦ ﻣﺴﺎﯾﻠﯽ ﻫﺮﭼﻪ زودﺗﺮ آﺷﮑﺎر ﺷﻮﻧﺪ‪ ،‬آﺳﺎنﺗﺮ ﻣﺪﯾﺮﯾﺖ ﺧﻮاﻫﻨﺪ ﺷﺪ‪ .‬ﭘﻨﻬﺎن‬
‫ﮐﺮدن اﻃﻼﻋﺎت ﺷﺎﯾﺪ ﺑﻪ ﻧﻈﺮ راﻫﮑﺎر ﺳﺎدهای ﺑﺮای ﺟﻠﻮﮔﯿﺮی از ﺑﺮوز اﺧﺘﻼف ﻧﻈﺮ ﺑﯿﺎﯾﺪ‪ ،‬وﻟﯽ رﯾﺴﮏﻫﺎی ﻓﺮاواﻧﯽ‬
‫دارد و از ﻧﻈﺮ اﺧﻼﻗﯽ ﻧﯿﺰ ﭘﺬﯾﺮﻓﺘﻨﯽ ﻧﯿﺴﺖ‪.‬‬
‫اﻧﺘﻘﺎل اﻃﻼﻋﺎت از آنﻫﺎ ﺑﻪ ﺷﻤﺎ‪ :‬ﺑﺎﯾﺪ ﻧﻈﺮ ذیﻧﻔﻌﺎن را ﺑﺸﻨﻮﯾﺪ و درک ﮐﻨﯿﺪ‪ .‬ﺑﺮای اﯾﻦ ﻣﻨﻈﻮر ﭘﯿﺶﻗﺪم ﺷﻮﯾﺪ و‬
‫ﻣﻨﺘﻈﺮ ﻧﻤﺎﻧﯿﺪ ﮐﻪ ﺑﻪ ﺷﻤﺎ ﻣﺮاﺟﻌﻪ ﮐﻨﻨﺪ‪ ،‬زﯾﺮا در آن ﺣﺎﻟﺖ ﺷﺎﯾﺪ ﮐﺎر از ﮐﺎر ﮔﺬﺷﺘﻪ ﺑﺎﺷﺪ و ﻣﺸﮑﻞزا ﺷﻮد‪.‬‬

‫ارﺗﺒﺎﻃﺎت اﻧﻮاع ﻣﺨﺘﻠﻔﯽ ﻧﯿﺰ دارﻧﺪ‪:‬‬

‫ارﺗﺒﺎط ﺑﺎ ﺑﺮﺧﯽ ذیﻧﻔﻌﺎن ﺑﺎﯾﺪ رﺳﻤﯽ ﺑﺎﺷﺪ‪ ،‬وﻟﯽ ارﺗﺒﺎط ﻏﯿﺮرﺳﻤﯽ ﺑﺎ ﺑﺮﺧﯽ دﯾﮕﺮ از ذیﻧﻔﻌﺎن ﮐﺎرآﻣﺪﺗﺮ اﺳﺖ‪.‬‬
‫ارﺗﺒﺎﻃﺎت ﻣﯽﺗﻮاﻧﻨﺪ ﻓﺮﺳﺘﺎدﻧﯽ )‪ (push‬ﯾﺎ درﯾﺎﻓﺘﯽ )‪ (pull‬ﺑﺎﺷﻨﺪ‪ .‬ﮔﺰارﺷﯽ ﭼﺎﭘﯽ ﮐﻪ ﺑﺮای ﮐﺴﯽ ﻣﯽﻓﺮﺳﺘﯿﺪ از ﻧﻮع‬
‫ﻧﺨﺴﺖ اﺳﺖ و اﮔﺮ ﯾﮏ داﺷﺒﻮرد اﻃﻼﻋﺎﺗﯽ آﻧﻼﯾﻦ ﺑﺴﺎزﯾﺪ ﺗﺎ ذیﻧﻔﻌﺎﻧﯽ ﮐﻪ ﻣﺎﯾﻞ ﺑﻮدﻧﺪ ﺑﻪ آن ﻣﺮاﺟﻌﻪ ﮐﺮده‪،‬‬
‫اﻃﻼﻋﺎت را درﯾﺎﻓﺖ ﮐﻨﻨﺪ‪ ،‬ارﺗﺒﺎط از ﻧﻮع دوم ﺧﻮاﻫﺪ ﺑﻮد‪ .‬ارﺗﺒﺎط درﯾﺎﻓﺘﯽ ﺳﺎدهﺗﺮ اﺳﺖ‪ ،‬وﻟﯽ ﺑﺎﯾﺪ ﻣﻄﻤﺌﻦ ﺷﻮﯾﺪ‬
‫ﮐﻪ ذیﻧﻔﻌﺎن ﺑﺎ ﺑﺴﺎﻣﺪ ﻣﻨﺎﺳﺐ ﺑﻪ آن ﻣﺮاﺟﻌﻪ ﻣﯽﮐﻨﻨﺪ و ﻓﺮاﻣﻮش ﻧﺸﺪه اﺳﺖ‪.‬‬

‫— ‪— 54‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺴﺘﺮﻫﺎی ﮔﻮﻧﺎﮔﻮﻧﯽ ﺑﺮای ارﺗﺒﺎط وﺟﻮد دارد‪ :‬اﯾﻤﯿﻞ‪ ،‬ﮔﺰارش ﭼﺎﭘﯽ‪ ،‬ﺟﻠﺴﻪ رو در رو‪ ،‬و ﻫﻤﺎﻧﻨﺪ آن‪ .‬ﺑﺴﺘﺮ ﻣﻨﺎﺳﺐ‬
‫ﺑﺮای ﻫﺮ ارﺗﺒﺎﻃﯽ ﺑﻪ ﺷﺮاﯾﻂ آن ﺑﺴﺘﮕﯽ دارد‪.‬‬

‫ﻧﮑﺘﻪای ﺑﺴﯿﺎر ﻣﻬﻢ درﺑﺎره ارﺗﺒﺎﻃﺎت وﺟﻮد دارد‪ :‬ﻫﺮ ارﺗﺒﺎﻃﯽ ﺑﺎﯾﺪ ردﭘﺎﯾﯽ داﺷﺘﻪ ﺑﺎﺷﺪ و اﻃﻼﻋﺎﺗﯽ ﮐﻪ ﻣﻨﺘﻘﻞ ﺷﺪهاﻧﺪ‬
‫ﻣﺎﻧﺪﮔﺎر ﺑﺎﺷﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﺟﻠﺴﻪای رو در رو دارﯾﺪ‪ ،‬ﺻﻮرت ﺟﻠﺴﻪای آﻣﺎده ﮐﻨﯿﺪ ﮐﻪ ﭼﮑﯿﺪهای از اﻃﻼﻋﺎت رد و‬
‫ﺑﺪل ﺷﺪه را ﺑﺎزﺗﺎب دﻫﺪ‪ .‬اﮔﺮ ﮔﻔﺘﮕﻮﯾﯽ ﺗﻠﻔﻨﯽ اﻧﺠﺎم ﺷﺪه اﺳﺖ‪ ،‬ﯾﺎدداﺷﺖ ﮐﻮﺗﺎﻫﯽ ﺑﺮدارﯾﺪ و آﻧﭽﻪ ﻃﺮح ﺷﺪه ﺑﻮد را در‬
‫آ ن ﺛ ﺒ ﺖ ﮐ ﻨ ﯿ ﺪ‪.‬‬

‫ﻣﺘﺎﺳﻔﺎﻧﻪ ﻣﺘﻮﺟﻪ ﺷﺪهام ﮐﻪ در ﺳﺎلﻫﺎی اﺧﯿﺮ اﺳﺘﻔﺎده از ﻧﺮماﻓﺰارﻫﺎی ﭘﯿﺎمرﺳﺎن ﻣﺎﻧﻨﺪ واﺗﺲاپ در ﭘﺮوژهﻫﺎی اﯾﺮاﻧﯽ‬
‫ﺑﻪ ﺷﺪت راﯾﺞ ﺷﺪه و در ﻋﻤﻞ ﺟﺎی اﯾﻤﯿﻞ و ﺑﺴﯿﺎری ﺑﺴﺘﺮﻫﺎی اﻃﻼﻋﺎﺗﯽ دﯾﮕﺮ را ﮔﺮﻓﺘﻪ اﺳﺖ‪ .‬ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﻢ از اﯾﻦ‬
‫ﮐﺎر ﺧﻮدداری ﮐﻨﯿﺪ‪ ،‬زﯾﺮا‬

‫اﻃﻼﻋﺎت در ﻧﺮماﻓﺰارﻫﺎی ﭘﯿﺎمرﺳﺎن ﻣﺎﻧﺪﮔﺎر ﻧﯿﺴﺖ و ﺑﺎﯾﮕﺎﻧﯽ ﮐﺮدﻧﺶ دﺷﻮار اﺳﺖ‪.‬‬

‫ﺟﺴﺘﺠﻮی اﻃﻼﻋﺎت ﭘﯿﺸﯿﻦ در ﻧﺮماﻓﺰارﻫﺎی ﭘﯿﺎمرﺳﺎن ﺳﺎده ﻧﯿﺴﺖ و ﺑﺮای ﮐﺴﺎﻧﯽ ﮐﻪ ﭘﯿﺎم ﺻﻮﺗﯽ ﻣﯽﻓﺮﺳﺘﻨﺪ ﺑﻪ‬
‫ﮐ ﻞ ا ﻣ ﮑ ﺎ ن ﭘ ﺬ ﯾ ﺮ ﻧ ﯿ ﺴ ﺖ‪.‬‬
‫اﻣﮑﺎن رﻫﮕﯿﺮی ﻣﺴﺎﯾﻞ در ﭼﻨﯿﻦ ﻧﺮماﻓﺰارﻫﺎﯾﯽ وﺟﻮد ﻧﺪارد و ﺷﺎﯾﺪ ﺑﺮﺧﯽ ﻣﺴﺎﯾﻞ از ﻗﻠﻢ ﺑﯿﻔﺘﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬وﻗﺘﯽ‬
‫ﻣﻮردی را ﺑﺎ اﯾﻤﯿﻞ ﻣﯽﻓﺮﺳﺘﯿﺪ‪ ،‬اﮔﺮ ﮔﯿﺮﻧﺪه در ﻫﻤﺎن زﻣﺎن ﻧﺘﻮاﻧﺪ اﻗﺪاﻣﯽ اﻧﺠﺎم دﻫﺪ اﯾﻤﯿﻞ را ﻧﮕﻪ ﻣﯽدارد و ﺑﻌﺪا‬
‫ﺑﻪ آن ﻣﺮاﺟﻌﻪ ﻣﯽﮐﻨﺪ‪ ،‬وﻟﯽ ﭘﯿﺎمﻫﺎی ﻓﻮری از ﻫﻢ ﻣﺴﺘﻘﻞ ﻧﯿﺴﺘﻨﺪ و ﺑﻪﺳﺮﻋﺖ در اﻧﺒﻮﻫﯽ از ﭘﯿﺎمﻫﺎی ﺗﺎزه ﮔﻢ‬
‫ﻣ ﯽ ﺷ ﻮ ﻧ ﺪ‪.‬‬

‫‪ .3.1.4‬اوﻟﻮﯾﺖﺑﻨﺪی‬

‫اﮔﺮ ذیﻧﻔﻌﺎن ﭘﺮﺷﻤﺎر ﺑﺎﺷﻨﺪ‪ ،‬ﺑﺪ ﻧﯿﺴﺖ آنﻫﺎ را ﺑﺮ ﭘﺎﯾﻪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺑﺮﻧﺎﻣﻪای ﮐﻪ ﺑﺮای ﻣﺸﺎرﮐﺖدادﻧﺸﺎن دارﯾﺪ‪ ،‬ﺣﺪود‬
‫اﺛﺮﮔﺬاری‪ ،‬و ﻣﻮارد ﻣﺸﺎﺑﻪ آن اوﻟﻮﯾﺖﺑﻨﺪی ﮐﻨﯿﺪ ﺗﺎ اﮔﺮ زﻣﺎﻧﯽ در ﻣﯿﺎن اﺟﺮای ﭘﺮوژه ﺗﻮان ﮐﺎﻓﯽ ﺑﺮای اﺟﺮای ﻫﻤﻪ ﺑﺮﻧﺎﻣﻪﻫﺎ‬
‫ﻧﺒﻮد‪ ،‬دﺳﺖﮐﻢ روی ﻣﻬﻢﺗﺮﯾﻦ ﻣﻮارد ﺗﻤﺮﮐﺰ ﮐﻨﯿﺪ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮیﻫﺎ داﯾﻤﺎ ﺗﻐﯿﯿﺮ ﻣﯽﮐﻨﻨﺪ و از اﯾﻦ رو ﺑﺎﯾﺪ اوﻟﻮﯾﺖﺑﻨﺪیﻫﺎ را ﻧﯿﺰ اﺻﻼح ﮐﻨﯿﺪ‪.‬‬

‫‪ .4.1.4‬ﻣﺸﺎرﮐﺖ دادن‬

‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺎﻓﯽ ﻧﯿﺴﺖ و ﺑﺎﯾﺪ آن را اﺟﺮا ﮐﺮد‪ .‬ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﺑﺮرﺳﯽ ﮐﻨﯿﺪ و ﺑﺒﯿﻨﯿﺪ ﮐﻪ ﺑﺮای ﻣﺸﺎرﮐﺖ دادن‬
‫ذیﻧﻔﻌﺎن ﭼﻪ ﻓﻌﺎﻟﯿﺖﻫﺎﯾﯽ دارد )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ارﺗﺒﺎﻃﺎت( و در ﻧﻈﺮ ﻫﻢ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺑﺮﺧﯽ اﻗﺪامﻫﺎ ﺿﻤﻨﯽ و ﻧﺎﻣﺮﺋﯽ‬
‫ﻫﺴﺘﻨﺪ‪ .‬آﯾﺎ اﯾﻦ ﺟﻨﺒﻪﻫﺎی ﻣﺘﻮوﻟﻮژی ﺑﺮای درﺟﻪ ﺣﺴﺎﺳﯿﺖ ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن در ﭘﺮوژهﺗﺎن ﮐﺎﻓﯿﺴﺖ؟ اﮔﺮ ﻧﺒﺎﺷﺪ ﺑﺎﯾﺪ‬
‫آن را ﺗﻘﻮﯾﺖ ﮐﻨﯿﺪ‪.‬‬

‫در ﮐﻨﺎر ﺑﺮﻧﺎﻣﻪرﯾﺰیﻫﺎﯾﯽ ﮐﻪ ﺑﺮای ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن ﻣﯽﮐﻨﯿﺪ‪ ،‬اﻗﺪامﻫﺎی ﻣﻮردی ﻓﺮاواﻧﯽ ﻧﯿﺰ وﺟﻮد ﺧﻮاﻫﺪ‬
‫داﺷﺖ‪ .‬ﻣﻬﺎرتﻫﺎی اﻧﺴﺎﻧﯽ‪ ،‬ﻣﺎﻧﻨﺪ ﻣﺬاﮐﺮه و رﻓﻊ اﺧﺘﻼف‪ ،‬در ﭼﻨﯿﻦ ﻣﻮاردی ﮐﻤﮏ ﺷﺎﯾﺎﻧﯽ ﻣﯽﮐﻨﻨﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﺑﻬﺘﺮ اﺳﺖ‬
‫ﺑﺮ ﺑﻬﺒﻮد ﻣﻬﺎرتﻫﺎی اﻧﺴﺎﻧﯽ ﺧﻮد ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﻨﯿﺪ‪.‬‬

‫— ‪— 55‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫رﻓﺘﺎرﻫﺎﯾﯽ ﻏﯿﺮاﺧﻼﻗﯽ ﻣﺎﻧﻨﺪ رﺷﻮه دادن راﻫﯽ راﯾﺞ ﺑﺮای ﻣﺸﺎرﮐﺖ دادن ذیﻧﻔﻌﺎن در ﺑﺮﺧﯽ ﮐﺸﻮرﻫﺎﺳﺖ‪ .‬ﻓﺮاﻣﻮش‬
‫ﻧﮑﻨﯿﺪ ﮐﻪ ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ اﺧﻼﻗﯽ ﻋﻤﻞ ﮐﻨﯿﺪ‪ ،‬ﺣﺘﯽ اﮔﺮ ﻫﯿﭻﮐﺲ دﯾﮕﺮی در اﻃﺮاﻓﺘﺎن اﺧﻼﻗﯽ ﻋﻤﻞ ﻧﻤﯽﮐﻨﺪ‪ .‬رﻓﺘﺎرﻫﺎﯾﯽ‬
‫ﻣﺎﻧﻨﺪ رﺷﻮه دادن ﭘﺬﯾﺮﻓﺘﻨﯽ ﻧﯿﺴﺘﻨﺪ‪.‬‬

‫ﺑﺮﺧﯽ رﻓﺘﺎرﻫﺎی ﺑﻪ ﻇﺎﻫﺮ ﺑﯽﮔﻨﺎه ﻫﻢ ﻣﯽﺗﻮاﻧﻨﺪ ذات رﺷﻮه دادن داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﯾﺎ اﯾﻦﮔﻮﻧﻪ ﺑﺮداﺷﺖ ﺷﻮﻧﺪ و درﻧﺘﯿﺠﻪ‬
‫ﺑﺎﯾﺪ ﻣﺮاﻗﺐ آنﻫﺎ ﻫﻢ ﺑﺎﺷﯿﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﺴﺘﮕﯽ ﺑﻪ ﻧﻮع ذیﻧﻔﻊ ﻧﯿﺰ دارد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﻣﺪﯾﺮ ﺷﺮﮐﺘﯽ ﺑﺎﺷﯿﺪ و‬
‫ﻣﺪﯾﺮان ﺷﺮﮐﺘﯽ ﻫﻤﮑﺎر را ﺑﻪ ﺿﯿﺎﻓﺘﯽ دﻋﻮت ﮐﻨﯿﺪ‪ ،‬ﺷﺎﯾﺪ ﻣﺸﮑﻠﯽ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬وﻟﯽ اﮔﺮ ﭼﻨﯿﻦ ﮐﺎری را ﺑﺎ ﻧﻤﺎﯾﻨﺪﮔﺎن‬
‫ﺳﺎزﻣﺎﻧﯽ ﻗﺎﻧﻮنﮔﺬار اﻧﺠﺎم دﻫﯿﺪ ﭘﺬﯾﺮﻓﺘﻨﯽ ﻧﺨﻮاﻫﺪ ﺑﻮد‪.‬‬

‫ﺑﺎ اﯾﻦﮐﻪ اﻃﻼعرﺳﺎﻧﯽ ﺑﻪ ذیﻧﻔﻌﺎن ﻻزم اﺳﺖ و ﺑﺮ ﻟﺰوم ﺷﻔﺎف ﺑﻮدن ارﺗﺒﺎطﻫﺎ ﭘﺎﻓﺸﺎری ﻣﯽﮐﻨﯿﻢ‪ ،‬ﺑﺎﯾﺪ ﻣﺤﺮﻣﺎﻧﮕﯽ‬
‫اﻃﻼﻋﺎت را ﻫﻢ در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ .‬ﮔﺮوﻫﯽ ﻓﻌﺎل در ﺣﻮزه ﻧﺮماﻓﺰارﻫﺎی آزاد )ﻣﺘﻦﺑﺎز( را در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪ :‬اﯾﻦ اﻓﺮاد‬
‫ﻣﻌﻤﻮﻻ ﺑﻪ ﮐﻨﻔﺮاﻧﺲﻫﺎ و اﻧﺠﻤﻦﻫﺎی ﻣﺨﺘﻠﻒ ﻣﯽروﻧﺪ و درﺑﺎره ﭘﺮوژهﻫﺎﯾﺸﺎن ﺑﺎ ﻫﺮ ﮐﺴﯽ ﮐﻪ ﺑﺘﻮاﻧﻨﺪ ﮔﻔﺘﮕﻮ ﻣﯽﮐﻨﻨﺪ ﺗﺎ‬
‫ﺣﻤﺎﯾﺖ ﺑﯿﺸﺘﺮی ﺑﻪ دﺳﺖ آورﻧﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﺮﺧﯽ ﺷﺮﮐﺖﻫﺎ‪ ،‬ﻣﺎﻧﻨﺪ اﭘﻞ‪ ،‬ﺳﺨﺘﮕﯿﺮیﻫﺎی ﻓﺮاواﻧﯽ درﺑﺎره‬
‫ﭘﺮوژهﻫﺎﯾﺸﺎن دارﻧﺪ و ﻣﺎﯾﻞ ﻧﯿﺴﺘﻨﺪ ﮐﺴﯽ از آنﻫﺎ ﺑﺎﺧﺒﺮ ﺷﻮد‪ .‬ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژه‪ ،‬ﺑﺎﯾﺪ از ﺳﯿﺎﺳﺖﻫﺎی ﻣﺤﺮﻣﺎﻧﮕﯽ‬
‫اﻃﻼﻋﺎت ﺳﺎزﻣﺎﻧﺘﺎن و ﻫﺮ ﻧﻮع ﻗﺎﻧﻮن و ﻗﺎﻋﺪه دﯾﮕﺮی ﮐﻪ در ﻣﺤﯿﻂ اﻃﺮاﻓﺘﺎن وﺟﻮد دارد ﺑﺎﺧﺒﺮ ﺑﺎﺷﯿﺪ و ﺗﺎ ﺟﺎﯾﯽ ﮐﻪ‬
‫ﺧﻼف اﺧﻼق ﻧﯿﺴﺘﻨﺪ در ﮐﺎرﻫﺎﯾﺘﺎن اﻋﻤﺎﻟﺸﺎن ﮐﻨﯿﺪ‪.‬‬

‫‪ .5.1.4‬ارزﯾﺎﺑﯽ‬

‫ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺑﻪ ﺟﺎی واﻗﻌﯿﺖﻫﺎی ﻋﯿﻨﯽ ﺑﺎ ﺟﻨﺒﻪﻫﺎی اﻧﺴﺎﻧﯽ ﺳﺮ و ﮐﺎر داﺷﺘﻪ ﺑﺎﺷﯿﻢ‪ ،‬روشﻫﺎی ﻣﺘﻌﯿﻦ ﮐﺎراﯾﯽ ﮐﺎﻓﯽ‬
‫ﻧﺨﻮاﻫﻨﺪ داﺷﺖ و ﻻزم اﺳﺖ ﮐﻪ ﺗﻄﺒﯿﻘﯽ ﭘﯿﺶ ﺑﺮوﯾﻢ‪ .‬از آنﺟﺎﯾﯽ ﮐﻪ ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن ﻣﺴﺌﻠﻪای ﮐﺎﻣﻼ اﻧﺴﺎﻧﯽﺳﺖ‪،‬‬
‫ﺑﺎﯾﺪ روﯾﮑﺮدﺗﺎن در اﯾﻦ ﺣﻮزه ﺗﻄﺒﯿﻘﯽ ﺑﺎﺷﺪ و ﺑﻪﺟﺎی ﺳﺎﺧﺖ ﺑﺮﻧﺎﻣﻪای ﮐﺎﻣﻼ ﺗﻔﺼﯿﻠﯽ در آﻏﺎز ﮐﺎر‪ ،‬ﺑﺮﻧﺎﻣﻪای ﺳﺎده آﻣﺎده‬
‫ﮐﺮده‪ ،‬زﻣﯿﻨﻪای ﻓﺮاﻫﻢ ﮐﻨﯿﺪ ﮐﻪ ﺑﺘﻮاﻧﯿﺪ ﺑﺎ اﺟﺮای آن ﺑﺮﻧﺎﻣﻪ ﺑﺎزﺧﻮرد ﻣﻨﺎﺳﺐ درﯾﺎﻓﺖ ﮐﺮده‪ ،‬ﺑﺮﻧﺎﻣﻪﻫﺎ را ﺑﺮای دوره ﺑﻌﺪ‬
‫ﺑ ﻬ ﺒ ﻮ د د ﻫ ﯿ ﺪ‪.‬‬

‫ﺑﺮای ﺗﻄﺒﯿﻖ ﺑﺎ ﻣﺤﯿﻂ ﺑﺎﯾﺪ داﯾﻤﺎ ﮐﺎراﯾﯽ ﺑﺮﻧﺎﻣﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ذیﻧﻔﻌﺎن را ارزﯾﺎﺑﯽ ﮐﻨﯿﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﮔﺰارﺷﯽ ﺑﺮای‬
‫ﮔﺮوﻫﯽ از ذیﻧﻔﻌﺎن ﻣﯽﻓﺮﺳﺘﯿﺪ‪ ،‬ﺑﺎ آنﻫﺎ ﺗﻤﺎس ﺑﮕﯿﺮﯾﺪ و ﮔﻔﺘﮕﻮ ﮐﻨﯿﺪ ﺗﺎ ﻣﻄﻤﺌﻦ ﺷﻮﯾﺪ ﮐﻪ ﭘﯿﺎم اﺻﻠﯽ ﮔﺰارش ﺑﻪ ﺧﻮﺑﯽ‬
‫ﻣﻨﺘﻘﻞ ﺷﺪه اﺳﺖ‪ .‬ﺷﺎﯾﺪ ﺑﻪ اﯾﻦ ﻧﺘﯿﺠﻪ ﺑﺮﺳﯿﺪ ﮐﻪ ﮔﺰارش ﺑﺮای ﺑﺮﺧﯽ از آن اﻓﺮاد ﮐﺎرآﻣﺪ ﺑﻮده اﺳﺖ‪ ،‬وﻟﯽ ﮔﺮوﻫﯽ دﯾﮕﺮ‬
‫ﻫﻨﻮز ﮔﺰارش را ﻣﻄﺎﻟﻌﻪ ﻧﮑﺮدهاﻧﺪ‪ .‬ﺷﺎﯾﺪ ﮔﺮوه دوم ﻣﺤﺪودﯾﺖ زﻣﺎن دارﻧﺪ و ﻻزم اﺳﺖ ﮔﺰارش ﺳﺎدهﺗﺮ و ﮐﻮﺗﺎهﺗﺮی‬
‫ﺑﺮاﯾﺸﺎن ﺑﻔﺮﺳﺘﯿﺪ‪.‬‬

‫ﻓﮑﺮ ﺧﻮﺑﯿﺴﺖ ﮐﻪ در ﻫﺮ ﻣﺘﺪوﻟﻮژیای ﮐﻪ دارﯾﺪ روﻧﺪ ارزﯾﺎﺑﯽ رﺿﺎﯾﺖ ذیﻧﻔﻌﺎﻧﯽ ﮐﻪ در ‪ P3.express‬ﺷﺮح داده ﺷﺪه‬
‫اﺳﺖ را ﻧﯿﺰ ﭘﯿﺎدهﺳﺎزی ﮐﻨﯿﺪ‪ .‬در اﯾﻦ ﺳﯿﺴﺘﻢ‪ ،‬ﻧﻈﺮﺳﻨﺠﯽ ﮔﻤﻨﺎﻣﯽ ﺑﺮای ﻫﻤﻪ ذیﻧﻔﻌﺎن دروﻧﯽ و ﺑﯿﺮوﻧﯽ ﭘﺮوژه ﻓﺮﺳﺘﺎده‬
‫ﻣﯽﺷﻮد‪ .‬از ﻧﺘﯿﺠﻪ ﻧﻈﺮﺳﻨﺠﯽ ﺑﺮای ﻃﺮاﺣﯽ ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻬﺒﻮد در دوره ﺑﻌﺪ ﮐﻤﮏ ﮔﺮﻓﺘﻪ ﻣﯽﺷﻮد‪.‬‬

‫‪ . 2 . 4‬ﺗﯿ ﻢ‬

‫— ‪— 56‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﻧﯿﺰ ذیﻧﻔﻌﺎن آن ﻫﺴﺘﻨﺪ و درﻧﺘﯿﺠﻪ ﻫﻤﻪ ﻣﺴﺎﯾﻠﯽ ﮐﻪ در ﺣﻮزه ﭘﯿﺶ ﺑﺮرﺳﯽ ﮐﺮدﯾﻢ ﺑﻪ آنﻫﺎ ﻧﯿﺰ‬
‫اﻋﻤﺎل ﻣﯽﺷﻮد‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬اﻋﻀﺎی ﺗﯿﻢ ﻧﯿﺎز ﺑﻪ ﻣﻼﺣﻈﺎت ﺑﯿﺸﺘﺮی دارﻧﺪ و آن ﺟﻨﺒﻪﻫﺎ در اﯾﻦ ﺣﻮزه ﺑﺮرﺳﯽ ﻣﯽﺷﻮﻧﺪ‪.‬‬

‫ﻣﺪﯾﺮ ﭘﺮوژه ﺑﻪ دو دﻟﯿﻞ ﺑﺎﯾﺪ ﺑﻪ اﯾﻦ ﺣﻮزه ﺗﻮﺟﻪ ﮐﻨﺪ‪:‬‬

‫ﻣﺠﻤﻮﻋﻪای از ﻣﺴﺌﻮﻟﯿﺖﻫﺎی اﺧﻼﻗﯽ در ﺑﺮاﺑﺮ اﻋﻀﺎی ﺗﯿﻢ وﺟﻮد دارد ﮐﻪ ﺑﺎﯾﺪ ﺟﺪا از ﻣﻨﻔﻌﺘﺸﺎن ﺑﺮای ﭘﺮوژه‬
‫ﻣ ﺤ ﻘ ﻖ ﺷ ﻮ ﻧ ﺪ‪.‬‬
‫اﻓﺰون ﺑﺮ آن‪ ،‬رﺿﺎﯾﺖ اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﺑﺎﻋﺚ ﻣﻮﻓﻘﯿﺖ ﺑﯿﺸﺘﺮ ﭘﺮوژه ﻧﯿﺰ ﻣﯽﺷﻮد‪.‬‬

‫ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ﺑﺴﯿﺎری از ﮐﺎرﻫﺎﯾﯽ ﮐﻪ ﺑﺮای اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه اﻧﺠﺎم ﻣﯽدﻫﯿﺪ ﺳﺮاﻧﺠﺎم ﺑﻪ ﻧﻔﻊ ﭘﺮوژه ﻧﯿﺰ ﺧﻮاﻫﺪ ﺑﻮد‪،‬‬
‫وﻟﯽ ﻧﻔﻊ ﭘﺮوژه ﺗﻨﻬﺎ دﻟﯿﻞ ﺑﺮای اﻧﺠﺎم آنﻫﺎ ﻧﯿﺴﺖ‪ .‬ﻫﯿﭻ وﻗﺖ ﺑﺮای اﯾﺠﺎد ﻓﻀﺎﯾﯽ اﻣﻦ و ﺳﺎﻟﻢ ﺑﺮای اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﺑﻪ‬
‫دﻧﺒﺎل ﺗﻮﺟﯿﻪ اﺿﺎﻓﻪای ﻧﮕﺮدﯾﺪ‪ ،‬ﺑﻠﮑﻪ آن را وﻇﯿﻔﻪ اﺧﻼﻗﯽ ﺧﻮد ﺑﺪاﻧﯿﺪ‪ .‬ﻣﻨﻔﻌﺘﯽ ﮐﻪ ﭘﺮوژه ﻣﻤﮑﻦ اﺳﺖ از اﯾﻦ ﻣﺴﺌﻠﻪ‬
‫ﺑﺒﺮد ﺻﺮﻓﺎ اﻣﺘﯿﺎزی اﺿﺎﻓﻪ اﺳﺖ‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ ﺗﯿﻢ ﻣﺒﺤﺚ ﮔﺴﺘﺮدهاﯾﺴﺖ و در اﯾﻦ ﺑﺨﺶ ﻓﻘﻂ ﺑﻪ ﺑﺮﺧﯽ از ﻣﻬﻢﺗﺮﯾﻦ ﻣﺴﺎﯾﻞ ﺧﻮاﻫﯿﻢ ﭘﺮداﺧﺖ‪ :‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‪،‬‬
‫ﺑﻬﺒﻮد ﺗﯿﻢ‪ ،‬و رﻫﺒﺮی‪.‬‬

‫‪ .1.2.4‬ﺳﺎﺧﺘﺎر ﺗﯿﻢ‬

‫ﻫﺮ ﻣﺘﺪوﻟﻮژی ﺳﺎﺧﺘﺎر وﯾﮋه ﺧﻮد را ﺑﺮای ﺗﯿﻢ ﭘﺮوژه دارد و در ﻓﺼﻞ ﮔﺬﺷﺘﻪ ﺑﺎ ﺑﺮﺧﯽ از آنﻫﺎ آﺷﻨﺎ ﺷﺪﯾﺪ‪ .‬ﺑﯿﺸﺘﺮ آنﻫﺎ‬
‫اﻣﮑﺎن ﺑﺎزﺑﯿﻨﯽ ﺳﺎﺧﺘﺎر را ﻧﯿﺰ ﻣﯽدﻫﻨﺪ‪.‬‬

‫ﻣﺜﻞ ﻫﻤﯿﺸﻪ‪ ،‬ﻣﺮاﻗﺐ ﺑﺎﺷﯿﺪ ﮐﻪ ﺗﻐﯿﯿﺮی ﮐﻪ اﻋﻤﺎل ﻣﯽﮐﻨﯿﺪ ﺳﺎزﮔﺎری دروﻧﯽ ﻣﺘﺪوﻟﻮژی را از ﺑﯿﻦ ﻧﺒﺮد و ﺳﯿﺴﺘﻢ را‬
‫ﺑ ﯽ دﻟ ﯿ ﻞ ﭘ ﯿ ﭽ ﯿ ﺪ ه ﻧ ﮑ ﻨ ﺪ‪.‬‬

‫‪ .1.1.2.4‬ﻣﺪﯾﺮ ﭘﺮوژه در ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ‬

‫ﭼﺎﺑﮑﯽ روﯾﮑﺮدی در ﺳﺎﺧﺖ ﻣﺤﺼﻮل اﺳﺖ‪ .‬ﺑﺮﺧﯽ از ﻣﺘﺪوﻟﻮژیﻫﺎ ﻓﻘﻂ ﺑﺮای ﺳﺎﺧﺖ ﭼﺎﺑﮏ ﻃﺮاﺣﯽ ﺷﺪهاﻧﺪ‪ ،‬ﺑﺮﺧﯽ ﻫﻢ‬
‫ﺑﺮای ﺳﺎﺧﺖ ﭼﺎﺑﮏ و ﻫﻢ ﻣﺘﻌﯿﻦ‪ ،‬و ﺑﺮﺧﯽ ﻧﯿﺰ ﺑﯿﺸﺘﺮ ﻣﻨﺎﺳﺐ ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﻣﺘﻌﯿﻦ ﻫﺴﺘﻨﺪ‪.‬‬

‫ﺑﯿﺸﺘﺮ روشﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ ﻧﺨﺴﺖ‪ ،‬ﻣﺎﻧﻨﺪ ‪ DSDM‬و ‪ ،XP‬ﻧﻘﺸﯽ ﺑﻪﻋﻨﻮان ﻣﺪﯾﺮ ﭘﺮوژه دارﻧﺪ ﯾﺎ دﺳﺖﮐﻢ ﻣﺨﺎﻟﻔﺘﯽ ﺑﺎ‬
‫ﭼﻨﯿﻦ ﻧﻘﺸﯽ ﻧﺪارﻧﺪ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬اﺳﮑﺮام ﭼﻨﯿﻦ ﻧﻘﺸﯽ ﻧﺪارد و اﻓﺰودﻧﺶ ﺑﻪ اﺳﮑﺮام ﻧﯿﺰ ﺳﺎزﮔﺎری دروﻧﯽ آن را ﻧﺎﺑﻮد‬
‫ﻣﯽﮐﻨﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ اﻫﻤﯿﺖ ﻓﺮاواﻧﯽ دارد‪ ،‬زﯾﺮا ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﺑﺎ اﻓﺰودن ﻣﺪﯾﺮ ﭘﺮوژه ﺑﻪ اﺳﮑﺮام آن را ﺗﻘﻮﯾﺖ‬
‫ﮐﺮدهاﻧﺪ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ آن را ﺿﻌﯿﻒﺗﺮ ﮐﺮدهاﻧﺪ‪.‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﻪ دﻟﯿﻞ ﮔﺴﺘﺮدﮔﯽ ﻓﺮاوان اﺳﮑﺮام و اﯾﻦ واﻗﻌﯿﺖ ﮐﻪ ﺑﺴﯿﺎری از روشﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ دوم از اﺳﮑﺮام‬
‫اﻟﮕﻮﺑﺮداری ﮐﺮدﻧﺪ‪ ،‬ﺑﺮﺧﯽ ﻣﯽﭘﻨﺪارﻧﺪ ﮐﻪ وﺟﻮد ﻣﺪﯾﺮ ﭘﺮوژه ﺑﺎ ذات ﭼﺎﺑﮑﯽ ﻧﺎﺳﺎزﮔﺎر اﺳﺖ‪ ،‬ﮐﻪ ﮐﺎﻣﻼ اﺷﺘﺒﺎﻫﺴﺖ‪ .‬ﺑﺴﯿﺎری‬
‫از روشﻫﺎی ﭼﺎﺑﮏ ﻧﯿﺎز ﺑﻪ ﻣﺪﯾﺮ ﭘﺮوژه دارﻧﺪ‪.‬‬

‫— ‪— 57‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .2.1.2.4‬ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻣﺘﻤﺮﮐﺰ ﯾﺎ ﻧﺎﻣﺘﻤﺮﮐﺰ‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﭘﻢﺑﺎک درﺑﺎره ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ و ﻧﻪ ﻣﺪﯾﺮ ﭘﺮوژه‪ .‬ﺑﯿﺸﺘﺮ ﭘﺮوژهﻫﺎ ﻣﺪﯾﺮ ﭘﺮوژه دارﻧﺪ‪ ،‬وﻟﯽ‬
‫ﻫﯿﭻ ﭘﺮوژهای ﺑﺪون ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﻧﺠﺎم ﻧﻤﯽﺷﻮد‪ .‬ﺣﺘﯽ وﻗﺘﯽ ﺑﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺗﻮﺟﻬﯽ ﻧﺸﻮد‪ ،‬ﺑﺎزﻫﻢ ﺷﮑﻠﯽ ﺿﻤﻨﯽ از‬
‫آن در ﭘﺮوژه وﺟﻮد ﺧﻮاﻫﺪ داﺷﺖ‪.‬‬

‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه دو ﺷﮑﻞ ﮐﻠﯽ دارد‪:‬‬

‫ﻣﺘﻤﺮﮐﺰ‪ :‬در اﯾﻦ ﮔﺰﯾﻨﻪ ﮔﺮوﻫﯽ ﻣﺴﺌﻮل ﻫﻤﺎﻫﻨﮕﯽﻫﺎ و ﺳﺎﯾﺮ ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻫﺴﺘﻨﺪ‪ .‬ﻣﻌﻤﻮﻻ ﻓﺮدی ﻧﯿﺰ در‬
‫ﻣﺮﮐﺰ اﯾﻦ ﮔﺮوه ﻗﺮار دارد ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬
‫ﻧﺎﻣﺘﻤﺮﮐﺰ‪ :‬در اﯾﻦ ﮔﺰﯾﻨﻪ ﻓﺮد ﯾﺎ اﻓﺮادی ﮐﻪ ﻓﻘﻂ ﻣﺴﺌﻮل ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﺎﺷﻨﺪ وﺟﻮد ﻧﺪارﻧﺪ‪ ،‬ﺑﻠﮑﻪ ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ‬
‫ﮐﻪ ﻣﺴﺌﻮﻟﯿﺖﻫﺎی ﻓﻨﯽ دارﻧﺪ در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻧﯿﺰ ﻣﺸﺎرﮐﺖ ﻣﯽﮐﻨﻨﺪ‪.‬‬

‫ﻫﺮ دو ﺣﺎﻟﺖ‪ ،‬ﭼﻨﺎﻧﭽﻪ ﺑﺎ دﯾﮕﺮ اﺟﺰای ﻣﺘﺪوﻟﻮژی و ﻃﺒﯿﻌﺖ ﭘﺮوژه ﻫﻤﺎﻫﻨﮓ ﺑﺎﺷﻨﺪ‪ ،‬ﭘﺬﯾﺮﻓﺘﻨﯽ ﻫﺴﺘﻨﺪ‪ .‬ﺳﯿﺴﺘﻢﻫﺎی‬
‫ﻧﺎﻣﺘﻤﺮﮐﺰ را ﻓﻘﻂ در ﺗﯿﻢﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ ﻣﯽﺗﻮان ﺑﻪ ﮐﺎر ﺑﺮد و ﻧﻤﯽﺗﻮان اﻧﺘﻈﺎر داﺷﺖ ﭘﺮوژهای ﺑﺎ ﺻﺪﻫﺎ ﻧﻔﺮ‬
‫ﺧﻮدﺟﻮش و ﻧﺎﻣﺘﻤﺮﮐﺰ ﻣﺪﯾﺮﯾﺖ ﺷﻮد‪.‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﺴﯿﺎری از اﻓﺮاد ﻓﻨﯽ ﻋﻼﻗﻪای ﺑﻪ درﮔﯿﺮ ﮐﺮدن ﺧﻮد در ﻣﺴﺎﯾﻞ ﻫﻤﺎﻫﻨﮕﯽ و ﻣﺪﯾﺮﯾﺘﯽ ﻧﺪارﻧﺪ و ﭼﻨﺎﻧﭽﻪ‬
‫وادار ﺑﻪ ﭼﻨﯿﻦ ﮐﺎری ﺷﻮﻧﺪ‪ ،‬درﺟﻪ رﺿﺎﯾﺘﺸﺎن در ﭘﺮوژه ﮐﺎﻫﺶ ﺧﻮاﻫﺪ ﯾﺎﻓﺖ‪ .‬ﭼﻨﯿﻦ ﮐﺴﺎﻧﯽ ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ در ﻓﻀﺎﯾﯽ‬
‫ﮐﺎر ﮐﻨﻨﺪ ﮐﻪ ﺳﯿﺴﺘﻤﯽ ﻣﺘﻤﺮﮐﺰ ﺑﺮای ﻫﻤﺎﻫﻨﮕﯽﻫﺎ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ و اﻧﻮاع ﺧﺪﻣﺎت ﻣﺪﯾﺮﯾﺘﯽ را ﺑﻪ آنﻫﺎ ﺑﺪﻫﺪ ﺗﺎ‬
‫ﺑﺘﻮاﻧﻨﺪ در ﻓﻀﺎﯾﯽ اﻣﻦ ﺑﺮ ﮐﺎرﻫﺎی ﺗﺨﺼﺼﯽ ﺧﻮد ﺗﻤﺮﮐﺰ ﮐﻨﻨﺪ‪.‬‬

‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻦ دو ﻣﺴﺌﻠﻪ‪ ،‬ﮐﺎرﺑﺮد ﺳﯿﺴﺘﻢﻫﺎی ﻧﺎﻣﺘﻤﺮﮐﺰ ﺑﺴﯿﺎر ﻣﺤﺪود ﻣﯽﺷﻮد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﮐﺴﺐ و ﮐﺎر ﮐﻮﭼﮑﯽ‬
‫ﻫﻤﺮاه ﺑﺎ ﭼﻨﺪ ﻧﻔﺮ دﯾﮕﺮ راه اﻧﺪاﺧﺘﻪ ﺑﺎﺷﯿﺪ و در آن ﭘﺮوژهﻫﺎﯾﯽ اﻧﺠﺎم دﻫﯿﺪ‪ ،‬ﺷﺎﯾﺪ ﺳﯿﺴﺘﻢ ﻧﺎﻣﺘﻤﺮﮐﺰ اﻧﺘﺨﺎب ﺧﻮﺑﯽ‬
‫ﺑﺮاﯾﺘﺎن ﺑﺎﺷﺪ‪ .‬اﯾﻦ ﺳﯿﺴﺘﻢﻫﺎ در ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﻣﺤﺒﻮﺑﯿﺖ ﺑﯿﺸﺘﺮی دارﻧﺪ‪ .‬ﺑﺎ اﯾﻦﮐﻪ ﻣﺘﺪوﻟﻮژیﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ‪DSDM‬‬
‫ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺘﯽ ﻣﺘﻤﺮﮐﺰ دارد‪ ،‬اﺳﮑﺮام اﯾﻦﮔﻮﻧﻪ ﻧﯿﺴﺖ‪ .‬ﺳﯿﺴﺘﻢﻫﺎی ﺗﺎزهﺗﺮ ﭼﺎﺑﮏ ﻫﻢ ﺑﺎ اﻟﮕﻮﺑﺮداری از اﺳﮑﺮام‬
‫ﻣﯽﮐﻮﺷﻨﺪ ﻧﺎﻣﺘﻤﺮﮐﺰ ﺑﺎﺷﻨﺪ ﯾﺎ ﺣﺪاﻗﻞ واﻧﻤﻮد ﮐﻨﻨﺪ ﮐﻪ اﯾﻨﮕﻮﻧﻪ ﻫﺴﺘﻨﺪ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﭼﺎﻟﺶﻫﺎی ﻓﺮاواﻧﯽ ﺑﺮای ﺳﯿﺴﺘﻢﻫﺎی‬
‫ﭼﺎﺑﮏ ﻧﺴﻞ دوﻣﯽ ﮐﻪ ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺰرگﺗﺮ ﻃﺮاﺣﯽ ﺷﺪهاﻧﺪ اﯾﺠﺎد ﮐﺮده اﺳﺖ‪.‬‬

‫ﺑﻪ ﻫﺮ روی‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﻣﺪﯾﺮ ﭘﺮوژه داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﯾﺎ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ ،‬اﻣﺎ ﻫﻤﯿﺸﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺧﻮاﻫﯿﺪ داﺷﺖ و ﺑﻬﺘﺮ‬
‫اﺳﺖ آن را ﺳﺎﺧﺖﯾﺎﻓﺘﻪ و ﮐﺎرآﻣﺪ ﭘﯿﺶ ﺑﺒﺮﯾﺪ‪.‬‬

‫‪ .3.1.2.4‬ﺣﺎﻣﯽ ﭘﺮوژه‬

‫ﺑﺮﺧﯽ ﻣﺪﯾﺮ ﭘﺮوژه را ﺑﺎﻻﺗﺮﯾﻦ ﻧﻘﺶ ﭘﺮوژه ﻣﯽداﻧﻨﺪ‪ ،‬وﻟﯽ ﺑﯿﺸﺘﺮ ﻣﺘﺪوﻟﻮژیﻫﺎ ﻧﻘﺶ دﯾﮕﺮی ﺑﺎﻻﺗﺮ از ﻣﺪﯾﺮ ﭘﺮوژه دارﻧﺪ؛‬
‫ﻣﺪﯾﺮی ارﺷﺪ ﮐﻪ ﻣﯽﺗﻮاﻧﺪ‬

‫ﺑﺎ ﻗﺪرت ﺳﺎزﻣﺎﻧﯽای ﮐﻪ دارد ﺑﻮدﺟﻪ و ﺳﺎﯾﺮ ﻣﻨﺎﺑﻊ ﺑﺮای ﭘﺮوژه ﻓﺮاﻫﻢ ﮐﻨﺪ‪ ،‬و‬
‫ﺑﺮ ﭘﺎﯾﻪ داﻧﺸﯽ ﮐﻪ از اﺳﺘﺮاﺗﮋیﻫﺎی ﺑﻠﻨﺪﻣﺪت ﺳﺎزﻣﺎن دارد و دﯾﺪ ﮐﻼﻧﯽ ﮐﻪ در ﺳﻄﺢ ﺳﺎزﻣﺎن ﭘﯿﺪا ﮐﺮده اﺳﺖ‬

‫— ‪— 58‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺗﺼﻤﯿﻢﮔﯿﺮیﻫﺎی ﮐﻼن ﭘﺮوژه را ﺑﺮ دوش ﺑﮕﯿﺮد‪.‬‬

‫اﯾﻦ دو ﮐﺎر از ﺑﯿﺸﺘﺮ ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎ ﺳﺎﺧﺘﻪ ﻧﯿﺴﺖ‪ ،‬زﯾﺮا از ﯾﮏ ﺳﻮ ﻣﻌﻤﻮﻻ ﻗﺪرت ﺳﺎزﻣﺎﻧﯽ ﭼﻨﺪاﻧﯽ ﻧﺪارﻧﺪ )ﻣﺪﯾﺮ ارﺷﺪ‬
‫ﻧﯿﺴﺘﻨﺪ( و از رﯾﺰهﮐﺎریﻫﺎی اﺳﺘﺮاﺗﮋﯾﮏ و ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻠﻨﺪﻣﺪت ﺳﺎزﻣﺎن ﮐﻪ ﮔﺎﻫﯽ ﻓﻘﻂ در اﺧﺘﯿﺎر ﻣﺪﯾﺮان ارﺷﺪ و‬
‫ﺳﻬﺎمداران اﺳﺖ ﺑﯽاﻃﻼﻋﻨﺪ و از ﺳﻮی دﯾﮕﺮ ﺑﯿﺸﺘﺮ اﻓﺮاد ﻧﻤﯽﺗﻮاﻧﻨﺪ در ﻣﻮﺿﻮﻋﯽ ﯾﮑﻪ ﻫﻢ ﻣﺴﺌﻮﻟﯿﺖﻫﺎی اﻧﺘﺰاﻋﯽ و ﻫﻢ‬
‫روزﻣﺮه را ﺑﺮ دوش داﺷﺘﻪ ﺑﺎﺷﻨﺪ و در اﻧﺠﺎم ﯾﮑﯽ از اﯾﻦ دو ﻣﻮرد )ﻣﻌﻤﻮﻻ ﮐﺎرﻫﺎی اﻧﺘﺰاﻋﯽﺗﺮ( ﺳﻬﻞاﻧﮕﺎری ﻣﯽﮐﻨﻨﺪ‪.‬‬

‫ﻧﻘﺸﯽ ﮐﻪ در راس ﭘﺮوژه ﻗﺮار ﻣﯽﮔﯿﺮد‪ ،‬در ﺑﺴﯿﺎری از ﻣﻨﺎﺑﻊ‪ ،‬ازﺟﻤﻠﻪ ‪ ،P3.express‬ﺣﺎﻣﯽ ﭘﺮوژه )‪ ،( sponsor‬در‬
‫ﭘﺮﯾﻨﺲ‪ ۲‬ﻣﺪﯾﺮ ارﺷﺪ )‪ (executive‬و در ‪ DSDM‬ﺣﺎﻣﯽ ﮐﺴﺐ و ﮐﺎر )‪ (business sponsor‬ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬

‫‪ .4 . 1 . 2 . 4‬ﺑ ﺮ ﭼ ﺴ ﺐ ﻫ ﺎ‬

‫در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ اﻓﺮاد و ﺳﺎزﻣﺎنﻫﺎی ﻣﺨﺘﻠﻒ ﺑﺮﭼﺴﺐﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ »ﻣﺪﯾﺮ ﭘﺮوژه« و »ﺣﺎﻣﯽ ﭘﺮوژه« را ﺑﻪ‬
‫ﺷﮑﻞﻫﺎی ﮔﻮﻧﺎﮔﻮﻧﯽ ﺑﻪ ﮐﺎر ﻣﯽﺑﺮﻧﺪ‪ .‬ﮔﺎﻫﯽ ﻓﺮدی ﮐﻪ ﻣﺪﯾﺮ ﭘﺮوژه ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد درواﻗﻊ ﻧﻘﺶ ﺣﺎﻣﯽ ﭘﺮوژه را دارد و‬
‫ﮐﺎرﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﻓﺮدی اﻧﺠﺎم ﻣﯽدﻫﺪ ﮐﻪ ﺑﺮﭼﺴﺐ رﻫﺒﺮ ﺗﯿﻢ‪ ،‬رﺋﯿﺲ ﮐﺎرﮔﺎه و ﻫﻤﺎﻧﻨﺪ آن را دارد‪.‬‬

‫ﻓﺮﯾﺐ ﺑﺮﭼﺴﺐﻫﺎ را ﻧﺨﻮرﯾﺪ و اﮔﺮ ﮔﻤﺎن ﻣﯽﮐﻨﯿﺪ ﺑﺮﭼﺴﺐﻫﺎی ﭘﯿﺶﻓﺮﺿﯽ ﮐﻪ در ﻣﺘﺪوﻟﻮژﯾﺘﺎن وﺟﻮد دارﻧﺪ ﺑﺎ آﻧﭽﻪ در‬
‫ﻣﺤﯿﻂ اﻃﺮاﻓﺘﺎن اﺳﺘﻔﺎده ﻣﯽﺷﻮﻧﺪ ﺳﺎزﮔﺎر ﻧﯿﺴﺘﻨﺪ‪ ،‬ﺑﺮﭼﺴﺐﻫﺎی دﯾﮕﺮی اﻧﺘﺨﺎب ﮐﻨﯿﺪ ﮐﻪ ﺳﻮﺗﻔﺎﻫﻢ اﯾﺠﺎد ﻧﮑﻨﻨﺪ‪ .‬اﮔﺮ‬
‫وﺟﻮد ﻣﺪﯾﺮ ﭘﺮوژه در ﻣﺘﺪوﻟﻮژﯾﺘﺎن اﺟﺒﺎرﯾﺴﺖ‪ ،‬ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﻧﯿﺴﺖ ﮐﻪ وﺟﻮد ﺑﺮﭼﺴﺒﯽ ﺑﺎ آن ﻧﺎم اﻟﺰاﻣﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﺑﻪ‬
‫اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ وﺟﻮد ﻧﻘﺸﯽ ﺑﺎ ﻣﺴﺌﻮﻟﯿﺖﻫﺎی ﺗﻌﺮﯾﻒ ﺷﺪه اﻟﺰاﻣﯿﺴﺖ‪.‬‬

‫‪ .2.2.4‬ﺑﻬﺒﻮد ﺗﯿﻢ‬

‫ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ در ﺣﺎل ﺑﻬﺒﻮد ﺗﯿﻢ ﺑﺎﺷﯿﺪ‪ .‬ﺑﺴﯿﺎری از ﻣﺘﺪوﻟﻮژیﻫﺎ روشﻫﺎﯾﯽ وﯾﮋه و ﮔﺎﻫﯽ ﻧﺎﻣﺤﺴﻮس ﺑﺮای ﺗﯿﻢﺳﺎزی‬
‫دارﻧﺪ ﮐﻪ ﺷﺎﯾﺪ در ﻓﻌﺎﻟﯿﺖﻫﺎی ﻏﯿﺮاﻧﺘﺰاﻋﯽﺗﺮ ﻣﺨﻔﯽ ﺷﺪه ﺑﺎﺷﻨﺪ‪ .‬ﭼﻨﯿﻦ ﺗﺮﮐﯿﺐﻫﺎﯾﯽ ﻣﻌﻤﻮﻻ ﺑﻬﺘﺮ از ﺑﺮﻧﺎﻣﻪﻫﺎﯾﯽ ﮐﻪ ﻓﻘﻂ‬
‫ﺑﺮای ﺗﯿﻢﺳﺎزی ﺑﺎﺷﻨﺪ ﻋﻤﻞ ﻣﯽﮐﻨﻨﺪ‪.‬‬

‫ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﺑﺮرﺳﯽ ﮐﻨﯿﺪ ﺗﺎ ﺑﺒﯿﻨﯿﺪ ﻓﻌﺎﻟﯿﺖﻫﺎی ﺗﯿﻢﺳﺎزی ﻣﺴﺘﻘﯿﻢ و ﻏﯿﺮﻣﺴﺘﻘﯿﻢ آن ﺑﺮای ﭘﺮوژهﺗﺎن ﮐﺎﻓﯿﺴﺖ ﯾﺎ‬
‫ﻧﻪ‪ .‬اﮔﺮ ﻧﺒﻮد‪ ،‬راهﻫﺎی ﻧﻮآوراﻧﻪای ﺑﺮای آﻣﯿﺨﺘﻦ آن ﺑﺎ ﻓﻌﺎﻟﯿﺖﻫﺎی ﻣﻮﺟﻮد در ﻣﺘﺪوﻟﻮژی ﺑﯿﺎﺑﯿﺪ‪.‬‬

‫ﯾﮑﯽ از ﺑﻬﺘﺮﯾﻦ روشﻫﺎ ﺑﺮای ﺗﻘﻮﯾﺖ ﺗﯿﻢ اﯾﻦ اﺳﺖ ﮐﻪ ﺣﺲ ﻫﺪف ﻣﺸﺘﺮک داﺷﺘﻦ ﺑﻪ وﺟﻮد آورﯾﺪ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ اﻓﺮاد‬
‫ﺣﺲ ﮐﻨﻨﺪ ﮐﻪ ﻫﻤﺮاه ﻫﻢ در راﺳﺘﺎی ﺑﻪﺳﺮاﻧﺠﺎم رﺳﺎﻧﺪن ﻫﺪﻓﯽ ﮐﻮﺷﺶ ﻣﯽﮐﻨﻨﺪ ﺑﻬﺘﺮ ﻣﯽﺗﻮاﻧﻨﺪ ﻫﻤﮑﺎری ﮐﻨﻨﺪ ﺗﺎ زﻣﺎﻧﯽ‬
‫ﮐﻪ ﻓﻘﻂ ﺑﺮ ﻓﻌﺎﻟﯿﺖﻫﺎی ﺗﺨﺼﺼﯽ ﺧﻮد ﻣﺘﻤﺮﮐﺰﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬زﻣﺎﻧﯽ ﮐﻪ ﻣﻮﺳﺴﻪﻫﺎی ﻣﺨﺘﻠﻒ ﺑﺮای ﺳﺎﺧﺖ واﮐﺴﻦ‬
‫ﮐﺮوﻧﺎ ﻣﯽﮐﻮﺷﯿﺪﻧﺪ‪ ،‬ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎﯾﺸﺎن ﻣﯽﺗﻮاﻧﺴﺘﻨﺪ از اﯾﻦ ﻓﺮﺻﺖ ﺑﻬﺮه ﮔﯿﺮﻧﺪ و ﺑﺎ ﯾﺎدآوری داﯾﻤﯽ اﯾﻦ واﻗﻌﯿﺖ ﮐﻪ ﮐﻞ‬
‫ﺗﯿﻢ ﺑﺮای ﺣﻔﻆ ﺟﺎن اﻧﺴﺎنﻫﺎ در ﺗﻼش اﺳﺖ رواﺑﻂ درونﺗﯿﻤﯽ را ﺑﻬﺒﻮد دﻫﻨﺪ‪.‬‬

‫‪ .3.2.4‬رﻫﺒﺮی‬

‫— ‪— 59‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ ﭘﯿﺶ از اﯾﻦ ﻧﯿﺰ ﻃﺮح ﺷﺪ‪ ،‬دو ﻣﻮﺿﻮع اﺻﻠﯽ در رﻫﺒﺮی وﺟﻮد دارد‪:‬‬

‫ﭼﮕﻮﻧﻪ رﻫﺒﺮان ﭘﻨﻬﺎن را ﮐﺸﻒ و ﭘﺸﺘﯿﺒﺎﻧﯽ ﮐﻨﯿﻢ؟‬

‫ﭼﮕﻮﻧﻪ ﻣﻬﺎرتﻫﺎی رﻫﺒﺮی ﺧﻮد را ﺑﻬﺒﻮد دﻫﯿﻢ؟‬

‫ﻓﻬﺮﺳﺘﯽ از ﻣﻬﺎرتﻫﺎی رﻫﺒﺮی‪ ،‬ﻣﺎﻧﻨﺪ اﯾﺠﺎد اﻧﮕﯿﺰه‪ ،‬رﻓﻊ اﺧﺘﻼف‪ ،‬ﺣﻞ ﻣﺴﺌﻠﻪ‪ ،‬ﻣﺬاﮐﺮه‪ ،‬و ﺗﺴﻬﯿﻞﮔﺮی آﻣﺎده ﮐﺮده‪ ،‬آﻏﺎز‬
‫ﺑﻪ ﺑﻬﺒﻮد ﻣﻬﺎرتﻫﺎی ﺧﻮد در ﻫﺮﯾﮏ از آنﻫﺎ ﮐﻨﯿﺪ‪ .‬ﺑﺮای اﯾﻦ ﮐﺎر ﻣﻨﺎﺑﻊ ﻓﺮاواﻧﯽ وﺟﻮد دارد و ﺑﺎ ﻣﻄﺎﻟﻌﻪ آنﻫﺎ و ﺗﻤﺮﯾﻦ در‬
‫ﻓﻀﺎی واﻗﻌﯽ ﭘﺮوژه ﺑﻪﺗﺪرﯾﺞ ﻣﯽﺗﻮاﻧﯿﺪ ﺗﻮاﻧﺎﯾﯽﻫﺎی ﺧﻮد را اﻓﺰاﯾﺶ دﻫﯿﺪ‪ .‬ﺧﻮب اﺳﺖ ﮐﻪ ﭼﻨﯿﻦ آﻣﻮزشﻫﺎﯾﯽ را در‬
‫اﺧﺘﯿﺎر ﺑﺮﺧﯽ دﯾﮕﺮ از اﻋﻀﺎی ﺗﯿﻢ ﻧﯿﺰ ﺑﮕﺬارﯾﺪ‪ ،‬ﺑﻪ وﯾﮋه ﮐﺴﺎﻧﯽ ﮐﻪ ﭘﺘﺎﻧﺴﯿﻞ ﮐﻤﮏ ﺑﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه دارﻧﺪ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻓﺮض ﮐﻨﯿﺪ ﻣﻬﻨﺪس ﺟﻮاﻧﯽ در ﭘﺮوژه وﺟﻮد دارد ﮐﻪ دوﺳﺖ دارد زﻣﺎﻧﯽ ﻣﺪﯾﺮ ﭘﺮوژه ﺷﻮد‪ ،‬و ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ‬
‫ﭘﯿﺶﺗﺮ ﮔﻔﺘﻪ ﺷﺪ‪ ،‬ﻣﺴﺌﻮﻟﯿﺖ دارﯾﺪ ﮐﻪ ﻓﻀﺎی رﺷﺪ در اﺧﺘﯿﺎر ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ ﺑﮕﺬارﯾﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻓﺮض ﮐﻨﯿﺪ ﮐﻪ‬
‫در ﺗﺴﻬﯿﻞﮔﺮی ﭼﻨﺪان ﻣﺎﻫﺮ ﻧﯿﺴﺘﯿﺪ و ﻓﻌﻼ زﻣﺎن ﮐﺎﻓﯽ ﺑﺮای ﺑﻬﺒﻮد اﯾﻦ ﻣﻬﺎرت ﻧﺪارﯾﺪ‪ .‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ از اﯾﻦ ﻓﺮﺻﺖ‬
‫اﺳﺘﻔﺎده ﮐﻨﯿﺪ و اﮔﺮ آن ﻣﻬﻨﺪس ﺟﻮان ﻋﻼﻗﻪﻣﻨﺪ اﺳﺖ‪ ،‬ﺑﺮاﯾﺶ آﻣﻮزش ﺗﺴﻬﯿﻞﮔﺮی ﻓﺮاﻫﻢ ﮐﻨﯿﺪ و ﭘﺲ از آن ﻣﺴﺌﻮﻟﯿﺖ‬
‫ﺗﺴﻬﯿﻞﮔﺮی ﮐﺎرﮔﺎهﻫﺎ و ﺟﻠﺴﻪﻫﺎ را ﺑﺮ دوﺷﺶ ﺑﮕﺬارﯾﺪ‪ .‬اﯾﻨﮕﻮﻧﻪ‪ ،‬ﻫﻢ ﻓﺮﺻﺘﯽ ﺑﻪ آن ﻣﻬﻨﺪس ﺟﻮان دادهاﯾﺪ و ﻫﻢ‬
‫ﻣﺸﮑﻠﯽ ﮐﻪ ﺧﻮد داﺷﺘﻪاﯾﺪ را ﺣﻞ ﮐﺮدهاﯾﺪ‪.‬‬

‫راﻫﮑﺎر ﭘﯿﺸﯿﻦ ﻧﻤﻮﻧﻪای از ﺣﺎﻟﺖ ﺑﺮد‪-‬ﺑﺮد اﺳﺖ‪ .‬ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ اﮔﺮ ﻣﻬﺎرت ﮐﺎﻓﯽ در ﻣﺬاﮐﺮه داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﺑﺎﯾﺪ‬
‫ﺑﺘﻮاﻧﻨﺪ ﺑﺮﻧﺪه ﻫﻤﻪ ﻣﺬاﮐﺮهﻫﺎ ﺑﺎﺷﻨﺪ‪ ،‬ﺣﺘﯽ ﺑﻪ ﻗﯿﻤﺖ ﺷﮑﺴﺖ ﻃﺮف دﯾﮕﺮ‪ .‬ﯾﮑﯽ از وﯾﮋﮔﯽﻫﺎی ﻣﺬاﮐﺮهﮐﻨﻨﺪه ﻣﺎﻫﺮ اﯾﻦ‬
‫اﺳﺖ ﮐﻪ ﻫﻤﯿﺸﻪ ﺷﺮاﯾﻂ ﺑﺮد‪-‬ﺑﺮد ﺑﻪ وﺟﻮد آورد‪ ،‬زﯾﺮا اﮔﺮ ﻃﺮف دﯾﮕﺮ ﺑﺮﻧﺪه ﻧﺒﺎﺷﺪ‪ ،‬ﺑﺮد ﺧﻮدش ﻧﯿﺰ ﻫﻤﯿﺸﮕﯽ ﻧﺨﻮاﻫﺪ‬
‫ﺑﻮد و ﺟﺎﯾﯽ ﻣﺸﮑﻞ اﯾﺠﺎد ﺧﻮاﻫﺪ ﺷﺪ‪ .‬آﯾﺎ ﻣﺎﯾﻠﯿﺪ ﺑﯿﺸﺘﺮ درﺑﺎره ﻣﺬاﮐﺮه ﺑﯿﺎﻣﻮزﯾﺪ؟ اﮔﺮ ﻣﺎﯾﻞ ﻫﺴﺘﯿﺪ‪ ،‬ﯾﮑﯽ از ﻣﻨﺎﺑﻊ ﺧﻮﺑﯽ‬
‫ﮐﻪ در اﯾﻦ ﺣﻮزه وﺟﻮد دارد را اﻧﺘﺨﺎب و ﻣﻄﺎﻟﻌﻪ‪ ،‬و ﻫﺮآنﭼﻪ ﻣﯿﺎﻣﻮزﯾﺪ را در ﻋﻤﻞ ﺗﺠﺮﺑﻪ ﮐﻨﯿﺪ‪.‬‬

‫‪ .3.4‬ﭼﺮﺧﻪ ﺣﯿﺎت و روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬

‫ﻣﻮﺿﻮع ﭼﺮﺧﻪ ﺣﯿﺎت و روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﮔﺴﺘﺮده و ﮐﻤﺎﺑﯿﺶ ﭘﯿﭽﯿﺪه اﺳﺖ و ﭼﯿﺮﮔﯽ ﮐﺎﻣﻞ ﺑﺮ آنﻫﺎ ﺑﺮای ﺑﯿﺸﺘﺮ‬
‫ﻣﺪﯾﺮ ﭘﺮوژهﻫﺎ اﻟﺰاﻣﯽ ﻧﯿﺴﺖ‪ .‬در اﯾﻦ ﺑﺨﺶ ﻓﻘﻂ ﻣﺴﺎﯾﻠﯽ ﮐﻪ در اﯾﻦ ﺣﻮزه اﻫﻤﯿﺖ ﺑﯿﺸﺘﺮی دارﻧﺪ و ﺑﺮای ﻫﻤﻪ ﻣﺪﯾﺮ‬
‫ﭘﺮوژهﻫﺎ ﻻزم ﻫﺴﺘﻨﺪ را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﯿﻢ‪.‬‬

‫‪ .1.3.4‬ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬

‫ﻣﺤﺼﻮل ﭘﺮوژه را ﻣﯽﺗﻮان ﺑﻪ ﺷﯿﻮه ﻣﺘﻌﯿﻦ ﯾﺎ ﺗﻄﺒﯿﻘﯽ )ﭼﺎﺑﮏ( ﺳﺎﺧﺖ‪ .‬ﭘﯿﺶ از اﯾﻦ ﭼﮕﻮﻧﮕﯽ اﯾﻦ دو روش را ﺑﺮرﺳﯽ‬
‫ﮐﺮدﯾﻢ و اﮔﺮ آن را ﺑﻪ ﯾﺎد ﻧﺪارﯾﺪ ﺑﻬﺘﺮ اﺳﺖ ﭘﯿﺶ از اداﻣﻪ دادن اﯾﻦ ﺑﺨﺶ ﻧﮕﺎه دوﺑﺎرهای ﺑﻪ آن ﺑﯿﻨﺪازﯾﺪ‪.‬‬

‫ﺑﺎ اﯾﻦ ﻓﺮض ﮐﻪ ﻣﯽداﻧﯿﺪ اﯾﻦ دو روش ﭼﻪ ﻫﺴﺘﻨﺪ و ﭼﻪ ﺗﻔﺎوتﻫﺎﯾﯽ ﺑﺎ ﻫﻢ دارﻧﺪ‪ ،‬ﺑﺎﯾﺪ ﮐﻤﯽ ﺑﯿﺸﺘﺮ اﯾﻦﮐﻪ ﭼﻪ روﺷﯽ‬
‫ﺑﺮای ﭼﻪ ﻧﻮع ﭘﺮوژهای ﻣﻨﺎﺳﺐ اﺳﺖ را ﺑﺮرﺳﯽ ﮐﻨﯿﻢ‪ .‬اﻟﺒﺘﻪ ﭘﯿﺶ از آن ﻧﯿﺎز ﺑﻪ ﮐﻤﯽ اﻃﻼﻋﺎت ﭘﯿﺮاﻣﻮﻧﯽ ﻫﻢ دارﯾﻢ و‬
‫ﺑﻨﺎﺑﺮاﯾﻦ ﻣﺒﺤﺚ را ﺑﺎ آن ﻣﻮﺿﻮعﻫﺎ آﻏﺎز ﺧﻮاﻫﯿﻢ ﮐﺮد‪.‬‬

‫— ‪— 60‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .1 . 1 . 3 . 4‬ﭘ ﯿ ﺸ ﯿ ﻨ ﻪ ر و ش ﻫ ﺎ ی ﭼ ﺎ ﺑ ﮏ‬

‫ﺗﻤﺪن ﺑﺸﺮی ﻫﻤﯿﺸﻪ از ﻫﺮ دو روش ﻣﺘﻌﯿﻦ و ﺗﻄﺒﯿﻘﯽ اﺳﺘﻔﺎده ﮐﺮده اﺳﺖ و ﻧﺸﺎﻧﻪﻫﺎی آن را ﻣﯽﺗﻮان در ﺑﺴﯿﺎری‬
‫ﭘﺮوژهﻫﺎی ﺑﺎﺳﺘﺎﻧﯽ دﯾﺪ‪ .‬ﻧﺨﺴﺘﯿﻦ ﻧﺴﻞ ﮐﺎﻣﭙﯿﻮﺗﺮﻫﺎ ﻣﺤﺪودﯾﺖﻫﺎی ﻓﺮاوان و ﻣﺨﺎﻃﺐ وﯾﮋه و اﻧﺪﮐﯽ داﺷﺘﻨﺪ ﮐﻪ ﺑﺎﻋﺚ‬
‫ﻣﯽﺷﺪ ﺳﺎﺧﺖ ﻧﺮماﻓﺰارﻫﺎﯾﺸﺎن ﻧﯿﺎز ﺑﻪ روﺷﯽ ﻣﺘﻌﯿﻦ داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺑﺎ ﭘﯿﺸﺮﻓﺖ ﺳﺨﺖاﻓﺰار‪ ،‬ﮐﺎﻫﺶ ﻣﺤﺪودﯾﺖﻫﺎ‪ ،‬و‬
‫دﮔﺮﮔﻮﻧﯽ ﻧﻮع و ﮔﺴﺘﺮدﮔﯽ ﻣﺨﺎﻃﺐ ﻧﺮماﻓﺰارﻫﺎ‪ ،‬روشﻫﺎی ﻣﺘﻌﯿﻦ دﯾﮕﺮ ﮔﺰﯾﻨﻪ ﺧﻮﺑﯽ ﺑﺮای ﺳﺎﺧﺖ ﻧﺮماﻓﺰار ﻧﺒﻮدﻧﺪ‪ ،‬وﻟﯽ‬
‫دﺳﺖاﻧﺪرﮐﺎران اﯾﻦ ﻧﻮع ﭘﺮوژهﻫﺎ ﻫﻤﭽﻨﺎن ﺑﻪ ﻋﺎدت ﮔﺬﺷﺘﻪ ﻣﯽﮐﻮﺷﯿﺪﻧﺪ روشﻫﺎی ﻣﺘﻌﯿﻦ را ﺑﻪﮐﺎر ﮔﯿﺮﻧﺪ‪.‬‬

‫ﺗﺤﻤﯿﻞ روشﻫﺎی ﻣﺘﻌﯿﻦ ﺑﺮ ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﻫﻤﭽﻨﺎن اداﻣﻪ ﭘﯿﺪا ﮐﺮد‪ ،‬ﺗﺎ زﻣﺎﻧﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن و ﻣﺪﯾﺮان ﺗﯿﻢﻫﺎ‬
‫ﺑﯿﺸﺘﺮ و ﺑﯿﺸﺘﺮ از وﺿﻌﯿﺖ ﻧﺎراﺿﯽ ﺷﺪﻧﺪ و ﮔﺮاﯾﺶ ﺑﻪ ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺑﻪ ﺷﯿﻮه ﺗﻄﺒﯿﻘﯽ ﭘﯿﺪا ﮐﺮدﻧﺪ‪ .‬ﺳﺮاﻧﺠﺎم‪،‬‬
‫ﮔﺮوﻫﯽ از اﯾﻦ اﻓﺮاد دورﻫﻢ ﮔﺮد آﻣﺪﻧﺪ ﺗﺎ ﺑﻪ روﯾﮑﺮد ﺧﻮد رﺳﻤﯿﺖ ﺑﺨﺸﻨﺪ و ﺑﺮای آن ﻧﺎم ﭼﺎﺑﮏ را اﻧﺘﺨﺎب ﮐﺮدﻧﺪ‪.‬‬

‫ﻣﺘﺎﺳﻔﺎﻧﻪ اﺧﺘﻼفﻫﺎ و ﻣﺸﮑﻞﻫﺎی ﻓﺮاواﻧﯽ ﮐﻪ در اﯾﻦ روﻧﺪ ﺑﻪ وﺟﻮد آﻣﺪه ﺑﻮد ذﻫﻨﯿﺘﯽ ﻣﻨﻔﯽ درﺑﺎره روشﻫﺎی ﻣﺘﻌﯿﻦ‬
‫ﺑﺮای اﯾﻦ اﻓﺮاد و ﮐﺴﺎﻧﯽ ﮐﻪ اداﻣﻪدﻫﻨﺪه راﻫﺸﺎن ﺷﺪﻧﺪ ﺑﻪ وﺟﻮد آورد‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ﺑﻪﺟﺎی اﺻﻼﺣﯽ ﺗﺪرﯾﺠﯽ‪،‬‬
‫اﻧﻘﻼﺑﯽ ﺧﻮﻧﯿﻦ ﺑﻪ وﺟﻮد آﻣﺪ‪ .‬ﮐﻤﯽ ﭘﺲ از اﻧﻘﻼب ﻫﻢ ﮔﺮوﻫﯽ ﮐﻮﭼﮏ ﻣﻬﺮهﻫﺎی اﺻﻠﯽ را ﮐﻨﺎر زده‪ ،‬ﻗﺪرت ﻣﻄﻠﻖ را ﺑﻪ‬
‫دﺳﺖ ﮔﺮﻓﺘﻨﺪ‪ .‬داﯾﻤﺎ ﻫﻢ درﺑﺎره دﺷﻤﻦ ﺑﯿﺮوﻧﯽ ﻫﺸﺪار ﻣﯽدﻫﻨﺪ! ﺑﺮای اﻃﻼﻋﺎت ﺑﯿﺸﺘﺮ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ ﮐﺘﺎب »ﻗﻠﻌﻪ‬
‫ﺣﯿﻮاﻧﺎت«‪ ،‬اﺛﺮ ﺟﻮرج اورول ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬

‫روشﻫﺎی ﭼﺎﺑﮏ ﻣﺴﺘﻘﻞ و ﺑﺪون ﮐﻤﮏ ﮔﺮﻓﺘﻦ از ﺗﺠﺮﺑﻪﻫﺎی ﺳﺎﯾﺮ روشﻫﺎی ﺳﺎﺧﺖ ﺷﮑﻞ ﮔﺮﻓﺘﻨﺪ‪ .‬اﯾﻦ وﯾﮋﮔﯽ ﻫﻢ‬
‫ﺟﻨﺒﻪﻫﺎی ﻣﺜﺒﺖ دارد )ﻧﻮآوری ﺑﯿﺸﺘﺮ( و ﻫﻢ ﻣﻨﻔﯽ )اﺷﺘﺒﺎهﻫﺎ و ﺗﺒﺎه ﮐﺮدن ﻣﻨﺎﺑﻊ ﺑﯿﺸﺘﺮ(‪ .‬اﯾﻦ روشﻫﺎ اﺛﺒﺎت ﮐﺮدﻧﺪ ﮐﻪ‬
‫ﺳﯿﺴﺘﻢﻫﺎی ﺳﺎده ﻣﯽﺗﻮاﻧﻨﺪ ﮐﺎرآﻣﺪﺗﺮ از ﺳﯿﺴﺘﻢﻫﺎی ﭘﯿﭽﯿﺪه ﺑﺎﺷﻨﺪ‪ .‬ﺟﻨﺒﻪﻫﺎی اﻧﺴﺎﻧﯽ در ﺑﺴﯿﺎری از ﺳﯿﺴﺘﻢﻫﺎی‬
‫ﭼﺎﺑﮏ ﻧﻬﺎدﯾﻨﻪ ﺷﺪه ﺑﻮدﻧﺪ ﮐﻪ ﺧﻮد ﭘﯿﺎﻣﺪﻫﺎی ﺑﺴﯿﺎر ﺧﻮﺑﯽ داﺷﺖ‪ ،‬ﺑﺎ اﯾﻦﮐﻪ ﺑﺴﯿﺎری دﯾﮕﺮ از ﺳﯿﺴﺘﻢﻫﺎ درﺑﺎره اﻫﻤﯿﺖ‬
‫ﻣﺴﺎﯾﻞ اﻧﺴﺎﻧﯽ ﺳﺨﻦ ﻣﯽﮔﻔﺘﻨﺪ‪ ،‬وﻟﯽ آنﻫﺎ را ﺑﻪ ﺷﮑﻠﯽ ﮐﺎرا در ﺳﯿﺴﺘﻢ ﺧﻮد ﺑﻪ ﺟﺮﯾﺎن ﻧﯿﺎﻧﺪاﺧﺘﻪ ﺑﻮدﻧﺪ‪ .‬اﯾﻦ دو ﺟﻨﺒﻪ‬
‫و ﺑﺮﺧﯽ دﯾﮕﺮ از ﯾﺎﻓﺘﻪﻫﺎی اﯾﻦ ﺣﻮزه ﺑﺴﯿﺎر ﺑﺎارزﺷﻨﺪ و ﭼﻪﺑﺴﺎ ﺑﺴﯿﺎری از ﺳﯿﺴﺘﻢﻫﺎﯾﯽ ﮐﻪ در آﯾﻨﺪه ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮﻧﺪ‬
‫ﻧﯿﺰ آنﻫﺎ را ﺑﻪ ارث ﺧﻮاﻫﻨﺪ ﺑﺮد‪.‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬دﯾﺪﮔﺎه ﻣﻨﻔﯽ اﻓﺮاد اﯾﻦ ﺣﻮزه ﺑﻪ ﺳﯿﺴﺘﻢﻫﺎی ﻣﺘﻌﯿﻦ ﺑﻪﺗﺪرﯾﺞ اﻓﺰاﯾﺶ ﯾﺎﻓﺖ‪ ،‬ﺑﻪﮔﻮﻧﻪای ﮐﻪ ﺑﺮای ﺑﺮﺧﯽ‬
‫ﺿﺪﯾﺖ ﮐﺮدن ﺑﺎ ﺳﯿﺴﺘﻢﻫﺎی ﻣﺘﻌﯿﻦ ﺗﺒﺪﯾﻞ ﺑﻪ ﻫﻮﯾﺖ ﺷﺪ‪ .‬اﯾﻦ روﯾﮑﺮد ﮐﻢﮐﻢ ﭼﺎﺑﮑﯽ را ﺗﺒﺪﯾﻞ ﺑﻪ ﻓﺮﻗﻪ و ﻣﺬﻫﺒﯽ ﮐﺮد ﮐﻪ‬
‫ﭘﯿﺮواﻧﺶ ﭘﺬﯾﺮای ﻫﯿﭻ اﯾﺪه دﯾﮕﺮی ﻧﯿﺴﺘﻨﺪ و ﻫﻤﻮاره آﻣﺎده ﺟﻨﮓ ﺑﺎ »دﺷﻤﻨﺎن« ﺑﯿﺮوﻧﯽ‪ .‬ﻣﺎﻧﻨﺪ ﻫﻤﻪ ﺳﯿﺴﺘﻢﻫﺎی‬
‫دﮔﻤﺎﺗﯿﺴﺘﯽ‪ ،‬ﺧﻮدﺷﺎن ﻧﯿﺰ ﺑﻪ ﮔﺮوهﻫﺎی ﻓﺮاواﻧﯽ ﺗﻘﺴﯿﻢ ﻣﯽﺷﻮﻧﺪ و ﻫﺮﯾﮏ دﯾﮕﺮی را ﮐﺎﻓﺮ ﻣﯽداﻧﺪ‪.‬‬

‫ﻫﺮﮐﺪام از روشﻫﺎی ﻣﺘﻌﯿﻦ و ﺗﻄﺒﯿﻘﯽ ﺑﺮای ﻧﻮع وﯾﮋهای از ﻣﺤﺼﻮل ﻣﻨﺎﺳﺐ ﻫﺴﺘﻨﺪ و وﻗﺘﯽ ﺑﻪدرﺳﺘﯽ ﺑﻪ ﮐﺎر ﮔﺮﻓﺘﻪ‬
‫ﺷﻮﻧﺪ ﭘﺬﯾﺮﻓﺘﻨﯽاﻧﺪ‪ .‬ﭼﺎﺑﮏﮐﺎراﻧﯽ ﮐﻪ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﻫﻤﻪ ﭘﺮوژهﻫﺎ را ﻣﯽﺗﻮان ﭼﺎﺑﮏ اﺟﺮا ﮐﺮد ﯾﺎ ﻧﻤﯽداﻧﻨﺪ ﭼﺎﺑﮑﯽ ﭼﯿﺴﺖ‬
‫ﯾﺎ ﺗﺼﻮری از ﭘﺮوژهﻫﺎی ﻏﯿﺮﻧﺮماﻓﺰاری ﻧﺪارﻧﺪ‪ .‬ﮐﺴﺎﻧﯽ ﻫﻢ ﮐﻪ ﭼﺎﺑﮑﯽ را ﺑﻪﮐﻞ رد ﻣﯽﮐﻨﻨﺪ ﭼﺸﻤﺎن ﺧﻮد را ﺑﻪ روی‬
‫ﻓﺮﺻﺖﻫﺎی ﺑﺰرﮔﯽ ﻣﯽﺑﻨﺪﻧﺪ‪.‬‬

‫‪ .2.1.3.4‬روشﻫﺎی ﺗﺮﮐﯿﺒﯽ‬

‫— ‪— 61‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺴﯿﺎری از ﻣﻨﺎﺑﻊ اﻣﺮوزی درﺑﺎره روشﻫﺎی ﺗﺮﮐﯿﺒﯽ )‪ (hybrid‬ﺳﺨﻦ ﻣﯽﮔﻮﯾﻨﺪ؛ روشﻫﺎﯾﯽ ﮐﻪ از ﺗﺮﮐﯿﺐ روشﻫﺎی ﻣﺘﻌﯿﻦ‬
‫و ﭼﺎﺑﮏ ﺑﻪ وﺟﻮد ﻣﯽآﯾﺪ‪ .‬در ﻋﻤﻞ ﻧﻤﯽﺗﻮان ﭼﻨﯿﻦ ﺗﺮﮐﯿﺒﯽ داﺷﺖ‪ ،‬زﯾﺮا ﺑﺮای ﺗﻄﺒﯿﻘﯽ ﺑﻮدن در ﭘﺮوژه ﺑﺎﯾﺪ ﻫﻤﻪ ﻋﻨﺎﺻﺮ آن‬
‫ﺗﻄﺒﯿﻘﯽ ﺑﺎﺷﻨﺪ و ﻫﻤﯿﻦﮐﻪ ﺟﻨﺒﻪای از آن را ﺛﺎﺑﺖ و ﻣﺘﻌﯿﻦ ﮐﻨﯿﻢ‪ ،‬اﻧﻌﻄﺎفﭘﺬﯾﺮی و اﻧﻄﺒﺎقﭘﺬﯾﺮی ﻫﻤﻪ ﺑﺨﺶﻫﺎ از ﺑﯿﻦ‬
‫ﻣﯽروﻧﺪ‪ .‬اﮔﺮ ﺑﺘﻮان ﺑﺨﺸﯽ را ﻣﺘﻌﯿﻦ ﮐﺮد ﺑﺪون اﯾﻦﮐﻪ ﺗﻄﺒﯿﻖﭘﺬﯾﺮی ﺑﺨﺶﻫﺎی دﯾﮕﺮ را از ﺑﯿﻦ ﺑﺒﺮد‪ ،‬آن دو ﺑﺨﺶ‬
‫اﺳﺘﻘﻼل ﻣﻔﻬﻮﻣﯽ‪ ،‬ﻋﻤﻠﮑﺮدی و ﺗﻮﻟﯿﺪی ﮐﺎﻣﻞ دارﻧﺪ و درﻧﺘﯿﺠﻪ ﺑﺎ دو ﻣﺤﺼﻮل ﺳﺮوﮐﺎر دارﯾﻢ ﮐﻪ ﻧﯿﺎز ﺑﻪ دو ﭘﺮوژه ﻣﺨﺘﻠﻒ‬
‫دارﻧﺪ‪ ،‬و ﻫﯿﭻ ﻣﻨﻌﯽ ﺑﺮای اﺳﺘﻔﺎده از دو روش ﺳﺎﺧﺖ ﻣﺘﻔﺎوت در دو ﭘﺮوژه وﺟﻮد ﻧﺪارد‪ ،‬وﻟﯽ آن را ﻧﻤﯽﺗﻮان »روش‬
‫ﺗﺮﮐﯿﺒﯽ« داﻧﺴﺖ‪ .‬وﻗﺘﯽ ﺑﺎ ﯾﮏ ﭘﺮوژه و ﯾﮏ ﻣﺤﺼﻮل ﺳﺮوﮐﺎر دارﯾﻢ‪ ،‬روش ﺳﺎﺧﺖ ﯾﺎ ﻣﺘﻌﯿﻦ ﺧﻮاﻫﺪ ﺑﻮد‪ ،‬ﯾﺎ ﺗﻄﺒﯿﻘﯽ‪.‬‬

‫ﮐﺴﺎﻧﯽ ﮐﻪ از روشﻫﺎی ﺗﺮﮐﯿﺒﯽ ﺳﺨﻦ ﻣﯽﮔﻮﯾﻨﺪ ﻣﻌﻤﻮﻻ ﺗﻮﺟﻬﺸﺎن ﻣﻌﻄﻮف ﻇﻮاﻫﺮ اﺳﺖ و ﻫﺮﮔﺎه ﺗﺮﮐﯿﺒﯽ از ﺑﺮﭼﺴﺐﻫﺎ‪،‬‬
‫اﺳﻨﺎد‪ ،‬و ﻣﺮاﺳﻢ ﮐﻪ از دو روش آﻣﺪه ﺑﺎﺷﻨﺪ ﺑﯿﻨﻨﺪ‪ ،‬آن را روﺷﯽ ﺗﺮﮐﯿﺒﯽ ﻣﯽﻧﺎﻣﻨﺪ‪ .‬ﻣﺪﯾﺮ ﭘﺮوژه ﺧﺒﺮه ﻣﯽداﻧﺪ ﮐﻪ ﺗﻮﺟﻪ ﺑﻪ‬
‫ﻇﻮاﻫﺮ ﺑﺎرﭘﺮﺳﺘﯽ اﺳﺖ و ﺑﺎﯾﺪ ﺑﻪﺟﺎی آن ﺑﻪ ﻋﻤﻠﮑﺮدﻫﺎی واﻗﻌﯽ و ذات ﻣﺴﺎﯾﻞ ﺗﻮﺟﻪ داﺷﺖ‪.‬‬

‫ﻣﺘﺎﺳﻔﺎﻧﻪ ﭘﻢﺑﺎک ‪ ۷‬ﻧﯿﺰ ﭘﯿﺮوی ﺳﻮﺗﻔﺎﻫﻢ راﯾﺠﯽ ﮐﻪ در اﯾﻦ ﺑﺎره وﺟﻮد دارد درﺑﺎره روشﻫﺎی ﺗﺮﮐﯿﺒﯽ ﺳﺨﻦ ﻣﯽﮔﻮﯾﺪ‪.‬‬
‫ﮐﻮﺷﺶ ﻣﻦ ﺑﺮای ﻗﺎﻧﻊ ﮐﺮدن ﺗﯿﻢ و ﺣﺬف اﯾﻦ اﺷﺘﺒﺎه ﻧﯿﺰ ﺑﻪ ﺟﺎﯾﯽ ﻧﺮﺳﯿﺪ‪.‬‬

‫‪ .3 . 1 . 3 . 4‬ا ﻧ ﺘ ﺨ ﺎ ب ر و ش ﺳ ﺎ ﺧ ﺖ ﻣ ﺤ ﺼ ﻮ ل‬

‫روش ﻣﻨﺎﺳﺐ ﺑﺮای ﺳﺎﺧﺖ ﻫﺮ ﻣﺤﺼﻮل ﻓﻘﻂ ﺑﺴﺘﮕﯽ ﺑﻪ ﻧﻮع ﻣﺤﺼﻮل دارد و ﻧﻪ ﻣﺴﺎﯾﻞ دﯾﮕﺮی ﻣﺎﻧﻨﺪ ﺗﺮﺟﯿﺢ ﺗﯿﻢ‪ ،‬ﻣﺪﯾﺮ‬
‫ﭘﺮوژه‪ ،‬ﺳﺎزﻣﺎن‪ ،‬ﯾﺎ ﮐﺎرﻓﺮﻣﺎ‪.‬‬

‫آﯾﺎ ﻣﯽﺗﻮاﻧﯿﺪ ﻣﺤﺼﻮﻟﯽ ﮐﻪ ﭘﺎﺳﺨﮕﻮی ﻧﯿﺎزﻫﺎ و ﺧﻮاﺳﺘﻪﻫﺎ ﺑﺎﺷﺪ را ﭘﯿﺶﺑﯿﻨﯽ ﮐﻨﯿﺪ ﯾﺎ ﺑﺎ ﺧﻮاﺳﺘﻪﻫﺎﯾﯽ ﭘﯿﺶﺑﯿﻨﯽﻧﺎﭘﺬﯾﺮ‬
‫ﺳﺮوﮐﺎر دارﯾﺪ و ﻻزم اﺳﺖ ﮐﻪ آنﻫﺎ را ﺑﻪﺗﺪرﯾﺞ و ﺑﺎ ﻧﻤﺎﯾﺶ دادن ﻧﺴﺨﻪﻫﺎﯾﯽ ﻗﺎﺑﻞ اﺳﺘﻔﺎده از ﻣﺤﺼﻮل )‪(increment‬‬
‫ﮐﺸﻒ ﮐﻨﯿﺪ؟ آﯾﺎ اﺻﻼ اﻣﮑﺎن ﺳﺎﺧﺖ ﻧﺴﺨﻪﻫﺎی ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺤﺼﻮل ﺑﺮای ارزﯾﺎﺑﯽ ﺧﻮاﺳﺘﻪﻫﺎی ﺑﺎزار وﺟﻮد دارد؟‬

‫د ر ر و ش ﺗ ﻄ ﺒ ﯿ ﻘ ﯽ ﺑ ﺎ ﯾ ﺪ ﺑ ﺘ ﻮ ا ﻧ ﯿ ﻢ ﻧ ﺴ ﺨ ﻪ ﻫ ﺎ ی ﻣ ﺘ ﻌ ﺪ د ی ا ز ﻣ ﺤ ﺼ ﻮ ل ﺑ ﺴ ﺎ ز ﯾ ﻢ ‪ ،‬ﺑ ﻪ ﮔ ﻮ ﻧ ﻪ ا ی ﮐ ﻪ ﻫ ﺮ ﻧ ﺴ ﺨ ﻪ ﻗ ﺎ ﺑﻠ ﯿ ﺖ ﻫ ﺎ ی ﺑ ﯿ ﺸ ﺘ ﺮ ی‬
‫داﺷﺘﻪ ﺑﺎﺷﺪ و ﻫﻤﻮاره ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﺑﺎﺷﺪ زﯾﺮا ﻓﻘﻂ اﯾﻨﮕﻮﻧﻪ ﻣﯽﺗﻮان ﺑﺎزﺧﻮرد ﻣﻨﺎﺳﺐ از ﻣﺤﯿﻂ درﯾﺎﻓﺖ ﮐﺮد‪ .‬ﺑﺎ‬
‫ﺑﻬﺮهﻣﻨﺪی از ﺑﺎزﺧﻮرد ﻫﺮ ﻧﺴﺨﻪ‪ ،‬ﺣﺪس ﻣﯿﺰﻧﯿﻢ ﮐﻪ ﺑﻬﺘﺮﯾﻦ ﮐﺎری ﮐﻪ در ﻧﺴﺨﻪ ﺑﻌﺪ ﻣﯽﺗﻮان اﻧﺠﺎم داد ﭼﯿﺴﺖ و ﺑﺮ آن‬
‫ﭘﺎﯾﻪ ﺟﻠﻮ ﻣﯽروﯾﻢ‪ .‬ﻓﺮاﻣﻮش ﻧﮑﻨﯿﺪ ﮐﻪ ﻫﺪف اﺻﻠﯽ از ﮔﺮدآوری ﺑﺎزﺧﻮرد در ﺳﯿﺴﺘﻢﻫﺎی ﻣﺘﻌﯿﻦ ﮐﺸﻒ ﻣﺴﯿﺮ ﻣﻨﺎﺳﺐ‬
‫ﺑﺮای آﯾﻨﺪه اﺳﺖ و ﻧﻪ اﺻﻼح ﮔﺬﺷﺘﻪ‪ .‬اﺻﻼح ﮔﺬﺷﺘﻪ ﺑﺮ ﭘﺎﯾﻪ ﺑﺎزﺧﻮرد در ﻫﻤﻪ ﭘﺮوژهﻫﺎ وﺟﻮد دارد و ﺑﻪ ﻣﻌﻨﯽ ﺗﻄﺒﯿﻘﯽ‬
‫ﺑ ﻮ د ن ﻧ ﯿ ﺴ ﺖ‪.‬‬

‫ﺑﺮای اﯾﻦﮐﻪ ﺑﺘﻮان ﺑﻪ ﺗﺮﺗﯿﺐ ﮔﻔﺘﻪ ﺷﺪه ﺟﻠﻮ رﻓﺖ‪ ،‬ﺑﺎﯾﺪ در ﻫﺮ ﻧﺴﺨﻪ ﺑﺮ زﯾﺮﻣﺠﻤﻮﻋﻪای از وﯾﮋﮔﯽﻫﺎی ﺗﺎزه ﺗﻤﺮﮐﺰ ﮐﻨﯿﻢ و‬
‫آن اﺟﺰا را ﺟﺪا از ﺳﺎﯾﺮ اﺟﺰا ﺗﻌﺮﯾﻒ‪ ،‬ﻃﺮاﺣﯽ‪ ،‬و ﺗﻮﻟﯿﺪ ﮐﺮده‪ ،‬ﺑﺎ ﺧﺮوﺟﯽﻫﺎی ﭘﯿﺸﯿﻦ ﺗﺮﮐﯿﺐ ﮐﻨﯿﻢ‪ .‬اﮔﺮ ﻓﺮآﯾﻨﺪﻫﺎی ﺗﻮﺳﻌﻪ‬
‫)ﺗﻌﺮﯾﻒ‪ ،‬ﻃﺮاﺣﯽ‪ (… ،‬را ﻧﺘﻮاﻧﯿﻢ از ﻫﻢ ﺟﺪا ﮐﻨﯿﻢ‪ ،‬اﺟﺰای ﺳﺎزﻧﺪه ﭘﺮوژه آزادی ﮐﺎﻣﻞ ﻧﺨﻮاﻫﺪ داﺷﺖ و ﺳﻄﺤﯽ از‬
‫اﻧﻌﻄﺎفﭘﺬﯾﺮی ﮐﻪ ﺑﺮای ﭼﺎﺑﮑﯽ ﻻزم اﺳﺖ ﻓﺮاﻫﻢ ﻧﺨﻮاﻫﺪ ﺷﺪ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺳﺎﺧﺘﻤﺎﻧﯽ را ﻓﺮض ﮐﻨﯿﺪ‪ :‬ﻓﻮﻧﺪاﺳﯿﻮن آن را ﻧﻤﯽﺗﻮان ﺟﺪا از ﺳﺎﯾﺮ ﻋﻨﺎﺻﺮ ﻃﺮاﺣﯽ ﮐﺮد و ﺳﺎﺧﺖ‪ ،‬زﯾﺮا ﺑﺮای‬
‫ﻃﺮاﺣﯽ ﻓﻮﻧﺪاﺳﯿﻮن ﺑﺎﯾﺪ ﺑﺎری ﮐﻪ ﺑﺮ آن وارد ﻣﯽﺷﻮد را داﻧﺴﺖ و ﺗﻨﻬﺎ راه ﺑﺮای داﻧﺴﺘﻦ آن اﯾﻦ اﺳﺖ ﮐﻪ ﮐﻞ ﺳﺎﺧﺘﻤﺎن‬
‫ﻃﺮاﺣﯽ ﺷﻮد‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬درﺟﻪای از آزادی ﮐﻪ ﺑﺮای ﭼﺎﺑﮑﯽ ﻻزم اﺳﺖ در ﭘﺮوژهﻫﺎی ﺳﺎﺧﺘﻤﺎﻧﯽ وﺟﻮد ﻧﺪارد‪.‬‬

‫— ‪— 62‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬در ﭘﺮوژهﻫﺎی ﺳﺎﺧﺘﻤﺎﻧﯽ ﻧﻤﯽﺗﻮان ﻧﺴﺨﻪﻫﺎﯾﯽ ﻧﺨﺴﺘﯿﻦ از ﻣﺤﺼﻮل آﻣﺎده ﮐﺮد ﮐﻪ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﺑﺎﺷﻨﺪ‬
‫ﺗﺎ ﺑﺮ ﭘﺎﯾﻪ آنﻫﺎ ﺑﺎزﺧﻮرد واﻗﻌﯽ درﯾﺎﻓﺖ ﮐﺮد؛ ﺳﺎﺧﺘﻤﺎن ﻓﻘﻂ زﻣﺎﻧﯽ ﻗﺎﺑﻞ اﺳﺘﻔﺎده اﺳﺖ ﮐﻪ ﮐﺎﻣﻞ ﺷﺪه ﺑﺎﺷﺪ‪ .‬از اﯾﻦ رو‪،‬‬
‫ﺣﺘﯽ اﮔﺮ آزادی ﻋﻤﻞ در ﭼﻨﯿﻦ ﻣﺤﺼﻮﻟﯽ وﺟﻮد ﻣﯽداﺷﺖ‪ ،‬ﺑﺎز ﻫﻢ اﻣﮑﺎن ﭼﺎﺑﮏ اﺟﺮا ﮐﺮدﻧﺶ ﻓﺮاﻫﻢ ﻧﻤﯽﺷﺪ‪.‬‬

‫اﮔﺮ ﺑﺮآﻧﯿﺪ ﮐﻪ ﻧﺮماﻓﺰاری ﺑﺮای ﮐﺎرﺑﺮد ﻫﻤﮕﺎن ﺑﺴﺎزﯾﺪ‪ ،‬ﭘﯿﺶﺑﯿﻨﯽ ﭘﺬﯾﺮش ﻫﻤﮕﺎﻧﯽاش ﻣﮑﺎنﭘﺬﯾﺮ ﻧﺨﻮاﻫﺪ ﺑﻮد‪ .‬اﺟﺰای‬
‫ﺳﺎزﻧﺪه ﻧﺮماﻓﺰار را ﺑﺮﺧﻼف ﺳﺎﺧﺘﻤﺎن ﻣﯽﺗﻮان ﻣﺴﺘﻘﻞ از ﻫﻢ ﺳﺎﺧﺖ و ﻧﺴﺨﻪﻫﺎﯾﯽ ﻧﺨﺴﺘﯿﻦ از ﻧﺮماﻓﺰار ﺳﺎﺧﺖ ﮐﻪ‬
‫ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﺑﺎﺷﻨﺪ‪ .‬اﯾﻦ ﻧﺴﺨﻪﻫﺎ را ﻣﯽﺗﻮان ﺑﻪ ﮐﺎرﺑﺮان ﻣﺤﺪودی ﻧﺸﺎن داد و ﺑﺮ ﭘﺎﯾﻪ ﻧﻮع اﺳﺘﻔﺎده و ﻧﻈﺮ آنﻫﺎ‬
‫ﺣﺪس زد ﮐﻪ ﮔﺎم ﺑﻌﺪی ﭼﻪ ﺑﺎﺷﺪ و ﺑﺮ آن ﭘﺎﯾﻪ ﭘﯿﺶ رﻓﺖ‪ .‬ﭼﻨﯿﻦ روﺷﯽ ﺑﺮای اﯾﻦ ﻧﻮع ﭘﺮوژه ﺑﻬﺘﺮﯾﻦ ﻧﺘﯿﺠﻪ را ﻣﯽدﻫﺪ و‬
‫رﯾﺴﮏﻫﺎﯾﯽ ﮐﻪ ﺑﺮآﻣﺪه از ﭘﯿﭽﯿﺪﮔﯽ ﭘﯿﺶﺑﯿﻨﯽ رﻓﺘﺎر اﻧﺴﺎﻧﯿﺴﺖ را ﺣﺪاﻗﻞ ﻣﯽﮐﻨﺪ‪.‬‬

‫ﻫﺮ ﭘﺮوژه ﻧﺮماﻓﺰاریای ﻧﯿﺰ ﻧﺒﺎﯾﺪ ﺗﻄﺒﯿﻘﯽ اﻧﺠﺎم ﺷﻮد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﻗﺮار اﺳﺖ ﺳﯿﺴﺘﻢﻋﺎﻣﻞ و ﺑﺮﺧﯽ دﯾﮕﺮ از‬
‫ﻧﺮماﻓﺰارﻫﺎی ﯾﮏ دﯾﺘﺎﺳﻨﺘﺮ را ﺗﻐﯿﯿﺮ دﻫﯿﺪ‪ ،‬ﺧﺒﺮی از ﭘﯿﭽﯿﺪﮔﯽﻫﺎی رﻓﺘﺎر اﻧﺴﺎﻧﯽ ﻧﺨﻮاﻫﺪ ﺑﻮد و ﺑﻬﺘﺮ اﺳﺖ آن را ﻣﺘﻌﯿﻦ‬
‫اﺟﺮا ﮐﻨﯿﺪ‪ .‬اﮔﺮ ﻗﺮار اﺳﺖ ﻧﺮماﻓﺰاری ﺑﺮای دﺳﺘﮕﺎﻫﯽ ﺑﯿﻤﺎرﺳﺘﺎﻧﯽ ﯾﺎ ﻧﻮﻋﯽ ﻫﻮاﭘﯿﻤﺎ ﺑﺴﺎزﯾﺪ‪ ،‬ﻫﻢ ﭘﯿﭽﯿﺪﮔﯽﻫﺎی ﮔﻔﺘﻪ ﺷﺪه‬
‫وﺟﻮد ﻧﺪارﻧﺪ و ﻫﻢ اﻣﮑﺎﻧﯽ ﺑﺮای آزﻣﺎﯾﺶ و ﺧﻄﺎ ﻧﺪارﯾﺪ‪ ،‬زﯾﺮا ﺑﺎ ﺟﺎن اﻧﺴﺎنﻫﺎ ﺳﺮوﮐﺎر دارﯾﺪ؛ از آنرو‪ ،‬ﻻزم اﺳﺖ ﮐﻪ‬
‫ﻣﺤﺼﻮل را ﺑﻪ ﺷﯿﻮه ﻣﺘﻌﯿﻦ و ﺑﺎ ﺗﯿﺰﺑﯿﻨﯽ و وﺳﻮاس ﻓﺮاوان اﺟﺮا ﮐﻨﯿﺪ‪.‬‬

‫ﺑﺮای ﭘﺮﻫﯿﺰ از اﺷﺘﺒﺎهﻫﺎی راﯾﺞ در اﯾﻦ ﺣﻮزه ﺑﻪ اﯾﻦ ﻣﻮارد ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪:‬‬

‫ﭼﺎﺑﮑﯽ ﺑﻪ ﻣﻌﻨﯽ ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺗﻄﺒﯿﻘﯽ اﺳﺖ و ﻧﻪ ﺑﻪﮐﺎر ﺑﺮدن ﺑﺮﭼﺴﺐﻫﺎ و ﻣﺮاﺳﻢ وﯾﮋه‪.‬‬
‫ﻫ ﺮ ﻧ ﺴ ﺨ ﻪ ﻗ ﺎ ﺑ ﻞ ا ﺳﺘ ﻔ ﺎ د ها ی ا ز ﻣ ﺤ ﺼ ﻮ ل ﻣ ﺠ ﻤ ﻮ ﻋ ﻪا ی ا ز ﺗ ﺤ ﻮ ﯾ ﻞ ﺷ ﺪ ﻧ ﯽ ﻫ ﺎ ﺳ ﺖ ‪ ،‬وﻟ ﯽ ﻫ ﺮ ﻣ ﺠ ﻤ ﻮ ﻋ ﻪا ی ا ز‬
‫ﺗ ﺤ ﻮ ﯾ ﻞ ﺷ ﺪ ﻧ ﯽ ﻫ ﺎ ﻧ ﺴ ﺨ ﻪ ا ی ﻗ ﺎ ﺑ ﻞ ا ﺳ ﺘ ﻔ ﺎ د ه ا ز ﻣ ﺤ ﺼ ﻮ ل ﻧ ﯿ ﺴ ﺖ‪.‬‬
‫ﻫﺪف اﺻﻠﯽ از ﮔﺮدآوری ﺑﺎزﺧﻮرد در روشﻫﺎی ﻣﺘﻌﯿﻦ ﺷﻨﺎﺳﺎﯾﯽ ﻣﺴﯿﺮ ﭘﯿﺶروﺳﺖ و ﻧﻪ اﺻﻼح آﻧﭽﻪ ﭘﯿﺸﺘﺮ‬
‫ا ﻧ ﺠ ﺎ م ﺷ ﺪ ه ا ﺳ ﺖ‪.‬‬

‫د ر ﭘﺎﯾﺎ ن ‪ ،‬ﺑ ﻪ اﯾ ﻦ ﻣ ﻮ ﺿ ﻮ ع ﻫ ﻢ ﺗ ﻮ ﺟ ﻪ دا ﺷﺘ ﻪ ﺑﺎ ﺷﯿ ﺪ ﮐ ﻪ ﻣﻨ ﻈ ﻮ ر ا ز ر و ش ﺳﺎ ﺧ ﺖ ﻣ ﺤ ﺼ ﻮ ل ﺗ ﻄﺒﯿ ﻘ ﯽ ‪ ،‬ر و ش ﺳﺎ ﺧﺘﯿ ﺴ ﺖ ﮐ ﻪ‬

‫درون ﯾﮏ ﭘﺮوژه و ﺑﺮای ﯾﮏ ﻣﺤﺼﻮل ﺑﻪ ﮐﺎر ﻣﯽرود‪ .‬اﮔﺮ ﯾﮏ ﭘﺮوژهای را اﺟﺮا ﮐﻨﯿﺪ و ﺑﺮ ﭘﺎﯾﻪ آﻣﻮﺧﺘﻪﻫﺎﯾﺘﺎن ﭘﺮوژه ﺑﻌﺪی را‬
‫ﺑﻬﺘﺮ اﺟﺮا ﮐﻨﯿﺪ‪ ،‬ﻧﻮﻋﯽ از اﻧﻄﺒﺎق وﺟﻮد دارد‪ ،‬وﻟﯽ اﯾﻦ اﻧﻄﺒﺎق ﻣﻔﻬﻮم دﯾﮕﺮﯾﺴﺖ ﮐﻪ ارﺗﺒﺎط ﻣﺴﺘﻘﯿﻤﯽ ﺑﺎ اﻧﻄﺒﺎق ﻣﺪﻧﻈﺮ‬
‫در روشﻫﺎی ﺗﻄﺒﯿﻘﯽ ﻧﺪارد‪.‬‬

‫‪ .2.3.4‬ﭼﺮﺧﻪ ﺣﯿﺎت ﭘﺮوژه‬

‫ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﮐﻤﺎﺑﯿﺶ ﺑﺮ ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺛﺮ ﻣﯽﮔﺬارد‪ .‬ﺑﺮﺧﯽ ﻣﺘﺪوﻟﻮژیﻫﺎ‪ ،‬ﻣﺎﻧﻨﺪ ‪،P3.express‬‬
‫ﺑﻪﮔﻮﻧﻪای ﻃﺮاﺣﯽ ﺷﺪهاﻧﺪ ﮐﻪ ﺑﺎ ﻫﺮ دو روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺳﺎزﮔﺎر ﺑﺎﺷﻨﺪ‪ ،‬وﻟﯽ ﺑﺮﺧﯽ‪ ،‬ﻣﺎﻧﻨﺪ ‪ ،DSDM‬ﻓﻘﻂ از ﯾﮑﯽ از‬
‫اﯾﻦ دو روش ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﭘﺸﺘﯿﺒﺎﻧﯽ ﻣﯽﮐﻨﻨﺪ‪ .‬درﻧﺘﯿﺠﻪ‪ ،‬در زﻣﺎن اﻧﺘﺨﺎب ﻣﺘﺪﻟﻮژی ﺑﺎﯾﺪ ﺑﻪ ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬
‫ﻧ ﯿ ﺰ ﺗ ﻮ ﺟ ﻪ ﮐ ﻨ ﯿ ﺪ‪.‬‬

‫ﻣﻮارد ﻣﺘﻌﺪدی در ﺳﺎزﮔﺎری ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه و ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل اﺛﺮ دارﻧﺪ و ﺑﺮرﺳﯽ آنﻫﺎ ﻓﺮاﺗﺮ از ﻫﺪف‬
‫اﯾﻦ ﮐﺘﺎب اﺳﺖ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژهای ﮐﻪ ﺧﻄﯽ ﺑﺎﺷﻨﺪ را ﻓﻘﻂ ﺑﺮای ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﻣﺘﻌﯿﻦ ﮐﻪ‬

‫— ‪— 63‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺧﻄﯽ اﺳﺖ ﻣﯽﺗﻮان ﺑﻪﮐﺎر ﺑﺮد‪ ،‬وﻟﯽ ﻣﺘﺪوﻟﻮژیﻫﺎﯾﯽ ﮐﻪ ﭼﺮﺧﻪای ﺑﺎﺷﻨﺪ را ﻫﻢ ﻣﯽﺗﻮان ﺑﺮای ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﻣﺘﻌﯿﻦ‬
‫اﺳﺘﻔﺎده ﮐﺮد و ﻫﻢ ﺗﻄﺒﯿﻘﯽ‪.‬‬

‫‪ .3.3.4‬ﭼﺮﺧﻪ ﺣﯿﺎت ﻣﺤﺼﻮل‬

‫ﻫﺮ ﭘﺮوژه ﻣﺤﺼﻮﻟﯽ را ﻣﯽآﻓﺮﯾﻨﺪ ﯾﺎ ﻣﺤﺼﻮﻟﯽ ﮐﻪ وﺟﻮد دارد ﺑﺎ ﺗﻐﯿﯿﺮ ﻣﯽدﻫﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﭼﺮﺧﻪ ﺣﯿﺎت ﭘﺮوژه‬
‫زﯾﺮﻣﺠﻤﻮﻋﻪای از ﭼﺮﺧﻪ ﺣﯿﺎت ﻣﺤﺼﻮل ﺧﻮاﻫﺪ ﺑﻮد‪ .‬ﺧﻮب اﺳﺖ ﮐﻪ در ﭘﺮوژه ﺑﻪ ﭼﺮﺧﻪ ﺣﯿﺎت ﻣﺤﺼﻮل ﻫﻢ ﺗﻮﺟﻪ‬
‫داﺷﺖ؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺷﺎﯾﺪ ﺑﺎ ﺻﺮف ﻣﻌﺎدل ‪ ۵۰‬ﻫﺰار ﭘﯿﺘﺰا ﻫﺰﯾﻨﻪ ﺑﺘﻮاﻧﯿﺪ ﮐﺎری ﮐﻨﯿﺪ ﮐﻪ ﻫﺰﯾﻨﻪ اﺳﺘﻔﺎده از ﻣﺤﺼﻮل ﭘﺮوژه‬
‫در زﻣﺎن ﺑﻬﺮهﺑﺮداری ﻣﻌﺎدل ‪ ۲‬ﻫﺰار ﭘﯿﺘﺰا در ﻣﺎه ﮐﺎﻫﺶ ﯾﺎﺑﺪ‪ .‬آﯾﺎ اﯾﻦ ﮐﺎر ﻓﮑﺮ ﺧﻮﺑﯿﺴﺖ؟‬

‫ﺗﺼﻤﯿﻢﮔﯿﺮی درﺑﺎره ﭼﻨﯿﻦ ﻣﺴﺎﯾﻠﯽ ﻓﺮاﺗﺮ از ﻣﺮزﻫﺎی ﭘﺮوژه ﻣﯽرود و ﺑﺎﯾﺪ در ﺳﻄﻮح ﻣﺪﯾﺮﯾﺘﯽ ﻣﻨﺎﺳﺐ ﺑﺎ دﯾﺪ ﮐﻼن و‬
‫ﻫﻤﻪﺟﺎﻧﺒﻪ اﻧﺠﺎم ﺷﻮد‪ .‬آﻧﭽﻪ از ﻻﯾﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﻧﺘﻈﺎر دارﯾﻢ‪ ،‬ﺷﻨﺎﺳﺎﯾﯽ ﭼﻨﯿﻦ ﻓﺮﺻﺖﻫﺎﯾﯽ و ﮔﺰارش دادن آنﻫﺎ ﺑﻪ‬
‫ﻻﯾﻪﻫﺎی ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪه اﺳﺖ‪.‬‬

‫‪ .4.4‬ﺑﺮﻧﺎﻣﻪرﯾﺰی‬

‫ﻗﺮار ﺑﻮد ﺑﻪ ﺟﻠﺴﻪای ﺑﺮوﯾﻢ و دﯾﺮ ﺷﺪه ﺑﻮد‪ .‬وﻗﺘﯽ ﺳﻮار ﻣﺎﺷﯿﻦ ﺷﺪﯾﻢ‪ ،‬ﻣﺸﻐﻮل ﺗﻨﻈﯿﻢ ‪ GPS‬ﺑﻮدم ﮐﻪ ﻫﻤﮑﺎرم ﮔﻔﺖ‬
‫»زود ﺑﺎش‪ ،‬دﯾﺮ ﺷﺪه‪ ،‬وﻗﺖ ﻧﺪارﯾﻢ«‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬از اﯾﻦ رو ﻣﺸﻐﻮل ﺗﻨﻈﯿﻢ ‪ GPS‬ﺑﻮدم ﮐﻪ دﯾﺮ ﺷﺪه ﺑﻮد و وﻗﺖ‬
‫ﻧﺪاﺷﺘﯿﻢ‪ .‬ﺑﻪ ﮐﻤﮏ ‪ GPS‬ﻣﯽﺗﻮاﻧﺴﺘﯿﻢ از ﻣﺴﯿﺮﻫﺎﯾﯽ ﮐﻪ ﺗﺮاﻓﯿﮏ ﺳﻨﮕﯿﻦ ﻣﻮردی دارﻧﺪ دوری ﮐﻨﯿﻢ و ﺳﺮﯾﻊﺗﺮ ﺑﻪ ﻣﻘﺼﺪ‬
‫ﺑﺮﺳﯿﻢ‪.‬‬

‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻫﻢ اﯾﻦﭼﻨﯿﻦ اﺳﺖ‪ .‬ﮐﻤﺒﻮد وﻗﺖ دﻟﯿﻠﯽ ﺑﺮای ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻧﮑﺮدن ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ دﻟﯿﻠﯽ ﺑﺮای ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺮدن‬
‫ا ﺳ ﺖ‪.‬‬

‫‪ .1.4.4‬ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺑﺴﺘﻪ ﺑﻪ ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل‬

‫ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﻧﯿﺎز ﺑﻪ ﺑﺮﻧﺎﻣﻪرﯾﺰی دارﻧﺪ‪ .‬ﺑﺮﺧﯽ ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﻧﯿﺎز ﺑﻪ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻧﺪارﻧﺪ‪ ،‬وﻟﯽ اﯾﻦﭼﻨﯿﻦ‬
‫ﻧﯿﺴﺖ؛ ﻓﻘﻂ ﺑﺮﻧﺎﻣﻪرﯾﺰی آنﻫﺎ ﺑﺎ ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﻣﺘﻔﺎوت اﺳﺖ‪:‬‬

‫ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﺑﺮﻧﺎﻣﻪﻫﺎی ﺗﻔﺼﯿﻠﯽ ﯾﺎ ﮐﻼن ﻧﺨﺴﺘﯿﻦ دارﻧﺪ‪ .‬اﮔﺮ ﺑﺮﻧﺎﻣﻪ ﻧﺨﺴﺘﯿﻦ ﺗﻔﺼﯿﻠﯽ ﻧﺒﺎﺷﺪ‪ ،‬ﻣﻌﻤﻮﻻ‬
‫دورهای )ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻣﺎﻫﺎﻧﻪ( ﺗﻔﺼﯿﻠﯽ ﻣﯽﺷﻮد‪.‬‬
‫ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﺑﺎ ﺑﺮﻧﺎﻣﻪای ﮐﻼن آﻏﺎز ﻣﯽﺷﻮﻧﺪ‪ .‬ﺷﺎﯾﺪ ﺑﺮﻧﺎﻣﻪ ﻫﺮ دوره ﮐﻤﯽ ﺗﻔﺼﯿﻠﯽﺗﺮ ﺷﻮد‪ ،‬وﻟﯽ ﻓﻘﻂ ﭘﯿﺶ‬
‫از اﺟﺮای ﻫﺮ ﺟﺰ اﺳﺖ ﮐﻪ ﺑﺮﻧﺎﻣﻪاش ﮐﺎﻣﻞ ﺗﻔﺼﯿﻠﯽ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫ﻫﻤﻪ ﮐﺎرﻫﺎﯾﻤﺎن ﺑﺎﯾﺪ ﻫﺪﻓﻤﻨﺪ ﺑﺎﺷﻨﺪ‪ .‬ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺑﺎ دو ﻫﺪف ﮐﻠﯽ اﻧﺠﺎم ﻣﯽﺷﻮد‪:‬‬

‫ﻫﺪاﯾﺖ ﭘﺮوژه‬
‫ارزﯾﺎﺑﯽ وﺿﻌﯿﺖ ﭘﺮوژه‬

‫— ‪— 64‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﭼﮕﻮﻧﮕﯽ ﻫﺪاﯾﺖ ﭘﺮوژه ﺑﻪ ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل ﺑﺴﺘﮕﯽ دارد و ارزﯾﺎﺑﯽ وﺿﻌﯿﺖ ﭘﺮوژه ﺑﻪ ﻣﺘﺪوﻟﻮژی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪.‬‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻣﻔﻬﻮﻣﯽ ﻣﺴﺘﻘﻞ ﻧﯿﺴﺖ و ﻧﻤﯽﺗﻮان درﺑﺎره ﮐﯿﻔﯿﺖ ﺑﺮﻧﺎﻣﻪ ﻣﺴﺘﻘﻞ از ﺷﯿﻮه ﺳﺎﺧﺖ ﻣﺤﺼﻮل و ﻣﺘﺪوﻟﻮژی‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻗﻀﺎوت ﮐﺮد‪ .‬ﺷﺎﯾﺪ ﺑﺮﻧﺎﻣﻪای ﺑﺮای ﯾﮏ ﺑﺴﺘﺮ ﻣﻨﺎﺳﺐ و ﺑﺮای ﺑﺴﺘﺮی دﯾﮕﺮ ﻧﺎﻣﻨﺎﺳﺐ ﺑﺎﺷﺪ‪.‬‬

‫‪ .2.4.4‬ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻣﺴﺘﻤﺮ‬

‫ﻣﺴﺘﻘﻞ از اﯾﻦﮐﻪ از ﭼﻪ روﺷﯽ ﺑﺮای ﺳﺎﺧﺖ ﻣﺤﺼﻮل اﺳﺘﻔﺎده ﻣﯽﮐﻨﯿﺪ‪ ،‬ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺑﺎﯾﺪ ﻣﺴﺘﻤﺮ ﺑﺎﺷﺪ‪ .‬ﺑﺮﺧﯽ ﮔﻤﺎن‬
‫ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﻣﯽﺗﻮان در آﻏﺎز ﭘﺮوژه ﺑﺮﻧﺎﻣﻪای آﻣﺎده ﮐﺮد‪ ،‬ﻧﺴﺨﻪای از آن را ﭼﺎپ و ﺑﺮ دﯾﻮار ﻧﺼﺐ ﮐﺮد و ﺗﺎ ﭘﺎﯾﺎن ﭘﺮوژه‬
‫دﺳﺖ از ﮐﺎر ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺸﯿﺪ‪ .‬ﺑﺮﻧﺎﻣﻪای ﮐﻪ داﯾﻤﺎ ﺑﺎزﺑﯿﻨﯽ ﻧﺸﻮد ﺑﻪﺳﺮﻋﺖ ﮐﺎرﺑﺮد ﺧﻮد را از دﺳﺖ ﻣﯽدﻫﺪ‪ ،‬زﯾﺮا ﺑﺎ‬
‫اﯾﻦﮐﻪ اﺟﺮا ﺑﺮ ﭘﺎﯾﻪ ﺑﺮﻧﺎﻣﻪ ﻗﺮار اﺳﺖ اﻧﺠﺎم ﺷﻮد‪ ،‬ﻋﺪمﻗﻄﻌﯿﺖﻫﺎی اﺟﺮاﯾﯽ ﻫﻤﯿﺸﻪ ﺗﻔﺎوتﻫﺎﯾﯽ ﺑﻪ وﺟﻮد ﻣﯽآورﻧﺪ‪ .‬اﯾﻦ‬
‫ﺗﻔﺎوتﻫﺎ را ﺑﺎﯾﺪ در ﺑﺮﻧﺎﻣﻪ ﺑﺎزﺗﺎب داده‪ ،‬آن را ﺑﺎزﺑﯿﻨﯽ ﮐﺮد‪.‬‬

‫‪ .3.4.4‬ﻣﺤﺘﻮای ﺑﺮﻧﺎﻣﻪﻫﺎ‬

‫ﻫﺮ ﻣﺘﺪوﻟﻮژی زﻣﺎن ﻣﻨﺎﺳﺐ و روﻧﺪ ﺑﺮﻧﺎﻣﻪرﯾﺰی را ﺗﻮﺿﯿﺢ ﻣﯽدﻫﺪ‪ ،‬وﻟﯽ ﮔﺎﻫﯽ ﻣﺤﺘﻮای ﺑﺮﻧﺎﻣﻪﻫﺎﯾﺸﺎن ﭼﻨﺪان روﺷﻦ‬
‫ﻧ ﯿ ﺴ ﺖ‪.‬‬

‫ﻧﺴﺨﻪﻫﺎی ﭘﯿﺸﯿﻦ ﭘﻢﺑﺎک ﻣﺠﻤﻮﻋﻪای از ﺣﻮزهﻫﺎی داﻧﺶ داﺷﺘﻨﺪ ﮐﻪ از ﺑﺮﺧﯽ ﺟﻬﺎت ﻣﺎﻧﻨﺪ ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﻧﺴﺨﻪ‬
‫ﻫﻔﺘﻢ )ﻣﻮﺿﻮع اﯾﻦ ﻓﺼﻞ( ﺑﻮدﻧﺪ‪ ،‬وﻟﯽ ﯾﮑﺴﺎن ﻧﯿﺴﺘﻨﺪ‪ .‬ﺑﻪ ﻧﻈﺮ ﻣﻦ ﺣﻮزهﻫﺎی داﻧﺶ دﺳﺘﻪﺑﻨﺪی ﺑﺴﯿﺎر ﺧﻮﺑﯽ ﺑﺮای ﺷﺮح‬
‫آﻧﭽﻪ ﻗﺮار اﺳﺖ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺷﻮد ﻫﺴﺘﻨﺪ‪:‬‬

‫ﯾ ﮑﭙﺎ ر ﭼ ﮕ ﯽ‬
‫ﮔﺴﺘﺮه‬
‫زﻣﺎن‬
‫ﻫ ﺰﯾﻨ ﻪ‬
‫ﮐﯿ ﻔﯿ ﺖ‬
‫ﻣﻨﺎﺑ ﻊ‬
‫ارﺗﺒﺎﻃﺎت‬
‫رﯾ ﺴ ﮏ‬
‫ﺗﺪارﮐﺎت‬
‫ذ یﻧ ﻔ ﻌﺎ ن‬

‫اﯾﻦ دﺳﺘﻪﺑﻨﺪی ﯾﮑﯽ از اﻧﻮاع دﺳﺘﻪﺑﻨﺪی اﺳﺖ ﮐﻪ ﻣﯽﺗﻮاﻧﯿﺪ در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ .‬ﻫﻤﻪ اﯾﻦ ﻣﻮارد ﺑﺎﯾﺪ ﺑﻪﻧﻮﻋﯽ در‬
‫ﺑﺮﻧﺎﻣﻪﻫﺎﯾﺘﺎن وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻣﺘﺪوﻟﻮژﯾﺘﺎن اﺣﺘﻤﺎﻻ ﻫﻤﮕﯽ را ﭘﻮﺷﺶ دﻫﺪ‪ ،‬وﻟﯽ ﺷﺎﯾﺪ ﺑﺮﺧﯽ از اﯾﻦ ﺟﻨﺒﻪﻫﺎی‬
‫ﭘﺮوژهﺗﺎن ﺣﺴﺎسﺗﺮ ﺑﺎﺷﻨﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﻧﯿﺎز ﺑﺎﺷﺪ ﮐﻪ آنﻫﺎ را ﺑﺴﺘﻪ ﺑﻪ ﭘﯿﺶﻓﺮﺿﯽ ﮐﻪ در ﻣﺘﺪﻟﻮژی وﺟﻮد دارد ﻗﻮیﺗﺮ‬
‫ﮐ ﻨ ﯿ ﺪ‪.‬‬

‫ﻓﺮاﻣﻮش ﻧﮑﻨﯿﺪ ﮐﻪ ﺑﺮﻧﺎﻣﻪ زﻣﺎنﺑﻨﺪی ﻓﻘﻂ ﯾﮑﯽ از اﯾﻦ ‪ ۱۲‬ﻣﻮرد اﺳﺖ‪.‬‬

‫— ‪— 65‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ .4.4.4‬اﻧﻮاع زﻣﺎنﺑﻨﺪی‬

‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺑﺎﯾﺪ ﮔﺴﺘﺮه‪ ،‬زﻣﺎن‪ ،‬ﻫﺰﯾﻨﻪ‪ ،‬ﮐﯿﻔﯿﺖ‪ ،‬ﻣﻨﺎﺑﻊ‪ ،‬رﯾﺴﮏ و ﺳﺎﯾﺮ ﺣﻮزهﻫﺎ را ﭘﻮﺷﺶ دﻫﺪ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬زﻣﺎنﺑﻨﺪی‬
‫ﯾﮑﯽ از ﻋﻨﺎﺻﺮ ﻣﻬﻢ و ﻣﺮﮐﺰی در ﺑﺮﻧﺎﻣﻪرﯾﺰﯾﺴﺖ و ﻣﻌﻤﻮﻻ ﻣﻮردی ﮐﻪ ﭼﺎﻟﺶﻫﺎی وﯾﮋه ﺧﻮد را دارد و از اﯾﻦرو ﺑﯿﺸﺘﺮ از‬
‫دﯾﮕﺮ ﺣﻮزهﻫﺎ ﺑﻪ آن ﭘﺮداﺧﺘﻪ ﺷﺪه اﺳﺖ‪.‬‬

‫زﻣﺎنﺑﻨﺪی ﺑﻪ ﻣﻌﻨﯽ ﺗﺨﺼﯿﺺ زﻣﺎن آﻏﺎز و ﭘﺎﯾﺎن ﯾﺎ ﺗﺮﺗﯿﺐ اﺟﺮا ﺑﻪ ﻓﻌﺎﻟﯿﺖﻫﺎی ﭘﺮوژه اﺳﺖ‪.‬‬

‫دو ﻧﻮع زﻣﺎنﺑﻨﺪی ﻣﯽﺗﻮان داﺷﺖ‪:‬‬

‫واﺑ ﺴﺘ ﮕ ﯽ ﻣ ﺤ ﻮ ر‬
‫ا وﻟ ﻮ ﯾ ﺖ ﻣ ﺤ ﻮ ر‬

‫ﻓﻌﺎﻟﯿﺖﻫﺎی ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎ واﺑﺴﺘﮕﯽﻫﺎﯾﯽ ذاﺗﯽ و ﮔﺮﯾﺰﻧﺎﭘﺬﯾﺮ ﺑﻪ ﻫﻤﺪﯾﮕﺮ دارﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺗﺎ وﻗﺘﯽ دﯾﻮاری ﺳﺎﺧﺘﻪ‬
‫ﻧﺸﺪه ﺑﺎﺷﺪ ﻧﻤﯽﺗﻮاﻧﯿﺪ آن را رﻧﮓ ﮐﻨﯿﺪ‪ .‬ﭼﻨﯿﻦ ﭘﺮوژهﻫﺎﯾﯽ را ﺑﺎﯾﺪ ﺑﻪ ﺷﯿﻮه واﺑﺴﺘﮕﯽ ﻣﺤﻮر ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺮد‪ .‬ﺑﺮای اﯾﻦ‬
‫ﮐﺎر ﺷﺒﮑﻪای از رواﺑﻂ ﻣﯿﺎن ﻓﻌﺎﻟﯿﺖﻫﺎ ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮد و اﻃﻼﻋﺎﺗﯽ دﯾﮕﺮ ﻣﺎﻧﻨﺪ ﻣﺪتزﻣﺎن آنﻫﺎ ﻧﯿﺰ درج ﻣﯽﺷﻮد‪ .‬ﭘﺲ از‬
‫آن ﺑﺎ روش ﻣﺴﯿﺮ ﺑﺤﺮاﻧﯽ )‪ (critical path method‬و ﻫﻤﺎﻧﻨﺪ آن ﺗﺎرﯾﺦﻫﺎی آﻏﺎز و ﭘﺎﯾﺎن ﺑﻪ دﺳﺖ ﻣﯽآﯾﻨﺪ‪.‬‬
‫ﻧﺮماﻓﺰارﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﭘﺮﯾﻤﺎورا و ﻣﺎﯾﮑﺮوﺳﺎﻓﺖ ﭘﺮاﺟﮑﺖ ﻧﻤﻮﻧﻪﻫﺎﯾﯽ از اﺑﺰارﻫﺎی راﯾﺞ در اﯾﻦ ﻧﻮع ﺑﺮﻧﺎﻣﻪرﯾﺰیاﻧﺪ‪.‬‬

‫ﻓﻌﺎﻟﯿﺖﻫﺎی ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ را ﻣﯽﺗﻮان ﺑﻪ ﺷﮑﻠﯽ ﺳﺎﺧﺖ ﮐﻪ ﺑﻪ ﻫﻢ واﺑﺴﺘﻪ ﻧﺒﺎﺷﻨﺪ‪ .‬در اﯾﻦ ﺣﺎﻟﺖ ﻣﯽﺗﻮاﻧﯿﺪ آنﻫﺎ را ﺑﺎ‬
‫روﺷﯽ اوﻟﻮﯾﺖ ﻣﺤﻮر زﻣﺎنﺑﻨﺪی ﮐﻨﯿﺪ‪ .‬در اﯾﻦ روش‪ ،‬اوﻟﻮﯾﺖ ﻫﺮ ﻓﻌﺎﻟﯿﺖ ﺑﺮ ﭘﺎﯾﻪ ﻣﺠﻤﻮﻋﻪای از ﭘﺎراﻣﺘﺮﻫﺎ ﻣﺎﻧﻨﺪ ارزش و‬
‫رﯾﺴﮏ ﺗﻌﯿﯿﻦ ﻣﯽﺷﻮد و ﺳﭙﺲ ﻓﻬﺮﺳﺖ ﻓﻌﺎﻟﯿﺖﻫﺎ ﺑﺮ آن ﭘﺎﯾﻪ ﻣﺮﺗﺐ ﻣﯽﺷﻮد‪ .‬ﻧﺮماﻓﺰارﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﺗﺮﻟﻮ ﺑﺮ اﯾﻦ ﭘﺎﯾﻪ ﻋﻤﻞ‬
‫ﻣ ﯽ ﮐ ﻨ ﻨ ﺪ‪.‬‬

‫ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﻓﻘﻂ ﺑﺎ زﻣﺎنﺑﻨﺪیﻫﺎی اوﻟﻮﯾﺖ ﻣﺤﻮر ﮐﺎر ﻣﯽﮐﻨﻨﺪ و اﮔﺮ ﺑﻪ ﻧﻈﺮﺗﺎن ﻣﯽآﯾﺪ ﮐﻪ زﻣﺎنﺑﻨﺪی ﭘﺮوژهﺗﺎن را‬
‫ﻧﻤﯽﺗﻮاﻧﯿﺪ ﺑﻪ ﺷﯿﻮه اوﻟﻮﯾﺖ ﻣﺤﻮر ﺑﺴﺎزﯾﺪ ﺑﻪ اﯾﻦ ﻣﻌﻨﯿﺴﺖ ﮐﻪ ﻣﺤﺼﻮل ﭘﺮوژه ﺑﺮای ﺳﺎﺧﺖ ﺗﻄﺒﯿﻘﯽ ﻣﻨﺎﺳﺐ ﻧﯿﺴﺖ‪.‬‬

‫ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﻣﯽﺗﻮاﻧﻨﺪ از ﻫﺮ دو ﺷﯿﻮه زﻣﺎنﺑﻨﺪی اﺳﺘﻔﺎده ﮐﻨﻨﺪ‪ .‬در اﯾﻦ ﻧﻮع ﭘﺮوژهﻫﺎ ﺣﺘﯽ اﻣﮑﺎن ﺗﺮﮐﯿﺐ اﯾﻦ دو‬
‫ﺣﺎﻟﺖ ﻧﯿﺰ وﺟﻮد دارد‪ :‬ﻣﯽﺗﻮاﻧﯿﺪ ﺳﻄﻮح ﺑﺎﻻﺗﺮ ﺑﺮﻧﺎﻣﻪ را واﺑﺴﺘﮕﯽ ﻣﺤﻮر و ﺳﻄﻮح ﭘﺎﯾﯿﻦﺗﺮ را اوﻟﻮﯾﺖ ﻣﺤﻮر ﺑﺴﺎزﯾﺪ‪.‬‬

‫‪ .5.4.4‬ﻻﯾﻪﻫﺎی ﺑﺮﻧﺎﻣﻪرﯾﺰی‬

‫دو ﻻﯾﻪ ﺑﺮﻧﺎﻣﻪرﯾﺰی وﺟﻮد دارد‪:‬‬

‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﺎر‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی ﭼﮕﻮﻧﮕﯽ ﺑﺮﻧﺎﻣﻪرﯾﺰی‪ ،‬ارزﯾﺎﺑﯽ‪ ،‬و ﮐﻨﺘﺮل‬

‫ﻣﺤﺼﻮل اﯾﻦ دو ﻻﯾﻪ را ﻣﯽﺗﻮان ﺑﻪ ﺗﺮﺗﯿﺐ ﺑﺮﻧﺎﻣﻪ و ﻣﺘﺎﺑﺮﻧﺎﻣﻪ ﻧﺎﻣﯿﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺑﺮﻧﺎﻣﻪ رﯾﺴﮏ ﻓﻬﺮﺳﺘﯽ از رﯾﺴﮏﻫﺎی‬
‫ﺷﻨﺎﺳﺎﯾﯽ ﺷﺪه و واﮐﻨﺶﻫﺎﯾﯿﺴﺖ ﮐﻪ ﺑﺮاﯾﺸﺎن ﻃﺮاﺣﯽ ﮐﺮدهاﯾﺪ‪ .‬اﯾﻦ ﺑﺮﻧﺎﻣﻪ ﻣﯽﺗﻮاﻧﺪ در ﺻﻔﺤﻪﮔﺴﺘﺮدهای در اﮐﺴﻞ و‬

‫— ‪— 66‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻧﺮماﻓﺰارﻫﺎی ﻫﻤﺎﻧﻨﺪ آن ﺑﺎﺷﺪ و ﻓﻬﺮﺳﺖ رﯾﺴﮏ )‪ (risk register‬ﻧﺎﻣﯿﺪه ﺷﻮد‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻣﺘﺎﺑﺮﻧﺎﻣﻪ رﯾﺴﮏ‬
‫ﺳﻨﺪﯾﺴﺖ ﮐﻪ ﺷﯿﻮه ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ را ﺗﻮﺿﯿﺢ ﻣﯽدﻫﺪ‪ :‬ﺗﮑﻨﯿﮏﻫﺎﯾﯽ ﮐﻪ اﺳﺘﻔﺎده ﻣﯽﮐﻨﯿﺪ‪ ،‬ﺟﺮﯾﺎن ﮐﺎر‪ ،‬اﺳﻨﺎد‪ ،‬و …‬

‫ﻫﺮ ﻣﺘﺪوﻟﻮژی ﺷﯿﻮه ﻣﺪﯾﺮﯾﺖ ﻫﺮﮐﺪام از ﺣﻮزهﻫﺎ را ﺗﻮﺿﯿﺢ ﻣﯽدﻫﺪ و اﯾﻨﮕﻮﻧﻪ ﺑﺨﺸﯽ از ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎ در ﻣﺘﺪوﻟﻮژی وﺟﻮد‬
‫دارد‪ ،‬وﻟﯽ ﻫﻤﻪ ﺟﻨﺒﻪﻫﺎ را ﻧﻤﯽﺗﻮان در ﻣﺘﺪوﻟﻮژی ﻟﺤﺎظ ﮐﺮد و از اﯾﻦ رو ﮔﺎﻫﯽ ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد ﮐﻪ ﺑﺮای ﻫﺮ ﺣﻮزه‬
‫ﻣﺘﺎﺑﺮﻧﺎﻣﻪای ﻧﯿﺰ ﺑﺴﺎزﯾﺪ‪.‬‬

‫ﻣﻌﻤﻮﻻ ﻣﺘﺪوﻟﻮژیﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﭘﺮﯾﻨﺲ‪ ،۲‬ﮐﻪ ﻧﯿﺎز ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺨﺴﺘﯿﻦ دارﻧﺪ‪ ،‬ﺳﺎﺧﺖ ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎ را ﻧﯿﺰ ﭘﯿﺸﻨﻬﺎد‬
‫ﻣﯽﮐﻨﻨﺪ‪ ،‬وﻟﯽ آنﻫﺎﯾﯽ ﮐﻪ ﻣﺎﻧﻨﺪ ‪ P3.express‬ﻧﯿﺎز ﺑﻪ اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻧﺨﺴﺘﯿﻦ ﻧﺪارﻧﺪ ﭼﻨﯿﻦ ﭘﯿﺸﻨﻬﺎدی ﻧﯿﺰ ﻧﻤﯽﮐﻨﻨﺪ‪.‬‬
‫ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﺣﺘﯽ در ﻣﻮرد دوم ﻫﻢ اﮔﺮ ﺣﻮزهای وﺟﻮد دارد ﮐﻪ ﺣﺴﺎﺳﯿﺖﻫﺎی وﯾﮋهای در ﭘﺮوژه دارد‪ ،‬ﺑﻬﺘﺮ اﺳﺖ ﺑﺮاﯾﺶ‬
‫در آﻏﺎز ﻣﺘﺎﺑﺮﻧﺎﻣﻪ آﻣﺎده ﮐﻨﯿﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﺗﺪارﮐﺎت ﭘﺮوژه ﭼﺎﻟﺶﺑﺮاﻧﮕﯿﺰ اﺳﺖ‪ ،‬ﺷﯿﻮه ﺑﺮﻧﺎﻣﻪرﯾﺰی‪ ،‬ارزﯾﺎﺑﯽ و ﮐﻨﺘﺮل‬
‫آن را ﺗﻌﯿﯿﻦ ﮐﺮده‪ ،‬در ﺳﻨﺪی ﺑﺎ ﻧﺎم ﺑﺮﻧﺎﻣﻪ ﻣﺪﯾﺮﯾﺖ ﺗﺪارﮐﺎت ﯾﺎ اﺳﺘﺮاﺗﮋی ﻣﺪﯾﺮﯾﺖ ﺗﺪارﮐﺎت ﺛﺒﺖ ﮐﻨﯿﺪ‪.‬‬

‫ﻣﻌﻤﻮﻻ ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎی ﭘﺮوژهﻫﺎﯾﯽ ﮐﻪ در ﯾﮏ ﺳﺎزﻣﺎن اﺟﺮا ﻣﯽﺷﻮﻧﺪ ﻫﻤﺎﻧﻨﺪیﻫﺎی ﻓﺮاواﻧﯽ دارﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﻣﺘﺎﺑﺮﻧﺎﻣﻪای‬
‫ﮐﻪ در ﯾﮏ ﭘﺮوژه ﺳﺎﺧﺘﻪ ﺷﺪه ﺑﺎﺷﺪ ﺑﺮای ﺳﺎﯾﺮﯾﻦ ﻧﯿﺰ ﻣﯽﺗﻮاﻧﺪ ﮐﺎرآﻣﺪ ﺑﺎﺷﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﺑﻬﺘﺮ اﺳﺖ ﺑﺮای ﻫﺮ ﭘﺮوژه از ﺻﻔﺮ‬
‫آﻣﺎده ﻧﺸﻮد‪ .‬ﻣﯽﺗﻮان ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎی ﮐﻼن را در ﻣﺮﮐﺰی در ﺳﺎزﻣﺎن آﻣﺎده و ﻧﮕﻬﺪاری ﮐﺮد و ﺑﺮای ﻫﻤﻪ ﭘﺮوژهﻫﺎی ﺗﺎزه‬
‫ﻓﺮﺳﺘﺎد‪ .‬در زﻣﺎن اﺳﺘﻔﺎده از آنﻫﺎ در ﭘﺮوژهﻫﺎ اﯾﺪهﻫﺎی ﺑﻬﺒﻮدی ﻧﯿﺰ ﺷﮑﻞ ﻣﯽﮔﯿﺮﻧﺪ و ﻣﯽﺗﻮان آنﻫﺎ را ﺑﻪ ﻣﺮﮐﺰ ﻓﺮﺳﺘﺎد‬
‫ﺗﺎ در ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎی ﻋﻤﻮﻣﯽ ﺑﺎزﺗﺎب ﯾﺎﻓﺘﻪ‪ ،‬در ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﺗﺴﺮی ﭘﯿﺪا ﮐﻨﻨﺪ‪.‬‬

‫آﻧﭽﻪ در ﺑﺎﻻ ﺷﺮح داده ﺷﺪ ﻫﻤﺎن ﻣﺮﺣﻠﻪ ﻧﺨﺴﺘﯿﻦ اﺧﺘﺼﺎﺻﯽﺳﺎزی اﺳﺖ ﮐﻪ ﭘﯿﺶ از اﯾﻦ ﻣﻄﺮح ﺷﺪه ﺑﻮد‪:‬‬
‫اﺧﺘﺼﺎﺻﯽﺳﺎزی ﻣﺘﺪوﻟﻮژی در ﺳﻄﺢ ﺳﺎزﻣﺎن‪.‬‬

‫ﻣﺮﮐﺰی ﮐﻪ ﻣﺘﺎﺑﺮﻧﺎﻣﻪﻫﺎ را ﺗﺪوﯾﻦ و ﻧﮕﻬﺪاری ﻣﯽﮐﻨﺪ را ﻣﯽﺗﻮان ﻣﺮﮐﺰ ﺗﻌﺎﻟﯽ )‪ (center of excellence‬ﻧﺎﻣﯿﺪ‪ .‬ﺑﺮﺧﯽ ﻫﻢ‬
‫آن را ‪ PMO‬ﻣﯽﻧﺎﻣﻨﺪ )ﻣﺨﻔﻒ ‪ project management office‬ﯾﺎ ﻋﺒﺎرﺗﯽ ﻣﺸﺎﺑﻪ آن(‪.‬‬

‫‪ .5.4‬اﺟﺮا‬

‫ﻧﺨﺴﺖ ﺑﺮﻧﺎﻣﻪرﯾﺰی و ﺳﭙﺲ اﺟﺮا ﻣﯽﮐﻨﯿﻢ‪ .‬ﻫﻤﻪ ﭘﺮوژهﻫﺎ اﯾﻦﮔﻮﻧﻪ ﻫﺴﺘﻨﺪ‪:‬‬

‫در ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ‪ ،‬ﻋﻨﺎﺻﺮ در آﻏﺎز ﭘﺮوژه ﺑﻪ ﺷﮑﻞ ﮐﻼن ﯾﺎ ﺗﻔﺼﯿﻠﯽ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻣﯽﺷﻮﻧﺪ‪ .‬اﮔﺮ ﺑﺮﻧﺎﻣﻪرﯾﺰی‬
‫ﻧﺨﺴﺘﯿﻦ ﻋﻨﺼﺮی ﮐﻼن ﺑﺎﺷﺪ‪ ،‬در آﻏﺎز دورهای ﮐﻪ ﻗﺮار اﺳﺖ اﺟﺮا ﺷﻮد ﺗﻔﺼﯿﻠﯽ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬
‫در ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ‪ ،‬ﻋﻨﺎﺻﺮ در آﻏﺎز ﭘﺮوژه ﺑﻪ ﺷﮑﻞ ﮐﻼن ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻣﯽﺷﻮﻧﺪ و ﻫﺮ ﻋﻨﺼﺮ در زﻣﺎن اﺟﺮاﯾﺶ‬
‫ﺗ ﻔ ﺼ ﯿﻠ ﯽ ﺧ ﻮ ا ﻫ ﺪ ﺷ ﺪ‪.‬‬

‫‪ .1.5.4‬ﺗﻮازن ﻣﯿﺎن اﺟﺮا و ﺑﺮﻧﺎﻣﻪرﯾﺰی‬

‫ﯾﮑﯽ از ﻣﺴﺎﯾﻞ ﻣﻬﻢ در اﺟﺮای ﭘﺮوژه‪ ،‬ﺗﻮازن ﻣﯿﺎن اﺟﺮا و ﺑﺮﻧﺎﻣﻪرﯾﺰﯾﺴﺖ‪ .‬ﭘﺮوژهﻫﺎی ﻣﺨﺘﻠﻒ ﺑﻪ ﯾﮑﯽ از ﺷﮑﻞﻫﺎی زﯾﺮ‬
‫اﺟﺮا ﻣﯽﺷﻮﻧﺪ‪:‬‬

‫— ‪— 67‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺮﺧﯽ از ﭘﺮوژهﻫﺎ ﺑﺪون ﺑﺮﻧﺎﻣﻪ ﯾﺎ ﺑﺪون ﺗﻮﺟﻪ ﺑﻪ ﺑﺮﻧﺎﻣﻪ اﺟﺮا ﻣﯽﺷﻮﻧﺪ‪ .‬در اﯾﻦ ﺣﺎﻟﺖ ﻧﯿﺮوﻫﺎی اﺟﺮاﯾﯽ ﭘﺮوژه ﺑﺮ ﭘﺎﯾﻪ‬
‫ﺗﺠﺮﺑﻪ و ﺑﺮﻧﺎﻣﻪﻫﺎی ﺿﻤﻨﯽای ﮐﻪ در ذﻫﻦ دارﻧﺪ اﻗﺪام ﺑﻌﺪی را اﻧﺘﺨﺎب ﻣﯽﮐﻨﻨﺪ‪ .‬اﮔﺮ ﺑﺮﻧﺎﻣﻪای وﺟﻮد داﺷﺘﻪ‬
‫ﺑﺎﺷﺪ‪ ،‬ﺷﺎﯾﺪ ﻣﺴﺌﻮﻟﯽ ﺑﺮای ﺑﺮﻧﺎﻣﻪرﯾﺰی ﻫﻢ ﺑﺎﺷﺪ ﮐﻪ داﯾﻤﺎ آن را ﺑﺮ ﭘﺎﯾﻪ واﻗﻌﯿﺖﻫﺎی ﭘﺮوژه ﺑﻪروزرﺳﺎﻧﯽ ﮐﻨﺪ ﺗﺎ‬
‫ﺑﺘﻮاﻧﺪ از آن ﺑﺮای ارزﯾﺎﺑﯽ ﭘﺮوژه اﺳﺘﻔﺎده ﮐﻨﺪ‪ ،‬وﻟﯽ ﮐﻤﺎﮐﺎن اﺳﺘﻔﺎده از ﺑﺮﻧﺎﻣﻪ ﻣﺤﺪود ﺑﻪ ارزﯾﺎﺑﯽﺳﺖ و ﻧﻪ‬
‫ﺳﻮدﻫﯽ ﺑﻪ ﭘﺮوژه‪.‬‬
‫ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﭘﺎﻓﺸﺎری زﯾﺎد از ﺣﺪی ﺑﺮ ﻣﻄﺎﺑﻘﺖ اﺟﺮا و ﺑﺮﻧﺎﻣﻪرﯾﺰی دارﻧﺪ و ﮐﻮﭼﮏﺗﺮﯾﻦ ﺗﻔﺎوﺗﯽ را ﻧﻤﯽﭘﺬﯾﺮﻧﺪ‪،‬‬
‫ﮐﻪ ﺧﻮد ﻣﻨﺒﻊ دﺷﻮاریﻫﺎی ﻓﺮاواﻧﯿﺴﺖ‪ ،‬زﯾﺮا ﺑﺮﻧﺎﻣﻪﻫﺎ ﻫﯿﭻوﻗﺖ اﯾﺪهآل ﻧﯿﺴﺘﻨﺪ‪.‬‬
‫ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﺗﻮازن ﻣﻨﺎﺳﺒﯽ ﻣﯿﺎن ﺑﺮﻧﺎﻣﻪرﯾﺰی و اﺟﺮا ﺑﺮﻗﺮار ﻣﯽﮐﻨﻨﺪ‪ .‬اﺟﺮا ﺑﺮ ﭘﺎﯾﻪ ﺑﺮﻧﺎﻣﻪﻫﺎ اﻧﺠﺎم ﻣﯽﺷﻮد‪ ،‬و در‬
‫ﻋﯿﻦ ﺣﺎل اﻧﻌﻄﺎفﭘﺬﯾﺮی ﮐﺎﻓﯽ ﺑﺮای ﺟﺬب ﻋﺪمﻗﻄﻌﯿﺖﻫﺎ دارد‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﺑﺮﻧﺎﻣﻪﻫﺎ ﻧﯿﺰ ﺑﺮ ﭘﺎﯾﻪ واﻗﻌﯿﺖﻫﺎی‬
‫اﺟﺮاﯾﯽ داﯾﻤﺎ ﺑﻪروزرﺳﺎﻧﯽ ﻣﯽﺷﻮﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬در ‪ P3.express‬ﺟﻠﺴﻪای ﻫﻔﺘﮕﯽ وﺟﻮد دارد ﮐﻪ در آن اﻋﻀﺎی‬
‫ﮐﻠﯿﺪی ﭘﺮوژه ﮐﺎرﻫﺎی ﻫﻔﺘﻪ ﭘﯿﺶ رو را ﻫﻤﺮاه ﻫﻢ ﻣﺮور ﻣﯽﮐﻨﻨﺪ ﺗﺎ ﭼﺎﻟﺶﻫﺎ و ﻧﺎﺳﺎزﮔﺎریﻫﺎی اﺣﺘﻤﺎﻟﯽ ﮐﺸﻒ و‬
‫ا ﺻ ﻼ ح ﺷ ﻮ ﻧ ﺪ‪.‬‬

‫ﻫﺮﮔﺎه ﺑﺮﻧﺎﻣﻪ را ﺑﺮ ﭘﺎﯾﻪ واﻗﻌﯿﺖﻫﺎ ﺑﺎزﺑﯿﻨﯽ ﻣﯽﮐﻨﯿﺪ‪ ،‬ﺗﻐﯿﯿﺮ ﺷﮑﻞ داده‪ ،‬اﻃﻼﻋﺎت ﺗﺎزهای اراﺋﻪ ﻣﯽﮐﻨﺪ‪ .‬اﯾﻦ اﻃﻼﻋﺎت ﺑﺮای‬
‫ارزﯾﺎﺑﯽﻫﺎ )ﻣﻮﺿﻮع ﺣﻮزه ﺑﻌﺪی( ﺑﻪ ﮐﺎر ﻣﯽروﻧﺪ و ﺑﺮ آن ﭘﺎﯾﻪ اﻗﺪامﻫﺎی اﺻﻼﺣﯽ و ﭘﯿﺸﮕﯿﺮاﻧﻪ ﻃﺮاﺣﯽ ﺧﻮاﻫﯿﺪ ﮐﺮد‪.‬‬

‫ﻫﻤﮑﻨﺶ و ﺗﻮازن ﻣﯿﺎن ﺑﺮﻧﺎﻣﻪرﯾﺰی و اﺟﺮا ﺑﻪ ﭼﻪ ﺷﮑﻠﯽ در ﻣﺘﺪوﻟﻮژﯾﺘﺎن ﺑﺎزﺗﺎب ﯾﺎﻓﺘﻪ اﺳﺖ؟ اﮔﺮ ﻋﺪمﻗﻄﻌﯿﺖﻫﺎی‬
‫ﭘﺮوژهﺗﺎن ﺑﯿﺸﺘﺮ از ﻣﯿﺎﻧﮕﯿﻦ ﭘﺮوژهﻫﺎ ﺑﺎﺷﺪ‪ ،‬ﺷﺎﯾﺪ ﻻزم ﺑﺎﺷﺪ ﺑﻪ اﯾﻦ ﺣﻮزه ﺗﻮﺟﻪ ﺑﯿﺸﺘﺮی ﮐﺮده‪ ،‬آن را در ﻣﺘﺪوﻟﻮژی ﺧﻮد‬
‫ﺗ ﻘ ﻮ ﯾ ﺖ ﮐ ﻨ ﯿ ﺪ‪.‬‬

‫‪ .2.5.4‬ﻣﯿﺰان ﺗﻔﺼﯿﻞ‬

‫ﺣﺪ ﻣﻨﺎﺳﺒﯽ از ﺗﻔﺼﯿﻞ ﺑﺮای ﺑﺮﻧﺎﻣﻪﻫﺎﯾﯽ ﮐﻪ در ﻻﯾﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه آﻣﺎده ﻣﯽﮐﻨﯿﺪ وﺟﻮد دارد و ﺑﻬﺘﺮ اﺳﺖ ﺑﺎﻗﯿﻤﺎﻧﺪه‬
‫ﺟﺰﺋﯿﺎت را ﺑﻪ ﺗﯿﻢاﺟﺮاﯾﯽ ﺑﺴﭙﺎرﯾﺪ ﺗﺎ ﺧﻮد ﺑﻪﮔﻮﻧﻪای ﺿﻤﻨﯽ ﯾﺎ ﻏﯿﺮﺿﻤﻨﯽ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﮐﻨﻨﺪ‪ .‬ﺑﺎ اﯾﻦ ﮐﺎر ﻫﻢ ﺣﻖ اﻧﺘﺨﺎب‬
‫ﺑﯿﺸﺘﺮی ﺑﻪ ﺗﯿﻢﻫﺎ ﻣﯽدﻫﯿﺪ ﮐﻪ ﻣﺎﻧﻊ از ﺟﺒﻬﻪﮔﯿﺮیﻫﺎی ﻣﻨﻔﯽ ﻣﯽﺷﻮد و ﻫﻢ ﺑﺮﻧﺎﻣﻪﻫﺎی اﺻﻠﯽ را ﺳﺎدهﺗﺮ و ﮐﺎراﺗﺮ ﻧﮕﻪ‬
‫ﻣ ﯽ د ا ر ﯾ ﺪ‪.‬‬

‫ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﭘﺮﯾﻨﺲ‪ ۲‬ﺑﺮﻧﺎﻣﻪای ﮐﻼن دارد ﮐﻪ در آﻏﺎز ﭘﺮوژه ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮد‪ .‬ﺳﭙﺲ ﺑﺮای ﻫﺮ دوره ﺑﺮﻧﺎﻣﻪای ﮐﻤﺎﺑﯿﺶ‬
‫ﺗﻔﺼﯿﻠﯽ ﺑﺮای ﻫﻤﺎن دوره ﺗﻨﻈﯿﻢ ﻣﯽﺷﻮد‪ .‬ﺟﺰﺋﯿﺎت ﮐﺎﻣﻞ در ﺑﺮﻧﺎﻣﻪ ﺳﻮﻣﯽ ﻗﺮار دارد ﮐﻪ ﺳﺎﺧﺖ و ﻧﮕﻪداریاش ﺑﺮ دوش‬
‫ﺗﯿﻢﻫﺎی اﺟﺮاﯾﯿﺴﺖ و ﻧﻪ ﻣﺪﯾﺮ ﭘﺮوژه‪.‬‬

‫ﻧﮑﺘﻪ ﭘﺎﯾﺎﻧﯽ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎوﺟﻮد ﭘﺎﻓﺸﺎری ﻓﺮاواﻧﯽ ﮐﻪ ﺑﺮ اﻫﻤﯿﺖ ﺑﺮﻧﺎﻣﻪرﯾﺰی داﺷﺘﻪاﯾﻢ‪ ،‬ﻧﺒﺎﯾﺪ ﺗﺼﻮر ﮐﻨﯿﺪ ﮐﻪ ﻫﻤﻪﭼﯿﺰ‬
‫ﺑﺎﯾﺪ ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺷﻮد‪ .‬ﻋﻨﺎﺻﺮ ﮐﻢاﻫﻤﯿﺖ ﭘﺮوژه را ﻣﯽﺗﻮان ﺑﻪ ﻃﻮر ﻣﻮردی و ﺑﯿﺮون ﺑﺮﻧﺎﻣﻪﻫﺎ ﻫﺪاﯾﺖ ﮐﺮد‪.‬‬

‫‪ .3.5.4‬اﻗﻼم ﻗﺎﺑﻞﭘﯿﮕﯿﺮی‬

‫در ﺣﺎل اﺟﺮای ﭘﺮوژه ﺑﺎ اﻧﻮاع اﻗﻼم ﻗﺎﺑﻞﭘﯿﮕﯿﺮی )‪ (follow-up item‬روﺑﺮو ﺧﻮاﻫﯿﺪ ﺷﺪ ﮐﻪ ﺑﺎﯾﺪ آنﻫﺎ را ﺛﺒﺖ و ﻣﺪﯾﺮﯾﺖ‬
‫ﮐ ﻨ ﯿ ﺪ‪ .‬ﻣ ﻨ ﻈ ﻮ ر ا ز ا ﻗ ﻼ م ﻗ ﺎ ﺑ ﻞ ﭘ ﯿ ﮕ ﯿ ﺮ ی ‪ ،‬ﻋ ﻨ ﺎ ﺻ ﺮ ز ﯾ ﺮ ا ﺳ ﺖ ‪:‬‬

‫— ‪— 68‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫رﯾﺴﮏﻫﺎ‪ :‬رﯾﺴﮏ ﺑﻪ ﭘﯿﺸﺎﻣﺪﻫﺎﯾﯽ ﮐﻪ ﻣﻤﮑﻦ اﺳﺖ در آﯾﻨﺪه روی دﻫﻨﺪ و اﺛﺮی ﻣﺜﺒﺖ ﯾﺎ ﻣﻨﻔﯽ ﺑﺮ ﭘﺮوژه ﺑﮕﺬارﻧﺪ‬
‫ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪ .‬در زﻣﺎن اﺟﺮای ﭘﺮوژه‪ ،‬ﺑﻪ دﻟﯿﻞ ﻧﺰدﯾﮑﯽ ﺑﯿﺸﺘﺮ ﺑﻪ ﮐﺎر‪ ،‬اﻣﮑﺎن ﺑﯿﺸﺘﺮی ﺑﺮای ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎ‬
‫ﺧﻮاﻫﯿﺪ داﺷﺖ‪ .‬ﺑﺴﯿﺎری از ﺳﯿﺴﺘﻢﻫﺎی ﭼﺎﺑﮏ ﺟﻠﺴﻪﻫﺎﯾﯽ روزاﻧﻪ دارﻧﺪ ﮐﻪ ﻫﻤﻪ اﻋﻀﺎی ﺗﯿﻢ ﮔﺮد ﻫﻢ ﻣﯽآﯾﻨﺪ و‬
‫در ﻣﺪت ‪ ۱۵‬ﺗﺎ ‪ ۲۰‬دﻗﯿﻘﻪ‪ ،‬ﻫﺮﮐﺪام از اﻋﻀﺎی ﺗﯿﻢ ﭘﺎﺳﺦ ﺳﻪ ﭘﺮﺳﺶ را ﻣﯽدﻫﺪ‪ :‬از دﯾﺮوز ﺗﺎ اﻣﺮوز ﭼﻪ ﮐﺮدهام؟ از‬
‫اﻣﺮوز ﺗﺎ ﻓﺮدا ﭼﻪ ﺧﻮاﻫﻢ ﮐﺮد؟ ﺑﺮای اﻧﺠﺎم ﮐﺎرﻫﺎﯾﻢ ﺑﺎ ﭼﻪ دﺷﻮاریﻫﺎﯾﯽ ﻣﻤﮑﻦ اﺳﺖ روﺑﺮو ﺷﻮم؟ ﭼﻨﯿﻦ‬
‫ﺟﻠﺴﻪﻫﺎﯾﯽ ﻓﺮﺻﺖ ﺧﻮﺑﯽ ﺑﺮای ﺷﻨﺎﺳﺎﯾﯽ رﯾﺴﮏﻫﺎﯾﯿﺴﺖ ﮐﻪ در آﯾﻨﺪه ﻧﺰدﯾﮏ وﺟﻮد ﺧﻮاﻫﺪ داﺷﺖ و ﺑﺎ ﮐﻤﯽ‬
‫ﮐﻮﺷﺶ ﺑﯿﺸﺘﺮ ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ آن را ﺑﻪ رﯾﺴﮏﻫﺎی دورﺗﺮ ﻫﻢ ﺗﺴﺮی دﻫﯿﺪ‪ .‬ﭼﻨﯿﻦ ﺟﻠﺴﻪای ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر‬
‫ﮐﻮﭼﮏ ﻣﻨﺎﺳﺐ اﺳﺖ‪ ،‬وﻟﯽ در ﺳﺎﯾﺮ ﭘﺮوژهﻫﺎ ﻫﻢ ﻣﯽﺗﻮان ﺷﮑﻞﻫﺎی اﺧﺘﺼﺎﺻﯽﺳﺎزیﺷﺪهای از آن را ﺑﻪ وﺟﻮد‬
‫آورد‪.‬‬
‫ﻣﺴﺎﯾﻞ‪ :‬ﺑﻪ ﻃﻮر ﮐﻠﯽ‪ ،‬ﻫﺮﭼﻪ ﺧﻼف ﺑﺮﻧﺎﻣﻪﻫﺎ ﭘﯿﺶ رﻓﺘﻪ ﺑﺎﺷﺪ »ﻣﺴﺌﻠﻪ« ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪ .‬ﻣﺸﮑﻞﻫﺎﯾﯽ ﮐﻪ در‬
‫ﻫ ﻨ ﮕ ﺎ م ﮐ ﺎ ر ر و ی ﻣ ﯽ د ﻫ ﻨ ﺪ و ر ﯾ ﺴ ﮏ ﻫ ﺎ ﯾ ﯽ ﮐ ﻪ ﻋ ﯿ ﻨ ﯿ ﺖ ﭘ ﯿ ﺪ ا ﻣ ﯽ ﮐ ﻨ ﻨ ﺪ ﻧ ﻤ ﻮ ﻧ ﻪ ﻫ ﺎ ﯾ ﯽ ا ز ﻣ ﺴ ﺎ ﯾ ﻞ ﻫ ﺴ ﺘ ﻨ ﺪ‪.‬‬
‫ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻬﺒﻮد‪ :‬ﺑﻬﺘﺮ اﺳﺖ رﺿﺎﯾﺖ ذیﻧﻔﻌﺎن را دورهای ارزﯾﺎﺑﯽ ﮐﺮده‪ ،‬ﺑﺮ ﭘﺎﯾﻪ آن ﺑﺮﻧﺎﻣﻪﻫﺎﯾﯽ ﺑﺮای ﺑﻬﺒﻮد ﮐﺎر‬
‫ﻃﺮاﺣﯽ ﮐﻨﯿﺪ‪.‬‬
‫درﺧﻮاﺳﺖﻫﺎی ﺗﻐﯿﯿﺮ‪ :‬ﻫﺮﮔﺎه ﮐﺎرﻓﺮﻣﺎ ﯾﺎ ذیﻧﻔﻊ دﯾﮕﺮی درﺧﻮاﺳﺖ ﺗﻐﯿﯿﺮی ﺑﻔﺮﺳﺘﺪ‪ ،‬ﺑﺎﯾﺪ اﺛﺮ آن را ﺑﺮ ﮔﺴﺘﺮه‪،‬‬
‫زﻣﺎن‪ ،‬ﻫﺰﯾﻨﻪ‪ ،‬و ﺳﺎﯾﺮ ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﺳﻨﺠﯿﺪ و ﺑﺮ آن ﭘﺎﯾﻪ ﯾﮏ ﯾﺎ ﭼﻨﺪ ﭘﯿﺸﻨﻬﺎد ﺑﺮای ﭘﺬﯾﺮش آن آﻣﺎده و ﺑﺮای‬
‫ﻻﯾﻪﻫﺎی ﺗﺼﻤﯿﻢﮔﯿﺮﻧﺪه ﻓﺮﺳﺘﺎد‪ .‬ﻓﻘﻂ ﭘﺲ از اﻧﺘﺨﺎب رﺳﻤﯽ ﯾﮑﯽ از ﭘﯿﺸﻨﻬﺎدﻫﺎ ﺗﻐﯿﯿﺮ را در ﭘﺮوژه اﻋﻤﺎل ﮐﻨﯿﺪ‪.‬‬
‫ﺗﻐﯿﯿﺮ ذاﺗﺎ ﻋﻨﺼﺮی ﻣﻨﻔﯽ ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﻓﻘﻂ ﺗﻐﯿﯿﺮی ﮐﻪ ﯾﮑﭙﺎرﭼﻪ )ﺑﺮ ﭘﺎﯾﻪ ﻫﻤﻪ ﻣﺘﻐﯿﺮﻫﺎ( ﮐﻨﺘﺮل ﻧﺸﺪه ﺑﺎﺷﺪ ﺗﺎﺛﯿﺮی‬
‫ﻣﻨﻔﯽ دارد‪.‬‬
‫درس آﻣﻮﺧﺘﻪﻫﺎ‪ :‬ﻫﺮﭼﻪ در ﭘﺮوژه ﻣﯽآﻣﻮزﯾﻢ ﻣﯽﺗﻮاﻧﺪ در آﯾﻨﺪه ﮐﺎرﮔﺸﺎ ﺑﺎﺷﺪ‪ .‬ﺑﻬﺘﺮ اﺳﺖ اﯾﻦ ﻣﻮارد را ﺑﺮای‬
‫ﭘﺮوژهﻫﺎی ﺑﻌﺪی ﺛﺒﺖ و ﻧﮕﻬﺪاری ﮐﻨﯿﻢ‪.‬‬

‫ﻓﺮﻗﯽ ﻧﻤﯽﮐﻨﺪ ﮐﻪ ﭘﺮوژه ﺗﺎ ﭼﻪ اﻧﺪازه ﺳﺎده و ﮐﻮﭼﮏ ﺑﺎﺷﺪ‪ ،‬ﺑﺎزﻫﻢ ﺑﺎﯾﺪ اﯾﻦ ﻣﻮارد را ﺑﻪ ﻣﺤﺾ ﺷﻨﺎﺳﺎﯾﯽ ﺛﺒﺖ ﮐﺮد‪،‬‬
‫وﮔﺮﻧﻪ ﻫﻢ اﻣﮑﺎن ﻓﺮاﻣﻮشﮐﺎری وﺟﻮد دارد و ﻫﻢ اﯾﻦﮐﻪ ﺑﻪ ﺧﺎﻃﺮ ﺳﭙﺮدن آنﻫﺎ ﺑﯽدﻟﯿﻞ ﺑﺨﺸﯽ از ﺗﻮان ذﻫﻨﯽﺗﺎن را‬
‫ﺻﺮف ﺧﻮد ﺧﻮاﻫﺪ ﮐﺮد‪ .‬ﭘﺲ از ﺛﺒﺖ ﺑﺎﯾﺪ آنﻫﺎ را ﭘﯿﮕﯿﺮی ﮐﺮد‪ ،‬ﺗﺎ زﻣﺎﻧﯽ ﮐﻪ ﺑﺴﺘﻪ ﺷﻮﻧﺪ‪.‬‬

‫در ‪ P3.express‬ﯾﮏ ﺳﻨﺪ ﺑﺎ ﻧﺎم ﻓﻬﺮﺳﺖ ﭘﯿﮕﯿﺮی )‪ (follow up register‬ﺑﺮای ﻫﻤﻪ اﯾﻦ ﻣﻮارد وﺟﻮد دارد‪ ،‬وﻟﯽ ﺑﺴﯿﺎری‬
‫از ﻣﺘﺪوﻟﻮژیﻫﺎ اﺳﻨﺎد ﺟﺪاﮔﺎﻧﻪای ﺑﺮای اﯾﻦ ﻣﻮارد دارﻧﺪ‪ .‬در اﯾﻦ ﻣﺘﺪوﻟﻮژی‪ ،‬ﻫﺮ ﻋﻨﺼﺮی در اﯾﻦ ﺳﻨﺪ ﻧﯿﺎز ﺑﻪ ﯾﮏ ﻣﺘﻮﻟﯽ‬
‫)‪ (custodian‬دارد ﮐﻪ وﺿﻌﯿﺖ آن را ﭘﯿﮕﯿﺮی ﮐﺮده‪ ،‬ﮔﺰارش دﻫﺪ‪ .‬ﻫﻤﺎﻧﻨﺪ آن‪ ،‬ﻫﺮﮐﺪام از ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﭘﺮوژه ﻧﯿﺰ‬
‫ﺑ ﺎ ﯾ ﺪ ﯾ ﮏ ﻣ ﺘ ﻮﻟ ﯽ د ا ﺷ ﺘ ﻪ ﺑ ﺎ ﺷ ﻨ ﺪ‪.‬‬

‫‪ .6.4‬ارزﯾﺎﺑﯽ ﭘﯿﺸﺮﻓﺖ‬

‫ﺑﺮﻧﺎﻣﻪﻫﺎ دو ﮐﺎرﺑﺮد دارﻧﺪ‪:‬‬

‫ﻫ ﺪاﯾ ﺖ ﮐﺎ ر‬
‫ارزﯾﺎﺑ ﯽ ﮐﺎر اﻧ ﺠﺎ م ﺷ ﺪه‬

‫— ‪— 69‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﺟﺮا ﺑﺮ ﭘﺎﯾﻪ ﺑﺮﻧﺎﻣﻪﻫﺎ اﻧﺠﺎم ﻣﯽﺷﻮد‪ ،‬وﻟﯽ ﻫﯿﭻوﻗﺖ اﻧﻄﺒﺎق ﮐﺎﻣﻠﯽ وﺟﻮد ﻧﺪارد‪ .‬از اﯾﻦ رو‪ ،‬ﺑﺎﯾﺪ ﺑﺮﻧﺎﻣﻪﻫﺎ را داﯾﻤﺎ ﺑﺮ ﭘﺎﯾﻪ‬
‫واﻗﻌﯿﺖﻫﺎی اﺟﺮاﯾﯽ ﺑﺎزﺑﯿﻨﯽ ﮐﺮد ﺗﺎ ﺑﺮای ﻫﺪاﯾﺖ اداﻣﻪ ﮐﺎر ﮐﺎرﺑﺮد داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪﻫﺎ ﺑﺎزﺑﯿﻨﯽ ﻣﯽﺷﻮﻧﺪ‪،‬‬
‫ﺷﺎﯾﺪ ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﻣﺎﻧﻨﺪ زﻣﺎن ﺗﻐﯿﯿﺮ ﮐﻨﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺷﺎﯾﺪ ﺗﺎزهﺗﺮﯾﻦ ﭘﯿﺸﺒﯿﻨﯽ ﺑﺮای ﭘﺮوژهای ﮐﻪ ﻗﺮار ﺑﻮد ‪ ۲۲‬ﻣﺎﻫﻪ‬
‫ﺑﻪ ﭘﺎﯾﺎن ﺑﺮﺳﺪ اﯾﻦ ﺑﺎﺷﺪ ﮐﻪ در ‪ ۲۴‬ﻣﺎه ﺑﻪ ﭘﺎﯾﺎن ﺧﻮاﻫﺪ رﺳﯿﺪ‪ .‬در اﯾﻦ ﺣﺎﻟﺖ ﭼﻪ ﺑﺎﯾﺪ ﮐﺮد؟‬

‫‪ .1.6.4‬اﺻﻼح اﻧﺤﺮافﻫﺎ‬

‫ﻫﺮﮔﺎه ﺗﻔﺎوت اﺟﺮا و ﺑﺮﻧﺎﻣﻪ اﻧﺤﺮاﻓﯽ در ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﻣﺎﻧﻨﺪ زﻣﺎن و ﻫﺰﯾﻨﻪ اﯾﺠﺎد ﮐﻨﺪ‪ ،‬ﯾﺎ ﺑﺎﯾﺪ ﻣﺘﻐﯿﺮﻫﺎ را ﺑﺎزﺑﯿﻨﯽ ﮐﺮد‬
‫ﯾﺎ اﻧﺤﺮافﻫﺎ را از ﺑﯿﻦ ﺑﺮد‪ .‬ﻫﺮ ﻣﺘﺪوﻟﻮژی روﻧﺪ وﯾﮋهای ﺑﺮای اﯾﻦ ﮐﺎر دارد‪ .‬ﻣﻌﻤﻮﻻ ﻫﻨﮕﺎﻣﯽ ﮐﻪ اﺛﺮ اﻧﺤﺮاف از ﺣﺪی ﮐﻤﺘﺮ‬
‫ﺑﺎﺷﺪ‪ ،‬اﻋﻀﺎی ﺗﯿﻢ ﯾﺎ رﻫﺒﺮان ﺗﯿﻢﻫﺎ ﺑﺮای اﻧﺤﺮاف ﺗﺼﻤﯿﻢ ﻣﯽﮔﯿﺮﻧﺪ‪ ،‬اﮔﺮ اﺛﺮ از ﺣﺪ آنﻫﺎ ﺑﺎﻻﺗﺮ ﺑﺎﺷﺪ ﻣﺪﯾﺮ ﭘﺮوژه‪ ،‬وﮔﺮﻧﻪ‬
‫ﺣﺎﻣﯽ ﭘﺮوژه و اﻓﺮاد دﯾﮕﺮ در ﻻﯾﻪﻫﺎی ﺑﺎﻻﺗﺮ ﺳﺎزﻣﺎن‪.‬‬

‫ﺑﺴﯿﺎری از ﻣﺘﺪوﻟﻮژیﻫﺎ ﺣﺪود ﺗﺼﻤﯿﻢﮔﯿﺮی دارﻧﺪ‪ ،‬وﻟﯽ ﺑﺴﯿﺎری ﺑﺮداﺷﺖ اﺷﺘﺒﺎﻫﯽ درﺑﺎره آنﻫﺎ دارﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪،‬‬
‫ﺣﺪود ﺗﺼﻤﯿﻢﮔﯿﺮی در ﭘﺮﯾﻨﺲ‪ ۲‬ﺗﻠﻮراﻧﺲ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮﻧﺪ‪ ،‬و ﺑﺴﯿﺎری ﮔﻤﺎن ﻣﯽﮐﻨﻨﺪ ﮐﻪ اﯾﻦ ﺗﻠﻮراﻧﺲﻫﺎ ﻣﺎﻧﻨﺪ‬
‫ﺗﻠﻮراﻧﺲﻫﺎی ﻣﻬﻨﺪﺳﯽ ﻫﺴﺘﻨﺪ و ﻣﺸﺨﺺ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﭼﻪ ﻣﻮاردی ﻧﯿﺎز ﺑﻪ ﺗﺼﻤﯿﻢﮔﯿﺮی دارﻧﺪ و اﮔﺮ اﺛﺮ ﻣﻮردی ﮐﻤﺘﺮ از‬
‫ﺗﻠﻮراﻧﺲ ﺑﺎﺷﺪ ﻧﯿﺎز ﺑﻪ اﺻﻼح ﻧﺨﻮاﻫﺪ داﺷﺖ‪ .‬ﭼﻨﯿﻦ ﺑﺮداﺷﺘﯽ درﺳﺖ ﻧﯿﺴﺖ‪ :‬ﻫﺮ اﻧﺤﺮاﻓﯽ ﻧﯿﺎز ﺑﻪ اﺻﻼح دارد و‬
‫ﺗﻠﻮراﻧﺲﻫﺎ ﻓﻘﻂ ﻣﺸﺨﺺ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﭼﻪ ﮐﺴﯽ ﺑﺎﯾﺪ ﺗﺼﻤﯿﻢﮔﯿﺮی ﮐﻨﺪ‪.‬‬

‫ﻫﻤﯿﺸﻪ ﺑﻬﺘﺮ اﺳﺖ اﻧﺤﺮافﻫﺎ در زودﺗﺮﯾﻦ زﻣﺎن اﺻﻼح ﺷﻮﻧﺪ‪ ،‬زﯾﺮا ﻫﺮﭼﻪ ﺑﯿﺸﺘﺮ روی ﻫﻢ اﻧﺒﺎﺷﺘﻪ ﺷﻮﻧﺪ اﺻﻼح‬
‫ﮐﺮدﻧﺸﺎن دﺷﻮارﺗﺮ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫‪ .2.6.4‬اﺻﻼح ﯾﺎ ﭘﯿﺸﮕﯿﺮی‬

‫وﻗﺘﯽ اﻧﺤﺮاﻓﯽ وﺟﻮد دارد‪ ،‬ﺑﺎﯾﺪ ﺑﺮاﯾﺶ اﻗﺪاﻣﯽ اﺻﻼﺣﯽ ﻃﺮاﺣﯽ ﮐﻨﯿﺪ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﻻزم اﺳﺖ ﮐﻪ اﻗﺪاﻣﯽ ﭘﯿﺸﮕﯿﺮاﻧﻪ‬
‫ﻧﯿﺰ ﻃﺮاﺣﯽ ﮐﻨﯿﺪ ﮐﻪ اﺣﺘﻤﺎل ﺑﺮوز ﻣﺸﮑﻞﻫﺎی ﻫﻤﺎﻧﻨﺪش را در آﯾﻨﺪه ﮐﻢ ﮐﻨﺪ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ ﺑﺴﯿﺎری ﻓﻘﻂ ﺑﻪ اﻗﺪامﻫﺎی‬
‫اﺻﻼﺣﯽ ﺗﻮﺟﻪ ﻣﯽﮐﻨﻨﺪ و ﻧﻪ ﭘﯿﺸﮕﯿﺮاﻧﻪ‪.‬‬

‫اﮔﺮ ﺑﻪ ﻫﺮ دﻟﯿﻠﯽ ﻻزم ﺑﺎﺷﺪ ﮐﻪ ﻣﯿﺎن اﻗﺪام اﺻﻼﺣﯽ و اﻗﺪام ﭘﯿﺸﮕﯿﺮاﻧﻪ ﺗﻨﻬﺎ ﯾﮑﯽ را اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪ ،‬اﻧﺘﺨﺎب درﺳﺖ‪ ،‬اﻗﺪام‬
‫ﭘﯿﺸﮕﯿﺮاﻧﻪ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬اﮔﺮ ﻏﯿﺮ از اﯾﻦ ﻋﻤﻞ ﮐﻨﯿﺪ‪ ،‬ﻫﻤﯿﺸﻪ ﺑﺎ اﻧﺒﻮﻫﯽ از دﺷﻮاری روﺑﺮو ﺧﻮاﻫﯿﺪ ﺑﻮد و ﻫﯿﭻ زﻣﺎﻧﯽ ﺑﺮای‬
‫ﮐﺎرﻫﺎی زﯾﺮﺑﻨﺎﯾﯽ ﻧﺨﻮاﻫﯿﺪ داﺷﺖ‪.‬‬

‫روﻧﺪ ﻣﻨﺎﺳﺐ در روﯾﺎروﯾﯽ ﺑﺎ ﻫﺮ اﻧﺤﺮاﻓﯽ اﯾﻦﭼﻨﯿﻦ اﺳﺖ‪:‬‬

‫‪ .1‬دﻟﯿﻞ رﯾﺸﻪای ﺑﺮوز اﯾﻦ اﻧﺤﺮاف ﭼﯿﺴﺖ؟ ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﻢ از ﺑﺮوز ﻣﺸﮑﻞﻫﺎی ﻫﻤﺎﻧﻨﺪ آن در آﯾﻨﺪه ﺟﻠﻮﮔﯿﺮی‬
‫ﮐﻨ ﻢ ؟‬
‫‪ .2‬ﭼﮕﻮﻧﻪ ﻣﯽﺗﻮاﻧﻢ اﻧﺤﺮاف ﮐﻨﻮﻧﯽ را اﺻﻼح ﮐﻨﻢ؟‬

‫ﻧ ﮕ ﺎ ﻫ ﯽ ﺑ ﻪ ﻣ ﺘ ﺪ وﻟ ﻮ ژ ی ﺧ ﻮ د ﺑ ﯿ ﻨ ﺪ ا ز ﯾ ﺪ و ﺑ ﺒ ﯿ ﻨ ﯿ ﺪ ﮐ ﻪ ا ﯾ ﻦ د و ﻣ ﺴ ﺌﻠ ﻪ ﭼ ﮕ ﻮ ﻧ ﻪ ﭘ ﻮ ﺷ ﺶ د ا د ه ﺷ ﺪ ه ا ﻧ ﺪ‪ .‬ا ﮔ ﺮ ﮔ ﻤ ﺎ ن ﻣ ﯽ ﮐ ﻨ ﯿ ﺪ ﻣ ﻤ ﮑ ﻦ‬

‫— ‪— 70‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﺳﺖ ﻃﺮاﺣﯽ اﻗﺪامﻫﺎی ﭘﯿﺸﮕﯿﺮاﻧﻪ را ﻓﺮاﻣﻮش ﮐﻨﯿﺪ و اﯾﻦ ﻣﻮﺿﻮع در ﻣﺘﺪوﻟﻮژی ﺑﻪاﻧﺪازه ﮐﺎﻓﯽ روﺷﻦ ﻧﯿﺴﺖ‪ ،‬آن ﺟﻨﺒﻪ‬
‫را ﺗﻘﻮﯾﺖ ﮐﻨﯿﺪ ﺗﺎ از ﻗﻠﻢ ﻧﯿﻔﺘﺪ‪.‬‬

‫‪ .3.6.4‬ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه‬

‫ﯾﮑﯽ از ﻣﻌﯿﺎرﻫﺎی ﻣﻬﻢ در ارزﯾﺎﺑﯽ وﺿﻌﯿﺖ ﭘﺮوژه‪ ،‬ﺗﻮﺟﯿﻪﭘﺬﯾﺮی آن اﺳﺖ‪ .‬داﯾﻤﺎ ﺑﺎﯾﺪ اﯾﻦ ﻣﺴﺌﻠﻪ را ﮐﻨﺘﺮل ﮐﻨﯿﺪ و ﻫﺮﮔﺎه‬
‫ﭘﺮوژه ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﺧﻮد را از دﺳﺖ داد ﻣﺴﺌﻠﻪ را ﺑﻪ ﺣﺎﻣﯽ ﭘﺮوژه اﻃﻼع دﻫﯿﺪ‪.‬‬

‫ﻣﺘﺪوﻟﻮژﯾﺘﺎن اﺣﺘﻤﺎﻻ ﮐﻨﺘﺮلﻫﺎﯾﯽ دورهای ﺑﺮای ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه دارد‪ .‬اﮔﺮ اﯾﻦﮔﻮﻧﻪ ﻧﯿﺴﺖ‪ ،‬ﻻزم اﺳﺖ آن را ﺑﯿﻔﺰاﯾﯿﺪ‪.‬‬

‫درﺑﺎره ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﭼﻪ ﺑﺎﯾﺪ ﮐﺮد؟‬

‫ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه ﺟﻨﺒﻪﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ ﮔﺴﺘﺮه‪ ،‬زﻣﺎن‪ ،‬ﻫﺰﯾﻨﻪ‪ ،‬و ﮐﯿﻔﯿﺖ ﻫﺴﺘﻨﺪ‪ .‬ﺑﺮﺧﯽ ﻣﻨﺎﺑﻊ ﻣﺘﻐﯿﺮﻫﺎی دﯾﮕﺮی ﻣﺎﻧﻨﺪ ﻣﺠﻤﻮع‬
‫رﯾﺴﮏ و ﻣﻨﺎﻓﻊ را ﻧﯿﺰ اﺿﺎﻓﻪ ﻣﯽﮐﻨﻨﺪ‪ .‬ﻫﻤﻪ اﯾﻦ ﻣﺘﻐﯿﺮﻫﺎ را ﺑﺎﯾﺪ داﯾﻤﺎ ارزﯾﺎﺑﯽ ﮐﺮد و ﺗﻮﺟﯿﻪﭘﺬﯾﺮی ﭘﺮوژه ﻣﻌﻤﻮﻻ ﺗﺮﮐﯿﺒﯽ از‬
‫ﻫ ﻤ ﻪ آ ن ﻫ ﺎ ﺳ ﺖ‪.‬‬

‫ﻫﺮﯾﮏ از ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژهﺗﺎن ﺗﺎ ﭼﻪ اﻧﺪازه ﺣﺴﺎﺳﻨﺪ؟ ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬اﮔﺮ ﻗﺮار اﺳﺖ ﻣﺠﻤﻮﻋﻪای ﺑﺴﺎزﯾﺪ ﮐﻪ ﺑﺮای ﻫﻤﺎﯾﺸﯽ‬
‫ﻣﻠﯽ ﺑﻪ ﮐﺎر ﺑﺮود‪ ،‬ﻫﯿﭻﮔﻮﻧﻪ ﺗﺎﺧﯿﺮی ﭘﺬﯾﺮﻓﺘﻨﯽ ﻧﺨﻮاﻫﺪ ﺑﻮد و ﻧﯿﺎز ﺑﻪ ﮐﻨﺘﺮلﻫﺎی دﻗﯿﻖﺗﺮی ﺑﺮای زﻣﺎن ﺧﻮاﻫﯿﺪ داﺷﺖ‪ .‬در‬
‫ﭼﻨﯿﻦ ﻣﻮاردی‪ ،‬ﮐﻨﺘﺮلﻫﺎی ﻻزم را در ﻣﺘﺪوﻟﻮژی ﺧﻮد ﺗﻘﻮﯾﺖ ﮐﻨﯿﺪ‪.‬‬

‫‪ .4.6.4‬ارزﯾﺎﺑﯽﻫﺎی درﺳﺖ‬

‫ﭼﮕﻮﻧﻪ وﺿﻌﯿﺖ ﭘﺮوژه را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﯿﺪ؟‬

‫در ﮔﺬﺷﺘﻪ راﯾﺞ ﺑﻮد ﮐﻪ ﭘﯿﺸﺮﻓﺖ ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری را ﺑﺮ ﭘﺎﯾﻪ ﺗﻌﺪاد ﺧﻂ ﺑﺮﻧﺎﻣﻪای ﮐﻪ ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ ﺑﺴﻨﺠﻨﺪ‪.‬‬
‫زﻣﺎﻧﯽ ﺷﺮﮐﺘﯽ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﺑﺴﯿﺎر ﺧﺒﺮهای را اﺳﺘﺨﺪام ﮐﺮد و در ﭘﺎﯾﺎن ﻣﺎه از او ﺧﻮاﺳﺘﻨﺪ ﮐﻪ ﺗﻌﺪاد ﺧﻂ ﺑﺮﻧﺎﻣﻪای ﮐﻪ‬
‫ﻧﻮﺷﺘﻪ اﺳﺖ را اﻋﻼم ﮐﻨﺪ‪ .‬ﻣﻘﺪاری ﮐﻪ ﮔﺰارش ﮐﺮده ﺑﻮد ﻋﺪدی ﻣﻨﻔﯽ ﺑﻮد! او در ﻣﺪت ﻣﺎه ﻣﺸﻐﻮل ﺑﺮرﺳﯽ ﮐﺪﻫﺎی‬
‫ﭘﯿﺸﯿﻦ و اﺻﻼح آنﻫﺎ ﺑﻮد و در ﺑﺴﯿﺎری ﻣﻮارد ﮐﺪﻫﺎی ﺗﮑﺮاری ﯾﺎ اﺿﺎﻓﻪ را ﭘﺎک ﮐﺮده ﺑﻮد‪ .‬ﮐﺎر اﯾﻦ ﻓﺮد ﮐﻤﮏ ﻓﺮاواﻧﯽ ﺑﻪ‬
‫ﭘﺮوژه ﮐﺮده ﺑﻮد‪ ،‬وﻟﯽ ﺑﺎ ﻣﻌﯿﺎر ارزﯾﺎﺑﯽ ﻣﻮﺟﻮد اﯾﻦﮔﻮﻧﻪ ﺑﺮداﺷﺖ ﻧﻤﯽﺷﺪ‪.‬‬

‫اﯾﻦ ﺷﯿﻮه ارزﯾﺎﺑﯽ ﭘﯿﺸﺮﻓﺖ‪ ،‬ﮐﻪ ﺑﻪ وﺿﻮح ﮐﺎراﯾﯽ ﻣﻨﺎﺳﺒﯽ ﻧﺪارد‪ ،‬اﻣﺮوزه ﭼﻨﺪان راﯾﺞ ﻧﯿﺴﺖ‪ .‬دﻟﯿﻞ اﺻﻠﯽ ﺑﺮای از ﺑﯿﻦ‬
‫رﻓﺘﻦ اﯾﻦ روش‪ ،‬رواج ﺷﯿﻮهﻫﺎی ﭼﺎﺑﮏ و ﻣﺨﺎﻟﻔﺖ آنﻫﺎ ﺑﺎ اﯾﻦ ﻧﻮع ارزﯾﺎﺑﯽ اﺳﺖ‪ .‬ﺷﯿﻮهﻫﺎی راﯾﺞ ارزﯾﺎﺑﯽ در ﭘﺮوژهﻫﺎی‬
‫ﭼﺎﺑﮏ ﮐﺎراﯾﯽ ﻧﺴﺒﺘﺎ ﻣﻨﺎﺳﺒﯽ دارﻧﺪ‪ ،‬وﻟﯽ ﻣﺘﺎﺳﻔﺎﻧﻪ آنﻫﺎ ﻧﯿﺰ ﺑﻪ ﺷﮑﻞ دﯾﮕﺮی ﻣﻨﺤﺮف ﺷﺪهاﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬در ﺑﺴﯿﺎری‬
‫از اﯾﻦ روشﻫﺎ ﻓﻬﺮﺳﺘﯽ از ﮐﺎرﻫﺎ ﺑﺮای دوره ﭘﯿﺶ رو اﻧﺘﺨﺎب ﻣﯽﺷﻮﻧﺪ‪ .‬در ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﺷﻤﺎر ﮐﺎرﻫﺎی ﺗﮑﻤﯿﻞ ﺷﺪه در‬
‫ﭘﺎﯾﺎن دوره را ﺑﺎ آﻧﭽﻪ اﻧﺘﺨﺎب ﺷﺪه ﺑﻮد ﻣﻘﺎﯾﺴﻪ ﻣﯽﮐﻨﻨﺪ و اﯾﻦ ﻣﺴﺌﻠﻪ ﺑﺮاﯾﺸﺎن ﻣﻌﯿﺎر ارزﯾﺎﺑﯽ ﻣﻬﻤﯿﺴﺖ‪ .‬اﯾﻦ ﻣﻌﯿﺎر‬
‫درﺳﺖ ﻧﯿﺴﺖ‪ ،‬زﯾﺮا ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن را ﺗﺸﻮﯾﻖ ﻣﯽﮐﻨﺪ ﮐﻪ در آﻏﺎز دوره ﮐﺎرﻫﺎی ﮐﻤﺘﺮی را اﻧﺘﺨﺎب ﮐﻨﻨﺪ و آن ﻫﻢ ﺑﻪ ﻧﻮﺑﻪ‬
‫ﺧﻮد ﻣﻨﺠﺮ ﺑﻪ ﮐﺎﻫﺶ ﺧﺮوﺟﯽ ﻣﯽﺷﻮد‪ ،‬زﯾﺮا »ﮐﺎر ﺑﻪ اﻧﺪازه زﻣﺎﻧﯽ ﮐﻪ در اﺧﺘﯿﺎر دارﯾﺪ ﻣﻨﺒﺴﻂ ﻣﯽﺷﻮد« )اﺻﻞ‬
‫ﭘﺎرﮐﯿﻨﺴﻮن(‪.‬‬

‫— ‪— 71‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻫﻤﯿﺸﻪ ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺷﯿﻮه ارزﯾﺎﺑﯽ ﻋﻤﻠﮑﺮد ﺑﺮ ﻋﻤﻠﮑﺮد اﺛﺮ ﻣﯽﮔﺬارد‪ ،‬زﯾﺮا اﻋﻀﺎی ﺗﯿﻢ ﭘﺮوژه ﻣﯽﮐﻮﺷﻨﺪ ﺑﺎ‬
‫ﺗ ﻐ ﯿ ﯿ ﺮ ر و ﻧ ﺪ ﮐ ﺎ ر ی ﺧ ﻮ د ﮐ ﺎ ر ی ﮐ ﻨ ﻨ ﺪ ﮐ ﻪ د ر ا ر ز ﯾ ﺎ ﺑ ﯽ ﻫ ﺎ ﻣ ﻮ ﻓ ﻖ ﺗ ﺮ ﺟﻠ ﻮ ه ﮐ ﻨ ﻨ ﺪ‪.‬‬

‫ارزﯾﺎﺑﯽ ﻫﺪف واﻗﻌﯽ ﭘﺮوژه و ارزش آﻓﺮﯾﺪه ﺷﺪه ﺑﻪ دﻟﯿﻞ اﻧﺘﺰاﻋﯽ ﺑﻮدﻧﺸﺎن ﮐﺎری ﺳﺎده و ﻋﻤﻠﯽ ﻧﯿﺴﺖ‪ .‬از اﯾﻦ رو‪،‬‬
‫ﺑﻪﺟﺎی ارزﯾﺎﺑﯽ ﻫﺪف ﯾﺎ اﻫﺪاف اﺻﻠﯽ‪ ،‬ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﯿﻢ‪ .‬اﯾﻦ ﮐﺎر اﯾﺪهآل ﻧﯿﺴﺖ‪ ،‬وﻟﯽ ﻧﺰدﯾﮏﺗﺮﯾﻦ‬
‫ﺗﻘﺮﯾﺐ ﺑﺮای اﻫﺪاف اﺳﺖ‪ .‬در ﻣﺮاﺣﻞ ﺑﻌﺪ‪ ،‬ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﻣﯽﺗﻮاﻧﺪ ﺑﺮ ﭘﺎﯾﻪ اﯾﻦ دادهﻫﺎ ارزﯾﺎﺑﯽﻫﺎی‬
‫ﭘﯿﭽﯿﺪهﺗﺮی روی ﺗﻮﺟﯿﻪﭘﺬﯾﺮی و ارزش ﭘﺮوژه اﻧﺠﺎم دﻫﺪ‪.‬‬

‫ﻣﺸﮑﻞ راﯾﺞ در ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ اﯾﻦ اﺳﺖ ﮐﻪ ﺧﺮوﺟﯽ ارزﯾﺎﺑﯽﻫﺎ ﻣﻘﺎدﯾﺮی اﻧﺘﺰاﻋﯽ از ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه‪ ،‬ﻣﺎﻧﻨﺪ ﭘﯿﺸﺮﻓﺖ‬
‫واﻗﻌﯽ و ﺑﺮﻧﺎﻣﻪرﯾﺰی ﺷﺪه دورهای و ﺗﺠﻤﻌﯽ ﻫﺴﺘﻨﺪ‪ .‬اﯾﻦ دادهﻫﺎ در ﻓﺮآﯾﻨﺪ ارزﯾﺎﺑﯽ ﻻزﻣﻨﺪ‪ ،‬وﻟﯽ ﺧﺮوﺟﯽ ﻣﻨﺎﺳﺒﯽ‬
‫ﻧﯿﺴﺘﻨﺪ‪ .‬ﻣﺴﺌﻮل ارزﯾﺎﺑﯽ ﺑﺎﯾﺪ ﺑﺎ ﮐﻤﮏ ﺑﺮﻧﺎﻣﻪﻫﺎ و اﯾﻦ دادهﻫﺎ وﺿﻌﯿﺖ ﻣﺘﻐﯿﺮﻫﺎی ﭘﺮوژه را ﺑﺮای زﻣﺎن ﭘﺎﯾﺎن ﭘﯿﺶﺑﯿﻨﯽ‬
‫ﮐﻨﺪ؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪» ،‬اﮔﺮ اﯾﻨﮕﻮﻧﻪ ﭘﯿﺶ ﺑﺮوﯾﻢ‪ ،‬ﭘﺮوژه دو ﻣﺎه دﯾﺮﺗﺮ از زﻣﺎن ﻣﻘﺮر و ﺑﺎ ﻫﺰﯾﻨﻪای ﻣﻌﺎدل ‪ ۲۵‬ﻫﺰار ﭘﯿﺘﺰا ﺑﯿﺸﺘﺮ‬
‫ا ز ا ﻧ ﺘ ﻈ ﺎ ر ﻧ ﺨ ﺴ ﺘ ﯿ ﻦ ﭘ ﺎ ﯾ ﺎ ن ﺧ ﻮ ا ﻫ ﺪ ﯾ ﺎ ﻓ ﺖ‪« .‬‬

‫اﮔﺮ در ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﻓﻌﺎﻟﯿﺖ ﻣﯽﮐﻨﯿﺪ‪ ،‬ﺑﺎ ﺷﯿﻮه ﺗﺤﻠﯿﻞ زﻣﺎن ﮐﺴﺐ ﺷﺪه )‪ (earned schedule analysis‬آﺷﻨﺎ‬
‫ﺷﻮﯾﺪ‪ .‬اﯾﻦ روش ﺑﻬﺘﺮﯾﻦ ﮔﺰﯾﻨﻪ ﺑﺮای ﭘﯿﺶﺑﯿﻨﯽ زﻣﺎن ﭘﺎﯾﺎن ﭘﺮوژه اﺳﺖ‪.‬‬

‫‪ .5.6.4‬ﮔﺰارشدﻫﯽ‬

‫ﭘﺲ از ارزﯾﺎﺑﯽ وﺿﻌﯿﺖ ﭘﺮوژه‪ ،‬ﺑﺎﯾﺪ ﻧﺘﯿﺠﻪ را ﺑﻪ ﺑﺮﺧﯽ از ذیﻧﻔﻌﺎن ﮔﺰارش ﮐﻨﯿﺪ‪ .‬اﻋﻀﺎی ﺗﯿﻢ ﺑﺎﯾﺪ از وﺿﻌﯿﺖ ﭘﺮوژه آﮔﺎه‬
‫ﺑﺎﺷﻨﺪ ﺗﺎ ﺑﺘﻮاﻧﻨﺪ ﮐﺎر ﺧﻮد را ﺑﺮ آن ﭘﺎﯾﻪ اﺻﻼح ﮐﻨﻨﺪ‪ .‬ﺑﺮﺧﯽ ﻻﯾﻪﻫﺎی ﻣﺪﯾﺮﯾﺘﯽ ﺳﺎزﻣﺎن ﻫﻢ ﺑﺎﯾﺪ از وﺿﻌﯿﺖ ﭘﺮوژه ﺑﺎﺧﺒﺮ‬
‫ﺑﺎﺷﻨﺪ‪ .‬اﮔﺮ ﮐﺎرﻓﺮﻣﺎﯾﯽ ﺑﯿﺮون ﺳﺎزﻣﺎن داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﻫﻢ ﺑﯽﮔﻤﺎن از ﺷﻤﺎ اﻧﺘﻈﺎر ﮔﺰارش ﺧﻮاﻫﺪ داﺷﺖ‪.‬‬

‫در ﺑﯿﺸﺘﺮ ﻣﻮاﻗﻊ ﻧﻤﯽﺗﻮان ﺑﺎ ﻓﻘﻂ ﯾﮏ ﻧﻮع ﮔﺰارش ﺑﺎ ﻫﻤﻪ ذیﻧﻔﻌﺎن ارﺗﺒﺎط ﻣﻨﺎﺳﺐ ﺑﺮﻗﺮار ﮐﺮد‪ .‬ﺑﺮﺧﯽ ﻧﯿﺎز ﺑﻪ اﻃﻼﻋﺎت‬
‫ﻓﻨﯽ و ﺑﺮﺧﯽ ﻣﺪﯾﺮﯾﺘﯽ دارﻧﺪ‪ .‬ﺑﺮﺧﯽ ﻧﯿﺎز ﺑﻪ اﻃﻼﻋﺎت ﺗﻔﺼﯿﻠﯽ دارﻧﺪ و ﺑﺮﺧﯽ ﮐﻼن‪ .‬ﭼﻨﺪ ﻧﻮع ﮔﺰارش ﮐﻪ ﺑﺮای ﭘﺎﺳﺨﮕﻮﯾﯽ‬
‫ﺑﻪ ﻫﻤﻪ ﻧﯿﺎزﻫﺎ ﮐﺎﻓﯽ ﺑﺎﺷﺪ ﻃﺮاﺣﯽ ﮐﻨﯿﺪ و در ﻓﻬﺮﺳﺖ ذیﻧﻔﻌﺎن ﻫﻢ ﻣﺸﺨﺺ ﮐﻨﯿﺪ ﮐﻪ ﻫﺮ ﻓﺮد ﻗﺮار اﺳﺖ ﭼﻪ ﻧﻮع‬
‫ﮔﺰارﺷﯽ درﯾﺎﻓﺖ ﮐﻨﺪ‪ .‬ﭘﺲ از ﻓﺮﺳﺘﺎدن ﮔﺰارش‪ ،‬ﺑﺎ ذیﻧﻔﻌﺎن ﮔﻔﺘﮕﻮ ﮐﺮده‪ ،‬ﮐﺎرآﻣﺪی ﮔﺰارش را ارزﯾﺎﺑﯽ ﮐﻨﯿﺪ‪ .‬ﺑﺎﯾﺪ داﯾﻤﺎ‬
‫ﺑﻪ دﻧﺒﺎل ﯾﺎﻓﺘﻦ راهﻫﺎﯾﯽ ﺑﺮای ﺑﻬﺒﻮد ﮔﺰارشﻫﺎی ﺧﻮد ﺑﺎﺷﯿﺪ‪.‬‬

‫ذیﻧﻔﻌﺎن ﺑﻪ درﺟﻪﻫﺎی ﻣﺨﺘﻠﻔﯽ ﮔﺮﻓﺘﺎر ﻫﺴﺘﻨﺪ و ﺑﺴﯿﺎری از آنﻫﺎ ﺻﺒﺮ و ﺣﻮﺻﻠﻪ ﻧﺪارﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﮔﺰارشﻫﺎی ﺧﻼﺻﻪ‬
‫و ﺳﺮراﺳﺖ ﮐﺎرآﻣﺪﺗﺮ ﻫﺴﺘﻨﺪ‪ .‬ﺑﺮﺧﯽ از ذیﻧﻔﻌﺎﻧﺘﺎن ﭘﺎﻓﺸﺎری ﺧﻮاﻫﻨﺪ ﮐﺮد ﮐﻪ ﮔﺰارشﻫﺎی ﺗﻔﺼﯿﻠﯽ ﺑﺮاﯾﺸﺎن ﺑﻔﺮﺳﺘﯿﺪ‪،‬‬
‫وﻟﯽ ﺣﺘﯽ در آن ﺣﺎﻟﺖ ﻫﻢ ﮔﺰارﺷﯽ ﺗﮏﺻﻔﺤﻪای ﺑﻪ آن ﭘﯿﻮﺳﺖ ﮐﻨﯿﺪ‪ ،‬زﯾﺮا ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﮔﺰارش ﺗﻔﺼﯿﻠﯽ درﺧﻮاﺳﺖ‬
‫ﻣﯽﮐﻨﻨﺪ ﺑﯿﺸﺘﺮ از اﯾﻦ روﺳﺖ ﮐﻪ ﻣﻄﻤﺌﻦ ﺑﺎﺷﻨﺪ زﯾﺮﺳﺎﺧﺖ و ﺗﻮاﻧﺎﯾﯽ ﮐﺎﻓﯽ را ﺑﺮای ارزﯾﺎﺑﯽ ﭘﺮوژه دارﯾﺪ‪ ،‬وﻟﯽ ﻃﻮﻻﻧﯽ‬
‫ﺑﻮدن ﮔﺰارش ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﮐﻪ در ﻣﻄﺎﻟﻌﻪ آن ﺳﻬﻞاﻧﮕﺎری ﮐﻨﻨﺪ‪ .‬وﺟﻮد ﮔﺰارش ﺗﮏﺻﻔﺤﻪای در ﮐﻨﺎر ﮔﺰارش ﺗﻔﺼﯿﻠﯽ‬
‫اﯾﻦ ﻣﺸﮑﻞ را ﺣﻞ ﺧﻮاﻫﺪ ﮐﺮد‪.‬‬

‫ﻫﯿﭻ اﻟﺰاﻣﯽ ﻧﺪارد ﮐﻪ ﻫﻤﻪ ﮔﺰارشﻫﺎﯾﺘﺎن ﮐﺎﻏﺬی ﺑﺎﺷﻨﺪ‪ .‬ﮔﺎﻫﯽ ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ ﮔﺰارش ﺑﺮ روی ﺗﺨﺘﻪﻫﺎی ﺑﺰرگ در ﻣﺤﻞ‬
‫ﭘﺮوژه ﻗﺮار داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬اﮔﺮ ذیﻧﻔﻌﺎن ﻫﻢﻣﺤﻞ ﻧﯿﺴﺘﻨﺪ‪ ،‬ﺑﻪ ﺟﺎی ﺗﺨﺘﻪ ﻓﯿﺰﯾﮑﯽ ﻣﯽﺗﻮان از داﺷﺒﻮردﻫﺎی اﯾﻨﺘﺮﻧﺘﯽ‬

‫— ‪— 72‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﺳﺘﻔﺎده ﮐﺮد‪ .‬ﭼﻨﺎﻧﭽﻪ از اﯾﻦ ﺷﯿﻮه ارﺗﺒﺎﻃﯽ اﺳﺘﻔﺎده ﻣﯽﮐﻨﯿﺪ‪ ،‬ﺑﺎﯾﺪ ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ ﮐﻪ ذیﻧﻔﻌﺎن وﺟﻮد داﺷﺒﻮرد را‬
‫ﻓﺮاﻣﻮش ﻧﻤﯽﮐﻨﻨﺪ و از ﭘﺮوژه ﺑﺎﺧﺒﺮ ﻣﯽﻣﺎﻧﻨﺪ؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﭘﺲ از ﻫﺮ ﺑﻪروزرﺳﺎﻧﯽ اﯾﻤﯿﻠﯽ ﻓﺮﺳﺘﺎده‪ ،‬وﺟﻮد‬
‫ﻧﺴﺨﻪ ﺗﺎزه را اﻋﻼم ﮐﻨﯿﺪ‪.‬‬

‫‪ . 7 . 4‬ﺗ ﺤ ﻮﯾ ﻞ‬

‫داﺳﺘﺎﻧﯽ از ﯾﮏ ﺳﺎزﻧﺪه آﺳﺎﻧﺴﻮر وﺟﻮد دارد‪ :‬ﻣﺸﺘﺮﯾﺎن از ﮐﻨﺪی آﺳﺎﻧﺴﻮرﻫﺎ ﻧﺎراﺿﯽ ﺑﻮدﻧﺪ‪ .‬ﺳﺎزﻧﺪه ﭘﺮوژهﻫﺎی ﻣﺨﺘﻠﻔﯽ‬
‫ﺑﺮای اﻓﺰاﯾﺶ ﺳﺮﻋﺖ ﻣﺤﺼﻮل اﺟﺮا ﮐﺮده ﺑﻮد و ﻣﺸﺘﺮﯾﺎن ﻫﻤﭽﻨﺎن ﻧﺎراﺿﯽ ﺑﻮدﻧﺪ‪ .‬روزی ﺑﺮآن ﺑﻮدﻧﺪ ﮐﻪ ﭘﺮوژه دﯾﮕﺮی‬
‫ﺑﺮای اﻓﺰاﯾﺶ ﺳﺮﻋﺖ آﻏﺎز ﮐﻨﻨﺪ ﮐﻪ ﯾﮑﯽ از اﻋﻀﺎی ﺗﯿﻢ ﮔﻔﺘﮕﻮی ﺟﺎﻟﺒﯽ را آﻏﺎز ﮐﺮد‪:‬‬

‫ﭼﺮا؟‬
‫ﭼﯽ‪ ،‬ﭼﺮا؟‬
‫ﭼﺮا ﺑﺎﯾﺪ ﺳﺮﻋﺖ آﺳﺎﻧﺴﻮر را اﻓﺰاﯾﺶ دﻫﯿﻢ؟‬
‫ﺧ ﻮ ب ‪ ،‬ﺑ ﻪ ا ﯾ ﻦ دﻟ ﯿ ﻞ ﮐ ﻪ ﺳ ﺮ ﯾ ﻊ ﺗ ﺮ ﺑ ﻮ د ن ﺑ ﻬ ﺘ ﺮ ا ﺳ ﺖ!‬
‫ﭼﺮا ﺳﺮﯾﻊ ﺑﻮدن ﺑﻬﺘﺮ اﺳﺖ؟‬
‫ﻣﺸﺘﺮﯾﺎن اﻧﺘﻈﺎر آﺳﺎﻧﺴﻮرﻫﺎی ﺳﺮﯾﻊﺗﺮ دارﻧﺪ‪.‬‬
‫ﭼﺮا ﭼﻨﯿﻦ اﻧﺘﻈﺎری دارﻧﺪ؟‬
‫ﻣﻤﻢ… ﺧﻮب‪ ،‬آﺳﺎﻧﺴﻮر اﺗﺎﻗﮑﯽ ﮐﻮﭼﮏ اﺳﺖ و ﻣﺴﺎﻓﺮان ﮐﺎر ﺧﺎﺻﯽ ﻧﺪارﻧﺪ ﮐﻪ اﻧﺠﺎم دﻫﻨﺪ؛ ﺣﻮﺻﻠﻪﺷﺎن ﺳﺮ‬
‫ﻣﯽرود و از اﯾﻦ رو‪ ،‬ﺗﺮﺟﯿﺢ ﻣﯽدﻫﻨﺪ ﺳﺮﯾﻊﺗﺮ ﺑﺎﺷﺪ‪.‬‬
‫ﺧﻮب‪ ،‬ﭘﺲ ﻫﺪف اﻓﺰاﯾﺶ ﺳﺮﻋﺖ آﺳﺎﻧﺴﻮرﻫﺎ ﻧﯿﺴﺖ‪ ،‬ﻫﺪف ﺟﻠﻮﮔﯿﺮی از ﺳﺮرﻓﺘﻦ ﺣﻮﺻﻠﻪ ﻣﺴﺎﻓﺮان اﺳﺖ!‬

‫ﭘﺲ از ﻣﺪﺗﯽ ﺑﺮرﺳﯽ‪ ،‬ﺑﻪﺟﺎی ﺗﻐﯿﯿﺮ دادن ﺳﺮﻋﺖ آﺳﺎﻧﺴﻮر‪ ،‬ﻓﻘﻂ آﯾﯿﻨﻪای در آﺳﺎﻧﺴﻮر ﻧﺼﺐ ﮐﺮدﻧﺪ‪ .‬اﯾﻨﮕﻮﻧﻪ ﺣﻮاس‬
‫ﻣﺴﺎﻓﺮان ﺑﻪ ﺳﺮ و وﺿﻊ ﺧﻮدﺷﺎن ﻣﯽرﻓﺖ و اﯾﻦ ﻣﺸﻐﻮﻟﯿﺖ ﺑﺎﻋﺚ ﻣﯽﺷﺪ ﮐﻪ ﮔﺬﺷﺖ زﻣﺎن را ﮐﻤﺘﺮ اﺣﺴﺎس ﮐﻨﻨﺪ‪ .‬ﻧﮑﺘﻪ‬
‫ﺟﺎﻟﺐ اﯾﻦ اﺳﺖ ﮐﻪ ﭘﺲ از ﻧﺼﺐ آﯾﯿﻨﻪ‪ ،‬ﺑﺴﯿﺎری از اﻓﺮاد ﮔﻤﺎن ﮐﺮدﻧﺪ ﮐﻪ ﺳﺮﻋﺖ آﺳﺎﻧﺴﻮر ﺑﯿﺸﺘﺮ ﺷﺪه اﺳﺖ‪.‬‬

‫‪ .1.7.4‬ﺑﺮرﺳﯽﺗﺎن را ﺑﺎ اﻟﺰاﻣﺎت آﻏﺎز ﮐﻨﯿﺪ‬

‫ﺑﯿﺸﺘﺮ اﻓﺮاد در ﭘﺎﺳﺦ ﺑﻪ ﻧﯿﺎزﻫﺎ ﯾﺎ ﻣﺸﮑﻞﻫﺎ ﺑﯽدرﻧﮓ ﻧﺨﺴﺘﯿﻦ راﻫﮑﺎر »ﺑﺪﯾﻬﯽ« را اﻧﺘﺨﺎب ﻣﯽﮐﻨﻨﺪ‪ .‬اﮔﺮ زﻣﺎن ﺑﯿﺸﺘﺮی‬
‫ﺻﺮف درک ﻣﺸﮑﻞ و ﻧﯿﺎز ﮐﻨﯿﻢ و راﻫﮑﺎرﻫﺎی ﮔﻮﻧﺎﮔﻮن را ﺑﺴﻨﺠﯿﻢ‪ ،‬ﻣﻌﻤﻮﻻ ﻣﯽﺗﻮاﻧﯿﻢ ﮔﺰﯾﻨﻪﻫﺎی ﺑﻬﺘﺮی ﺑﯿﺎﺑﯿﻢ‪ .‬ﺑﺮای‬
‫ﻫﻤﯿﻦ ﭼﻨﯿﻦ روﻧﺪی در ﻫﻤﻪ ﻣﺘﺪوﻟﻮژیﻫﺎ وﺟﻮد دارد‪:‬‬

‫اﻟﺰاﻣﺎت ← ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ← ﻓﻌﺎﻟﯿﺖﻫﺎ‬

‫ﮔﺎم ﻧﺨﺴﺖ‪ ،‬ﺷﻨﺎﺳﺎﯾﯽ اﻟﺰاﻣﺎت اﺳﺖ؛ ﻫﻢ اﻟﺰاﻣﺎت واﺿﺢ و ﻫﻢ ﭘﻨﻬﺎن‪ .‬ﺑﺴﯿﺎری از اﻟﺰاﻣﺎت از ﺳﻮی ﮐﺎرﻓﺮﻣﺎ ﻫﺴﺘﻨﺪ‪ ،‬وﻟﯽ‬
‫ﻣﻌﻤﻮﻻ آﻧﭽﻪ ﺑﻪ ﺷﻤﺎ ﻣﯽﮔﻮﯾﻨﺪ واﻗﻌﺎ اﻟﺰام ﭘﺮوژه ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ راﻫﮑﺎری »ﺑﺪﯾﻬﯽ« اﺳﺖ ﺑﺮای اﻟﺰاﻣﯽ ﮐﻪ در ذﻫﻦ‬
‫داﺷﺘﻪاﻧﺪ‪ .‬از اﯾﻦ رو‪ ،‬ﺑﺎﯾﺪ ﺑﺎ آنﻫﺎ ﮔﻔﺘﮕﻮ ﮐﻨﯿﺪ ﺗﺎ ﺑﺘﻮاﻧﯿﺪ اﻟﺰاﻣﺎت واﻗﻌﯽ را اﺳﺘﺨﺮاج ﮐﻨﯿﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻣﻌﻤﻮﻻ ﺑﯿﺶ‬
‫از ﯾﮏ ﻧﻤﺎﯾﻨﺪه از ﺳﻮی ﮐﺎرﻓﺮﻣﺎ وﺟﻮد دارد و اﻟﺰاﻣﺎﺗﯽ ﮐﻪ در اﺧﺘﯿﺎرﺗﺎن ﻣﯽﮔﺬارﻧﺪ ﺷﺎﯾﺪ ﺑﺎ ﯾﮑﺪﯾﮕﺮ ﻫﻤﺎﻫﻨﮓ ﻧﺒﺎﺷﻨﺪ ﮐﻪ در‬

‫— ‪— 73‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫اﯾﻦ ﺣﺎﻟﺖ ﻫﻢ ﺑﺎﯾﺪ ﺑﻪ ﺷﮑﻞﻫﺎی ﮔﻮﻧﺎﮔﻮن رﻓﻊ اﺧﺘﻼف ﮐﻨﯿﺪ و ﺑﻪ ﻣﺠﻤﻮﻋﻪای ﺳﺎزﮔﺎر از اﻟﺰاﻣﺎت ﺑﺮﺳﯿﺪ‪ .‬ﺑﺴﺘﻪ ﺑﻪ ﻧﻮع‬
‫ﻣﺤﺼﻮل ﭘﺮوژه و ﻣﺤﺪوده ﻣﺴﺌﻮﻟﯿﺖﻫﺎﯾﺘﺎن‪ ،‬ﺷﺎﯾﺪ ﺑﻬﺘﺮ ﺑﺎﺷﺪ ﺑﻪ آﻧﭽﻪ از ﻧﻤﺎﯾﻨﺪﮔﺎن ﮐﺎرﻓﺮﻣﺎ ﻣﯽﺷﻨﻮﯾﺪ ﻧﯿﺰ ﮐﺎﻣﻼ اﻋﺘﻤﺎد‬
‫ﻧﮑﻨﯿﺪ و ﺑﺎ ﺷﻤﺎری از ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﮐﻪ در آﯾﻨﺪه از ﻣﺤﺼﻮل اﺳﺘﻔﺎده ﺧﻮاﻫﻨﺪ ﮐﺮد ﻫﻢ ﮔﻔﺘﮕﻮ ﮐﻨﯿﺪ‪.‬‬

‫اﻓﺰون ﺑﺮ ﮐﺎرﻓﺮﻣﺎ‪ ،‬ﺳﺎزﻣﺎن ﺧﻮدﺗﺎن ﻫﻢ ﭼﻪﺑﺴﺎ اﻟﺰاﻣﺎﺗﯽ ﺑﺮای ﻫﻤﻪ ﭘﺮوژهﻫﺎ داﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﺑﺎﯾﺪ در ﻧﻈﺮﺷﺎن ﺑﮕﯿﺮﯾﺪ‪.‬‬
‫ﺷﺎﯾﺪ آﯾﯿﻦﻧﺎﻣﻪﻫﺎی ﻣﺨﺘﻠﻔﯽ ﻫﻢ ﺑﺮای ﻧﻮع ﭘﺮوژهﺗﺎن وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﮐﻪ اﻟﺰاﻣﺎﺗﯽ را ﺣﮑﻢ ﮐﻨﻨﺪ‪.‬‬

‫ﻫﻤﯿﺸﻪ ﺑﺎﯾﺪ ﮐﺎرﺗﺎن را ﺑﺎ درک اﻟﺰاﻣﺎت آﻏﺎز ﮐﻨﯿﺪ و ﭘﺲ از آن ﺑﻪ ﺳﺮاغ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ و در ﭘﺎﯾﺎن ﻓﻌﺎﻟﯿﺖﻫﺎ ﺑﺮوﯾﺪ‪.‬‬
‫ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ و ﺗﻄﺒﯿﻘﯽ از اﯾﻦ دﯾﺪﮔﺎه ﺗﻔﺎوﺗﯽ ﺑﺎ ﻫﻢ ﻧﺪارﻧﺪ‪ :‬زﻣﺎن اﺟﺮای اﯾﻦ ﻓﺮآﯾﻨﺪﻫﺎ در آنﻫﺎ ﯾﮑﺴﺎن ﻧﯿﺴﺖ‪،‬‬
‫وﻟﯽ ﺗﺮﺗﯿﺐ ﻓﺮآﯾﻨﺪﻫﺎ ﯾﮑﺴﺎن اﺳﺖ‪.‬‬

‫ﻓﺮض ﮐﻨﯿﺪ درﮔﯿﺮ اﻧﺠﺎم ﭘﺮوژهای ﻧﺮماﻓﺰاری ﻫﺴﺘﯿﺪ و ﯾﮑﯽ از ذیﻧﻔﻌﺎن ﺑﻪ ﺷﻤﺎ ﻣﺮاﺟﻌﻪ ﻣﯽﮐﻨﺪ و ﻣﯽﮔﻮﯾﺪ ﮐﻪ ﻧﯿﺎز ﺑﻪ‬
‫ﻗﺎﺑﻠﯿﺖ ﺗﺎزهای دارﻧﺪ ﮐﻪ ﺑﺎ ﮐﻤﮏ آن ﻧﯿﺮوﻫﺎی ﭘﺸﺘﯿﺒﺎﻧﯽ ﺳﺎﯾﺖ ﺑﺘﻮاﻧﻨﺪ ﺑﺪون داﻧﺴﺘﻦ ﭘﺴﻮرد ﮐﺎرﺑﺮان ﺑﻪﺟﺎی آنﻫﺎ‬
‫ﻻﮔﯿﻦ ﮐﻨﻨﺪ‪ .‬ﭼﻪ ﺧﻮاﻫﯿﺪ ﮐﺮد؟‬

‫آﻧﭽﻪ ﺑﻪ ﺷﻤﺎ ﮔﻔﺘﻪاﻧﺪ درﺑﺎره ﯾﮏ ﺗﺤﻮﯾﻞﺷﺪﻧﯽ اﺳﺖ‪ ،‬وﻟﯽ ﻣﯽداﻧﯿﻢ ﺑﺎﯾﺪ ﮐﺎرﻣﺎن را ﺑﺎ اﻟﺰاﻣﺎت آﻏﺎز ﮐﻨﯿﻢ‪ .‬ﭘﺲ ﻧﺨﺴﺘﯿﻦ‬
‫ﮐﺎر اﯾﻦ اﺳﺖ ﮐﻪ درﺑﺎره اﯾﻦ ﻗﺎﺑﻠﯿﺖ ﺑﺎ آنﻫﺎ ﮔﻔﺘﮕﻮ ﮐﻨﯿﺪ و درک ﮐﻨﯿﺪ ﮐﻪ ﻧﯿﺎز واﻗﻌﯽﺷﺎن ﭼﯿﺴﺖ‪ .‬ﭘﺲ از آن‪ ،‬ﺑﻪ‬
‫راﻫﮑﺎرﻫﺎی ﻣﺨﺘﻠﻒ ﺑﯿﻨﺪﯾﺸﯿﺪ و ﺑﺎ ﻫﻤﮑﺎری آنﻫﺎ ﺑﻬﺘﺮﯾﻦ ﮔﺰﯾﻨﻪ را اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪.‬‬

‫روﻧﺪ راﯾﺞ در ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ اﯾﻦ اﺳﺖ ﮐﻪ ﻗﺎﺑﻠﯿﺖﻫﺎ در ﻗﺎﻟﺐ ‪ user story‬اراﺋﻪ ﺷﻮﻧﺪ؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪» :‬ﺑﻪﻋﻨﻮان ﻧﯿﺮوی‬
‫ﭘﺸﺘﯿﺒﺎﻧﯽ ﺳﺎﯾﺖ‪ ،‬ﻣﯽﺧﻮاﻫﻢ ﺑﺪون در اﺧﺘﯿﺎر داﺷﺘﻦ ﭘﺴﻮرد ﮐﺎرﺑﺮان از ﻃﺮف آنﻫﺎ در ﺳﺎﯾﺖ ﻻﮔﯿﻦ ﮐﻨﻢ ﺗﺎ وﺿﻌﯿﺖ‬
‫ﺣﺴﺎب و دﺳﺘﺮﺳﯽﻫﺎﯾﺸﺎن را از زاوﯾﻪ دﯾﺪ ﺧﻮدﺷﺎن ﺑﺒﯿﻨﻢ و ﻣﺸﮑﻞ را ﺑﻪﺳﺮﻋﺖ ﺣﻞ ﮐﻨﻢ‪ ،‬ﺑﺪون اﯾﻦﮐﻪ دهﻫﺎ ﭘﯿﺎم و‬
‫ﺗﺼﻮﯾﺮ از ﺻﻔﺤﻪ ﮐﺎرﺑﺮ ردوﺑﺪل ﺷﻮد‪«.‬‬

‫اﯾﻦ ﻗﺎﻟﺐ ﺑﺴﯿﺎر ﻣﻔﯿﺪ اﺳﺖ‪ ،‬زﯾﺮا ﺑﺨﺶ ﭘﺎﯾﺎﻧﯽ آن ﻫﺪف را ﺗﻮﺿﯿﺢ ﻣﯽدﻫﺪ و اﻟﺰاﻣﯽ ﮐﻪ در ﭘﺲ ﻗﺎﺑﻠﯿﺖ ﺑﻮده در ﻫﺪف‬
‫ﻣﺴﺘﺘﺮ اﺳﺖ‪ .‬اﯾﻦ ﻗﺎﻟﺐ ﮐﻤﺎﺑﯿﺶ ﻣﺨﺎﻃﺐ را ﺗﺸﻮﯾﻖ ﻣﯽﮐﻨﺪ ﮐﻪ ﺑﻪ راﻫﮑﺎرﻫﺎی دﯾﮕﺮ ﻫﻢ ﺑﯿﻨﺪﯾﺸﯿﺪ‪ .‬اﻓﺰون ﺑﺮ آن‪ ،‬ﺑﻪ‬
‫ﺗﺪﻗﯿﻖ ﻗﺎﺑﻠﯿﺖ ﻫﻢ ﮐﻤﮏ ﻣﯽﮐﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺑﺎ ﺧﻮاﻧﺪن ﻣﺘﻦ ﺑﺎﻻ ﻣﺘﻮﺟﻪ ﻣﯽﺷﻮﯾﻢ ﮐﻪ ﻧﯿﺎزی ﻧﯿﺴﺖ ﮐﻪ ﻧﯿﺮوﻫﺎی‬
‫ﭘﺸﺘﯿﺒﺎﻧﯽ ﺑﺘﻮاﻧﻨﺪ ﺑﻪﺟﺎی ﻣﺪﯾﺮان ﺳﺎﯾﺖ و ﺳﺎﯾﺮ ﮐﺎرﺑﺮان ﻻﮔﯿﻦ ﮐﻨﻨﺪ و ﻧﯿﺎز ﻓﻘﻂ ﺑﺮای ﻣﺸﺘﺮﯾﺎن اﺳﺖ‪.‬‬

‫آﯾﺎ ﻣﺘﺪوﻟﻮژﯾﺘﺎن ﺑﻪ اﻧﺪازه ﮐﺎﻓﯽ ﺑﻪ اﻟﺰاﻣﺎت ﭘﺮوژه اوﻟﻮﯾﺖ ﻣﯽدﻫﺪ؟ اﮔﺮ اﯾﻦ ﺟﻨﺒﻪ واﺿﺢ ﯾﺎ ﻗﻮی ﻧﯿﺴﺖ‪ ،‬ﺷﺎﯾﺪ ﺑﻬﺘﺮ ﺑﺎﺷﺪ‬
‫آن را ﺑﻬﺒﻮد دﻫﯿﺪ‪.‬‬

‫‪ .2.7.4‬ﺳﻠﺴﻠﻪﻣﺮاﺗﺐ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ‬

‫ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎ ﺑﻪ اﻧﺪازهای ﭘﺮﺷﻤﺎرﻧﺪ ﮐﻪ اﮔﺮ در ﻓﻬﺮﺳﺘﯽ ﺳﺎده و ﺗﮏﺳﻄﺤﯽ ﻗﺮار داده ﺷﻮﻧﺪ‬
‫ﻓﻬﺮﺳﺖ آﻧﻘﺪر ﺑﻠﻨﺪ ﻣﯽﺷﻮد ﮐﻪ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻧﺨﻮاﻫﺪ ﺑﻮد‪ .‬راﻫﮑﺎر ﻣﻌﻤﻮل در ﭼﻨﯿﻦ ﻣﻮاﻗﻌﯽ‪ ،‬دﺳﺘﻪﺑﻨﺪی ﮐﺮدن‬
‫آﯾﺘﻢﻫﺎی ﻓﻬﺮﺳﺖ اﺳﺖ و ﺑﺮای ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﻧﯿﺰ ﻣﯽﺗﻮان ﭼﻨﯿﻦ ﮐﺎری ﮐﺮد‪ .‬ﺑﻪﺟﺎی ﯾﮏ ﺳﻄﺢ دﺳﺘﻪﺑﻨﺪی ﻫﻢ‬
‫ﻣﯽﺗﻮاﻧﯿﺪ ﭼﻨﺪﯾﻦ ﺳﻄﺢ داﺷﺖ ﮐﻪ اﺻﻼﺣﺎ ﺳﻠﺴﻠﻪﻣﺮاﺗﺒﯽ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬

‫— ‪— 74‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺴﯿﺎری از ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺘﻔﺎده از دﺳﺘﻪﺑﻨﺪیﻫﺎی ﺳﻠﺴﻠﻪ ﻣﺮاﺗﺒﯽ را ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﻨﺪ‪ .‬در ﭼﻨﯿﻦ‬
‫دﺳﺘﻪﺑﻨﺪیﻫﺎﯾﯽ ﻣﺤﺼﻮل اﺻﻠﯽ ﭘﺮوژه ﺑﻪ ﭼﻨﺪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽ ﮐﻼن ﺗﻘﺴﯿﻢ ﻣﯽﺷﻮد‪ ،‬ﻫﺮﮐﺪام از آنﻫﺎ ﺑﻪ ﭼﻨﺪ‬
‫ﺗﺤﻮﯾﻞﺷﺪﻧﯽ ﮐﻮﭼﮏﺗﺮ و روﻧﺪ ﺑﻪ ﻫﻤﯿﻦ ﺗﺮﺗﯿﺐ اداﻣﻪ ﭘﯿﺪا ﻣﯽﮐﻨﺪ ﺗﺎ ﺑﻪ ﺟﺰﺋﯽﺗﺮﯾﻦ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﺑﺮﺳﯿﻢ‪.‬‬

‫اﯾﻦ دﺳﺘﻪﺑﻨﺪیﻫﺎی ﺳﻠﺴﻠﻪﻣﺮاﺗﺒﯽ ﻧﺎمﻫﺎی ﻣﺨﺘﻠﻔﯽ دارﻧﺪ‪:‬‬

‫ﺑﯿﺸﺘﺮ ﻣﻨﺎﺑﻊ‪ :‬ﺳﺎﺧﺘﺎر ﺷﮑﺴﺖ ﮐﺎر )‪(work breakdown structure‬‬

‫ﭘﺮﯾﻨﺲ‪ :۲‬ﺳﺎﺧﺘﺎر ﺷﮑﺴﺖ ﻣﺤﺼﻮل )‪(product breakdown structure‬‬
‫‪ :P3.express‬ﻧﻘﺸﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ )‪(deliverables map‬‬

‫ﺑﻪﮐﺎرﮔﯿﺮی ﭼﻨﯿﻦ ﺳﺎﺧﺘﺎرﻫﺎﯾﯽ ﺑﺴﯿﺎر ﮐﺎرآﻣﺪ اﺳﺖ‪ ،‬وﻟﯽ ﺑﺎزﻫﻢ ﺑﺎﯾﺪ ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻟﯿﺴﺖﻫﺎی ﺗﮏ ﺳﻄﺤﯽ ﺑﺮای‬
‫ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ ﮐﺎﻓﯽ و ﻣﻨﺎﺳﺐﺗﺮ ﻫﺴﺘﻨﺪ‪ .‬از اﯾﻦ رو‪ ،‬در ﻣﺘﺪوﻟﻮژی ‪ ،micro.P3.express‬ﮐﻪ ﻧﺴﺨﻪ وﯾﮋهای از‬
‫‪ P3.express‬ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ اﺳﺖ‪ ،‬وﺟﻮد ﻧﻘﺸﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ اﻟﺰاﻣﯽ ﻧﯿﺴﺖ‪.‬‬

‫‪ .3.7.4‬زﻣﺎن و ﺑﺴﺎﻣﺪ ﺗﺤﻮﯾﻞ‬

‫دﯾﺮ ﯾﺎ زود‪ ،‬ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﭘﺮوژه‪ ،‬ﺷﺎﻣﻞ ﻫﻤﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎﯾﺶ‪ ،‬ﺑﻪ ﮐﺎرﻓﺮﻣﺎ ﺗﺤﻮﯾﻞ ﻣﯽﺷﻮد و در اﺧﺘﯿﺎر ﮐﺎرﺑﺮان‬
‫ﻧﻬﺎﯾﯽ ﻗﺮار ﻣﯽﮔﯿﺮد‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬زﻣﺎن‪ ،‬ﭼﮕﻮﻧﮕﯽ‪ ،‬و ﺑﺴﺎﻣﺪ ﺗﺤﻮﯾﻞ ﻫﻤﯿﺸﻪ ﯾﮑﺴﺎن ﻧﯿﺴﺖ‪:‬‬

‫ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ‪ :‬ﺑﻪ دﻟﯿﻞ روﻧﺪ ﮐﻤﺎﺑﯿﺶ ﺧﻄﯽ اﯾﻦ ﻧﻮع ﭘﺮوژه‪ ،‬ﻣﻌﻤﻮﻻ ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﭘﺮوژه ﯾﮏﺑﺎره و در ﭘﺎﯾﺎن‬
‫ﮐﺎر ﺗﺤﻮﯾﻞ ﻣﯽﺷﻮد‪ .‬ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﭼﻨﺪ ﺑﺨﺶ ﮐﻤﺎﺑﯿﺶ ﺟﺪا از ﻫﻢ دارﻧﺪ و در ﻓﺎزﻫﺎی ﻣﺨﺘﻠﻒ اﻧﺠﺎم‬
‫ﺷﺪه‪ ،‬ﺟﺪاﮔﺎﻧﻪ و در ﻃﻮل اﻧﺠﺎم ﭘﺮوژه ﺗﺤﻮﯾﻞ ﻣﯽﺷﻮﻧﺪ‪.‬‬
‫ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ‪ :‬در ﻫﻨﮕﺎم اﺟﺮای ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﺑﺎﯾﺪ ﻧﺴﺨﻪﻫﺎی ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﺳﺎﺧﺘﻪ‬
‫ﺷﺪه‪ ،‬در اﺧﺘﯿﺎر ﻫﻤﻪ ﯾﺎ ﺑﺨﺸﯽ از ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﻗﺮار ﮔﯿﺮد ﺗﺎ ﺑﺮ ﭘﺎﯾﻪ ﺑﺎزﺧﻮردﻫﺎی درﯾﺎﻓﺘﯽ ﻣﺴﯿﺮ ﭘﯿﺶ روی ﭘﺮوژه‬
‫ﺗﻌﯿﯿﻦ ﮔﺮدد‪ .‬اﯾﻦ ﻧﺴﺨﻪﻫﺎ ﺑﺎﯾﺪ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﺑﺎﺷﻨﺪ‪ ،‬وﮔﺮﻧﻪ ﺑﺎزﺧﻮرد ﻓﺮاﻫﻢ ﺷﺪه اﻃﻤﯿﻨﺎنﭘﺬﯾﺮ ﻧﺨﻮاﻫﺪ ﺑﻮد‪ .‬از‬
‫آنﺟﺎﯾﯽ ﮐﻪ ﻧﺴﺨﻪﻫﺎ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻫﺴﺘﻨﺪ‪ ،‬ﻣﯽﺗﻮان آنﻫﺎ را ﺗﺤﻮﯾﻞ ﻧﯿﺰ داد و ﻋﻤﻠﯿﺎﺗﯽ ﮐﺮد‪ .‬اﯾﻨﮕﻮﻧﻪ‪ ،‬ﺗﺤﻮﯾﻞ در‬
‫ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﻣﯽﺗﻮاﻧﺪ ﺗﺪرﯾﺠﯽ ﺑﺎﺷﺪ‪.‬‬

‫ﭘﺮوژهای ﮐﻪ ﻧﺘﻮاﻧﺪ ﻧﺴﺨﻪﻫﺎی ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺤﺼﻮل را ﺑﺴﺎزد ﻧﻤﯽﺗﻮاﻧﺪ ﺗﻄﺒﯿﻘﯽ ﺑﺎﺷﺪ‪ .‬ﻓﺮاﻣﻮش ﻫﻢ ﻧﮑﻨﯿﺪ ﮐﻪ ﻫﺮ‬
‫ﻧ ﺴ ﺨ ﻪ ﻗ ﺎ ﺑ ﻞ ا ﺳﺘ ﻔ ﺎ د ه ﻣ ﺠ ﻤ ﻮ ﻋ ﻪا ی ا ز ﺗ ﺤ ﻮ ﯾ ﻞ ﺷ ﺪ ﻧ ﯽ ﻫ ﺎ ﺳ ﺖ ‪ ،‬وﻟ ﯽ ﻫ ﺮ ﻣ ﺠ ﻤ ﻮ ﻋ ﻪا ی ا ز ﺗ ﺤ ﻮ ﯾ ﻞ ﺷ ﺪ ﻧ ﯽ ﻫ ﺎ ﻧ ﺴ ﺨ ﻪا ی ﻗ ﺎ ﺑ ﻞ‬
‫ا ﺳ ﺘ ﻔ ﺎ د ه ﻧ ﯿ ﺴ ﺖ‪.‬‬

‫‪ .4.7.4‬رﯾﺴﮏ ﺗﺤﻮﯾﻞ‬

‫ﺗﺤﻮﯾﻞ ﯾﮏﺑﺎره در ﭘﺎﯾﺎن ﭘﺮوژه رﯾﺴﮏﻫﺎی ﻓﺮاواﻧﯽ دارد‪ ،‬زﯾﺮا اﮔﺮ ﻋﻨﺼﺮی از ﭘﺮوژه ﻣﻨﺎﺳﺐ ﻧﺒﺎﺷﺪ و در زﻣﺎن ﺗﺤﻮﯾﻞ‬
‫ﮐﺸﻒ ﺷﻮد‪ ،‬اﺻﻼﺣﺶ ﻣﯽﺗﻮاﻧﺪ ﺑﺴﯿﺎر ﭘﺮﻫﺰﯾﻨﻪ ﺑﺎﺷﺪ‪ .‬ﭘﺮوژهﻫﺎی ﺗﻄﺒﯿﻘﯽ ﮐﻪ ﺗﺤﻮﯾﻞ ﺗﺪرﯾﺠﯽ دارﻧﺪ ﭼﻨﯿﻦ رﯾﺴﮑﯽ‬
‫ﻧﺪارﻧﺪ‪ ،‬اﻣﺎ در ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﺑﺎﯾﺪ ﻣﺮاﻗﺐ آن ﺑﻮد‪.‬‬

‫— ‪— 75‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﺑﺎ اﯾﻦﮐﻪ در ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎی ﻣﺘﻌﯿﻦ ﻧﻤﯽﺗﻮان ﺗﺤﻮﯾﻞ در ﻣﯿﺎﻧﻪ ﮐﺎر داﺷﺖ‪ ،‬ﺑﺎزﻫﻢ ﻣﯽﺗﻮان روﻧﺪی دورهای ﺑﺮای‬
‫ﺑﺮرﺳﯽ وﺿﻌﯿﺖ ﺗﺎزه ﻣﺤﺼﻮل و درﯾﺎﻓﺖ ﺗﺎﯾﯿﺪی ﺿﻤﻨﯽ از ﮐﺎرﻓﺮﻣﺎ داﺷﺖ‪ .‬اﯾﻦ ﻣﺴﺌﻠﻪ ﭼﻨﺎن ﻣﻬﻢ اﺳﺖ ﮐﻪ ﺑﺴﯿﺎری از‬
‫ﻣﺘﺪوﻟﻮژیﻫﺎ روﻧﺪی ﺑﺮای اﯾﻦ ﻣﻨﻈﻮر دارﻧﺪ‪ .‬اﮔﺮ ﻣﺘﺪوﻟﻮژﯾﺘﺎن ﭼﻨﯿﻦ ﺟﻨﺒﻪای را ﭘﻮﺷﺶ ﻧﺪاده ﺑﺎﺷﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ آن را‬
‫ﺑﯿﻔﺰاﯾﯿﺪ‪ ،‬ﺑﻪوﯾﮋه اﮔﺮ ﭘﯿﺶﺑﯿﻨﯽ ﻣﯽﮐﻨﯿﺪ ﮐﻪ ﻣﯿﺎن ﮐﺎرﻓﺮﻣﺎ و ﭘﯿﻤﺎﻧﮑﺎر اﺧﺘﻼفﻧﻈﺮ ﺑﻪ وﺟﻮد ﺧﻮاﻫﺪ آﻣﺪ‪.‬‬

‫‪ .5.7.4‬ﺷﻤﺎر ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﻧﯿﻤﻪﮐﺎره‬

‫در ﻫﺮ زﻣﺎن ﺷﻤﺎری ﺗﺤﻮﯾﻞﺷﺪﻧﯽ ﻧﯿﻤﻪﮐﺎره در ﭘﺮوژه وﺟﻮد دارد‪ .‬ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎ ﺣﺴﺎﺳﯿﺘﯽ ﺑﻪ ﺧﺮج ﻧﻤﯽدﻫﻨﺪ و‬
‫ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﭘﺮﺷﻤﺎری را ﺑﻪﻣﻮازت ﻫﻢ ﭘﯿﺶ ﻣﯽﺑﺮﻧﺪ ﮐﻪ ﺑﺎﻋﺚ اﻓﺖ ﺑﻬﺮهوری ﮐﻠﯽ ﭘﺮوژه ﻣﯽﺷﻮد‪.‬‬

‫ﻣﺤﺪود ﮐﺮدن ﮐﺎر ﻧﯿﻤﻪﮐﺎره ﯾﮑﯽ از اﺻﻞﻫﺎی زﯾﺮﺑﻨﺎﯾﯽ در ﺗﻮﻟﯿﺪ ‪ Lean‬اﺳﺖ‪ ،‬ﮐﻪ ﺗﺎﺛﯿﺮ ﺑﺰرﮔﯽ ﻫﻢ در ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ‬
‫ﮔﺬاﺷﺘﻪ اﺳﺖ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﮐﺎرﺑﺮد آن ﻣﺤﺪود ﺑﻪ ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﻧﯿﺴﺖ و در ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﺑﺎﯾﺪ ﺑﻪ آن ﺗﻮﺟﻪ داﺷﺖ‪.‬‬

‫ﯾﮑﯽ از ﻣﺴﺎﯾﻞ اﺻﻠﯽ درﺑﺎره اﻓﺰاﯾﺶ ﺑﯿﺶ از اﻧﺪازه ﺷﻤﺎر ﮐﺎرﻫﺎی ﻣﻮازی اﯾﻦ اﺳﺖ ﮐﻪ وﻗﺘﯽ ﭼﻨﯿﻦ ﻓﺮﻫﻨﮕﯽ در ﭘﺮوژه‬
‫وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻫﺮﮔﺎه اﻋﻀﺎی ﺗﯿﻢ در ﺳﺎﺧﺖ ﺗﺤﻮﯾﻞﺷﺪﻧﯽای ﺑﻪ دﺷﻮاری ﺑﺮ ﺑﺨﻮرﻧﺪ ﺑﻪﺟﺎی ﮔﺮهﮔﺸﺎﯾﯽ ﺑﻪ ﺳﺮاغ‬
‫اﻧﺠﺎم ﺗﺤﻮﯾﻞﺷﺪﻧﯽ دﯾﮕﺮی ﻣﯽروﻧﺪ ﮐﻪ ﺧﺮوﺟﯽ ﮐﺎرﺷﺎن ﺑﻪ ﻇﺎﻫﺮ ﺑﺎﻻﺗﺮ ﺑﺎﺷﺪ‪ .‬ﻫﺮﭼﻪ ﺑﯿﺸﺘﺮ از زﻣﺎن ﺑﺮوز دﺷﻮاری‬
‫ﺑﮕﺬرد‪ ،‬ﺣﻠﺶ ﺳﺨﺖﺗﺮ ﻣﯽﺷﻮد و از اﯾﻦ رو ﭼﻨﯿﻦ روﻧﺪی ﻣﻨﺎﺳﺐ ﻧﯿﺴﺖ‪ .‬ﻫﻤﯿﺸﻪ ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻫﺪف زودﺗﺮ‬
‫آﻏﺎز ﮐﺮدن ﮐﺎرﻫﺎ ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ زودﺗﺮ ﺑﻪ ﭘﺎﯾﺎن رﺳﺎﻧﺪن آنﻫﺎﺳﺖ‪.‬‬

‫ﺑﺮﺧﯽ از ﻣﺘﺪوﻟﻮژیﻫﺎ ﻋﻨﺎﺻﺮی دارﻧﺪ ﮐﻪ ﺗﯿﻢ ﭘﺮوژه را ﺗﺸﻮﯾﻖ ﻣﯽﮐﻨﺪ ﮐﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﻧﯿﻤﻪﮐﺎره را ﺑﻪ ﺳﺮاﻧﺠﺎم‬
‫ﺑﺮﺳﺎﻧﻨﺪ و ﭘﺲ از آن دﺳﺖ ﺑﻪ ﮐﺎر ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﺗﺎزه ﺑﺸﻮﻧﺪ‪ .‬ﭼﻨﯿﻦ ﻋﻨﺼﺮی را ﻣﯽﺗﻮان ﺑﻪ روﻧﺪی ﺿﻤﻨﯽ ﺑﺮای‬
‫درﯾﺎﻓﺖ ﺗﺎﯾﯿﺪ ﻧﯿﺰ ﻣﺘﺼﻞ ﮐﺮد ﮐﻪ ﺧﻮد ﻣﺎﻧﻊ ﺑﺮوز ﺑﺴﯿﺎری از دﺷﻮاریﻫﺎی زﻣﺎن ﺗﺤﻮﯾﻞ ﻧﻬﺎﯾﯽ ﻣﯽﺷﻮد و در ﺑﺨﺶ‬
‫ﮔﺬﺷﺘﻪ ﺑﺮرﺳﯽ ﺷﺪ‪ .‬اﮔﺮ ﻣﺘﺪوﻟﻮژﯾﺘﺎن ﭼﻨﯿﻦ ﺟﻨﺒﻪای را ﭘﻮﺷﺶ ﻧﺪاده ﺑﺎﺷﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ آن را اﺿﺎﻓﻪ ﮐﻨﯿﺪ‪.‬‬

‫ﺗ ﻮ ﺟ ﻪ د ا ﺷ ﺘ ﻪ ﺑ ﺎ ﺷ ﯿ ﺪ ﮐ ﻪ آ ﻧ ﭽ ﻪ ﮔ ﻔ ﺘ ﻪ ﺷ ﺪ ﺑ ﻪ ﻣ ﻌ ﻨ ﯽ ﺣ ﺬ ف ﮐ ﺎ ر ﻣ ﻮ ا ز ی ﻧ ﯿ ﺴ ﺖ ‪ ،‬ﺑﻠ ﮑ ﻪ ﺑ ﻪ ﻣ ﻌ ﻨ ﯽ ﺑ ﻬ ﯿ ﻨ ﻪ ﺳ ﺎ ز ی آ ن ا ﺳ ﺖ‪ .‬ﻫ ﺮ‬
‫ﭘﺮوژهای ﻧﯿﺎز ﺑﻪ ﺣﺪی از ﮐﺎر ﻣﻮازی دارد و ﺣﺪ ﻣﻨﺎﺳﺐ ﺑﺴﺘﮕﯽ ﺑﻪ ﺷﺮاﯾﻂ و ﻣﺤﺼﻮل ﭘﺮوژه‪ ،‬اﻓﺮاد ﻣﺸﻐﻮل ﺑﻪ ﮐﺎر‪ ،‬و‬
‫ﺑﺴﯿﺎری ﻋﻨﺎﺻﺮ دﯾﮕﺮ دارد‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﺣﺪ ﺑﻬﯿﻨﻪ ﻣﻌﻤﻮﻻ ﺑﺴﯿﺎر ﭘﺎﯾﯿﻦﺗﺮ از آن اﺳﺖ ﮐﻪ ﺑﺴﯿﺎری ﻣﯽﭘﻨﺪارﻧﺪ‪.‬‬

‫‪ .6.7.4‬ﮐﯿﻔﯿﺖ ﮐﺎر‬

‫ﻫﻤﺎﻧﮕﻮﻧﻪ ﮐﻪ ﮔﻔﺘﻪ ﺷﺪ‪ ،‬ﺑﻬﺘﺮ اﺳﺖ روﻧﺪی ﺑﺮای ﺗﯿﻢ ﭘﺮوژه وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﺑﻪﺟﺎی ﮐﺎر روی اﻧﺒﻮﻫﯽ از‬
‫ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ‪ ،‬روی ﺷﻤﺎر اﻧﺪﮐﯽ ﮐﺎر ﮐﺮده‪ ،‬آنﻫﺎ را ﺑﻪ ﺳﺮاﻧﺠﺎم ﺑﺮﺳﺎﻧﺪ‪ .‬ﺑﻬﺘﺮ اﺳﺖ ﻣﺪﯾﺮ ﭘﺮوژه ﮐﺎرﻫﺎی ﭘﺎﯾﺎن ﯾﺎﻓﺘﻪ را‬
‫ﺑﺮرﺳﯽ و ﺗﺎﯾﯿﺪ ﻧﯿﺰ ﺑﮑﻨﺪ‪.‬‬

‫ﺗﺎﯾﯿﺪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﺑﺮ ﭘﺎﯾﻪ ﮔﺴﺘﺮه و ﮐﯿﻔﯿﺖ آنﻫﺎﺳﺖ‪ .‬ﺑﺎﯾﺪ ﭘﯿﺶ از آﻏﺎز ﺑﻪ ﮐﺎر روی ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ از ﻧﯿﺮوﻫﺎی‬
‫ﻓﻨﯽ ﭘﺮوژه ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ و ﮔﺴﺘﺮه و ﮐﯿﻔﯿﺖ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ را ﺑﺮ ﭘﺎﯾﻪ اﻟﺰاﻣﺎت و ﻧﯿﺎزﻫﺎی ذیﻧﻔﻌﺎن ﺗﻌﯿﯿﻦ ﮐﻨﯿﺪ‪ .‬ﭘﺲ از‬
‫اﯾﻦﮐﻪ ﮐﺎر ﺑﻪ ﭘﺎﯾﺎن رﺳﺪ‪ ،‬ﺑﺮ ﭘﺎﯾﻪ ﻫﻤﺎن ﺗﻌﺮﯾﻒ ﻧﺨﺴﺘﯿﻨﯽ ﮐﻪ ﺑﻪ ﮐﻤﮏ اﻋﻀﺎی ﺗﯿﻢ ﺷﺪه ﺑﻮد ﮐﺎرﺷﺎن را ﺑﺮرﺳﯽ ﺧﻮاﻫﯿﺪ‬
‫ﮐﺮد‪ .‬اﯾﻦ ﺑﺮرﺳﯽ ﺑﻪ ﻣﻔﻬﻮم ﻧﻈﺎرﺗﯽ از ﺑﺎﻻ ﺑﻪ ﭘﺎﯾﯿﻦ و ﺑﺎ ﻫﺪف ﺧﺮدهﮔﯿﺮی ﻧﯿﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﮐﻤﮑﯽ دوﺳﺘﺎﻧﻪ اﺳﺖ از ﺳﻮی‬

‫— ‪— 76‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻓﺮدی ﮐﻪ ﺷﺎﯾﺪ ﺣﺘﯽ ﻓﻨﯽ ﻫﻢ ﻧﺒﺎﺷﺪ ﺗﺎ ﺑﺎ ﻧﮕﺎﻫﯽ ﺗﺎزه‪ ،‬ﮐﻤﯽ دورﺗﺮ از ﮐﺎر ﺑﻪ آن ﺑﻨﮕﺮد و ﺗﻔﺎوت اﺣﺘﻤﺎﻟﯽ آن را ﺑﺎ آﻧﭽﻪ‬
‫اﻓﺮاد ﻓﻨﯽ در ﻧﻈﺮ داﺷﺘﻪاﻧﺪ ﺑﺴﻨﺠﺪ و ﮐﻤﺒﻮدﻫﺎی اﺣﺘﻤﺎﻟﯽ را ﻣﺸﺨﺺ ﮐﻨﺪ‪.‬‬

‫ﺟﻠﻮﮔﯿﺮی از ﺑﺮوز دﺷﻮاریﻫﺎی ﺑﻨﯿﺎدﯾﻦ در زﻣﺎن ﺗﺤﻮﯾﻞ ﻧﻬﺎﯾﯽ‪ ،‬اﻓﺰاﯾﺶ ﺑﻬﺮهوری ﮐﺎر ﺑﺎ ﻣﺤﺪود ﮐﺮدن ﮐﺎرﻫﺎی ﻣﻮازی‪ ،‬و‬
‫ﺑﺴﯿﺎری دﯾﮕﺮ از ﻋﻨﺎﺻﺮ ﻣﻔﯿﺪ ﭘﺮوژه ﻣﺴﺘﻠﺰم ﺗﻌﯿﯿﻦ ﮔﺴﺘﺮه و ﮐﯿﻔﯿﺖ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﭘﯿﺶ از ﺳﺎﺧﺖ اﺳﺖ‪ .‬ﭘﺮﯾﻨﺲ‪۲‬‬
‫ﺑﺮای اﯾﻦ ﮐﺎر ﺳﻨﺪی ﺑﻪ ﻧﺎم ﺷﺮح ﻣﺤﺼﻮل دارد )»ﻣﺤﺼﻮل« در اﯾﻨﺠﺎ ﺑﻪ ﻣﻌﻨﯽ ﺗﺤﻮﯾﻞﺷﺪﻧﯽ اﺳﺖ( و ‪ P3.express‬اﯾﻦ‬
‫ﻣﺸﺨﺼﺎت را ﺑﻪ ﺷﮑﻞ ﯾﺎدداﺷﺖ در ﻧﻘﺸﻪ ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ ﻟﺤﺎظ ﻣﯽﮐﻨﺪ‪ .‬ﻣﺘﺪوﻟﻮژی ﺧﻮد را ﺑﺮرﺳﯽ ﮐﻨﯿﺪ ﺗﺎ ﺑﺒﯿﻨﯿﺪ ﺑﺮای‬
‫اﯾﻦ ﮐﺎر ﭼﻪ ﻋﻨﺎﺻﺮی در ﻧﻈﺮ ﮔﺮﻓﺘﻪ اﺳﺖ و اﮔﺮ ﺑﺮای ﺷﺮاﯾﻂ ﭘﺮوژه ﮐﺎﻓﯽ ﻧﯿﺴﺖ‪ ،‬آن را اﺿﺎﻓﻪ ﯾﺎ اﺻﻼح ﮐﻨﯿﺪ‪.‬‬

‫ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ ﻣﻌﻤﻮﻻ اﻗﻼم ﮐﺎری را ﺑﺮ روی ﮐﺎرتﻫﺎی ﮐﻮﭼﮏ ﻣﯽﻧﻮﯾﺴﻨﺪ و اﻃﻼﻋﺎت ﺗﮑﻤﯿﻠﯽ درﺑﺎره ﮔﺴﺘﺮه و ﮐﯿﻔﯿﺖ‬
‫را در ﭘﺸﺖ ﮐﺎرت درج ﻣﯽﮐﻨﻨﺪ‪ .‬ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎی ﭘﺮوژهﻫﺎی ﻧﺮماﻓﺰاری ﺑﺴﯿﺎر ﯾﮑﺪﺳﺖﺗﺮ از ﺑﺴﯿﺎری ﭘﺮوژهﻫﺎی دﯾﮕﺮ‬
‫ﻫﺴﺘﻨﺪ و از اﯾﻦ رو ﮐﯿﻔﯿﺖ و ﺳﺎﯾﺮ ﺷﺮاﯾﻂ ﭘﺬﯾﺮﺷﺸﺎن اﺷﺘﺮاکﻫﺎی ﻓﺮاواﻧﯽ دارﻧﺪ‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ‪ ،‬ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ‬
‫ﺑﻪﺟﺎی ﺗﮑﺮار آن ﺷﺮاﯾﻂ ﺑﺮای ﻫﻤﻪ اﻗﻼم‪ ،‬اﺷﺘﺮاکﻫﺎ را ﺟﺪا ﮐﺮده‪ ،‬در ﺳﻨﺪی ﮐﻪ ﻣﯽﺗﻮاﻧﺪ ‪ definition of done‬ﻧﺎﻣﯿﺪه‬
‫ﺷﻮد ذﺧﯿﺮه ﻣﯽﮐﻨﻨﺪ‪ .‬اﯾﻦ ﺗﺮﻓﻨﺪ ﺑﺴﯿﺎر ﮐﺎرآﻣﺪ اﺳﺖ و ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ آن را ﺑﻪ ﻧﻮﻋﯽ در ﭘﺮوژهﻫﺎی ﻏﯿﺮﭼﺎﺑﮏ ﻧﯿﺰ ﺑﻪ ﮐﺎر‬
‫ﺑﺒﺮﯾﺪ؛ ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺷﺎﯾﺪ ﺑﺘﻮاﻧﯿﺪ ﺑﺴﯿﺎری از ﺗﺤﻮﯾﻞﺷﺪﻧﯽﻫﺎ را ﺑﺮ ﭘﺎﯾﻪ ﻫﻤﺎﻧﻨﺪیﻫﺎی اﻟﮕﻮی ﭘﺬﯾﺮﺷﺸﺎن در ﭼﻨﺪ ﮔﺮوه‬
‫ﺗﻘﺴﯿﻢ ﮐﺮده‪ ،‬ﺑﺮای ﻫﺮ ﮔﺮوه اﻟﮕﻮی ﭘﺬﯾﺮش ﻣﺸﺘﺮﮐﯽ ﺗﺪوﯾﻦ ﮐﻨﯿﺪ‪.‬‬

‫‪ . 8 . 4‬ﻋ ﺪ م ﻗ ﻄ ﻌﯿ ﺖ‬

‫ﻋﺪمﻗﻄﻌﯿﺖ ﻣﺒﺎﺣﺚ ﻓﺮاواﻧﯽ دارد‪ ،‬وﻟﯽ ﻣﻬﻢﺗﺮﯾﻦ ﺟﻨﺒﻪ آن در ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ اﺳﺖ‪.‬‬

‫ﻫﻤﺎﻧﮕﻮﻧﻪ ﮐﻪ ﭘﯿﺶﺗﺮ ﺑﻪ آن اﺷﺎره ﺷﺪ‪ ،‬ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﻣﻨﺎﺳﺐ رﯾﺴﮏ ﺑﺎﯾﺪ روﻧﺪی ﮐﺎرا ﺑﺮای ﺷﻨﺎﺳﺎﯾﯽ‪ ،‬ﺗﺤﻠﯿﻞ‪ ،‬و‬
‫ﺑﺮﻧﺎﻣﻪرﯾﺰی واﮐﻨﺶ ﺑﻪ رﯾﺴﮏ داﺷﺘﻪ ﺑﺎﺷﯿﻢ و ﺳﭙﺲ واﮐﻨﺶﻫﺎ را اﺟﺮا ﮐﺮده‪ ،‬اﺛﺮﺑﺨﺸﯽ آنﻫﺎ و ﺳﺎﯾﺮ ﺗﻐﯿﯿﺮﻫﺎی‬
‫اﺣﺘﻤﺎﻟﯽ در وﺿﻌﯿﺖ رﯾﺴﮏ را ﭘﺎﯾﺶ ﮐﻨﯿﻢ‪.‬‬

‫‪ .1.8.4‬ﻣﯿﺰان ﭘﯿﭽﯿﺪﮔﯽ‬

‫ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ را ﺑﺎ ﻣﯿﺰان ﭘﯿﭽﯿﺪﮔﯽ ﻣﺘﻔﺎوﺗﯽ ﻣﯽﺗﻮان ﭘﯿﺎدهﺳﺎزی ﮐﺮد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬در ﺳﯿﺴﺘﻢ ﻣﯿﻨﯿﻤﺎﻟﯿﺴﺘﯽ‬
‫‪ P3.express‬ﯾﮏ ﺳﻨﺪ ﺑﻪ ﻧﺎم ﻓﻬﺮﺳﺖ ﭘﯿﮕﯿﺮی وﺟﻮد دارد ﮐﻪ ﺑﺮای ذﺧﯿﺮهﺳﺎزی اﻃﻼﻋﺎت رﯾﺴﮏﻫﺎ‪ ،‬ﻣﺴﺎﯾﻞ‪،‬‬
‫درﺧﻮاﺳﺖﻫﺎی ﺗﻐﯿﯿﺮ‪ ،‬ﺑﺮﻧﺎﻣﻪﻫﺎی ﺑﻬﺒﻮد‪ ،‬و درس آﻣﻮﺧﺘﻪﻫﺎ ﺑﻪ ﮐﺎر ﻣﯽرود‪ .‬اﯾﻦ روﯾﮑﺮد ﮐﻪ ﺑﺎ روﯾﮑﺮد ﺑﺴﯿﺎری از‬
‫ﻣﺘ ﺪ وﻟ ﻮ ژ ی ﻫ ﺎ ﻣﺘ ﻔ ﺎ و ت ا ﺳ ﺖ ﺑ ﻪ د و دﻟﯿ ﻞ ا ﻧﺘ ﺨ ﺎ ب ﺷ ﺪ ه ا ﺳ ﺖ ‪:‬‬

‫‪ .1‬ﻣﯽﺗﻮان از ﻓﺮآﯾﻨﺪی ﻫﻤﺴﺎن ﺑﺮای ﭘﯿﮕﯿﺮی ﻫﻤﻪ آن ﻣﻮارد اﺳﺘﻔﺎده ﮐﺮد‪ ،‬ﺑﺪون اﯾﻦﮐﻪ وارد ﺟﺰﺋﯿﺎﺗﯽ ﺷﺪ ﮐﻪ واﺑﺴﺘﻪ‬
‫ﺑ ﻪ ﻧ ﻮ ع ا ﻗ ﻼ م ﻗ ﺎ ﺑ ﻞ ﭘ ﯿ ﮕ ﯿ ﺮ ﯾ ﺴ ﺖ‪.‬‬
‫‪ .2‬اﻗﻼم ﻗﺎﺑﻞﭘﯿﮕﯿﺮی ﻧﻮع ﺛﺎﺑﺘﯽ ﻧﺪارﻧﺪ‪ ،‬ﺑﻠﮑﻪ ﻣﻌﻤﻮﻻ از ﻧﻮﻋﯽ ﺑﻪ ﻧﻮع دﯾﮕﺮ ﺗﺒﺪﯾﻞ ﻣﯽﺷﻮﻧﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﯾﮑﯽ از‬
‫اﻗﻼم ﻣﯽﺗﻮاﻧﺪ درﺑﺎره روﯾﺪادی در آﯾﻨﺪه ﭘﺮوژه ﺑﺎﺷﺪ ﮐﻪ رخ دادﻧﺶ ﻗﻄﻌﯽ ﻧﯿﺴﺖ‪ .‬اﯾﻦ ﻗﻠﻢ در زﻣﺎن ﺗﺪوﯾﻨﺶ‬
‫ر ﯾ ﺴ ﮏ ﺑ ﻪ ﺷ ﻤ ﺎ ر ﻣ ﯽ ر و د‪ .‬ﺑ ﺎ ا ﯾ ﻦ ﻫ ﻤ ﻪ ‪ ،‬و ﻗ ﺘ ﯽ ﺟﻠ ﻮ ﺗ ﺮ ﺑ ﺮ و ﯾ ﻢ و و ا ﻗ ﻌ ﺎ ر و ی د ﻫ ﺪ ‪ ،‬ﻫ ﻤ ﺎ ن ﻗﻠ ﻢ ﻧ ﺎ ﮔ ﻬ ﺎ ن ا ز ر ﯾ ﺴ ﮏ ﺗ ﺒ ﺪ ﯾ ﻞ ﺑ ﻪ‬

‫— ‪— 77‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺴﺌﻠﻪ ﻣﯽﺷﻮد‪ .‬وﻗﺘﯽ ﻣﺴﺌﻠﻪ را ﭘﯿﮕﯿﺮی ﮐﻨﯿﻢ و دﯾﺮ ﯾﺎ زود ﺑﺒﻨﺪﯾﻢ‪ ،‬ﺗﺒﺪﯾﻞ ﺑﻪ درس آﻣﻮﺧﺘﻪ ﻣﯽﺷﻮد‪.‬‬

‫ﭼﻨﯿﻦ روﺷﯽ ﺑﺮای ﺑﺴﯿﺎری از ﭘﺮوژهﻫﺎ ﻣﻨﺎﺳﺐﺗﺮ از روشﻫﺎی ﭘﯿﭽﯿﺪه اﺳﺖ‪ ،‬وﻟﯽ‪ ،‬ﭼﻪﺑﺴﺎ در ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﺑﺰرگ‬
‫ﭘﺎﺳﺨﮕﻮ ﻧﺒﺎﺷﺪ و ﻻزم ﺑﺎﺷﺪ درﺟﻪ ﭘﯿﭽﯿﺪﮔﯽ ﺳﯿﺴﺘﻢ را اﻓﺰاﯾﺶ داده‪ ،‬ﺑﺮای ﻫﺮﮐﺪام از اﻧﻮاع اﻗﻼم ﻗﺎﺑﻞﭘﯿﮕﯿﺮی اﺳﻨﺎد و‬
‫ﻓﺮآﯾﻨﺪﻫﺎی ﺟﺪاﮔﺎﻧﻪای ﺑﺴﺎزﯾﺪ‪.‬‬

‫ﭘﺮﯾﻨﺲ‪ ۲‬و ﺑﺴﯿﺎری دﯾﮕﺮ از ﻣﺘﺪوﻟﻮژیﻫﺎ ﺳﻨﺪی ﺑﺎ ﻧﺎم ﻓﻬﺮﺳﺖ رﯾﺴﮏ )‪ (risk register‬ﺑﺮای ذﺧﯿﺮهﺳﺎزی اﻃﻼﻋﺎت‬
‫رﯾﺴﮏﻫﺎ و ﺑﺮﻧﺎﻣﻪﻫﺎی واﮐﻨﺸﯽﺷﺎن دارﻧﺪ‪ .‬اﯾﻦ ﻓﻬﺮﺳﺖ را ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ ﺷﮑﻞ ﺟﺪوﻟﯽ در اﮐﺴﻞ و ﻧﺮماﻓﺰارﻫﺎی ﻣﺸﺎﺑﻪ‬
‫ﺑ ﺴ ﺎ ز ﯾ ﺪ‪.‬‬

‫ﻫﺮ رﯾﺴﮏ ﻣﯽﺗﻮاﻧﺪ ﺑﯿﺶ از ﯾﮏ واﮐﻨﺶ ﺑﺮﻧﺎﻣﻪرﯾﺰیﺷﺪه داﺷﺘﻪ ﺑﺎﺷﺪ و ﻫﺮ واﮐﻨﺶ ﻣﯽﺗﻮاﻧﺪ ﺑﺮای ﺑﯿﺶ از ﯾﮏ رﯾﺴﮏ‬
‫ﺑﻪ ﮐﺎر رود‪ .‬از اﯾﻦ رو‪ ،‬اﮔﺮ ﻣﺎﯾﻞ ﺑﺎﺷﯿﺪ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ ﭘﯿﺸﺮﻓﺘﻪﺗﺮی داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﻣﯽﺗﻮاﻧﯿﺪ اﻃﻼﻋﺎت رﯾﺴﮏ را‬
‫در ﯾﮏ ﺟﺪول و واﮐﻨﺶﻫﺎ را در ﺟﺪول دﯾﮕﺮی ذﺧﯿﺮه ﮐﺮده‪ ،‬ارﺗﺒﺎﻃﯽ ﭼﻨﺪ‪-‬ﺑﻪ‪-‬ﭼﻨﺪ ﻣﯿﺎن آنﻫﺎ اﯾﺠﺎد ﮐﻨﯿﺪ‪.‬‬

‫از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻫﺮ رﯾﺴﮏ ﻧﺘﯿﺠﻪ راﺑﻄﻪای ﻋﻠﯽ اﺳﺖ و ﺗﺤﻠﯿﻞ اﯾﻦ رواﺑﻂ در ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ اﻫﻤﯿﺖ ﻓﺮاواﻧﯽ دارد زﯾﺮا‬
‫ﻋﻠﺘﯽ ﯾﮑﻪ ﻣﯽﺗﻮاﻧﺪ ﺑﯿﺶ از ﯾﮏ ﻣﻌﻠﻮل )رﯾﺴﮏ( داﺷﺘﻪ ﺑﺎﺷﺪ و ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺎ ﻫﺪف ﻗﺮار دادن ﭼﻨﺎن ﻋﻠﺘﯽ ﻣﯽﺗﻮان ﭼﻨﺪﯾﻦ‬
‫رﯾﺴﮏ را ﻫﻢزﻣﺎن ﭘﻮﺷﺶ داد‪ .‬اﻓﺰون ﺑﺮ اﯾﻦﮐﻪ ﯾﮏ ﻋﻠﺖ ﻣﯽﺗﻮاﻧﺪ ﭼﻨﺪ ﻣﻌﻠﻮل داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻫﺮ ﭘﺪﯾﺪهای ﻧﯿﺰ ﻣﯽﺗﻮاﻧﺪ‬
‫ﻣﻌﻠﻮل ﭼﻨﺪ ﻋﻠﺖ ﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ‪ ،‬در ﮔﺎم ﺑﻌﺪی ﻣﯽﺗﻮان ﻋﻠﺖﻫﺎ را ﻫﻢ از ﺟﺪول اﻃﻼﻋﺎت رﯾﺴﮏ ﺟﺪا ﮐﺮده‪ ،‬ارﺗﺒﺎﻃﯽ‬
‫ﭼﻨﺪ ﺑﻪ ﭼﻨﺪ ﻣﯿﺎن آنﻫﺎ ﺑﺮﻗﺮار ﮐﺮد‪ .‬ﯾﮏ ﮔﺎم ﻓﺮاﺗﺮ اﯾﻦ اﺳﺖ ﮐﻪ ﺷﺒﮑﻪ ﻋﻠﯽ را ﺑﻪﺟﺎی دو ﺟﺪول در ﻗﺎﻟﺐ ﯾﮏ ﮔﺮاف‬
‫ﺑﺎزﺳﺎزی ﮐﻨﯿﺪ ﺗﺎ ﺑﻪ واﻗﻌﯿﺖ ﻧﺰدﯾﮏﺗﺮ ﺑﺎﺷﺪ‪.‬‬

‫در ﻋﻤﻞ ﻧﻬﺎﯾﺘﯽ ﺑﺮای اﻓﺰاﯾﺶ ﭘﯿﭽﯿﺪﮔﯽ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ وﺟﻮد ﻧﺪارد و ﻧﻤﯽﺗﻮان ﺣﺪ ﻣﺸﺨﺼﯽ از ﭘﯿﭽﯿﺪﮔﯽ ﻫﻢ‬
‫در ﻧﻈﺮ ﮔﺮﻓﺖ ﮐﻪ ﺑﺮای ﻫﻤﻪ ﭘﺮوژهﻫﺎ ﻣﻨﺎﺳﺐ ﺑﺎﺷﺪ‪ .‬ﺳﯿﺴﺘﻤﯽ ﻣﺎﻧﻨﺪ ‪ P3.express‬ﺣﺪ ﭘﯿﭽﯿﺪﮔﯽ ﺑﺴﯿﺎر ﮐﻤﯽ را ﺑﻪ‬
‫ﭘﺮوژهﻫﺎی ﻣﺨﺎﻃﺐ ﺧﻮد ﭘﯿﺸﻨﻬﺎد ﻣﯽﮐﻨﺪ‪ ،‬ﭘﺮﯾﻨﺲ‪ ۲‬ﺣﺪی ﺑﺎﻻﺗﺮ‪ ،‬ﻣﻨﺎﺑﻊ ﺗﺨﺼﺼﯽ ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ ﻫﻢ ﻣﻌﻤﻮﻻ ﺑﺎﻻﺗﺮ از‬
‫ﻫﻤﻪ‪ .‬ﻣﻄﺎﺑﻖ ﻣﻌﻤﻮل‪ ،‬ﺑﺎﯾﺪ ﺷﺮاﯾﻂ ﭘﺮوژه ﺧﻮد را ﺑﺴﻨﺠﯿﺪ و ﺗﺼﻤﯿﻢ ﺑﮕﯿﺮﯾﺪ ﮐﻪ ﺳﯿﺴﺘﻢ ﭘﯿﺶﻓﺮض ﻣﺘﺪوﻟﻮژﯾﺘﺎن ﺑﺮای‬
‫ﭘﺮوژه ﻣﻨﺎﺳﺐ اﺳﺖ ﯾﺎ ﺑﺎﯾﺪ آن را ﺳﺎدهﺗﺮ ﯾﺎ ﭘﯿﭽﯿﺪهﺗﺮ ﮐﺮد‪ .‬ﻫﺮﮔﺎه در ﭼﻨﯿﻦ ﺗﺼﻤﯿﻢﮔﯿﺮیای دودل ﺑﻮدﯾﺪ‪ ،‬ﮔﺰﯾﻨﻪ ﺳﺎدهﺗﺮ‬
‫را اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪.‬‬

‫‪ .2.8.4‬ﺗﺤﻠﯿﻞ ﮐﻤﯽ‬

‫واﮐﻨﺶﻫﺎﯾﯽ ﮐﻪ ﺑﺮای رﯾﺴﮏﻫﺎ ﻃﺮاﺣﯽ ﻣﯽﮐﻨﯿﺪ ﺑﺎﯾﺪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﺑﺎﺷﻨﺪ‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﺑﻪﮐﺎرﮔﯿﺮی ﻫﺰﯾﻨﻪای ﻣﻌﺎدل ﻫﺰار‬
‫ﭘﯿﺘﺰا در ﻣﺎه ﺑﺮای ﺑﯿﻤﻪ ﮐﺮدن ﭘﺮوژهای ﮐﻪ در ﺑﺮوز ﻣﺸﮑﻞ دﭼﺎر آﺳﯿﺐ ﻣﻌﺎدل ﭼﻨﺪ ﻣﯿﻠﯿﻮن ﭘﯿﺘﺰا ﻣﯽﺷﻮد ﺷﺎﯾﺪ‬
‫ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﺑﺎﺷﺪ‪ ،‬وﻟﯽ اﮔﺮ ﺣﺪاﮐﺜﺮ آﺳﯿﺐ ﻣﻌﺎدل ﭼﻨﺪ ﻫﺰار ﭘﯿﺘﺰا ﺑﺎﺷﺪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮ ﻧﺨﻮاﻫﺪ ﺑﻮد‪.‬‬

‫ﺑﺮرﺳﯽ ﺷﻬﻮدی و ﻣﻮردی واﮐﻨﺶﻫﺎ ﺑﺮای ﺑﯿﺸﺘﺮ ﭘﺮوژهﻫﺎ ﺑﻪاﻧﺪازه و ﻣﻨﺎﺳﺐ اﺳﺖ‪ ،‬وﻟﯽ در ﺑﺮﺧﯽ ﭘﺮوژهﻫﺎی ﺑﺰرگ و‬
‫ﺣﺴﺎس ﺑﺎﯾﺪ از ﻣﺤﺎﺳﺒﺎت ﭘﯿﺸﺮﻓﺘﻪﺗﺮی اﺳﺘﻔﺎده ﮐﺮد‪.‬‬

‫وﻗﺘﯽ ﻧﯿﺎز ﺑﻪ ﻣﻮﺷﮑﺎﻓﯽ ﭘﯿﺸﺮﻓﺘﻪﺗﺮ ﺑﺎﺷﺪ‪ ،‬ﻣﯽﺗﻮان دادهﻫﺎی اﺣﺘﻤﺎﻟﯽ را ﮔﺮدآوری ﮐﺮده‪ ،‬ﺑﺎ روﺷﯽ ﻣﺎﻧﻨﺪ ﻣﻮﻧﺖﮐﺎرﻟﻮ‬
‫ﺑﺮرﺳﯽ ﮐﺮد و ﺑﺎ ﺗﺮﮐﯿﺐ آنﻫﺎ در ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻒ ﺧﺮوﺟﯽﻫﺎی اﺣﺘﻤﺎﻟﯽ را ﻣﺤﺎﺳﺒﻪ ﮐﺮد‪ .‬ﺑﺮای ﻧﻤﻮﻧﻪ‪ ،‬ﭘﺲ از ﺗﺤﻠﯿﻞ‬

‫— ‪— 78‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫وﺿﻌﯿﺖ ﻧﺨﺴﺘﯿﻦ ﭘﺮوژهای ﻣﯽﺑﯿﻨﯿﺪ ﮐﻪ ﺑﻪ اﺣﺘﻤﺎل ‪ ٪۸۵‬در ﺣﺪاﮐﺜﺮ ‪ ۲۲‬ﻣﺎه ﺑﻪ ﭘﺎﯾﺎن ﻣﯽرﺳﺪ‪ .‬ﭘﺲ از اﯾﻦﮐﻪ‬
‫واﮐﻨﺶﻫﺎی رﯾﺴﮏ را ﺑﻪ ﺑﺮﻧﺎﻣﻪ اﺿﺎﻓﻪ ﮐﻨﯿﺪ‪ ،‬ﮐﻪ ﻣﻌﺎدل ‪ ۸۰‬ﻫﺰار ﭘﯿﺘﺰا ﻫﺰﯾﻨﻪ دارﻧﺪ‪ ،‬اﺣﺘﻤﺎل ﭘﺎﯾﺎن ﭘﺮوژه در ‪ ۲۲‬ﻣﺎه ﺑﻪ‬
‫‪ ٪۹۸‬ﻣﯽرﺳﺪ‪ .‬در اﯾﻦ ﻣﺮﺣﻠﻪ ﻣﯽﺗﻮاﻧﯿﺪ ﺗﻮﺟﯿﻪﭘﺬﯾﺮی واﮐﻨﺶﻫﺎ را ﺑﺮ ﭘﺎﯾﻪ اﻫﺪاف و اﺳﺘﺮاﺗﮋیﻫﺎ ﺑﺴﻨﺠﯿﺪ‪.‬‬

‫ﭼﻨﯿﻦ ﺷﮑﻠﯽ از ﺗﺤﻠﯿﻞ ﮐﻤﯽ رﯾﺴﮏ‪ ،‬ﮐﺎری ﭘﯿﭽﯿﺪه و ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ و ﻓﻘﻂ ﺑﺎﯾﺪ در ﭘﺮوژهﻫﺎی ﺑﺰرگ و ﺣﺴﺎس ﺑﻪ ﮐﺎر‬
‫ﺑ ﺮ و د‪.‬‬

‫‪ .3.8.4‬ارﺗﺒﺎط ﺑﺎ ﺳﻄﻮح ﺑﺎﻻﺗﺮ ﺳﺎزﻣﺎن‬

‫ﻫﺮآنﭼﻪ در ﭘﺮوژه اﻧﺠﺎم ﻣﯽدﻫﯿﻢ ﺑﺎﯾﺪ ﺑﺎ ﺳﻄﻮح ﺑﺎﻻﺗﺮ ﺳﺎزﻣﺎن ﻫﻤﺎﻫﻨﮓ و ﻫﻤﺴﻮ ﺑﺎﺷﺪ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬درﺟﻪ ﺣﺴﺎﺳﯿﺖ‬
‫ﮐﺎرﻫﺎی ﻣﺨﺘﻠﻒ ﯾﮑﺴﺎن ﻧﯿﺴﺖ و ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ از ﻣﻮاردﯾﺴﺖ ﮐﻪ ﻧﯿﺎز ﺑﻪ ﻫﻤﺎﻫﻨﮕﯽ ﺑﯿﺸﺘﺮی دارد‪.‬‬

‫ﻣﻬﻢﺗﺮﯾﻦ دﻟﯿﻞ ﺑﺮای ﺣﺴﺎﺳﯿﺖ ﺑﺎﻻی ﻣﺪﯾﺮﯾﺖ رﯾﺴﮏ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺮﺧﯽ از رﯾﺴﮏﻫﺎ ﺑﺮ ﺑﯿﺶ از ﯾﮏ ﭘﺮوژه اﺛﺮ‬
‫ﻣﯽﮔﺬارﻧﺪ و وﻗﺘﯽ اﯾﻦﮔﻮﻧﻪ ﺑﺎﺷﺪ ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ واﮐﻨﺶ ﺑﻪ رﯾﺴﮏ در ﺳﻄﺤﯽ ﺑﺎﻻﺗﺮ از ﭘﺮوژهﻫﺎ و ﺑﺎ روﯾﮑﺮدی ﻫﻤﻪﺟﺎﻧﺒﻪ‬
‫ا ﻧ ﺠ ﺎ م ﺷ ﻮ د‪.‬‬

‫ﻻﯾﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮی ﺳﺎزﻣﺎن ﺑﺎﯾﺪ ﻓﻬﺮﺳﺘﯽ از رﯾﺴﮏﻫﺎﯾﯽ ﮐﻪ ﻣﯿﺎن ﭘﺮوژهﻫﺎ ﻣﺸﺘﺮک ﻫﺴﺘﻨﺪ ﺑﺴﺎزد و ﭘﯿﮕﯿﺮی ﮐﻨﺪ‪.‬‬
‫اﯾﻦ ﻓﻬﺮﺳﺖ ﺑﺎﯾﺪ در اﺧﺘﯿﺎر ﻣﺪﯾﺮان ﭘﺮوژهﻫﺎ ﻧﯿﺰ ﺑﺎﺷﺪ ﺗﺎ در ﭘﺮوژهﻫﺎﯾﺸﺎن ﻟﺤﺎظ ﮐﻨﻨﺪ و اﻃﻼﻋﺎت ﺗﮑﻤﯿﻠﯽ اﺣﺘﻤﺎﻟﯽ را ﺑﻪ‬
‫ﻻﯾﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﺑﻔﺮﺳﺘﻨﺪ‪ .‬از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻣﺪﯾﺮان ﭘﺮوژهﻫﺎ ﻧﯿﺰ ﺑﺎﯾﺪ ﻓﻬﺮﺳﺖ رﯾﺴﮏﻫﺎی ﺧﻮد را در اﺧﺘﯿﺎر ﻻﯾﻪ‬
‫ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﺑﮕﺬارﻧﺪ ﮐﻪ ﭼﻨﺎﻧﭽﻪ رﯾﺴﮏﻫﺎی ﻣﺸﺘﺮک ﺗﺎزهای ﻣﯿﺎن ﭘﺮوژهﻫﺎ ﮐﺸﻒ ﺷﺪ ﻣﺪﯾﺮﯾﺘﺶ ﺑﻪ ﻻﯾﻪ ﺑﺎﻻﺗﺮ‬
‫ﻣ ﻨ ﺘ ﻘ ﻞ ﺷ ﻮ د‪.‬‬

‫ﺑﺴﯿﺎری از ﺳﺎزﻣﺎنﻫﺎ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ ﻧﺪارﻧﺪ‪ .‬اﮔﺮ در ﭼﻨﯿﻦ ﺳﺎزﻣﺎﻧﯽ ﮐﺎر ﮐﻨﯿﺪ ﭼﺎﻟﺶﻫﺎﯾﺘﺎن ﺑﻪ‬
‫ﻧﺒ ﻮ د ر وﻧ ﺪ ﻣﻨﺎ ﺳﺒ ﯽ ﮐ ﻪ د ر اﯾ ﻦ ﺑ ﺨ ﺶ ﺗ ﻮ ﺿﯿ ﺢ دا د ه ﺷ ﺪ ﻣ ﺤ ﺪ و د ﻧ ﺨ ﻮا ﻫ ﺪ ﺷ ﺪ و ﺷﺎﯾ ﺪ ﮐﺎ ر ﭼﻨ ﺪاﻧ ﯽ ﻫ ﻢ ا ز د ﺳﺘﺘﺎ ن ﺳﺎ ﺧﺘ ﻪ‬
‫ﻧﺒﺎﺷﺪ‪ .‬ﺑﺎ اﯾﻦﻫﻤﻪ‪ ،‬ﺑﺮای ﮐﺎﺳﺘﻦ دﺷﻮاریﻫﺎ ﻣﯽﺗﻮاﻧﯿﺪ ﺟﻠﺴﻪﻫﺎی ﻣﺸﺘﺮک ﻣﺎﻫﺎﻧﻪای ﺑﺎ دﯾﮕﺮ ﻣﺪﯾﺮان ﭘﺮوژهﻫﺎ داﺷﺘﻪ‬
‫ﺑﺎﺷﯿﺪ ﺗﺎ درﺑﺎره رﯾﺴﮏﻫﺎی ﭘﺮوژهﻫﺎﯾﺘﺎن ﻫﻤﻔﮑﺮی ﮐﻨﯿﺪ‪ .‬اﯾﻦ ﮐﺎر ﺟﺎی ﺧﺎﻟﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ را ﭘﺮ‬
‫ﻧﺨﻮاﻫﺪ ﮐﺮد‪ ،‬وﻟﯽ ﺑﺎز ﻫﻢ ﮐﻤﮏ ﻓﺮاواﻧﯽ ﺑﻪ ﭘﺮوژهﻫﺎ ﺧﻮاﻫﺪ ﮐﺮد‪ .‬ﻣﯽﺗﻮاﻧﯿﺪ ﻣﺸﺎﺑﻪ ﻫﻤﯿﻦ روﻧﺪ را ﺑﺮای ﺑﻪ‬
‫اﺷﺘﺮاکﮔﺬاﺷﺘﻦ درس آﻣﻮﺧﺘﻪﻫﺎ ﻣﯿﺎن ﭘﺮوژهﻫﺎ ﻧﯿﺰ ﺑﻪ ﮐﺎر ﺑﺒﺮﯾﺪ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻪ ﻣﻌﻨﯽ درﺳﺖ اﻧﺠﺎم دادن ﮐﺎر و ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﺑﻪ ﻣﻌﻨﯽ اﻧﺠﺎم دادن ﮐﺎر‬
‫درﺳﺖ اﺳﺖ‪.‬‬

‫— ‪— 79‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫‪ . 5‬ﮔﺎ م ﺑ ﻌ ﺪ ی‬

‫اﻣﯿﺪوارم از ﻣﻄﺎﻟﻌﻪ اﯾﻦ ﮐﺘﺎب ﻟﺬت ﺑﺮده ﺑﺎﺷﯿﺪ و ﺑﺮاﯾﺘﺎن ﻣﻔﯿﺪ ﺑﻮده ﺑﺎﺷﺪ‪ ،‬ﺑﻪوﯾﮋه ﮐﻪ ﻣﺤﺘﻮای ﮐﺘﺎب ﻣﺘﻤﺮﮐﺰ ﺑﺮ‬
‫ﺟﻨﺒﻪﻫﺎی ﻣﻔﻬﻮﻣﯽ ﭘﻢﺑﺎک ‪ ۷‬اﺳﺖ و ﺗﻨﺎﻇﺮ ﯾﮏﺑﻪﯾﮑﯽ ﺑﺎ ﻣﺤﺘﻮای ﻣﻨﻮآل ﻧﺪارد‪ .‬ﺑﺮای ﺑﺴﯿﺎری از ﻋﻨﺎوﯾﻦ ﭘﻢﺑﺎک ﻋﻨﻮاﻧﯽ‬
‫در اﯾﻦ ﮐﺘﺎب وﺟﻮد ﻧﺪارد‪ ،‬وﻟﯽ ﻧﮕﺮان ﻧﺒﺎﺷﯿﺪ‪ ،‬ﭼﻮن ﺗﻤﺎم ﺟﻨﺒﻪﻫﺎی ﻣﻬﻢ و ﮐﻠﯿﺪی ﺑﻪ ﺷﮑﻞﻫﺎی ﻣﺨﺘﻠﻒ در ﮐﺘﺎب‬
‫ﭘ ﻮ ﺷ ﺶ د ا د ه ﺷ ﺪ ه ا ﻧ ﺪ‪.‬‬

‫ﺑﺴﯿﺎری ﻣﯽﮐﻮﺷﻨﺪ ﺳﯿﺴﺘﻢ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺧﻮد را ﺑﺮ ﭘﺎﯾﻪ ﭘﻢﺑﺎک ﺑﺴﺎزﻧﺪ ﮐﻪ ﮔﺰﯾﻨﻪ ﮐﺎﻣﻼ اﺷﺘﺒﺎﻫﯿﺴﺖ زﯾﺮا ﭘﻢﺑﺎک‬
‫ﻣﺘﺪوﻟﻮژی ﻧﯿﺴﺖ‪ .‬از اﯾﻦ رو ﺗﻤﺮﮐﺰ اﯾﻦ ﮐﺘﺎب ﺑﺮ روﺷﻦ ﮐﺮدن اﯾﻦ ﺗﻤﺎﯾﺰ و ﺗﻮﺿﯿﺢ دادن رﺳﺎﻟﺖ واﻗﻌﯽ ﭘﻢﺑﺎک ﺑﻮد‪.‬‬

‫از ﭘﻢﺑﺎک ﺑﻪ دو ﺷﮑﻞ ﻣﯽﺗﻮاﻧﯿﺪ در ﭘﺮوژهﻫﺎی ﺧﻮد ﮐﻤﮏ ﺑﮕﯿﺮﯾﺪ‪:‬‬

‫اﺻﻞﻫﺎ ﺑﻪ ﺷﻤﺎ ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ ﮐﻪ درک درﺳﺖﺗﺮ و ﮐﺎرآﻣﺪﺗﺮی از ﺟﻨﺒﻪﻫﺎی ﻣﺨﺘﻠﻒ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﺑﻪ دﺳﺖ‬
‫آ و ر ﯾ ﺪ‪.‬‬
‫ﺣﻮزهﻫﺎی ﻋﻤﻠﮑﺮدی ﺑﻪ ﺷﻤﺎ ﮐﻤﮏ ﻣﯽﮐﻨﻨﺪ ﮐﻪ ﻣﺘﺪوﻟﻮژیای ﮐﻪ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﻧﺘﺨﺎب ﮐﺮدهاﯾﺪ را ﺗﻘﻮﯾﺖ‬
‫ﮐ ﻨ ﯿ ﺪ‪.‬‬

‫از اﯾﻦ رو ﻻزم ﺑﻮد ﮐﻪ ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را ﻫﻢ اﻧﺪﮐﯽ ﺑﺮرﺳﯽ ﮐﻨﯿﻢ ﮐﻪ ﻣﻮﺿﻮع ﯾﮑﯽ از ﻓﺼﻞﻫﺎی ﮐﺘﺎب ﺑﻮد‪.‬‬

‫اﮔﺮ ﻋﻼﻗﻪﻣﻨﺪ ﺑﻪ ﯾﺎدﮔﯿﺮی ﺑﯿﺸﺘﺮ در اﯾﻦ ﺣﻮزهﻫﺎ ﺑﺎﺷﯿﺪ ﻣﯽﺗﻮاﻧﻢ ﻣﻮارد زﯾﺮ را ﭘﯿﺸﻨﻬﺎد ﮐﻨﻢ‪:‬‬

‫راﻫﻨﻤﺎﻫﺎی ﺳﺎﺧﺖﯾﺎﻓﺘﻪ‬
‫ﻣﻨﻮآل ‪ :PMBOK Guide‬ﯾﮑﯽ از اﻣﺘﯿﺎزﻫﺎﯾﯽ ﮐﻪ ﺑﺎ ﭘﺮداﺧﺖ ﺣﻖ ﻋﻀﻮﯾﺖ در ‪ PMI‬ﺑﻪ دﺳﺖ ﻣﯽآورﯾﺪ اﻣﮑﺎن‬
‫داﻧﻠﻮد راﯾﮕﺎن ﻫﻤﻪ ﮐﺘﺎبﻫﺎی ‪ PMI‬اﺳﺖ‪.‬‬
‫ﮐﺘﺎب ‪ :Process Groups: A Practice Guide‬اﮔﺮ ﻋﻼﻗﻪﻣﻨﺪ ﺑﻪ ﯾﺎدﮔﯿﺮی ﻓﺮآﯾﻨﺪﻫﺎی ‪ ، PMI‬ﮐﻪ ﻣﺤﺘﻮای‬
‫اﺻﻠﯽ وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ ﭘﻢﺑﺎک ﺑﻮدﻧﺪ ﺑﺎﺷﯿﺪ‪ ،‬ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ اﯾﻦ ﮐﺘﺎب ﺗﺎزه ‪ PMI‬ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬
‫ﻣﻨﻮآل ‪ :Open PM²‬ﻣﺎﻧﻨﺪ ﭘﻢﺑﺎک‪ PM² ،‬ﻫﻢ راﻫﻨﻤﺎﯾﯽ ﺑﺮای ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ ﮐﻪ ﻣﯽﺗﻮاﻧﺪ ﺑﺎ زاوﯾﻪ دﯾﺪی‬
‫ﮐﻤﺎﺑﯿﺶ ﻣﺘﻔﺎوت ﺑﻪ ﺷﻤﺎ ﮐﻤﮏ ﮐﻨﺪ‪ PM² .‬ﻣﺘﻌﻠﻖ ﺑﻪ ﮐﻤﯿﺴﯿﻮن اروﭘﺎﺳﺖ و ﻣﯽﺗﻮاﻧﯿﺪ آن را ﺑﻪراﯾﮕﺎن از‬
‫ﺳﺎﯾﺖ ﮐﻤﯿﺴﯿﻮن )‪ ( https://op.europa.eu‬داﻧﻠﻮد ﮐﻨﯿﺪ‪.‬‬
‫ﻣﻨﻮآل ‪ :APMbok‬اﯾﻦ ﻣﻨﺒﻊ ﺑﯿﺸﺘﺮ در اﻧﮕﻠﺴﺘﺎن اﺳﺘﻔﺎده ﻣﯽﺷﻮد و ﺳﺎﺧﺘﺎری ﮐﻤﺎﺑﯿﺶ ﻫﻤﺎﻧﻨﺪ‬
‫وﯾﺮاﯾﺶﻫﺎی ﭘﯿﺸﯿﻦ ﭘﻢﺑﺎک دارد‪ ،‬وﻟﯽ ﺟﻨﺒﻪﻫﺎی وﯾﮋهای ﻧﯿﺰ دارد ﮐﻪ ﺷﺎﯾﺪ راﻫﮕﺸﺎ ﺑﺎﺷﺪ‪.‬‬
‫راﻫﻨﻤﺎی ‪ :NUPP‬ﻣﺠﻤﻮﻋﻪ اﺻﻞﻫﺎی ‪ NUPP‬آزاد و راﯾﮕﺎن ﻫﺴﺘﻨﺪ و ﻣﯽﺗﻮاﻧﯿﺪ آن را ﺑﻪ زﺑﺎنﻫﺎی ﻣﺨﺘﻠﻒ‪،‬‬
‫ازﺟﻤﻠﻪ ﻓﺎرﺳﯽ‪ ،‬از ‪ https://nupp.guide‬درﯾﺎﻓﺖ ﮐﻨﯿﺪ‪.‬‬
‫ﻣﺘ ﺪ وﻟ ﻮ ژ ی ﻫ ﺎ‬
‫ﻣﻨﻮآل ‪ :PRINCE2‬ﭘﺮﯾﻨﺲ‪ ۲‬ﯾﮑﯽ از ﺑﻬﺘﺮﯾﻦ ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه اﺳﺖ‪ .‬اﮔﺮ ﻣﻨﻮآل رﺳﻤﯽ ﺑﻪ‬
‫ﻧﻈﺮﺗﺎن ﭘﯿﭽﯿﺪه ﺑﺎﺷﺪ ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪﺟﺎﯾﺶ ﯾﮑﯽ از ﮐﺘﺎبﻫﺎی راﻫﻨﻤﺎﯾﯽ ﮐﻪ درﺑﺎره آن ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ را‬
‫ﻣ ﻄ ﺎﻟ ﻌ ﻪ ﮐ ﻨ ﯿ ﺪ‪.‬‬
‫ﻣﻨﻮآل ‪ :P3.express‬اﯾﻦ ﻣﺘﺪوﻟﻮژی آزاد و ﻣﯿﻨﯿﻤﺎﻟﯿﺴﺘﯽ اﺳﺖ و ﺑﻨﺎﺑﺮاﯾﻦ اﺳﺘﻔﺎده از آن ﺳﺎدهﺗﺮ از‬

‫— ‪— 80‬‬
 ‫راﻫﻨﻤﺎی ﻣﻔﻬﻮﻣﯽ ‪PMBOK 7‬‬

‫ﻣﺘﺪوﻟﻮژیﻫﺎی دﯾﮕﺮ‪ .‬ﻣﻨﻮآل آن ﺑﻪراﯾﮕﺎن در ‪ https://p3.express‬ﺑﻪ زﺑﺎنﻫﺎی ﮔﻮﻧﺎﮔﻮن‪ ،‬ازﺟﻤﻠﻪ ﻓﺎرﺳﯽ‪،‬‬

‫ﻣ ﻮ ﺟ ﻮ د ا ﺳ ﺖ‪.‬‬
‫ﻣﻨﻮآل ‪ :micro.P3.express‬وﯾﺮاﯾﺶ اﺻﻠﯽ ‪ P3.express‬ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺎ اﻧﺪازه ﻣﻌﻤﻮل ﻃﺮاﺣﯽ ﺷﺪه‬
‫اﺳﺖ و ﻧﻪ ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﺑﺰرگ ﯾﺎ ﺑﺴﯿﺎر ﮐﻮﭼﮏ‪ .‬ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺴﯿﺎر ﮐﻮﭼﮏ ﮔﺰﯾﻨﻪ ﺳﺎدهﺗﺮی ﺑﻪ ﻧﺎم‬
‫‪ micro.P3.express‬وﺟﻮد دارد‪.‬‬
‫ﻣﻨﻮآل ‪ :DSDM‬ﻣﺘﺪوﻟﻮژی ‪ DSDM‬ﯾﮑﯽ از روشﻫﺎی ﭼﺎﺑﮏ ﻧﺴﻞ ﻧﺨﺴﺖ اﺳﺖ ﮐﻪ ﺑﺮای ﭘﺮوژهﻫﺎی ﺑﺰرگ‬
‫ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ‪ .‬وﯾﺮاﯾﺶ آﻧﻼﯾﻦ ﻣﻨﻮآل ﺑﻪراﯾﮕﺎن در ‪ https://www.agilebusiness.org‬در دﺳﺘﺮس‬
‫ا ﺳ ﺖ‪.‬‬
‫راﻫﻨﻤﺎی ‪ :Scrum‬اﺳﮑﺮام روﺷﯽ ﺳﺎده و ﻣﯿﻨﯿﻤﺎﻟﯿﺴﺘﯽ ﺑﺮای اﺟﺮای ﭘﺮوژهﻫﺎی ﭼﺎﺑﮏ اﺳﺖ ﮐﻪ اﻟﺒﺘﻪ ﻫﻤﻪ‬
‫ﺟﻨﺒﻪﻫﺎی ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه را درﺑﺮﻧﻤﯽﮔﯿﺮد‪ .‬راﻫﻨﻤﺎی رﺳﻤﯽ آن ﺑﻪ زﺑﺎنﻫﺎی ﻣﺨﺘﻠﻒ‪ ،‬ازﺟﻤﻠﻪ ﻓﺎرﺳﯽ‪ ،‬در‬
‫‪ https://scrumguides.org‬در دﺳﺘﺮس اﺳﺖ‪ .‬اﻟﺒﺘﻪ اﯾﻦ راﻫﻨﻤﺎ ﺑﺴﯿﺎر ﺧﻼﺻﻪ اﺳﺖ و ﺷﺎﯾﺪ ﺑﻬﺘﺮ ﺑﺎﺷﺪ‬
‫ﮐﻪ ﺑﻪﺟﺎی آن ﺑﻪ ﯾﮑﯽ از ﮐﺘﺎبﻫﺎﯾﯽ ﮐﻪ درﺑﺎره اﺳﮑﺮام ﻣﻨﺘﺸﺮ ﺷﺪه اﺳﺖ ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬
‫راﻫﻨﻤﺎﻫﺎی ﺗﺨﺼﺼﯽ‬
‫ﻣﻬﺎرتﻫﺎی رﻓﺘﺎری و اﻧﺴﺎﻧﯽ‪ :‬ﮐﺘﺎبﻫﺎی ﻓﺮاواﻧﯽ درﺑﺎره اﻧﺪﯾﺸﻪ اﻧﺘﻘﺎدی‪ ،‬رﻫﺒﺮی‪ ،‬اﯾﺠﺎد اﻧﮕﯿﺰه‪ ،‬ﻣﺬاﮐﺮه‪،‬‬
‫رﻓﻊ اﺧﺘﻼف و ﻫﻤﺎﻧﻨﺪ آن وﺟﻮد دارد‪ .‬ﺑﯽﮔﻤﺎن ﺑﺮ ﯾﺎدﮔﯿﺮی اﯾﻦ ﻣﻬﺎرتﻫﺎ ﺳﺮﻣﺎﯾﻪﮔﺬاری ﮐﻨﯿﺪ‪.‬‬
‫ﻣﻬﺎرتﻫﺎی ﻓﻨﯽ‪ :‬ﺑﺴﺘﻪ ﺑﻪ ﻧﻮع ﭘﺮوژه ﺷﺎﯾﺪ ﻧﯿﺎز ﺑﻪ ﻣﻬﺎرتﻫﺎی ﻓﻨﯽ ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه‪ ،‬ﻣﺎﻧﻨﺪ زﻣﺎنﺑﻨﺪی و‬
‫ﺗﺤﻠﯿﻞ رﯾﺴﮏ ﻧﯿﺰ داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪ .‬ﺑﺮای ﻫﺮﮐﺪام از اﯾﻦ ﻣﻮارد ﻫﻢ اﺳﺘﺎﻧﺪارد و ﻫﻢ ﮐﺘﺎبﻫﺎی ﻓﺮاواﻧﯽ وﺟﻮد‬
‫دارد‪.‬‬

‫در ﭘﺎﯾﺎن اﯾﻦﮐﻪ ﺑﺮای ﮐﺴﺎﻧﯽ ﮐﻪ در ﺣﻮزه ﻣﺪﯾﺮﯾﺖ ﭘﺮوژه ﻓﻌﺎﻟﯿﺖ ﻣﯽﮐﻨﻨﺪ‪ ،‬ﯾﺎدﮔﯿﺮی ﻣﺪﯾﺮﯾﺖ ﭘﺮﺗﻔﻮﻟﯿﻮ ﻧﯿﺰ ﺳﻮدﻣﻨﺪ‬
‫ﺧ ﻮ ا ﻫ ﺪ ﺑ ﻮ د‪.‬‬

‫ﭘ ﯿ ﺮ و ز ﺑ ﺎ ﺷ ﯿ ﺪ!‬

‫— ‪— 81‬‬