It’s amazing how the things you learn growing up stick with you. Take my introduction early in life with mentoring. I was introduced to this concept in a 1970s Saturday morning television show called “Shazam.”
The protagonist, a young boy named Billy, traveled the country in an RV with an advisor — whom he called mentor — getting advice and guidance while encountering new experiences each week. The mentor was a pipe-smoking, middle-aged guy who wore tight-fitting turtlenecks. In the show, Billy also had a staff of elders he consulted with in each episode. These elders consisted of no less than the mythic heavyweights Solomon, Hercules, Atlas, Zeus, Achilles, and Mercury. Once Billy had consulted with his mentor and the elders, he would yell “Shazam” and magically turn into an adult Superhero, who wore a tight fitting body suit that showed off his potbelly when he flew. He, of course, saved the day by using the wisdom of his mentor and elders.
Why do I cling to this memory? For the past seven years, I’ve been a mentor to almost 20 new and experienced project managers (PMs). Fortunately, I haven’t had to wear tight-fitting turtlenecks or drive an RV. Coincidentally, the PMs I work with do not directly report to me but rather to several hierarchal chains (i.e. their elders). Getting all the links in these chains to see that a well-trained PM increases the chance of a project’s success sometimes feels like nothing short of an Olympic feat.
Over these years I’ve formulated some principles or assumptions that guide me as a mentor. I don’t promise they’ll work all the time for you, but taken together they have been extremely helpful to me.
- PMs will accept help but they will rarely, if ever, ask for it. My major assumption! I had to devise a way to gain acceptance of my mentorship role since none of the PMs directly reported to me. I also had to ensure that I met with them on a regular basis so we could build a relationship.
- A PM and a mentor must find a common ground to work from. The only common ground I figured I could quickly negotiate with each PM was that my role was geared to make them successful. This goal was quickly agreed to by each PM. However, each PM took a wait-and-see attitude to verify that I was going to be true to my word. My feeling was if the PMs were successful the projects would be successful. Although this may not always be the case, I figured the odds were in my favor.
- A mentor must never let the PM’s project fail. If the PM ignores the mentor’s advice and the mentor feels the project will fail, the mentor must bring this to the attention of the PM’s hierarchy. Although this sounds contrary to the previous point, I believe it is a must. In the last seven years, I have not been faced with this situation, but it is something I am ready to address if the situation arises.
- PMs should explain their plans to the mentor. The mentor should actively listen to these plans and determine if they will or will not work — there are many ways to successfully execute projects. The role of a mentor is to determine if the PM’s plan is sound and will work. It is NOT the role of the mentor to get the PM to do it exactly as the mentor would.
- A mentor must allow a PM to experience little failures so that the PM can grow. If a PM never experiences negative feedback from others, she or he will not grow. The challenge to the mentor and PM is determining what little failures look like.
- A mentor must take time to listen to what others are saying about the PM’s project. If the only data or viewpoint a mentor gets is from the PM, then only one side of the story is heard and the mentor won’t be able to properly coach the PM to be successful.
- Part of the mentor’s role is to be a venting source for the PM. No action or words of wisdom may be required, just the ability to listen and let the PM vent. New or experienced PMs do not have many vehicles to allow them to feel secure while venting their frustrations.
- A mentor must not be seen as competing with the PM. I do not attend the project team meetings but am copied on the resulting meeting notes. If I showed up at the project reviews, the project team might become confused as to who was in charge. A project can have only one overall PM.
To date, by using combinations of these assumptions/principles, I estimate that 95 percent of the PMs I have mentored, and their projects, have been successful. Not one of the PMs has ever had to yell “Shazam”! As I continue to mentor PMs, I imagine new assumptions/principles will be added and some eliminated due to the individual needs of PMs and their hierarchies.