20 Bay Street, 11th Floor
Toronto ON
M5J 2N8 Canada Phone +1.416.846.6185 Contact Us
Program Management is essentially the process of managing several interrelated projects. For this reason, people tend to incorrectly assume that it requires essentially the same skills and techniques as project management, just on a larger scale. The reality, as is known to those who manage them, is that programs (or programmes) are several degrees more complicated and risky.
What makes the difference? Scale is definitely one contributing factor. The multiplication effect of issues from multiple interdependent projects is another. But the biggest one is the breadth of impact that is expected to result, often affecting multiple functions or business units. This means that the risk of failure is significantly higher than for the average project because it may only take one unprepared change leader or resistant function to derail or seriously delay the entire effort.
Unlike Project Management, training, standards and software only go so far in Program Management. Program Managers need these foundations, but will tell you that experience is much more important and that creative strategies and techniques to control and reduce risk is what it’s all about. And they know there are some deceptively simple tools that, when used in the right way and at the right time, can make a huge difference in risk reduction. These are the Program Manager’s “tricks of the trade”.
StratForm has significant experience from managing a range of programs across different industries and cultures. And we’ve found certain “tricks” that we rely on time and again because they avoided serious downstream issues. Here are three that we highly recommend to any budding Program Manager.
What makes the difference? Scale is definitely one contributing factor. The multiplication effect of issues from multiple interdependent projects is another. But the biggest one is the breadth of impact that is expected to result, often affecting multiple functions or business units. This means that the risk of failure is significantly higher than for the average project because it may only take one unprepared change leader or resistant function to derail or seriously delay the entire effort.
Unlike Project Management, training, standards and software only go so far in Program Management. Program Managers need these foundations, but will tell you that experience is much more important and that creative strategies and techniques to control and reduce risk is what it’s all about. And they know there are some deceptively simple tools that, when used in the right way and at the right time, can make a huge difference in risk reduction. These are the Program Manager’s “tricks of the trade”.
StratForm has significant experience from managing a range of programs across different industries and cultures. And we’ve found certain “tricks” that we rely on time and again because they avoided serious downstream issues. Here are three that we highly recommend to any budding Program Manager.
Simple But Powerful Program Management "Tricks"
Who, Won, Done
Fax +1.416.214.2043
Knowledge Center
© 2010 StratForm
Based on excellent research by Francis Hartman (SMART Management), there are three key questions that any large-scale project or Program Manager should pose to their sponsors:
The beauty of these three key questions is that they boil down an entire program into succinct points that all members of a program management structure can understand and retain - people typically only remember three things about any subject. Clearly stating the (a) tangible deliverables that are expected at the end date (Done), (b) how the success of the program will truly be evaluated (Won), and (c) which stakeholders will be the ultimate evaluators of both questions, is worth its weight in gold.
In the many programs we’ve managed, these questions tend to get repeated and reviewed more often than any other element of the program charter. They are incredibly useful reminders in Steering Committee meeting to realign both old and new participants on the objectives of the program, and an easy way to identify changes in thinking that may have arisen. While it is important to not spend too much time on developing this one element, especially to the detriment of spending sufficient time on other important topics, this is one of the best “tricks” we can recommend.
- How do we know when we’re Done?
- How do we know if we’ve Won (succeeded)?
- Who gets to vote on questions 1 and 2?
The beauty of these three key questions is that they boil down an entire program into succinct points that all members of a program management structure can understand and retain - people typically only remember three things about any subject. Clearly stating the (a) tangible deliverables that are expected at the end date (Done), (b) how the success of the program will truly be evaluated (Won), and (c) which stakeholders will be the ultimate evaluators of both questions, is worth its weight in gold.
In the many programs we’ve managed, these questions tend to get repeated and reviewed more often than any other element of the program charter. They are incredibly useful reminders in Steering Committee meeting to realign both old and new participants on the objectives of the program, and an easy way to identify changes in thinking that may have arisen. While it is important to not spend too much time on developing this one element, especially to the detriment of spending sufficient time on other important topics, this is one of the best “tricks” we can recommend.
The Priority Triangle
This model is referred to in many sources including the Project Management Body of Knowledge guide by the Project Management Institute, and is most commonly seen in engineering projects (perhaps engineers are the ones who most easily understand the reality of constraints? We digress....).
The Priority Triangle is another deceptively simply tool that that can tremendously increase a Program Manager’s confidence to accepting accountability for a program. The three points on the triangle represent the constraints of Time, Cost and Quality, all of which are important but rarely satisfied equally well. The “trick” is to identify and gain agreement on which constraint is fixed (i.e., most important), which is second priority (i.e., has some flexibility) and which may be sacrificed if needed.
It is truly an (all to frequent) cop-out to say that they are all equally important. Programs rarely achieve all three and re-prioritization decision-making is a regular occurrence that must be anticipated. If you get a Steering Committee to agree on these priorities early in the program then downstream scope change management become much easier. Prioritizing one constraint doesn’t imply that the other two are ignored, what it should drive a Program Manager to do is budget more safety buffers for them in anticipation of downstream change impacts; for example, increase timeline and financial contingencies if the quality of final deliverables is considered to be “sacred”.
Similar to Who, Won and Done, StratForm consultants have found that referring back to a priority triangle (and revising it if situations change) multiple times during a program is a highly valuable “trick” to objectively resolve debates and simplify change management in a complex program.
The Priority Triangle is another deceptively simply tool that that can tremendously increase a Program Manager’s confidence to accepting accountability for a program. The three points on the triangle represent the constraints of Time, Cost and Quality, all of which are important but rarely satisfied equally well. The “trick” is to identify and gain agreement on which constraint is fixed (i.e., most important), which is second priority (i.e., has some flexibility) and which may be sacrificed if needed.
It is truly an (all to frequent) cop-out to say that they are all equally important. Programs rarely achieve all three and re-prioritization decision-making is a regular occurrence that must be anticipated. If you get a Steering Committee to agree on these priorities early in the program then downstream scope change management become much easier. Prioritizing one constraint doesn’t imply that the other two are ignored, what it should drive a Program Manager to do is budget more safety buffers for them in anticipation of downstream change impacts; for example, increase timeline and financial contingencies if the quality of final deliverables is considered to be “sacred”.
Similar to Who, Won and Done, StratForm consultants have found that referring back to a priority triangle (and revising it if situations change) multiple times during a program is a highly valuable “trick” to objectively resolve debates and simplify change management in a complex program.
The Happy Survey
This last recommended “trick” for Program Managers is not a specific tool or model, but rather a regular activity to do from start to finish during a program: conducting “happy surveys” of your team.
The basic concept is to objectively survey key members of your program office and project teams on their general state of satisfaction about the program, their particular project/track and role, etc. The surveys are conducted regularly, results shared and discussed, and improvement strategies are developed. The results should be trended throughout the program. The “happy survey” is a team effectiveness evaluation technique, and we’ve seen multiple formats and techniques used successfully in different situations, from online questionnaires to people putting color tokens into “happy, neutral, sad” buckets at the door when they leave the office.
The “trick” however, is to choose a method and do it consistently and properly. When people tell us about cases where they’ve tried but abandoned its use, the most common root causes of the problems were that it was anonymous, too time consuming, too infrequent or used for marketing purposes – in other words, the program office saw it as a reporting and not an analysis and problem-solving tool.
A good “happy survey” is very brief (less than 6 questions), done enough times to trend general satisfaction throughout each stage of the program, and requires people’s names so that more insight can be gained when needed. A Program Manager aggregates the results and discusses them with team members and sponsors to determine how to resolve problems, including whether they are common to the team or specific to one person. The results are not used for punishment or finger-pointing.
Completing and using some form of a “happy survey” is an objective way to get the core members of a program structure to sit back and evaluate the internal health of the program team. It shouldn’t replace the need to ask people directly “How are you doing?”, but it complements and builds on those efforts.
Again, this is a simple, but very powerful technique that we’ve found makes its way into almost every successful program that we’ve had the pleasure to manage or participate in.
The basic concept is to objectively survey key members of your program office and project teams on their general state of satisfaction about the program, their particular project/track and role, etc. The surveys are conducted regularly, results shared and discussed, and improvement strategies are developed. The results should be trended throughout the program. The “happy survey” is a team effectiveness evaluation technique, and we’ve seen multiple formats and techniques used successfully in different situations, from online questionnaires to people putting color tokens into “happy, neutral, sad” buckets at the door when they leave the office.
The “trick” however, is to choose a method and do it consistently and properly. When people tell us about cases where they’ve tried but abandoned its use, the most common root causes of the problems were that it was anonymous, too time consuming, too infrequent or used for marketing purposes – in other words, the program office saw it as a reporting and not an analysis and problem-solving tool.
A good “happy survey” is very brief (less than 6 questions), done enough times to trend general satisfaction throughout each stage of the program, and requires people’s names so that more insight can be gained when needed. A Program Manager aggregates the results and discusses them with team members and sponsors to determine how to resolve problems, including whether they are common to the team or specific to one person. The results are not used for punishment or finger-pointing.
Completing and using some form of a “happy survey” is an objective way to get the core members of a program structure to sit back and evaluate the internal health of the program team. It shouldn’t replace the need to ask people directly “How are you doing?”, but it complements and builds on those efforts.
Again, this is a simple, but very powerful technique that we’ve found makes its way into almost every successful program that we’ve had the pleasure to manage or participate in.