درحال مشاهده: مهندسی و مدیریت ساخت پروژه - مطالب ابر كنترل پروژه


ادعونی
اهدای خون
موسسه محک
اهداء عضو

Planning the Scope

-
-
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی

The first step in planning the scope of a project is to identify the requirements. Let’s take an office building. The customer [user] wants to hold its important meetings in the building (obviously). So, we need to have a conference room. What are the requirements for the room? For example, what’s the required capacity?

Then, we have to identify the building elements of the product. My preferred way is to use a mind-map. It starts with the final product, and then shows the main elements of the product in the next level. Those elements are broken down into smaller ones, and so on.

This is a great way to identify the scope, because that breakdown helps you find the gaps. You don’t have to use a mind-map (though I highly recommend it), but whatever you do use should be a hierarchical list. That hierarchical list of the building elements (deliverables) is called a WBS.

WBS stands for Work Breakdown Structure, and it is a terrible name for this concept! It’s misleading because of the word “work”. Most people think it’s a grouping for project activities, but that’s not right. If you see it like that, and probably deal with a WBS only in the scheduling software, please stop. Just try it once. Identify the building elements of a product with a mind-mapping software in a facilitated workshop. You’ll be amazed by the number of problems you prevent.

So, to understand the product, we need to define its scope and quality. How should we plan quality?



محصول یا نتیجه

-
-
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی

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

چرا پروژه رو انجام می‌دیم؟
برای این‌که محصولی تولید کنیم.
چرا محصول رو تولید کنیم؟
برای این‌که نتیجه‌ای انتظار داریم.
چرا نتیجه‌ای انتظار داریم؟
چون می‌خوایم باهاش به منافعی برسیم.
چرا می‌خوایم به منافع برسیم؟

دیگه از این‌جا به بعد سوال و جواب یه مقدار فلسفی می‌شه و می‌ذاریمش برای یه موقع دیگه.
حالا بیاین همون سوال و جواب رو با مثال تکرار کنیم:

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

خوب، حالا فرقی نداره پروژه چطوریه، باید یه بار هم مسیر رو برعکس طی کنیم:

پس می‌خوایم جلوی ضررهامون رو بگیریم. آیا الان ضرر بزرگ‌تری نمی‌کنیم یا فرصت بهتری برامون وجود نداره که روی اون تمرکز کنیم (منافع > نتیجه)؟
نه!
خوب، پس همون سیستم مدیریت اسنادمون رو بهبود می‌دیم. حالا چطوری می‌تونیم این کار رو بکنیم (نتیجه > محصول)؟
گفتم که، با شیرپوینت.
راه حل‌های دیگه چیه؟ باید اون‌ها رو با هم بسنجیم و ببینیم بهترینش چیه، همینطوری که نمی‌تونیم بریم سراغ شیرپوینت.

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


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

محصول یا نتیجه



Tailor it

-
-
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی

There are many reasons why you cannot follow the PRINCE2 manual line by line, and succeed. The key reason is that it’s generic, and you cannot use it out of the box. Every project has its own environment and the methodology should be “tailored” for it.

A common problem is having PRINCE2 implemented in the project without any thoughts and without tailoring. The result is usually an extreme bureaucratic environment that everyone hates, and doesn’t bring any benefits.

A good example for tailoring is the Checkpoint Report. It’s a performance report that Team Managers send to the Project Manager periodically. Should it exist? Yes, always. Should it be a long document? No! If the project is simple, the Checkpoint Report can be even a simple telephone call on certain time to discuss certain things. That’s proper tailoring.

The seventh core principle is: Tailor to suit the project environment.
Tailor it
Remember that all successful project management systems are simple.
OK, we’ve reviewed all seven core principles of PRINCE2. Which one is your biggest weakness in your projects?
We’ll have a recap tomorrow.



چابکی در پروژه - محصول‌های متعین

-
-
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی

چابکی در پروژه - محصول‌های متعین

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

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

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

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


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



مهندسی و مدیریت ساخت پروژه - مطالب ابر كنترل پروژه

مهندسی و مدیریت ساخت پروژه - مطالب ابر كنترل پروژه,مدیریت ساخت ,مدیریت پروژه, مدیریت پروژه های ساخت, مدیریت پروژه و ساخت,مدل سازی اطلاعات ساختمان,مدیریت ساخت
تمامی حقوق این وب سایت متعلق به مهندسی و مدیریت ساخت پروژه است. |طراحی و توسعه:امیرحسین ستوده بیدختی|