ساير

جستجوی مطالب و خبرنامه

نظر سنجی ها

پیوندها

RSS

وزن دهي در MSP 

دانلود نمونه فرم هايي از طرح تجاري ، بيانيه محدوده ،فرم هايي از مستند آغاز پروژه ، فرم هايي از منشو 

از اینجا دانلود کنید

منشور پروژه چيست؟ 

تهيه منشور پروژه:

منشور پروژه سندي است كه مجوز اجراي پروژه را صادر مي نمايد. كه بايد مشخص ، قابل اندازه گيري ، عملياتي ، واقعي و در چارچوب زماني مشخصي باشد.

 پس از تشخيص امكان پذيري پروژه و ترجيحاً در زماني كه منشور پروژه در حال تدوين است، مدير پروژه به اين مقام منصوب مي شود.

تهيه منشور پروژه اصولاً با مستند سازي نياز هاي تجاري ، توجيه پروژه ، درك فعلي احتياجات مشتري و محصول جديد ، خدمت يا نتيجه اي كه قرار است نيازمندي هاي آنان را تامين نمايد در ارتباط است.

 منشور پروژه بايد دقيقاً موارد شامل و خارج از محدوده كار را مشخص نمايد.

وروديهاي مورد نياز براي تهيه منشور پروژه :

الف- قرارداد (Contract(When applicable: قرارداد به عنوان يك ورودي محسوب مي شود.قرارداد با يك مشتري ورودي محسوب مي شود.

ب- بيانيه كاري پروژه ( Project Statement of work ): توصيف يا شرح دقيق محصولات يا خدماتي است كه توسط پروژه توليد مي شوند كه شامل سه بخش است :

1- نياز تجاري (Business Need): شامل نيازهاي آموزشي، درخواست بازار ، پيشرفتهاي فني و نياز هاي قانوني يا استاندارد دولتي مي باشد.

2- شرح محدوده محصول (Product Scope description ): نيازها و ويژگي هاي محصول يا خدماتي كه قرار است با اجراي پروژه توليد شوند را مستند مي كند.

3- برنامه استراتژيك (strategic plane ): كليه پروژه ها بايستي از اهداف استراتژيك سازمان حمايت كنند. هنگام تصميم گيريهاي انتخاب پروژه ، برنامه استراتژيك سازمان مجري بايد مد نظر قرار گيرد.

ج- عوامل محيطي (Enterprise Environmental Factors ): بايستي تمامي عوامل و سيستم هاي محيطي كار كه پروژه را احاطه كرده و بر موفقيت آن تاثير مي گذارند مد نظر قرار گيرند كه شامل:

1- فرهنگ و ساختار سازماني يا شركت

2- استاندارد هاي دولتي يا صنعتي

3- زير ساختها

4- منابع انساني موجود

5- اداره امور پرسنلي

6- سيستم تفويض اختيار كاري شركت يا شايد سيستم تصويب و مجوز كار در شركت ((Company work authorization

7- شرايط بازار

8- تحمل ريسك ذي نفعان

9- پايگاههاي اطلاعات تجاري

10- سيستمهاي اطلاعات مديريت پروژه

د- سرمايه هاي فرايندي سازمان: تمامي امتيازاتي كه براي موفقيت پروژه مورد استفاده قرار مي گيرند از سرمايه هاي فرايندي سازمان اخذ مي گردند كه در دو گروه طبقه بندي مي شوند:

1- رويه ها و فرايند هاي سازمان براي هدايت كار

2- مبناي دانش مشترك سازماني براي ذخيره و بازيافت اطلاعات

خروجيها:

ü       منشور پروژه ها معمولاً به واسطه يك يا چند مولفه (مشكلات ، فرصتها و نياز هاي تجاري) زير براي سازمان پروژه ايجاد، تصويب و مجاز مي گردند:

·   يك تقاضاي بازار    A Market demand

·  يك نياز تجاري يا كسب و كار  A business need

·  يك در خواست مشتري A customer request

·  يك پيشرفت فني A technical advance

·  يك الزام قانوني A legal requirement

·  يك نياز اجتماعي  A social requirement

ü       منشور پروژه چه به صورت مستقيم و يا در اسناد به ديگر مستندات ، بايد اطلاعات زيرين را مد نظر قرار دهد:

1.       نام حامي پروژه

2.       منافع پروژه برا ي سازمان

3.       الزاماتي كه نياز ها، خواسته ها و انتظارات مشتريان ، حاميان و ساير ذي نفعان را ارضاء مي كنند.

4.       نياز هاي تجاري ، توصيف سطح بالايي از پروژه ، يا نيازمنديهاي مربوط به محصولي كه پروژه متعهد به پاسخگويي آنهاست.

5.       هدف يا توجيه پروژه

6.       انتصاب مدير پروژه و ميزان اختيارات وي

7.       خلاصه اي از زمانبندي مايلستونها (محدوده زماني مورد انتظار كار)

8.       تاثير گذاري ذي نفعان

9.       سازمانهاي عملياتي و مشاركت آنها

10.   فرضيات سازماني، محيطي و بيروني

11.    موضوعات تجاري يا اقتصادي توجيه كننده پروژه : شامل بازگشت سرمايه

12.   خلاصه اي از بودجه

13.   امضاي حامي پروژه

ابزار ها و تكنيك ها:

·             روشهاي انتخاب پروژه

-       روشهاي سنجش سود، شامل رويكرد هاي مقايسه اي ، مدل هاي ثبت امتياز ، توزيع سود يا الگو هاي اقتصادي

-       الگوهاي رياضي كه از الگوريتمهاي برنامه ريزي چند هدفي ، عدد صحيح ، پويا ، خطي و غيرخطي استفاده مي كنند.

·             روش شناسي مديريت پروژه:

اين روش معرف مجموعه اي از گروههاي فرايندي مديريت پروژه همراه با وظايف كنترلي و فرايند هاي مرتبط با آنها است ، كه به صورت يك مجموعه كل عمل كننده واحد ، تركيب و تحكيم شده اند.

·             سيستم اطلاعات مديريت پروژه:

PMIS توسط تيم مديريت پروژه براي ايجاد منشور پروژه ، تسهيل در ارائه بازخوردها جهت پالايش و تغييرات مدارك و مستندات ، كنترل تغييرات در منشور پروژه و صدور اسناد مورد تاييد ، به كار گرفته مي شود.

دانلود نرم افزار ‏Primavera Pertmaster‏  

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

نرم افزار ‏Primavera Pertmaster‏ یکی از قدرتمندترین نرم افزارهای مدیریت ریسک پروژه می باشد که توسط ‏شرکت ‏Primavera‏ توسعه داده شده است. این نرم افزار برای انجام آنالیز ریسک بر روی پروژه ها از شبیه سازی ‏مونت کارلو استفاده می کند. ‏

در این نرم افزار علاوه بر قابلیت بهره گیری از ابزارهای مناسب جهت ورود ریسک و رتبه بندی آن در پروژه، امکان ‏برنامه ریزی پروژه های ‏PERT‏ و ‏GERT‏ در شرایط عدم قطعیت نیز وجود دارد.‏

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

علاوه بر اینکه این نرم افزار قابلیت برنامه ریزی کامل یک پروژه در شرایط قطعی یا غیر قطعی و اجرای آنالیز ریسک ‏را دارد، از آن می توان به عنوان یک نرم افزار کمکی در کنار سایر نرم افزارهای مدیریت پروژه نظیر ‏Primavera‏ یا ‏Microsoft Office Project‏ برای انجام آنالیز ریسک و انتقال اطلاعات بین آنها استفاده کرد

نرم افزار Pert Master در عین سهولت کاربری، سیستم مدیریت پروژه بسیار قدرتمندی است که در کنار ویژگیها و امکانات مدیریت ریسک تمامی خصوصیات یک نرم افزار کامل امروزی را داراست :

امکان نمایش نمودار میله ای و نمودار شبکه با کیفیت بالا

جداول ورود اطلاعات مختلف با کاربری ساده و امکان Undo/redo  نامحدود

امکان تخصیص و تسطیح منابع با قدرت بالا

تقویمهای کاری و قیود (Constraints)

امکان تعریف گزارشات مختلف

مقیاس بندی برای چاپ

اماکن تعریف برنامه مبنا (Baseline) و پیگیری (Tracking)

محاسبات ارزش حاصله (Earned Value)

امکان ایجاد فیلدهای دلخواه

قدرت بالا در شبیه سازی ریسک

نرم افزار Pert master Project Risk , ابزار پیشرفته پیچیده ترین ریسکهای پروژه را در اختیار دارد که انجام شبیه سازی های زیر را برای کاربران میسر میسازد :

مصرف منابع احتمالی

Cash Flow احتمالی

پنجره ریسک

فعالیتهای احتمالی

ساختار شکست احتمالی

ارتباط زمان و هزینه

انجام محاسبات و اتخاذ تصمیمات

نمودار شبکه پروژه و ارتباطات تک تک فعالیتها

نمایش مدت، شروع، پایان و مصرف منابع

کپی مستقیم نمودارها به برنامه Word و PowerPoint و غیره

نمایش برنامه جاری و برنامه مبنا (Baseline)

ایجاد و نمایش نمودار ریسک

محاسبات بحرانیت، حساسیت و قطعیت

مرتب سازی و فیلتر فعالیتها بر اساس بحرانیت حساسیت و قطعیت

نمایش اطلاعات فعالیت در جدول و نمودار میله ای فعالیت

محاسبه خودکار کمترین ، بیشترین ، نما ، میانه ، انحراف معیار برای زمان، هزینه و منابع

امکان انتقال (Export) اطلاعات تحلیل ریسک به برنامه های صفحه گسترده برای محاسبه یا رسم نمودار های دلخواه.

تحلیل ریسک Montecarlo

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

ارتباط با سایر سیستمها

پرتمستر می تواند در ارتباط با سیستمهای مدیریت پروژه زیر مورد استفاده قرار گیرد:

Microsoft Project

Microsoft Project server 2000

Primavera Planner

Primavera Enterprise

 دانلود آخرین نسخه Primavera Risk Analyser از اینجا (79 مگابایت)

دانلود نرم افزار Primavera Pertmaster 8.1 از اینجا (80.6 مگابایت)

دانلود فایل کرک (1) نرم افزار Primavera Pertmaster 8.1 از اینجا (167 کیلوبایت)

دانلود فایل کرک (2) نرم افزار Primavera Pertmaster  از اینجا (3.15 مگابایت)

 1- نسخه 7.8 به همراه کرک  دانلود 1      دانلود 2   (حجم فایل 38.7 مگابایت)

2- دانلود کرک نسخه 7.8 (به تنهایی) (حجم فایل 3.1 مگابایت)

3- دانلود نسخه 8.2 بدون کرک (حجم فایل 95 مگابایت)

منبع : وبلاگ دروس آموخته

دانلود کتاب PMBOK  

کتاب PMBOK2004

دانلود کتاب PMBOK  از سرور شماره یک اینجا

مطالب مرتبط :

PMBOK2000

EPM چیست ؟ 

EPM مجموعه اي از محصولات هم‌خانواده شركت ميكروسافت را براي ارائه يك راه‌حل جامع مديريت پروژه  گسترش داده است. اين راه حل محصولات زير را شامل مي‌گردد:
- Microsoft Project Professional
نرم‌افزار كاملي كه مديران پروژه توسط آن پروژه‌ها و منابع سازماني را ايجاد و تغيير مي‌دهند. اين پروژه‌ها و منابع در بانك اطلاعاتي Microsoft Project Server ذخيره مي‌شوند. 

- Microsoft Project Server
يك بانك اطلاعاتي Microsoft Project Server كه كاربرگ‌ها، گزارشات وضعيت، گزارشات و مدل‌هاي portfolio، منابع سازماني، يك قالب جامع سازماني (enterprise global template)، و الگو‌هايي (template) را براي تعريف سريعتر پروژه‌هاي جديد فراهم مي‌كند.

- Microsoft Project Web Access
يك نرم‌افزار مبتني بر وب كه به اعضاء تيم (team member)، مديران پروژه‌ها و منابع، و مديران سازمان اجازه مي‌دهد كه به اطلاعات Microsoft Project Server مانند كاربرگ‌ها و گزارشات دسترسي يابند

براي همه سازمان هايي که MS Project را به دليل کاربر پسند بودن، سهولت استفاده و قابليت هاي يکپارچگي با مجموعه Office براي پاسخگويي به نياز برنامه ريزي و کنترل پروژه انتخاب کرده اند و به دنبال توسعه همکاري اطلاعاتي تيم پروژه، کنترل مدارک پروژه و مديريت قوي تر منابع و گزارش گيري ساده تر و سريع تر از وضعيت پروژه هايشان هستند  راه حل جامع مديريت پروژه EPM راه حل ايده آل و قابل اعتماديست که کاهش ريسک پروژه و افزايش بازگشت سرمايه (ROI) را به همراه خواهد داشتاه حل میکروسافت برای مدیریت اطلاعات پروژه های بزرگ استفاده از EPM است . این راه حل در حقیقت یک ارتباط منطقی بین سه محصول اصلی ميكروسافت در مديريت پروژه به نام های :
1- Microsoft Office Project Professional 2003
2- Microsoft Office Project Server 2003
3- Microsoft Office Project Web Access
مي باشد ولي معماري این راه حل فراتر از این سه محصول است

شكل زير بيانگر معماري كلي EPM می باشد که به صورت خلاصه شرح داده خواهد شد.



- کلیه اطلاعات Project Server در MS SQL Server 2000 نگهداری می گردد .
- از طریق ارتباط با SharePoint Services(WSS) نیازمندیهای اشتراکی کاربران از جمله مدیریت مدارک اشتراکی و پیگیری Issue های پروژه را انجام می دهد .
- مدیران پروژه ها از  Msp pro 2003 Desktop برای مدیریت اطلاعات پروژه ها استفاده خواهند نمود.
- Project Web Access به عنوان ابزار ارتباطی بین اعضای تیم جهت انتشار اطلاعات پروژه ها استفاده می گردد. کلیه افراد مرتبط با پروژه قادر خواهند بود بدون نیاز به MSP و فقط از طریق WEB به اطلاعات دسترسی داشته و سطح دسترسی خود آنها را بروز نمایند.
- EPM از طریق ارتباط با اکثر نرم افزارهای حوزه MS Office کاربر را قادر نموده است تا حداکثر امور مورد نیاز پروژه را از طریق بر طرف نماید . از جمله MS Outlook جهت تبادل داده به صورت Offline ، ذخیره اطلاعات متنی در MS Word و ....
- همچنین EPM ارتباط با خارج از محصولات میکروسافت را از طریق معماری Open Server فراهم نموده است .

یک فایل هم هست که م یتونید از اینجا دانلود کنید(منبع سایت : inden.ir)

دانلود از سرور شماره دو : اینجا

دانلود از سرور شماره یک : اینجا

دانلود جزوات مهندسی صنایع 

منبع  http://www.shirouyehzad.com

دانلود جزوات برنامه ریزی تولید ،نت(نگهداری و تعمیرات)،مدیریت پروژه

http://www.shirouyehzad.com

ISO10006  

ISO 10006

مقالات مدیریت پروژه و اموزش نرم افزار سيستم كنترل پروژه Primavera P3.3 

• چگونه مديران از سيستم كنترل پروژه دركنترل و اجراى طرحها و پروژه هايشان استفاده بهينه نمايند

• كاربرد كامپيوتر در سيستمهاي علمي برنامه ريزي

• سابقه برنامه ريزي در مديريت اجرائي پروژه هاي عمراني در ايران و كشورهاي توسعه يافته غرب با استفاده از نرم افزارهاي كامپيوتري برنامه ريزي و كنترل پروژه تحت روشهاي علمي CPM و PDM

• چگونه شبكه CPM / PDM يك طرح يا پروژه را طراحي كنيم

• عناوين و سر فصل هاي مهم براي يك كارشناس كنترل پروزه در استفاده از سيستم Primavera 3

• مراحل اساسي طراحي شبكه و استفاده از سيستم كامپيوتري كنترل پروژه در برنامه ريزي و كنترل يك طرح به روش PDM

• روش استفاده از سيستم كنترل پروژه Primavera P3.3 در برنامه ريزي، كنترل و اجراي شبكه PDM يك پروژه

• ليست كتابهاي مهم در رابطه با مديريت پروژه و سيستم برنامه ريزي و كنترل پروژه و نيز نرم افزارهاي كنترل پروژه

• خلاصه مفاهيم اساسي سيستم برنامه ريزي و كنترل پروژه به روش CPM-PRECEDENCE

• معرفي شبكه PDM و امكانات آن در مقايسه با روش CPM در طراحي شبكه فعاليت هاي يك پروژه

• خلاصه اي از قوانين انجام محاسبات Forward و backward روي شبكه هاي CPM

PMBOK  

يک صد قاعده و قانون برای مديريت پروژه ناسا(قسمت دوم) 

Contractors and Contracting 

Rule #47: A project manager is not the monitor of the contractor's work but is to be the driver. In award fee situations, the government personnel should be making every effort possible to make sure the contractor gets a high score (i.e., be on schedule and produce good work). Contractors don't fail, NASA does and that is why one must be proactive in support. This is also why a low score damages the government project manager as much as the contractor's manager because it means that he is not getting the job done.

Rule #48: Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. The project management measurement system (pms) should be used to verify the scores. Consistent poor scores require senior management intervention to determine the reason. Consistent good scores which are consistent with pms reflect a well-run project, but if these scores are not consistent with the pms, senior management must take action to find out why.

Rule #49: Morale of the contractor's personnel is important to a government manager. Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware developed by under- motivated people. You should take an active role in motivating all personnel on the project.

Rule #50: Being friendly with a contractor is fine—being a friend of a contractor is dangerous to your objectivity.

Rule #51: Remember, your contractor has a tendency to have a one-on-one interface with your staff. Every member of your staff costs you at least one person on the contract per year.

Rule #52: Contractors tend to size up the government counterparts and staff their part of the project accordingly. If they think yours are clunkers, they will take their poorer people to put on your project.

Rule #53: Contractors respond well to the customer that pays attention to what they are doing but not too well to the customer that continually second-guesses their activity. The basic rule is a customer is always right but the cost will escalate if a customer always has things done his way instead of how the contractor planned on doing it. The ground rule is: never change a contractor's plans unless they are flawed or too costly (i.e., the old saying that better is the enemy of good).

Rule #54: There'is only one solution to a weak project manager in industry—get rid of him fast. The main job of a project manager in industry is to keep the customer happy. Make sure the one working with you knows that it is not flattery but on-schedule, on-cost, and a good product that makes you happy.

Engineers and Scientists 

Rule #55: Over-engineering is common. Engineers like puzzles and mazes. Try to make them keep their designs simple.

Rule #56: The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.

Rule #57: The project has many resources within itself. There probably are five or ten system engineers considering all the contractors and instrument developers. This is a powerful resource that can be used to attack problems.

Rule #58: Many managers, just because they have the scientists under contract on their project, forget that the scientists are their customers and many times have easier access to top management than the managers do.

Rule #59: Most scientists are rational unless you endanger their chance to do their experiment. They will work with you if they believe you are telling them the truth. This includes reducing their own plans.

Hardware 

Rule #60: In the space business, there is no such thing as previously flown hardware. The people who build the next unit probably never saw the previous unit. There are probably minor changes (perhaps even major changes); the operational environment has probably changed; the people who check the unit out in most cases will not understand the unit or the test equipment.

Rule #61: Most equipment works as built, not as the designer planned. This is due to layout of the design, poor understanding on the designer's part, or poor understanding of component specifications.

Computers and Software 

Rule #62: Not using modern techniques, like computer systems, is a great mistake, but forgetting that the computer simulates thinking is a still greater mistake.

Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software.

Rule #64: Knowledge is often revised by simulations or testing, but computer models have hidden flaws not the least of which is poor input data.

Rule #65: In olden times, engineers had hands-on experience, technicians understood how the electronics worked and what it was supposed to do, and layout technicians knew too—but today only the computer knows for sure and it's not talking.

Senior Management, Program Offices, and Above 

Rule #66: Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will astonish you.

Rule #67: Know your management—some like a good joke, others only like a joke if they tell it.

Rule #68: Remember the boss has the right to make decisions. Even if you think they are wrong, tell the boss what you think but if he still wants it done his way; do it his way and do your best to make sure the outcome is successful.

Rule #69: Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you can't.

Rule #70: You and the Program Manager should work as a team. The Program Manager is your advocate at NASA HQ and must be tied into the decision makers and should aid your efforts to be tied in also.

Rule #71: Know who the decision makers on the program are. It may be someone outside who has the ear of Congress or the Administrator, or the Associate Administrator, or one of the scientists—someone in the chain of command—whoever they are. Try to get a line of communication to them on a formal or informal basis.

Program Planning, Budgeting, and Estimating 

Rule #72: Today one must push the state of the art, be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long as the ground rules such as funding profile and schedule are established up front and maintained.

Rule #73: Most of yesteryear's projects overran because of poor estimates and not because of mistakes. Getting better estimates will not lower costs but will improve NASA's business reputation. Actually, there is a high probability that getting better estimates will increase costs and assure a higher profit to industry unless the fee is reduced to reflect lower risk on the part of industry. A better reputation is necessary in the present environment.

Rule #74: All problems are solvable in time, so make sure you have enough schedule contingency—if you don't, the next project manager that takes your place will.

Rule #75: The old NASA pushed the limits of technology and science; therefore, it did not worry about requirements creep or overruns. The new NASA has to work as if all projects are fixed price; therefore, requirement creep has become a deadly sin.

Rule #76: Know the resources of your center and, if possible, other centers. Other centers, if they have the resources , are normally happy to help. It is always surprising how much good help one can get by just asking.

Rule #77: Other than budget information prior to the President's submittal to Congress, there is probably no secret information on a project—so don't treat anything like it is secret. Everyone does better if they can see the whole picture so don't hide any of it from anyone.

Rule #78: NASA programs compete for budget funds—they do not compete with each other (i.e., you never attack any other program or NASA work with the idea that you should get their funding). Sell what you have on its own merit.

Rule #79: Next year is always the year with adequate funding and schedule. Next year arrives on the 50th year of your career.

The Customer 

Rule #80: Remember who the customer is and what his objectives are (i.e., check with him when you go to change anything of significance).

NASA Management Instructions 

Rule #81: NASA Management Instructions were written by another NASA employee like you; therefore, challenge them if they don't make sense. It is possible another NASA employee will rewrite them or waive them for you.

Decisionmaking 

Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them.

Rule #83: Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss, but if you constantly have to solve someone's problems, you are working for him.

Rule #84: Never make a decision from a cartoon. Look at the actual hardware or what real information is available such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.

Professional Ethics and Integrity 

Rule #85: Integrity means your subordinates trust you.

Rule #86: In the rush to get things done, it's always important to remember who you work for. Blindsiding the boss will not be to your benefit in the long run.

Project Management and Teamwork 

Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays.

Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity.

Rule #89: Whoever said beggars can't be choosers doesn't understand project management, although many times it is better to trust to luck than to get poor support.

Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion.

Rule #91: Remember, the President, Congress, OMB, NASA HQ, senior center management, and your customers all have jobs to do. All you have to do is keep them all happy.

Treating and Avoiding Failures 

Rule #92: In case of a failure:

• a) Make a timeline of events and include everything that is known.
• b) Put down known facts. Check every theory against them.
• c) Don't beat the data until it confesses (i.e., know when to stop trying to force-fit a scenario).
• d) Do not arrive at a conclusion too fast. Make sure any deviation from normal is explained. Remember the wrong conclusion is prologue to the next failure.
• e) Know when to stop.

Rule #93: Things that fail are lessons learned for the future. Occasionally things go right: these are also lessons learned. Try to duplicate that which works.

Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.

Rule #95: History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards.

Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.

Rule #97: Don't be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.

Rule #98: One of the advantages of NASA in the early days was the fact that everyone knew that the facts we were absolutely sure of could be wrong.

Rule #99: Redundancy in hardware can be a fiction. We are adept at building things to be identical so that if one fails, the other will also fail. Make sure all hardware is treated in a build as if it were one of a kind and needed for mission success.

Rule #100: Never make excuses; instead, present plans of actions to be taken.

فرايندهاي پروژه 

فرايندهاي پروژه

فرايند: مجموعه فعاليت هاي لازم براي رسيدن به يک نتيجه را گويند.

مديريت پروژه فرايند مجموعه فعاليتهاي يکپارچه و بهم مرتبط ميباشد و لذا کسب نتيجه هر يک از محدودهاي مديريت پروژه معمولا در سايرين نيز موثر است و تعامل بين محدودها داراي نتايج مثبت و منفي براي هر يک از آنها است .

به عنوان مثال تغيير در محدوده کار غالبا در افزايش هزينه هاي پروژه موثر است اما ايت تا ثير مي تواند در رويه جريان و يا حتي کيفيت محصول يا خدمات مورد نظر اثر منفي داشته باشد و لذا در اين تعاملات مي بايستي هميشه به اهداف پروژه توجه نمود.

“موفقيت در مديريت پروژه ،مستلزم مديريت بر تعامل بين محدوده ها براي نيل به اهداف پروژه به بهترين روش ممکن است”.

فرايندهاي پروژه به دو دسته تقسيم مي شوند:

1- فرايندهاي مديريت پروژه:

شامل تشريح و سازماندهي فعاليتهاي پروژه مي باشد و اين فرايندها  دراغلب پروژه ها و در زمان هاي مختلف قابل اجرا است.اين فرايندها مي خواهند  روخ حاکم محصول پروژه شده و در جهت رسيدن بهينه به محصول پروژه کمک نمايند.

2- فرايندهاي محصول پروژه:

شامل تهيه،نوليد و ارائه محصول پروژه بوده و اين فرايندها عمدتا در غالب تعيين چرخه حيات پروژه بيان مي گردند.

از ابتدا تا انتهاي پروژه تعامل بين دو دسته فرايند فوق برقرار است به نمونه تعيين محدوده کار پروژه بدون درک کافي از چگونگي تهيه،توليد و ارائه محصول آن امکان پذير نمي باشد.

فرايندهاي مديريت پروژه در قالب يکي از پنج گروه زير انجام مي شود :

1-فرايندهاي آغازين

2-فرايندهاي برنامه ريزي

3-فرايندهاي اجرايي

4-فرايندهاي کنترلي

5-فرايندهاي پاياني

1.                  فرايندهاي آغازين :

فرايندهاي آغازين شامل تشخيص ،تدوين و ارائه مراحل و فعاليتها لازم براي شروع پروژه مي باشد.

مجموعه اقدامات لازم در اخذ مجوزها و اختيارات لازم براي سازمان دهي کار و منابع کاري براي شروع پروژه با يک مرحله از آن و به عنوان بخشي از مديريت محدوده پروژه مي باشد.

نکته: فرايندهاي آغازين تنها يک بار بايستي انجام شود.

2.                  فرايندهاي برنامه ريزي:

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

پروژه ها ، اجراي فعاليت هاي منحصر به فردي هستند که قبل از اين اجرا نشده اند لذا برنامه ريزي پروژه ها از اهميت ويژه اي برخوردارند . به همين علت تعامل قابل ملاحظه اي بين فرايندهاي اين بخش وجود دارد .

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

فرايندهاي برنامه ريزي به دو دسته زير تقسيم مي شوند:

1-فرايندهاي اصلي و عمده

2-فرايندهاي فرعي و کمکي

فرايندهاي اصلي و عمده:

اجراي برخي از فرايندهاي برنامه ريزي در کليه پروژه ها ضروري است .و لزوم اجراي آنها و رعايت حق تقدم و تاخر بين آنها بديهي و اجتناب ناپذيز است. به عنوان مثال قبل از تعريف ها فعاليت هاي يک پروژه ، زمان بندي و بودجه بندي آنها عملا ميسر نيست.

فرايندهاي اصلي و عمده که مي توانند به طور مذکور در 

طول اجراي پروژه در سازمانهاي متعدد و همچنين به موازات شروع وادامه يک يا چند مرحله از پروژه تحقق يابد به شرح ذيل است :

برنامه ريزي محدود :

تدوين محدوده کار که به عنوان يا با اتخاذ کليه تصميمات پروژه است.

تعريف محدوده :

تشريح و تفکيک اهداف بلند مدت و کلان به اهداف کوتاه مدت و کاملا مشخص به منظور مديريت دقيق بر آنها ست.

تعريف فعاليتها :

تعيين دقيق فعاليتها ي قابل انجام براي حصول به نتايج واهداف کوتاه مدت مي باشد.

توالي فعاليت ها :

بررسي و تدوين ارتباطات بين هر يک از فعاليت ها با ساير فعاليتها

برآورد مدت زمان فعاليتها : 

برآورد مدت زمان براي اجراي هر يک از فعاليتها به طور مستقل

تهيه زمان بندي :

 تجزيه و تحليل ارتباط بين فعاليت ها ، مدت زمان اجرا و منابع مورد نياز هر يک از آنها براي تهيه برنامه زمان بندي پروژه مي باشد .

برنامه ريزي مديريت ريسک:

با اتخاذ تصميم در نحوه مراجعه با رويه هاي بالقوه مخاطره آميز و برنامه هاي مورد نياز در مديريت رريسک پروژه مي باشد.

 برنامه ريزي منابع کاري:

بررسي و تعيين نوع و ميزان منابع کاري شامل (نيرويانساني ، ماشين آلات و..) براي تحقق هر يک از فعاليتهاي پروژه است

براورد هزينه:

محاسبه و براورد کل بودجه مورد نياز براي اجراي پروژه مي باشد

برنامه ريزي بودجه :

تسهيم و تخصيص بودجه به هر مجموعه از فعاليتها در محدوده  بودجه کلي پروژه است .

تهيه برنامه بودجه :

جمع بندي ، يکپارچه سازي و مستند سازي فرايندها يبر شمرده شده فوق در يک مجموعه مدون و قابل ارائه مي باشد.

فرايندهاي فرعي و کمکي :

استفاده از مجموعه فرايندهاي فرعي و کمکي بستگي زيادي به ماهيت پروژه دارد . بعنوان مثال شرايط اجراي بسياري از پروژه ها بنحوي است که نيازمند توجه ويژه به فاکتورهاي ريسگ پذير نيست . ولي در برخي از پروژه ها اين بالعکس مي باشد مجموعه فرايندهاي فرعي و کمکي همواره در اجراي فرايندهاي برنامه ريزي مورد توجه است به شرح زير مي باشد:

 برنامه ريزي کيفيت

برنامه ريزي سازماني

جذب نيرو

برنامه ريزي ارتباطات

برنامه ريزي تدارکات

برنامه ريزي درخواست ها

تبيين ريسک:

احتمالي موثر در اجراي پروژه و تدوين مشخصه هاي آن است

تجزيه و تحليل کيفي ريسک:

تجزيه وتحليل مشخصات ريسک و تعيين اولويت هر يک از آنها در تحقق اهداف پروژه ميباشد.

تجزيه و تحليل کمي ريسک:

ارزيابي مقداري احتمال و اثر ريسک و تعيين سطح معني دار بودن آنها در تحقق اهداف پروژه مي باشد.

برنامه ريزي واکنش به ريسک:

تدوين رويه و اجراي تکنيکهايي است که با توجه به ريسک موجود ، موجب افزايش فرصت ها و کاهش تهديدها در پروژه مي گردد .

3.                  فرايندهاي اجرايي :

مجموعه عمليات هماهنگي بين کليه ارکان اجرايي پروژه مطابق برنامه مي باشد.

4.                  فرايندهاي کنترلي:

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

5.                  فرايند اختتامي

مجموعه فعاليت ها مطابق مراحل اجرا شده و اهداف از پيش تعيين شده پروژه مي باشد.

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

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

تعامل بين فرايندها:

 هر يک از گرههاي فرايندي نيز از مجموعه کاملا مشخص تشکيل شده اند که با يکديگر مرتبط هستند اين ارتباطات 

 به صورت خروجي هر يک و ورودي ديگر مي باشد.

هر يک از فرايندها از سه بخش مجزاي زير تشکيل شده است:

ورودي ها :

شامل مدارک و مستندات و نتايج از فرايندها اجرايي ما قبل است

ابزار و تکنيک ها:

شامل رويه ها ، تکنيک ها و ابزارهاي لازم براي استفاده و وروديها اجراي فرايند و کسب خروجي ها است.

خروجي ها :شامل مدارک و مستندات و نتيج حاصله از اجراي فرايند مي باشد.

يک صد قاعده و قانون برای مديريت پروژه ناسا(قسمت اول) 

One Hundred Rules for NASA Project Managers 

Lessons Learned as Compiled by Jerry Madden , Associate Director of the Flight Projects Directorate at NASA's Goddard Space Flight Center: (Jerry collected these gems of wisdom over a number of years from various unidentifiable sources. They have been edited by Rod Stewart of Mobile Data Services in Huntsville, Alabama.). January 1, 1995. Updated July 9, 1996.

• The Project Manager
• Initial Work
• Communications
• People
• Reviews and Reports
• Contractors and Contracting
• Engineers and Scientists
• Hardware
• Computers and Software
• Senior Management, Program Offices, and Above
• Program Planning, Budgeting, and Estimating
• The Customer
• NASA Management Instructions
• Decisionmaking
• Professional Ethics and Integrity
• Project Management and Teamwork
• Treating and Avoiding Failures

 

The Project Manager 

Rule #1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing.

Rule #2: A project manager must know what motivates the project contractors (i.e., their award system, their fiscal system, their policies, and their company culture).

Rule #3: Management principles still are the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it.

Rule #4: Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge.

Rule #5: Vicious, dispicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishywashies can not.

Rule #6: A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.

Rule #7: One problem new managers face is that everyone wants to solve their problems. Old managers were told by senior management—"solve your own darn problems, that is what we hired you to do."

Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.

Rule #9: The boss may not know how to do the work but he has to know what he wants. The boss had better find out what he expects and wants if he doesn't know. A blind leader tends to go in circles.

Rule #10: Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure but luck favors the competent hard working manager.

Rule #11: Never try to get even for some slight by anyone on the project. It is not good form and it puts you on the same level as the other person and, besides, probably ends up hurting the project getting done.

Rule #12: Don't get too egotistical so that you can't change your position, especially if your personnel tell you that you are wrong. You should cultivate an attitude on the project where your personnel know they can tell you of wrong decisions.

Rule #13: A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.

Rule #14: Most managers succeed on the strength and skill of their staff.

Initial Work 

Rule #15: The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.

Communications 

Rule #16: Cooperative efforts require good communications and early warning systems. A project manager should try to keep his partners aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The partners should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides his partners will be treated in kind and will be considered a person of no integrity.

Rule #17: Talk is not cheap; but the best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.

Rule #18: Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said.

Rule #19: You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn computerese, communicationese and all the rest of the modern "ese's" of the world. You can't manage if you don't understand what is being said or written.

People 

Rule #20: You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job.

Rule #21: We have developed a set of people whose self interest is more paramount than the work or at least it appears so to older managers. It appears to the older managers that the newer ones are more interested in form than in substance. The question is are old managers right or just old? Consider both viewpoints.

Rule #22: A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews.

Rule #23: The source of most problems is people, but darned if they will admit it. Know the people working on your project to know what the real weak spots are.

Rule #24: One must pay close attention to workaholics—if they get going in the wrong direction, they can do a lot of damage in a short time. It is possible to overload them and cause premature burnout but hard to determine if the load is too much, since much of it is self generated. It is important to make sure such people take enough time off and that the workload does not exceed 1 1/4 to 1 1/2 times what is normal.

Rule #25: Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better.

Rule #26: If you have someone who doesn't look, ask, and analyze; ask them to transfer.

Rule #27: Personal time is very important. You must be careful as a manager that you realize the value of other people's time (i.e., the work you hand out and meetings should be necessary). You must, where possible, shield your staff from unnecessary work (i.e., some requests should be ignored or a refusal sent to the requestor).

Rule #28: People who monitor work and don't help get it done never seem to know exactly what is going on (being involved is the key to excellence).

Rule #29: There is no greater motivation than giving a good person his piece of the puzzle to control, but a pat on the back or an award helps.

Rule #30: It is mainly the incompetent that don't like to show off their work.

Rule #31: There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people, but get their work done as soon as possible. Getting the work done by someone else takes two or three times longer and the product is normally below standard.

Rule #32: People have reasons for doing things the way they do them. Most people want to do a good job and, if they don't, the problem is they probably don't know how or exactly what is expected.

Rule #33: If you have a problem that requires additional people to solve, you should approach putting people on like a cook who has under-salted the food.

Reviews and Reports 

Rule #34: NASA has established a set of reviewers and a set of reviews. Once firmly established, the system will fight to stay alive, so make the most of it. Try to find a way for the reviews to work for you.

Rule #35: The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation.

Rule #36: Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses—just state facts.

Rule #37: External reviews are scheduled at the worst possible time, therefore, keep an up-to-date set of business and technical data so that you can rapidly respond. Not having up-to-date data should be cause for dismissal.

Rule #38: Never undercut your staff in public (i.e., In public meetings, don't reverse decisions on work that you have given them to do). Even if you direct a change, never take the responsibility for implementing away from your staff.

Rule #39: Reviews are for the reviewed an not the reviewer. The review is a failure if the reviewed learn nothing from it.

Rule #40: A working meeting has about six people attending. Meetings larger than this are for information transfer (management science has shown that, in a group greater than twelve, some are wasting their time).

Rule #41: The amount of reviews and reports are proportional to management's understanding (i.e., the less management knows or understands the activities, the more they require reviews and reports). It is necessary in this type of environment to make sure that data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence.

Rule #42: Managers who rely only on the paperwork to do the reporting of activities are known failures.

Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly.

Rule #44: Just because you give monthly reports, don't think that you can abbreviate anything in a yearly report. If management understood the monthlies, they wouldn't need a yearly.

Rule #45: Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know hundreds. Use them sparingly in presentations unless your objective is to confuse.

Rule #46: Remember, it is often easier to do foolish paperwork that to fight the need for it. Fight only if it is a global issue which will save much future work.

گزارشات عملکرد 

گزارشات عملکرد کارامد نياز مديريت اثربخش پروژه :

 بررسي ضرورت بکارگيري دوره هاي زماني کوتاه مدت

گزارشات عملکرد يکي از کاراترين و ضروري ترين ابزارهاي مديريت پروژه مي باشد. اين گزارشات به عنوان بخش اساسي از سيستم کنترل پروژه، فرايندي است که علي رغم اهميت آن کمتر به آن پرداخته شده است. ويژگيهاي يک گزارش عملکرد کارا و همچنين

نحوه تعيين دوره زماني گزارشگيري و سطح گزارشگيري ساختارشکست کار، محل تمرکز اين نوشتار مي باشد. در اين مقاله با تمرکزبر پروژه هاي پتروشيميايي، تلاش مي شود که الزامات يک گزارش عملکرد کارا به طور جامع بررسي گردد.

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

آقاي کوکي ديويس مي گويد

اصولا به منظور پياده سازي يک سيستم کنترل اثربخش، حصول موارد زير ضروري مي باشد:

-1 تدوين برنامه پروژه( استانداردهاي کاري)

-2 دسترسي به اطلاعات صحيح، دقيق و به موقع از ميزان واقعي کار انجام شده

-3 مقايسه برنامه با عملکرد واقعي و تعيين ميزان مغايرت و همچنين علل تخطي از برنامه

-4 تمهيد و اجراي اقدامات اصلاحي مناسب به منظور جبران مغايرتهاي احتمالي از برنامه

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

فرآيند گزارش عملکرد :

جمع آوري و توزيع اطلاعات عملکرد پروژه به منظور ارائه اطلاعات به ذي نفعان پروژه در مورد چگونگي استفاده از منابعبراي دستيابي به اهداف را گزارش عملکرد گويند. فرآيند گزارش عمکرد داراي اجزاي زير ميباشد:

1-گزارش وضعيت – کار انجام گرفته توسط تيم پروژه را تشريح ميکند . اين امر به کمک شاخصهاي عملکرد زمانبندي و هزينه

نشان داده ميشود.

2-گزارش پيشرفت - کار انجام گرفته توسط تيم پروژه را تشريح ميکند. درصد پيشرفت زمانبندي، درصد پيشرفت هزينه اي يا

کار انجام گرفته به کل کار، از جمله مواردي است که در اين بخش ارائه ميگردد.

3- پيش بيني - وضعيت و پيشرفت آتي پروژه را تشريح ميکند.

به طور معمول گزارشات عملکرد اطلاعاتي در مورد محدوده، زمانبندي، ،هزينه و کيفيت پروژه ارائه مي نمايند. در بسيار از پروژه هااطلاعاتي در مورد ريسک و تداکرات نيز ارائه ميگردد.

وروديها، تکنيکها و ابزارهاي لازم جهت تحقق اين فرايند و همچنين خروجي حاصل از آن به شرح زير ميباشد :

گزارشات عملکرد :

گزارشات عملکرد، اطلاعات جمع آوري شده را سازماندهي و خلاصه کرده و نتايج تحليل هاي صورت گرفته بر آنها را نيز ارائه

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

ارائه درخواست تغييرات ميباشد. معمولا پس از تحليل وضعيت پروژه نياز به پاره اي تغييرات در برنامه پروژه ميباشد که لازم است ازطريق گزارش عملکرد به اطلاع ذي نفعان مقتضي رسانده شوند در يک گزارش عملکرد معمولا اطلاعات زير ارائه مي گردد :

1-ساختار شکست کار(تا سطح مورد نياز)، 2- ارزش وزني،

 3-ميزان کل کار برنامه ريزي شده ، 4- ميزان کار برنامه

ريزي شده در آن دوره زماني ، 5- ميزان کار انجام گرفته تا کنون، 6- ميزان کار انجام گرفته در اين دوره زماني،

8- متوسط کار برنامه ريزي شده در دوره هاي گذشته،

9- متوسط ، (SPI1,CPI2,SSI3,DCI )شاخصهاي عملکرد

کار انجام گرفته در دوره هاي گذشته، 10- اختلاف کار انجام شده برنامه ريزي شده در آن دوره، 11- اختلاف کار برنامه

ريزي شده کل با انجام شده کل، 12- پيش بيني روند،

 13- مشکلات و تنگناها و ساير اطلاعات موردي ضروري با توجه به مخاطب گزارش و همچنين متغيرهاي مطرح شده

ويژگيهاي يک گزارش عملکرد کارآمد

1- صحت اطلاعات

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

2- جامعيت اطلاعاتي

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

3- به هنگام بودن

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

از طرف ديگر هر قدر فاصله زماني بين انجام کار و گزارش زيادتر باشد ، کشف دلائل و علل انحراف نتايج کار از برنامه موردنظر، دشوارتر خواهد شد. زيرا گذشت زمان خود عامل مؤثري در خطاي ذهني و گم شدن علل انحراف است .

4- سازماندهي، ساختار و نحوه ارائه مطلوب

به طور کلي نحوه ارائه و ساختار هر گزارش و يا خبر، نقش بسيار تعيين کننده اي در ميزان تأثيرگذاري بر مخاطب دارد. به منظور ايجاد بالاترين تأثيرگذاري در گزارشات، مي بايست از روشهاي مختلف ارائه اطلاعات استفاده نمود. روشهاي معمول عبارتند از :

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

5- اخطار دهندگي

همواره لازمست که علاوه بر گزارش ميزان کار انجام گرفته و ميزان کار برنامه ريزي شده، مغايرت اين دو نيز گزارش گردد.شاخص قابليت » علاوه بر اين مغايرت، ضرورت دارد که امکان جبران تاخيرات نيز بررسي گردد. اين امر با استفاده از شاخصهايي چون قابل بررسي مي باشد. بررسي اولويت بندي عناصر تاخيرزا و ميزان بحرانيت هرکدام، مسائلي است که بايد در گزارشات «(DCI) جبرانعملکرد منعکس گردند. اين امر موجب مي شود که مخاطب گزارش هشدار لازم براي اتخاذ اقدام اصلاحي مناسب را دريافت نمايد.

6- صلاحيت تهيه کنندگان و فرايند گزارشگيري

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

7- تناسب اطلاعاتي

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

8- تعادل تأثيرگذاري:

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

فراهم نمودن اين ويژگيها براي هر گزارش کارامدي آن گزارش را تضمين مي نمايند. اما علاوه بر خصوصيات ثابت ذکر شده در بالا، براي تهيه هر گزارش عملکرد لازمست که مدير پروژه به دو سوال اساسي پاسخ گويد :

1- دوره زماني گزارشگيري چقدر باشد ؟

2- سطح گزارشگيري ساختار شکست کار در چه سطحي باشد (تعيين ميزان نياز به تجزيه ساختار شکست کار) ؟

عوامل مؤثر بر تعيين دوره زماني گزارش گيري :

همانطوريکه اشاره شد يکي از مهمترين کارويژه هاي گزارشات عملکرد ( و شايد مهمترين آنها ) ، استفاده از اين گزارشات به منظور تعيين اقدامات اصلاحي لازم به منظور جبران تخطيهاي احتمالي از برنامه ميباشد. پر واضح است که اين کار ويژه مشروط به تهيه به موقع اين گزارشات مي باشد. لذا يکي از مهمترين تصميم گيريهائي که در مورد گزارشات عملکرد ميبايست اتخاذ نمود، تعيين دروه زماني گزارش گيري مي باشد. در بسياري از پروژه ها گزارشات عملکرد از يک ابزار مديريتي کارساز، به يک شر لازم تنزل رتبه داده شده و بهاء لازم به آن داده نمي شود. متأسفانه گزارش گيري براساس کليشه هاي بي اساس و نظرات بي مبناي مديريتي، بعضا” کارآمدي گزارشات عملکرد را تا حد قابل ملاحظه اي کاهش مي دهد.

مدير پروژه بايد توجه داشته باشد که دوره هاي زماني گزارش گيري، تابع متغيرهاي فراواني است که با پيشرفت پروژه تغيير مي کنند. لذا تعيين دوره زماني مناسب براي پروژه در هر برهه زماني وظيفه مدير پروژه مي باشد. عوامل مؤثر بر دوره زماني به قرار زيرند:

1- حجم کار در هر دوره :

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

   با توجه به اين موضوع که به طور معمول توزيع حجم کار در زمان پروژه يکنواخت نمي باشد و حجم کار در نيمه دوم اين بازه زماني معمولا” بيش از نيمه اول است(چولگي به چپ) ، ضرورت دارد که مدير پروژه اين تغييرات را مدنظر داشته و دوره زماني گزارش گيري را با اين تغييرات همساز نمايد.

2- قابليت جبران :

همانطور که قبلا” نيز بدان اشاره شد، مهمترين خاصيت گزارشات عملکرد کمک به تعيين اقدامات اصلاحي لازم به منظورجبران تخطي از برنامه مي باشد. لذا با توجه به اين موضوع که هرچه از زمان پروژه سپري گردد امکان جبران عقب افتادگي از برنامه کمتر مي شود، بايد با کوتاه شدن زمان باقيمانده از پروژه (کم شدن امکان جبران مغايرتها) دوره زماني گزارشگيري را کوتاه تر نمود. با مي باشد، (CONSTRUCTION) با توجه به اين موضوع که در پروژه هاي پتروشيميايي آخرين مرحله ساخت پروژه ، مرحله ساختمان ضرورت دارد که در اين مرحله از دوره هاي زماني کوتاه گزارشگيري استفاده نمود.

3- شاخص بحرانيت

به طور کلي پروژه ها داراي فعاليتهاي متفاوتي هستند که از لحاظ تأثيرگذاري بر مدت زمان اجراي پروژه مي توان آنها را به

2دسته تقسيم نمود : 1- فعاليتهاي بحراني 2- فعاليتهاي غيربحراني.

فعاليتهاي بحراني آندسته از فعاليتها هستند که زمان شناوري نداشته و تأخير در آنها به هر اندازه موجبات تأخير کلي پروژه را فراهم  مي آورند . لذا اينگونه فعاليتها نيازمند نظارت و کنترل دقيق تري مي باشند . پس لازم است که گزارشات عملکرد، اينگونه فعاليتها رابصورت ويژه اي بررسي کرده و ارائه نمايند.به طور کلي در هر پروژه هرچه تعداد فعاليتهاي بحراني آن به تعداد کل فعاليتها در يک دوره زماني مشخص بيشتر باشد،متغير (CI = ) احتمال تأخير در تکميل پروژه بيشتر خواهد بود. شاخص بحرانيت پروژه (کل فعاليتها / تعداد فعاليتهاي بحراني)مناسبي جهت بررسي اين وضعيت در پروژه مي باشد. هرچه اين شاخص مقدار بالاتري را نشان دهد لازمست که دوره هاي زماني گزارشگيري را کوتاهتر نمود، چرا که يک واحد زماني تأخير داراي احتمال بالاتري براي به تأخير انداختن کل پروژه مي باشد. درصورتيکه در پروژه از زنجيره بحراني استفاده مي شود، مي توان همين اصل را براي فعاليتهاي زنجيره بحراني نيز اجرا نمود.

4-عملکرد پروژه

در هنگام بروز تلاطم و تغييرات متعدد در پروژه به تصميم گيريهاي اساسي و راهگشا نياز مي باشد. مهمترين الزام جهت در دسترس بودن اطلاعات (داده هاي پردازش شده را اطلاعات گويند) مي باشد. لذا گزارشات عملکرد به t اتخاذ يک تصميم اثربخش عنوان مرجع رسمي اطلاعات وضعيت پروژه، مي بايست در چنين شرايطي تا حد امکان تفصيلي و در دوره هاي زماني کوتاه تهيه شوند. چرا که در شرايط تلاطم و تغيير هر لحظه امکان تبديل حالت مطلوب به حالت نامطلوب ممکن مي باشد. همچنين در شرايط عملکرد نامطلوب پروژه نيز از آنجا که به يک اقدام اصلاحي مناسب و اثربخش نياز است و لازمه يافتن جهت (CPI) و عملکرد هزينه (SPI) راه حل مناسب چيزي نيست جز اطلاعات صحيح، به هنگام و جامع، شاخصهاي عملکرد زمانبندي بررسي عملکرد پروژه مناسب مي باشند. اما همواره بايد به خاطر داشت که اين شاخصها عملکرد تيم پروژه را نشان مي دهند و نه استفاده نمود. DCI يا SSI وضعيت پروژه را . جهت درک همزمان عملکرد و وضعيت پروژه مي توان از شاخصهاي

5- برنامه پذيري تيم پروژه

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

6- نقاط استراتژيک u1705 کنترل

بخشهايي از فرآيند پروژه که نتايج و عملکردشان نقش مهم و تعيين کننده اي در کل پروژه دارد را نقاط استراتژيک(کليدي) کنترل مي نامند. در پروژه هاي پتروشيميايي ايران بخش مربوط به سازندگان داخلي و همچنين کار مورد نياز جهت ساخت جزء نقاط کليدي کنترل (LONG DELIVERY ITEMS) تجهيزات و مواردي که مدت زمان تحويل آنها به سايت طولاني مي باشد

همچنين بخشهايي که نمودي از کل عملکرد پروژه مي باشند نيز به عنوان نقاط استراتژيک کنترل محسوب مي شوند. براي بسيار کليدي مي (PIPING) يک پروژه پتروشيميايي، عملکرد ديسيپلين لوله کشي (CONSTRUCTION) مثال در مرحله ساختمان باشد و مي تواند به عنوان يک نقطه استراتژيک کنترل مطرح باشد. به طور کلي از آنجا که شناسايي و نظارت بر نقاط استراتژيک کنترل در يک پروژه بسيار مهم مي باشد، لازمست که در گزارشات عملکرد توجهي ويژه به آنها بشود. همچنين انطباق و تناسب دورههاي زماني گزارشات عملکرد با زمان وقوع نقاط استراتژيک کنترل، بسيار مهم و ضروري مي باشد .

7- استفاده کنندگان از گزارش:

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

8- محدوديتها

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

سطح گزارش گيري

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

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

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

1- عدم احراز شرايط فوق در عناصر سطح آخر ساختار شکست کار

2- عدم وجود توافق نظر در مورد شرح کار عناصر سطح آخر ساختار شکست کار

3- اعلام نياز هر يک از ذي نفعان کليدي پروژه در مورد اطلاعات وضعيت و عملکرد بخشي خاص از برخي عناصر ساختار شکست کار

4-نياز به تدقيق براوردهاي زمان و هزينه و مقادير فيزيکي عناصر ساختار شکست کار

5- تعدد مسؤولين عناصرآخرين سطح از ساختار شکست کار

6- عناصر آخرين سطح از ساختار شکست کار دستاوردها و يا فرايندهاي کاري متعدد و متنافري را در بر داشته باشند

7- نياز به دانستن زمان يا هزينه تحقق هريک از فازها(مايل استونها)ي درون هر عنصر

8- وجود وابستگي بين فازها(مايل استونهاي) درون يک عنصر با يک عنصر ديگر ساختار شکست کار

9- وجود فواصل زماني قابل ملاحظه بين فازها(مايل استونها)ي عناصر ساختار شکست کار

10- تغيير منابع مورد نياز عناصر در گذر زمان

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

1-عملکرد ضعيف و غيرقابل قبول

2- اعلام نياز استفاده کنندگان از گزارش

3- عدم وجود منابع ضروري

4- ضريب بالاي بحرانيت

5- قابليت جبران کم

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

نتيجه گيري

تعيين دوره زماني گزارشات عملکرد و سطج گزارشگيري براي هر پروژه خاص متفاوت مي باشد. اين متغيرها همچنين در طول يک پروژه مشخص نيز با توجه به فاکتورهاي متعددي که در اين مقاله بررسي شد تغيير ميکند. لذا لازمست که مدير پروژه در طول يک

پروژه بنا به نيازهاي کنترلي آن پروژه، به طور دائم اين متغيرها را تعيين نمايد.

منابع

                            n1. Harold Koontz, MANAGEMENT: a global prespective,Tenth Edition, 1993, McGraw-Hill Inc.,575-680

         n2. Abstracted from T. Cooke-Davies, Return of the Project Managers, Management Today, BIM, UK, May 1990

 n3. Project Management Institute , A Guide to Project Management Body Of Knowledge (PMBOK® Guide) –

                                                                                    n2000 Edition. Newtown Square, PA: Project Management Institute . p142-143

n167- 4. سيد مهدي الواني، مديريت عمومي، چاپ هفدهم، تهران، نشر ني، 1381 ،صفحات 193

n279- 5. عليمحمد اقتداري، سازمان و مديريت، چاپ سي و چهارم، تهران، انتشارات مولوي، 1381 ،صفحات 266

n6. گزارشات عملکرد شرکت مديريت توسعه صنايع پتروشيمي

n7. انجمن مديريت پروژه. استاندارد عملي انجمن مديريت پروژه براي ساختارهاي شکست کار. احسان نجابت ، حسين اصولي –

nچاپ اول – تهران ، انتشارات شرکت ملي صنايع پتروشيمي، 1382 ، صص 8،9،20،21

منوی اصلی

آرشیو موضوعی

آرشیو مطالب

نویسندگان

راهنمایی و اضافات وبلاگ

آمار وبلاگ

امکانات