Measuring Enterprise Architecture return on investment

Explore The Enterprise Architecture Toolkit

IT projects have always competed for limited funds, and obtaining top business executive support is a necessary but not sufficient tactic to ensure approval. Funding must be allocated to projects that are more aligned with company strategic direction and more likely to leverage business opportunities (for example, increase market share, beat competitors, provide organizational agility, enable product reuse, fit existing resource availability). Selected projects must produce value sooner or be able to generate higher long-range recurring benefits (for example, increase revenue, provide higher-quality products, decrease costs, improve service, shorten time-to-value).

Generally, companies try to justify projects on tangible benefits (such as quantitative costs and benefits), but even when there is no reduction in staff, significant benefits exist in projects that enhance customer credibility, increase productivity, or open up new business opportunities. IT managers must measure these intangible benefits to justify project selection, determine breakeven dates, and drive business strategy.

Measuring Enterprise Architecture project return on investment (ROI) is a significant challenge when, during the four or five years often needed to recover project costs, the project implementation and subsequent changes alter processes, roles, procedures, tools, data access, hardware costs, product features, customer behaviors, and even the original system functions. Most organizations are not quantifying recurring benefits and allocating them back to one or more projects. Enterprise Architecture ROI estimates are often based on current performance assumptions without an understanding of the impact of these changes. The real value of Enterprise Architecture ROI estimation and measurement is in examining all the costs and benefits to determine business impact (operations, staffing and opportunities, for example) and shape company strategy.

Collecting Measurements. IT projects are measured more than any other IT portfolio components (for example, predicting demand, planning strategy, eliciting requirements, justifying priority, allocating funding, estimating benefits, sourcing resources, monitoring activity, building components, tracking issues, testing outputs, reporting outcomes, controlling operations, managing satisfaction). Risks, strategy, and estimated benefits must be added to typical IT project size estimates (i.e., effort hours, product size, team size), schedules, and costs.

Managers must estimate project ROI based on historical performance and anticipated changes before a project is selected, executed, and deployed. The following cautions apply when considering ROI calculations:

Estimates must not be based on assumptions that are manipulated to reach a desired result.

• Guesses need rationale that fits the organization's performance history and risk culture.
• Just as intangible benefits are included, all associated costs must be estimated.
• Costs and benefits must be matched for the same scope. For example, when measuring the ROI for application management and counting benefits for an application, only the costs for the resources that the application uses should be counted.
• Spending time evaluating future impacts is a valuable exercise in scenario planning.
• It should not be assumed that once a project is selected, there is no need to measure the ROI. There is tremendous value in the process of ROI measurement (for example, profitability assurance).
• Projects should be justified based on business impact, not technology appeal.

Enterprise Architecture Toolkit: the definitive resource for Enterprise Architecture projects