در دهه‌های گذشته و در کشورهای مختلف دنیا، پروژه‌های زیادی با مالکیت‌های گوناگون،‌ حیطه زمانی متفاوت و با بکار بردن حجم‌های مختلفی از منابع مالی اجرا شده است. اجرا و تکمیل پروژه‌ها، تلاش زیاد و قابلیت‌های فنی و تخصصی مدیران پروژه را می‌طلبیده است. کاربرد کامپیوترهای شخصی (PC) ابعاد دیگری از استفاده ابزار موثر در روند مدیریت پروژه بوده است. این نوشته بر این امر تاکید دارد که طراحی صحیح و کاربرد ساختار شکست کار WORK BREAKDOWN STRURE)WBS)  نظام کدینگ و استفاده از واژه‌های مشخص، مبنای موثری برای کنترل نظام های پروژه، خط‌مشی‌ها و روش‌ها برای کلیه پروژه‌ها است. ساختار شکست کار به سازماندهی و برنامه‌ریزی کلیه مراحل پروژه کمک می‌کند. مدیریت پروژه و کلیه افرادی که در اجرای عملیات و مدیریت و کنترل درگیر هستند، در مراحل مختلف اجرای کار به اطلاعات دقیق و مفید نیاز دارند. یک ساختار شکست کار خوب طراحی شده، مبنایی برای تنظیم مناسب سیستم اطلاعاتی برای کنترل پروژه در اجرای عملیات را فراهم می‌کند.

تعریف ساختار شکست کار

ساختار شکست کار را می‌توان بدین ترتیب تعریف کرد:

یک ساختار شبکه‌ای یا درختی به صورت گرافیکی است برای نشان دادن روش تولید محصول یا خدمت شامل بخش‌های سخت‌افزار، نرم‌افزار، خدمات و سایر وظایفی که یک سازمان یا شرکت انجام می‌دهد مانند کارهایی که باید انجام شود تا یک محصول یا خدمت مشخص تولید و یا ارایه شود.

در این تعریف منظور از «کارهایی که باید انجام شود» انجام و اتمام یک پروژه با بودجه و زمان مشخص است. تدوین ساختار شکست کار به عنوان یک نظام کاری، برای اطمینان از مشارکت‌کنندگان در اجرای پروژه، اعم از کارفرما، پیمانکاران/فروشندگان است که همگی بدانند چه عملیاتی برای تکمیل پروژه مورد نیاز است.

استفاده از ساختار شکست کار به عنوان یک شالوده اطلاعاتی، برقراری ارتباط صحیح در باره پروژه را برای گروههای کاری و سازمانهای حکومتی ناظر بر پروژه و سایر فرآیندهای قانونی، از طریق کاربرد یک مبنای مشترک، تسهیل می‌کند.

توضیحات بیشتر را در ادامه مطلب مطالعه فرمایید.

|+| نوشته شده توسط شهاب احمدی در پنجشنبه 22 مرداد1388 و ساعت 8:35  

1- در هر شرایطی ، تمركز خویش را بر سه ركن موفقیت پروژه ( كیفیت ، هزینه و زمان) از دست ندهید !
پیروزی در پروژه بستگی ‌به برقراری تعادل مناسبی بین سه ‌عامل مهم زمان انجام ‌كار ، منابع مورد استفاده و نتایج‌ كار در راستای ارائه‌ سطح‌ مناسبی از خدمات به ‌مشتری دارد . پروژه در خدمت رضایتمندی مشتری است ، بنابراین سه ‌عامل مهم موردنظر او باید در نظر گرفته‌شده و تعادل مناسبی بین آنها برقرار شود . او علاقه‌ دارد پروژه‌اش در موعد مقرر به‌ پایان ‌رسد ،‌ نتایج مشخصات درخواستی را رعایت‌ كنند و دقیقا آنچه باشد كه او می‌خواسته و در آخر اینكه پروژه قیمت ‌تمام‌شده‌ مناسبی داشته‌ باشد ، آنچه كه قبلا بر آن توافق‌ شده و بودجه‌ معینی برایش تخصیص ‌داده ‌شده ‌است . سه ‌مورد فوق بیانگر سه‌ عامل اساسی زمان ، كیفیت و هزینه هستند كه بین آنها تعادلی برقرار است و بیش از هر عضوی ، این وظیفه مدیر پروژه است كه تعادل مابین این اهداف و نیز ، تمركز تیم اجرایی را بر این اهداف مهم حفظ نماید . 

2- از خاطر نبرید كه برنامه‌ریزی همه چیز یك پروژه است و در عین حال ، لازم‌التغییر .

شاید این عنوان در برجسته نمودن اهمیت برنامه‌ریزی پروژه ، كمی اغراق‌آمیز به نظر آید ؛ لیكن باید دانست كه اغلب متون ، مقالات و كتب منتشره در حوزه مدیریت پروژه بر این حقیقت متفق‌القول بوده‌اند كه برنامه‌ریزی مهمترین فعالیتی است كه بر دوش مدیریت پروژه نهاده شده و بی‌تردید ، برخورداری از یك برنامه روشن با جزئیات مشخص كه در آن به اصول و قواعد برنامه‌ریزی پروژه توجه كافی مبذول گردیده باشد و در عین حال تمامی اركان پروژه را تحت پوشش خود قرار دهد ، ركن اساسی در موفقیت آتی پروژه است .
از سوی دگر ، در عمل و به هنگام پیاده‌سازی مراحل برنامه‌ریزی شده ، همواره رخدادهایی حادث می‌شوند كه ضرورت ایجاد تغییرات در برنامه پروژه را موجب می‌گردند ؛ در اینگونه موارد مدیریت پروژه باید تغییرات لازم را در برنامه ایجاد نماید تا قدرت و كارایی آن در جهت نیل به اهداف پروژه حفظ گردد ؛ از اینروست كه برنامه‌ریزی و برنامه‌ریزی مجدد جزئی چشمگیر از زندگی انسانیست كه در مقام مدیریت پروژه قرار گرفته است .

دیگر نکات را در ادامه مطلب ملاحظه فرمایید

|+| نوشته شده توسط شهاب احمدی در چهارشنبه 13 خرداد1388 و ساعت 8:10  

مقدمه 

همیشه نباید یك سند داشته باشیم !

منشور پروژه همیشه نباید در یك سند گنجانده شود. در ایده‌آل‌ترین حالت، یك سند حداکثر، اجازه انجام كار را صادر كرده و مراجع و منابع را با استفاده از اسناد و مدارك موجود مشخص می­کند كه نشان‌دهنده نیازها و الزامات کسب و کار، زمان‌بندی وقایع مهم و دیگر اطلاعات كلیدی است.

در غالب شركتهایی كه كار پروژه را از طرف مشتری انجام می‌دهند، دستور انجام كار می‌تواند به عنوان جزئی كلیدی از منشور پروژه، ایفای نقش كند. این دستور در این شركتها، مجوز استفاده از منابع سازمانی را به افراد مشخصی اعطا می‌كند. امضای مشتری در پای سند، اجازه و اختیار را از طرف مشتری به شرکت مشاور منتقل می‌كند و امضای مقابل از طرف مسئول یا گروه مشاوره نیز اجرای توافق‌نامه را برای مشاور الزام‌آور می‌سازد.

حامیان پروژه‌ها معمولا مدیران اجرایی ارشد هستند که اوقات آزاد آنان كم و محدود است. به همین دلیل، انتظار نگارش و ارائه منشور كامل پروژه از طرف آنان، حتی در سازمانی پروژه‌محور، شاید غیرمعقول و ناممكن باشد. مدیران اجرایی ارشد معمولا هنگام تنظیم پیامهای مهم، از تندنویس یا كسانی كه توانایی مكتوب كردن سخنان را دارند، استفاده می‌كنند. مدیر پروژه باید خود را برای ایفای این نقش، یعنی تنظیم پیش‌نویس و حتی نسخه نهایی منشور آماده كند.

نوشتن منشور توسط حامیان پروژه، به خصوص برای پروژه‌هایی كه حامیان آن را كمیته یا مجموعه‌ای از افراد تشکیل می‌دهند، غیرعملی است. نوعا در این شرایط، مدیر پروژه یا یكی از حامیان به نوشتن سند اقدام كرده و دیگران آن را تایید می‌كنند.

نگارش منشور

به منظور انتشار منشور در ابتدایی‌ترین نقطه پروژه، نویسنده منشور باید آن را تنها بر اساس بخشی از اطلاعاتی که در همان ابتدا در دسترس دارد، تهیه كند. راهنمای PMBOK، گنجاندن «نیازها و الزامات»، «‌زمان‌بندی»، و «بودجه» را در منشور توصیه کرده است، اما ارائه اطلاعات دقیق از هركدام از این اطلاعات در آغاز پروژه غیرممكن خواهد بود. در اینجا باید منشور را بر اساس اطلاعات محدود و موجودی که در دسترس است، آماده كرد.

در مقایسه با تجزیه و تحلیل دقیق نیازها و الزامات، منشور ضرورتا توضیح بسیار كمتری ارائه خواهد داد. به طور مشخص، مدیران پروژه‌های فناوری اطلاعات از برداشتهای اشتباه در مورد اصطلاح «نیازها و الزامات» رنج می‌برند. شكایات بسیاری مبنی بر پایین بودن كیفیت پروژه‌های IT در هنگام تحویل وجود داشته است، بنابراین متخصصان طراحی نرم‌افزار به متخصصان IT اصرار می‌كنند كه قبل از انجام هرگونه طراحی یا برنامه‌نویسی، نیازها و الزامات را به طور كامل و دقیق درك كنند. مدیران پروژهIT نباید از این توصیه به عنوان توجیهی برای اجتناب از مستندسازی سریع شرایط و نیازمندیهای کسب‌وکار استفاده كنند. یک منشور خوب می‌تواند شامل اطلاعات با اهمیت و سطح بالایی درباره نیازها و الزامات باشد. اطلاعاتی که به واقع می‌توانند در هدایت و تعیین مسیر تمركز در مرحله تنظیم دقیق نیازها و الزامات، نقش موثری ایفا نمایند.
احتمال دارد كه نیازها و الزامات پروژه كاملا ناشناخته بوده و تنظیم منشور برای تمامی ابعاد آن غیرممكن باشد. همیشه امكان دارد كه برای اولین مرحله پروژه، تنها برخی از نیازهای كسب و کار تعریف شده باشد. مراحل بعدی پروژه می‌توانند نیازها و الزامات ملموستر و مشخصتر پروژه را شناسایی كرده و منشور پروژه را اصلاح كنند.

منشورهای جزئی برای پروژه

منشور در مرحله آغاز پروژه و قبل از تعیین منابع اصلی تنظیم می‌شود. منشور اولیه پروژه نوعا باید كوتاه، شاید در حد چند صفحه باشد. تا زمانی كه مفهوم اصلی این منشورها تایید واضح و صریح صلاحیت پروژه و مدیر پروژه باشد، می‌توانند حتی كمتر از یك صفحه نیز باشند.

اسناد طولانی‌تر و دارای ساختار منظم، معمولا برای موفقیت سازمان و پروژه اساسی هستند. این اسناد جایگزین منشورهای كوتاه اولیه می شوند و به عنوان سند اصلی و راهنمای گروه پروژه عمل می‌كنند. این سیر تکاملی طبیعی است و باید مورد تشویق قرار بگیرد.

چه زمانی حامی باید منشور مجدد پروژه را صادر نماید ؟

در پروژه های دیگری كه دارای مدیران فرعی یا گروههای رهبری جداگانه نیستند، در آغاز یا پایان هر یك از مراحل پروژه، حامی ممكن است بخواهد در منشور پروژه تجدید نظر و یا منشور جدیدی را با مجوزهای جدید صادر و تأیید كند. این زمان فرصتهای مناسبی برای بازبینی منشور در اختیار حامی قرار می‌دهد.

منشور اولیه ممكن است دارای چشم‌انداز یا تعریف محدودی باشد. شكل منشورهای بروز شده پروژه ممكن است با منشور اولیه پروژه تفاوت زیادی داشته باشند. آنها ممكن است حاوی طرحهای دقیق و جزئی‌تری از كار، بودجه‌ها، فهرست مشخص اجزای قابل عرضه و موارد دیگر باشند. این منشورهای بروزشده ممكن است دارای صفحات بسیاری بوده و شامل تمام عناصر طرح جزئی پروژه باشند. گاهی اوقات تنظیم طرح و برنامه‌ریزی برای گام بعدی پروژه، یكی از اجزای نهایی قابل عرضه در مرحله­ای از پروژه محسوب می‌شود.

رابطه منشور پروژه و استراتژی سازمانی

منشور پروژه یكی از ایده­آل­ترین ابزارها برای بررسی نقادانه همسویی یا ناهمسویی پروژه با استراتژی سازمانی و میزان حمایت پروژه از این استراتژی است. اگر پروژه واقعا با استراتژی سازمانی همراستا نباشد، منشور بهترین فرصت برای متوقف كردن پروژه قبل از اتلاف منابع خواهد بود. اگر مدیران پروژه همواره پروژه‌های ناهماهنگ را قبل از شروع متوقف می‌كردند، امروز با پروژه‌های شكست‌خورده بسیار كمتری مواجه بودیم.

منشور كوتاه است اما باید حاوی نیازها و الزامات و اهداف کسب و کار باشد. یعنی در منشور، جزئیات اجرایی هنوزکاملا تعریف نشده‌اند. استراتژی سازمانی نیز دقیقا در این سطح عمل می‌كند: مشخص کردن نیازها و الزامات و اهداف کسب و کار، بدون جزئیات اجرایی.

افراد می‌توانند به سرعت منشور پروژه را با مسیرحرکت، طرح کسب وکار و یا سند مربوط به استراتژی مقایسه و تعیین كنند كه آنها باهم سازگار و هماهنگ هستند یا نه. منشور، قصد و هدف کسب و کار را به صورت خالص و محض بیان می‌كند. پیش‌نویس كردن منشور، فرصتی استثنایی برای هم‌راستا كردن کامل پروژه با اهداف كلی کسب و کار است.

شروع كار سازمان با منشورها

برخی از مسؤولان اجرایی پروژه‌ها بدون بررسی دقیق و درك از روند و فرایند انتخاب پروژه، دستور به آغاز آن می دهند و این موضوع باعث شكایت برخی مدیران پروژه از این امر می شود. آنها می‌خواهند كه این مسئولان اجرایی، قبل از شروع كار این پروژه‌ها، با مدیران پروژه برای آگاه شدن از نظر آنها و انجام درست كار مذاکره كنند.

حقیقت این است كه این مسئولان اجرایی با مدیران پروژه مذاکره می‌كنند. آنها زمانی با مدیران پروژه مذاکره می‌كنند كه می‌خواهند وظایف را تعیین كنند و یا منشور پروژه را ارائه دهند. بسیاری از مدیران پروژه، آمادگی بهره‌برداری از این فرصت کوتاه را برای مشارکت در استراتژی سازمانی ندارند.
مدیر پروژه باید در زمان واگذاری پروژه، بدون اتلاف وقت، سؤالاتی بنیادی را مطرح کند. اگر رابطه پروژه با استراتژی سازمانی نامشخص باشد، زمان پرسیدن این سؤالات در طول انجام كار خواهد بود. اگر این رابطه مشخص باشد، منشور وسیله‌ای برای مستندسازی دقیق و روشن فرضیات و گرفتن تایید حامی مبنی بر درست بودن آنها خواهد بود. اگر زمانی كه مدیر پروژه تعیین می‌شود، پروژه در حال انجام باشد، تایید مجدد منشور موجود یا نوشتن نسخه‌ای جدید از آن، راهی فوق‌العاده برای مدیر جدید پروژه به منظور جا انداختن و باورپذیر كردن موقعیت خود خواهد بود.

مدیر پروژه به عنوان مؤلف یا نگارنده منشور

سپردن تالیف منشور به فردی دیگر، در واقع سپردن پیشرفت، بازاریابی و مسیر پروژه به آن فرد است. بهترین حامیان می‌توانند بخوبی از عهده ایفای این نقشها بر‌آیند، اما همه آن‌ها این توانایی را دارا نیستند. بسیاری از مدیران پروژه به این دلیل دچار سرخوردگی و ناامیدی می‌شوند كه حامی پروژه آنها، منشور را به صورت شفاف تنظیم نمی‌کند.

در برخی موارد، ممکن است حامی پروژه نتواند یا نخواهد پیش‌نویس منشور را تایید كند. حامیان پروژه ممكن است خواستار تغییرات پی در پی باشند، یا این كه با تایید منشور مخالفت كنند. تمایل نداشتن برای تایید سند نشانه درك اشتباه ، نبود پشتیبانی و یا حتی مواردی بدتر از اینهاست. مدیر حرفه‌ای پروژه باید تا زمان حل شدن مشكل، كار را متوقف كند. ادامه پروژه بدون هیچگونه تفویض اختیار یا تعریفی مشخص از کار، به فاجعه ختم می‌شود.

برای درك مناسب‌تر موضوع، یك نمونه منشور پروژه كه با توجه به طبیعت و نیازمندیهای موجود در كشورمان تهیه شده است، ارائه می‌شود. این نمونه در دو قسمت تنظیم و ارائه شده است. قسمت اول نگاهی اجمالی به كل پروژه و تعریف و واژگان كلیدی می اندازد و قسمت دوم راهكارهای رسیدن به اهداف كلیدی پروژه را مطرح می‌كند. لازم به ذكر است كه در ارائه این نمونه، به دلیل رعایت اختصار، تنها به ذكر عنوان وار محتویات بسنده شده است :

بخش اول – اطلاعات كلی و شرح اجمالی از پروژه

الف – تاریخچه

ب – تعریف منشور پروژه در این سند

پ – تعریف پروژه (عقد قرارداد) و جایگاه آن

ت – ذی‌نفعان پروژه شامل سفارش دهنده و مشتریان اصلی، حامی و وظایف او و مدیر پروژه.

ث – هدف اصلی پروژه

ج – محدوده پروژه

چ – نیازها، الزامات و معیارهای پذیرش سفارش دهنده پروژه

ح – موارد مبهم برای عقد قرارداد

خ – نقشها و مسئولیتها

بخش دوم – راهكارهای دست‌یابی به اهداف پروژه

الف – سازماندهی تیم پروژه

ب – تهیه و تصویب نمودار سازمانی تیم عقد قرارداد

پ – روشها و راهكارهای ویژه این پروژه

ت – وابستگیها

ث – برنامه های پشتیبانی

ج – مدیریت ریسك (ماتریس شناسایی ریسك و اقدامات لازم برای پوشش ریسك‌ها)

چ – زمان

ح – هزینه ها و جریان نقدی پروژه.

|+| نوشته شده توسط شهاب احمدی در دوشنبه 11 آذر1387 و ساعت 6:57  

مقدمه :

صرفنظر از اینكه شما به عنوان یك مدیر پروژه[Project Manger] ، از چه میزان تجربه و پیشینه كاری برخوردار هستید ، پروژه‌ها توانمندی شما در بكارگیری دانش ، هنر و همچنین هر اندازه زیركی بالقوه‌ - برای پیشبرد امور - كه در وجودتان نهفته است را ، به مبارزه فرا می‌خوانند .

در این مقاله به ذكر سرچشمه تعدادی از چالشهای فراروی مدیر ، در طول پروسه مدیریت پروژه - كه توانمندیهای وی را در انجام وظایف و مسوولیتهای خویش به بوته آزمایش می‌كشند – پرداخته و به بیان نكاتی در راستای غلبه بر این منابع ایجاد دشواری در مسیر انجام صحیح پروژه ،  مبادرت خواهم ورزید .

1- ضرب‌الاجلهای غیرواقعی[Unrealistic Deadlines] :

بسیاری از مدیران پروژه‌ها ،‌ همواره از این حقیقت كه پروژه‌هایی كه به آنها واگذار می‌شود ، دارای ضرب‌الاجلهای از پیش تعیین‌شده هستند ، گلایه‌مندند . البته ، همیشه ضرب‌الاجلهای مطلقی چون برآوردهای خواسته شده یا رویدادهای بازاریابی وجود دارند اما بسیاری از تاریخهای ختم یك فعالیت یا رویداد خاص ، به پارامترهایی گره خورده‌اند كه به محدوده پروژه[Project Scope] ، وابستگی چندانی ندارند ؛ به عنوان نمونه ، آیا شما بر این عقیده‌اید كه تعطیلات مدیران و یا حتی چرخه بودجه[Budget Cycle] دارای چنین وابستگی می‌باشند ؟!

در پروژه‌هایی كه محدودیتهای زمانی[Constraints] مطلق ندارند ، می‌توان راههایی برای كنترل برنامه زمانی در مقابل تغییر در ضرب‌الاجلها ، اتخاذ نمود ؛ مدیریت فشاری كه در نتیجه ضرب‌الاجلها و خروجی پروژه بر تیم پروژه و در راس آن مدیریت پروژه وارد می‌گردد ،‌ از این جمله است ؛ این امر ، از طریق برنامه‌ریزی خلاقانه[Creative Planning] ، تجزیه‌وتحلیل آلتوناتیوها[Alternatives Analysis] و ارتباطات حقیقی و صادقانه با مشتری یا مشتریان ، شدنی خواهد بود ؛ در گام بعد و در مرحله‌ای فراتر ،‌ تعیین آنكه كدامیك از ضرب‌الاجلها با اهداف سطوح بالاتری گره خورده‌اند و نیز ایجاد پیوند مابین برنامه پروژه موردنظر با برنامه‌ زمانی دیگر پروژه‌های سازمان هم می‌تواند در كاستن از استرس ناشی از سررسید ضرب‌الاجلهای غیرواقعی اثربخش واقع گردد .     

2- پیدایش تغییر در محدوده پروژه :

یكی از قواعد مدیریت پروژه آن است كه تغییر ، اجتناب‌ناپذیر است ! اما آنچه كه ایجاد دشواری می‌نماید و لذا نباید اجتناب‌ناپذیر باشد ، تغییرات كنترل‌نشده است كه آن را به عنوان خزش در محدوده پروژه[Scope Creep] می‌شناسیم . یك مدیر پروژه ، باید هرگونه تقاضایی را به دقت مورد تجزیه‌وتحلیل قرار دهد و سپس مابین تاثیرات ناشی از هر تغییر و آلترناتیوهای موجود ، ارتباطی منطقی و مناسب برقرار نماید .  

به خاطر داشته باشید كه شما نمی‌توانید تغییرات را به كلی نادیده بگیرید اما می‌توانید به مشتری یا مشتریانی كه چشم‌انتظار محصول نهایی پروژه هستند بفهمانید كه هرگونه تغییری ، چگونه برنامه زمانی[Schedule] ، هزینه ، محدوده و كیفیت پروژه را تحت تاثیر قرار می‌دهد .

3- عدم موفقیت در مدیریت ریسك پروژه[Project Risk Management] :

طرح اغلب پروژه‌ها دارای لیستی از ریسكهای ممكن می‌باشد ، اما غالبا ، آنالیزها و برنامه‌ریزیهای بیشتر انجام نمی‌پذیرند مگر تا زمانیكه در طول دوره اجرای پروژه ، رویدادی ناسازگار رخ بنماید .

چنانچه تیم پروژه ریسكها را شناخته باشد ، اعضای تیم می‌توانند براحتی برای تعیین احتمال و تاثیر رخداد هر ریسك اقدام نمایند ؛ اینجاست كه آنان می‌توانند با بهره‌گیری از تجزیه‌وتحلیل آلترناتیوها ، از حدوث آن پیشگیری كنند و یا از طریق استراتژیهای مسكن[Mitigation Strategies] احتمال وقوع و/یا شدت تاثیر آن را كاهش داده و یا حتی برنامه‌ای عكس‌العملی برای واكنش نشان دادن پس از رویدادن ریسك ، پیش‌بینی نمایند .

4- تخصص ناكافی تیم پروژه :

دوستی می‌گفت : در دسترس بودن یك فرد ، برای او یك مهارت به شما نمی‌‌آید و نمی‌توان آن را در دایره تخصصها ارزیابی نمود ! متاسفانه ، اغلب پركارترین انسانها ،‌ تمایل دارند كه ماهرترینها نیز باشند ؛ اما حقیقت ممكن است چیز دیگری باشد !

به خاطر داشته باشید كه تشخیص آنكه یكی از اعضا برای كار در تیم پروژه از تخصص كافی برخوردار نیست زمانی دشوارتر می‌گردد كه او ، خود هم نداند كه تا چه اندازه ناكارآمد است .

شایسته است در برخورد با تیم كاری پروژه ، توجه شما را به نكاتی جلب نمایم :  

4-1- نخست آنكه ، هیچگاه كارگری را كه تلاش كرده وظیفه خود را به نحو مناسبی انجام دهد اما نتواسته ، سرزنش نكنید ؛‌ به این فكر كنید كه شاید این مشكل از آنجا ناشی شده باشد كه آموزش و هدایت مناسبی برای اینكه وی در موقعیت شغلیش فرد مناسبی باشد به او داده نشده است .

4-2- دوم آنكه ، به عنوان یك مدیر پروژه ، سندی از تخصصهای گوناگون موردنیاز در پروژه تهیه كرده و سپس ، صادقانه ، مهارتهای هر یك از اعضای فعلی را با آنچه كه در سند خود لیست نموده اید ، مقایسه كنید . با انجام این ارزیابی ، مدیر پروژه می‌تواند تیمش را از طریق آموزشهای تكمیلی مورد نیاز ، به سوی صلاحیتهای درخور و بایسته ، رهنمون نماید .

5-  در نظر گرفته نشدن مشتری/مشتریان نهایی در طول دوره پروژه :

گاهی اوقات ، تیم پروژه تا اندازه‌ای بر روی عناصر داخلی پروژه (همانند فرایندهای كاری ، ضرب‌الاجلها و ...) تمركز می‌نماید كه نتیجه آن ، تنها ، عدم اطلاع‌رسانی و آگاه‌سازی مصرف‌كنندگان نهایی ، از فازهای حساس و بحرانی پروژه می‌باشد ؛ برای پیشگیری از بروز چنین شكافهایی ، برگزاری تجمعات و جلسات برنامه‌ریزی شده با حضور مشتریان و مصرف كنندگان نهایی و آگاه نمودن آنان از وضعیت كنونی پروژه مفید فایده خواهد بود . از سوی دیگر ، اینگونه همایشها برای جمع‌آوری اطلاعات موردنیاز نیز مفید خواهد بود و به تیم پروژه اطمینان خواهد بخشید كه محصول نهایی ، انتظارات و توقعات مخاطبان را برآورده خواهد ساخت .

6- عدم تبیین دقیق نگرش و اهداف پروژه :

متاسفانه اهداف موردنظر از اجرای پروژه‌ها ، همیشه به روشنی تعریف نمی شوند ؛ در نتیجه ، ایجاد ارتباط مابین این اهداف مبهم و اعضای تیم پروژه به صورت یك فعالیت ناممكن درمی‌آید ؛ غلبه بر این ابهامات زمانی دشوارتر می‌گردد كه شخص مدیر پروژه نیز ، راهنمایی مناسب و كافی را دریافت نكرده باشد .

در اینگونه موارد ، ابتدا تعیین نمایید كه كدامیك از بخشهای پروژه توسط عناصر درگیر در پروژه به خوبی فهمیده نشده‌اند و سپس از آنها بخواهید بازخورهای[Feedback] خود را به شما ارائه دهند ؛ سپس نكات و سوالات مهمی كه از آنها متبادر می‌شود را یادداشت كرده و مورد بررسی قرار دهید . آن دسته از اسناد پروژه كه تاكنون آماده شده‌اند را مورد بازبینی مجدد قرار دهید و اهداف و آرمانهایی كه در آنها اشاره شده‌اند را تا حد امكان ، روشنتر و ملموستر گردانید .

موفقیت هر پروژه به اهداف استراتژیك ، مسیر حركت و نگرش تمامی بخشهای سازمان گره خورده‌ است ؛ ممكن است بتوان برای مشكلات اجرای پروژه ، دلایلی بی‌شمار برشمرد اما به نظر می‌رسد كه راه‌حل غالبا به یك نقطه باز می‌گردد : آفرینش ارتباطاتی موثر و سازمان‌یافته مابین تمامی اركان پروژه .

7- ارتباطات بی‌اثر :

با پیشرفت تكنولوژی دیگر كمبودی برای جریان اطلاعات[Information Flow] وجود ندارد ؛ اما مشكل اینجاست كه اغلب اطلاعات مناسب و مرتبط در اختیار اعضای پروژه قرار نمی گیرد . این امر عمدتا از دو دلیل ناشی می‌شود :‌ یكی اینكه سازمان قادر به ایجاد ارتباطات كارا نبوده و دیگر اینكه ما هنوز نمی‌دانیم كه چه كسی یا چه چیزی در راه حصول هدف ، اثربخشی دارد . 

برای غلبه بر این دشواری ، چراها ، چیستی‌ها ، چگونگیها و چه‌زمانیها را در پروژه ، به دقت مشخص كنید و نمونه‌هایی از برنامه زمانی ، صورت‌جلسات ، گزارشها و طرحها را ، متناسب با پروژه موردنظر خود بیابید و با حتی بیافرینید .

به خاطر داشته باشید كه اگر چه خروجی پروژه ، همیشه منحصربفرد است اما برقراری ارتباطاتی خوب و موثر باید به صورت یك عادت درآید .

در این مقاله ، به تبیین تعدادی از مهمترین چالشهای پیش‌روی مدیران پروژه پرداختیم ؛ اما باید توجه نمود كه این چالشها ، تنها منحصر به آنچه گفته شد نمی‌باشند و آنچه كه مدیر پروژه در طول دوره اجرای پروژه با آن مواجه خواهد گشت بیش از اینها می‌باشد ؛ اما عمومیت هفت چالش ذكر شده در این مجال بارها و بارها مورد تایید قرار گرفته است و بایسته است تا مدیران پروژه در كشورمان نیز بر روی راهكارهای اثربخش مقابله با آنان در سازمان پروژه خویش ، هر چه بیشتر و بیشتر بیندیشند .

|+| نوشته شده توسط شهاب احمدی در سه شنبه 5 آذر1387 و ساعت 6:54  

اگر می‌خواهید یك مدیر پروژه توانمند و كارا باشید ، لازم است تا به همان اندازه در ارزیابی روند اجرا و مراحل تكمیل پروژه خود ، قدرتمند و مقتدر عمل نمایید . در این نوشتار ، به معرفی دوازده گام كلیدی[To Do List] از میان آنچه كه یك مدیر پروژه می‌تواند در پروسه بازنگری پروژه‌اش ، بدانها بپردازد خواهم پرداخت ؛ توجه داشته باشید كه مطالعه این گامها ، حتی برای دفعات بیشمار ، اثربخشی نخواهد داشت مگر تا زمانیكه كه شما تصمیم بگیرید تا آستینهاتان را بالا بزنید !

مقدمه

پس از آنكه برنامه پروژه[Poject Plan] مورد تایید قرار گرفت و در مسیر اجرای آن گام نهادید ، از گامهای ذیل برای كنترل پیشبرد برنامه یاری جویید ؛ بكوشید برای هر پروژه‌ای كه تحت مدیریت دارید ، حداقل هفته‌ای یك بار به مرور مواردی كه در ادامه خواهم گفت بپردازید ؛ مگر آنكه نوع پروژه شما بگونه‌ای باشد كه نیاز به ارزیابی و كنترل در بازه‌های زمانی متفاوتی داشته باشد ؛ و اما گامهای طلایی دوازده‌گانه :

مرحله اول : محدوده پروژه[Project Scope] خود را مجددا برای خود تعریف نمایید .

ذهن و حافظه‌تان را نسبت به اهداف و محدودیتهای پروژه بازیابی كنید ؛ بویژه ، از این نكته اطمینان حاصل نمایید كه تصویر روشنی از میزان ارتباطی كه باید مابین نتایج موردانتظار شما از اجرای پروژه ، با هزینه‌ها ، كیفیت و سایر موارد اینچنینی در این مرحله از پروسه وجود داشته باشد ، در ذهن دارید . هیچگاه از خاطر نبرید كه آرمانهای اولیه شما چه بوده و اینك چه در دست دارید !

مرحله دوم : اقلام قابل تحویل[Deliverables] خود را بررسی نمایید .

وضعیت اقلام قابل تحویل پروژه را تجزیه و تحلیل كنید ؛ آیا نتایجی كه حاصل ‌آمده‌اند مطابق با برنامه پروژه بوده است ؟ اگر چنین است :

- لیستی از معیارهای كیفیتی كه برای كنترل كیفیت اقلام قابل تحویل در این مرحله از پروژه ، بایستی در نظر گرفته شوند ، تهیه كنید . شما به خوبی می‌دانید كه كارفرما از شما چه می‌خواهد ، پس اجازه ندهید چیزی غیر از آن رخ دهد .

- طرحهای پیشنهادی[Proposal] پیمانكاران و یا حتی قراردادهای به ثبت رسیده را مجددا بررسی نمایید تا مطمئن شوید كه می‌دانید در این مرحله از پروژه ، از آنان چه می‌خواهید .

- به تمامی اقلام قابل تحویل پروژه سركشی كنید ؛ گروههای كاری ، باید بدانند كه شما همیشه حاضر و ناظرید و همه چیز در كنترل شماست !

- تصمیم بگیرید كه آیا اقلام قابل تحویلی كه مورد بررسی قرار داده‌اید را تایید می‌كنید و یا نیاز به دوباره‌كاری (كه به شدت مضر نیز هست) دارند .

مرحله سوم : برنامه زمانی[Schedule] پروژه را بررسی نمایید .

آیا مقاطع كلیدی[Milestones] ، تاریخهای مهم و مسیر بحرانی پروژه ، در همان جایی هستند كه باید باشند ؟

مرحله چهارم : واریانسها (انحرافات از برنامه) را مورد تجزیه و تحلیل قرار دهید .

شما بایستی مقادیر تخمینی[Estimated] را با مقادیر واقعی[Actual] در مقام مقایسه قرار دهید :

- آیا فعالیتها[Activities] از آنچه پیش از این تخمین زده شده ، بیشتر به طول انجامیده‌اند ؟

- آیا تعداد ساعات كاری منابع بیش از میزان پیش‌بینی شده بوده است ؟

- آیا هزینه‌های واقعی از هزینه‌های تخمینی پیشی گرفته‌اند ؟

چنانچه واریانسهای حاصله كوچكتر از آنند كه در برنامه پروژه ایجاد تغییر نمایند ، به آسانی مرتفع می‌شوند اما در غیر اینصورت می‌توانند محدوده پروژه را تغییر دهند و مشكلات اساسی ایجاد نمایند ، پس هر چه سریعتر اقدامات اصلاحی را در جهت كاهش آنها به كار بندید ؛ نكته ریز دیگر اینكه : به دلایل ایجاد یك چنین واریانسهای بزرگی فكر كنید و به دنبال از بین بردنشان باشید .

مرحله پنجم : تغییرات محدوده پروژه را مورد بررسی قرار دهید .

- تغییرات در محدوده پروژه را شناسایی كنید ؛ عواملی چون تغییرات برنامه زمانی ، هزینه‌ها و ...

- تغییرات ایجاد شده را در صورت ضرورت ، مدیریت و راهبری كنید .

مرحله ششم : مشكلاتی كه سر باز كرده‌اند را لیست كنید ، پیگیری كرده و از سر راه بردارید .

- لیستی از مشكلاتی كه هنوز حل نشده‌اند تهیه نمایید و یا :

- نگاهی به لیستی كه در ارزیابی پیشین تهیه كرده بودید بیندازید و برای حل مشكلات مطروحه در آن تلاش كنید .

به خاطر داشته باشید كه ساده‌ترین خراشها می‌توانند روزی عفونی‌ترین زخمها باشند !

مرحله هفتم : ریسكهای بالقوه پروژه را مورد بازنگری قرار دهید .

- چنانچه برنامه‌ای برای مدیریت ریسك تهیه نموده‌اید ، آن را به اجرا بگذارید .

- لیستی از فعالیتهای تاثیرگذار بر ریسك پروژه را تهیه كرده و آنها را در ذهن خود پررنگتر نمایید .

مرحله هشتم : گزارشی از وضعیت كنونی پروژه تهیه نمایید .

یك مدیر پروژه قدرتمند به كاغذپاره‌ها وابسته نیست اما به خوبی می‌داند كه ثبت گزارشات از چه اهمیت شایانی برخوردار است ؛ لذا :

- با تیم پروژه خود صحبت كنید و وضعیت پروژه را از منظر نگاه آنان ارزیابی كنید ؛ توصیه می‌كنم حتی از نظرات پایین‌ترین رده‌های كاری نیز غافل نمانید !

- صورت وضعیتی از پروژه تهیه كرده و آن را منتشر نمایید . فراموش نكنید پاره‌ای از موارد را بهتر است همه بدانند !

مرحله نهم : به فعالیتهایی كه می‌توان خاتمه بخشید ، بیندیشید .

گاه در طول اجرای پروژه ، ممكن است به فعالیتهایی برخورد كنید كه انجام آنها بر پروژه كوچكترین تاثیری ندارند ؛ یا حتی نه ، به فعالیتهای موثری برخورد كنید كه زمان اجرای آنها دیگر خاتمه یافته ؛ پس :

- از خود بپرسید كه كدامیك از فعالیتها را می‌توانید ببندید و یا كدامیك از اقلام قابل تحویل را می‌توانید تایید و واگذار نمایید .

- در صورت نیاز ، فرمهای پایان كار را تهیه و امضا كنید .

مرحله دهم : آیا اینك زمان خاتمه پروژه است ؟

در طی مراحل دوره‌ای ارزیابی پروژه ، تنها یك بار پاسخ این پرسش مثبت خواهد بود و آن یك بار هم در انتهای پروژه است ؛ اگر چنین بود پس خسته نباشید اما هنوز كارتان پایان نگرفته است ! زیرا :

مرحله یازدهم : لیستی تهیه كنید از درسهای جدیدی كه در این اجرای این پروژه فرا گرفته‌اید .

هر پروژه جدید یعنی شرایط جدید و طبیعتا درسهای جدید ؛ گرچه بسیاری از این نكات ، در ناخودآگاهتان ثبت خواهند شد اما از ثبت نمودن آنها در دنیای واقعی غافل نشوید ؛ این درسها نه تنها برای شما و سازمان شما ، كه برای سایرین نیز روزی مفید خواهند بود .

مرحله دوازدهم : چك‌لیستهای ارزیابی را تكمیل كنید .

به شما توصیه می‌كنم چك‌لیستهایی برای ارزیابی كلیه اركان درگیر در پروژه تهیه كنید و با تكمیل آنها ، آرشیوی كامل از عملكرد سازمان و یا واحد صنعتی خود برجای بگذارید.

|+| نوشته شده توسط شهاب احمدی در یکشنبه 19 آبان1387 و ساعت 12:19