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

در طراحی این کارگاه تلاش شده موارد زیر مورد توجه قرار گیرد:

  • تعریف روش و فرآیندی ساخت‌یافته برای سازماندهی، برآورد، بودجه‌ریزی و کنترل هزینه پروژه‌ها
  • تفکیک مفاهیم کلیدی هزینه / درآمد / نقدینگی از یکدیگر
  • تشریح پیامدهای ناشی از اشتباه‌های رایج در مدیریت هزینه و نقدینگی
  • تشریح تجارب موفق در زمینه مدیریت هزینه و نقدینگی پروژه‌ها
  • تمرکز مفاهیم برای به‌کارگیری در یک پیمانکار EPC (با توجه به پیچیدگی‌های ناشی از ماهیت قرارداد و مسوولیت‌های پیمانکار در قبال مدیریت هزینه)
  • استفاده از یک مثال و تمرین برای تشریح مفاهیم
  • رویکرد تعاملی در تشریح و بررسی مفاهیم و کاربردهای آنها
  • تشریح مفاهیم به گونه‌ای که قابلیت کاربرد در دو رویکرد In-house و Out source در شرکت‌‌های پیمانکاری را داشته باشند.

سرفصل مطالب

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

آقای مهندس مزدك عبائي، دانش آموخته كارشناس ارشد مهندسي و مديريت ساخت (دانشگاه تهران) و كارشناس مهندسي عمران (دانشگاه صنعتي شريف) و همچنین دارای مدارک حرفه ای گواهینامه PMP و PBA از انمجمن مدریت پروژه آمریکا می باشد .او سابقه تدريس در بيش از ۱۸۰ دوره و كارگاه آموزشي در زمينه‌هاي مديريت پروژه، مدیریت قراردادها و دعاوی، تعالي مديريت پروژه و مهندسي‌ارزش در کارنامه خود دارد . او همواره در کنار کارهای آموزشی، فعالیتهای حرف های خود را نیز ادامه داده است که این امر سبب ارائه خدمات مشاوره و آموزشی قوی از سوی او شده است .چراکه از نزدیک با دغدغه ها و چالشهای سازمانها و افراد در حوزه های مدیریت پروژه سازمانی ارتباط دارد.از سوابق حرفه ای او می توان :

مشاور و دستیار رییس هیات مدیره شرکت کیسون

مشاور و مدرس مدیریت پروژه و مدیریت قراردادها

مدیر سابق PMO در شرکت های کیسون و مهاب قدس

مدیر سابق دفتر هماهنگی خدمات مدیریت شرکت سابیر

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

تغییر آزمون PMP در سال 2018

آزمون PMP در تاریخ ششم فروردین ماه 1397 به دلیل تغییر ویرایش استاندارد PMBOK، تغییر کرد. در سپتامبر سال 2017، کتاب استاندارد PMBOK ویرایش ششم منتشر گردید و براساس خبری که در سایت PMI اعلام شد، تقریبا هفت ماه بعد یعنی در تاریخ 26 مارچ 2018، آزمون PMP بروزرسانی گردید.

اجایل در آزمون PMP

انجمن مدیریت پروژه آمریکا (Project Management Institute) در تاریخ بیست و ششم مارچ 2018 آزمون PMP را تغییر داد و این تغییرات بر اساس ویرایش ششم کتاب PMBOK می باشد که نسبتا هم زیاد است.یکی از این تغییرات، اضافه شدن مبحث اجایل به متن استاندارد و همچنین آزمون می باشد.

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

چگونه محدوده محصول تعیین می شود؟

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

این یک گام مهم به سوی تکمیل موفقیت آمیز پروژه است.

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

محدوده پروژه

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

 

تفاوت بین محدوده پروژه و محدوده محصول

در زیر چند تفاوت بین محدوده پروژه و محدوده محصول را ملاحظه می کنید:

محدوده پروژه کاری است که در پایان، محصول را ارائه می دهد. 

•محدوده پروژه اشاره به همه چیز که باید انجام شود جهت ارائه محصول دارد و محدوده محصول شامل ویژگی ها و خصوصیات محصول است.

•دامنه محصولات متمایل به "چه" بخشی (الزامات عملکردی) و دامنه پروژه محور متمایل به "چگونه" بخش (کار مرتبط) است.

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

 

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

برنامه احتیاطی  Contingency Plan

مریام وبستر "احتیاط" را اینگونه شرح می دهد؛ یک رویداد که ممکن است رخ بدهد یا ندهد. این توضیح بر این مبنا است که برنامه احتیاتی  برنامه ای است که برای مواجه با رویدادهایی است که احتمال دارد رخ دهد.

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

توجه داشته باشید؛ برنامه احتیاطی  برای ریسکهای شناخته شده بکار برده می شود.

یک مثال واقعی

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

با جستجو در اینترنت به تعاریف مختلفی برای  شرح برنامه احتیاتی  موجه خواهید شد که تفاوتی در شرح موضوع وجود ندارد و فقط از کلمات متفاوتی برای توضیح دادن استفاده شده است مانند: 

-         برنامه احتیاتی  برنامه ای است که کارهای خاصی در زمان رخ دادن یک تهدید و یا فرصت انجام می گیرد. 

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

در واقع بعد از بررسی این دو تعریف ملاحظه می شود که تعاریف کاملا شبیه هم هستند و با آنچه که در قبل شرح داده شد متفاوت نیست.

 برنامه جایگزین Fallback Plan 

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

مثال

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

 

 

تغییرات استاندارد پمباک ویرایش ششم (PMBOK 6th)، انجمن مدیریت پروژه آمریکا (PMI)، بصورت معمول هر 4 الی 5 سال، نسخه جدید از کتاب راهنمای پیکره دانش مدیریت پروژه ارائه می نماید که در آخرین نسخه آن (ویرایش ششم) در تابستان 1396 منتشر می شود.

متدلوژی مدیریت پروژه ترکیبی (Hybrid Project Management Methodology)

Several months ago, I had a consultancy meeting with one of my clients in the telecommunication sector. A meeting with the PMO manager and his crew was about selecting the right and sufficient project management methodology for the PMO department. They had been using a methodology that was developed using A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition for three years. The company has more than 5,500 people and 30 live projects. It has several competitors, and the economy and technology are unpredictable external factors—so it has to complete and deliver its projects quickly and efficiently.

Let’s get back to the meeting. I asked the PMO manager to explain current and upcoming projects to me. The company had been using MS Project Server 2013 as a PMIS. The manager and team showed me the project portfolio dashboard, which included more than 30 projects, sub-programs and programs. After that, the PMO manager described the project portfolio components. Finally, he said that the reason behind inviting us was that the company CEO wanted to be more agile. They wanted us to find a way to deliver the project’s value more quickly.

Before asking about their project management methodology, I asked them to describe their project types. In a nutshell, they divided their projects in two categories:

  1. IT services projects such as customer portal, CRM, value-added services (VAS) portal, etc.
  2. Networking services projects such as core network rollout, BTS installation, site administrative management (SAM), radio and core optimization, etc.

The PMO manager described their project management methodology. They have developed and customized the Telecom Enterprise Project Management Methodology (TEPMM) based on PMBOK® Guide—Fourth Edition and used it on whole projects.

If you look back to the categories, you can find that they have completely different elements. The first category had a change-driven development element because they were software projects. In the information technology projects, we can’t define product and project scope comprehensively (and in full detail) in advance. Most of the time, we have to change the features and requirements. We should also deliver some parts of the product during the project because early and continuous delivery is vital in the software industry. Then we have to structure the project and team to deliver value early and frequently.

On the other hand, the second category had a plan-driven development component because of the hardware and site installation, core network rollout, etc. In this category, project and product scope were clear. Most of the time, we can use waterfall methods and sequential phases. They used TEPMM for both IT services and networking services projects. However, they were encountering two problems:

  1. Some programs and projects included both categorizations.
  2. The TEPMM was heavy for projects in the first category.

Monitoring and controlling the project portfolio based on this unique approach 
I recommended a hybrid Scrum/PMBOK® Guide methodology that we called TEPMM2. It included all of the principles and elements identified in both Scrum and PMBOK® Guide. In this methodology, we use the PMBOK® Guide as an external layer and Scrum as an internal layer. The external layer includes project management processes, and in the internal layer we have product management processes:

Figure 1.1: Part of TEPMM2 methodology

After approving the project charter, we should collect requirements and define the product backlog, so we should use the decomposition technique. The project is broken down into manageable items either by discipline (installation, software, networking, etc.) or by functionality. At the lowest level of the WBS, we will have a list of work packages. Based on those elements (linear or incremental), we put them into one or more sprints. For example, installation hardware is linear, and implementing user login is incremental (because of intellectual property issues, I can’t publish the complete methodology framework).

In conclusion, many companies and organizations that work in different industries encounter the same challenges, specifically in the IT, EPC, telecom and R&D industries. They have both plan-driven and change-driven projects. Sometimes, some part of a project is best suited to an agile approach, while other parts to a PMBOK® Guide approach. So implementing a hybrid methodology can be more effective and useful, because traditional approaches are so heavy and complex for incremental projects or works. In some projects we have both approaches (agile and traditional) together, so applying a methodology that supports that is important.

راهنمای تصویری آموزشی مراحل تکمیل فرم PMP Applicationراهنمای تصویری آموزشی مراحل تکمیل فرم PMP Applicationمتاسفانه از بسیاری داوطلبین شنیدم که برخی از افراد و موسسات در ایران، برای تکمیل فرم آزمون پی ام پی (PMP Application Form ) مبالغی را از داوطلبین دریافت می کنند .بر خود واجب دانستم که با راهنمایی گام به گام شما داوطلب گرامی، جلوی این کار غیر حرفه ای را بگیرم .  برای تکمیل فرم PMP Application ، نیاز است شما 2 مرحله را طی نمایید که من برای هر 2 مرحله ویدیویی تهیه کردم . **مرحله اول: راهنمای عضویت در سایت انجمن مدیریت پروژه آمریکا PMI (جهت مشاهده ویدیو اینجا را کلیک نمایید) .** مرحله دوم :  راهنمای تکمیل فرم PMP Application (جهت مشاهده ویدیو اینجا را کلیک نمایید).

 

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

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

طبق کتاب راهنمای مدیریت پروژه، مدیر پروژه می تواند 5 نوع از قدرت را داشته باشد:

1-     قدرت رسمی یا قانونی ( Formal or Legitimate Power)

2-     قدرت پاداش (Reward Power)

3-     قدرت تنبیه (Punishment Power)

4-     قدرت مهارت (Expert Power)

5-     قدرت ارجاع دادن (Referent Power)

این قدرت ها می توانند به دو عنوان جایگاهی و شخصی دسته بندی شوند.

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

قدرتهای پاداش و مهارت بهترین نتیجه را برای مدیر پروژه دارند.

1-     قدرت رسمی یا حق قانونی ( Formal or Legitimate Power)

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

2-    قدرت پاداش (Reward Power)

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

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

پاداش باید دست یافتنی بوده و نباید نوع آن برد- باخت باشد و پرداخت آن منصفانه و روشن برای همه افراد در نظر گرفته شود.

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

3-    قدرت تنبیه (Punishment Power)

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

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

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

4-    قدرت مهارت Expert Power))

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

5-    قدرت ارجاع دادن (Referent Power)

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

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