یه قابلیت جالب تو پراجکت 2010 هست که بهش می‌گن Smart Copy & Paste…
ماجرا اینه که پراجکت 2010 انواع ساختارهای سلسله مراتبی رو می‌تونه تشخیص بده. مثلا فرض کنین یه همچین چیزی تو ورد داشته باشین:
این یه مجموعه بولته که سلسله مراتب داره. حالا کلش رو انتخاب می‌کنیم، می‌ریم تو پراجکت 2010، یکی از سلول‌های Name رو انتخاب می‌کنیم و بدون این‌که زحمت خاصی بکشیم پیست می‌کنیم. نتیجه می‌شه این:
یعنی خیلی راحت سلسله مراتب رو ترتیب می‌کنه به ساختار شکست کار. خیلی راحت می‌تونین منابع اطلاعاتی‌ای که تو نرم‌افزارهای دیگه‌ای تهیه شده رو به پراجکت منتقل کنین.
حالا عکس این کار رو هم می‌شه کرد. مثلا می‌شه همون‌ها رو کپی کنیم و ببریم تو اکسل پیست کنیم؛ نتیجه می‌شه این:
من همیشه برای این‌که همچین کاری کنم، علاوه بر اسم‌ها، فیلدهای Ouline Level و Summary رو هم کپی می‌کردم و همچین لیستی را با فرمول و قالب‌بندی خودکار می‌ساختم. حالا از این به بعد دیگه کارم راحت می‌شه.
من همیشه چیزی رو به دوستان و همکاران توصیه کردم، چیزی که بهش می‌گم قاعده ردیابی:
باید گزارش‌ها طوری تنظیم بشن که اگه یک برگشون جدا بشه و جایی تو دنیا پیدا بشه، امکان ردیابی اون و رسیدن به فایل و مشخصات وجود داشته باشه.
این یعنی این‌که مشخصات پروژه، شرکتی که گزارش رو تهیه کرده، اسم فایل، تاریخ و زمان چاپ تو تمام صفحه‌ها باشه. تو فایل‌ها هم باید متادیتای کافی وجود داشته باشه. سیاست خوبی هم برای مدیریت فایل‌ها باشه. مثلا اگه گزارشی رو چاپ کردین تا کسی، حتی از همکارانتون، اون رو کنترل کنه و بعد اصلاحاتی در اون وارد کردین، بلافاصله اون رو با نام جدیدی ذخیره کنین تا فایل قبلی تو جای خودش باقی بمونه (خوشبختانه هارد ارزون‌تر از اونی شده که بخواد معیار قرار بگیره). بهتره انتهای نام هر فایل دو شماره باشه، اولی نسخه فایل و دومی زیرنسخه اون. شماره دوم اونیه که مثل نقل و نبات قراره بره بالا، و اولی اونیه که برای تغییرات اصلی که معمولا همراه با ارائه هست اضافه می‌شه.
احتمالا می‌دونین که پراجکت قابلیتی برای تحلیل پرت داشت. با کمک اون می‌تونستین مدت زمان‌ها رو سه‌نقطه‌ای وارد کنین (مدت زمان خوشبینانه، محتمل و بدبینانه) و بعد دستوری رو اجرا می‌کردین تا مدت زمان اصلی فعالیت با ترکیب دلخواهی از اون سه مدت زمان به دست بیاد. حالت پیش‌فرض میانگینی وزنی از اون سه‌تا بود که وزن مدت محتمل بیشتر بود. علاوه بر اون دو حالت کاملا بدبینانه و کاملا خوشبینانه هم بود.
این تحلیل خیلی ابتداییه و محصول چندانی نداره. می‌شه با داده سه‌نقطه‌ای تحلیل‌های خیلی کامل‌تری تو پرت‌مستر انجام داد. پرت‌مستر می‌تونه با محاسبه مونت‌کارلو ترکیب‌های آماری مقادیر رو محاسبه کنه و با ترکیب اون‌ها توزیع واقعی مدت زمان خلاصه‌فعالیت‌ها و پروژه رو محاسبه کنه. علاوه بر اون‌ها، شناوری‌ها و بحرانی بودن‌ها و خیلی فاکتورهای دیگه رو هم آماری مشخص می‌کنه. ولی هیچکدوم از این خروجی‌ها تو تحلیل پرت پراجکت وجود ندارن.
به هر حال، نکته‌ای که می‌خواستم بگم اینه که الان متوجه شدم این قابلیت از پراجکت 2010 حذف شده! این حذف شدن تو سایت مایکروسافت هم تایید شده، ولی هیچ توضیحی دربارش نیست.
هزار روز شد که این سایت فعالیت می‌کنه! زود می‌گذره…
الان که فکر می‌کنم درست یادم نمیاد که سایت رو دقیقا با چه هدفی ساختم، ولی الان که بهش نگاه می‌بینم که عمده‌ترین کارکردی که داشته، این بوده که حدودا 80 هزار نفری که اطلاعاتی رو تو حوزه برنامه‌ریزی و کنترل پروژه جستجو می‌کردن پذیرفته و امیدوارم که حداقل عده‌ای از اون‌ها مطلبی رو پیدا کرده باشن که دنبالش بودن. تو این مدت حدودا سه هزار ایمیل گرفتم که از من سوال‌هایی پرسیده بودن، و اون‌ها رو با خوشحالی جواب دادم، و باز هم امیدوارم که به بعضی‌هاشون کمکی شده باشه. صادقانه بگم که خودم تقریبا تو هیچکدوم از زمینه‌هایی که کار کردم کسی رو نداشتم که بتونم به این شکل ازش سوال‌هام رو بپرسم، و خوشم میاد از این‌که چنین امکانی رو برای کسای دیگه فراهم کنم.
به هر حال، این رو نوشتم که بگم از داشتن این سایت و ارتباطی که با شما همکاران و هم‌رشته‌هام دارم، خوشحالم.
ترجمه کتاب پم‌باک بعد از 106 روز کار، تموم شد. احتمالا یک هفته طول می‌کشه که مرورش کنم و بعد از اون تحویلش میدم به ناشر. تجربه خوبی بود و از نتیجه کارم راضی هستم.
متن پم‌باک روان نیست و خواننده رو دچار مشکل می‌کنه. خیلی جاها مجبور شدم که برای بهتر فهمیدنِ متن به بقیه استانداردهای PMI مراجعه کنم و گاهی به مراجع دیگه هم مراجعه کردم. سعی کردم متن کتاب فارسی خیلی روان و قابل‌فهم باشه، و به این خاطر تعهدم رو به متن اصلی کم کردم و معیار رو انتقال مفاهیم قرار دادم. خیلی جاها جمله‌ها و حتی پاراگراف‌هایی رو کم و زیاد کردم و زیرنویس‌هایی هم اضافه کردم. می‌تونم ادعا کنم که این ترجمه بیشتر از هر ترجمه دیگه‌ای می‌تونه پم‌باک رو با تمام جزئیاتش به خواننده بشناسونه. یه نکته دیگه که رعایت کردم، این بود که معادل انگلیسی تمام واژه‌ها و اصطلاحات تخصصی رو تو زیرنویس‌ها آوردم تا کسایی که می‌خوان در آینده تو آزمون PMP شرکت کنن راحت‌تر باشن. خوب، این هم از پم‌باک. قبلا برنامه‌م این بود که بعد از پم‌باک برم سراغ ترجمه کتاب راهنمای آزمون PMP ریتا، ولی الان می‌خوام اون رو کمی به تاخیر بندازم و قبلش به پراجکت 2010 ادای دین کنم.
تا حالا خیلی از همکاران به من ایمیل دادن و با من در مورد بعضی مسایلی که تو حوزه برنامه‌ریزی با مدیران مجموعه‌هاشون دارن صحبت کردن. این وسط یه مسئله خیلی مهم وجود داره که می‌خوام اینجا هم بنویسم. برنامه زمان‌بندی یه مدل پیچیده از پروژه‌س، که فهمیدنش، تعبیر کردنش و استخراج اطلاعات صحیح از اون، نیاز به تخصص داره. اگه این برنامه منتشر بشه و در اختیار مدیران و سرپرستان و کارشناسان قرار بگیره، شک ندارم که اشتباهات زیادی به وجود میاد. تو جاهایی که کار کردم همیشه سعی کردم این رو جا بندازم که برنامه دست هیچ‌کس نمی‌ره، به جز کارشناسای واحد برنامه‌ریزی و کنترل پروژه! البته استثنا زمانیه که قراره برنامه تایید و تصویب بشه. بقیه اعضای تیم پروژه فقط باید با گزارش‌های کنترل پروژه سر و کار داشته باشن. واحد برنامه‌ریزی و کنترل پروژه باید گزارش‌های مناسبی تهیه کنه که پیچیده نباشه، سوتفاهم ایجاد نکنه و نیازها رو پاسخگویی کنه. اگه زمانی کسی، جایی و به علتی نیاز به اطلاعات دیگه‌ای داشت، باید اعلام کنه تا به صورت گزارشی دیگه ارائه بشه یا به گزارش اصلی اضافه بشه. و یه نکته. حجم اطلاعات هر گزارشی حد مناسبی داره، که بیشترین درک رو برای مخاطبش به وجود میاره (این حد بستگی به نوع مخاطب داره). اگه اطلاعات کمتر یا بیشتر (بله، بیشتر) از اون حد باشه، کارکرد گزارش افت می‌کنه. مسئله مهم اینه که حد مناسب معمولا خیلی …
تا حالا عده به نسبت زیادی در مورد کاربرد منطق فازی تو مدیریت پروژه باهام مشورت کردن؛ ظاهرا پروژه‌های دانشجویی زیادی تو این حوزه تعریف شده.
من تخصص فوق‌لیسانسم فلسفه منطق و به طور خاص‌تر منطق‌های چندارزشی و فازی بوده (فوق لیسانس من فلسفه علمه). البته یه تفاوت بزرگ بین من و بقیه کسایی که در این مورد کار کردن و پایان‌نامه نوشتن وجود داره؛ من تقریبا می‌شه گفت با منطق فازی مخالفم.
تو پایان‌نامم یه سری دلایل شهودی و اثباتی منطقی آوردم و نشون دادم که منطق‌های چندارزشی و فازی با منطبق دو ارزشی معادل می‌شن. اشتباهی که وجود داره اینه که بعضی‌ها فکر می‌کنن منطق فازی می‌تونه کارهایی انجام بده که منطق دو ارزشی نمی‌تونه انجام بده یا به اون خوبی انجام نمی‌ده. این طرز فکر اکیدا غلطه. شاهدش هم اینه که تمام برنامه‌های فازی دارن تو کامپیوترهای باینری اجرا می‌شن، یعنی اون کاری که قراره منطق فازی انجام بده عملا تبدیل می‌شه به منطق دو ارزشی کلاسیک و به اون ترتیب انجام می‌شه.
منظور من اینه که منطق فازی به درد نمی‌خوره؟
نه کاملا؛ یه ابزاره، برای کسی که می‌خواد مدل‌سازی کنه. اگه راحت‌تر باشه، از اون استفاده کنه بهتره. من خودم ترجیح میدم منطق‌ام هسته کوچکی داشته باشه و برای همین هم منطق دو ارزشی رو ترجیح میدم. البته یه تئوری دیگه هم دارم و اون اینه که منطق دو ارزشی کاملا برعکسِ تبلیغاتی که می‌شه، خیلی به …
مهم‌ترین نکته تو مدیریت پروژه اینه که چطوری منابعِ محدودِ پروژه رو به فعالیت‌های مختلف اختصاص بدیم. راهی که اکثر مدیران در پیش می‌گیرن، چندفعالیته کردن منابعه (multi-tasking) که تقریبا معادل می‌شه با fast tracking. آدما تو کارهای شخصیشون هم همین کار رو می‌کنن. چون باید پنج‌تا کار مختلف رو انجام بدن، یه کم از اولی انجام می‌دن، بعد ولش می‌کنن و میرن یه کم رو دومی کار می‌کنن، بعد برمیگردن سر اولی، میرن سراغ پنجمی، …
درست و غلطش رو نمی‌دونم، ولی بچه که بودم تو مجله دانشمند خونده بودم که درصد به نسبت بالایی از سوخت هواپیما صرف بلند شدنش از زمین می‌شه.
شروع کردن کار منبع زیاد مصرف می‌کنه. وقتی فعالیتی رو دایما متوقف می‌کنیم و دوباره شروع می‌کنیم، برای هر بار شروعش ضرر می‌کنیم. پس چرا وقتی می‌تونیم کاری رو تموم کنیم و بعد بریم سراغ کار بعدی، اون‌ها رو با هم مخلوط کنیم؟ سردرگمی و تنش و اشتباه‌کاری رو هم به دلایل اضافه کنین.
چیزایی که گفتم هم به کارهای پروژه مربوط می‌شه و هم به کارهای شخصی. خودم از وقتی یادمه این مسئله رو تو کارهای شخصیم رعایت کردم. کوانتوم زمان برای من نصف روزه (صبح تا موقع ناهار و بعد از ناهار تا عصر)؛ هر کاری رو که شروع می‌کنم اگه تموم نشده باشه تو کمتر از یه نصف روز نمی‌ذارمش کنار.
روش مدیریت زنجیره بحرانی خیلی خوب روی این مسئله تاکید می‌کنه. عملا دشمن multi-tasking …
توصیه اینه که تعداد فعالیت‌های برنامه رو الکی زیاد نکنین و تاجایی که به برنامه‌ریزی (تعیین روابط) و کنترل (تعیین پیشرفت‌ها) صدمه نمی‌زنه، اون رو کم کنین.
واقعیت اینه که اگه برنامه‌تون رو کسی ارزیابی می‌کنه که کارشناس برنامه‌ریزی و کنترل پروژه نیست، کم بودن تعداد فعالیت‌ها رو به ضعیف بودن برنامه تعبیر می‌کنه.
نتیجه اینه که تو تنظیم ساختار شکست کار و تعداد فعالیت‌ها باید به فرهنگ سازمانی هم توجه کنین؛ باید بدونین جایی که برنامتون رو ارزیابی می‌کنه از چه کارشناسایی استفاده می‌کنه و در چه سطحی هستن؛ اگه مهارتشون تو این حوزه به اندازه کافی بالا نبود، خودتون رو مجاز بدونین که تعداد فعالیت‌هاتون رو الکی زیاد کنین!
یه بار رو همین حساب برنامه‌ای که در حالت مناسبش حدود 500 فعالیت می‌شد رو با 17000 فعالیت تحویل دادم! و باورتون نمی‌شد که ارزیابان گرامی تا چه حد خوشحال شده بودن که شرکت ما تا این اندازه به برنامه‌ریزی و کنترل پروژه اهمیت می‌ده. ولی اگه جایی برای من اون برنامه 17000 آیتمی رو برای کنترل بفرسته، بر می‌گردونمش و می‌گم تعداد فعالیت‌ها رو تا حد مناسبی کم کنن.
آموزش و پرورش تصمیم گرفته که کار تهیه کتاب‌های درسیش رو برون‌سپاری کنه. این کار رو از چند وقت پیش شروع کردن و اگه وبلاگم رو دنبال کرده باشین تا حدی ازش اطلاع دارین.
من کارم رو با کتاب مبانی رایانه شروع کردم که برای فنی و حرفه‌ای بود. این کتاب هنوز تکلیفش مشخص نیست که تایید شده یا رد شده. بعد از اون یه کتاب درباره اکسل یا به قول خودشون صفحه گسترده نوشتم که تایید شد و چاپ شد و الان دست دانش‌آموزاس. کتاب دوم برای کار دانش بود.
چند وقت پیش چنتا مراسم گرفتن و از مولف‌های کتاب‌های درسی تقدیر کردن؛ حسابی هم خجالت دادن آدمو. این تصویر تقدیرنامه‌هاس:
یه عنصر مهم که باید تو گزارش‌ها ارائه کنیم، مقدار تاخیر پروژه و اجزای اصلی اونه. بهتره تاخیر رو بر حسب روز بگیم.
اگه برنامه جبرانی تصویب شده باشه، عملا تاخیرها در زمان تصویب برنامه جبرانی صفر می‌شن. به همین خاطر بهتره که همیشه مشخص کنیم که تاخیرهای گزارش شده از چه تاریخی به بعد هستن. مثلا بگیم که در مدت 85 روز، 14 روز تاخیر به وجود اومده، و حتی می‌تونیم بگیم که این مقدار معادل چند درصد اون زمانه، ولی اگه این کار رو بکنیم مقدار اطلاعاتِ گزارش زیاد می‌شن و این هم خودش نکته منفی‌ایه.
برای هر گزارش باید یه برگ راهنما هم تهیه کنین و اون رو در ابتدای انتشار مجموعه گزارش‌ها ارائه کنین. نیازی نیست که راهنما رو داخل خود گزارش بذارین یا هر دفعه ارائه کنین، فقط کاری کنین که مطمئن باشین همه بهش دسترسی دارن.
باید مفهوم و عملکرد تمام عناصر گزارش رو هم تو راهنما مشخص کنین. در مورد تاخیر می‌تونین همچنین چیزی بنویسین:
تاخیر: اگر ادامه کار با سرعتی معادلِ سرعت برنامه‌ریزی پیش برود (و نه سرعت کنونی)، پایان پروژه به اندازه‌ای که در کادر تاخیر مشخص شده است دیرتر از تاریخ برنامه‌ریزی شده پایان خواهد یافت.
خیلی‌ها فکر می‌کنن که تاخیر به این معنیه که اگه پیمانکار با روند کنونی کارش رو ادامه بده به اون اندازه دیرتر تموم می‌کنه، که خیلی اشتباهه.
یکی از بزرگ‌ترین محصول‌های برنامه‌ریزی و کنترل پروژه، ارائه گزارش‌های وضعیت یا به عبارت دیگه گزارش‌های پیشرفته. این گزارش‌ها باید به بهترین شکلِ ممکن وضعیت پروژه رو نشون بدن تا انواع مدیران بتونن بر اساس این اطلاعات پروژه رو راهبری و مدیریت کنن.
تو یه سری مطلب که با این پست شروع شده، درباره عناصر مفیدی که می‌تونن تو گزارش‌هامون باشن صحبت کنم.
قبل از هر چیز هم باید توضیح بدم که وقتی درباره گزارش پیشرفت صحبت می‌کنم، به هیچ وجه یه گزارش 20 تا 50 صفحه به سبک رایج در نظرم نیست. گزارش پیشرفت از نظر من یک صفحه A4 هست، که معمولا سعی می‌کنم یک رو باشه و گاهی که مجبور باشم از دو طرفش استفاده می‌کنم. دلیلم هم اینه که هرچی گزارش خلاصه‌تر باشه، تاثیرگذاری بیشتری خواهد داشت. البته شکی نیست که از مطالبی که گفته می‌شه می‌تونیم برای اون گزارش‌های گنده هم استفاده کنیم.
خوب، تو این مطلب اول می‌خوام درباره یه چیز خیلی ساده صحبت کنم: تعداد روزهای باقی مونده.
داده ساده‌ایه، ولی خیلی دیدِ خوبی می‌ده. تو هر گزارشی باید مشخص کنیم که چقدر تا پایان برنامه‌ریزی شده پروژه وقت داریم. اگه بلوک‌ها یا فاز‌ها یا ناحیه‌های مختلفی داریم که جداگانه تو گزارش میان و نمی‌تونن از شناوری کل استفاده کنن و حتما باید در تاریخ‌های دیگه‌ای تموم بشن، باید مدت زمان باقیمونده اون‌ها رو هم گزارش کنیم.
ممکنه فرضتون این باشه که گزارشی که تهیه می‌کنین رنگی پرینت می‌شه و واقعا هم این‌طور باشه. ولی این واقعیت رو قبول کنین که از هر گزارشی که تهیه شده باشه نسخه‌های سیاه و سفیدی هم تولید می‌شه؛ مثلا ممکنه در آینده کسایی که به فایل دسترسی ندارن گزارش رو فتوکپی کنن، یا نسخه‌ای که برای کاری دم دستی لازم هست رو پرینت سیاه و سفید کنن تا صرفه جویی کنن.
پس حتی وقتی که گزارشی رو رنگی آماده می‌کنین، طوری طراحیش کنین که سیاه و سفیدش هم خوانا باشه. مهم‌ترین عنصر در این موارد رنگه. سیاه و سفید بعضی رنگ‌ها تمایز کافی ندارن و نباید از اون‌ها استفاده کنین. مثلا آبی و قرمز با این‌که وقتی رنگی هستن کاملا از هم متمایز می‌شن، وقتی سیاه و سفید بشن زیاد با هم فرق نمی‌کنن؛ این در حالیه که مثلا آبی و سبز چنین حالتی ندارن.
رسیدنم به مرز 10 سال سابقه کار در برنامه‌ریزی و کنترل پروژه رویدادیه که خیلی توجهم رو جلب کرده. البته واقعیت اینه که سه-چهار ماهی تا اون زمان باقی مونده، ولی به هر حال دیشب برای بدرقه مسافری به فرودگاه امام، که اولین تجربه کاریم بود، رفتم. 12 سال پیش، هر روز این مسیرِ طولانی رو می‌رفتم و برمی‌گشتم، و الان به عنوان یه استفاده کننده معمولی می‌رم اونجا. یادِ همکارام افتادم، یاد مدیر پروژه بیچارمون که کمی مونده به کارگاه تو جاده تصادف کرد و مرد، یاد این‌که با ماشین تو باندهای فرودگاه رانندگی می‌کردیم و با خودم فکر می‌کردم که یه زمانی به جای ماشین‌های ما هواپیماهای گنده اینجا رفت و آمد می‌کنن و الان همچین موقعیه… یاد خیلی چیزها افتادم.
نکته مهم اینه که از زمینه کاریم خیلی راضیم؛ برام لذت‌بخشه. به راحتی ادعا می‌کنم که در هیچ حوزه کاری دیگه‌ای نمی‌تونستم به این اندازه خوشحال و سعادت‌مند باشم. این جهت‌گیری هم مثل خیلی دیگه از اتفاقاتی که تو زندگیمون میفته اتفاقی بود؛ یه موقعیت کاری تو فرودگاه برام پیش اومد و من هم استقبال کردم. این موضوع کاری، برنامه‌ریزی و کنترل پروژه بود، که هیچی دربارش نمی‌دونستم. من رو می‌خواستن چون می‌دونستن که تو کارهای نرم‌افزاری می‌تونم بهشون کمک‌های زیادی بکنم. تو هفته‌ای که تا شروع کارم باقی مونده بود هرچی کتاب در این زمینه‌ها وجود داشت رو خوندم و کارم رو شروع …
تو مطلب محاسبه پایان پروژه شماره 1 توضیح دادم که چطوری می‌شه تاخیر کلاسیک رو به دست آورد. این محاسبات در اکثر نرم‌افزارها وجود دارد و کاملا هم جا افتاده هستن. با این حال تعبیر خاصی دارن که ممکنه برای ما کافی نباشه.
شاید بخوایم بدونیم که اگه پیمانکار با سرعتی کمابیش مشابه سرعتی که از ابتدای پروژه تا الان داشته کارش رو پیش ببره در چه زمانی پروژه رو تموم می‌کنه.
برای این کار می‌تونیم از شیوه محاسبه ES (مخفف Earned Schedule) استفاده کنیم. الان یه تعداد روزی از آغاز پروژه گذشته (مثلا 140 روز) و پیشرفت واقعی پروژه هم مقداری داره (مثلا 30٪). الان باید برین بگردین و ببینین که پیشرفت برنامه‌ریزی شده در چه تاریخی با پیشرفت واقعی کنونی برابر بوده (مثلا روز 100ام). حالا تعداد روز برنامه‌ریزی رو بر تعداد روز واقعی تقسیم کنین تا شاخصی که SPIt نامیده می‌شه رو به دست بیارین. تو عددهایی که تو این مثال گذشتم مقدار SPIt می‌شه حدود 71٪. معنیش اینه که ما عملا داریم با سرعتی معادل 71٪ سرعت برنامه‌ریزی شده پیش می‌ریم.
خوب، حالا مدت زمان اولیه پروژه چقدر بوده؟ مثلا 500 روز؟ اون رو بر SPIt تقسیم کنین تا مدت زمان تخمینی پایان پروژه به دست بیاد. تو این مثال می‌شه 704 روز.
پس تو این مثال اگه پروژه با سرعتی کمابیش مشابه سرعت کنونی پیش بره، احتمالا حدود 200 روز بعد از پایان برنامه‌ریزی شده تموم می‌شه.
وقتی برنامه رو بعد از وارد کردن اطلاعات واقعی Reschdule کنین، زمان‌بندی جدیدی به دست میارین. این زمان‌بندی وضعیت پروژه رو در شرایط وارد شده نشون می‌ده. یکی از چیزهایی که معلوم می‌شه، تاریخ پایان پروژه‌س که از فیلد Finish خلاصه فعالیت پروژه خونده می‌شه. این تاریخ احتمالا با تاریخ قبل فرق می‌کنه. اگه خط‌مبنا (baseline) ذخیره کرده باشین، می‌تونین این تفاوت رو در فیلد Finish Variance بخونین. مثلا این فید می‌گه که پایان پروژه 30 روز به تاخیر افتاده.
حالا این مقدار تاخیر و این تاریخ پایان جدید چیه؟
اگه پیمانکار ادامه کارش رو از همین لحظه تا پایان کاملِ پروژه با توانی دقیقا برابر با مقدار برنامه‌ریزی شده انجام بده، پروژه در اون تاریخ و با اون مقدار تاخیر تموم می‌شه؛ معنیش اینه.
پس همین‌طوری که دیدین این مقدار کمابیش خوشبینانه‌س و باید همیشه با توجه داشتن به تعبیرش اون رو معنی کرد.
