As organizations grow, senior leadership inevitably asks for more aggregated reporting; there is too much going on for them to know all the details. A popular version of this reporting is the stoplight: red, yellow, green. But when you reduce complex efforts into a single color, there can be a shocking loss of fidelity.
A member of my team recently introduced me to a new concept: the “Watermelon Project.” These are projects on your dashboard that are green on the outside while being red on the inside. (Some online definitions call them “red and bleeding” on the inside, for what it’s worth.) He didn’t invent the term, but I found the concept fascinating, and it resonated with my experiences. Let us examine why the phenomenon exists at all, and then some examples of types of watermelons.
Boiling it down to a color. At a certain organizational size, senior leadership stops being able to remain in touch with all the details of the projects that are in-flight. While they are capable and interested in a deep dive, they don’t have the bandwidth to do it for every project, so they look for quick indicators as to where to best spend their time. A long time ago, someone cleverly decided to use the stoplight approach, calling projects red, yellow or green. Calling a project red eventually became an invitation for an executive to dig into a project, causing the leadership of the project a lot of unwanted attention.
Because of this reality, few product owners or project managers want to declare that their project is red, even if it truly is on fire. I can tell you that as a manager of project managers, I would explicitly tell them that if the first time I found out that project was red was on some kind of dashboard or executive report they would be looking for a new job the following morning. While there is nothing wrong with highlighting that your project is in trouble, doing so by inviting executive scrutiny as a first step feels like poor project and stakeholder management.
This has caused many a project manager to look for any excuse to call their project green, or at worst, yellow (these are called grapefruits, and are a topic for a different article.) This way, the project can blissfully careen off a cliff, with no interference or extra work needed. The team is either hopeful that the project will right itself again before anyone finds out, or it won’t and no one will notice. So they encase their red project in a shell of green, and hold their breath. In other words, they turn their projects into watermelons.
TYPES OF WATERMELONS
There are lots of ways that a project manager can make a project look like it is going well, even if it isn’t. Some of these involve lying and deception, but those tend to be easy to catch (and the correction path is pretty well known.) What is harder to catch is when what the teams knows and what is being outwardly reported are close to each other, unless you look hard enough, or to extend the metaphor, cut open the project and look inside. And one of the more difficult ones to catch is when the project itself is humming along, but the final product won’t fulfill the actual need.
Changes in scope, changes in value. Changing the scope of a project happens all the time, and is completely natural. Schedules can change, features can be cut or added, and developers can be added or taken away. Projects can go through dozens of re-scoping exercises for each release, leaving the final product something barely recognizable from the original intent. In itself, this isn’t a problem. As we learn more about the customer and the problem, pivoting on what the project will deliver is often a good thing. New features and requirements that come during the middle and end phases of a product can sometimes add significant value. But it’s possible and easy to do the opposite.
As projects move along, the final delivery triangulates across the three levers that project teams have to play with: features, cost and time. Most organizations have little appetite for increasing the cost of a project, and they have some tolerance, but not a lot, for slipping a schedule. Many project managers that I know have an “on-time and on-budget” metric that they must hit as part of their performance review. What they are unlikely to have is a “must hit feature list” measurement.
As a project schedule seems less and less likely to represent reality, a good project manager will start calling out schedule risk, and perhaps even turning the project itself yellow. A very easy reaction to this is to cut functionality from the final product, reducing the amount of time it will take to develop, thereby getting it back on schedule. Hooray, the project is back to green. The first couple of times this happens, the team is likely to cut features that aren’t critical to the business case. Sometimes doing this even gets them back to truly green. Other times, the team starts cutting functionality that is actually vital to the product, or they put it in a nebulous “Phase Two” that is unlikely to get funded anyway.
This may mean that the team is reporting that they are on time and on budget, or near enough as to make no difference, but what they are delivering will fail in the market due to lack of features. Everything being measured on the project such as cost, burndown charts, effort, schedule, are all showing as being okay. But the value of the deliverable is suffering, causing the project to be green on the outside, and red on the inside.
Everybody knows this is going nowhere. Project managers love to measure things. They will measure velocity, bug counts, tickets or tasks completed, percentage to goal, and a whole bunch of seemingly very useful KPIs for project success. One of the more maddening traits of a project manager is one who has the habit of showing progress by declaring something 74% complete this week, and 76% next week. One of my favorite aspects of Agile is getting rid of this kind of language entirely; something s either done, or it is not. This kind of measurement helps prevent a different kind of watermelon, the one where there seems to be a lot of progress, but nothing is getting done.
Being 80% done with ten tasks is not the same as being 100% done with eight of them. Even though both project managers can legitimately call themselves 80% complete, the true story paints a much different picture. And in truth, the team knows the full story. No matter how the project is being managed, there is always a way to mark something “complete.” It could be a checkbox in MS-Project, it could be moving a sticky note on a task board, or it can be as simply as crossing something out on a to-do list. Completing things builds momentum, and the team will know if the project has any.
The project team will know this is going on, and this will only exacerbate the problem. Developers will see the project manager reporting that the project is moving along and is 80% complete, but no one on the team will believe it. The people who live in the project every day know that there is a lot of activity and a lot of parts moving around, but if nothing is getting finished, they will start to slow down. These are the types of projects that linger for years in a mostly complete state, but they start to lose team members, and stall out. All the metrics about completion and progress are green, but the project is definitely red.
It’ll never work. Decisions are made early on in projects that affect the health of the project for its entire life, and sometimes beyond. These decisions are usually made by very smart people, using all available knowledge at the time, and at that singular moment, are the correct decisions. A project can have several of these decisions that lay the foundation for how the entire effort will unravel going forward. And sometimes, one of these decisions turns out to be fundamentally wrong.
Based on what was known at the time and based on and imperfect understanding of the future, the project team put together a design for how the product would work at the most basic level. Most projects have smart people doing the design, and what they come up with usually does meet the needs of the product, project or organization. However, things change, and sometimes those changes invalidate the decisions made early on. Rarely does a project team have the luxury of going back in time and making a different decision; they are either told or decide to just plow ahead.
This case is even harder to surface; even digging into the project is unlikely to show a problem. Most of the team doesn’t even know about the impending doom facing the project. They are moving along on their tasks and making good progress. Tasks are getting completed and iterations are getting demonstrated. What they don’t know is hidden; perhaps the final outcome won’t scale to the needed amount of users, or maybe the security system is all wrong, or any number of the foundational elements are just slightly off. They can even look right when done on a small scale or in development, but they won’t ever handle being in a production environment.
Someone on the team knows this, or is at least worried about it. There is even a chance that person is calling it out and raising it as a risk. But there is no evidence yet; the project hasn’t hit the problem. So they either keep their mouth shut, or they are told to do so. But the fact remains, progress is being made and items are being marked as finished, but there is little hope that the final product will ever launch.
A timeless fruit. Wikipedia tells me that watermelons date back into antiquity, and claims that watermelon seeds have even been found in King Tut’s tomb. That sounds right to me, as the problems that projects face are also not new developments. Wikipedia also informs me that there are 1200 different varieties of watermelons in the world, and I might agree that there are that many flavors of problems that projects can face. In this article we only had space to explore three of them, but these three are the ones that you will face most often.
The first situation is one where the project itself is running just fine, but what it is delivering has little to no chance of hitting the business goals. This comes from project re-scoping and recalibration to hit project KPIs in a way that harms the commercial viability of the product.
The second is where the project looks as if activity is happening and progress being made, but nothing is being completed. If you were to ask anyone on the project, they would profess to be very busy, and they can show you the tasks that they are working on. They might even be able to give you a date they intend to be complete. It would take a much deeper look to guess that their completion date is wishful thinking.
The final one we discussed is even more difficult to see. The project is reporting green, tasks are being fully completed, tested and demonstrated, and the momentum of the team is good. But there is a fatal flaw that few of them see yet, and it’s bad enough to sink the effort entirely.
Watermelon projects come in many flavors, but the end result is still the same. From the outside, or even holding it in your hands, you would call it green. But once you start digging into it, you find that it’s red and bleeding. It is worth the effort to examine all the projects in your portfolio from time to time, including the green ones. Especially the green ones.
Bart has been in ecommerce for over 20 years, and can't imagine a better job to have. He is interested in all things agile, or anything new to learn.
https://www.projectmanagement.com/articles/283162/watermelon-projects
مع نمو المنظمات ، تطلب القيادة العليا حتماً المزيد من التقارير المجمعة ؛ هناك الكثير مما يجري بالنسبة لهم لمعرفة كل التفاصيل. نسخة شائعة من هذا التقرير هي إشارة التوقف: أحمر ، أصفر ، أخضر. ولكن عندما تقوم بتقليل الجهود المعقدة إلى لون واحد ، فقد يكون هناك خسارة مروعة في الدقة.
قدم لي أحد أعضاء فريقي مؤخرًا مفهومًا جديدًا: "مشروع البطيخ". تظهر هذه المشاريع على لوحة القيادة باللون الأخضر من الخارج بينما تكون حمراء من الداخل. (بعض التعريفات على الإنترنت تسميها "حمراء ونزيف" من الداخل ، لما تستحقه.) لم يخترع المصطلح ، لكنني وجدت المفهوم رائعًا ، وكان له صدى في تجاربي. دعونا نفحص سبب وجود هذه الظاهرة على الإطلاق ، ثم بعض الأمثلة على أنواع البطيخ.
غليها إلى لون
في حجم تنظيمي معين ، تتوقف القيادة العليا عن كونها قادرة على البقاء على اتصال بجميع تفاصيل المشاريع الموجودة على متن الطائرة. في حين أنهم قادرون ومهتمون بالغطس العميق ، إلا أنهم لا يمتلكون النطاق الترددي للقيام بذلك لكل مشروع ، لذلك يبحثون عن مؤشرات سريعة حول أفضل مكان يقضون فيه وقتهم. منذ زمن بعيد ، قرر شخص ما بذكاء استخدام نهج التوقف ، واصفًا المشروعات باللون الأحمر أو الأصفر أو الأخضر. أصبح استدعاء المشروع باللون الأحمر في النهاية دعوة للمدير التنفيذي للبحث في المشروع ، مما تسبب في الكثير من الاهتمام غير المرغوب فيه لقيادة المشروع.
بسبب هذا الواقع ، يرغب عدد قليل من مالكي المنتجات أو مديري المشاريع في إعلان أن مشروعهم باللون الأحمر ، حتى لو كان مشتعلًا بالفعل. يمكنني أن أخبرك أنه بصفتي مديرًا لمديري المشاريع ، سأخبرهم صراحة أنه إذا اكتشفت أن المشروع باللون الأحمر لأول مرة كان على نوع من لوحة القيادة أو التقرير التنفيذي ، فسيبحثون عن وظيفة جديدة في صباح اليوم التالي. في حين أنه لا يوجد خطأ في إبراز أن مشروعك في مأزق ، فإن القيام بذلك عن طريق دعوة التدقيق التنفيذي كخطوة أولى يبدو وكأنه إدارة سيئة للمشروع وأصحاب المصلحة.
وقد تسبب هذا في قيام العديد من مديري المشروع بالبحث عن أي عذر لتسمية مشروعهم باللون الأخضر ، أو في أسوأ الأحوال ، باللون الأصفر (تسمى هذه بالجريبفروت ، وهي موضوع لمقال مختلف.) وبهذه الطريقة ، يمكن للمشروع أن يهتم بسعادة من منحدر صخري. ، دون تدخل أو الحاجة إلى عمل إضافي. يأمل الفريق إما أن يصحح المشروع نفسه مرة أخرى قبل أن يكتشف أي شخص ذلك ، أو أنه لن يفعل ولن يلاحظ أحد. لذلك قاموا بتغليف مشروعهم الأحمر بصدفة خضراء ، وحبسوا أنفاسهم. بمعنى آخر ، يحولون مشاريعهم إلى بطيخ.
أنواع البطيخ
هناك العديد من الطرق التي يمكن لمدير المشروع من خلالها جعل المشروع يبدو وكأنه يسير على ما يرام ، حتى لو لم يكن كذلك. تتضمن بعض هذه الأشياء الكذب والخداع ، ولكن من السهل القبض عليهم (ومسار التصحيح معروف جيدًا.) ما يصعب اكتشافه هو عندما يكون ما يعرفه الفريق وما يتم الإبلاغ عنه خارجيًا قريبًا من بعضهم البعض ، ما لم تنظر بجدية كافية ، أو لتوسيع الاستعارة ، فافتح المشروع وانظر إلى الداخل. واحدة من أصعب الأمور التي يمكن ملاحظتها هي عندما يستمر المشروع نفسه ، لكن المنتج النهائي لن يلبي الحاجة الفعلية.
التغييرات في النطاق ، التغييرات في القيمة. يحدث تغيير نطاق المشروع طوال الوقت ، وهو أمر طبيعي تمامًا. يمكن تغيير الجداول ، ويمكن قص الميزات أو إضافتها ، ويمكن إضافة المطورين أو حذفهم. يمكن أن تمر المشاريع بالعشرات من تمارين إعادة تحديد النطاق لكل إصدار ، مما يترك المنتج النهائي شيئًا بالكاد يمكن التعرف عليه من الهدف الأصلي. في حد ذاته ، هذه ليست مشكلة. نظرًا لأننا نتعلم المزيد عن العميل والمشكلة ، فإن التركيز على ما سيقدمه المشروع غالبًا ما يكون أمرًا جيدًا. يمكن أن تضيف الميزات والمتطلبات الجديدة التي تظهر خلال المرحلتين الوسطى والنهائية للمنتج أحيانًا قيمة كبيرة. ولكن من الممكن والسهل القيام بالعكس.
مع تقدم المشاريع ، يتم التسليم النهائي عبر ثلاثة عوامل يجب أن تلعبها فرق المشروع: الميزات والتكلفة والوقت. معظم المؤسسات لديها القليل من الرغبة في زيادة تكلفة المشروع ، ولديهم بعض التسامح ، ولكن ليس كثيرًا ، لتخطي الجدول الزمني. العديد من مديري المشاريع الذين أعرفهم لديهم مقياس "في الوقت المحدد وفي حدود الميزانية" يجب عليهم الوصول إليه كجزء من مراجعة أدائهم. ما من غير المحتمل أن يكون لديهم هو قياس "قائمة الميزات التي يجب أن تصل إلى".
نظرًا لأن الجدول الزمني للمشروع يبدو أقل احتمالًا أن يمثل الواقع ، سيبدأ مدير المشروع الجيد في استدعاء مخاطر الجدول الزمني ، وربما حتى يحول المشروع نفسه إلى اللون الأصفر. رد الفعل السهل جدًا على ذلك هو قطع الوظائف عن المنتج النهائي ، وتقليل مقدار الوقت الذي سيستغرقه التطوير ، وبالتالي إعادته إلى الموعد المحدد. حسنًا ، عاد المشروع إلى اللون الأخضر. في المرات الأولى التي يحدث فيها ذلك ، من المرجح أن يقطع الفريق ميزات ليست مهمة لحالة العمل. في بعض الأحيان ، يؤدي القيام بذلك إلى إعادتهم إلى اللون الأخضر حقًا. في أوقات أخرى ، يبدأ الفريق في قطع الوظائف التي تعتبر حيوية بالفعل للمنتج ، أو يضعونها في "المرحلة الثانية" الغامضة التي من غير المرجح أن يتم تمويلها على أي حال.
قد يعني هذا أن الفريق يبلغ أنه في الموعد المحدد وعلى الميزانية ، أو أنه قريب بما يكفي لعدم إحداث فرق ، لكن ما يقدمونه سيفشل في السوق بسبب نقص الميزات. كل شيء يتم قياسه في المشروع ، مثل التكلفة ومخططات التوقف والجهد والجدول الزمني ، كلها تظهر على أنها بخير. لكن قيمة الناتج تتأثر ، مما يجعل المشروع أخضر من الخارج وأحمر من الداخل.
يعلم الجميع أن هذا لن يذهب إلى أي مكان. يحب مديرو المشاريع قياس الأشياء. سيقومون بقياس السرعة ، وعدد الأخطاء ، والتذاكر أو المهام المنجزة ، والنسبة المئوية للهدف ، ومجموعة كاملة من مؤشرات الأداء الرئيسية التي تبدو مفيدة للغاية لنجاح المشروع. واحدة من السمات الأكثر جنونًا لمدير المشروع هو الشخص الذي لديه عادة إظهار التقدم من خلال الإعلان عن شيء ما بنسبة 74٪ مكتمل هذا الأسبوع ، و 76٪ الأسبوع المقبل. أحد الجوانب المفضلة لدي في Agile هو التخلص من هذا النوع من اللغة تمامًا ؛ سواء تم القيام بشيء ما أو لم يتم القيام به. يساعد هذا النوع من القياس في منع نوع مختلف من البطيخ ، النوع الذي يبدو أنه يوجد فيه الكثير من التقدم ، ولكن لم يتم إنجاز أي شيء.
لا يعني إنجاز 80٪ من المهام العشر إنجازًا بنسبة 100٪ لثماني مهام. على الرغم من أن مديري المشروع يمكن أن يطلقوا على أنفسهم 80٪ بشكل شرعي ، إلا أن القصة الحقيقية ترسم صورة مختلفة كثيرًا. وفي الحقيقة ، يعرف الفريق القصة كاملة. بغض النظر عن كيفية إدارة المشروع ، هناك دائمًا طريقة لوضع علامة "مكتمل" على شيء ما. يمكن أن يكون مربع اختيار في MS-Project ، أو قد يكون نقل ملاحظة لاصقة على لوحة المهام ، أو يمكن أن يكون ببساطة مثل شطب شيء ما في قائمة المهام. يؤدي إكمال الأشياء إلى بناء الزخم ، وسيعرف الفريق ما إذا كان للمشروع أي زخم.
سيعرف فريق المشروع أن هذا مستمر ، وسيؤدي هذا فقط إلى تفاقم المشكلة. سيرى المطورون مدير المشروع يبلغ عن أن المشروع يسير على قدم وساق وأنه مكتمل بنسبة 80٪ ، ولكن لن يصدقه أحد في الفريق. يعرف الأشخاص الذين يعيشون في المشروع كل يوم أن هناك نشاطًا كبيرًا وكثيرًا من الأجزاء تتحرك ، ولكن إذا لم يتم الانتهاء من أي شيء ، فسوف يبدأون في التباطؤ. هذه هي أنواع المشاريع التي تستمر لسنوات في حالة كاملة في الغالب ، لكنها تبدأ في فقدان أعضاء الفريق ، وتعثر. جميع المقاييس حول الإنجاز والتقدم خضراء ، لكن المشروع باللون الأحمر بالتأكيد.
انها لن تنجح ابدا. يتم اتخاذ القرارات في وقت مبكر في المشاريع التي تؤثر على صحة المشروع طوال حياته ، وفي بعض الأحيان بعد ذلك. عادة ما يتم اتخاذ هذه القرارات من قبل أشخاص أذكياء للغاية ، باستخدام كل المعرفة المتاحة في ذلك الوقت ، وفي تلك اللحظة الفريدة ، هي القرارات الصحيحة. يمكن أن يحتوي المشروع على العديد من هذه القرارات التي تضع الأساس لكيفية تفكك الجهد بأكمله في المستقبل. وأحيانًا ، يتبين أن أحد هذه القرارات خاطئ بشكل أساسي.
بناءً على ما كان معروفًا في ذلك الوقت واستنادًا إلى الفهم غير الكامل للمستقبل ، وضع فريق المشروع معًا تصميمًا لكيفية عمل المنتج على المستوى الأساسي. تحتوي معظم المشاريع على أشخاص أذكياء يقومون بالتصميم ، وعادة ما يلبي ما يبتكرونه احتياجات المنتج أو المشروع أو المنظمة. ومع ذلك ، تتغير الأشياء ، وفي بعض الأحيان تبطل هذه التغييرات القرارات التي اتخذت في وقت مبكر. نادرًا ما يتمتع فريق المشروع برفاهية العودة بالزمن إلى الوراء واتخاذ قرار مختلف ؛ إما أن يتم إخبارهم أو قرروا المضي قدمًا.
هذه الحالة أصعب في الظهور ؛ حتى الحفر في المشروع من غير المرجح أن يظهر مشكلة. لا يعرف معظم الفريق حتى عن الموت الوشيك الذي يواجه المشروع. إنهم يتقدمون في مهامهم ويحرزون تقدمًا جيدًا. تكتمل المهام ويتم عرض التكرارات. ما لا يعرفونه مخفي. ربما لا تتناسب النتيجة النهائية مع العدد المطلوب من المستخدمين ، أو ربما يكون نظام الأمان خاطئًا بالكامل ، أو أن أي عدد من العناصر التأسيسية قد تم إيقافه قليلاً. حتى أنها يمكن أن تبدو بشكل صحيح عند القيام بها على نطاق صغير أو في التطوير ، لكنها لن تتعامل مع التواجد في بيئة إنتاج.
يعرف هذا أحد أعضاء الفريق ، أو على الأقل يشعر بالقلق حياله. حتى أن هناك احتمال أن يقوم هذا الشخص بالتصريح بها ورفعها على أنها مخاطرة. لكن لا يوجد دليل حتى الآن ؛ المشروع لم يفعل
فاكهة خالدة.
تخبرني ويكيبيديا أن البطيخ يعود إلى العصور القديمة ، ويدعي أنه تم العثور على بذور البطيخ في مقبرة الملك توت. يبدو هذا صحيحًا بالنسبة لي ، حيث إن المشكلات التي تواجه المشاريع ليست أيضًا تطورات جديدة. تخبرني ويكيبيديا أيضًا أن هناك 1200 نوع مختلف من البطيخ في العالم ، وقد أوافق على أن هناك العديد من المشاكل التي يمكن أن تواجهها المشاريع. في هذه المقالة ، لم يكن لدينا سوى مساحة لاستكشاف ثلاثة منهم ، لكن هؤلاء الثلاثة هم الذين ستواجههم كثيرًا.
الموقف الأول هو الحالة التي يعمل فيها المشروع نفسه بشكل جيد ، ولكن ما يقدمه ليس لديه فرصة ضئيلة أو معدومة لتحقيق أهداف العمل. يأتي هذا من إعادة تحديد نطاق المشروع وإعادة المعايرة لضرب مؤشرات الأداء الرئيسية للمشروع بطريقة تضر بالجدوى التجارية للمنتج.
والثاني هو المكان الذي يبدو فيه المشروع كما لو كان النشاط يحدث وتقدمًا ، ولكن لا شيء يكتمل. إذا سألت أي شخص في المشروع ، فسيعلن أنه مشغول للغاية ، ويمكنه أن يوضح لك المهام التي يعمل عليها. قد يكونون قادرين على إعطائك تاريخًا يعتزمون استكماله. سوف يتطلب الأمر نظرة أعمق بكثير لتخمين أن تاريخ الانتهاء هو تفكير بالتمني.
آخر واحد ناقشناه هو أكثر صعوبة في الرؤية. يبلغ المشروع عن البيئة الخضراء ، ويتم إكمال المهام واختبارها وعرضها بشكل كامل ، كما أن زخم الفريق جيد. ولكن هناك عيبًا فادحًا لم يراه سوى القليل منهم حتى الآن ، وهو أمر سيئ بما يكفي لإفشال هذا الجهد بالكامل.
تأتي مشاريع البطيخ في العديد من النكهات ، لكن النتيجة النهائية لا تزال كما هي. من الخارج ، أو حتى الإمساك به بين يديك ، يمكنك تسميته باللون الأخضر. ولكن بمجرد أن تبدأ في الحفر ، تجد أنها حمراء وتنزف. يستحق الأمر الجهد المبذول لفحص جميع المشاريع في محفظتك من وقت لآخر ، بما في ذلك المشاريع الخضراء. خاصة تلك الخضراء.
No comments:
Post a Comment