Three reasons why a less obvious choice might be better.
Unlike conventional practice, where discovery is about gathering requirements and design is predominantly about technical design and human factors design, discovery-and-design for strategy translation is a very business-centric activity. We must discover stuff having strategic potential and then design the stuff to realize strategic potential. The objective is to improve the organization in specific ways to contribute to business strategy.
Given such a strong business focus, the answer to the question "Who should do strategy translation?" seems easy: the business side. However, while the strategy translation practitioner must have strong business skills regardless of which side he or she belongs to, there are a few advantages to making the software team responsible for doing strategy translation.
Reason 1
A major reason is that strategy translation will get done as a standard activity only if it were part of the software team’s regular process. Business folks have other things to do: business-as-usual or daily business operations. They do have a strong strategy process that covers strategy formulation and strategy execution, but the latter is focused on business-as-usual and on managing new programs and projects. The strategy process misses the crucial activity of strategy translation. At least until this gets fixed, it's better that conventional SDLC be expanded and equipped to include strategy translation.Reason 2
Strategy translation involves working on business processes in and around the software. If so, digital strategist Ade McCormack has a point. In a Financial Times article, McCormack said, “The IT department should influence the business processes as much as the user community. The IT department is in a unique position in terms of its view of the process flows across the organisation and so can provide genuinely valuable process consultancy. I believe process consulting is the core function of the IT department.” A related point is that business process expertise gained by team members in one project can be used in other projects requiring the same expertise.Reason 3
Finally, by performing the crucial strategy translation activity well, the software team becomes part of something much bigger. They no longer deliver just technology, but make measurable strategic contributions to the organization.What it takes
McCormack hilariously says, “IT people are often happy to work on a system, or a small subset of the system, without having any real desire to understand the business rationale.… The only reason they would ever climb over the IT department sandbags would be to rescue an injured fool who thought that engaging with users in a helpful manner would undo years of bitter enmity.” It’s true that software folks generally prefer technical activities. Thankfully, only the software team's business analysts need to up-skill for the how-to skills in strategy translation. The rest of the team need only pick up awareness of strategy translation.This article was first published at CIO.com, Jul 29, 2016