# NUPP

اصول کمابیش جهانشمول پروژه

[image]

این نسخه دانلودی به طور خودکار در 2026‑07‑02 بر اساس منوآل آنلاین ساخته شده است. برای دریافت نسخه‌های جدیدتر به سایت مراجعه کنید:

https://omimo.org/fa/modules/nupp/

نوپ محصولی از اومیمو است. اومیمو مجموعه‌ای از ماژول‌های آزاد و حداقلی (مینیمالیست) است. این منوآل را می‌توانید آزادانه بر اساس پروانه Creative Commons Attribution 4.0 International به کار ببرید.

اومیمو با کمک مالی اتحادیه اروپا فعالیت می‌کند. با این وجود، دیدگاه‌های بیان شده در اومیمو صرفا متعلق به اومیموست و نه اتحادیه اروپا.

مترجم: مهرزاد منصورزاده


## مقدمه

NUPP شامل مجموعه‌ اصولی است که برای کسب بهترین نتیجه-ممکن در پروژه ها باید به بهترین شکل ممکن آنها را بکار گرفت، صرفنظر از اینکه کدام متدولوژی‌ یا رویکرد در مدیریت پروژه استفاده میکنیم.

هریک از منابع در دسترس (اعم از نیروی انسانی و متریال و ماشین‌آلات) و متدهای اجرای پروژه به برخی از این اصول NUP (Nearly Universal Principles of Projects) متکی هستند. بااین‌حال، میبایست نکات زیر نیز در نظر گرفته شود :

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

NUPP با همه متدها، سیستم‌ها، منابع و چارچوب‌های اصلی نظیر PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP, Scrum سازگار است. اگرچه ممکن است با تفسیر خاصی از این سیستم‌ها سازگار نباشد. اینجاست که NUPP متخصصین را به تجدید نظر در تفسیرهای خود ترغیب می‌کند.

NUPP مجموعه‌ای از NUP های زیر است:

  - NUP1 — نتایج و صحت آن‌ها بر وابستگی‌ها و تعصب‌ها مقدم اند
  - NUP2 — حفظ و بهینه‌سازی انرژی و منابع
  - NUP3 — همیشه غیرانفعالی رفتار کنید
  - NUP4 — استحکام یک زنجیر تنها به‌اندازه استحکام ضعیف‌ترین حلقه آن است
  - NUP5 — بدون وجود هدف واضح و مشخص دست به انجام هیچ کاری نزنید
  - NUP6 — از اجزا تکرار پذیر استفاده کنید


## NUP1 نتایج و صحت آن‌ها بر وابستگی‌ها و تعصب‌ها مقدم اند

[image]

همه ما به‌طور ذاتی تمایل به عضویت در گروه داریم این میل اغلب از شکل اولیه خود فراتر رفته و با ایجاد وابستگی‌های شدید، مشکل‌ساز می‌شود. بدلیل این وابستگیها، بیش از آنکه از عضویت در گروه منفعتی بدست بیاوریم، متضرر میشویم. با محدود نکردن شخصیت و سلایقمان به گروهی خاص، میتوانیم متخصص حرفه ای تر و کارامدتری باشیم.


### مثال: شیوه اجرای چابک در برابر آبشاری

زمانی که عرفِ مدیریت پروژه، مدیریت با رویکرد متعین (Predictive Approach) بود گروهی از افراد مشتاق و علاقه‌مند شهامت به خرج داده، گرد هم آمدند تا توسعه با رویکرد تطبیقی (Adaptive Development) را در صنعت IT به‌کارگیرند و آن را چابک (Agile) نام نهادند. این کار ابتکاری بزرگ بود تا خودمان را به مواردی که صرفا در نگاه اول ضروری بنظر میرسند محدود نکنیم. اگرچه هنوز، بسیاری از افراد مشتاق و نتیجه گرا عضو جامعه مدیریت چابک (Agile) هستند اما متاسفانه افراد دیگری نیز در این جامعه هستند که Agile را به یک فرقه تبدیل کرده و کسانی که خارج از این فرقه هستند را دشمن می‌پندارند که این کار مشکلات گوناگونی ایجاد میکند از جمله:

  - مانع یادگیری ایشان از افراد خارج از فرقه می‌شود.
  - دیگران را نسبت به یادگیری از خود دلسرد می‌کنند.
  - اهمیت عضویت در گروه را پر رنگ تر از هدف واقعی گروه جلوه میدهند که به‌نوبه خود مانع یادگیری معنای واقعی چابکی (Agility) برای بسیاری از اعضای گروه می‌گردد. این مشکل تا حد قابل‌ملاحظه‌ای کمرنگ تر شده و یا به‌کلی از بین خواهد رفت اگر:
  - Agile را صرفاً یک عنوان برای اشاره به یک رویکرد توسعه‌ای در نظر بگیریم و نه جامعه‌ای از افراد و اعضا
  - افراد خود را سازنده، حلّال مشکلات (Problem Solver) و رهبری بدانند که Agile را به‌عنوان ابزاری توانمند ساز به همراه خود دارند و نه به‌عنوان هویت یا شخصیت خود

برای افراد حرفه‌ای‌ هیچ نزاعی بین Agile و Waterfall در کار نیست.


### مثال: PRINCE2^(®) در برابر PMBOK^(®) Guide

بسیاری از افراد حرفه‌ای در جامعه، خودشان را به یکی از دو رویکرد PMBOK^(®) Guide یا PRINCE2^(®) وابسته می‌دانند (معمولاً به دلیل موقعیت جغرافیاییِ‌شان) و با رویکرد دیگر آشنا نیستند. همه ما می‌توانیم یکی از این دو را به دیگری ترجیح دهیم این سلیقه ماست و نه هویت ما. مهم‌تر اینکه باید تمامی رویکردها را بشناسیم تا افق دید بهتر و حق انتخاب بیشتری داشته باشیم.

یک حرفه‌ای واقعی بدون هرگونه وابستگی و تعصب، تمامی ایده‌ها را با آغوش باز می‌پذیرد، آن‌ها را دنبال کرده و فرامی‌گیرد تا در موقع لزوم از آن‌ها استفاده کند.


### مثال: یادگیری مداوم

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

آنچه امروز باور داریم، تمامِ حقیقت نیست، بلکه صرفاً بهترین درک ما از حقیقت تا به امروز است که باید به‌مرورزمان بهبود یابد. اگر ایده‌های کسی دقیقاً شبیه ایده‌های چند سال قبل او باشد نشان می‌دهد که یک جای کار اشتباه است. این مورد حتی در مورد NUPP هم صادق است یعنی اگر چند سال بعد به آن مراجعه کردید و دیدید همه چیز کاملا شبیه امروز است باید در آن تردید کنید.


### مثال: نقد پذیری

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

ممکن است، کسی عمداً خودتان را به‌جای ایده‌تان هدف قرار دهد در آن شرایط پیش از انجام هرکاری، سعی کنید به او کمک کنید تا، به‌جای شما بر روی ایده‌هایتان تمرکز کند و این روند را در طول مکالمه حفظ کنید.


## NUP2 حفظ و بهینه‌سازی انرژی و منابع

[image]

همانگونه که منابع در طبیعت محدودند، منابع در دسترس پروژه نیز محدود هستند. از آنجا که انرژی ذهنی شما نیز برای اتخاذ تصمیمات مناسب محدود است، شما باید این منبع را برای خودتان و پروژه حفظ کرده و بهینه مصرف کنید و به سایر اعضای گروه نیز کمک کنید تا این کار را انجام دهند.


### مثال: اصل ۸۰/۲۰

80% منافع قابل حصول از انجام فعالیتهای مدیریت پروژه تنها با اندکی تلاش به دست می‌آید. اکثر مواقع دستیابی به 100% مزایای ممکن، بسیار گران‌قیمت و فاقد توجیه اقتصادی است. می‌بایست این قاعده را در تمامی کارهایی که می‌کنید در نظر گرفته و دیگران را نیز به استفاده از این قاعده ترغیب کنید.


### مثال: خستگی تصمیم

همه ما برای انواع تصمیم‌گیری‌ها تنها یک منبع انرژی ذهنی داریم، بنابراین اگر بیش از حد این منبع را برای تصمیمات غیرضروری یا کم‌اهمیت استفاده کنیم انرژی کمتری برای تصمیم‌گیری‌های مهم خواهیم داشت که ممکن است باعث کسب نتایج ضعیف گردد. این، یکی از دلایلی است که باید از میکرو مدیریت (مدیریت تمام جزئیات) اجتناب کنید (اصل “Manage by exception” در PRINCE2^(®))

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


### مثال: مراقبت از خود

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

اعضای گروه را نیز برای انجام اموری مشابه تشویق کنید. ابتدا اطمینان حاصل کنید که آن‌ها با سرعت مناسب و بدون ساعات اضافه‌کاری زیاد کار می‌کنند. سپس سعی کنید درصورتی‌که حق انتخاب دارید از غذا، میان وعده و نوشیدنی سالم و مُقوّی در طول زمان کار استفاده کنید.


### مثال: موازنه کار-زندگی

خیلی از ما عاشقانه شغلمان را دوست داریم اما این تمام آن چیزی نیست که ما در زندگی به آن نیاز داریم. همان‌گونه که برای بهتر شدن کارتان تلاش می‌کنید باید برای داشتن زندگی شاد و مفرح برنامه‌ریزی کنید. هرچقدر شادتر باشید می‌توانید در کارتان هم موفق‌تر باشید. اگر می‌توانید سایر اعضا گروهتان را برای انجام اموری مشابه تشویق کنید.


### مثال: انگیزه

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


### مثال: تشریک‌مساعی و کار تیمی

گاهی ممکن است افرادی که باهم همکاری می‌کنند بتوانند نتایج بهتری خلق کنند اما مهم‌تر آن است که بشر موجودی اجتماعی است و از اینکه عضوی از یک گروه باشد لذت می‌برد. اگر بتوانید جنبه‌های منفی کار تیمی را از بین ببرید و محیط دلپذیری ایجاد کنید اعضای گروه شما در پروژه شادتر خواهند بود.

به تفاوت افراد توجه کنید، برخی نیاز به آرامش بیشتر، تمرکز بیشتر و زمان‌های تنهایی و خلوت بیشتر نسبت به دیگران دارند و باید تعادل را در این زمینه برقرار کرد.


### مثال: فرهنگ تیم واحد

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


### مثال: خرد جمعی

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

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


### مثال: تسهیل‌کننده ارشد پروژه

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


## NUP3 همیشه غیرانفعالی رفتار کنید

[image]

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


### مثال: برنامه‌ریزی

هنگامی‌که می‌خواهید رانندگی کنید تا به مقصد جدیدی بروید و زمان کمی هم دارید، می‌توانید فوراً راه بیافتید تا در زمان صرفه‌جویی کنید و با مشکلات احتمالی -هر زمان که پیش آمدند -دست‌وپنجه نرم کنید. رویکرد غیر انفعالی این است که در آغاز زمانی را برای تنظیم GPS اختصاص بدهید تا به شما سریع‌ترین مسیر را بر اساس وضعیت ترافیکی مسیر و تصادف‌های احتمالی و مسیرهای مسدود، نشان دهد و سپس شروع به رانندگی کنید. این زمان صرف شده قبل از حرکت به‌منظور پیشگیری از مشکلات آتی است بنابراین درنهایت در زمان صرفه‌جویی خواهیم کرد.

برخلاف آنچه برخی تصور می‌کنند برنامه‌ریزی همیشه برای پروژه‌های چابک (Agile) ضروری بوده و تفاوت تنها در نوع و سطح جزئیات موجود در برنامه است. برنامه‌ریزی قبل از اجرا رویکردی غیرانفعالی است.

این ضرب‌المثل را به یاد داشته باشید: اگر برای بریدن یک درخت شش ساعت به من زمان بدهید چهار ساعت از آن را برای تیز کردن تبر صرف خواهم کرد.

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


### مثال: برنامه‌ریزیِ برنامه‌ریزی

برنامه‌ریزی روش اجرای پروژه یک رویکرد غیر انفعالی است. با برنامه ریزی روش تهیه برنامه ای که میخواهیم با آن پروژه را اجرا کنیم می‌توانیم (برنامه‌ریزیِ برنامه‌ریزی) غیرانفعالی بودنمان را توسعه دهیم. این مفهوم عبارت Management Plan در PMBOK^(®) Guide و Management Strategies در PRINCE2^(®) و approach های DSDM^(®) است.


### مثال: برنامه‌ریزی مداوم

بندرت آنچه در واقعیت اتفاق میافتد منطبق بر برنامه است و این طبیعی است اما باید دائماً برنامه‌هایمان را اصلاح کنیم تا اطمینان حاصل کنیم که برنامه‌هایمان کاربردی و واقع‌بینانه است. به‌محض اینکه نیاز به بازبینی و اصلاح احساس شد باید این کار انجام شود نه زمانی که به مشکل برخوردیم. این رویکرد غیرانفعالی است.


### مثال: مدیریت ریسک

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

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


### مثال: تعریف نقش‌ها و مسئولیت‌ها

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

تعداد و تنوع نقش‌ها بسته به نوع و ابعاد پروژه متفاوت است، می‌تواند تعریف ساده‌ای داشته باشد نظیر آنچه در Scrum آمده است و یا تعریف میانه‌ای مانند آنچه در P3.express یا تعریف جامعی نظیر آنچه در DSDM^(®) و PRINCE2^(®) آمده است. به‌هرحال فراموش نکنید که نقش‌های تعریف‌شده در این متدها فقط راجع به فعالیت‌های مدیریتی است و شما همواره نیاز به تعریف نقش‌هایی که جنبه فنی دارند خواهید داشت.


### مثال: انتخاب‌های موجود

آیا باید پروژه را پیش از موعد مقرر خاتمه داد و یا باید آن را ادامه دهیم؟

بندرت پیش میاید که فقط دو گزینه پیشِ رو داشته باشیم حتی اگر از صورت‌مسئله اینگونه بنظر برسد. شما باید رویکرد غیرانفعالی داشته باشید و قبل از تصمیم‌گیری، تمام گزینه‌های ممکن را در نظر بگیرید. شاید بتوانید Scope پروژه را تغییر دهید، شاید بتوانید پروژه را متوقف کنید تا زمانیکه موضوع دیگری شفاف شود یا شاید بتوانید رویکرد پروژه را تغییر دهید (مثلاً برون‌سپاری) و …


### مثال: تفکر انتقادی

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

به‌عنوان یک مرجع می‌توانید از لیست تعصبات شناختی ویکی‌پدیا استفاده کنید.

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


### مثال: شفافیت

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


### مثال: برقراری ارتباطات مؤثر

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


### مثال: مسئولیت‌پذیری

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

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


## NUP4 استحکام یک زنجیر تنها به‌اندازه استحکام ضعیف‌ترین حلقه آن است

[image]

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


### مثال: همه‌چیز با ضرب‌الاجل مرتبط است

فرض کنید که شما در حال ساختِ مکانی برای مسابقات المپیک هستید این کار دارای یک ضرب‌الاجل بسیار جدیِ زمانی است که اهمیت مدیریت زمان را دوچندان می‌کند. آیا موافقید؟

اگر کیفیت آن‌قدر کم باشد که پس از مدتی نیاز به دوباره‌کاری باشد چه؟ پس کیفیت میتواند روی زمان تاثیرگذار باشد. ممکن است در پروژه شما یک باغ فانتزی نیز تعریف شده باشد اما ذکر شده باشد که در صورت کمبود وقت می‌توان از آن چشم‌پوشی کرده و صرفاً آن زمین را چمن‌کاری کرد؛ بنابراین مدیریت محدوده کار (Scope Management) نیز مهم است. پس تا اینجا حوزه‌های زمان و کیفیت و Scope در کانون توجه ما قرار گرفت.

احتمالاً این داستان معروف را شنیده‌اید: زمانی که رئیس‌جمهور آمریکا، آقای کِنِدی از یکی از نگهبان‌های ناسا پرسید چه‌کار می‌کنی؟ او در پاسخ گفت “من اینجا برای فرستان انسان به کره ماه به دیگران کمک می‌کنم” آیا داشتن این‌گونه افراد در پروژه، به تحویل به‌موقع آن کمک نخواهد کرد؟

هر چه بیشتر پیش می‌روید متوجه خواهید شد که هر یک از این حوزه‌ها در مدیریت زمان مشارکت دارند و تازمانیکه شما به همه حوزه‌ها توجه نکنید نمی‌توانید ضرب‌الاجل‌ها را در سطح قابل قبولی از قطعیت برآورده کنید.


### مثال: رفتار گزینشی

وقتی‌که افراد با متدهای متنوع مدیریت روبرو می‌شوند گاهی گزینشی رفتار کرده و هر آنچه از متدهای مختلف برایشان جذاب است را باهم ترکیب می‌کنند. این کار معمولاً بی‌نتیجه است زیرا اجزا به‌تنهایی کار نمی‌کنند، اجزایی که در کنار هم آورده میشود باید با یکدیگر سازگار باشند. هرگونه حذف، اضافه یا تغییر در یک سیستم باید با نگاهی جامع صورت پذیرد.

دلیل آنکه گاهی وقت‌ها اجزا ضد و نقیضی در متدهای مختلف می‌بینیم نیز همین است مثلا میبینیم که یک کار در یک متد خاص نتیجه می‌دهد و متضاد آن در متد دیگر. هر جزء، به‌خودی‌خود صحیح یا غلط نیست.

ایمن‌ترین رویکرد آن است که یک متدولوژی برای پروژه انتخاب کنید، آن را سفارشی‌سازی (Tailoring) کنید و پیوسته با در نظر گرفتن سازگاری آن با کل سیستم، اجزا دیگری به آن اضافه کنید.


### مثال: رویکرد ضد فرآیند

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

شکی نیست که برخی از افراد سعی می‌کنند فرآیندهای پیشرفته‌تر را جایگزین عوامل انسانی کنند اما این تنها نوعی سوءِ رفتار است. حتی به‌طور مشابه افراد مخالف این ایده نیز وجود دارد و برخی در تلاش‌اند تا فرآیندها را با عوامل انسانی جایگزین کنند که این هم نتیجه خوبی نخواهد داشت.


### مثال: تمام حوزه‌هایی که نیاز دارید اینجاست

وقتی به حوزه‌ها فکر می‌کنید باید مراقب باشید که هیچ‌کدام از آن‌ها را از قلم نیندازید. این حوزه‌ها کدم‌اند؟ اگر کتب مرجع را بررسی کنید جواب‌های متفاوتی خواهید یافت ، تا به امروز هیچ‌یک از آن‌ها کل حقیقت را بیان نکرده است.

تم‌های PRINCE2^(®) همان حوزه‌ها هستند اما این تنها دامنه‌هایی است که نقش کلیدی در متدولوژی ایفا می‌کنند مابقی حوزه‌ها صرفاً به‌طور ضمنی اشاره‌شده.

PMBOK^(®) Guide یک متدلوژی نیست و می‌توان آن را با 10 حوزه دانش (Knowledge Area) به‌طور مناسب‌تری فرموله کرد بااین‌حال، این حوزه‌های دانش تفسیری از تمام حوزه‌های پروژه مبتنی بر چشم‌انداز PMBOK^(®) است . به‌عنوان‌مثال PMBOK^(®) به عوامل انسانی توجه چندانی نمی‌کند.

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

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


## NUP5 بدون وجود هدف واضح و مشخص دست به انجام هیچ کاری نزنید

[image]

تا زمانیکه هدف روشنی از انجام کاری ندارید آن را انجام ندهید. دو جهان موازی را تصور کنید که در آن دو، همه‌چیز یکسان است به‌جز کاری که شما برای انجام، در نظر دارید. این دو جهان چقدر تفاوت خواهند داشت؟ آیا این تفاوت ارزش تلاش‌هایی که شما برای اجرای آن می‌کنید دارد یا نه؟

اگر هدف مشخصی در ذهن ندارید و کاری را صرفاً فقط به این دلیل انجام می‌دهید که بقیه نیز این کار را می‌کنند و اینکه دیگران میگویند انجامش مهم است:

  - ممکن است در رابطه با مساله شما واقعاً سودی نداشته باشد بنابراین چیزی نصیب شما نشود.
  - ممکن است برای شما مزایای بالقوه‌ای داشته باشد اما به دلیل آنکه هدفی در ذهنتان ندارید آن کار را به‌گونه‌ای انجام دهید که باعث شود به آن منافع نرسید.


### مثال: پرتفولیو و طرح

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

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


### مثال: کلیت پروژه

انعطاف‌پذیری محصولات در پروژه‌های مختلف، متفاوت است. در برخی پروژه‌های توسعه در صنعت IT، محصول کاملاً انعطاف‌پذیر است و شکل نهایی آن به بازخوردی که از توسعه تدریجی محصول (Increments) می‌گیریم وابسته است که نیازمند رویکرد تطبیقی (Adaptive approach in Agile) است. این عملیات ترکیبی از پرتفولیو، طرح و لایه‌هایی از پروژه است که نیازمند حداکثر توجه به هدف نهایی است. ایده خوبی است که هدف را مستند کرده و در دسترس قرار دهیم، این، یکی از اهداف “Product Vision” است که در برخی از پروژه‌های اسکرام استفاده می‌شود. توجه به ارزش کسب‌وکار (Business Value) در پروژه‌های Agile راهی برای تضمین هماهنگی باهدف است.

در دیگر مدل‌های پروژه که محصول آن‌ها نسبتاً ثابت است برای ارزیابی آنکه محصول شناسایی‌شده می‌تواند ما را به هدفمان برساند یا خیر مکانیسم‌های دیگری وجود دارد و برای اعضا تیم پروژه‌ این امکان وجود دارد که بخش عمده‌ای از تمرکزشان را به‌جای هدف به محصول معطوف کنند (اصل “Focus on Products” از PRINCE2^(®))، اما برای آنکه مطمئن شویم آنچه قرار است ساخته شود ما را به هدفمان می‌رساند همچنان یک توجه حداقلی به هدف موردنیاز است که از طریق مقایسه منافع پیش‌بینی‌شده با منافع کسب‌شده می‌توان به آن دست‌یافت. (اصل “Continued Business justification” و تم “Business Case” از PRINCE2^(®)).

وقتی پروژه‌ای را برای کارفرمای خارج از سازمان انجام می‌دهید، کارفرما هدف خاص خود را از آن پروژه دارد و سازمان شما نیز هدف خاص خود را دارد که این اهداف لزوماً باهم یکسان نیستند. برای کامیابی واقعی در پروژه باید هر دو هدف را درک کرده و مدنظر قرارداد.


### مثال: نظارت بر پروژه

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

وقتی نوبت به نظارت می‌رسد، نظارت جزئی در پروژه با استفاده از جزئی ‌ترین متغیرها انجام می‌گردد چون معمولاً پیگیری هدف نهایی به‌جز از طریق نظارت بر جزئیات امکان‌پذیر نیست. در این شرایط باید همچنان هدف را در ذهن داشته باشید. هدف از نظارت چیست؟

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

سایر ارزیابی‌ها نظیر مقادیر برنامه‌ریزی‌شده (Planned Values) و مقادیر واقعی تا به امروز (Actual Values) صرفاً مقادیر موقتی هستند که برای انجام پیش‌بینی‌ها نیاز دارید و مقادیر نهایی که برای اهداف مدیریتی استفاده می‌کنید نیستند.


### مثال: اسناد

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

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

گاهی اوقات مساله تصمیم‌گیری در خصوصِ لحاظ کردن عنصری خاص در برنامه‌هاست و گاهی در خصوص روش برنامه‌ریزی و یا تهیه چیزی است. چه Business Case باشد، چه Project charter و یا یک گزارش، شما باید همواره از خودتان بپرسید که هدف از تهیه این مدرک یا سند چیست و چگونه به پروژه کمک خواهد کرد.

به دنبال یک الگو (Template) بودن، با انجام کار بر مبنای هدف مشخص در تضاد است.


### مثال: گزارش وضعیت

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

داشتن هدف اغلب اوقات منجر به تولید گزارش‌های بسیار ساده یک‌صفحه‌ای می‌شود که ذینفعان واقعاً آن را مطالعه می‌کنند و نسبت به گزارش‌های طولانی قابل‌فهم‌تر است. این نتیجه توجه به هدف است.

وقتی گزارش‌های یک‌صفحه‌ای تهیه می‌کنید ممکن است برای برخی سو تفاهم پیش بیاید و فکر کنند که سیستم نظارتی مناسبی ندارید. عملاً این کار هدف ثانویه‌ای را نیز به دنبال دارد (در کنار هدف اولیه که کمک به فهم وضعیت پروژه برای ذینفعان است) هدف ثانویه این است که در صورت لزوم بتوانید گزارشات مفصلی را برمبنای آن گزارش یک صفحه ای تهیه کنید. به‌هرحال نباید این هدف را باهدفِ تهیه گزارش اولیه ادغام کرد زیرا هدف از تهیه این دو یکسان نیست.


### مثال: Business Case و Project charter

تهیه مدارکی نظیر Business Case و Project charter برای اکثر مردم معمولاً خسته‌کننده، بی‌فایده است، که صرفاً به دلیل ضرورت‌های بوروکراتیک تهیه می‌گردد در صورتیکه این مدارک همگی دارای اهداف معتبری هستند که در اکثر پروژه‌ها اعمال می‌شود. اگر شما به دنبال یافتن یک الگو هستید تا آن را پرکنید این کار بیهوده است، در حالیکه شما می‌توانید به‌جای آن، هدف واقعی از تهیه این‌گونه مدارک را دنبال کنید، ببینید این مدارک می‌تواند به پروژه شما کمک کند یا خیر؟ و چگونه؟ بعد با هر روشی که دوست دارید مدارک را تهیه کنید تا به هدف موردنظر برسید. در اینصورت خروجیِ آن، مدرک مناسبی خواهد بود.

وقتی به روش تهیه این اسناد برای تأمین اهداف موردنظر می‌اندیشید احتمالاً به تمام سناریوهای ممکن فکر نکرده و برخی از آن‌ها را از قلم خواهید انداخت، به‌منظور پیشگیری از وقوع چنین اتفاقی، می‌توانید بررسی کنید که منابعی نظیر PRINCE2^(®), PMBOK^(®) Guide, P3.express و DSDM^(®) چه پیشنهادی می‌دهند، سپس پیشنهادها را بر مبنای اهداف خودارزیابی کنید.


### مثال: پسا پروژه

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

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

نظارت پسا پروژه یک گام ضروری برای هدف محور بودن است. اساساً مسئولیت این کار، بر عهده سیستمهای مدیریت پرتفولیو و مدیریت طرح است اما ازآنجاکه بسیاری از شرکت‌ها این‌گونه لایه‌های مدیریتی را در خود ندارند این گام‌ها معمولاً مورد غفلت واقع می‌شوند. به این دلیل است که متدهایی نظیر P3.express و DSDM^(®) این گام را به متدولوژی‌های مدیریت پروژه خود اضافه می‌کنند.


### مثال: سادگی

دنیا پیچیده و بی‌نظم است، اما مدل‌های ما تقریباً انتزاعی بوده و بخشی از این دنیا را منعکس می‌کنند تا برای ما ساده تر شود. از سوی دیگر، سیستمهای ساده معمولاً بهتر کار می‌کنند، چون می‌توانیم روی ایده اصلی بهتر متمرکز شویم.

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


### مثال: سفارشی‌سازی

شرایط یک نرم‌افزار ساخت و ویرایش موسیقی نسبت به نرم‌افزاری که برای تجهیز بیمارستان و یا هواپیما تهیه می‌شود که با جانِ افراد سروکار دارد یا نرم‌افزار تهیه شده برای استفاده در ماهواره‌هایی که قرار است سال‌های سال بدون مشکل کار کند متفاوت است و همه آن‌ها با ساخت یک ویلای تابستانی، ایستگاه آتش‌نشانی یا یک کارخانه تفاوت دارند.

وقتی هدفی در ذهن داشته باشید درک بهتری از نحوه سفارشی‌سازی سیستمها و مصنوعات (Artifacts) برای پروژه‌های مختلف دارید.


## NUP6 از اجزا تکرار پذیر استفاده کنید

[image]

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


### مثال: چک‌لیست‌های کیفی

چک‌لیست یک نمونه ساده از اجزایی است که پتانسیل تکرارپذیری را دارد که خیلی از افراد در زندگی شخصی و کاری خود از آن استفاده می‌کنند، به‌عنوان‌مثال:

  - در ابتدای پروژه در وهله اول احتمالاً چک‌لیستی از تمامی معیارهای لازم تهیه می‌کنید که این، یکی از انواع برنامه‌ریزی است.
  - آنچه NUP 6 توصیه می‌کند این است که “تعمیم دهید”. بررسی کنید که آیا اقلام تحویل شدنی (Deliverable) مشابهی در پروژه وجود دارد؟ در صورت وجود، یک چک‌لیست برای کیفیت آن دسته از اقلام تهیه کنید و از آن برای همه اقلام تحویل شدنی استفاده کنید. اگر اختلافاتی وجود دارد، لیست عمومی را حفظ کنید و چند مورد اضافی برای آن تحویل شدنی خاص به آن بیفزایید. تا به یک چک‌لیست‌ تکرارپذیر برسید.
  - زمانی که شما چک‌لیست‌های عمومی را برای انواع مختلف اقلام تحویل شدنی تهیه می‌کنید ممکن است با اجزایی برخورد کنید که زیرِ آن‌ها تکرار می‌شوند در این شرایط بجای تکرار آیتم‌ها برای تمامی چک‌لیست‌های عمومی، می‌توانید آن‌ها را بیرون کشیده و به چک‌لیست‌های عمومی اضافه کنید. درنهایت احتمالاً یک چک‌لیست عمومی منحصربه‌فرد برای کل پروژه خواهید داشت. “Definition of done” در اسکرام یک مثال برای استفاده از چک‌لیست‌های کیفی در سطح پروژه است. با این کار هر تحویل شدنی، متعلق به یک سلسله‌مراتب از دسته‌بندی‌ها خواهد بود و می‌بایست الزامات موجود در چک‌لیست‌های متعلق به دسته‌بندی‌های زنجیره خود را رعایت کند.

به این ترتیب آیتم‌های موجود در چک‌لیست مادر، برای تمامی تحویل شدنیهای زیرمجموعه آن تکرارپذیر می‌شوند که باعث صرفه‌جویی در زمان و انرژی حین برنامه‌ریزی و اجرا خواهد شد.

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


### مثال: فرآیندها و گردش کارها

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

پروژه‌های Agile ، اجزا تکرارپذیر دارد که در رویکرد توسعه گام‌به‌گام (Iterative Development Approach) فعالیت‌های توسعه‌ای مشخصی برای هر قابلیت (Feature) تکرار می‌شود. مثلاً روال معمول روزانه در XP(eXtreme Programming) عبارتند از: جفت کردن، انتخاب یک آیتم، طراحی آن بر روی تخته وایت برد، ساخت اسکریپتها و کدهای آزمایشی و یکپارچه‌سازی کدها و …

در کنار گردش کارهای تکرارپذیر که می‌تواند برای فعالیت‌های فنی استفاده شود، شما می‌توانید برای فعالیت‌های مدیریت پروژه نیز فعالیت‌های تکرارپذیر داشته باشید. فرآیندها در PMBOK^(®) Guide، PRINCE2^(®) و DSDM^(®)، فعالیت‌ها در P3.express و رویدادها در Scrum مثال‌هایی از این مفهوم هستند.


### مثال: چرخه‌ها

داشتن اجزا تکرارپذیر در مدیریت پروژه مفید است. با قرار دادن این اجزا در چرخه‌های تکرارپذیر می‌توان باز هم آن ها را ساده‌تر کرد. این چرخه‌ها به میزان قابل‌توجهی فعالیت‌های روزمره افرادِ درگیر در مدیریت و رهبری پروژه را تسهیل می‌کند. چرخه ی Process group های PMBOK^(®) Guide وقتی در پروژه‌ای با فازها و مراحل چندگانه استفاده میشود Stage ها در PRINCE2^(®)، چرخه‌های روزانه و هفتگی و ماهیانه در P3.express، تکرارها و Timebox ها در DSDM^(®) و اسپرینت‌ها در اسکرام همگی مثال‌هایی از این مفهوم هستند.

چرخه‌های کوتاه‌تر قابل‌فهم‌تر و قابل‌استفاده‌تر از چرخه‌های طولانی‌مدت هستند. مثلاً اسپرینت ها در اسکرام در مقایسه با فازهای پروژه در PMBOK^(®) Guide. بااین‌حال چرخه‌هایی که خیلی کوتاه‌اند ممکن است برای پشتیبانی از برخی از پروژه‌ها مناسب نباشد و راه‌حل آن می‌تواند استفاده مکرر از چرخه‌ها باشد مثلاً استفاده از چرخه‌های کوتاه Timebox همراه با چرخه‌های تکرار طولانی‌تر در DSDM^(®)، یا استفاده از چرخه‌های روزانه و هفتگی و ماهیانه در P3.express.


### مثال: متدها

استفاده از متدلوژی‌ها و چارچوب‌ها برای اجرای پروژه‌ها کاربرد دیگری از اجزا تکرارپذیر است خواه یکی از سیستمهای موجود نظیر PRINCE2^(®)، DSDM^(®)، P3.express یا Scrum باشد یا سیستمی که شما برای خودتان ساخته یا سفارشی‌سازی کرده‌اید، اگرچه معمولاً بهتر است به جای آنکه متدی را از ابتدا بسازید، با یکی از متدهای موجود کارتان را شروع کنید و آن را با نیازهایتان وفق دهید.

همه اجزا تکرارپذیر خلاصه بوده و نیاز به سفارشی‌سازی و تطبیقِ آن با دنیای واقعی دارید؛ طیفی از مفاهیم و نیازها برای سفارشی‌سازی وجود دارد، چک‌لیست‌های کوچک و نسبتاً خشک در یک سمت این طیف با کمترین میزان انتزاع و نیاز به سفارشی‌سازی و متدولوژی‌ها با بیشترین میزانِ نیاز به سفارشی‌سازی در سمت دیگر این طیف قرار دارند. همواره باید نیاز به سفارشی‌سازی موردتوجه قرار گیرد در غیر این صورت اجزا تکرارپذیر به‌خوبی پاسخگوی نیازتان نخواهد بود.