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