Project Connoisseur
This post originally appeared on July 19, 2010 on BetterProjects.net.
I love everything about wine. From the vineyard to the glass, the entire process simply fascinates me. I love talking about grape varieties, soil composition, weather patterns, oaked v/s steel, yeast, racking, bottling… the list just goes on and on. If you know anyone like me, or are yourself a fan of wine, you’ll know that there are lots of terms that are used by wine snobs that you’re not likely to hear anywhere else. There is a completely new vocabulary to learn if you want to be thought of as a wine connoisseur by your friends.The same thing can be said for working on projects. We talk about project plans, predecessors and successors, KPIs, functional requirements, burn down charts, RACI matrix and requirements elicitation. These are terms that make sense to those of us who have worked on projects for years and allow us to communicate with other project people more effectively. This shared lexicon is a huge positive attribute when speaking with other people who know the language, but can be a huge detriment to people who do not know the language.
Lets use an absurd example to prove this point… If someone is dying of dehydration and stumbles into a wine party, what would you, the wine snob, do? Would you start to discuss the ways in which the skins were left long into the fermentation process in order to extract all the proper tannins? Or about how the grapes were allowed to desiccate and slightly mold on the vine, just enough so that their sugar content rose and their water content fell enough to make a perfect vintage?
No, you would not do this to a dehydrated person. You would give them water. Clean, pure, clear water. Wine is not refreshment; it is taste, flavor, texture and smell. Water is life (but wine is what makes it worth living!)
So why is it that when our stakeholders come to us with massive problems in their areas, why do we expect them to speak the language of projects? Our stakeholders don’t care about a project charter or gantt chart; they care about how their business is crumbling apart in their hands.
Its not that the language and processes of project land are not important; they are vitally important and I wish that everyone shared in my belief of their importance. I do my best, when my stakeholders are on solid ground and in no danger of drowning, to educate them in the how, what and why of project theory. Most of them are appreciative for the new knowledge and can quickly assimilate the lessons into their daily activities, but that is only when their first priority is not survival.
When next a stakeholder comes to you, I challenge us all to make sure that our response to their need is not to send them off with a project document template or a complaint about how you don’t have time for them right now. Spend five minutes, acknowledge their concerns, schedule them for a half hour meeting in the next few days where you can more properly focus on their need, lending them your expertise in helping to solve their problems. Even if you do nothing more than listen to them complain for the entire time, at the end you will have built a vast amount of good will that you can call upon in the future.