I’ve read many postings online about all of the subject matter to be learned about the discipline of Program Management. I’ve also known some people that knew an intimidating amount of Program Management jargon that, no doubt, came from serious studying about Program Management. My experience, however, has been, that these people can be a source of power in a discussion about the topic of Program Management but they lack the practical skills to relate to a cross-functional team and launch a program successfully.
These people can create forms that nobody can understand and create timelines that are so complicated that nobody can follow. Then I’ve seen them stare down their noses at the people that are really doing the work as if to say, “What’s not to understand? I’m from Corporate, and I’m here to help. You’re not as smart as I thought you were.”
For my whole career in Program Management, I have said, “Program Managers neither create nor destroy information. They merely orchestrate the cross functional resources to deliver on the contractual obligations of the enterprise.”
Let’s face it, the Program Manager’s only marketable output is Program Management. There is no product we can put a price tag on and sell. We have to guide the team, anticipate risk, mitigate risk, balance resources, and on and on. If people-skills is one of the most important factors in Program Management, and I believe it is, they why do Program Managers attempt to dilute the functional team members workload with a bunch of self-serving Program Management jargon?
Cross-functional team members just want to be led. They want somebody to keep the end goal in front of them and have meaningful touch-points for assessing project status and direction. They do not want to learn how many fancy Program Management concepts you can articulate.
I get that this “expertise” must exist. It has its place in the Program Management Office (PMO). The PMO is the place where the Program Managers go to sharpen their saw and make sure they have the right tools in the toolbox. However, I believe that when a PM is deployed by the PMO, they need to spend less time talking about the tools and more time demonstrating what the tools can produce.
If the carpenter you hired to build your deck spent all of his time trying to impress you with his special saw instead of using it to build your deck, would you think he was helpful? The tool is of no value other than the product that it produces.
These people can create forms that nobody can understand and create timelines that are so complicated that nobody can follow. Then I’ve seen them stare down their noses at the people that are really doing the work as if to say, “What’s not to understand? I’m from Corporate, and I’m here to help. You’re not as smart as I thought you were.”
For my whole career in Program Management, I have said, “Program Managers neither create nor destroy information. They merely orchestrate the cross functional resources to deliver on the contractual obligations of the enterprise.”
Let’s face it, the Program Manager’s only marketable output is Program Management. There is no product we can put a price tag on and sell. We have to guide the team, anticipate risk, mitigate risk, balance resources, and on and on. If people-skills is one of the most important factors in Program Management, and I believe it is, they why do Program Managers attempt to dilute the functional team members workload with a bunch of self-serving Program Management jargon?
Cross-functional team members just want to be led. They want somebody to keep the end goal in front of them and have meaningful touch-points for assessing project status and direction. They do not want to learn how many fancy Program Management concepts you can articulate.
I get that this “expertise” must exist. It has its place in the Program Management Office (PMO). The PMO is the place where the Program Managers go to sharpen their saw and make sure they have the right tools in the toolbox. However, I believe that when a PM is deployed by the PMO, they need to spend less time talking about the tools and more time demonstrating what the tools can produce.
If the carpenter you hired to build your deck spent all of his time trying to impress you with his special saw instead of using it to build your deck, would you think he was helpful? The tool is of no value other than the product that it produces.
RSS Feed
