تعود فكرة إدارة المشاريع إلى عهد طويل من الزمن. فإذا فكرت بكل الأشياء التي تشكلت في تاريخ الحضارات ستجد أنه لدينا الآلاف من سنوات الخبرة في إدارة المشاريع لنتعلم منها.

إن الشخص المسئول عن إدارة المشروع في العديد من المنظمات لا يشغل بالضرورة منصب مدير المشروع، حيث يقوم كل من المبرمجين والمدراء ورؤساء المجموعات والمسؤولين عن اختبار المنتجات والمصممين بإدارة المشاريع في عملهم اليومي، سواء كانوا يعملون وحدهم أم يقودون فرق عمل. وفي سلسلة مقالاتنا حول إدارة المشاريع التي تعد تجميع لأسباب نجاح المشاريع وكيفية قيام الأشخاص الذين يقودون مشاريع ناجحة بعملهم. إن الأفكار الأساسية والاستراتيجيات لا تتطلب مناصب أو طرقًا أو هرمية محددة، لذلك إذا كنت تعمل على مشروع ما وكان لديك جزء من المسؤولية عن نتائجه فإن ما يلي سينطبق عليك، وبخاصة إذا حملت بطاقة التعريف بعملك عنوان (مدير مشاريع)، فعندها سيكون هذا رائعًا.
لقد صمم هذه المقالات لتكون مفيدة في ثلاثة مجالات: كمجموعة مقالات متخصصة في موضوع محدد أو كموضوع سردي موسع، أو كمرجع للحالات العامة. حيث يختص كل فصل بمهمة عالية المستوى، ويقدم إطار عمل أساسيًا وخططًا واستراتيجيات لإتمام هذه المهمة بنجاح، بينما يتسم هذا الفصل الأولى بطريقة عرض مختلفة، حيث يتناول ثلاثة مواضيع عامة لتسهل متابعة هذا الكتاب.
الموضوع الأول هو لمحة تاريخية قصيرة عن المشاريع ولماذا يجب أن نتعلم من إنجازات الآخرين. أما الثاني فهو عبارة عن خلفية بسيطة عن الأشكال المختلفة لإدارة المشاريع وتتضمن بعض الملاحظات من خبرتي في العمل لدى شركة Microsoft. ويلقي الموضوع الثالث نظرة على التحديات الكامنة في إدارة المشاريع وكيف يمكن التغلب عليها. على الرغم من أن فائدة هذه النقاط ستتوضح لاحقًا، فإنه يمكن استيعاب الفصول اللاحقة بدونها، وبالتالي يمكنك الانتقال فورًا إلى الفصل الثاني ونواة هذا الكتاب إذا رغبت في ذلك.

لمحة تاريخية موجزة
تعود فكرة إدارة المشاريع إلى عهد طويل من الزمن. فإذا فكرت بكل الأشياء التي تشكلت في تاريخ الحضارات ستجد أنه لدينا الآلاف من سنوات الخبرة في إدارة المشاريع لنتعلم منها. فمثلاً يمكننا الربط بين مطوري البرامج في وقتنا الحاضر وبين بناة الأهرامات في مصر أو المعماريين الذين صمموا قنوات المياه الصنعية الرومانية عبر التاريخ. لقد لعب مدراء المشاريع في تلك الاختصاصات أدوارًا مشابهة عندما طبقوا التقنيات على المشكلات الموجودة في زمانهم. أما في عصرنا الحالي، فمن النادر أن يهتم الأشخاص الذين يحاولون تحسين طريقة إدارة مشاريعهم البرمجية أو مواقعهم على الإنترنت بالدروس المأخوذة من الماضي، فالخط الزمني الذي نستخدمه كمجال للمعرفة المفيدة يعتبر قريبًا جدًا من الحاضر أكثر مما يجب. 
إن تاريخ المشاريع الهندسية يبين أن أغلب المشاريع فيها العديد من أوجه التشابه، حيث إن جميع هذه المشاريع لها متطلبات وتصاميم وقيود، وهي تعتمد على الاتصالات واتخاذ القرارات ومزيج من الأفكار المنطقية والإبداعية. تتضمن المشاريع عادة جدولة زمنية وميزانية وعملاء. والأمر الأهم هو أن مهمتها الأساسية هي تجميع أعمال عدة أشخاص في وحدة متناسقة تكون مفيدة بالنسبة للأشخاص أو العملاء. وهناك مجموعة من المفاهيم الأساسية التي تشترك بها أغلب المشاريع سواء كان اعتماد المشروع على HTML أم ++ C أم على الفولاذ والأسمنت.
لقد اهتممت بشكل خاص بمجال تطوير الوب والبرمجيات بسبب فضولي تجاه الحصول على أفضل الطرق للقيام بهذا الأمر. بالإضافة إلى دراستي لمجالات وصناعات أخرى لأعرف كيف تمكنوا من تجاوز التحديات الأساسية في مشاريعهم. وبذلك يمكنني أن أطبق حلولاً مشابهة في عملي الخاص. فمثلاً كنت دائمًا أتساءل: كيف تم تصميم وتنفيذ مشاريع مثل Hubble Space Telescope و Boeing 777؟ وهل يمكنني إعادة استخدام أي من مواصفاتهم المعقدة وعملياتهم التخطيطية؟
أو كيف تم بناء Chrysler Building في نيويورك و Parthenon في أثينا؟ هل قام قائدو المشاريع بالتخطيط والتقدير بنائهم بنفس الأسلوب الذي يتبعه المبرمجون الذين يعملون معي؟ ما الاختلافات الهامة وما الذي يمكن أن نجنيه من اختبار هذه الاختلافات؟
ماذا عن محرري الصحف، الذين ينظمون ويخططون لإنتاج المعلومات اليومي؟ لقد عملوا في مجال الوسائط المتعددة (الصور والنصوص) قبل حلم النشر على الإنترنت بزمن طويل. ماذا عن إنتاج فيلم المستقبل؟ عن إقلاع Apollo13؟ لقد تمكنت بدراسة هذه الأسئلة من إلقاء الضوء على كيفية قيادة فرق عمل المشاريع بأسلوب جديد.
إن هذه التساؤلات من جهة أخرى لا تقدم دائمًا إجابات واضحة. فأنا لا أعدك بأن تتقدم سريعًا أو أن تخطط بشكل أفضل، خاصة لأن النصائح الموجودة في هذا الكتاب تأثرت بتلك المصادر. ولكنني أعرف جيدًا أنني عندما عدت إلى عالم البرمجيات بعد البحث في أماكن أخرى وجدت أن عملياتي وأدواتي الخاصة بدت مختلفة بالنسبة لي، فقد اكتشفت طرقًا لتغييرها لم تكن تخطر لي من قبل.
لقد وجدت بالمحصلة أن العديد من المقارنات والطرق المفيدة التي اكتشفتها لم تذكر قط في دراستي لعلوم الحاسب في الجامعة، كما أنها لم تناقش أبدًأ في مؤتمرات التقنية ولم يكتب عنها في المجلات التجارية.
إن الدروس الأساسية التي حصلت عليها من بحثي في الماضي هي النقاط الثلاث الآتية:
1- إن إدارة المشاريع وتطوير البرمجيات ليست فنونًا مقدسة: إن أي عمل هندسي معاصر هو عبارة عن مدخل جديد في التاريخ الطويل لتشكيل الأشياء. من الممكن أن تتغير التقنيات والمهارات، إلا أن العديد من التحديات الأساسية التي تعقد العمل الهندسي تبقى موجودة. فجميع الأشياء سواء كانت لغات برمجية أم منهجيات تطوير تعتبر فريدة من جهة ومشتقة من جهة أخرى. ولكن إذا أردنا إعادة استخدام أي مقدار مرغوب من المعرفة المأخوذة من الماضي يجب أن نتأكد أننا نستوعب اختيار الجهتين -التفرد والاشتقاق- بالمقارنة مع ما حصل سابقًا.
2- كلما كانت نظرتك أبسط تجاه ما تفعله، توفر لك المزيد من الطاقة والتركيز أثناء التنفيذ: إذا استطعنا المحافظة دائمًا على رؤية مبسطة لعملنا، يمكننا عندها اكتشاف مقارنات مفيدة مع طرق أخرى لصنع الأشياء الموجودة حولنا. كما سيتوفر لدينا المزيد من الدروس والأمثلة من الماضي ومن الصناعات الحديثة التي يمكننا الاستنباط منها والمقارنة معها ومناقضتها. إن هذا يشب المفهوم الذي تعرفه بالكلمة اليابانية شوشين (Shoshin) التي تعني التفكير المبدئي أو التفكير المفتوح، وهو جزء أساسي من أنظمة العديد من المواد الغنية. إن المحافظة على الانفتاح والفضول هي التي تجعل التطوير ممكنًا، وهي تتطلب التدرب على المحافظة على المنهج الفكري. لكي نستمر بالتعلم يجب أن نتجنب إغراء الانجذاب نحو الآراء المحددة والآمنة تجاه ما نفعله.
3- البساطة لا تعني السهولة: إن أفضل الأبطال الرياضيين والكتاب والمبرمجين والمدراء يميلون لأن يسروا دائمًا أعمالهم بسيطة في طبيعتها وصعبة في الوقت نفسه. تذكر أن البساطة ليست نفسها السهولة. فعلى سبيل المثال: إنه لأمر بسيط أن تجري في سباق الماراثون، فأنت تبدأ الجري دون أن تتوقف إلى أن تقطع مسافة 26.2 ميلاً. ماذا أبسط من هذا؟ إن حقيقة كونه صعبًا لا تناقض بساطته. فالإدارة والقيادة تعتبران أيضًا من الأمور الصعبة، إلا أن طبيعتهما - إنجاز المهام بطريقة محددة من أجل هدف محدد- تعتبر بسيطة.
ستتم الإشارة إلى هذه المفاهيم في فصول عديدة، وفي بعض الأحيان تكون هذه المواضيع خارج الحدود المعروفة للتطوير البرمجي. آمل أنك ستتفهم أسباب ذلك. وعندما اقترح بأن اتخاذ القرارات أو الجدولة هي وظائف إدارية بسيطة سأفترض أنك تعلم أن هذا لا يشير بأي شكل أنها أمور من السهل القيام بها.
التعلم من الفشل

«إن البشر الذين يتميزون (عن الحيوانات) بامتلاكهم القدرة على التعلم من تجارب الآخرين، يتميزون أيضًا بإعراضهم الواضح عن هذه الفائدة».
Douglas Adams

إن سؤالاً بسيطًا ينتج عن دراسة تاريخ المشاريع، وهو: لم يرغب أي كان في أن يعاني من الأخطاء والخيبات إذا كان من الممكن تجنبها؟ على الرغم من أن تاريخ الهندسة القديمة والمعاصرة متوفر بشكل واسع في متناول العموم، إلا أننا كنا نتقاضى أجرًا عن القيام بأفعال ذكية بغض النظر عن مصدر الإلهام. فلماذا هي قليلة المنظمات التي تكافئ الأشخاص على تحصيل العبر من الماضي؟ بينما وفي كل يوم تكتمل مشاريع وتلغى أخرى (ينتهي العديد من المشاريع التطويرية بهذا الشكل). كل يوم تبذل جهود قليلة فقط للتعلم مما حصل؟ يبدو أن المدراء في أغلب المنظمات نادرًا ما يكافئون الأشخاص الذين يبحثون عن هذه المعرفة. وقد يعود السبب في ذلك إما إلى الخوف مما قد يكتشفونه أو الخوف من تحمل المسؤولية تجاه ذلك. أو ربما قلة الاهتمام من قبل أي شخص لمراجعة التجارب المؤلمة والمخيبة في حين يمكن أن يُمضي الوقت بدلاً من ذلك في بحث الموضوع الجديد التالي.
في كتاب Henry Petroski دور الفشل في التصميم الناجح: في الهندسة طابع إنساني (Vintge Books,1992) يشرح عددًا من التطورات التقنية المفاجئة التي حصلت في الهندسة كنتيجة للفشل. إن هذا يحصل من جهة لأن الفشل يجبرنا على مزيد من الانتباه، حيث يتطلب منا كل فشل أن نعيد اختبار الفرضيات التي نسينا وجودها (من الصعب التظاهر بأن كل شيء على ما يرام بينما يتجزأ النموذج الأولى إلى عدة قطع) تبعًا لاقتراح Karl Popper يوجد نوعان فقط من النظريات: تلك التي تعتبر خاطئة، والأخرى غير المكتملة. بدون الفشل سننسى (بسبب كبريائنا) أن استيعابنا للأمور ليس مكتملاً كما نظن.

حينئذ تكمن المهارة في التعلم قدر الإمكان من فشل الآخرين، وعلينا أن نستخدم خبراتهم في دعم المستقبل.

رغم اختلاف التفاصيل الظاهرية للفشل اختلافًا عظيمًا من مشروع إلى آخر فإن المسببات الجذرية أو الأعمال التي قام بها فريق العمل والتي أدت إلى هذه المسببات من الممكن أن يتم نقلها أو تجنبها كليًا. حتى في مشاريعنا الخاصة علينا أيضًا أن نتجنب الهروب والاختباء من الفشل. بدلاً من ذلك علينا أن ننظر إلى التجارب الفاشلة على أنها فرص جيدة للتعلم، وأن نستكشف العوامل المسببة لحدوثها؟ أي منها يمكن تخفيضه أو إلغاؤه بسهولة؟ تبعًا لوجهة نظر petroski فإن المعرفة الحقيقية المأخوذة من الفشل الحقيقي تمثل المصدر الأقوى للتقدم الذي نحن عليه الآن باعتبار أنه تتوفر لدينا الشجاعة لنختبر ما حدث بعناية.
ربما لهذا السبب قامت شركة Boeing، وهي واحدة من أكبر شركات هندسة وتصميم الطائرات في العالم، بالاحتفاظ بكتاب أسود يتألف من الدروس التي تعلمتها من فشل العمليات التصميمية والهندسية. لقد احتفظت الشركة بهذا الملف منذ بداياتها. وهي تستخدمه لكل يساعد المصممين المعاصرين على التعلم من المحاولات الماضية. إن أي منظمة تتدبر القيام بذلك لا تزيد فقط من احتمالاتها لنجاح مشاريعها بل تساعد أيضًا على خلق بيئة من الممكن فيها مناقشة ومواجهة الفشل بشكل منفتح، بدلاً من التنكر له والاختباء منه. يبدو أنه على مطوري البرمجيات الاحتفاظ بكتبهم السوداء الخاصة.
تطوير الوب، المطابخ وغرف الإسعاف
إحدى المشكلات المتعلقة بالعودة إلى التاريخ هي أنه ليس مشابهًا دائمًا لما نحن عليه. من الممكن أن يكون من الصعب تطبيق الدروس عبر عقود من الزمن، وكذلك التعاطف مع الأشياء التي تبدو مختلفة جدًا عن طريقة إنجاز الأعمال حاليًا. ويكون أحد البدائل هو أن تجري مقارنات مع أنواع مهمة من المشاريع الحديثة. في حين أن هذا ليس له نفس أهمية التاريخ الهندسي إلا أنه يقدم ملاحظات وخبرات الشخص الأول. غالبًا إن رؤية الأشياء مباشرة هي الطريقة الوحيدة لتزويد الناس بالمعلومات الكافية للربط بين الأفكار المختلفة.
كمثال على ذلك، أعرف مطور وب يعتقد أن عمله لا يشبه أي شيء آخر في تاريخ الكون. فهو يشعر أنه بسبب أن طبيعة عمله تتطلب اتخاذ قرارات هندسية معقدة - تصميمية وتنسيقية كلما تطور عمله وكذلك التأكد من متابعة التغييرات الحاصلة خلال ساعات أو دقائق، ومن ثم نشر كل ذلك إلى العالم -فإن مشروعه وإدارته للمهام لا تشبه أي شيء قد حصل مسبقًا. إنه فخور بمهارته في كل من Java و  Flashو XHTML و CSS والتقنيات الأخرى التي يحترفها، مصرحًا أنها كانت ستحير أعظم الأدمغة منذ خمسين عامًا مضت.
أنا واثق أنك قابلت شخصًا مثله في حياتك، أو ربما تكون قد عملت في حالات بدت وكأنه يصعب على أي شخص في العالم أن يتدبر أي شيء بصعوبة وتعقيد ما تفعله.
اقترحت على صديقي المطور البرمجي هذا أن يتجول في المطبخ الخاص بالمطعم المفضل لديه في يوم حافل. وذلك لعدة أسباب، أولاً أنه من الممتع أن تلقي نظرة على المطابخ (راجع كتاب Anthony Bourdain الرائع، أسرار المطبخ Ecco,2001). ولكن هدفي المحدد كان موضوع الإنتاجية، فعندما يرى أحد الأشخاص للمرة الأولى سرعة إدارة وتنسيق المهام التي تنجز في مطبخ احترافي حافل بالطلبات، فإنه على الأغلب سيعيد النظر في مدى صعوبة العمل الذي يقوم به. يتعامل الطباخون في غالب الوقت مع أدوات المطبخ من أجل طلبات مختلفة وحالات مختلفة لإتمامها، كما أنهم يطوفون على عدة مواقد في الزوايا الأخرى، بينما يقوم الندل (جمع نادل) بالدخول والخروج لإيصال الأخبار عن التعديلات والطلبات الجديدة من قبل الزبائن.
إن كل ذلك يحدث في غرف صغيرة وضيقة حيث تتجاوز درجة الحرارة التسعين وأضواء المصابيح تسطع في الأعلى. وعلى الرغم من كثرة الطلبات التي تخرج كل بضعة ثوان، فإن الطلبات الجديدة تدخل بنفس السرعة. كما أن هناك بعض الطلبات التي تعود، كما يحدث مع المشاريع البرمجية التي تتطلب تعديلات من قبل الزبون وتعديلات اللحظة الأخيرة (الطاولة رقم 1: السكر غير كافٍ، الطاولة رقم 2: يطلب إضافة الصلصة إلى الطبق الجانبي، وهكذا). إن مراقبة المطابخ الكبيرة والمشغولة أمر مذهل، فهي تبدو فوضوية في البداية إلا أنها تدار بمستوى من العناية والدقة يفوق عمل أغلب مجموعات التطوير.
إن الطباخين الماهرين هم مدراء مشاريع مطبخية، أو كما يصفهم Bourdain المتحكمون بحركة مرور الهواء (حرفة أخرى يجب أخذها بالاعتبار من قبل الممتعن). على الرغم من أن فريق العمل في المطبخ يعمل ضمن مجال أصغر وأقل شهرة من مدير فريق التطوير البرمجي، فإنه لا مجال لمقارنة كثافة العمل اليومي. إذا لم تصدق، اسأل النادل في المرة التالية التي تتناول فيها الغداء في مطعم أن يسمح لك بالدخول إلى المطبخ، إنه قد يرفض ولكن إذا سمح لك، فإن ظنك لن يخيب. (بعض المطاعم الحديثة فيها مطابخ مفتوحة، إذا وجدت أحدها، اجلس قريبًا من المطبخ قدر المستطاع، وحاول متابعة أحد الأشخاص لبضعة دقائق. راقب كيف تدخل الطلبات وكيف تتم متابعتها وتجهيزها وإيصالها. إذا ذهبت في يوم حافل فإنك ستفكر بشكل مختلف تجاه الأخطاء البرمجية، كيف تتشكل وتتابع وبعد ذلك تصحح).
من الدروس العملية الهامة أيضًا في مجال إدارة المشاريع ما يأتي من غرف الإسعاف في المستشفى. لقد تابعت ذلك على أحد الأقنية، حيث تقوم فرق صغيرة من الأطباء المحترفين والممرضات والمختصين يعملون معًا كفريق عمل في مشروع لمعالجة الحالات المتنوعة وأحيانًا الغريبة التي تدخل المستشفى. ليس مستغربًا أن هذه المهارة هي التي أدت إلى الإجراء المسمى triage، وهو المصطلح الشائع في المشاريع البرمجية لترتيب أولويات المواضيع والعيوب البرمجية.
إن البيئة الطبية، وخاصة حالات الكسور والرضوض، تقدم نموذجًا رائعًا للعمل الذي يحتاج إلى مجموعة أشخاص، وحالات اتخاذ قرار تحت ضغوط نفسية هائلة ونتائج المشاريع التي تؤثر على حياة العديد من الأشخاص كل يوم.
كما كتب Atul Gawande في كتابه الرائع (تعقيدات: ملاحظات الجراح على العلم غير الكامل (Picador USA, 2003:
نحن ننظر إلى الطب على أنه حقل المعرفة والإجراءات المنهجي. ولكنه ليس كذلك. إنه علم غير كامل، فهو مؤسسة للمعرفة المتغيرة باستمرار، وللمعلومات غير المؤكدة والأفراد اللامعصومين. ولكنه في الوقت نفسه يمس حياة جميع الناس مباشرة. إن ما نقوم به فيه شيء من العلم، أجل، ولكنه يعتبر أيضًا عادة أو فطرة وأحيانًا تخمينًا بسيطًا وقديمًا. إن الفجوة بين ما نعرفه وما نهدف إليه موجودة، وهي التي تعقد كل ما نفعله.
تنطبق هذه النقطة بالإضافة إلى نقاط أخرى عديدة في كتاب Gawande الرائع على التطوير البرمجي. لقد أجرى Fred Brooks في كتابه عن هندسة البرمجيات مقارنات مشابهة بين مجموعات عمل من الجراحين ومجموعات عمل من المبرمجين، وعلى الرغم من أن حياة الناس لا تكون في حالة مخاطرة في مجال العمل بمواقع الوب أو قواعد البيانات فإنه يوجد العديد من التشابهات الفعلية في التحديات التي يجب على هؤلاء الأشخاص المتباينين مواجهتها.
دور إدارة المشاريع
إن إدارة المشاريع يمكن أن تعتبر حرفةً أو عملاً أو دورًا أو نشاطًا. يوجد في بعض الشركات مدراء مشاريع، عملهم هو الإشراف على مشاريع يعمل عليها مئتا شخص. بينما يستخدم هذا المنصب في شركات أخرى للدلالة على المدراء المبتدئين من المستوى الأول للإدارة حيث يعتبر كل منهم مسؤولا عن مساحة صغيرة في مشروع كبير. يمكننا بالاعتماد على هيكلية المنظمة وثقافتها وأهداف المشروع أن نصنف إدارة المشاريع كمهمة غير رسمية (يقوم بها أي كان متى دعت الحاجة إليها)، أو أنها تحدد بدقة (سارة وريم ورشا هم مدراء المشاريع بدوام كامل).
سوف أستخدم بشكل أساسي في هذا الكتاب عبارة مدير المشروع للإشارة إلى أي شخص يتدخل في عملية إدارة وقيادة المشروع. أعني بعملية إدارة المشروع: قيادة مجموعة العمل لبيان ما هو المشروع (تخطيط، جدولة عمل وتجميع متطلبات) وإيصال المشروع عبر مراحل التصميم والتطوير (الاتصالات، اتخاذ القرارات واستراتيجيات منتصف اللعبة) وقيادة المشروع نحو الاكتمال (القيادة، إدارة الأزمات وإستراتيجية نهاية اللعبة).
إذا لم تكن هذه الهيكلية في العمل مألوفة في عملك، يمكنك اعتبار مدير المشروع على أنه (الشخص الذي ينفذ مهام إدارة المشروع) ولو لم يكن هذا هو عمله الأساسي أو (الشخص الذي يفكر بالمشروع على أعلى مستوياته). لقد صادفت العديد من الطرق  المختلفة لتوزيع هذه المهام عبر فرق العمل. والنصائح الموجودة في هذا الكتاب ليست متباينة جدًا بالنسبة لهم. إن مضمون هذا الكتاب لا يركز على المناصب والتشكيلات، وإنما يهتم أكثر بكيفية إنجاز المهام وتحقيق الأهداف. ولكن لكي أصوغ كتابتي بأبسط شكل ممكن سأعتمد عبارة مدير المشروع.
في بعض الأحيان يكون عدم تكريس شخص محدد كمدير للمشروع أمرًا جيدًا، حيث يقوم المبرمجون مع رؤسائهم بتحديد الجدولة والخطط الهندسية (إذا وجدت). ويقوم المحلل أو موظف التسويق بعمل المتطلبات أو التخطيط. وأي شيء آخر يعتبر مهمة ضمن إدارة المشروع يمكن توزيعه ببساطة على أعضاء الفريق. قد يخصص بعض أعضاء الفريق بسبب اهتماماتهم التي تتجاوز كتابة الشيفرة. فهم قد لا يمانعون بالقيام بالتخطيط الأولى، أو تصميم الواجهات للمستخدمين، وتحديد إستراتيجية العمل، وقد تكون الأمثلية عظمى عند العمل بهذا الأسلوب. طالما أن الجميع يرغبون بدفع ضريبة المسؤولية عن تجميع الأشياء وتوزيع العبء الذي قد يحمله مدير المشروع على أعضاء الفريق، عندها لن يكون الفريق بحاجة إلى هذا الموظف. إن الفعالية والبساطة هي أمور جيدة.  
لكن قد يخلق غياب مدير المشروع في أحيان أخرى اختلالاً وظيفيًا، فإن عدم وجود شخص عمله الأساسي هو قيادة الجهود الكلية فإن ذلك سيؤدي إلى أن تحرف الميول والاهتمامات الشخصية الفريق عن مساراته المحددة، حيث إنه من الممكن حينها أن تتشكل زمر معارضة قوية في المهام الهندسية والعملية، مما يبطئ التقدم ويخيف أي شخص له علاقة بالمشروع. افترض أنه في غرفة الإسعاف في المستشفى، يتحمل أحد الأطباء مسؤولية اتخاذ قرار بشأن ما يجب القيام به من أجل أحد المرضى. إن هذا يسرع اتخاذ القرارات، ويعطي وضوحًا للمهام التي يجب أن يقوم بها كل عضو من أعضاء مجموعة الكسور والرضوض. إن غياب هذا النوع من المسؤولية الواضحة بالنسبة للأمور المتعلقة بالإدارة، يمكن أن يقود مجموعة العمل إلى المشكلات. إذا لم يكن هناك شخص محدد بوضوح لقيادة عملية ترتيب الأولويات بالنسبة. للأخطاء أو أنه لا يوجد شخص مكرس لتبع الجدولة والمشكلات الصغيرة، فإن هذه المهام قد تتفاقم بشكل خطير بين النشاطات البرمجية الفردية اللامركزية.
اعتقد أن العديد من أفضل المبرمجين يعرفون كفاية عن إدارة المشاريع ليقوموا بهذه المهمة بأنفسهم، إلا أنهم يتفهمون مدى الفائدة الفريدة لوجود شخص جيد مكرس ليلعب دور المدير.
إدارة المشاريع والبرامج في Microsoft 
واجهت شركة Microsoft في نهاية الثمانينات مشكلة تتعلق بكيفية تنسيق الجهود الهندسية مع الجانب التسويقي والعملي في كل قسم (قد يعتقد البعض أن هذه المشكلة مازالت قائمة في Microsoft والعديد من الشركات الأخرى).
استنتج رجل حكيم يدعى Jabe Blumenthal أنه قد يوجد عمل خاص يكون فيه الفرد مسؤولاً عن هاتين المهمتين، حيث يلعب دورًا هامًا في كلتا العمليتين: القيادة والتنسيق. إن هذا الشخص سيهتم بالمشروع اعتبارًا من اليوم الأول في عملية التخطيط وعبر جميع المراحل حتى اليوم الأخير للاختبارات. كما أنه يجب أن يكون شخصًا متمرسًا تقنيًا بما يكفي لكي يعمل مع المبرمجين ويكسب احترامهم، بالإضافة إلى امتلاكه المواهب والاهتمامات من أجل التدخل الأوسع في كيفية صنع المنتجات.
من أجل أن تنجح هذه المهمة، فإن عليه أن يستمتع بقضاء وقته في إنجاز المهام على اختلافها بدءًا من كتابة المواصفات الخاصة بالمشروع، ومراجعة خطط التسويق، وإيجاد جدولة المشروع، وقيادة فرق العمل، وإنجاز التخطيط الاستراتيجي، وإدارة عملية ترتيب الأولويات بالنسبة للعيوب والأخطاء، وصقل معنويات الفريق والقيام بأي شيء آخر يجب القيام به ولم ينفذه أحد «بشكل جيد».
سمي هذا المنصب الجديد في Microsoft مدير المشروع. لم يكن على أعضاء الفريق رفع التقارير إليه مباشرة، ولكنه منح سلطة كبيرة لقيادة المشروع. (وفق نظرية الإدارة، يعبر ذلك تقريبًا عن فكرة المنظمة المصوفية، حيث يوجد تصنيفان لهيكلة التقارير بالنسبة للأفراد: الأول مبني على الوظيفة والآخر على المشروع. وبالتالي يجب على المبرمج أو مختبر الجودة أن يرفع التقارير إلى اتجاهين مختلفين- اتجاه أساسي يتعلق بمهمته الوظيفية، وآخر ثانوي ولكن هام، يتعلق بالمشروع الذي يعمل عليه).
لعب Jabe هذا الدور من أجل منتج سمي Multiplan (الذي تحول لاحقًا إلى Microsoft Excel) ونجح فيه، مما أدى إلى تحسين العملية الهندسية والتطويرية جنبًا إلى جنب وجودة التنسيق مع فريق العمل. وقد عم الابتهاج أنحاء الشركة. وتبنت معظم فرق العمل ضمن الشركة هذه المهمة ببطء بعد العديد من المذكرات والاجتماعات. قل ما تريد عن المنتج النهائي سواء كان جيدًا أم سيئًا، ولكن الفكرة كانت ناجحة. بتحديد مهمة لذلك الشخص اللا اختصاصي على مستوى معين والذي هو عبارة عن قائد وليس تابعًا، تغيرت الديناميكية التي تعمل بها فرق العمل في شركة Microsoft إلى الأبد. إن مهمة مدير البرامج كانت هي في خلال معظم سنوات عملي في شركة Microsoft، وقد عملت مع فرق إنتاجية تضمنت مستكشف الإنترنت MSN، و Windows. وقد قمت أيضًا بإدارة فرق من الأشخاص الذين قاموا بهذه المهمة.
لا أعرف حتى هذا اليوم عن كثير من الشركات التي وصلت إلى هذا المستوى في إعادة تعريف وصياغة شكل متخصص لإدارة المشروع. وكان من النادر أن أصادف في اتصالاتي المتعددة مع شركات التطوير البرمجي وتطوير الوب الأخرى شخصًا يقوم بدور مشابه (لقد كانوا إما مهندسين أو محللي أعمال، أو في حالات نادرة مصممين). يستخدم العديد من الشركات هيكلية فريق العمل من أجل تنظيم الأعمال، إلا أن القليل منها يعرف المهام التي تتجاوز مستويات الهندسة والعمل عن سابق تصميم. في Microsoft الآن أكثر من 5000 مدير برمجي (من أصل 50.000 موظف في الشركة). ورغم أن سيطرة هذه الفكرة قد انخفضت (وفي بعض الحالات لا تستخدم كما يجب) فإن الروح الأساسية لها لا تزال موجودة بين العديد من الفرق ومجموعات العمل ضمن الشركة.
لكن بغض النظر عما هو موجود على بطاقة التعريف بعملي، أو ما تسمح لك شركة Microsoft أن تختار تطبيقه أو تجاهله، فإن وظيفتي اليومية كمدير برامج كانت عبارة عن تطبيق عمليات إدارة المشاريع. إن هذا يعني بأبسط تعبير ممكن أنني كنت مسؤولا عن إنجاح المشروع- وكل من يشارك فيه- إلى أقصى درجة ممكنة.
بالإضافة إلى هذه المهارات فإن السلوك والسمات الشخصية تلعب دورًا هامًا. وبعدم إدراك ذلك سيعاني أي شخص يقود أو يدير مشروعًا من صعوبات جمة.
أعمال الموازنة في إدارة المشاريع
من الصعب إيجاد مدراء مشاريع جيدين، حيث يجب عليهم المحافظة على التوازن في سلوكهم. لقد سمي Tom Peters في مقالته (السعي وراء مدير مشروع كامل السمات) هذه السلوكيات المتضاربة بالمتناقضات أو الأزمات. وهو اسم مناسب لها، لأن الحالات المختلفة تتطلب تصرفات مختلفة، ذلك يعني أنه على مدير المشروع أن يعي هذه الصفات وأن يطور الفطرة أيضًا حتى يعرف متى يستخدم أيًا منها تبعًا للحالة. إن هذا يدعم فكرة اعتبار إدارة المشاريع فنًا، فهي تتطلب الفطرة، والحكم الصحيح والخبرة لاستخدام هذه السمات بشكل فعال. لقد تم اشتقاق قائمة المزايا التالية من مقالة Peters:
• الأنا/ اللاأنا: إن حجم المسؤولية التي يتحملها مدراء المشاريع، تجعلهم يحصلون على الرضا عن النفس في عملهم. من المفهوم أنهم حققوا استثمارًا عاطفيًا كبيرًا في ما يقومون به. وقد كان هذا الرابط الشعوري لدى العديد منهم هو السبب في محافظتهم على القوة المطلوبة ليكونوا فعالين. ولكن في الوقت نفسه، يجب على مدراء المشاريع تجنب تقديم مصالحهم الشخصية على مصلحة المشروع. فعليهم أن يكونوا قادرين على توكيل المهام الهامة والممتعة ومشاركة كامل الفريق بالحوافز والمكافآت. بقدر ما تقدم الأنا طاقة لمدير المشروع، يجب عليه أن يعرف متى تقف هذه الأنانية في طريق المشروع.
• المستبد/ المتواكل: في بعض الحالات، تكون الأمور الأكثر أهمية هي توضيح مقدار السلطات بالإضافة إلى زمن استجابة سريع. وعلى مدير المشروع أن يكون واثقًا من نفسه، ولديه القدرة الكافية للتحكم وإجبار أعضاء الفريق على تنفيذ أعمال محددة. ومن ناحية أخرى فإن الهدف العام يجب أن يكون تجنب  الحاجة إلى هذه الحالات الشديدة. فالمشروع المدار جيدًا يجب أن يخلق بيئة يكون فيها العمل قابلاً للتوكيل أو المشاركة بفعالية.
• تحمل الغموض/ السعي وراء الكمال: إن المراحل الأولية للمشروع تكون عامة، وتتدفق فيها الخبرات حيث ترجح كفة المجهول بشدة على كفة المعلوم. إن التحكم بالغموض هو أمر أساسي من أجل أن تظهر الأفكار الجيدة، وعلى مدير المشروع أن يحترمه، إذا لم نقل أن يديره. ولكن في حالات أخرى، خاصة في المراحل المتقدمة للمشروع يجب أن يسيطر الانضباط والدقة. حيث إن الحكمة مطلوبة لملاحظة وقت الحاجة إلى تحقيق الكمال، وبالمقابل تحديد متى يكون الحل السريع أو المتوسط كافيًا (راجع الفقرة «إيجاد وموازنة الخيارات)).
• شفهي/ كتابي: بغض النظر عن مدى اعتماد منظمات التطوير البرمجي على البريد الإلكتروني، فإن المهارات الشفهية تعتبر بالغة الأهمية في إدارة المشاريع. حيث توجد دائمًا اجتماعات، ومفاوضات ومناقشات جانبية وجلسات عصف دماغ (تحفيز ذهني)، وعلى مدير المشروع أن يتمتع بالكفاءة في مهارتي استيعاب وربط الأفكار وجهًا لوجه. وكلما كانت المنظمة أو المشروع بحجم أكبر، ازدادت أهمية المهارات الكتابية (والقدرة على استعمالها). وبغض النظر عن تفضيلات مدير المشروع، يجب عليه أن يميز ما الحالات التي تكون فيها الاتصالات الكتابية أو الشفهية أكثر فعالية.
• التسليم بوجود التعقيدات/ ترجيح التبسيط: يقع العديد من الأشخاص ضحية للتعقيد. فعندما يواجهون تحديات هندسية أو تنظيمية معقدة يتيهون في التفاصيل، وينسون الموضوع الأساسي. بينما يبقى الآخرون مبتعدين عن التعقيد، فيتخذون قرارات سيئة بسبب أنهم لا يعون تمامًا دقة الأمر. وتكون الموازنة في هذه الحالة بإدراك أي نظرة للمشروع هي الأكثر فائدة إزاء المشكلة أو القرار الحالي، والتنقل بين الآراء بارتياح أو الاحتفاظ بها في الذاكرة في ذات الوقت (دون أن ينفجر دماغك). على مدراء المشاريع أن يكونوا مقنعين في جعل الفريق يكافح من أجل البساطة والوضوح في العمل، دون التقليل من التعقيدات الموجودة في كتابة شيفرة جيدة وموثوقة.
• غير صبور/ صبور: في غالب الأحيان يكون مدير المشروع هو الشخص الذي يدفع الآخرين للقيام بعملهم ويجبرهم على جعل العمل موجزًا ومركزًا. ولكن فقدان الصبر أحيانًا يكون ضد مصلحة المشروع. إن بعض النشاطات السياسية أو التابعة للمنظمة أو البيروقراطية تمثل استهلاكًا للوقت لا يمكن تجنبه، مثلاً يجب أن يكون أحد الأشخاص موجودًا في الغرفة، أو أن يكون هذا الشخص مسؤولاً عن المؤتمر الهاتفي الذي يقدم تقريرًا عن استثمارات المشروع، وعليهم أن يكونوا صبورين. وبالتالي فإن معرفة توقيت فرض أمر ما، أو التراجع لجعل الأمور تتحقق هي عبارة عن حس يجب على مدراء المشاريع تطويره.
• الشجاعة/ الخوف: إن إحدى أهم التسميات الخاطئة في الثقافة الأمريكية هي اعتبار الشجعان هم الأشخاص الذين لا يشعرون بالخوف. إنها كذبة، فالشجعان هم أولئك الذين يشعرون بالخوف، ولكن يختارون التصرف بكل الأحوال. يجب أن يكون لدى مدير المشروع احترام صحيح لكل الأشياء التي قد تكون خاطئة، وأن ينظر إليها على أنها ممكنة كليًا. ولكن على مدير المشروع أن يربط هذا الاحترام بالشجاعة اللازمة للإقدام على التحديات الكبرى.
• مؤمن/ مرتاب: ليس هناك من دفع معنوي أعظم للفريق من وجود قائد محترم يؤمن بما يفعله. فمن المهم لمدير المشروع أن يثق بالعمل المنجز، وأن يقدر الأهداف التي ستتحقق، ولكن في الوقت نفسه هناك حاجة إلى الشكوك (لا التطرف) تجاه كيفية حدوث الأشياء والطرق التي تتم بها. على أحدهم أن يبحث ويسأل، وأن يقدم الافتراضات، ويبين الأمور الصعبة. وتكون الموازنة بأن تطرح أسئلة بقوة نوعًا ما وتواجه الافتراضات المقدمة من قبل الآخرين، دون أن يهتز إيمان الفريق بما يفعله.
يشير Peters في مقالته أنه من النادر جدًا أن تجد أشخاصًا يتمتعون بكل هذه المهارات، أو أنهم غير قادرين على تحقيق التوازن فيما بينها بالشكل المناسب. يتضمن الكثير من الأخطاء التي يقع فيها أي مدير مشروع حسابات خاطئة في موازنة واحدة أو أكثر من هذه الإمكانيات المتناقضة. من جهة أخرى، يستطيع أي شخص أن يحسن من إدراكه وفهمه، ومن ثم تطويره لقدرته الخاصة على الحفاظ على توازن هذه القوى، وبالتالي، رغم أنني لن أمنح هذه القائمة من المتناقضات تركيزًا هامًا (رغم أنها ستظهر فيما يلي عددًا من المرات) فإنها تعتبر مرجعًا يستحق الذكر. إن تأمل هذه القائمة من القوى المتناقضة والضرورية في نفس الوقت قد يساعدك على إعادة حساباتك فيما تقوم به وأسبابه، وكذلك يساعدك على اتخاذ قرارات أكثر ذكاء.
 الضغط النفسي والتشتيت
إن أحد مخاوف أولئك الجدد على عملية إدارة المشاريع هو أن النجاح يتطلب التغيير. حيث تنشأ المشاريع الجديدة بنية تغيير حالة العالم بالتعديل أو البناء أو بتحطيم شيء ما. إن المحافظة على الوضع الحالي -إلا إذا كان هذا هو الهدف الصريح للمشروع، لسبب ما غريب -لا يعتبر ناتجًا ناجحًا. فالعالم يتغير باستمرار. وإذا لم يكن موقع الوب أو أي مشروع اليوم بالجودة التي كان عليها في العام الماضي، فإن هذا يعني عمومًا أنه فشل، لأن الأهداف لم تكن مناسبة أو أن تنفيذ المشروع فشل بشكل ما.
من الصعب تجاهل الضغط الذي يسببه هذا لمدراء المشاريع، ولكنه نتيجة متوقعة. لا تكتفي بتأمل الوضع، حاول أن تجعله أفضل. هناك دائمًا طريقة جديدة للتفكير أو موضوع جديد يمكن تعلمه وتطبيقه، أو عملية جديدة تجعل العمل أكثر متعة وأكثر فعالية. ربما يعتبر ما سبق مسؤوليات أشبه بالقيادة منها بالإدارة. ولكن التمييز بين الأمرين ثابت. ومهما فعلت لتفصل بينهما، فإن الإدارة الناجحة تتطلب مهارات قيادة، كما تتطلب القيادة الجيدة مهارات إدارية. إن أي شخص يتدخل في إدارة المشروع سيكون مسؤولا عن جزء من كليهما، بغض النظر عما يتضمنه توصيف عمله.
بالعودة إلى موضوع الضغط النفسي، فقد رأيت العديد من مدراء المشاريع الذين يخجلون من الحالات القيادية (مثلاً أي حالة يكون فيها الفريق/ المشروع بحاجة أن يتخذ أحدهم قرارًا حاسمًا) ويتوقفون عن متابعة جهود الآخرين بدلاً من تسليمها أو المشاركة بها. إذا كان كل ما يقوم به هذا الشخص هو الاحتفاظ بالنتائج والمراقبة من بعيد، فإنه سيكون مناسبًا لقسم المحاسبة. وإذا كان الشخص الذي يتولى مهمة قيادية سيستجيب دائمًا للضغط النفسي بالهروب، فهو لا يقود، وإنما يختبئ. ومدراء المشاريع الذين يتأثرون سلبًا بالضغط النفسي يميلون لأن يؤثروا في نواحٍ ثانوية للمشروع، فهم لا يضيفون إلا القليل.
خلط العمليات بالأهداف
يلجأ بعض مدراء المشاريع في هذه الحالة إلى تقدير الأشياء التي ليست بحاجة إلى ذلك. إما بسبب كونهم غير واثقين بالقيام بأمر آخر، أو أنهم خائفون من تنفيذ أغلب ما يجب إنجازه، فهم يشغلون أوقاتهم بأمور ثانوية. وكلما اتسعت الفجوة بين المشروع ومديره، يزداد مقدار الاهتمام غير الضروري بالمخططات البيانية والجداول ولوائح التدقيق والتقارير. ومن الممكن أن يبدأ مدير المشروع في مرحلة ما بالاعتقاد أن البيانات والعمليات هي التي تشكل المشروع، فيركزون على الأمور الأقل أهمية والأسهل للعمل (التقارير وأوراق العمل) بدلاً من الأشياء الهامة التي تشكل تحديًا لإنجازها (الجهود البرمجية أو الجدولة). إنهم قد يعتقدون أنه يكفي إتباع إجراء محدد باتجاه الكمال واختبار الأشياء الصحيحة في لوائح التدقيق، عندها يكون نجاح المشروع مضمونًا (أو بنظرة أكثر تطرفًا، إن أي فشل قد يحدث لا تقع لائمته عليهم تقنيًا).
ومن أجل تقليل احتمالية الارتباك، يبتعد مدراء المشاريع الماهرون عن تعريف حدود صارمة لأنواع الأعمال التي ينوون القيام بها أو تجاهلها. فهم يتجنبون الخطوط الصفراء اللامعة بين مهام إدارة المشروع والمشروع نفسه. إن الالتزام بلوائح تدقيق معينة يفترض أن هناك عمليات محددة تضمن نتائج محددة، ولكن الأمر ليس كذلك. في الواقع هناك دائمًا ثلاثة أشياء فقط: هدف، وكومة من العمل ومجموعة من الأشخاص. إن المهام المحددة جيدًا قد تساعد أولئك الأشخاص على تنظيم العمل، ولكن صياغة المهام ليست هي الهدف. وكذلك فقد تساعد لوائح التدقيق هؤلاء الناس على القيام بالعمل بطريقة تؤدي إلى تحقيق الهدف، ولكن هذه اللوائح لا تشكل الهدف أيضًا. إن أحد الأخطاء الكبرى في الإدارة هو خلط العمليات مع الأهداف. على الاعتراف: لقد وقعت أنا بهذا.
منذ سنوات مضت، عندما كنت أعمل في مشروع متصفح الانترنت، وكنت مسؤولا عن إدارة المشروع لمساحات كبيرة من واجهات المستخدم. وأحسست وقتها بضغط نفسي هائل، فقد كانت أكبر مهمة أوكلت إلي في حينها. وكردة فعل على ذلك آمنت بشدة أنني إذا دونت كل شيء في لوائح تدقيق فإنني لن أفشل أبدًا، بينما كان علي متابعة أمور المشروع بحرص إلا أنني ذهبت أبعد من ذلك بكثير. لقد صممت ورقة عمل تفصيلية لأعرض مناظر البيانات المتعددة، وقد امتلأت الألواح البيضاء في مكتبي بالجداول والقوائم (بالإضافة إلى المزيد منها التي كانت في طريقها إلي).
وقد سمح لي رئيسي بالاستمرار في ذلك، لأن الأمور كانت تسير جيدًا، وقد استمر ذلك، إلى أن رآني أقضي وقتًا مع لوائح التدقيق والعمليات أكثر من الوقت الذي أمضيه مع الفريق -فارتفعت راية حمراء حينها (إشارة تحذير). لقد دخل مكتبي ذات مرة، وعندما رأى مجموعة كبيرة من لوائح التدقيق والجداول التي كتبتها بشكل مضحك على كل سطح مستو في مكتبي. طلب مني الجلوس، وإغلاق الباب، وقال: «إن هذه الأشياء جيدة، ولكن مشروعك هو فريقك. قم بإدارة الفريق، لا لوائح التدقيق. فإذا كانت تساعدك على إدارة الفريق فهذا رائع، ولكن بالطريقة التي تتبعها، ستصل إلى مرحلة تستخدم فيها الفريق ليساعدك على إدارة تلك اللوائح».
بالتالي يجب على مدراء المشاريع التركيز على فرق عملهم بدلاً من التركيز على العمليات والطرق. وبالتأكيد سيكون هناك حاجة لاستخدام أنظمة تخطيط وتتبع بسيطة، لكنها يجب أن تتناسب مع مدى تعقيد المشروع ومع ثقافة فريق العمل، وبتعبير أدق، يجب أن يدعم التخطيط والتتبع لأعضاء الفريق في تحقيق أهداف المشروع- لا أن يثبطهم. إنني على أتم الثقة أنه طالما اهتم مدير المشروع أكثر وتمكن من كسب ثقة فريقه، فإن أي مهام ناقصة، أو عمليات أو تقارير أو لوائح تدقيق أو أي آليات أخرى لازمة لإدارة المشروع ستكون واضحة قبل أن تصبح المشكلات التي قد تساعد هذه الأدوات في حلها جدية.
سنناقش في الفصل العاشر فكرة أنه لا يكفي أن يصدر كتاب أو حكم من قبل أحد التنفيذيين للقيام بأمر ما، أو أن توظف تقنية ما في العام أو الشهر الماضي لتطبيقها اليوم. فكل مشروع وكل فريق يختلف عن الآخر، وهناك دائمًا أسباب منطقية للبحث في الأحكام القديمة. إن السبب في التحفظ على الطرق والعمليات هو أن الأنواع غير الضرورية منها تميل لأن تنمو باستمرار مما يقود فريق العمل إلى الهاوية في المشاريع الصعبة، كما جاء الوصف في كتاب (The Mythical Man-Month :Fred Brooks) عندما تلزم العمليات لإدارة العمليات يكون من الصعب أن تعرف فيما إذا تم إنجاز العمل الفعلي. عادة لدى قائد الفريق أو مدير المشروع القدرة العظمى على إبعاد الفريق عن البيروقراطية، أو بنظرة أكثر فلسفية، عن الوقوع في دوائر لا منتهية من الإجراءات وأسلوب التفكير المتحكم به من قبل مجموعة محددة.
التدخل الصحيح
إن جميع المدراء - اعتبارًا من المدراء التنفيذين على مستوى التصنيف الأمريكي لأفضل 500 منظمة ربحية حتى مدربي الفرق الرياضية- معرضون لإقحام أنفسهم بشكل مبالغ به. على ما أظن أنهم يعلمون إلى حد ما أنهم يعتبرون من ضمن مصاريف المشروع الإضافية الكامنة، والتدخل الإجباري يعتبر طريقة مناسبة (رغم سلبيتها) للمحاولة لتعويض ذلك. إن هذا يفسر جزئيًا التوارد غير المنتهي للمدراء الصغار. إن أسهل ما يقوم به المدير الضيف هو أن يسيء استخدام نفوذه تجاه أعضاء فريقه (وفي الحالات الشديدة، يضيفون إلى ذلك إلقاء اللوم عليهم كونهم لم يكونوا مؤهلين بما يلزم حيث إنهم كانوا بحاجة إلى ذلك الاهتمام). إن المدراء الضعفاء جدًا يعودون إلى حقيقة أنه وفق مصطلحات الثورة الصناعية فإن المدراء لا مكان لهم في خط الإنتاج، فهم لا يصنعون أي شيء بيديهم، كما أنهم ليسوا من تصنيف أولئك الذين يقومون بذلك.
حيث إن توظيف المدير ليس من أجل زيادة الإنتاج لمعمل أو تسويق برمجي ما كما هو متوقع من العامل أو المبرمج، وإنما تم توظيف المدراء والقادة لزيادة فعالية كل من حولهم، والطرق المتبعة لإضافة هذا النوع من القيم تختلف عن العمل على خط الإنتاج. ولكن بسبب كون العديد من المدراء مبرمجين سابقين تمت ترقيتهم إلى الإدارة بعد عملهم في خط الإنتاج، فالاحتمالات أن لديهم مهارات وثقة أكبر في موضوع كتابة الشيفرة مما لديهم في قيادة وإدارة الأشخاص الذين يكتبون الشيفرة.
إن وجود المدير يفترض المساهمة بشيء ما مختلف في طبيعته عن مجرد إضافة مساهم فردي آخر. تمامًا مثل المدرب في لعبة كرة القاعدة (البيسبول)، أحيانًا يكون هذا بحسم المجادلات أو حماية الفريق من السياسات، وأحيانًا أخرى بتزويد خطط جيدة عالية المستوى أو بإيجاد حلول مؤقتة للحالات غير المتوقعة. باعتبار أن هذه المساهمات صعبة التحديد، فإن العديد من مدراء المشاريع يعانون بسبب غموض مهامهم، فمن السهل استهدافهم لإلقاء اللوم عليهم، بالإضافة إلى كونهم لا يستطيعون الاختباء. لكي تكون فعالاً وسعيدًا كقائد لفريق عمل عليك أن تمزج أسلوب الإقناع مع الثقة والتركيز. 
الاستفادة من آراءك
إن أفضل طريقة لإيجاد نقاط الدعم هي استغلال الاختلاف في الحالات النفسية الذي يتم اكتسابه من طبيعة العمل خارج خط الإنتاج. إن مدير المشروع، تبعًا لمهامه، يقضي بشكل طبيعي وقتًأ طويلاً مع أشخاص مختلفين في فريقه أكثر مما يفعل أي شخص آخر، وبالتالي فهو يكتسب المزيد من موارد المعلومات، وكذلك وجهات نظر أوسع عن المشروع. عندها سيستوعب مدير المشروع الرؤية العملية لهذا المشروع بالإضافة إلى الرؤية التقنية وسيساعد الفريق على الترجمة بين هذين الاتجاهين عند الضرورة. إن وجهة النظر العريضة تلك تسهل توصيل أجزاء صغيرة بالغة الأهمية والحساسية من المعلومات إلى الأشخاص المناسبين في الوقت المناسب. وبالتالي فإن هذه السلطة يمكن أن تمتد آثارها على مجال عريض. فما يلي قصة بسيطة قد تساعد على توضيح هذه النقطة على نحو أوسع.
أقوم دائمًا بحكم العادة بالتجول بين المكاتب والدخول إلى غرف المبرمجين الذين تركوا بابهم مفتوحًا، وأجري معهم عادةً حديثًا قصيرًا، محاولاً أن أجعلهم يضحكون. وأطلب منهم أن يعرضوا علي ما كانوا يفعلونه، وكنت أشاهد نسخة تجريبية من أي شيء يقدمونه لي. إن القيام بهذا خلال فترات متقاربة، ولو لبضعة دقائق، كان يعطيني دائمًا فكرة جيدة عن الحالة الحقيقية للمشروع.
على سبيل المثال، ذات صباح أثناء العمل في مشروع متصفح الإنترنت. مررت بمكتب فريد الذي كان يتناقش مع ستيف وهو مبرمج آخر، بشأن كيف يمكنهم جعل إحدى الأدوات البرمجية التي تعرض قائمة من البنود تعمل بالشكل المناسب -وهو موضوع توافقية غير متوقع تم اكتشافه في صباح ذلك اليوم. لم يرغب أي منهما بالقيام بالعمل، وقد عرفت مما سمعته أن الأمر يستغرق عمل نصف يوم أو أكثر لحل المشكلة. عندها قمت بحشر أنفي والتأكيد على ما قالاه، وقد هز كل منهما رأسه وكأنه يقول «لم تهتم؟» سألتهما حينها أن يذهبا إلى مكتب بيل، فتساءلا مجددًا لم؟ معتقدين أن الأمر عبارة عن موضوع اختصاصي لا يمكنني فهمه بسهولة. فابتسمت وقلت «لأنني غادرت مكتبه للتو، ولديه عنصر الشجرة الجديدة، ويعمل جيدًا في حاسبه. لقد تمكن من حل المشكلة في الليلة الماضية وإصلاح الأزمة كجزء من عمل آخر».
بالطبع، ومن هذه القصة الصغيرة، فإنني لم أنقذ العالم أو أتفادى أزمة هائلة، ولكني لو لم أجر هذا التواصل بينهم ستكون النتيجة ضياع بعض الساعات أو نصف يوم من العمل (رغم حقيقة أن الجدولة تتعرض عادةً للإزاحة الزمنية، كما سنناقش ذلك في الفصل 8)، ولكن العبرة ليست هنا. فالمدراء الجيدون يجعلون شغلهم الشاغل هو معرفة كل أنواع الأمور المفيدة عن حالة الفريق -وحالة العالم- وبعدها تطبيق تلك المعرفة لمساعدة الأشخاص على إنجاز الأشياء. إنها فقط تلك الكتل الصغيرة من المعلومات المنقولة في الوقت المناسب، مثل تلك التي في القصة، هي التي تجعل الفرق المتوسطة جيدة، والفرق الجيدة رائعة. إن أي نظام تتبع للأخطاء أو المشروع لن يحل بشكل كامل مكان الحاجة إلى تواصل الأشخاص بعضهم مع بعض بشأن ما يجري، لأن العلاقات الاجتماعية تكون دائمًا أقوى، وأحيانًا أسرع من العلاقات والاتصالات التقنية. والتحديات الكبرى مثل الرؤية الخاصة بالمشروع، وقوائم الموازنة، والجدولة تأتي دائمًا أدنى مرتبة من كثير من التحديات التي تتأثر إيجابيًا بمدى سهولة المعرفة الجيدة وتدفق المعلومات عبر الفريق. ويلعب مدراء المشاريع دورًا بالغ الحرج في جعل هذا التدفق صحيًا وفعالاً.
لكن سواء كانت المشكلات كبيرة أم صغيرة، فإن القرارات والأفعال التي يتخذها المدراء يجب أن تكون تمامًا في مصلحة الفريق بأكمله. من المحتمل أن يستغرق الأمر أسبوعًا أو شهرًا ليصبح واضحًا، ولكن مدير المشروع الناجح يؤثر أثرًا إيجابيًا على نوعية العمل المنتج وغالبًا على نوعية الحياة التي يعيشها كل من له علاقة بالمشروع. وعندها سيشعر الأشخاص بشكل مختلف تجاه عملهم وسيقولون على الملأ إنهم يتفهمون أكثر ما يقومون به وأسبابه ويشعرون بالارتياح لما سيلي أكثر من ذي قبل. إن هذا النوع من التغيير يحدث فقط في اجتماع أو بسبب اتخاذ قرار ما أو مناقشة موضوع ما في كل مرة، ولكن في فترة المشروع كاملاً يمكن لهذا الأثر المعنوي أن يؤدي إلى دفع معنوي وتطوير بالغ الأثر.
مدراء المشاريع يوجدون قيمًا فريدة
كنتيجة لما سبق، سوف يكسب مدراء المشاريع الناجحون نوعًا خاصًا من الاحترام من قبل المبرمجين والمسؤولين عن اختبار المنتج والمصممين والمسوقين والمسؤولين عن التوثيق الذين هم على اتصال بهم. وعلى مدير المشروع أن يكون قادرًا على اتخاذ خطوات جريئة في التفكير والتخطيط الاستراتيجي والقيادة، مما يؤثر إيجابيًا على الفريق وقليل من الأشخاص قادر على هذا. من هذا أن يتمكن من إيجاد اختصارات وتفصيلات ذكية في تدفق العمل اليومي، أو إعطاء دفعات من الحماس والتشجيع بالطريقة المناسبة وفي الوقت المناسب. والقيام بذلك لا يتطلب منهم أن يكونوا خارقين أو على درجة عالية من الذكاء (كما اكتشفت ومن دون شك). عليهم فقط أن يعوا فائدة آرائهم وأن يختاروا استغلالها.
هناك حقيقة واحدة بسيطة غير قابلة للجدل هي أن مدراء أو قادة المشاريع يقضون فترة الوقت مع كل فرد من أفراد الفريق أكثر مما يفعل أي شخص آخر. فهم موجودون في عدد أكبر من الاجتماعات، ويمرون على المكاتب ويتحدثون أكثر مع أي شخص مساهم في المشروع أكثر مما يفعل أي شخص آخر. كما أنهم يتخذون قرارات أو يؤثرون على قرارات المشروع أكثر مما يفعل أي شخص آخر في المنظمة. وإذا كان مدير المشروع سعيدًا أو حزينًا أو متحمسًا أو مكتئبًا، فإن جزءًا من هذه المشاعر سينتقل إلى كل من يصادفه في ذلك اليوم، فكل ما يؤثر به المدير على المشروع، جيدًا كان أم سيئًا سينتقل بالعدوى إلى باقي أعضاء الفريق. وبالتالي إذا كان مدير المشروع مركزًا في عمله وملتزمًا به ومتحمسًا له وقادرًا على إنجاحه، فإن احتمالات أن يتصرف الآخرون بالشكل نفسه ستصبح أعلى. إن المدراء من أي نوع لديهم طاقات كامنة مشابهة، وهناك نقاط دعم قليلة لمثل هذه القيم في أغلب بيئات العمل. إن هذا يعني أنه إذا كان من الممكن صقل السلوكيات والأفكار التي ناقشناها حتى الآن، فلن يكون هناك مكان أفضل لإجراء مثل هذه الاستثمارات من المدراء والقادة. ولكن ذلك لا يعني أنه على مدير المشروع أن يتحلى بشخصية البطل الآسرة، أو أن يكون استسلامه صعبًا، أو أن يتمكن من قيادة جيش من المبرمجين إلى المعركة  بدلاً من كل ذلك عليه فقط أن يهتم جيدًا بمساعدة أعضاء فريقه وأن يكون قادرًا على النجاح في هذا الأمر غالبًا.
في النهاية، إن الفكرة الأساسية التي أؤمن بها، هي أنه طالما لا يتعرض أي شخص للأذى (ربما عدا المنافسين) وأنك تتعامل مع الأشخاص بالشكل المناسب، فلا شيء أهم من إنتاج الأشياء الجيدة. كما أنه ليس مهمًا كم الأفكار التي تصدرها أنت أو أي شخص آخر، طالما أن النتائج إيجابية. فإدارة المشروع هي أن تستخدم وسائل ضرورية لازمة لزيادة احتمالات وسرعة النتائج الإيجابية. من أجل ذلك فقد اعتدت استخدام تعويذة يومية مفيدة هي (اجعل الأمور الجيدة تحدث). كان الموظفون يرونني في الممرات أو أثناء مناقشتي للمبرمجين على الألواح البيضاء فيسألونني «ماذا تفعل؟» فابتسم وأجيب «اجعل الأمور الجيدة تحدث». لقد أصبحت جزءًا مسيطرًا على أسلوبي اليومي. وأثناء إدارتي للفريق كان هذا السلوك يتوسع وينتقل عبر أفراد الفريق. أتمنى أن يكبر إحساسك بقيمة هذا السلوك والأفكار الأساسية لهذا الفصل الأولي، كلما انتقلت إلى فصول أكثر تخصصًا بالموضوع في هذا الكتاب.
خلاصة
ينتهي كل مقال بخلاصة قصيرة عن النقاط الأساسية لتساعدك على مراجعته فيما بعد: 

• إن إدارة المشاريع موجودة في كل مكان، ومنذ زمن طويل.
• إذا حافظت على عقلية المبتدئ ستحصل على المزيد من الفرص للتعلم.
• إن إدارة المشروع يمكن أن تكون عملاً أو مهمة أو نشاطًا (ينصح هذا الكتاب ألا تهتم بتعريفها).
• إن إدارة المشروع هي مهمة إدارة مشروع معرفة بشكل جيد من قبل شركة Microsoft ومشتقة من فكرة المنظمة المصفوفية.
• إن القيادة والإدارة تتطلب تفهمًا وفطرة تجاه العديد من المتناقضات العامة. بما فيها الأنا/ اللاأنا والاستبداد/ التوكل والشجاعة/ الخوف.
• تحرز في أدائك لمهمة الإدارة من التدخل الزائد والادعاءات، فالعمل يجب أن يدعم الفريق، لا الجهات الأخرى.
• إذا كنت مديرًا مخصصًا لعمل الإدارة، ابحث عن طرق لتحسين آرائك الفريدة عن الفريق والمشروع.

المرجع
كتاب : فن إدارة المشروعات، تأليف : سكوت بيركان، ترجمة حلا قش قش، دار شعاع للطباعة والنشر والتوزيع. من ص 7 إلى 28