The purpose of a business strategy is to set direction and priorities of an organization. It is the job of the business architect to understand, interpret, and articulate the strategy so that it can be operationalized. I've mentioned earlier that I do not think it is the role of the business architect to develop the business strategy.
I've had strong success with business executives using a tool to concisely describe the elements of their strategy in a single page (depicted below). This strategy-on-a-page (SOAP) serves as a useful listening device for interpreting the strategy and communicating it to other stakeholders. Since I introduced the format to Microsoft a year ago, it has gained broad adoption across business and IT for articulating the business strategy.
The SOAP is tightly aligned to the elements of strategy that I described earlier. It begins with a statement of the organization's vision. This is usually an aspirational statement of ultimate end state for the organization. I've also used it to describe 3-5 year visions, especially when the organization is about to engage in a major transformation.
The second component is a statement of the organization's mission. This is a description of what the organization does. Most organizations have one handy so it's fairly easy to cut-and-paste into the SOAP. One of the purposes of this deliverable is to help determine if there are alignment issues within the strategy. The description of the mission should align with the vision – if it doesn't that is a good opportunity to have a discussion around that disconnect.
Priorities represent the 4-6 major things that the organization will focus on to achieve it's vision over the next 36-60 months. I explain to my clients that these are their strategy's "big rocks." I've heard these also referred to as "themes" or "pillars." Whatever you call it, try to make them as specific as possible - many businesses, especially those that are run bottom up, will use priorities as classification buckets for the imperatives underneath – this causes them to use simple words to describe the priorities rather than full statements.
Imperatives are the key set of actions that the organization will undertake in order to realize it's 3-year vision. These should be operational rather than aspirational. Generally, these things are well-understood but be sure to confirm that they are not short-term 12 month actions.
Outcomes and measures are a description of the desired outcomes and how they are measured. Although it is nice to be able to tie them to each priority, in some cases, the outcomes will cross multiple priorities. It should be noted that you are documenting specific business outcomes, not actions, i.e. the outcome might be described as the number of new customers acquired as opposed to the deployment of a particular system (which enables the customer acquisition).
I've had good traction with the SOAPs since I introduced them to Microsoft IT. This format is used by all MSIT business architects to describe their business strategies. Tony Scott, our CIO, has declared in meetings with our business clients that he "loves SOAPs" as they provide him with an easy way to talk about business strategy with his stakeholders. We've found that a number of our business clients are using the SOAPs as an easy tool to talk about their business strategy. On the IT side, our solution managers are using them to anchor discussions about priorities, i.e. "Should we do this? It doesn't map to the SOAP for the business." A VP for another business division seized on the format and mandated that each of his directs produce one. If you decide to use this format, I'd love to hear back about how well it works for your company.