Creating a business capability map is just part of the challenge businesses and chief information offices face. Taking the information in the map and making it work and translate into real, tangible business impact can often present far more obstacles than the development of the map itself but without this crucial step the benefits of undertaking the task of creating a business capability map are generally lost.

In order to create business impact based on a capability map, businesses need to change but that can be difficult. Whether the business has embedded processes or faces opposition to change from other employees, change can be challenging but it’s needed to keep the business evolving, driving forward and competing with rivals.

Chip Gliedman, the former VP and Principal Analyst of Forrester Research, has previously written an article that outlines eight ways that chief information officers can use a capability map to create business impact.

• Clarifying priorities and uncovering common interests
• Improving the technology investment process
• Connecting business process and IT change initiatives
• Linking the ‘bill of IT’ to the business model
• Having a better-informed discussion on the right service-level agreements
• Meaningful rationalization of the application portfolio
• Educating project teams on business context
• Guiding innovation around business impacts

Are you doing each of these things within your business? If not it’s time to ask yourself what’s keeping your organization from using your capability map in one or more of the listed ways. It’s hard work changing how a business organizes work but the effort is worth it.

The best area to focus on will depend on each individual business and their goals. Assessing each business’ targets and how best to achieve them should drive the use of capability maps for delivering impact. For instance a large, complex business with numerous business and IT projects simultaneously operating can benefit from connecting business process and IT change initiatives to ensure each separate project is contributing to the bigger picture.  On the other hand, in firms that take IT services for granted, the CIO could benefit by demonstrating the crucial role IT plays.

Overcoming the challenges

Even once you’ve selected a process you want to adopt, it’s no easy task to translate capability mapping into business impact. The capability map can be used to highlight the need for something to change, but without “change management practices”, those needs may fall on deaf ears.  Your stakeholders have to want to change.  Without the support of stakeholders the outcomes are likely to be limited or the necessary changes may not be implemented.

For enterprise architects or chief information officers faced with proving the value of capability mapping, this seems like a double challenge.  The capability map shows that “Program X” is needed, but now you have to get “Program X” to deliver value before you can claim that the capability map delivered value!  If someone in the business was already pushing for “Program X” (nearly always the case), then how do you claim that the capability map achieved value at all?

The nugget of truth here is to create a “bottom up” priority chart of suggested programs BEFORE applying the capability exercise.  Capability mapping will reprioritize your programs and may create new programs entirely.  If ANY of the programs that “move up” in priority, as a result of capability mapping, deliver value, you can make a legitimate claim that capability mapping delivered value.  This is simply due to the role that capability mapping had in getting the program funded and started in the first place.  This process (of creating a baseline roadmap and a new roadmap, delivering programs, and drawing a conclusion based on the value of prioritized delivery) can take two full planning cycles to take effect.  In many organizations, that means two to three years!

In many ways, depending on a program that you’ve prioritized to deliver value puts your skin in the game.  As a business architect, the scope of those programs has to be small, achievable, and measurable.  You have to care more about those programs, and that’s healthy.  It means spending time to ensure their success, because that helps ensure your success.

If your business stakeholder gives you partial credit for his program success, other business stakeholders will trust you to provide success to them as well.

The last step, as always, is one of the most important… telling the story.  You have to plan for this step from the beginning.  As you get programs funded that would not otherwise be funded, work with the key stakeholders to get their thanks, in writing, and their hopes for the outcome of the programs.  Work with them to establish baseline measures of the processes you are improving or the exceptions you are reducing or the costs you are hoping to cut.  Help them to build the case for why their program is successful, because that builds your case as well.

Making the case

As the program nears fruition, go back and remeasure and look for improvements that can be made as you roll out (this is especially effective in agile development, where you can deliver many times). Help your stakeholders achieve measurable outcomes.  Real numbers matter here.

Then, in THEIR presentations of the value of their programs, remind your stakeholders to thank you for getting them funded using capability mapping.  Remind them of the value you added, so that the people singing your praises are the people who achieved success.  Also, make sure that your stakeholders have the best possible presentation of value.  Consider using visual storytelling as a mechanism for securing that presentation.

Business leaders like seeing their peers succeed.  They will mimic success.  If your business stakeholder gives you partial credit for his program success, other business stakeholders will trust you to provide success to them as well.  You will have business leaders in your corner.  They are your most important weapon in the fight for relevance.

(this article was authored by Nick Malik and Charlotte Malone).