برای اجرای هر
پروژهای نیاز به اخذ یک تأئیدیه مبنی بر اثبات رابطه مثبت و منطقی بین
پروژه و استراتژی سازمانی از مسئولان ارشد و ذی‌نفعان کلیدی یک بنگاه
اقتصادی وجود دارد. طبیعی است که مسئولان ارشد برای صدور این تأئیدیه نیاز
به ابزاری برای اندازهگیری مفهوم فوق دارند. منشور پروژه، بهترین ابزار
برای ارزیابی شاخص فوق و مفاهیم مهم دیگری در هر پروژه محسوب میشود. این
ابزار در ابتدایی‌ترین نقط? پروژه، زمانی که باید اهداف و ایده‌های پروژه
برای عملیاتی کردن آن ارائه شود، ایجاد شده و سندی ایده‌آل برای مستندسازی
روابط بین پروژه و استراتژی سازمانی محسوب میشود. با وجود این، منشور یکی
از مهجورترین اجزای قابل عرضه در بحث مدیریت پروژه بوده که بسیار کم به آن
پرداخته شده است. موضوعات برنامه‌ریزی زمانی و هزینه‌ای، در مقایسه با
موضوع منشور پروژه، توجه زیادتری را به خود جلب کرده‌اند.
منشور پروژه چیست؟
ویرایش
سوم راهنمایPMBOK، منشور پروژه را به عنوان «سندی» تعریف میکند«که توسط
طراح یا حامی پروژه انتشار یافته و به طور رسمی موجودیت پروژه را تصویب و
اختیار به کارگیری منابع سازمانی را در جهت انجام فعالیتهای پروژه، به مدیر
پروژه واگذار میکند.» (PMBOK سال 2004، صفحه 368). واژه کلیدی در این
تعریف، «اختیار» است. منشور، به پروژه موجودیت و اعتبار می بخشد و مدیر
پروژه را دارای مجوز و اختیار قانونی میکند.
راهنمای PMBOK فهرست
اطلاعات خاصی را که باید به طور مستقیم یا با استفاده از منابع دیگر در
منشور درج شود، بیان میکند. این اطلاعات عبارتند از:
- نیازها و الزامات
- نیازهای کسب و کار
- جدول زمان‌بندی کلی
- پیش‌فرضها و محدودیتها
- وضعیت کسب و کار، شامل بازده سرمایه‌گذاری.
این
فهرستی استاندارد و معمول است که نشان می‌دهد منشور پروژه «بهتر است» از
چه اجزایی تشکیل شود. اما اگر سندی یک یا چند مورد از موارد فهرست بالا را
هم نداشته باشد همچنان می‌تواند به عنوان منشور پذیرفته شود. اگر واقعاً
محاسب? نرخ بازده سرمایه‌گذاری، به منظور وارد کردن آن در منشور پروژه لازم
بود، پروژه‌های معدودی را میتوانستیم دارای منشور بنامیم. متخصصان هنوز
در مورد اینکه آیا محاسبه نرخ بازده سرمایه گذاری برای پروژه‌های نظارتی یا
وابسته معنی‌دار است یا نه، به نتیجه نرسیدهاند. بسیاری از پروژه‌های
فناوری اطلاعات نیز دارای تجزیه و تحلیل نرخ بازده سرمایه گذاری نیستند.
ممکن
است کلمه «سند» در تعریف منشور پروژه و یا فهرست اطلاعات مشخصی که کتاب
PMBOK برای وارد کردن در منشور پروژه ارائه داده است، باعث برداشت اشتباه
برخی از مدیران پروژه شود. آنها می‌ترسند که اگر در تنظیم منشور پروژه از
قالبی از پیش تعیین‌شده و عناوینی مشخص استفاده نکنند، دیگر آن سند به
عنوان منشور پروژه قابل مراجعه نباشد. در حالی که راهنمای PMBOK استفاده از
هیچ قالب مشخصی را برای این سند الزامی نساخته است و منشورهای پروژه
می‌توانند فر‌م‌های مختلفی داشته باشند. شکل ظاهری منشور حتی می‌تواند به
صورت یک ایمیل یا یادداشتی کوتاه و معمولی هم باشد.
برداشتهای اشتباه و رایج در مورد منشورها
اصطلاح
«منشور پروژه» اغلب به اشتباه فهمیده میشود. مدیران پروژه کم‌تجربه‌تر،
معمولاً اعتقاد دارند که منشور باید سندی بسیار رسمی باشد. خود کلمه
«منشور» به تنهایی، در زبان انگلیسی به عنوان معادلی برای قراردادها یا
اسناد اجرایی و اغلب اسناد مربوط به تأسیس شهرها، مؤسسات آموزشی و یا حتی
مجموعه‌های دولتی به کار می‌رود. به طور سنتی، منشور سندی رسمی و قانونی
است. منشورهای سنتی می‌توانند بسیار ساده و مختصر باشند، اما افراد کمی
دارای چنین نگرشی در مورد آنها هستند.
اما منشور پروژه، مفهومی کاملاً
متفاوت است که نوعاً توسط وکیل آماده نمی‌شود و ممکن است دارای هیچگونه
بار حقوقی نباشد. منشور پروژه تنها مجوزی است برای انجام مجموعه تلاشها در
یک دوره زمانی مشخص.
این برداشتهای اشتباه باعث شده که بسیاری از
مدیران پروژه با وجود داشتن منشور، از تشخیص آن ناتوان باشند. دلایلی که
این مدیران پروژه در توضیح نداشتن منشور یا ناتوانی خود در تنظیم منشور به
آنها استناد می‌کنند، عمدتاً می‌تواند شامل موارد زیر باشد:
- «سندی
وجود ندارد که به تنهایی شامل تمام اطلاعات مربوط به اعطای مجوز، نام
پروژه، نیازها و الزامات کسب‌وکار و نام مدیر پروژه باشد_»
- «ما سندی با تمام اطلاعات صحیح در اختیار داریم، اما این سند توسط حامی پروژه نوشته نشده است.»
-
«رئیس من فقط مسؤولیت انجام کار را به من واگذار کرده و پس از آن تمام
اسنادی را که برای آغاز پروژه به آنها نیاز دارم برای من ایمیل کرده است.
من منشوری ندارم.»
- «ما هنوز به مرحله تهیه و جمع‌آوری نیازها و
الزامات نرسیدیم، پس چگونه می‌توانیم در این مرحله منشور داشته باشیم؟ ما
نیازها و الزامات خود را نمی‌شناسیم.»
همیشه نباید یک سند داشته باشیم
منشور
پروژه همیشه نباید در یک سند گنجانده شود. در ایدهآلترین حالت، یک سند
حداکثر، اجاز? انجام کار را صادر کرده و مراجع و منابع را با استفاده از
اسناد و مدارک موجود مشخص میکند که نشان‌دهنده نیازها و الزامات کسب و
کار، زمان‌بندی وقایع مهم و دیگر اطلاعات کلیدی است.
در غالب شرکتهایی
که کار پروژه را از طرف مشتری انجام می‌دهند، دستور انجام کار می‌تواند به
عنوان جزئی کلیدی از منشور پروژه، ایفای نقش کند. این دستور، در این
شرکتها، مجوز استفاده از منابع سازمانی را به افراد مشخصی اعطاء میکند.
امضای مشتری در پای سند، اجازه و اختیار را از طرف مشتری به شرکت مشاور
منتقل میکند و امضای مقابل از طرف مسئول یا گروه مشاوره نیز اجرای
توافق‌نامه را برای مشاور الزام‌آور می‌سازد.
حامیان پروژه‌ها معمولاً
مدیران اجرایی ارشد هستند که اوقات آزاد آنان کم و محدود است. به همین
دلیل، انتظار نگارش و ارائه منشور کامل پروژه از طرف آنان، حتی در سازمانی
پروژه‌محور، شاید غیرمعقول و ناممکن باشد. مدیران اجرایی ارشد معمولاً
هنگام تنظیم پیامهای مهم، از تندنویس یا کسانی که توانایی مکتوب کردن سخنان
را دارند، استفاده می‌کنند. مدیر پروژه باید خود را برای ایفای این نقش،
یعنی تنظیم پیش‌نویس و حتی نسخه نهایی منشور آماده کند.
نوشتن منشور
توسط حامیان پروژه، بخصوص برای پروژه‌هایی که حامیان آن را کمیته یا
مجموعه‌ای از افراد تشکیل می‌دهند، غیرعملی است. نوعاً در این شرایط، مدیر
پروژه یا یکی از حامیان به نوشتن سند اقدام کرده و دیگران آن را تأیید
می‌کنند.
نگارش منشور
به
منظور انتشار منشور در ابتدایی‌ترین نقطه پروژه، نویسنده منشور باید آن را
تنها بر اساس بخشی از اطلاعاتی که در همان ابتدا در دسترس دارد، تهیه کند.
راهنمای PMBOK، گنجاندن «نیازها و الزامات»، «زمان‌بندی»، و «بودجه» را
در منشور توصیه کرده است، اما ارائه اطلاعات دقیق از هرکدام از این اطلاعات
در آغاز پروژه غیرممکن خواهد بود. در اینجا باید منشور را بر اساس اطلاعات
محدود و موجودی که در دسترس است، آماده کرد.
در مقایسه با تجزیه و
تحلیل دقیق نیازها و الزامات، منشور ضرورتاً توضیح بسیار کمتری ارائه خواهد
داد. به طور مشخص، مدیران پروژه‌های فناوری اطلاعات از برداشتهای اشتباه
در مورد اصطلاح «نیازها و الزامات» رنج می‌برند. شکایات بسیاری مبنی بر
پایین بودن کیفیت پروژه‌های IT در هنگام تحویل وجود داشته است، بنابراین
متخصصان طراحی نرم‌افزار به متخصصان IT اصرار می‌کنند که قبل از انجام
هرگونه طراحی یا برنامه‌نویسی، نیازها و الزامات را به طور کامل و دقیق درک
کنند. مدیران پروژ? IT نباید از این توصیه به عنوان توجیهی برای اجتناب از
مستندسازی سریع شرایط و نیازمندیهای کسب‌وکار استفاده کنند. یک منشور خوب
می‌تواند شامل اطلاعات با اهمیت و سطح بالایی در بارة نیازها و الزامات
باشد. اطلاعاتی که به واقع می‌توانند در هدایت و تعیین مسیر تمرکز در مرحله
تنظیم دقیق نیازها و الزامات، نقش مؤثری ایفا نمایند.
احتمال دارد که
نیازها و الزامات پروژه کاملاً ناشناخته بوده و تنظیم منشور برای تمامی
ابعاد آن غیرممکن باشد. همیشه امکان دارد که برای اولین مرحله پروژه، تنها
برخی از نیازهای کسب و کار تعریف شده باشد. مراحل بعدی پروژه می‌توانند
نیازها و الزامات ملموستر و مشخصتر پروژه را شناسایی کرده و منشور پروژه را
اصلاح کنند.
منشورهای جزئی برای پروژه
منشور
در مرحل? آغاز پروژه و قبل از تعیین منابع اصلی تنظیم میشود. منشور اولی?
پروژه نوعاً باید کوتاه، شاید در حد چند صفحه، باشد. تا زمانی که مفهوم
اصلی این منشورها تأیید واضح و صریح صلاحیت پروژه و مدیر پروژه باشد،
می‌توانند حتی کمتر از یک صفحه نیز باشند.
اسناد طولانی‌تر و دارای
ساختار منظم، معمولاً برای موفقیت سازمان و پروژه اساسی هستند. این اسناد
جایگزین منشورهای کوتاه اولیه می شوند و به عنوان سند اصلی و راهنمای گروه
پروژه عمل می‌کنند. این سیر تکاملی طبیعی است و باید مورد تشویق قرار
بگیرد.
چه زمانی حامی باید منشور مجدد صادر کند؟
در
پروژهای دیگری که دارای مدیران فرعی یا گروههای رهبری جداگانه نیستند، در
آغاز یا پایان هر یک از مراحل پروژه، حامی ممکن است، بخواهد در منشور پروژه
تجدید نظر و یا منشور جدیدی را با مجوزهای جدید صادر و تأیید کند. این
زمانه فرصتهای مناسبی برای بازبینی منشور در اختیار حامی قرار می‌دهد.
منشور اولیه ممکن است دارای چشم‌انداز یا تعریف محدودی باشد.
شکل
منشورهای به‌روزشد? پروژه ممکن است با منشور اولی? پروژه تفاوت زیادی داشته
باشند. آنها ممکن است حاوی طرحهای دقیق و جزئی‌تری از کار، بودجه‌ها،
فهرست مشخص اجزای قابل عرضه و موارد دیگر باشند. این منشورهای به‌روزشده
ممکن است دارای صفحات بسیاری بوده و شامل تمام عناصر طرح جزئی پروژه باشند.
گاهی اوقات تنظیم طرح و برنامه‌ریزی برای گام بعدی پروژه، یکی از اجزای
نهایی قابل عرضه در مرحلهای از پروژه محسوب میشود.
منشور و استراتژی سازمانی
منشور
پروژه یکی از ایدهآلترین ابزارها برای بررسی نقادانه همسویی یا ناهمسویی
پروژه با استراتژی سازمانی و میزان حمایت پروژه از این استراتژی است. اگر
پروژه واقعاً با استراتژی سازمانی همراستا نباشد، منشور بهترین فرصت برای
متوقف کردن پروژه قبل از اتلاف منابع خواهد بود. اگر مدیران پروژه همواره
پروژه‌های ناهماهنگ را قبل از شروع متوقف می‌کردند، امروز با پروژه‌های
شکست‌خورده بسیار کمتری مواجه بودیم.
منشور کوتاه است اما باید حاوی
نیازها و الزامات و اهداف کسب و کار باشد. یعنی در منشور، جزئیات اجرایی
هنوزکاملاً تعریف نشده‌اند. استراتژی سازمانی نیز دقیقاً در این سطح عمل
میکند: مشخص کردن نیازها و الزامات و اهداف کسب و کار، بدون جزئیات
اجرایی.
افراد می‌توانند به سرعت منشور پروژه را با مسیرحرکت، طرح کسب
وکار و یا سند مربوط به استراتژی مقایسه و تعیین کنند که آنها باهم سازگار و
هماهنگ هستند یا نه. منشور، قصد و هدف کسب و کار را به صورت خالص و محض
بیان میکند. پیش‌نویس کردن منشور، فرصتی استثنایی برای همراستا کردن کامل
پروژه با اهداف کلی کسب و کار است.
شروع کار سازمان شما با منشورها
برخی
از مسؤولان اجرایی پروژه‌ها بدون بررسی دقیق و درک از روند و فرایند
انتخاب پروژه، دستور به آغاز آن می دهند و این موضوع باعث شکایت برخی
مدیران پروژه از این امر می شود. آنها می‌خواهند که این مسئولان اجرایی،
قبل از شروع کار این پروژه‌ها، با مدیران پروژه برای آگاه شدن از نظر آنها و
انجام درست کار مذاکره کنند.
حقیقت این است که این مسئولان اجرایی با مدیران پروژه مذاکره می‌کنند.
آنها
زمانی با مدیران پروژه مذاکره می‌کنند که می‌خواهند وظایف را تعیین کنند و
یا منشور پروژه را ارائه دهند. بسیاری از مدیران پروژه، آمادگی
بهره‌برداری از این فرصت کوتاه را برای مشارکت در استراتژی سازمانی ندارند.
مدیر پروژه باید در زمان واگذاری پروژه، بدون اتلاف وقت، سؤالاتی
بنیادی را مطرح کند. اگر رابط? پروژه با استراتژی سازمانی نامشخص باشد،
زمان پرسیدن این سؤالات در طول انجام کار خواهد بود. اگر این رابطه مشخص
باشد، منشور وسیله‌ای برای مستندسازی دقیق و روشن فرضیات و گرفتن تأیید
حامی مبنی بر درست بودن آنها خواهد بود. اگر زمانی که مدیر پروژه تعیین
میشود، پروژه در حال انجام باشد، تأیید مجدد منشور موجود یا نوشتن نسخه‌ای
جدید از آن، راهی فوق‌العاده برای مدیر جدید پروژه به منظور جا انداختن و
باورپذیر کردن موقعیت خود خواهد بود.
مدیر پروژه به عنوان مؤلف (یا حداقل نگارنده) منشور
سپردن
تألیف منشور به فردی دیگر، در واقع سپردن پیشرفت، بازاریابی و مسیر پروژه
به آن فرد است. بهترین حامیان می‌توانند بخوبی از عهد? ایفای این نقشها
بر‌آیند، اما همه آنها این توانایی را دارا نیستند. بسیاری از مدیران
پروژه به این دلیل دچار سرخوردگی و ناامیدی می‌شوند که حامی پروژ? آنها،
منشور را به صورت شفاف تنظیم نمی‌کند.
در برخی موارد، ممکن است حامی
پروژه نتواند یا نخواهد پیش‌نویس منشور را تأیید کند. حامیان پروژه ممکن
است خواستار تغییرات پی در پی باشند، یا این که با تأیید منشور مخالفت
کنند. تمایل نداشتن برای تأیید سند نشانه درک اشتباه، نبود پشتیبانی و یا
حتی مواردی بدتر از اینهاست. مدیر حرفه‌ای پروژه باید تا زمان حل شدن مشکل،
کار را متوقف کند. ادام? پروژه بدون هیچگونه تفویض اختیار یا تعریفی مشخص
از کار، به فاجعه ختم میشود.
برای درک مناسب‌تر موضوع، یک نمونه منشور
پروژه که با توجه به طبیعت و نیازمندیهای موجود در کشورمان تهیه شده است،
ارائه میشود. این نمونه در دو قسمت تنظیم و ارائه شده است. قسمت اول نگاهی
اجمالی به کل پروژه و تعریف و واژگان کلیدی می اندازد و قسمت دوم
راهکارهای رسیدن به اهداف کلیدی پروژه را مطرح میکند. لازم به ذکر است که
در ارائه این نمونه، به دلیل رعایت اختصار، تنها به ذکر عنوان وار محتویات
بسنده شده است.
بخش اول – اطلاعات کلی و شرح اجمالی از پروژه
الف – تاریخچه
ب – تعریف منشور پروژه در این سند
پ – تعریف پروژه (عقد قرارداد) و جایگاه آن
ت – ذی‌نفعان پروژه شامل سفارش دهنده و مشتریان اصلی، حامی و وظایف او و مدیر پروژه.
ث – هدف اصلی پروژه
ج – محدوده پروژه
چ – نیازها، الزامات و معیارهای پذیرش سفارش دهنده پروژه
ح – موارد مبهم برای عقد قرارداد
خ – نقشها و مسئولیتها
بخش دوم – راهکارهای دست‌یابی به اهداف پروژه
الف – سازماندهی تیم پروژه
ب – تهیه و تصویب نمودار سازمانی تیم عقد قرارداد
پ – روشها و راهکارهای ویژه این پروژه
ت – وابستگیها
ث – برنامه های پشتیبانی
ج – مدیریت ریسک (ماتریس شناسایی ریسک و اقدامات لازم برای پوشش ریسک‌ها)
چ – زمان
ح – هزینه ها و جریان نقدی پروژه.
برای اجرای هر پروژهای نیاز به اخذ یک تاییدیه مبنی بر اثبات رابطه مثبت و منطقی بین پروژه و استراتژی سازمانی از مسئولان ارشد و ذی‌نفعان کلیدی یک بنگاه اقتصادی وجود دارد. طبیعی است که مسئولان ارشد برای صدور این تاییدیه نیاز به ابزاری برای اندازهگیری مفهوم فوق دارند. منشور پروژه، بهترین ابزار برای ارزیابی شاخص فوق و مفاهیم مهم دیگری در هر پروژه محسوب میشود. این ابزار در ابتدایی‌ترین نقطه پروژه، زمانی که باید اهداف و ایده‌های پروژه برای عملیاتی کردن آن ارائه شود، ایجاد شده و سندی ایده‌آل برای مستندسازی روابط بین پروژه و استراتژی سازمانی محسوب میشود. با وجود این، منشور یکی از مهجورترین اجزای قابل عرضه در بحث مدیریت پروژه بوده که بسیار کم به آن پرداخته شده است.
موضوعات برنامه‌ریزی زمانی و هزینه‌ای، در مقایسه با موضوع منشور پروژه، توجه زیادتری را به خود جلب کرده‌اند.
منشور پروژه چیست؟
ویرایش سوم راهنمایPMBOK، منشور پروژه را به عنوان «سندی» تعریف میکند«که توسط طراح یا حامی پروژه انتشار یافته و به طور رسمی موجودیت پروژه را تصویب و اختیار به کارگیری منابع سازمانی را در جهت انجام فعالیتهای پروژه، به مدیر پروژه واگذار میکند.» (PMBOK سال 2004، صفحه 368). واژه کلیدی در این تعریف، «اختیار» است. منشور، به پروژه موجودیت و اعتبار می بخشد و مدیر پروژه را دارای مجوز و اختیار قانونی میکند
مشخصه‌های اساسی پروژه‌ها کدامند ؟
مشخصات اصلی پروژه‌ها عبارتند از :۱- موقتی بودن۲- یکتا بودن ۳- تفضیل فزاینده
۱- مشخصه موقتی بودن در پروژه‌ها :هر
پروژه در زمان مشخصی آغاز و خاتمه می‌یابد ؛ پروژه زمانی خاتمه می‌یابد
که به اهداف (از پیش تعیین‌شده) نایل شده باشد و یا هنگامیکه مشخص شود
اهداف پروژه قابل حصول نبوده و می‌بایستی پروژه خاتمه یابد . اجرای موقتی
پروژه‌ها ، نه تنها لزوما به معنی دوره کوتاه انجام آنها نیست بلکه بسیاری
از پروژه‌ها در طی سالیان طولانی به نتیجه می‌رسد ، اما به هر حال زمان
اجرای هیچ پروژهای نامحدود نبوده و اجمالا پروژه یک تلاش مداوم نیست .
محصولات و خدمات منتج از اجرای پروژه‌ها برخلاف دوره اجرای آنها عموما
موقتی نیستند .
یک مساله دیگر درخصوص موقتی بودن پروژه‌ها میزان حصول به نتایج ( و اهداف از پیش) پیش‌بینی
شده آنها در موعد مشخص شده است ؛ این موضوع بطور دائم توجه مسئولین پروژه
را به خود مشغول می‌دارد و آنان همیشه در تکاپوی پاسخ به این سؤال هستند که
آیا می‌توانند پروژه را مطابق اهداف از پیش تعیین‌شده به اتمام برسانند ؟
۲- مشخصه یکتا بودن پروژه‌ها :اجرای
پروژه‌ها ، انجام آن مجموعه فعالیتهای منحصر بفردیست که پیش از این انجام
نشده‌اند و این نشانه یکتایی آنها است . پروژه تهیه و تولید یک محصول یا
ارائه خدمات ، اگرچه ممکن است در یک گروه مشخص (مانند طراحی نرم‌افزار)
قرار گیرد ، اما یکتا و منحصر بفرد است . پروژه‌ها با متولیان ، طراحان ،
موقعیتهای زمانی ، مکانی ، مجریان و سایر مشخصه‌های گوناگون و متفاوت از
یکدیگر ، اجرا می‌شوند لذا حتی وجوه اشتراک پروژه‌ها از برخی جهات و یا حتی
همه موارد برشمرده شده نیز نمی‌تواند یکتایی آنها را منتفی نماید .
۳- مشخصه تفصیل فزاینده :محصول
یا نتایج پروژه‌ها یکتا و منحصر به هر یک از آنها بوده و مشخصه‌های این
نتابج منحصر به فرد می‌بایستی از ابتدا تا انتها بطور فزاینده بسط داده شود
. مفهوم فزاینده روند صعودی مستمر و بدون بازگشت و تفصیل نیز بسط توسعه
یافته برای تکمیل تبیین می‌باشد .
تفصیل
فزاینده مشخصه‌های محصول پروژه می‌بایستی حتی‌الامکان از همان ابتدای
پروژه آغاز و به تدریج همزمان با تکمیل گروه مدیریت پروژه دقیق و کامل گردد
. تفصیل فزاینده مشخصه‌های محصول پروژه می‌بایستی بدقت با تعریف محدوده
پروژه ( مجموعه کارهایی که می‌بایستی برای نیل به اهداف پروژه انچام
پذیرند) هماهنگ و متناسب باشد و همچنین تفصیل فزاینده مشخصه‌های محصول
پروژه نمی‌بایستی موجب تغییر در تعریف محدوده مصوب پروژه گردد .
به
عنوان نمونه در پروژه احداث یک کارخانه پتروشیمی ابتدا مشخصه‌های فرایند
کارخانه تبیین ، آنگاه واحدهای اصلی فرایندی با توجه به این مشخصه‌ها طراحی
میگردد ؛ سپس این اطلاعات مبنا و معیار مناسبی برای انجام مهندسی پروژه
اعم از طراحی مفهومی ، پایه و تفصیلی جانمایی کل کارخانه (Detail plant layout) و همچنین طراحی مشخصه‌های فرایندی و مکانیکی هر یک از دستگاهها و تجهیزات در واحدهای فرایندی و سرویس‌های جانبی کارخانه می‌باشد .
نتایج
طراحی نقشه‌ها و تهیه مدارک مهندسی ، به مرور و بطور فزاینده تهیه و تولید
نقشه‌ها و مدارک خرید ، ساخت و نصب (مانند نقشه‌های ایزومتریک) را بدنبال
خواهد داشت . (هنگام عملیات اجرایی تقسیر و تطبیق بین برنامه کاری و شرایط
کاری بسیار ضروری و مبتنی بر اخذ تأییدات لازم می‌باشد) این تفصیل فزاینده
مشخصه‌ها ، در نهایت منجر به تولید نقشه‌های عین ساخت میگردد
برای اجرای هر پروژهای نیاز به اخذ یک تاییدیه مبنی بر اثبات رابطه مثبت و منطقی بین پروژه و استراتژی سازمانی از مسئولان ارشد و ذی‌نفعان کلیدی یک بنگاه اقتصادی وجود دارد. طبیعی است که مسئولان ارشد برای صدور این تاییدیه نیاز به ابزاری برای اندازهگیری مفهوم فوق دارند. منشور پروژه، بهترین ابزار برای ارزیابی شاخص فوق و مفاهیم مهم دیگری در هر پروژه محسوب میشود. این ابزار در ابتدایی‌ترین نقطه پروژه، زمانی که باید اهداف و ایده‌های پروژه برای عملیاتی کردن آن ارائه شود، ایجاد شده و سندی ایده‌آل برای مستندسازی روابط بین پروژه و استراتژی سازمانی محسوب میشود. با وجود این، منشور یکی از مهجورترین اجزای قابل عرضه در بحث مدیریت پروژه بوده که بسیار کم به آن پرداخته شده است. موضوعات برنامه‌ریزی زمانی و هزینه‌ای، در مقایسه با موضوع منشور پروژه، توجه زیادتری را به خود جلب کرده‌اند.
منشور پروژه چیست؟
ویرایش سوم راهنمایPMBOK، منشور پروژه را به عنوان «سندی» تعریف میکند«که توسط طراح یا حامی پروژه انتشار یافته و به طور رسمی موجودیت پروژه را تصویب و اختیار به کارگیری منابع سازمانی را در جهت انجام فعالیتهای پروژه، به مدیر پروژه واگذار میکند.» (PMBOK سال 2004، صفحه 368). واژه کلیدی در این تعریف، «اختیار» است. منشور، به پروژه موجودیت و اعتبار می بخشد و مدیر پروژه را دارای مجوز و اختیار قانونی میکند. راهنمای PMBOK فهرست اطلاعات خاصی را که باید به طور مستقیم یا با استفاده از منابع دیگر در منشور درج شود، بیان میکند. این اطلاعات عبارتند از:
- نیازها و الزامات
- نیازهای کسب و کار
- جدول زمان‌بندی کلی
- پیش‌فرضها و محدودیتها
- وضعیت کسب و کار، شامل بازده سرمایه‌گذاری.
این فهرستی استاندارد و معمول است که نشان می‌دهد منشور پروژه «بهتر است» از چه اجزایی تشکیل شود. اما اگر سندی یک یا چند مورد از موارد فهرست بالا را هم نداشته باشد همچنان می‌تواند به عنوان منشور پذیرفته شود. اگر واقعا محاسبه نرخ بازده سرمایه‌گذاری، به منظور وارد کردن آن در منشور پروژه لازم بود، پروژه‌های معدودی را میتوانستیم دارای منشور بنامیم. متخصصان هنوز در مورد اینکه آیا محاسبه نرخ بازده سرمایه گذاری برای پروژه‌های نظارتی یا وابسته معنی‌دار است یا نه، به نتیجه نرسیدهاند.
بسیاری از پروژه‌های فناوری اطلاعات نیز دارای تجزیه و تحلیل نرخ بازده سرمایه گذاری نیستند. ممکن است کلمه «سند» در تعریف منشور پروژه و یا فهرست اطلاعات مشخصی که کتاب PMBOK برای وارد کردن در منشور پروژه ارائه داده است، باعث برداشت اشتباه برخی از مدیران پروژه شود. آنها می‌ترسند که اگر در تنظیم منشور پروژه از قالبی از پیش تعیین‌شده و عناوینی مشخص استفاده نکنند، دیگر آن سند به عنوان منشور پروژه قابل مراجعه نباشد. در حالی که راهنمای PMBOK استفاده از هیچ قالب مشخصی را برای این سند الزامی نساخته است و منشورهای پروژه می‌توانند فر‌م‌های مختلفی داشته باشند. شکل ظاهری منشور حتی می‌تواند به صورت یک ایمیل یا یادداشتی کوتاه و معمولی هم باشد.
برداشتهای اشتباه و رایج در مورد منشورها
اصطلاح
«منشور پروژه» اغلب به اشتباه فهمیده میشود. مدیران پروژه کم‌تجربه‌تر،
معمولا اعتقاد دارند که منشور باید سندی بسیار رسمی باشد. خود کلمه «منشور»
به تنهایی، در زبان انگلیسی به عنوان معادلی برای قراردادها یا اسناد
اجرایی و اغلب اسناد مربوط به تاسیس شهرها، موسسات آموزشی و یا حتی
مجموعه‌های دولتی به کار می‌رود. به طور سنتی، منشور سندی رسمی و قانونی
است. منشورهای سنتی می‌توانند بسیار ساده و مختصر باشند، اما افراد کمی
دارای چنین نگرشی در مورد آنها هستند.
اما منشور پروژه، مفهومی کاملا متفاوت است که نوعا توسط وکیل آماده نمی‌شود و ممکن است دارای هیچگونه بار حقوقی نباشد. منشور پروژه تنها مجوزی است برای انجام مجموعه تلاشها در یک دوره زمانی مشخص.
این
برداشتهای اشتباه باعث شده که بسیاری از مدیران پروژه با وجود داشتن
منشور، از تشخیص آن ناتوان باشند. دلایلی که این مدیران پروژه در توضیح
نداشتن منشور یا ناتوانی خود در تنظیم منشور به آنها استناد می‌کنند، عمدتا
می‌تواند شامل موارد زیر باشد:
- «سندی وجود ندارد که به تنهایی شامل تمام اطلاعات مربوط به اعطای مجوز، نام پروژه، نیازها و الزامات کسب‌وکار و نام مدیر پروژه باشد»
- «ما سندی با تمام اطلاعات صحیح در اختیار داریم، اما این سند توسط حامی پروژه نوشته نشده است.»
- «رئیس من فقط مسؤولیت انجام کار را به من واگذار کرده و پس از آن تمام اسنادی را که برای آغاز پروژه به آنها نیاز دارم برای من ایمیل کرده است. من منشوری ندارم.»
- «ما هنوز به مرحله تهیه و جمع‌آوری نیازها و الزامات نرسیدیم، پس چگونه می‌توانیم در این مرحله منشور داشته باشیم؟ ما نیازها و الزامات خود را نمی‌شناسیم.»
همیشه نباید یک سند داشته باشیم !
منشور پروژه همیشه نباید در یک سند گنجانده شود. در ایدهآلترین حالت، یک سند حداکثر، اجازه انجام کار را صادر کرده و مراجع و منابع را با استفاده از اسناد و مدارک موجود مشخص میکند که نشان‌دهنده نیازها و الزامات کسب و کار، زمان‌بندی وقایع مهم و دیگر اطلاعات کلیدی است.
در غالب شرکتهایی که کار پروژه را از طرف مشتری انجام می‌دهند، دستور انجام کار می‌تواند به عنوان جزئی کلیدی از منشور پروژه، ایفای نقش کند. این دستور در این شرکتها، مجوز استفاده از منابع سازمانی را به افراد مشخصی اعطا میکند. امضای مشتری در پای سند، اجازه و اختیار را از طرف مشتری به شرکت مشاور منتقل میکند و امضای مقابل از طرف مسئول یا گروه مشاوره نیز اجرای توافق‌نامه را برای مشاور الزام‌آور می‌سازد.
حامیان پروژه‌ها معمولا مدیران اجرایی ارشد هستند که اوقات آزاد آنان کم و محدود است. به همین دلیل، انتظار نگارش و ارائه منشور کامل پروژه از طرف آنان، حتی در سازمانی پروژه‌محور، شاید غیرمعقول و ناممکن باشد. مدیران اجرایی ارشد معمولا هنگام تنظیم پیامهای مهم، از تندنویس یا کسانی که توانایی مکتوب کردن سخنان را دارند، استفاده می‌کنند. مدیر پروژه باید خود را برای ایفای این نقش، یعنی تنظیم پیش‌نویس و حتی نسخه نهایی منشور آماده کند.
نوشتن منشور توسط حامیان پروژه، به خصوص برای پروژه‌هایی که حامیان آن را کمیته یا مجموعه‌ای از افراد تشکیل می‌دهند، غیرعملی است. نوعا در این شرایط، مدیر پروژه یا یکی از حامیان به نوشتن سند اقدام کرده و دیگران آن را تایید می‌کنند.
نگارش منشور
به منظور انتشار منشور در ابتدایی‌ترین نقطه پروژه، نویسنده منشور باید آن را تنها بر اساس بخشی از اطلاعاتی که در همان ابتدا در دسترس دارد، تهیه کند. راهنمای PMBOK، گنجاندن «نیازها و الزامات»، «زمان‌بندی»، و «بودجه» را در منشور توصیه کرده است، اما ارائه اطلاعات دقیق از هرکدام از این اطلاعات در آغاز پروژه غیرممکن خواهد بود. در اینجا باید منشور را بر اساس اطلاعات محدود و موجودی که در دسترس است، آماده کرد.
در
مقایسه با تجزیه و تحلیل دقیق نیازها و الزامات، منشور ضرورتا توضیح بسیار
کمتری ارائه خواهد داد. به طور مشخص، مدیران پروژه‌های فناوری اطلاعات از
برداشتهای اشتباه در مورد اصطلاح «نیازها و الزامات» رنج می‌برند. شکایات
بسیاری مبنی بر پایین بودن کیفیت پروژه‌های IT در هنگام تحویل وجود داشته است، بنابراین متخصصان طراحی نرم‌افزار به متخصصان IT اصرار می‌کنند که قبل از انجام هرگونه طراحی یا برنامه‌نویسی، نیازها و الزامات را به طور کامل و دقیق درک کنند. مدیران پروژهIT
نباید از این توصیه به عنوان توجیهی برای اجتناب از مستندسازی سریع شرایط و
نیازمندیهای کسب‌وکار استفاده کنند. یک منشور خوب می‌تواند شامل اطلاعات
با اهمیت و سطح بالایی درباره نیازها و الزامات باشد. اطلاعاتی که به واقع
می‌توانند در هدایت و تعیین مسیر تمرکز در مرحله تنظیم دقیق نیازها و
الزامات، نقش موثری ایفا نمایند.
احتمال دارد که نیازها و الزامات پروژه
کاملا ناشناخته بوده و تنظیم منشور برای تمامی ابعاد آن غیرممکن باشد.
همیشه امکان دارد که برای اولین مرحله پروژه، تنها برخی از نیازهای کسب و
کار تعریف شده باشد. مراحل بعدی پروژه می‌توانند نیازها و الزامات ملموستر و
مشخصتر پروژه را شناسایی کرده و منشور پروژه را اصلاح کنند.
منشورهای جزئی برای پروژه
منشور در مرحله آغاز پروژه و قبل از تعیین منابع اصلی تنظیم میشود. منشور اولیه پروژه نوعا باید کوتاه، شاید در حد چند صفحه باشد. تا زمانی که مفهوم اصلی این منشورها تایید واضح و صریح صلاحیت پروژه و مدیر پروژه باشد، می‌توانند حتی کمتر از یک صفحه نیز باشند.
اسناد طولانی‌تر و دارای ساختار منظم، معمولا برای موفقیت سازمان و پروژه اساسی هستند. این اسناد جایگزین منشورهای کوتاه اولیه می شوند و به عنوان سند اصلی و راهنمای گروه پروژه عمل می‌کنند. این سیر تکاملی طبیعی است و باید مورد تشویق قرار بگیرد.
چه زمانی حامی باید منشور مجدد پروژه را صادر نماید ؟
در پروژه های دیگری که دارای مدیران فرعی یا گروههای رهبری جداگانه نیستند، در آغاز یا پایان هر یک از مراحل پروژه، حامی ممکن است بخواهد در منشور پروژه تجدید نظر و یا منشور جدیدی را با مجوزهای جدید صادر و تأیید کند. این زمان فرصتهای مناسبی برای بازبینی منشور در اختیار حامی قرار می‌دهد.
منشور اولیه ممکن است دارای چشم‌انداز یا تعریف محدودی باشد. شکل منشورهای بروز شده پروژه ممکن است با منشور اولیه پروژه تفاوت زیادی داشته باشند. آنها ممکن است حاوی طرحهای دقیق و جزئی‌تری از کار، بودجه‌ها، فهرست مشخص اجزای قابل عرضه و موارد دیگر باشند. این منشورهای بروزشده ممکن است دارای صفحات بسیاری بوده و شامل تمام عناصر طرح جزئی پروژه باشند. گاهی اوقات تنظیم طرح و برنامه‌ریزی برای گام بعدی پروژه، یکی از اجزای نهایی قابل عرضه در مرحلهای از پروژه محسوب میشود.
رابطه منشور پروژه و استراتژی سازمانی
منشور پروژه یکی از ایدهآلترین ابزارها برای بررسی نقادانه همسویی یا ناهمسویی پروژه با استراتژی سازمانی و میزان حمایت پروژه از این استراتژی است. اگر پروژه واقعا با استراتژی سازمانی همراستا نباشد، منشور بهترین فرصت برای متوقف کردن پروژه قبل از اتلاف منابع خواهد بود. اگر مدیران پروژه همواره پروژه‌های ناهماهنگ را قبل از شروع متوقف می‌کردند، امروز با پروژه‌های شکست‌خورده بسیار کمتری مواجه بودیم.
منشور کوتاه است اما باید حاوی نیازها و الزامات و اهداف کسب و کار باشد. یعنی در منشور، جزئیات اجرایی هنوزکاملا تعریف نشده‌اند. استراتژی سازمانی نیز دقیقا در این سطح عمل میکند: مشخص کردن نیازها و الزامات و اهداف کسب و کار، بدون جزئیات اجرایی.
افراد می‌توانند به سرعت منشور پروژه را با مسیرحرکت، طرح کسب وکار و یا سند مربوط به استراتژی مقایسه و تعیین کنند که آنها باهم سازگار و هماهنگ هستند یا نه. منشور، قصد و هدف کسب و کار را به صورت خالص و محض بیان میکند. پیش‌نویس کردن منشور، فرصتی استثنایی برای همراستا کردن کامل پروژه با اهداف کلی کسب و کار است.
شروع کار سازمان با منشورها
برخی از مسؤولان اجرایی پروژه‌ها بدون بررسی دقیق و درک از روند و فرایند انتخاب پروژه، دستور به آغاز آن می دهند و این موضوع باعث شکایت برخی مدیران پروژه از این امر می شود. آنها می‌خواهند که این مسئولان اجرایی، قبل از شروع کار این پروژه‌ها، با مدیران پروژه برای آگاه شدن از نظر آنها و انجام درست کار مذاکره کنند.
حقیقت
این است که این مسئولان اجرایی با مدیران پروژه مذاکره می‌کنند. آنها
زمانی با مدیران پروژه مذاکره می‌کنند که می‌خواهند وظایف را تعیین کنند و
یا منشور پروژه را ارائه دهند. بسیاری از مدیران پروژه، آمادگی بهره‌برداری
از این فرصت کوتاه را برای مشارکت در استراتژی سازمانی ندارند.
مدیر
پروژه باید در زمان واگذاری پروژه، بدون اتلاف وقت، سؤالاتی بنیادی را مطرح
کند. اگر رابطه پروژه با استراتژی سازمانی نامشخص باشد، زمان پرسیدن این
سؤالات در طول انجام کار خواهد بود. اگر این رابطه مشخص باشد، منشور
وسیله‌ای برای مستندسازی دقیق و روشن فرضیات و گرفتن تایید حامی مبنی بر
درست بودن آنها خواهد بود. اگر زمانی که مدیر پروژه تعیین میشود، پروژه در
حال انجام باشد، تایید مجدد منشور موجود یا نوشتن نسخه‌ای جدید از آن،
راهی فوق‌العاده برای مدیر جدید پروژه به منظور جا انداختن و باورپذیر کردن
موقعیت خود خواهد بود.
مدیر پروژه به عنوان مؤلف یا نگارنده منشور
سپردن تالیف منشور به فردی دیگر، در واقع سپردن پیشرفت، بازاریابی و مسیر پروژه به آن فرد است. بهترین حامیان می‌توانند بخوبی از عهده ایفای این نقشها بر‌آیند، اما همه آنها این توانایی را دارا نیستند. بسیاری از مدیران پروژه به این دلیل دچار سرخوردگی و ناامیدی می‌شوند که حامی پروژه آنها، منشور را به صورت شفاف تنظیم نمی‌کند.
در برخی موارد، ممکن است حامی پروژه نتواند یا نخواهد پیش‌نویس منشور را تایید کند. حامیان پروژه ممکن است خواستار تغییرات پی در پی باشند، یا این که با تایید منشور مخالفت کنند. تمایل نداشتن برای تایید سند نشانه درک اشتباه ، نبود پشتیبانی و یا حتی مواردی بدتر از اینهاست. مدیر حرفه‌ای پروژه باید تا زمان حل شدن مشکل، کار را متوقف کند. ادامه پروژه بدون هیچگونه تفویض اختیار یا تعریفی مشخص از کار، به فاجعه ختم میشود.
برای درک مناسب‌تر موضوع، یک نمونه منشور پروژه که با توجه به طبیعت و نیازمندیهای موجود در کشورمان تهیه شده است، ارائه میشود. این نمونه در دو قسمت تنظیم و ارائه شده است. قسمت اول نگاهی اجمالی به کل پروژه و تعریف و واژگان کلیدی می اندازد و قسمت دوم راهکارهای رسیدن به اهداف کلیدی پروژه را مطرح میکند. لازم به ذکر است که در ارائه این نمونه، به دلیل رعایت اختصار، تنها به ذکر عنوان وار محتویات بسنده شده است :
بخش اول – اطلاعات کلی و شرح اجمالی از پروژه
الف – تاریخچه
ب – تعریف منشور پروژه در این سند
پ – تعریف پروژه (عقد قرارداد) و جایگاه آن
ت – ذی‌نفعان پروژه شامل سفارش دهنده و مشتریان اصلی، حامی و وظایف او و مدیر پروژه.
ث – هدف اصلی پروژه
ج – محدوده پروژه
چ – نیازها، الزامات و معیارهای پذیرش سفارش دهنده پروژه
ح – موارد مبهم برای عقد قرارداد
خ – نقشها و مسئولیتها
بخش دوم – راهکارهای دست‌یابی به اهداف پروژه
الف – سازماندهی تیم پروژه
ب – تهیه و تصویب نمودار سازمانی تیم عقد قرارداد
پ – روشها و راهکارهای ویژه این پروژه
ت – وابستگیها
ث – برنامه های پشتیبانی
ج – مدیریت ریسک (ماتریس شناسایی ریسک و اقدامات لازم برای پوشش ریسک‌ها)
چ – زمان
ح – هزینه ها و جریان نقدی پروژه.