Rule #1,035: Know thy Sponsor
Guest post by Josh Nankivel, PMP
Founder of pmStudent.com and WBS Training
The following post by Josh Nankivel provides a first-hand perspective on the importance of understanding you project sponsor. We found his article where it was originally posted on Toolbox for IT and we thought it was totally pertinent outside of IT. Enjoy!
Have you ever poured your heart and soul into a project, and been so proud of the results you could almost cry?
And then have that project blow up in your face?
Well, I did.
11 Years Ago
It was my first real project. I had started with a small tool that I was building myself in my spare time to assist technical support reps in a major computer company. After a month and extensive collaboration with all the other domestic training departments, it was ready for initial release.
It gained immediate attention of a vice president who decided to back it with more funding and functionality. I was whisked away from my “day job” as a lead in the training department and managed the project with some external consultants the VP had brought on board.
It was a lot of work, but a work of passion. We decided to add troubleshooting guides into the tool for new technicians and as a reference for anyone who got stuck or ran out of ideas. I was proud of the work the team had done and how we had collaborated heavily with the end users through focus groups to uncover best practices in troubleshooting and customer service.
Implementation Time
Right before rolling out the new tool, I was called away to start a similar project for a different department within the company. It was time sensitive, so they handed the final details of training and roll-out to the consulting firm and the existing trainers throughout the United States.
While on travel to get things going with the other department, I learned they would be conducting the training on the new tool while I was there. I casually slipped into a training class to see how things were going.
The Punchline
Most of the training was great. It was a good overview of the tool and how to use it. It seemed to be pretty well-received by the trainees too.
Then it happened.
The trainer told the class that this tool would be mandatory. All technicians MUST use it and would be audited based on their use of the tool. If their troubleshooting method deviated from it, they may get written up.
My jaw dropped onto my lap, as did everyone else’s. They recovered more quickly than I did though, and the grumbling had reached crazy proportions while I still sat there wide-eyed and paralyzed.
The phone calls, shouting, and obscene displays of disgust I performed afterward at multiple locations in the US are not important.
The lesson I learned from this experience is.
Know Thy Sponsor
The directive about using the tool like robotic monkeys came directly from the project sponsor, the VP. No indication had ever been given that this tool would be mandatory or implemented in such an autocratic fashion. I focused nearly 100% of my attention on the end users, and nearly nothing besides standard status reports to the sponsor.
Had I paid more attention and asked better questions, I could have found out what his intentions were. My assumptions drove the project in a certain direction, and the end result would have been much different if I had uncovered this vital requirement from my sponsor early on. I also would have insisted on staying with the project through implementation and put an emphasis on proper change management techniques such as a phased transition if I had known what I should have known.
Josh Nankivel, PMP, is founder of pmStudent.com and WBS Training instructor. He has been managing IT and non-IT projects in computing, financial services, telecommunications, and aerospace for over a decade. Josh has a Bachelor of Science degree in project management.
If you’re on Twitter, you can follow Josh at @pmstudent and updates from this blog at @MTWblog. Let us know what you think about the guest posts you find here and what more you’d like to see.
