وقتی تعداد ستون‌های جدول زیاد باشه، دنبال کردن مقادیری که تو یه ردیف هستن خیلی سخت می‌شه. یه راه حل که بعضی‌ها استفاده می‌کنن، اینه که ردیف‌ها رو به تناوب پس‌زمینه می‌دن تا بشه اون‌ها رو دنبال کرد. اینطوری:
یه مقدار بهتر می‌شه. ولی چیزی که می‌خوام بگم، اینه که بهتره اینجور مواقع ردیف‌ها رو یکی در میون رنگی نکنین، اون‌ها رو دوتا در میون رنگی کنین:
به نظر شما اینطوری دنبال کردن ردیف‌ها راحت‌تر نیست؟ تعداد ردیف‌های رنگی کمتره و فاصله‌شون با هم بیشتره، در نتیجه ردیف‌های رنگی رو راحت‌تر می‌شه دنبال کرد. ردیف‌های غیر رنگی هم دو دسته هستن، اون‌هایی که زیرشون ردیف رنگی هست و اون‌هایی که بالاشون ردیف رنگی هست و با همین قاعده ناخودآگاه به راحتی می‌شه دنبالشون کرد.
می‌شه به جای رنگی کردن پس‌زمینه خط‌های افقی پررنگ‌تر بذارین:
الان ردیف‌ها تو ناخودآگاه بیننده سه گروه می‌شن: اون‌هایی که وسط هستن، اون‌هایی که بالاشون خط پهن هست و اون‌هایی که پایینشون خط پهن هست.
هر دو حالت رو می‌تونین به جای این‌که دستی قالب‌بندی کنین، با conditional formatting بسازین.
و یه نکته دیگه؛ می‌دونین که می‌شه جدول و نمودار گانت پراجکت رو تو نسخه ۲۰۰۷ و جدیدتر از اون به همین شکل قالب‌بندی کرد؟
به هر حال، هر کاری می‌کنین بکنین، فقط یه همچین چیزی نسازین:
زیاد پیش میاد که در زمان برنامه‌ریزی اولیه پروژه، یا بعدا در زمان اجرا، لازم باشه که برنامه رو تغییر بدین تا مدتش کمتر یا بیشتر بشه. معمولا دغدغه اصلی کم کردن مدت زمانه، ولی گاهی هم لازمه که بیشترش کرد.
در هر حال، برای خیلی‌ها سواله که چطوری می‌شه این کار رو کرد؛ مثلا مدت زمان فعالیت‌ها رو تو ضریبی ضرب کرد، منابع رو به شیوه خاصی تغییر داد یا …
جواب هیچکدوم از این‌ها نیست. افزایش یا کاهش مدت زمان پروژه تحت شرایط معمولی، اصلا کاری صرفا ریاضی نیست که به تنهایی انجامش بدین. باید شما، همراه با مدیر پروژه و سایر افراد کلیدی پروژه بشینین و تو زمان‌ها، روابط و منابع تجدید نظر کنین؛ یعنی همون کاری که قراره در زمان برنامه‌ریزی اولیه هم انجام داده باشینش.
تو این فرآیند کمک‌های تخصصی زیادی می‌تونین به تیم بکنین. مثلا اگه قراره مدت زمان کوتاه بشه، باید تیم رو هدایت کنین تا متمرکز بشه روی فعالیت‌های بحرانی و نزدیک به بحرانی و اگه قراره تو تعداد منابع تجدید نظر کنین، می‌تونین با کمی تجربه با نگاه کردن به هیستوگرام‌های منابع حدس بزنین که کدوم‌ها تاثیرگذارتر هستن و با چند بار آزمایش و خطا مسیر مناسب رو به تیم نشون بدین. ولی در هر حال، این کار بدون مشارکت تیم پروژه اصلا درست نیست.
چیزایی که گفتم برای وقتیه که واقعا بخواین برنامه‌ریزی کنین، نه این‌که ماجرا صوری باشه.
طبق نظرسنجی سایت ایبوک‌هام، کتاب راهنمای تدوین گزارش‌های پیشرفت پروژه پرطرفدارترین کتاب بین کتاب‌هایی بود که برای آینده در نظر داشتم. به همین خاطر تالیف این کتاب رو شروع کردم و تا الان متن اصلی کتاب تموم شده و چیزی که باقی مونده، چند نمونه گزارش پیشرفت فرضیه که تو پیوست‌هاش قرار می‌گیره.
تو این کتاب گزارش‌های پیشرفت پروژه به این شکل بررسی می‌شن که باید اول انواع محتوایی که قراره گزارش بشه رو انتخاب کنیم (پیشرفت تجمعی، پیشرفت دوره‌ای، تاخیر، عملکرد مالی، آمار نیروی انسانی و …) و بعد یک یا چند شیوه نمایش برای اون‌ها انتخاب کنیم. با ترکیب‌های مختلف این شیوه‌های نمایش انواع گزارش‌های پروژه به وجود میان.
تو این کتاب انواع محتوایی که برای گزارش‌های پیشرفت رایج هست رو فهرست کردم، درباره بایدها و نبایدهاشون صحبت کردم و در نهایت برای هرکدوم یک یا چند شیوه نمایشی ارائه کردم. در آخر درباره ترکیب و تدوین گزارش‌ها بر اساس این عناصر صحبت کردم و این‌که چطور باید گزارش‌های مناسب برای هر گروه از ذی‌نفعان رو تولید کرد. چون فکر می‌کنم که هیچ چیزی جای نمونه‌های کامل رو نمی‌گیره، از هرکدوم از سه نوع گزارش کلی‌ای که توضیح دادم هم یکی تو پیوست ارائه می‌کنم.
این کتاب تا قبل از نوروز به صورت ایبوک ارائه خواهد شد.
برای خیلی از کسانی که پروژه‌هاشون فهرست بهاییه این سوال پیش میاد که می‌شه ساختار شکست کار رو با فهرست بها منطبق کرد یا نه و اگه می‌شه، چطوری.
جوابش از نظر من منفیه؛ ساختار شکست کار و فهرست بها دو مقوله کاملا متفاوت هستن و نمی‌شه اون‌ها رو با هم ترکیب کرد.
اگه ایبوک رایگان راهنمای تدوین ساختار شکست کار رو مطالعه کرده باشین، می‌دونین که یه نکته خیلی مهم در مورد ساختار شکست کار اینه که محصول محور باشه؛ این در حالیه که فهرست بها کاملا کار محوره.
اگه بخواین ارتباط موثری بین فهرست بها و برنامه‌هاتون برقرار کنین (که خیلی هم خوب هست)، راهش اینه که آیتم‌های فهرست بها رو به عنوان منبع برای فعالیت‌ها وارد کنین. ترکیب خیلی خوب و موثری به وجود میاد که اصولی هم هست.
امروز ظهر پیش‌نویس نسخه پنجم استاندارد مدیریت پروژه PMBOK منتشر شد.
از این مرحله به بعد نظر افراد گردآوری می‌شه و بعد از اون ویرایش نهایی نسخه پنجم در پایان سال ۲۰۱۲ میلادی منتشر می‌شه.
تغییرات نسخه پنجم
تغییرات این نسخه نه خیلی زیاد بود و نه خیلی کم. مهم‌ترین ماجرا اینه که حوزه‌های دانش از ۹ حوزه به ۱۰ حوزه تبدیل شدن. حوزه جدید «مدیریت ذی‌نفعان پروژه» است.
اگه با پم‌باک آشنا باشین می‌دونین مدیریت ذی‌نفعان قبلا هم وجود داشت و زیرمجموعه‌ای از مدیریت ارتباطات بود. تو این نسخه استاندارد هم مدیریت ارتباطات و هم مدیریت ذی‌نفعان کمی تفصیلی‌تر شدن و هم این‌که از هم جدا شدن.
در مورد اکثر تغییرات این نسخه باید در نظر داشته باشین که مطلب جدیدی اضافه نشده، بلکه عمدتا ساختار عوض شده. قبلا ۴۲ فرآیند وجود داشت که انواعی از کارها و مهارت‌ها رو تو خودشون جا داده بودن. این مهارت‌ها و کارها الان با کمی تغییر در قالب ۴۷ فرآیند ارائه شده.
نسخه چهارم
نسخه پنجم
فرآیندها
۴۲
۴۷
گروه‌های فرآیندی
۵
۵
حوزه‌های دانش
۹
۱۰
اگه کتاب پم‌باک به زبان ساده رو خونده باشین، دیدین که تاکید زیادی روی تفکیک برنامه‌ریزی به دو سرفصل برنامه‌ریزی مدیریتی و برنامه‌ریزی کاری داشتم. برنامه‌ریزی مدیریتی شیوه برنامه‌ریزی کاری و شیوه کنترل کارها رو مشخص می‌کنه.
تو پم‌باک ۱۲ برنامه مدیریتی وجود داره که در نهایت همراه …
این کتاب مجموعه‌ایه از ۱۹ قاعده که از استانداردها و آیین‌نامه‌های PMI و وزارت دفاع آمریکا استخراج شدن. رعایت اون‌ها کیفیت برنامه‌های زمان‌بندی رو به طور چشمگیری افزایش می‌ده.
رعایت بعضی از این قواعد خیلی ساده‌س و اعتراف می‌کنم که رعایت بعضی‌هاشون هم خیلی مشکله؛ ولی ارزشش رو داره.
حداقل هفته‌ای یک دو نفر به من ایمیل می‌دن تا صحبت کنیم و بین گرفتن مدرک PMP و فوق لیسانس یکی رو انتخاب کنن.
سوال اصلی اینه که کدوم یکی از این دو مفیدتره.
این‌که کدوم مفیدتره از فردی به فرد دیگه فرق می‌کنه، من فقط یه سری از مبانی تصمیم‌گیری که مشترک هست رو می‌گم.
زمان
گرفتن مدرک PMP به نظر من کمتر وقت می‌بره. فکر می‌کنم اکثر افراد با ۱۰۰ تا ۳۰۰ ساعت مطالعه یا آموزش می‌تونن می‌تونن موفق بشن، ولی برای گرفتن فوق لیسانس مدت زمان کلاس‌ها و مدت زمانی که صرف رفت و آمد به دانشگاه می‌شه از این مقدار بیشتره.
هزینه
برای مدرک PMP باید حدود ۵۰۰ دلار برای آزمون هزینه کنین و یه مقداری هم برای سفر به امارات، ترکیه یا کشورهای دیگه. می‌شه حدود ۱۰۰۰ دلار. البته کسایی که ترجیح می‌دن کلاس برن یا پکیج‌های امتحانی بگیرن یه مقدار بیشتر باید هزینه کنن.
این هزینه مجموعا از هزینه فوق لیسانس‌هایی که رایگان نباشن (دوره‌های شبانه، دوره‌های مدیریت صنعتی و …) ارزون‌تر و از فوق لیسانس‌های رایگان گرون‌تره.
حالا نمی‌دونم کلا هزینه براتون چقدر اهمیت داره.
سختی قبول شدن
سختی هرکدوم از این دوتا یه جوره. برای من گرفتن یه فوق لیسانس خیلی سخت‌تر از مدرک PMP هست، چون برای اولی باید خیلی چیزهای متنوعی بخونم، بین اون‌ها حتما چیزهایی هست که خیلی نپسندمشون و در این صورت خوندنشون برام خیلی سخت می‌شه. با این حال سخت‌گیری تو …
ظاهرا فعالیت جدی و برنامه‌ریزی شده تیم PMI برای تهیه نسخه جدید (پنجم) استاندارد پم‌باک شروع شده. احتمالا پیش‌نویسش تا اواسط سال ۱۰۱۲ و نسخه نهاییش تا آخر سال ۲۰۱۲ منتشر می‌شه.
صحبت‌های فعلی درباره اینه که احتمالا نوع و تعداد فرآیندها تغییر چندانی نمی‌کنه و احتمالا گرایش‌های مدرن مثل سیستم‌های Agile هم تا حدی وارد استاندارد می‌شن.
این دومی خودش خبر جالبیه؛ پم‌باک بهترین نمود سیستم‌های مدیریت پروژه کلاسیکه که در مقابل شیوه‌های جدید (چابک، اجایل) قرار می‌گیره. من همیشه این ایده رو داشتم که باید سنتزی بین این دو نوع سیستم به وجود بیاد. حالا خیلی‌ها امیدوارن که این سنتز به صورت تدریجی و قدم به قدم تو استاندارد پم‌باک انجام بشه.
الان یکی از اهداف بزرگ من اینه که بتونم تیم مرکزی بازنگری رو قانع کنم که سهم بالاتری به تمایز زمان‌بندی و مدل زمان‌بندی بدن. به عنوان مثال فرآیندی که الان اسمش «تهیه زمان‌بندی» هست، اصولا باید «تهیه مدل زمان‌بندی» باشه و این تمایز باید تو متن راهنمای اون فرآیند هم منعکس بشه.
در هر حال، امیدوارم نسخه بعدی استاندارد تو این حوزه قوی‌تر بشه.
به‌روزرسانی: لطفا توجه کنین که این مطلب در مورد نسخه قدیمی پم‌باک هست. به زودی مطلب جدیدی برای معرفی پم‌باک بر اساس نسخه هفتم خواهم نوشت.
پم‌باک معروف‌ترین استاندارد جهانی در مدیریت پروژه است و رایج‌ترین معیار برای شکل‌دهی و ارزیابی سیستم‌های مدیریت پروژه به شمار می‌رود. بسیاری از رایج‌ترین تعاریف، اصطلاح‌ها و طبقه‌بندی‌هایی که امروزه در مدیریت پروژه به کار می‌روند از این استاندارد برداشت شده‌اند. به عبارت دیگر، پم‌باک زبان مشترکی جهانی در مدیریت پروژه است.
عبارت پم‌باک (PMBOK) مخفف Project Management Body Of Knowledge است و در فارسی به گستره دانش مدیریت پروژه، پیکره دانش مدیریت پروژه یا به صورت ساده‌تر به دانش مدیریت پروژه ترجمه شده است. منظور از Body Of Knowledge مجموعه‌ای جامع از اطلاعات و مهارت‌هاست که یک حرفه را شکل می‌دهند.
تاریخچه
پم‌باک را موسسه‌ای بین‌المللی و غیر انتفاعی با نام موسسه مدیریت پروژه (PMI) تدوین کرده است. این استاندارد با تلاش گروه بسیار بزرگی از دست‌اندرکاران مدیریت پروژه گردآوری شده و مبنای تدوین آن نیز الگوهای موفق و تجربه‌های این اشخاص بوده است و نه تئوری محض.
اولین پیش‌نویس استاندارد در سال ۱۹۸۷ تهیه شد و نسخه‌های مختلف آن در سال‌های بعد منتشر شدند. آخرین نسخه آن، یعنی نسخه ۴، در اواخر سال ۲۰۰۸ منتشر گردید.
کتاب کم حجمیه درباره استاندارد مدیریت پروژه پم‌باک، که مفاهیم و کلیات استاندارد رو به سادگی توضیح می‌ده. کتاب رو بر اساس بازخوردهایی که از خواننده‌های کتاب‌های قبلیم دریافت کردم و برای کسایی نوشتم که می‌خوان سریع و ساده با استاندارد آشنا بشن و کتاب‌های حجیمی که وارد تمام جزئیات می‌شن براشون جذاب نیست. البته من امیدوارم که با خوندن این کتاب علاقه‌مند به مطالعه بیشتر و حتی گرفتن مدرک PMP بشن. ولی در هر حال، کسایی که می‌خوان فقط بفهمن که کل ماجرای پم‌باک که روز به روز داره بیشتر سر زبون‌ها می‌افته چیه، جواب تمام سوال‌هاشون رو همونجا می‌گیرن.
از زمانی که استانداردهای مدیریت پروژه مثل PMBOK سر زبون‌ها افتادن، ارتباط بیشتری بین برنامه‌ریزی و کنترل پروژه از یه طرف و مدیریت پروژه از طرف دیگه به وجود اومده و کارشناسای برنامه‌ریزی و کنترل پروژه اطلاعات خیلی بیشتری در مورد مدیریت پروژه به دست آوردن.
مشکلی که من دارم تو این مسئله می‌بینم، اینه که هرکس یه مقدار در مورد مدیریت پروژه مطالعه می‌کنه شروع می‌کنه به ایراد گرفتن از کارها و تصمیم‌های هر مدیر پروژه‌ای که می‌بینه. این درسته؟ نه. همیشه این گفته یادتون باشه:
Little Knowledge is a dangerous thing
اطلاعاتی که می‌شه با خوندن کتاب‌ها به دست آورد، اطلاعاتی انتزاعیه، یعنی هر مسئله‌ای رو تو شرایط انتزاعی و با تعداد پارامتر خیلی کم می‌سنجه. این در حالیه که کار واقعی مدیریت پروژه کاملا کانکریته و تعداد پارامترهای موثر در هر تصمیم‌گیری بسیار زیاد هستن.
شکی نیست که هر مدیر پروژه‌ای که پیدا کنین اشتباه‌های زیادی مرتکب می‌شه، ولی تا وقتی که این ماجرا به صورت یه اصل تو ذهنتون باشه، عملا خودتون رو از یکی از مهم‌ترین ابزارهای یادگیری محروم کردین. روی دیگه سکه اینه که هرکدوم از اون‌ها مهارت‌های بالایی دارن و تصمیم‌گیری‌های خیلی خوبی هم می‌کنن که می‌تونه برای شما آموزنده باشه. دقت در کارها و تصمیم‌های مدیر پروژه‌هایی که در اطراف خودتون دارین و تجزیه و تحلیل اون‌ها «با توجه به توصیه‌ها، …
چهار نوع رابطه برای زمان‌بندی وجود داره و اکثر برنامه‌ریزها آزادانه از این چهار نوع استفاده می‌کنن (اشتباه!).
خیلی وقت پیش، وقتی که قرار بود برای یه طرح شیوه‌نامه برنامه‌ریزی تهیه کنم، یکی از بندهایی که گذاشتم این بود که برنامه‌ریز باید سعی کنه اکثر روابطش رو با FS پیاده‌سازی کنه. این رو به این خاطر گفته بودم که به تجربه بهم ثابت شده بود که بقیه روابط شبکه رو ضعیف می‌کنن و نتایجی که تو این حالت از برنامه می‌گیریم کیفیت مناسب ندارن.
مدتی بعد که مشغول خوندن استانداردها شدم، دیدم که PMBOK، استاندارد زمان‌بندی PMI و PRINCE2 همگی تاکید می‌کنن که باید تا جای ممکن از FS استفاده کرد. این ماجرا رویکرد من رو به این ماجرا تاکید کرد.
مدت‌ها بعد از اون گه‌گاه به این ماجرا فکر می‌کردم و تحلیلش می‌کردم، تا جایی که وقتی داشتم یه منبع آموزشی برای پراجکت تهیه می‌کردم، توش از طرف خودم توصیه کردم که سعی کنن بیشتر از ۹۰ درصد روابط رو با FS بسازن، چون تا اون موقع به این نتیجه رسیده بودم که استفاده از سایر روابط معمولا توجیه اصولی نداره و صرفا ناشی از اشتباه برداشته.
نکته جالب اینه که مدتی بعد یکی از دستورالعمل‌های وزارت دفاع آمریکا رو می‌خوندم که به پیمانکارانشون ابلاغ می‌شه. جایی تو اون دستورالعمل گفته بود که اگه تعداد روابط FS یه برنامه‌ای کمتر از ۹۰ درصد باشه، اون برنامه از نظرشون مردوده.
الان در حال تدوین یه مجموعه آموزشی مالتی‌مدیای نرم‌افزار پراجکت برای سازمان فنی و حرفه‌ای هستم. این مجموعه آموزشی نرم‌افزار پراجکت رو همراه با اصول و مفاهیم برنامه‌ریزی و کنترل پروژه توضیح می‌ده. عملا دوره آموزشی رو طوری دارم تنظیم می‌کنم که مخاطب تا پایان دوره دانش و مهارت‌های کافی برای برنامه‌ریزی و کنترل تمام جنبه‌های رایج در پروژه‌های ساده رو داشته باشه.
ویژگی مهم این دوره اینه که صرفا بر قابلیت‌های نرم‌افزار متمرکز نیست و حتی می‌تونم بگم که بیشتر از اون بر اصول و مفاهیم برنامه‌ریزی و کنترل پروژه متمرکزه. یه پروژه ساختمانی رو در نظر گرفتم و از ابتدا تا انتهای کار اون رو همراه با خواننده برنامه‌ریزی و کنترل می‌کنیم.
این مجموعه برای آموزش استاندارد پراجکت در مراکز فنی و حرفه‌ای به کار خواهد رفت. دوره‌هایی تشکیل می‌شه که این مجموعه در اختیار داوطلب قرار می‌گیره تا اون رو بخونه و بعد تو کلاس همراه با استاد مثال‌های بیشتر حل کنه و رفع اشکال کنه. تو پایان دوره هم آزمونی برگزار می‌شه و داوطلب‌هایی که تو آزمون موفق بشن گواهی فنی و حرفه‌ای این نرم‌افزار رو می‌گیرن.
خبر خوب اینه که به من اعلام کردن که نسخه کامل این دوره آموزشی رو تو سایت فنی و حرفه‌ای منتشر می‌کنن تا هر فردی که مایل بود بتونه به طور رایگان ازش استفاده کنه. بنابراین کسانی که به دنبال چنین منبعی هستن گوش به زنگ باشن که بعد …
تو اکثر نرم‌افزارهای برنامه‌ریزی دو جور هزینه وجود داره:
هزینه‌ای که بر اساس کارکرد منابع تعریف می‌شه
هزینه مستقل از منبع
هزینه مستقل از منبع پراجکت تو فیلد Fixed Cost وارد می‌شه. اگه مقداری تو فیلد Cost وارد کنین هم عملا مابه‌التفاوتش با هزینه منابع (اگه وجود داشته باشه) می‌ره تو همون فیلد Fixed Cost.
یه راه دیگه برای تعریف هزینه‌های مستقل از منبع تو پراجکت، استفاده از منابع هزینه هست (منظور Cost Resourc هست). می‌دونم که اسمش به نظر عجیب میاد، ولی این نوع منبع با منابع معمولی، یعنی منابع انسانی و ماشین آلات و مصالح فرق داره و عملا برای پیاده‌سازی هزینه‌های مستقل از منبعه. امتیازش به Fixed Cost اینه که انعطاف‌پذیری بیشتری داره و می‌شه باهاش هزینه‌های ثابت رو دسته‌بندی کرد و …
فقط مشکلش اینه که منابع هزینه تو محاسبات تحلیل ارزش کسب شده در نظر گرفته نمی‌شن. مایکروسافت فلسفه‌ای برای این ماجرا داره، ولی در هر حال باعث می‌شه که این فیلد زیاد کاربردی نباشه.
راه تعریف هزینه‌های مستقل از منبع تو پریماورا، استفاده از expense هست. رفتارش نزدیک به منابع هزینه پراجکته، ولی بر خلاف اون تو محاسبات تحلیل ارزش کسب شده هم میاد.
این از هزینه مستقل از منبع. هزینه وابسه به منبع هم که با منابع تعریف می‌شه.
تو پراجکت دوتا فیلد Fixed Cost Accrual برای هزینه‌های مستقل از منبع و Accrue At برای هزینه‌های …
خیلی وقت‌ها لازمه که برای باقیمانده کارها برنامه تهیه بشه یا اصولا وقتی که برنامه تهیه می‌شه قسمتی از کار انجام شده. خیلی‌ها تو این شرایط فقط قسمت‌های باقیمونده رو تو برنامه وارد می‌کنن و دارم این مطلب رو می‌نویسم که با تمام وجود تاکید کنم که:
گستره برنامه زمان‌بندی تو هر شرایطی باید کامل باشه
اگه از شما می‌خوان که برنامه‌ای برای باقیمونده کارها بنویسین، باز هم باید شامل تمام کارها بشه. می‌تونین یه دسته‌بندی فرعی برای برنامه درست کنین که قسمت‌ها باقیمونده رو جدا کنه یا فیلتری بسازین که فقط باقیمونده‌ها رو نمایش بده.
اگه برنامه‌تون کامل نباشه تو خیلی جاها دچار مشکل می‌شین که شاید مهم‌ترینش محاسبه پیشرفت‌ها باشه. بعدا اگه بخواین روی محاسبه تاخیرها کار کنین هم گرفتار می‌شین.
این متن برای اعلام خبر کتاب جدیدمه، ولی این دفعه یه تفاوت عمد وجود داره: کتاب رو الکترونیکی و رایگان منتشر کردم.
در نتیجه می‌تونین همین الان اون رو دانلود و مطالعه کنین. برای این کار به صفحه معرفی کتاب مراجعه کنین.
کتاب نزدیک به صد صفحه‌س و حجمش هم کمتر از 7 مگابایت.
تو این کتاب هر مسئله‌ای که به تدوین ساختار شکست کار مربوط می‌شده رو توضیح دادم. استانداردهای PMBOK و PRINCE2 و صد البته استاندارد ساختار شکست کار PMI هم توش به تفصیل توضیح داده شده. فکر می‌کنم حتی افراد پرسابقه هم بتونن تو بخش‌های آخر کتاب مطالب جالبی پیدا کنن.
