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

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

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

منشورهای جزئی برای پروژه
منشور در مرحل آغاز پروژه و قبل از تعیین منابع اصلی تنظیم می‌شود. منشور اولی? پروژه نوعاً باید کوتاه، شاید در حد چند صفحه، باشد. تا زمانی که مفهوم اصلی این منشورها تأیید واضح و صریح صلاحیت پروژه و مدیر پروژه باشد، می‌توانند حتی کمتر از یک صفحه نیز باشند.
اسناد طولانی‌تر و دارای ساختار منظم، معمولاً برای موفقیت سازمان و پروژه اساسی هستند. این اسناد جایگزین منشورهای کوتاه اولیه می شوند و به عنوان سند اصلی و راهنمای گروه پروژه عمل می‌کنند. این سیر تکاملی طبیعی است و باید مورد تشویق قرار بگیرد.
چه زمانی حامی باید منشور مجدد صادر کند؟
در پروژهای دیگری که دارای مدیران فرعی یا گروههای رهبری جداگانه نیستند، در آغاز یا پایان هر یک از مراحل پروژه، حامی ممکن است، بخواهد در منشور پروژه تجدید نظر و یا منشور جدیدی را با مجوزهای جدید صادر و تأیید کند. این زمانه فرصتهای مناسبی برای بازبینی منشور در اختیار حامی قرار می‌دهد. منشور اولیه ممکن است دارای چشم‌انداز یا تعریف محدودی باشد.
شکل منشورهای به‌روزشد? پروژه ممکن است با منشور اولی? پروژه تفاوت زیادی داشته باشند. آنها ممکن است حاوی طرحهای دقیق و جزئی‌تری از کار، بودجه‌ها، فهرست مشخص اجزای قابل عرضه و موارد دیگر باشند. این منشورهای به‌روزشده ممکن است دارای صفحات بسیاری بوده و شامل تمام عناصر طرح جزئی پروژه باشند. گاهی اوقات تنظیم طرح و برنامه‌ریزی برای گام بعدی پروژه، یکی از اجزای نهایی قابل عرضه در مرحله¬ای از پروژه محسوب می‌شود.

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

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

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

بخش دوم – راهکارهای دست‌یابی به اهداف پروژه
الف – سازماندهی تیم پروژه
ب – تهیه و تصویب نمودار سازمانی تیم عقد قرارداد
پ – روشها و راهکارهای ویژه این پروژه
ت – وابستگیها
ث – برنامه های پشتیبانی
ج – مدیریت ریسک (ماتریس شناسایی ریسک و اقدامات لازم برای پوشش ریسک‌ها)
چ – زمان
ح – هزینه ها و جریان نقدی پروژه.

منابع
1 – A Guide to the Project Management Body of Knowledge Third Edition (PMBOK ® Guide) چاپ 2004 منتشره بوسیله انجمن مدیریت پروژه امریکا (PMI)
2 - OPM3 (Organization Project Management Maturity Model) Knowledge Foundation چاپ 2003 منتشره بوسیله انجمن مدیریت پروژه امریکا (PMI)
3 – منابع اینترنتی
4 – تجارب اخذ شده در تدوین منشور پروژه برای پروژه‌های مطالعاتی و اجرایی ایران