No matter what industry you work in, chances are you've had to build a long list of specific requirements to help define project success and to identify project risks.
In many cases, you're required to align with your primary stakeholders on these requirements before you can move to the next project phase. These stakeholders are likely high-level executives who come from the sales or marketing side of business, or who are senior enough to have bypassed getting into the fundamentals of a project.
Whatever the case, you're now left with the challenge of presenting them with these requirements. If they don't agree or understand your direction, you can't proceed on the project.
If you're lucky, your stakeholders believe they hired you and your team because you're the experts. In this case, the presentation is more about showing them you've done the work and the next steps, instead of actually having to get their buy-in.
Conversely, you may find yourself in a situation where many of the requirements need to be discussed and debated among the stakeholders.
No matter which of these situations you're in, I've found that this three-step approach works best when presenting requirements to executives:
1. Divide the requirements into categories that will vary depending on the type of project. For example, if you're producing a software solution, your categories may be "security," "user interface," "connectivity," and "primary functionality."
2. When you have determined your categories, summarize the high-level direction being defined by each of the micro-requirements under each category.
If there is a particularly divisive requirement and you anticipate debate, you should pull that requirement out and highlight it with its own slide. For instance, if you have decided to develop using Java and this needs to be discussed, or specifically approved, make sure that item is highlighted.
3. For all categories of requirements, create a list of pros and cons for the recommendation, and provide justification for the choice the team made. For documentation purposes, I would also include a check box that indicates agreement or disagreement from the stakeholders.
Presenting detailed requirements to executives, especially in a limited time frame, is always a delicate operation. In my experience, following this approach will ultimately help you get the support you need to move forward in your project's next phase -- without risking a drawn-out approval process.
What techniques have you used successfully to gain executive-level buy-in on project requirements?
In many cases, you're required to align with your primary stakeholders on these requirements before you can move to the next project phase. These stakeholders are likely high-level executives who come from the sales or marketing side of business, or who are senior enough to have bypassed getting into the fundamentals of a project.
Whatever the case, you're now left with the challenge of presenting them with these requirements. If they don't agree or understand your direction, you can't proceed on the project.
If you're lucky, your stakeholders believe they hired you and your team because you're the experts. In this case, the presentation is more about showing them you've done the work and the next steps, instead of actually having to get their buy-in.
Conversely, you may find yourself in a situation where many of the requirements need to be discussed and debated among the stakeholders.
No matter which of these situations you're in, I've found that this three-step approach works best when presenting requirements to executives:
1. Divide the requirements into categories that will vary depending on the type of project. For example, if you're producing a software solution, your categories may be "security," "user interface," "connectivity," and "primary functionality."
2. When you have determined your categories, summarize the high-level direction being defined by each of the micro-requirements under each category.
If there is a particularly divisive requirement and you anticipate debate, you should pull that requirement out and highlight it with its own slide. For instance, if you have decided to develop using Java and this needs to be discussed, or specifically approved, make sure that item is highlighted.
3. For all categories of requirements, create a list of pros and cons for the recommendation, and provide justification for the choice the team made. For documentation purposes, I would also include a check box that indicates agreement or disagreement from the stakeholders.
Presenting detailed requirements to executives, especially in a limited time frame, is always a delicate operation. In my experience, following this approach will ultimately help you get the support you need to move forward in your project's next phase -- without risking a drawn-out approval process.
What techniques have you used successfully to gain executive-level buy-in on project requirements?
I like your approach. The only thing I would add is building support prior to the presentation.
I would reach out to some or all of the stakeholders in advance or others in the organization that could provide insight into areas where there may be agreement or disagreement. Most stakeholders will appreciate the opportunity to contribute and you may also learn about the hot buttons of those that don't by talking with those that do.