اقلام قابل تحویل پروژه (Deliverables)
اقلام قابل تحویل در یک پروژه يكي از مهمترین مباحث مهندسي صنايع مي باشد و همچنين كاربرد بسياري در بازار كار مهندسي صنايع خصوصا در زمینه مدیریت پروژه دارد. آموزش مفهوم اقلام قابل تحویل يكي از مهمترين سرفصل ها در دوره هاي آموزشي مهندسي صنايع مي باشد.
اقلام قابل تحویل در استاندارد PMBOK بدین صورت تعریف شده است:
نتیجه یا خروجی ملموس و عینی یک یا چند بسته کاری است که قابل اندازه گیری و صحه گذاری بوده و انجام بخشی از پروژه منوط به تکمیل و تحویل آن است.
همچنین تحویل شدنی ها در استاندارد ساختار شکست کار PMI به این صورت تعریف می گردد:
محصول، نتیجه یا قابلیتی منحصر به فرد و قابل ارزیابی است که وجودش برای تکمیل یک فرآیند، فاز یا پروژه لازم است. معمولا تحویل شدنی در مفهوم خاص تر به معنای تحویل شدنی های خارجی به کار میرود، یعنی تحویل شدنی هایی که باید به تایید کارفرما یا حامی برسند.
تهیه ملات سیمان منحصر به فرد نیست، در حالی که نصب شیرآلات یک طبقه منحصر به فرد است. البته مفهوم منحصر به فرد بودن قابل تفسیر است، مثلا ملات سیمانی که در زمانی خاص و برای منظور خاصی تهیه شده است را می توان منحصر به فرد در نظر گرفت. آیا دستگیره های در خودرویی که روزانه در یک کارخانه ساخته می شوند منحصر به فرد هستند؟ می توان آن ها را به حدی دقیق بررسی کرد که منحصر به فرد بود نشان مشخص شود، ولی این شیوه برخورد نیز معنا ندارد و آن ها را منحصر به فرد نمی دانیم و به همین خاطر کار کارخانه را نیز از نوع پروژه نمی دانیم، زیرا محصول پروژه باید منحصر به فرد باشد.
قابل ارزیابی بودن نیز اهمیت فراوانی دارد. این مفهوم نیز کاملا معین نیست و نیاز به تفسیر دارد. “نصب تمام شیرآلات یک طبقه” خیلی بیشتر از “نصب نصف شیرآلات یک طبقه” قابل ارزیابی است فرض کنید قرار است کامل شدن این دو تحویل شدنی را شخصا ارزیابی کنید. آیا ارزیابی نصب نصف شیرآلات یک طبقه به سادگی ارزیابی نصب تمام شیرآلات یک طبقه است؟ به همین دلیل نصب تمام شیرآلات یک طبقه برای در نظر گرفتن به عنوان تحویل شدنی مناسب است، در حالی که نصب نصف شیرآلات یک طبقه تحویل شدنی چندان مناسبی به شمار نمی رود.
امروزه در دنیا مدیران پروژه دریافته اند که راه نتیجه گرا بودن یک پروژه درگرو تمرکز روی اقلام قابل تحویل می باشد. مهمترین و اولین تکنیکی که می تواند باعث شفاف سازی روند تعریف تحویل شدنی ها گردد، نمودار WBS است. به همین دلیل تعریف جدید نمودار WBS به شرح زیر خواهد بود:
نمودار WBS یک نمودار سلسله مراتبی با نگرش شناسایی و تعریف اقلام قابل تحویل (Deliverable-Oriented) است که محدوده کل پروژه را تعریف میکند.
تحویل شدنیها باید برای ذینفعان عینی، دست یافتنی و قابل اندازه گیری بوده و ماهیت شعارگونه نداشته باشند.
نمونه هایی از اقلام قابل تحویل پروژه: محصولات، تجهیزات و ماشین آلات، نرم افزارها، دستورات، گزارشات و جداول، مقاله، کتاب، نمونه آزمایشی و …
تحویل شدنی های پروژه باید منطبق بر قرارداد و منشور پروژه باشد. در تهیه نمودار WBS باید سعی بر این باشد که بین آنچه که باید تحویل داده شود و آنچه به عنوان نیاز مشتری در قرارداد ذکر گردیده انطباق خوبی برقرار شود. همچنین تحویل شدنی ها در WBS باید کاملا شفاف باشند.
معمولا منظور از تحویل شدنی، تحویل شدنی های خارجی است، یعنی محصول هایی میانی که باید به تایید رسمی حامی یا کارفرما برسند. تحویل شدنی هایی که باید به تایید کارفرما برسند معمولا اهمیت مدیریتی بالاتری دارند و به این خاطر بهتر است که در سطوح بالای ساختار شکست کار قرار بگیرند. در مرحله بعد تحویل شدنی هایی قرار می گیرند که به تایید رسمی کارفرما نمی رسند، ولی باید به تایید مدیران ارشد پیمانکار (که حامی نماینده آن ها به شمار می رود) برسد. این تحویل شدنی ها معمولا در سطوح میانی ساختار شکست کار قرار می گیرند. در نهایت تحویل شدنی هایی در سطوح پایین قرار می گیرند که عمدتا اهمیت فنی دارند و نه مدیریتی و صرفا به تایید مدیر پروژه یا حتی سرپرستان زیرمجموعه وی می رسند. بسیاری از این تحویل شدنی ها برای کارفرما معنای خاصی ندارد و توجه وی عمدتا معطوف به تحویل شدنی های عمده ای است که در سطوح بالای ساختار قرار می گیرند.
تکمیل تدریجی تحویل شدنی ها اهمیت فراوانی دارد، زیرا اعتماد کارفرما را نیز افزایش می دهد. در PMBOK بر لزوم تحویل تدریجی تحویل شدنی ها تاکید شده است. برخی با تصور سرعت گرفتن انجام کارها شروع به اجرای موازی کارها میکنند که اصطلاحا به آن fast track میگویند که اینکار باعث پایین آمدن کیفیت تحویل شدنی ها میگردد.
در استانداردهای کلاسیک پروژه های نرم افزاری سامان دهی پروژه به نحوی انجام می شد که تحویل شدنی ها عمدتا یکباره تکمیل می شدند. امروزه استفاده از روش های چابک در مدیریت پروژه های نرم افزاری رایج شده است و در حال حاضر روش موفق تری به شمار می رود. یکی از مهم ترین تفاوت های این روش با روش های کلاسیک مدیریت پروژه های نرم افزاری در این است که تاکید بسیار زیادی بر شکستن پروژه به تحویل شدنی های کوچک و تکمیل تدریجی آن ها دارد. به این ترتیب هم اعتماد کارفرما افزایش می یابد و هم تغییرات بهتر مدیریت می شوند، زیرا با تکمیل تحویل شدنی های کوچک، تغییرات احتمالی مد نظر کارفرما زودتر کشف می شوند و دوباره کاری ها محدودتر خواهند شد.
با سلام… آیا امکان قرار دادن مطالب کاربردی در رابطه با Prince II در کانال تلگرام وجود دارد؟ البته مطالب که قابلیت پیاده سازی در سازمان داشته باشد و صرفا توضیحی و توصیفی نباشند. بسیاری از مطالب آموزش که در کانالهای تخصصی ارایه میشوند، جنبه توصیفی داشته و امکان اینکه بعنوان یک نقشه راه عملی بتوان از آن در یک محیط واقعی (مثلا یک پروژه ساخت و ساز) بطور عملیاتی استفاده کرد، وجود ندارد. متشکرم.