At John Hancock Financial Services Inc. we’ve improved the process by incorporating a view of our application architecture. The benefits have been numerous; I’d like to share with you how it works.
John Hancock is a large insurance company with many lines of business. IT is centralized, but there are application development areas facing each business unit. Because IT is centralized, the budget for business application projects is centrally accounted. And because there are so many business areas, each with its own IT applications and development needs, the process for identifying and committing to projects was traditionally a free-for-all.
In the annual planning and budgeting process, business units would provide lists of five, 10 or even 50 projects they wanted to undertake. The total number of projects company wide would be several hundred, and budget estimates were two to three times what was available. Further, the assumptions underlying these estimates were never clear. The result was a painful annual planning and budgeting process and a lot of surprises during implementation of the projects that got approved. No one was happy with the existing state of affairs.
Three years ago, John Hancock established an enterprise program office to try to tame this free-for-all. EPO program managers and business analysts would work with business areas and IT development groups to collect, assess and prioritize business project proposals so that senior IT and business management could then make the funding decisions. Standard proposal templates identified proposal goals, benefits, costs and ROI; this gave management better capability to make “apples to apples” comparisons.
Unfortunately, that process didn’t make it much easier to wade through the hundreds of proposed projects and develop a plan that made business and IT sense. We knew that many of the business proposals overlapped and that there were synergies among them that were being missed. For example, we found that we were funding separate workflow initiatives for each sales channel’s case management processes, and that these initiatives used very different products and technologies; in some cases we had to outsource the projects because there was no internal expertise. On top of that, none of the systems was capable of being expanded to support other sales channels. (As you might expect, we have since replaced those initiatives with a single system for all channels.)
Projects still took the IT infrastructure group by surprise, and this surprise would ripple back to the application development areas in the form of unexpected costs and project delays. The process was not conducive to well-architected solutions because the architects got involved with projects too late after they had been approved and funded, with budgets established and delivery commitments made. It was a frustrating situation.
Enter architecture
Eventually, we decided to reorient our architecture efforts toward providing the context and facts to guide planning decisions. But first we had to do some work. John Hancock already had a well-defined technical architecture, but it was focused on technology and tool standards, and had little connection to business applications. To supplement it, we developed several architectural deliverables.
– A model of the business that identified key processes, constituencies and business capabilities.
– An inventory and map of the current state of our large business application portfolio. We then overlaid that on our current technology infrastructure.
– A target state for the business application portfolio.
With these in hand, we engaged in the next year’s annual planning process. We mapped the proposed projects to the business model to see how projects related to each other. That allowed us to identify project overlaps in terms of common or related business functions, such as data marts with a high degree of common information. When it came time to prune the list of proposals, we could suggest consolidating projects so that one single effort could support more than one business need. The overall economics of the consolidated projects was improved more business benefit for a given unit of investment and so was their priority for funding. IT resources could be focused on a smaller number of projects, resulting in higher quality and more reliable delivery, as well as a reduction in subsequent application maintenance.
Similarly, we uncovered many situations in which business areas were proposing projects that overlapped with applications already existing in other areas. Because our IT groups worked in silos to some extent, they would not have been aware of the redundancies. We can now identify those cases and recommend either building on the existing applications or slating them for replacement.
Our architecture approach allows us to proactively assess the fit of proposed projects with the current technical architecture and provide early on a critical heads-up of the risk or cost that will be involved when the fit is not good. Software upgrade plans, meanwhile, can now be compared with the proposed projects to see where they could affect a project’s timing or the cost to perform the upgrade. The project’s estimated cost is then adjusted to reflect this.
We also found that we could use the business model to communicate to business management how much money was being spent to provide a given set of business capabilities. For example, we now report what percentage of our total discretionary spending is applied to new business processing capability and what percentage is spent servicing existing customers.
Better-laid plans
What’s the net result of all this? Three years ago, the annual planning process gave IT little opportunity to do more than react to business proposals. Architecture was viewed as something useful only in theory and harmful in fact. Happily for all concerned, that is changing. Business managers are beginning to see how the architecture group can help solve their problems, so they request our input more frequently. The IT development managers are including the architects in their planning discussions with the business because we help them provide better responses to business requests. Infrastructure concerns are better represented, and infrastructure service groups are better prepared for the funded projects when they start.
The annual planning process is still arduous, and may forever be. But the results have improved. More than 80 percent of all IT projects are now delivered on time and on budget, and they meet our company’s business needs. Furthermore, we all have greater confidence that the initiatives we undertake will provide the needed business value.
Alex Cullen is director of the Architecture & Design Competency Center at John Hancock Financial Services in Boston. He can be reached at acullen@jhancock.com.
