I tried not to sputter as the young, no-grey haired, highly-respected PhD sporting engineering manager told me my suggestion did not have merit, because I was non-technical. My experience in this challenge was relevant, and keenly pertinent. Our company needed to make this change, we couldn’t afford to do things the old way, but the engineering manager insisted the new way was too risky and “couldn’t be done.” In the end, we succeeded in making the change. We didn’t do it exactly the way I recommended. Our solution required expertise and implementation from about six other people including management and two other teams. Our adoption of the new way strengthened our product’s competitive advantage, and had minimal impact on the schedule. The reason I am bringing up this story with its happy ending is that it represents a common type of battle and the value of a program-manager.
The executed solution was not only one person’s idea. We weren’t barred from trying by one nay-sayer either. Program managers are key for the complex multi-dimensional projects that requires more expertise and judgment than can be found in any one person. It is very common that the program manager has not previously specialized in every aspect of the project. Planning a product throughout its lifecycle included design, implementation, and test, plus training, documentation, sales, improvements, and, eventually, wrap-up or even product retirement. The steps require a mosaic of experts at different points in the project. It is inevitable that the program manager will work with people who know more than they do on any given topic – it’s a good thing really. The challenge is to provide leadership in the right direction, listen carefully to arguments and counter-arguments, and guide the activities to best use all the required expertise. In the example at the beginning of the story, I needed to navigate the young engineering manager’s bias about the choices with other experts, with insisting that we could not keep doing things the old way, and with gathering input from others on how we could make this necessary change.
In addition to pointing out that lack of omniscience and differences in opinion are common occurrences, I wanted to share my recommendations to best choose the right next steps for your projects:
- Recognize that having a team with others that know more than you is a great treasure and benefit. Programs that truly need project managers generally require expertise (both formal education and work experience) that exceeds any individual’s knowledge. I can make a cake all by myself without extensive planning, (although if I include my twins, I do a work-breakdown structure) but new technology and large market products require teams. Actively welcome extra expertise and opinions. Dig into unclear comments to find the background and reasoning behind contrary input.
- Use facts as a foundation. Where possible, look things up. If you are lucky enough to have an organization with documented institutional knowledge (organizational process assets) review them and interview their authors. Be a good citizen and save and document your projects when closing your project. Actively seek expertise – even outside your company when needed. With today’s technology and expert forums there are many ways to check your facts.
- These technical differences of opinion can all be categorized under Risk. There is some probability that the concern is a valid one – in both likelihood and impact. A better solution to unclear choices where facts don’t pave the way to an answer, better than “I’m right.” “No, I am.” “Are not.” “Am too.” “Nunh unh!” is to map the concerns in a risk matrix. Identify risks. Rephrase objections into risks. Example – “We can’t do that; it will take forever.” Translates to: New method make take more time than schedule permits. Score the risk for likelihood and severity of impact. I use a spreadsheet so that Method taking too long: Possible = 3 Impact of Catastrophic = 5, therefore total risk = 15. The score helps rank risk, but the more interesting discussion is how to avoid or mitigate the risk. To avoid it: Use the old method ((be sure to rank that risk, too)). To mitigate it: new training or new equipment. Re-score these risks periodically. If nothing else, formally listing the disagreement as a risk helps move the conversation to productive alternatives and ideas.
It is not constructive to dismiss a suggestion by calling a program manager “non-technical” or to even debate how technical one is, the energy is better spent on the merit of the suggestion and thoughtful alternatives. Program managers add key value by getting synergy from the team members’ expertise. Good solutions to technical challenges usually include tradeoffs in time, cost, and risk. We absolutely need top experts with deep technical backgrounds, experts with business and hands-on experience, and super effective program managers who can bring together the facts, new ideas, and practical considerations to help their organizations deliver successful projects.
Well said. Program managers should be able to lead a team, not do it all themselves — the latter is a failure of delegation skills and experienced leaders would recognize that.