X
تبلیغات
رایتل
سه‌شنبه 8 آذر‌ماه سال 1390

زمان‌بندی پروژه‌‌ درست طراحی نشده بود

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

دلایل شکست پروژه‌ های IT

علی قادری*
ghaderi.ali@gmail.com
تحقیقات اخیر نشان داده است که حدود 62 درصد پروژه‌های IT در زمان تعیین شده و یا با هزینه پیش‌بینی شده نتوانسته‌اند به انجام برسند.
در واقع بسیاری از پروژه‌های IT قبل از اتمام، لغو شده و یا اصلاً پیاده‌سازی نشده‌اند.

طبق آمار ماه آگوست 2007 ، از این میان، 49 درصد پروژه‌ها دچار مشکل افزایش بودجه لازم، 47 درصد دچار مشکل هزینه‌های نگهداری پیش‌بینی نشده و 41 درصد دچار مشکل عدم جوابگویی نیازها شده‌اند.
دلیل عمده شکست این پروژه‌ها مربوط به مدیریت پروژه (Project Management) می‌باشد.

به طور کلی پروژه‌های IT بر اساس موفقیت به سه طبقه کلی تقسیم می‌شوند:
• Successful Projects : پروژه‌هایی که به موقع و با هزینه تعیین شده و نیز با کلیه ویژگی‌های تعریف شده به پایان رسیده‌اند.
• Failed Projects : پروژه‌هایی که لغو شده و یا به مرحله پیاده‌سازی نرسیده‌اند.
• Challenged Projects : پروژه‌هایی که با هزینه و یا زمان بیشتر و یا قابلیت‌های کمتری،انجام و به بهره‌برداری رسیده‌اند.

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

به طور کلی دلایل اصلی شکست پروژه‌های IT عبارتند از :
1)-Poor Planning (طرح ریزی ضعیف)
2)-Unclear Goals and Objectives (اهداف و مقاصد غیرشفاف و نامشخص)
3)- Objective Changes during Projects (تغییرات اهداف پروژه در حین انجام آن)
4)-Unrealistic Time or Resource Estimate (پیش‌بینی غیرواقعی زمان و یا منابع پروژه)
5)- Lack of Executive Support and User Involvement (نقصان پشتیبانی اجرایی و درگیر نمودن کاربران در پروژه )
6)- Failure to Communicate and Act as a Team (شکست در ایجاد ارتباط مدیر پروژه با تیم پروژه)
7)- Inappropriate Skills (تجربه‌های ناکافی و غیرمقتضی تیم پروژه)
8)- Lack of Testing and QA(Quality Assurance) standards(نقصان استانداردهای تست و تضمین کیفیت)
9)- Users and Organizations Resistances (مقاومت‌های کاربران و سازمان‌ها در پذیرش سیستم‌های جدید)

نتیجه‌گیری:
مدیران پروژه می‌توانند با رعایت توصیه‌های زیر احتمال شکست پروژه‌ها را کاهش دهند:
• توجه به موارد بحرانی موجود در پروژه و نیز مدیریت تغییرات (Changes Management)
• انجام فرآیندهای لازم جهت برخورد با ریسک‌های موجود در پروژه
• مشخص ساختن اهداف پروژه به صورت شفاف
• عدم استفاده از تخمین خطی در پیش‌بینی زمان و منابع پروژه
• پشتیبانی گرفتن از مدیریت اجرایی پروژه و ارتباط مستمر با تیم پروژه
• کسب اطمینان از وجود تجارب طرح‌ریزی و استفاده از تکنولوژی‌های و راه حل‌های مناسب
• ایجاد پروسه تست و تضمین کیفیت پروژه‌ها(Projects Quality Assurance)

*مدرس دانشگاه

منبع:ایتنا

جمعه 26 بهمن‌ماه سال 1386

تجربیات یک مدیر پروژه موفق

نویسنده : www.computerworld.com
مترجم : یاسمن حریری

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

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

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

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

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

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

از آن جایی که انتظار دارم گونه‌های متعددی از تست بر روی پروژه‌ها صورت گیرد، نمی‌توانم تنها از "تکمیل تست" به عنوان مرحله‌ای مهم نام ببرم. به عنوان مثال، زمانی که می‌گویم «کارکرد یک» تکمیل شد، فهرستی به شرح زیر ارایه می‌دهم:

  • کد «کارکرد یک» بدون اخطار بر روی تمامی پلاتفرم‌ها کامپایل می‌شود.
  • تست‌های واحد «کارکرد یک» مورد بررسی قرار گرفته و اجرا می‌شوند.
  • Smoke Test تستی که به سرعت و برای مرور دوباره‌ی سیستم و آگاهی از نقاط ضعف آن صورت می‌گیرد) «کارکرد یک» انجام شد«.
  • کارکرد یک» مورد آزمون قرار گرفته و تعریف شد. تست با موفقیت صورت گرفت.

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

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

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

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

منبع :www.systemgroup.net

جمعه 15 تیر‌ماه سال 1386

آموزش مدیریت پروژه های IT- قسمت اول

پروژه چیست؟

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

-    هر قسمت از کاری که در سازمان انجام می گیرد را یمتوان یک پروژه دانست به شرطی که مشخصات زیر را داشته باشد: 1- افق زمانی مشخص

    2- مجموع خوب و تعریف شده و واضح از ستاده ها

    3- مجموعه ای از منابع

    4- دلیلی برای وجود آن کار

    5- ساختار سازمانی که نشان دهنده نقش ها و مسئولیت های خاص است.

      - پروژه مسئله ای است که د رجریان حل قرار گرفته باشد.

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

 

انواع پروژه:

1-      پروژه مطالعاتی

2-      پروژه خدماتی

3-      پروژه اجرایی

 

ارکان پروژه

کارفرما: کارفرما در حقیقت مالکو صاحب اصلی پروژه محسوب می شود.

مشاور: مشاور بازوی فنی کارفرما است.

پیمانکار: اجراکننده پروژه می باشد.

 

مزایده: عملی برای فروش عمده کالا ی مورد نظر به بالاترین قیمت ممکن می باشد.

مناقصه: عملی برای انتخاب پیمانکار یا خرید خدمات با پایین ترین قیمت ممکن است.

 

مراحل انجام پروژه:

1-      مطالعات مرحله یکم- مطالعات توجیهی

2-      مطالعات مرحله دوم- طرح تفضیلی

3-      اجرا

 

پنج‌شنبه 10 خرداد‌ماه سال 1386

مدیریت خلاق برای موفقیت پروژه

مدیریت خلاق برای موفقیت پروژه





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

خلاقیت می تواند مدیریت شود آن می تواند تمرکز گرا باشد و آن می تواند دلیلی برای موفقیت پروژه ها باشد. TRIZ یک روش برای حل مساله است که توانایی تیم پروژه در حل ریسکهای ایجاد شد در مساله را تسریع می کنند .(Tate and Domb 1997). TRZ مخفف روسی تئوری حل خلاقانه مساله است. این روش توسط آلتشولر و هم دانشگاهی هایش توسعه داده شده است. آن اکنون یک علم بین المللی خلاقیت است که به الگوهای مسایل و راه حل ها متکی است.
بیش از 8/2 میلیون الگو تجزیه و تحلیل گشته تا الگوههای مربوط به راه حل های مسایل فنی استخراج گردند.
تحقیقات TRIZ با بیان این فرضیه آغاز می شود که یکسری اصول جهان مشمول اختراع وجود دارد که مبنایی برای نوآوری خلاق با استفاده از تکنولوژی های پیشرفته می باشد . این بدین معنی است که اگر این اصول تعریف و شناسایی گردند می توانند به تفکر افراد در ایجاد فرآیندهای مبتنی بر نوآوری به صورت قابل پیشبینانه تری عمل نمایند . این تحقیق در طی چندین مرحله در طول 50 سال گذشته تکامل یافته است , سه یافته اصلی از این تحقیق در زیر ارائه می شود:

1- مسایل و راه حل هایی که در میان صنایع و علوم تکرار شده بودند.
2- الگوهای تکامل فنی که در میان صنایع و علوم تکرار شده بودند.
3- نوآوری های استفاد شده توسط علوم خارج از زمینه ای که آن علوم توسعه یافته بودند.

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

شکل 1 این فرآیند را به صورت گرافیکی توصیف می کند:


شکل (1) : روش حل مساله با استفاده از TRIZ

نوآوران مساله خود را با مسایل عمومی TRIZ مطابقت می دهند, سپس راه حلهای عمومی TRIZ برای حل آن مساله را با راه حلی که خود پیشنهاد می دهند مقایسه می نمایند. با این روش , TRIZ آزمایشهای لازم را کاهش می دهد و موثرترین راه حل برای مساله مورد نظر را که مستقل از صنعتی خاص است , ارائه می کند.
برای مثال دلیل قاطع این روش از صنعت دارو سازی استخراج شده است(Anderson 1997 )

مطابق جریان شکل 1 , مساله ویژه به شرح زیر می باشد:

باکتری تیلور برای انتشار هورمونهای انسانی استفاده می شود , تولید یک محصول برتر که آن از منابع حیوانی تصفیه و استخراج می گردد. تولید نمودن محصول , مقادیر خیلی زیاد سلولهای باکتری تیلور که پرورش داده می شوند, سپس سلولها باید شکسته شوندو مواد دیواره سلول از بین رود, بطوریکه هورمونهای مفید بتوانند فرآورده شوند. یک روش مکانیکی برای گسیختگی و شکستن در مقیاس معقول برای بعضی زمان ها استفاده شده بودند, که بازده این روش 80درصد و متغیر بود. بحران جاری بازده را به 65 درصد کاهش داده و یک دوره طولانی مساله پیش بینی برای سعی در مقیاس تولید بالا و نرخ زیاد بود اما بازده باید خیلی بیشتر از 80 درصد شود.
مساله استاندارد TRIZدر بالاترین سطح , یک روش برای تولید نمودن محصول بدون ضایعات و بازده حدود 100 درصد پیدا نمود. فرمول بندی به عنوان یک راه حل استاندارد TRIZ به گونه ای است که بیان می داردکه مساله باید خودش را حل کند.
راه حل استاندارد دیگر TRIZ استفاده از الگوهای تکامل فنی است که در آن وسایل مکانیکی به وسیله فیلدها جایگزین می شوند. این ممکن است به ظاهر خیلی معمولی به نظر برسد اما آن محققان دارو ساز را به تجزیه و تحلیل همه منابع قابل دسترس در مساله هدایت می کند(سلول ها, دیواره های سلول ها, سیالی که سلول ها درآن هستند , حرکت سیال و … )و در نتیجه آنکه سه راه حل ویژه که دارای پتانسیل خیلی بالایی برای این مساله دارند وجود دارد:

1- دیواره های سلول باید توسط امواج صوتی شکسته شوند.(با استفاده از الگوی تکامل جایگزینی وسایل مکانیکی به وسیله فیلدها)
2- دیواره های سلول باید شکسته شوند به وسیله عمل تقسیم سازی همانند آنکه آنها از میان تسهیلات فرآیندی عبور می کنند.
3- یک آنزیم در سیال باید دیواره های سلول را بخورد و محتویات آن را در زمان مطلوب رها کند.

هر سه روش بطور موفقیت آمیزی آزمایش شده اند و با کمترین هزینه و بالاترین هزینه در یک زمان خیلی کوتاهی تولید شد.

TRIZ دودسته از تناقضات را مشخص می کند:

· تناقضات فنی که در حقیقت موازنه کلاسیک مهندسی هستند. حالت مطلوب به دلیل سایر موارد دیگری که سیستم از آن جلوگیری می کند , قابل دسترسی نمی باشد. به عبارت دیگر وقتی بعضی عوامل بهتر می شوند , بعضی عوامل دیگر بدتر می گردند. مثالهای کلاسیک شامل:

o محصول مستحکم تر می شود(خوب) اما وزن آن افزایش می یابد.(بد)
o ضخامت نوار افزایش می یابد (خوب) اما نیروی بیشتری لازم است.(بد)
o کیسه هوای اتومبیل باید خیلی سریع عمل نماید تا از سرنشین محافظت نماید(خوب)اما عمل سریع آن در خیلی موارد مشابه ممکن است افراد کوچک یا شخصی که خارج از موقعیت مناسب است را زخمی کند یا بکشد.(بد)

راه حلهای استاندارد TRIZ، اشاره شده در شکل 1 ، در حدود بیشتر از 50 سال توسط محققانTRIZ توسعه داده شده اند و به روشهای مختلفی سازمان دهی گشته اند.
بعضی از این روشهای تحلیلی عبارتند از:

· نتیجه نهایی ایده آل
· تجزیه و تحلیل وظایف و Trimming
· موقعیت تمرکز ناقص (بیشتر مدیران پروژه در غرب با آن آشنا هستند: تجزیه و تجلیل ریشه ای مشکل )

و مواردی که بیشتر تجویزی هستند عبارتند از:

· 40 اصل حل مساله
· اصول جداسازی
· قانون تکامل فنی و آینده نگری تکنولوژی

در دوره های حل مساله برای هر مساله فنی ، یک یا چند ابزار می تواند برای حل مساله استفاده شود. فلوچارت برای حل مساله در شکل 2 نشان داده شده است.
 

 

شکل 2 : فلوچارت برای استفاده از بعضی ابزارها و تکنیکهای TRIZ

40 اصل حل مساله در دسترس ترین ابزار TRIZ هستند.
این اصول در تمام زمینه ها قابل استفاده هستند. آنها برای حل مجدد تناقض ها بطوریکه آنها پروژه های توسعه محصول جدید را در موقعیت ریسک قرار می دهند استفاده می شوند.

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

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

TRIZ , 40اصل برای حل تناقضات فیزیکی و 4 اصل جداسازی برای حل تناقضات فیزیکی تعریف نموده است.


——————————————————————————–

صادق شهبازی
عضو هیئت علمی گروه خلاقیت و نوآوری مجتمع دانشگاهی ICTدانشگاه صنعتی مالک اشتر
عضو هیئت علمی مرکز پژوهشی خلاقیت شناسی ، نوآوری وTRIZ ایران
Email:sadegh.shahbazi@yahoo.com
 تهران- دانشگاه صنعتی مالک اشتر- مجتمع دانشگاهی ICT- گروه خلاقیت و نوآوری


منبع: مقاله دات نت
جمعه 31 فروردین‌ماه سال 1386

مدیریت پروژه

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

اجزای ‌طرح ‌پروژه ‌عبارتند از:

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

- طرحهای‌ مدیریت‌ خطوط ‌‌راهنما: این ‌طرحها شامل ‌مستندسازی‌ مدیریت ‌واریانسها در پروژه هستند.

- سایر محصولات ‌فرایند برنامه‌ریزی: این ‌محصولات ‌شامل ‌طرحهایی‌ برای مدیریت ‌خطر، کیفیت، تدارکات، استخدام‌ و ارتباطات هستند.

 

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

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

 

مرحله ‌3: توسعه بیانیه‌ حوزه کار

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

- نیاز کسب ‌و کار و مساله ‌کسب ‌و کار است

- اهداف ‌پروژه‌، به منظور حل ‌مشکلات ‌کسب ‌و کار

- مزایای انجام پروژه

- حوزه ‌‌پروژه

 

مرحله ‌4: توسعه‌ خطوط‌ راهنمای ‌‌پروژه

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

- خطوط راهنمای زمان بندی و هزینه

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

- شناسایی منابع هر فعالیت

- تخمین زمان مورد نیاز برای تکمیل هر فعالیت

- تخمین هزینه هر فعالیت ‌با استفاده از میانگین نرخ ساعات هر منبع.

- بررسی محدودیت‌های منبع یا زمان واقعی مورد نیاز هر منبع

- تعیین فعالیت‌های وابسته و توسعه مسیر بحرانی

- تعیین تقویم زمانی همه فعالیت‌ها به صورت (هفتگی، ماهانه، فصلی، سالانه)، به عبارتی هرفعالیت به چه میزان زمان نیاز دارد و زمان شروع و پایان آن چه هنگام است.

این فرایند یکباره شکل نمی‌گیرد، بلکه‌ در خلال پروژه، برخی یا همه این گام‌ها تکرار خواهند شد.

 

مرحله 5: ساخت طرح‌های مدیریت خطوط‌ راهنما

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

 

مرحله 6 : ارتباطات

طرح ارتباطات ‌یکی از جوانب مهم طرح پروژه ‌است. این سند به موارد ذیل اشاره دارد:

- هر فرد در پروژه چه گزارشاتی، در چه فرمتی و با چه رسانه‌ای را درخواست می‌کند.

- اطلاعات پروژه در کجا ذخیره می‌شوند و چه کسی می‌تواند به اطلاعات دسترسی پیدا کند.

- چه پارامترهایی برای حصول اطمینان از کیفیت محصول مورد توجه قرارگرفته‌اند.

- چه تدابیری برای رویارویی با عدم قطعیت‌ها اندیشیده شده است.

به محض اینکه طرح پروژه تکمیل شد،باید محتوای آن به ذینفعان کلیدی ارائه شود.

 

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

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

http://www.industryinfobase.ir/cofarsi/cofarsi/science/Article.asp?Id=ARQ1685#ARQ1685

 نویسنده:شهناز پیروزفر
منبع:mydocument.ir

جمعه 31 فروردین‌ماه سال 1386

مدیریت و کنترل پروژه

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

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

 

3. مقدمه ای بر مفهوم Earned – Value

 

الف – تاریخچه

ارزش به دست آمده چند دهه است که از سوی دولت ایالات متحده به صورت سختگیرانه ای برای بسیاری از سازمانها، اجبار شده است تا برای استفاده فرمالیزه و استاندارد از آن جدیت نمایند. نسخه رسمی و استاندارد آن از سال 1967 توصیه شده و این هنگامی بود که سازمان دفاع(DOD) ، سی و پنج معیار سیستمهای کنترل هزینه/زمانبندی (C/SCSC) را بر روی همه مراکز صنعتی خصوصی که خواستار شرکت در سیستمهای عمده دولتی آتی که از انواع قراردادهای هزینه/قابل پرداخت و یا مورد رقابت اکثر شرکتها بودند، در راهنمایی منتشر نمود. پس از آن هر موقع که سیستم عمده جدیدی توسط دولت ایالات متحده آمریکا تهبه می شد که ریسک رشد هزینه توسط آن ارگان ثابت می ماند، این 35 معیار باید توسط پیمانکار رعایت می شد.

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

مفهوم C/SCSC بطور ناسازگاری برای بیش از 30 سال به کار گرفته شده و به صورت قالب استاندارد مناسبی برای استفاده در سیستمهای عمده دولتی در آمده است. ارگانها و سازمانهای دیگر دولتی در ایالات متحده و کشورهای دیگر همانند استرالیا، کانادا و سوئد، معیار ارزش بدست آمده مشابهی را در مدیریت استفاده از سیستمهای عمده خود اتخاذ کرده اند.

یک ساختار کاربردی مدیریت علمی در استفاده از مفهوم ارزش به دست آمده، توسعه یافته که عمدتاً توسط DOD (سازمان دفاع) و انستیتو صنعتی نیروی هوایی (AFIT) پیشنهادشده است .

در ادامه بحث به تشریح استفاده عملی از مفهوم ارزش به دست آمده خواهیم پرداخت.

 

 

ب – مفاهیم مدیریت ارزش بدست آمده

 

قبل از بحث درباره استفاده از مدیریت ارزش بدست آمده در برنامه ریزی مدیریت ریسک یک پروژه لازم است که بعضی از مفاهیم پایه روش EV تشریح شود. مهمترین نکته کاربردی مدیریت ارزش بدست آمده، درک مفهوم ساختار شکست فعالیت(WBS : Work Breakdown Structure) می باشد.

 

 

ب – 1 ) ساختار شکست فعالیت (WBS)

 

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

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

 

WBS با یک عنصر واحد در رأس ساختار درختی شروع می شود که آن، عنصر نماینده کل فعالیتهای پروژه است. این به سطح یک WBS نسبت داده می شود؛ سطوح پایین تر به تناسب، سطوح 2، 3 و ... نامگذاری می گردند.

 

در ضمیمه 1 نمونه استانداردی از یک مثال WBS برای یک پروژه از دسته بندی توسعه نرم افزار نشان داده شده است.

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

 

 

ادامه بحث ساختار شکست فعالیت (WBS) پروژه نرم افزاری؛

مشخصات بسته کاری(Work Package)

 

هنگامی که این وظایف(وظایف شکسته شده در بخش قبلی) با پایین ترین سطح، زمانبندی شده و به خود هزینه اختصاص می دهند، بهمراه منابع(انسان و مواد) مورد نیاز و مسؤولیت فردی برای تکمیل آن، بسته کاری(Work Package) را تعریف می کنند. تعریف بسته کاری به مدیریت مؤثر ارزش بدست آمده، بستگی حیاتی دارد. یک بسته کاری(Work Package) باید مشخصات زیر را داشته باشد:

 

1- بسته کاری(Work Package) واحدهای کاری را در سطوحی که کار در آنجا ایفا می شود، نشان می دهد.

2- از بسته های کاری دیگر متمایز باشد.

3- به یک عنصر منفرد سازمانی، قابل تخصیص باشد.

4- در هر بسته کاری، شروع و تاریخهای تکمیل، زمانبندی شده باشند و مسافت نماهای(milestones) موقتی، کاربردی بوده و حاکی از روند تکمیل فیزیکی باشند.

5- بودجه یا مبلغ معینی داشته باشد که با تعابیر و اصطلاحاتی همچون دلار، نفر-ساعت یا واحدهای قابل اندازه گیری دیگر بیان شود.

6- مدت آن، به یک دوره زمانی کوتاه و نسبی محدود باشد یا توسط مسافت نماهای گسسته ارزش، به قسمتهای جزء تقسیم بندی شده تا اندازه گیری عینی کار انجام شده، تسهیل گردد.

7- با اجزای تفصیلی مهندسی، ساخت یا زمانبندی های دیگر یکپارچه و هماهنگ باشد.

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

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

 

 

 

ب – 2 ) توضیح عبارات و اصطلاحات مدیریت EV

 

در مدیریت ارزش بدست آمده، 3 کمیت معیارها و قالبهای اساسی برای اندازه گیری بازدهی هزینه می باشند؛ این کمیتها از مجموع هزینه های برنامه ریزی شده و واقعی در فازها(مراحل)ی زمانی محاسبه شده و منطبق با هرکدام از پکیج های کاری هستند(از این پس عبارت پکیج کاری به جای بسته کاری به کار برده خواهدشد) که عبارتند از:

1- هزینه بودجه بندی شده برای کار برنامه ریزی شده(BCWS) یا ارزش طراحی شده(یا برنامه ریزی شده)

2- هزینه بودجه بندی شده کار انجام شده(BCWP) یا ارزش بدست آمده

3- هزینه واقعی کار انجام شده(ACWP) یا هزینه واقعی کار تمام شده

 مقادیر بالا که در شکل 2 نشان داده شده اند، به صورت زیر تعریف می شوند:

 

Budgeted Cost of Work Scheduled )BCWS)

مجموع بودجه های لازم برای کل پکیج های کاری برنامه ریزی شده، جهت اتمام کار در یک دوره زمانی معین.

 

Budgeted Cost of Work Performed )BCWP)

مجموع بودجه های لازم برای پکیج های کاری تکمیل شده و اجزای کامل شده پکیج های کاری ناتمام.

 

Actual Cost of Work Performed )ACWP)

هزینه های واقعی صرف شده جهت تکمیل کارهای اجرایی در یک دوره زمانی معین؛ برای مقایسه متعادل، ACWP فقط برای کار انجام شده ثبت می شود تا در برابر کارهایی که BCWP آنها نیز گزارش شده، موجود باشد.

ب – 3 ) عبارات و اصطلاحات تکمیلی مدیریت EV

 

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

پنج عبارت اضافی نیز، جهت ثبت بازده هزینه و زمانبندی و بودجه برنامه، به صورت زیر تعریف می شوند:

 

Performance Measurement Baseline)PMB)

بیس لاین اندازه گیری کارآیی

مجموع BCWS کل پکیج های کاری برای هر دوره زمانی، که برای کل مدت برنامه محاسبه می شود. PMB طرح بودجه بندی بر مبنای مراحل زمانی(فازهای زمانی) را در برابر بازده محاسبه شده پروژه ارائه می کند.

Budget At Completion )BAC)

بودجه تکمیلی

مجموع کل بودجه های تخصیصی به یک برنامه، علاوه بر PMB؛

معمولاً مبالغی از ذخیره مدیریت کنار گذاشته می شود که جزئی از کل بودجه برنامه بوده و به پکیج های کاری خاصی اختصاص نمی یابد و برای اهداف کنترلی مدیریت ذخیره می شود. BAC، مشتمل بر کل ذخیره های مدیریتی علاوه بر PMB است.

 

Schedule Variance )SV)

انحراف زمانبندی

این کمیت از تفاوت میان کار زمانبندی شده (BCWS) و کار انجام شده حقیقی با بودجه تعیین شده (BCWP) به دست می آید. انحراف زمانبندی، با ارزش دلار بیان شده و از تفاضل "مقدار کاری که باید در دوره زمانی داده شده، تکمیل شود" و " کاری که واقعاً با همان بودجه تعیین شده به انجام رسیده"، حاصل می گردد.

 

Cost Variance )CV)

انحراف هزینه

اختلاف میان هزینه برنامه ریزی شده برای کار انجام شده(BCWP) و هزینه واقعی ناشی از انجام کار(ACWP).

CV هم ارزش حقیقی(به واحد دلار) هزینه های بالاسری(overrunning) و هم غیر بالاسری(under running)(در صورت وجود) را نسبت به هزینه برآورد شده اولیه نشان می دهد.

 

Estimate At Completion)EAC)

برآورد تکمیلی

این کمیت، هزینه های واقعی تحمیلی پروژه تا زمان حال، به اضافه برآوردی از هزینه های کارهای باقیمانده می باشد. در لحظه شروع پروژه BAC و EAC مساوی هستند؛ این تنها ACWP نامساوی با BCWP است که باعث ایجاد عدم تعادل میان EAC و BAC می شود.

 

 

ب- 4) کار با EV

ایجاد برنامه جامع پایین به بالا(Bottom-Up)

باید فرایندهای بحرانی را بگونه ای ترکیب کنیم که هم شامل محدوده کاری مشخص زمانبندی و منابع برآوردشده شوند و همچنین یک برنامه یکپارچه پایین به بالا از اجزاء(سلولها) اندازه گیری شده با تشریح کامل، بوجود آید که برنامه های محاسباتی کنترل(Control Account Plans : CAPs) نامیده می شوند. مدیریت پروژه بر مبنای ارزش بدست آمده مطابق CAPهای تفصیلی، اجرا می گردد به طوریکه در نتیجه، طراحی رسمی(Formal) و پایین به بالای پروژه بدست می آید. CAPهای منفرد، یکپارچگی تمامی فرایندهای بحرانی همچون "محدوده کاری"، "برنامه ریزی"، "زمانبندی"، "برآورد و تخمین" و "اجازه اختیار" را بازنمایی می کنند.

اندازه گیری بازده(Performance) در CAPهای تفصیلی جای می گیرد و بازده کل پروژه از مجموع آنها که در CAPهای تفصیلی انعکاس می یابد، بدست می آید. در اصل، هر CAP پروژه یک زیر پروژه از کل پروژه ای است که توسط یک مدیر CAP، "مدیریت"، "اندازه گیری" و "کنترل" می شود.

 

زمانبندی رسمی CAP ها

هرکدام از CAP های تعریف شده، باید بهمراه یک سیستم زمانبندی رسمی(formal)، برنامه ریزی و زمانبندی شوند.

 

تخصیص هر CAP به یک واحد اجرایی جهت بازده(کارآیی)

بمنظور حصول بازده، هرکدام از CAPهای تعریف شده باید به یک اجرای کاربردی پایدار، تخصیص یابند. این تخصیص بطور مؤثری، متعهد اجرا در جهت نظارت بر بازدهی و اثربخشی هر CAP می شود.

 

فراهم کردن یک baseline که CAP ها را خلاصه می کند

باید یک baseline برای اندازه گیری بازده کل پروژه فراهم گردد، بگونه ای که مجموع CAP های تشریح شده را بازنمایی کند.

 

اندازه گیری بازده در برابر زمانبندی

باید بازده زمانبندی پروژه را در برابر زمانبندی برنامه ریزی شده و اصلی پروژه، بطور متناوب اندازه گیری کنیم.

 

اندازه گیری اثربخشی هزینه در برابر هزینه های تحمیلی

باید بصورت دوره ای، میزان اثربخشی بازده پروژه را طوری اندازه گیری کنیم که رابطه میان EV اجرایی پروژه و هزینه های تحمیلی جهت دستیابی به EV را مشخص کند.

 

پیش بینی هزینه های نهایی بر اساس بازده

باید بصورت متناوب، نیازمندیهای هزینه نهایی پروژه را بر اساس بازده آن در برابر برنامه ریزی، پیش بینی نماییم. 

http://www.industryinfobase.ir/cofarsi/cofarsi/science/Article.asp?Id=ARY5259#ARY5259

نویسنده:سحر میرشاهی

منبع:mydocument.ir

سه‌شنبه 15 اسفند‌ماه سال 1385

ابزارهای مدیریت پروژه

 

مقدمه :
موافق استاندارد PMI، مدیریت پروژه، شامل بکارگیری چهار عامل اساسی ا- دانش (Knowledge) 2- مهارت
ها (Skills) 3- ابزار (‏Tools) و 4- تکنیکهای (Techniques) لازم در اداره جریان اجرای فعالیتها، به منظور رفع نیازهای پروژه است .
نقش ابزار مناسب در پیشبرد اهداف مدیریت پروژه انکارناپذیر است. در واقع پس از طراحی سیستم مدیریت پروژه در سازمان، بکارگیری ابزار مناسب در این سیستم، یکی از مهم
ترین عوامل محقق کننده اهداف مدیریت پروژه در سازمان است.
در این یادداشت
ها تحت عنوان “ابزارهای مدیریت پروژه” بنا داریم به ابزارها و نرمافزارهای مناسب مدیریت پروژه اشاره نماییم.

 

نرمافزارMicrosoft Project)  MSP) :

نرمافزار Microsoft Project یکی از قویترین و قدیمیترین نرمافزارهای موجود کنترل پروژه محسوب میشود. این نرمافزار قریب به 10 سال است که به بازار ایران وارد شده و به شکل گسترده توسط کاربران و برنامهریزان پروژه مورد استفاده واقع میشود. مهندسان کنترل پروژه عموماً از این نرمافزار به عنوان ابزاری جهت مدیریت زمان پروژهها استفاده میکنند. مایکروسافت پروجکت، علیرغم وجود برخی محدودیتها و کمبودها (در مقایسه با نرمافزارهای مشابه) به عنوان یک نرمافزار کاربردی و پرطرفدار در جهان و خصوصاً در ایران روزانه مورد استفاده کاربران بیشماری قرار میگیرد.

   سهولت کار با این نرمافزار ، قابلیت استفاده از امکانات Windows ، سازگاری با سایر نرمافزارهایMS Office و شباهت کامل محیط و جعبه ابزارهای آن با سایر محصولات مایکروسافت، راهنمای Online و کامل داخل برنامه، وجود گزارشها وView های متنوع، امکان تعریف View ها وTableهای جدید و به طورکلی داشتن یک محیطUser Friendly این نرمافزار را به نوعی از سایر نرمافزارهای مشابه متمایز کرده است.

 

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

الف) سازماندهی طرح
ب) زمان بندی کارها
ج) اختصاص منابع و هزینه
کارها

د) تنظیم طرح برای برآورد کردن محدودیتها

ه) آماده کردن گزارشها برای انتقال طرح نهایی به همه کسانی که باید طرح مورد نظر را اجرا کنند.

   پس از آغاز پروژه و اتمام کار برنامهریزی پروژه توسط این نرمافزار، آن را برای کنترل و نظارت بر کارهای در دست اقدام، به شرح زیر میتوان به کار برد:

  • کنترل عملکرد واقعی
  • برنامهریزی روی جدول زمانی پروژه
  • اصلاح طرح برای رویارویی با احتمالات
  • ارائه گزارشهای مطلوب

   شایان ذکر است برای پروژههایی که بیش از 9999 فعالیت دارند، از ابزارهای پیشرفتهتری همچون نرمافزار Primavera (که به آن نیز خواهیم پرداخت) باید استفاده نمود. معمولاً توصیه میشود به دلیل سادگی فوقالعاده این نرمافزار و یادگیری سهلتر آن نسبت به سایر ابزارهای دیگر کنترل پروژه، قبل از یادگیری پریماورا و یا سایر نرمافزارهای مدیریت زمان، به یادگیری MSP بپردازید. در این صورت به دلیل مشابهت مبانی و اصول برنامهربزی و کنترل پروژه در این نرمافزارها، فرایند یادگیری نرمافزارهای پیچیده بسیار سادهتر خواهد شد.

   ویرایش آخر این نرمافزار تحت عنوان Project 2002 Microsoft با قابلیتهای جدید به بازار آمده است.

   در سایتهای اینترنتی زیر اطلاعات جدید و ارزشمندی از این نرمافزار مییابید:

http://www.microsoft.com/office/project/default.asp
http://officesystem.partners.extranet.microsoft.com/msprojectpartner/

 

 

نرم افزار (Primavera Project Planner ( P3

بعد از معرفی نرمافزار Microsoft Project (MSP) اکنون به معرفی P3 که مخفف Primavera Project Planner میپردازیم.

   نرمافزار (Primavera Project Planner ( P3 کاملترین و قدرتمندترین ابزار مدیریت پروژه در مدیریت زمان در جهان شناخته شده است. P3 قادر است پروژههای تا سقف یکصد هزار فعالیت را به همراه منابع با محدودیت سازماندهی کند.

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

   همیشه سوالات متعددی برای مدیران پروژه مطرح میشود که بارزترین آنها: «این کار کی تمام می شود؟»، «چه کسانی کار را انجام میدهند؟»، «چه اتفاقی خواهد افتاد اگر .... (What-if)» و از این قبیل میباشد.
P3 پاسخ این سوالات را به سرعت و به شکل صحیح ارائه خواهد نمود. کاربرP3 به راحتی می
تواند اطلاعات پروژه و فعالیتهای آن را در این بانک اطلاعاتی جمعآوری نموده و به طرق مختلفی آنها را دستهبندی کرده و به نمایش درآورد. همچنین به سادگی میتواند روی جزئیات فعالیتهای پروژه متمرکز شده و نتایج کار خود را در قالب گزارش و نمودار در قالب گرافیکی دلخواه نمایش دهد. به کمک ابزارهای انعطافپذیر P3 از قبیل 24 کد فعالیت، 16 کد بخشهای اطلاعاتی دلخواه، 10 کد پروژه، 19مرحله مرتبسازی دادهها و 28 مرحله فیلتر به همراه 31 تقویم برای برنامهریزی فعالیتها میتوان اطلاعات پروژه را در قالبهای گوناگون دستهبندی و تجزیه وتحلیل کرد. این نرمافزار برای مدیران پروژه توسط طراحانی که خود مدیر پروژه بودهاند، تهیه شده است و دقیقاً به همین دلیل است که غالب نیازمندیهای مدیران پروژه را در برنامهریزی و کنترل طرحها را پاسخگوست.

   به کمک P3 میتوان شبکه فعالیتها را سریعاً در قالب گرافیکی تهیه کرد و همچنین امکان انتخاب نوع فعالیت را به سهولت امکان پذیر مینماید.

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

   امکان لینک؛ بازخوانی اطلاعات و اشتراک دادههای P3 با سایر نرمافزارهای مدیریت پروژه همچون MSP و Expedition (که به آن هم خواهیم پرداخت) وجود دارد.

   برخی دیگر از قابلیتهای این نرمافزار به شکل خلاصه عبارتند از :

  • پیگیری عملکرد منابع و هزینهها به کمک P3 سهل و آسان است.
  • P3 میتواند محدودیتهای مورد نظر کاربر را به فعالیتها اعمال کند.
  • P3 سازماندهی اطلاعات پروژه را آسان نموده است.
  • P3 امکان انتخاب نوع فعالیتها را به کاربر میدهد.
  • امکان بهنگام نمودن پروژه در خارج از محیط کارگاه فراهم است.

  • P3 می تواند محدودیتهای مورد نظر کاربر را به فعالیتها اعمال کند.

   Version جدید P3 تحت عنوان P3e که مخفف Primavera Project Planner Enterprise میباشد به بازار آمده که به شکل ساختاری با ویرایش گذشته آن متفاوت است. با توجه به آنکه کمپانی پریماورا تمامی پشتیبانیهای خود را از ویرایش قبلی این نرمافزار برداشته است، بزودی P3e کاملاً جای P3 را خواهد گرفت. (در آینده پیرامون قابلیتهای جدید P3e نیز با شما سخن خواهیم گفت.)

   سایت اینترنتی این نرمافزار www.primavera.com بوده که در آن میتوانید مطالب متنوع و جدیدی پیرامون این نرمافزار و سایر محصولات شرکت Primavera مرتبط به مقولههای مختلف مدیریت پروژه بیابید .
از شرکت پریماورا و محصولاتش در آینده بسیار خواهیم گفت!

*کارشناس ارشد برنامه‏ریزی و کنترل پروژه‏های پارس ‏جنوبی در پتروپارس