وبلاگ انجمن مدل سازی اطلاعات ساختمان ایران

چطوری منشور پروژه تهیه کنیم؟

 

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

 

الان اینجا چه اتفاق‌هایی افتاد؟

اول این‌که پروژه به عهده یه مدیر ارشد گذاشته شد. این به این معنی نیست که اون آدم مدیر پروژه می‌شه؛ نه، اون می‌شه مالک پروژه. دلیلش هم اینه که هر پروژه‌ای نیاز نفوذ و قدرت یه مدیر ارشد داره. تو پم‌باک به این آدم می‌گن Sponsor (حامی پروژه) و تو پرینس۲ بهش می‌گن Executive.

اون جایی که تو جلسه بحث نرم‌افزار پیش کشیده شد و بررسی پروژه رو شروع کردن هم می‌شه project mandate (جرقه پروژه).

 

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

حالا خودتون رو بذارین به جای اون مدیر ارشد؛ به نظرتون جالبه اگه کار رو شروع کنین و برین جلو، بعد ببینین که پول کافی برای این پروژه اختصاص نمیدن؟ یا این‌که از اول مشخص بوده که پروژه عدم قطعیت‌های زیادی داره و حتی موفقیت محصولش تضمین شده نیست و با پذیرش این واقعیت پروژه رو شروع کردین، ولی بعد در آخر که محصول موفق نشده شما رو مقصر می‌دونن؟ یا این‌که بقیه می‌گفتن پروژه باید ۳ ماهه انجام بشه و شما می‌گفتین ۶ ماهه و در نهایت احساس کردین همه موافقت کردن که ۶ ماهه باشه، ولی آخر سر میان و به شما می‌گن که چرا ۳ ماهه تموم نشده؟

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

 

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

 

از نظر پرینس۲ همه این کارها می‌شن بخشی از فرآیند راه‌اندازی پروژه (starting up a project).

 

در نهایت، بعد از این‌که قرارداد بین مدیر ارشد و سازمان بسته شد، یعنی منشور پروژه تایید شد، نوبت به قرارداد بین مدیر پروژه و مدیر ارشد میرسه. میدونین این قرارداد چیه؟ این قرارداد همون برنامه پروژس که تو پرینس۲ بهش می‌گیم Project Initiation Documentation (سند آغازش پروژه) و تو پم‌باک Project Management Plan (برنامه مدیریت پروژه). این برنامه تهیه می‌شه و وقتی به تایید برسه یعنی قراردادی بین مدیر پروژه و مدیر ارشد بسته شده؛ مدیر پروژه محصول پروژه رو تهیه می‌کنه و مدیر ارشد منابع رو در اختیارش می‌ذاره. این قرارداد رو می‌شه نسخه تفصیلی منشور پروژه دونست، که در هر حال باید با هم سازگار باشن.

 

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management

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

 

این بخش از کار می‌شه فرآیند آغازش پروژه (initiating a project) پرینس۲.

 

منشور ارتباطات چیست؟

منشور ارتباطات، یک سند رسمی است که شیوه های ارتباطی ترجیحی تیم شما را تشریح می کند. این سند به کاهش پیام های غیرضروری، صرفه جویی در وقت افراد، و بهبود تمرکز و بهره وری در ارتباطات فردی و تیمی کمک می کند.
منشور ارتباطات می تواند شامل موارد زیر باشد:

    اینکه افراد چه وقت باید به ایمیل ها پاسخ دهند و چه وقت نباید.
    اینکه افراد چه وقت باید با استفاده از گزینه "Reply All" به ایمیل ها پاسخ دهند و چه وقت باید از آن پرهیز کنند.
    اینکه جلسات منظم تیمی چگونه سازماندهی شود، چه کسانی باید در این جلسات شرکت کنند، آیا باید به افراد تلفن زده شود، چه نکاتی باید در صورتجلسات درج گردد، چه کسی باید صورتجلسات را به گردش درآورد، و غیره.
    اینکه سازمان شما چگونه با کارفرمایان خود یا با عموم، ارتباط برقرار می کند.
    اینکه اعضای تیم چگونه از طریق رسانه های اجتماعی با یکدیگر تعامل داشته باشند.
    اینکه چه وقت ساخت یک فیلم ویدئویی یا یک تماس صوتی، مناسب خواهد بود.
    اینکه افراد چگونه با دیگران تعامل رو در رو داشته باشند.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management

ایجاد یک منشور ارتباطات، خصوصاً برای تیم های مجازی، مفید است. این منشور به شما امکان می دهد که شیوه های ترجیحی برای ارتباط از راه دور، اینکه چه کسی باید وضعیت به روز شده پیشرفت را ارائه کند، و اینکه چگونه از افراد فیدبک گرفته خواهد شد، را برای افرادتان روشن کنید.

این 12 بخش را در منشور کامل پروژه تعریف کنید

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

    دیدگاه کلی پروژه: منظور از پروژه را بیان کنید. منافع کاری پروژه و اهداف کاری کلی آنرا تشریح نمایید.

    اهداف پروژه: اهدافی را که پروژه به دست خواهد آورد، فهرست کنید. این اهداف باید در راستای اهداف و استراتژی های سازمان باشد.

    محدوده پروژه: بخش محدوده شامل دو قسمت می شود: اقلام قابل تحویل و توضیح مرزها. برای هر قلم قابل تحویل، یک شرح کلی بیان کنید. شفاف نمودن آنچه که پروژه می تواند تولید کند، اما نمی کند، از اهمیت بالایی برخوردار است. در قسمت مرزهای پروژه بیان کنید که چه چیزهایی در درون محدوده پروژه قرار می گیرد و چه چیزهایی در خارج از آن.

    ساعت های کاری برآورد شده (منابع): ساعات کاری مورد نیاز را برآورد کنید و بیان کنید که این برآورد چگونه انجام شده است.

    مدت زمان برآورد شده: با معلوم بودن ساعات کاری می توانید مدت زمان تکمیل پروژه را با فرض اینکه چه تعداد منبع، مورد استفاده قرار خواهد گرفت، برآورد کنید.

    هزینه برآورد شده: هزینه نیروی انسانی را بر مبنای ساعات کاری، برآورد کنید و سایر هزینه ها، اعم از تجهیزات، تدارکات، آموزش، سفر، و غیره، را به آن بیفزایید.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management

    فرضیات مهم: فرضیات، مواردی را شامل می شود که درست بودن آنها را باور دارید، اما در مورد قطعی بودن آنها 100 درصد مطمئن نیستید.

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

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

    وابستگی های پروژه: در این بخش، پروژه های جاری یا متوقف شده ای را که با پروژه شما وابستگی دارند، فهرست کنید. این وابستگی ها باید به اقلام قابل تحویل مربوط باشند، نه به منابع مشترک.

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

    سازمان پروژه: نمودار سازمانی، جعبه هایی دارد که درگیری ذی نفعان مختلف را منعکس می کند. مدیر پروژه، حامی، تیم پروژه، هیئت مدیره، و غیره را فهرست کنید.