This Blog Has Moved to Forrester

Please continue to follow this blogger at blogs.forrester.com/brian_hopkins. Same material, new location. See you there!



Sunday, January 16, 2011

The Essential EA Toolkit Part 4 - An Enterprise Roadmap

This is the fourth and final part of my “The Essential EA Toolkit”  series covering some recommended tools for Enterprise Architecture Teams. By "tools" I mean a few well-executed deliverables or processes that contribute enormous value to the enterprise. These are not technologies; they can be developed using typical office productivity technology and perhaps a collaboration application such as SharePoint. Before I start, here are links to the first three:
In conclusion, the final tool is the Enterprise Roadmap...
An Enterprise Roadmap is the Linchpin for Transformation
The economic collapses of the 2000’s left a profound effect on businesses that includes a revaluation of how resources are spent on technology. As a result, IT budgets are lean, there is renewed focus on realistic business cases for investment, and CIOs recognize old ways of doing business will not work in the new economy. A mandate to transform is the legacy of these trying times.
Achieving a transformed ‘future state’ requires a tool to guide and govern day-to-day resource investment decisions - the Enterprise Roadmap. Roadmaps both compel us to towards the future and provide a basis for evaluating enterprise investment decisions required to get there. They are fast becoming necessary, and organizations without one will soon be left at a competitive disadvantage.
Good Roadmaps Have four Common elements
Besides a time-phased plan of action, good roadmaps have four other common elements:
  • Blueprints & Business Scenarios define a compelling future state. In order to be successful Roadmaps must compel us to the future state - no organization will maintain the discipline required for success without these. ‘Blueprints’ form the basis of our vision, and are created a various levels, from business friendly ‘sketches’ to data, application and technology focused details. Business Scenarios complement Blueprints by describing the desired outcomes and identifying key people, process and technology changes required to achieve them. Blueprints and Business Scenarios cross reference each other, clearly telling the story: “If we do these things, we will get to where we want to be”.
  • Complexity is simplified by defining ‘Enterprise Programs’. Large organizations are guaranteed to have many needs, competing agendas and a legacy of applications, technologies and desired projects. These challenge roadmap development by adding complexity. The best Roadmaps identify a few enterprise strategic themes, then rely on ‘Enterprise Programs’ to execute the appropriate steps. The old adage, ‘if everything is important, then nothing is’ rings true - good Roadmaps clearly identify important strategic goals and focus on attaining them. 
  • Key Performance Indicators measure success and prevent failure.  Many external factors can influence business performance, therefore non-financial Key Performance Indicators (KPIs) are necessary. The best roadmaps assign non-redundant KPI goals to each Enterprise Program. For example, a ‘Common View of the Customer’ program should set data quality measures to assess confidence that there is a single view of every customer. Other programs should not also target customer data quality as a primary benefit. Programs must take early action when desired outcomes will not be reached. History is littered with failed efforts that recognized a different approach was required too late. Close monitoring of outcomes is a must to prevent Roadmap’s from derailing.
  • A high-level financial model provides insight and direction. A high-level financial model is a final important component of a good Roadmap. Executives must be able to see quantified financial impacts in order to make large-scale investment decisions that roadmaps often require. The best models define program and project benefits to KPIs, which themselves are linked to expected financial performance; results are recorded over time using accounting standards to generate cash flow and expense projections. Project and program classifications allow analysis of cost and benefit by strategy, capability, process and line of business. Classification of project cost and benefit yields insight, answering the question, “are we investing in the right things to achieve what we want?”
Developing a Roadmap is Easy, The Hard Part is Successful Execution
Developing an Enterprise Roadmap is a difficult task, requiring a board-level mandate to transform and a significant shift in culture. Many organizations struggle with the necessary mindset as well as the format, employing management consultants, facilitated workshops and multiple attempts.  Because of the sheer effort to produce one, businesses can easily over self-congratulate before any results have been recognized. The bottom line is that a Roadmap unexecuted or failed is as bad as no Roadmap at all because of the time wasted and the political fallout of such a failure - stay focused and take the following steps:
  • Maintain business ownership; establish accountability and governance. Any successful Road-mapping effort required business ownership to complete; however fight the temptation to execution over to IT. This must not happen. Enterprise Roadmaps are tools to make business decisions about business and technology transformation. Keeping the business in possession of the roadmap requires enterprise accountability at the highest levels of any organization. Establishing clear decisions making authority and assigning results to executive performance requires an enterprise governance mechanism - this may be centralized or distributed with clear lines of responsibility. A Roadmap Execution Office, either as a single entity or virtual office, will be helpful.
  • Implement a Benefits Realization capability. Successful execution of a roadmap requires methodical, consistent measurement of KPIs and translation of those into financial measurements when appropriate. Often the best way to accomplish this is through a Benefits Realization capability. I say ‘capability’ because there are a mix of people, process and technology approaches that work. The commonality is that they all assign KPI to executives and programs, ensure that projects build out facilities to measure performance, and feed the results to enterprise reporting so action can be taken if expected outcomes are not achieved.
  • Execute disciplined information and change management. Execution of a roadmap involves collecting a lot of information about the your organization - strategies, projects, process and technology blueprints, financial and KPI projections, etc. This information will change overtime resulting in many ‘.ppts’ with different versions of the Roadmap. Besides preventing confusion as changes happen overtime, the biggest challenge is ensuring that the right information is brought forward to leadership for governance decisions. A roadmap Execution Office, proper change control processes and some technology tooling will help ensure the integrity and quality of the roadmap source data.
  • Exercise patience and a first-things-first attitude. Roadmaps can span varying lengths of time, but generally target three to five years. Undoubtedly, there are some ‘foundational’ things that must be done in order to achieve the desired benefits that are part of early project work, and often these efforts show little in the way of ‘hard’, bottom line impacting benefits. The existence of foundational work means that the roadmap may not show dramatic benefits over the first year or two of execution; in today’s economy, this can be very hard to abide. While roadmaps should have ‘quick hit’ projects that deliver short term benefit in an effort to partially self fund, tactical investment is not the point. Successful organizations must be committed to the end-game of the roadmap and have the discipline and patience to invest in foundational things first.

    No comments:

    Post a Comment

    About Me

    My photo
    Brian has 21 years of engineering and technology leadership including 12 years as an IT professional. As an Enterprise Architect, Brian has been a leader in establishing Enterprise Architecture Practices in both the Financial Services and Defense industries. He has led the development and implementation of information management strategies, established architecture governance processes, and led multimillion dollar, multiyear program teams. In addition, Brian has extensive experience with web interoperability and data exchange standards established by the W3C and OASIS.