One of the biggest opportunities for a Program Manager to exhibit leadership is during, what PMBOK refers to as, the “controlling processes”. This is the part of PMBOK and PMP training that says that project performance must be monitored to identify variances from the original plan. The idea being that the Program Manager can refine the plan to compensate for negative variances.
I believe, taken literally, this approach means the Program Manager has failed at leadership. It’s letting the project happen to the Program Manager, rather than driving results. It presumes that being late can only be seen in hindsight and not predicted by closely monitoring progress instead of functional group results. Functional group output should be viewed as that functional group’s mini-launch. It’s what they owe the cross-functional team. The entire team is not allowed to miss launch, so functional teams should not be allowed to miss their mini-launches.
As an example of how a Program Manager can provide leadership, consider a product engineering team that is developing components that must be purchased and assembled. If the development process takes 12 weeks, Purchasing should expect to receive data and drawings 12 weeks after Engineering starts working on designs.
However, if Purchasing waits until the 12 weeks is expired to being the sourcing process, they will have to get up to speed before they know the types of products that have to be bought and learn about any special requirements before they can contact suppliers. Likewise, the suppliers will have a steep learning curve. It’s like a relay race where runner 2 is standing still and runner 1 crashes into runner 2 to hand off the baton. In real relay races, runner 2 starts jogging to get up to speed in anticipation of runner 1 arriving. So, in our example, Purchasing can be brought into project team meetings 4 to 6 weeks before the final design is complete. They can learn that the product is bigger than a breadbox and smaller than an elephant. They can start to consider which commodities they need to buy and preferred suppliers. They can even share drawings with suppliers to get preliminary estimates and feasibility consideration.
That’s leadership. It creates a pull on engineering and creates constructive pressure to not be late. It pulls Purchasing into the project and takes away excuses for being late or getting a slow start. It allows Purchasing and suppliers to have a say in the design before it is released. It puts the emphasis on the success of the project instead of allowing different functional groups to sub-optimize their output over that of the entire project.
This is an example of where I believe having a system (PMBOK) gives Program Managers false confidence that they can turn off their brains because a system or process will deliver the project. It creates “newspaper reporter” Program Managers instead of “air traffic controller” Program Managers. The team desperately wants to be led. They probably feel that they already have enough managers.
I believe, taken literally, this approach means the Program Manager has failed at leadership. It’s letting the project happen to the Program Manager, rather than driving results. It presumes that being late can only be seen in hindsight and not predicted by closely monitoring progress instead of functional group results. Functional group output should be viewed as that functional group’s mini-launch. It’s what they owe the cross-functional team. The entire team is not allowed to miss launch, so functional teams should not be allowed to miss their mini-launches.
As an example of how a Program Manager can provide leadership, consider a product engineering team that is developing components that must be purchased and assembled. If the development process takes 12 weeks, Purchasing should expect to receive data and drawings 12 weeks after Engineering starts working on designs.
However, if Purchasing waits until the 12 weeks is expired to being the sourcing process, they will have to get up to speed before they know the types of products that have to be bought and learn about any special requirements before they can contact suppliers. Likewise, the suppliers will have a steep learning curve. It’s like a relay race where runner 2 is standing still and runner 1 crashes into runner 2 to hand off the baton. In real relay races, runner 2 starts jogging to get up to speed in anticipation of runner 1 arriving. So, in our example, Purchasing can be brought into project team meetings 4 to 6 weeks before the final design is complete. They can learn that the product is bigger than a breadbox and smaller than an elephant. They can start to consider which commodities they need to buy and preferred suppliers. They can even share drawings with suppliers to get preliminary estimates and feasibility consideration.
That’s leadership. It creates a pull on engineering and creates constructive pressure to not be late. It pulls Purchasing into the project and takes away excuses for being late or getting a slow start. It allows Purchasing and suppliers to have a say in the design before it is released. It puts the emphasis on the success of the project instead of allowing different functional groups to sub-optimize their output over that of the entire project.
This is an example of where I believe having a system (PMBOK) gives Program Managers false confidence that they can turn off their brains because a system or process will deliver the project. It creates “newspaper reporter” Program Managers instead of “air traffic controller” Program Managers. The team desperately wants to be led. They probably feel that they already have enough managers.
RSS Feed
