Nothing matters more than how the Enterprise Architecture supports the business
The Enterprise Architect must understand what the business is trying to do and what needs to be done to support it. The Benefit Ratio, Benefits gained / Costs Expended, should be a really big number. Benefits are gained by the business. Costs are expended by everyone in the organization and have initial and ongoing components. These measures can be total or marginal. Benefits are generally overstated and costs are generally understated. Be brutally honest in this analysis. If metrics are in place prior to changes being made, they can be checked afterward to determine the efficacy of the changes. If no metrics exist, they should be established and implemented as part of the change project. Make sure both benefit and cost sides are audited afterwards to ensure the assumptions were correct.
Becoming more business focused
Let’s start by acknowledging that most existing Enterprise Architects are senior technologists and are working on the IT staff. I’m there. You may always be there administratively but you don’t have to be stuck there practically. Here are my processes for establishing myself as a resource to the business leaders.
Do not spend all of your time in your IT work area
I do a lot of MBWA (management by walking around). I visit every business leader at least once per week and also talk with key managers and supervisors. What do we talk about? Their problems. The only problems of mine we discuss concern what I need to solve their problem.
Never propose a project to the leadership team yourself
I view myself as a business problem-solver but I don’t run any aspect of our real business. I am a staff person in a staff role in a staff function. I always team with the leader of a line function and have that person propose the project. The project outcome will be hers to bear so if she’s not bought in, why should anyone else on the leadership team buy in either? Besides, your funding will be coming from her budget for business improvement projects.
Don’t be afraid to re-propose a better, late arriving option
I worked on a rather complex problem with the head of one of our business divisions. I had IT build a proof of concept system to prove we could do the hardest part of the solution. The business leader and I successfully sold the project to our leadership. By the time of the next leadership meeting, the business leader had talked with a vendor we used and determined that they could do a similar project and get him further along his business improvement plan than our project result would do. We spoke with the vendor and I had to concur. At that ensuing meeting, the business leader described the new project and its benefits. I told the leadership that we should change projects. They agreed. I didn’t lose any points. I gained points for looking out for the best interest of the business.
So get out of your office and go talk with the business leaders. Team up with them and work on their problems. Gain a better understanding of what your enterprise really does.
The Benefits Ratio
The Benefits Ratio is just a simple way to present the outcome of a Cost/Benefit Analysis. Go back and read the first paragraph of this page because what I state there is true.
Project benefits are generally overstated
It is just human nature to take a very rosy view of the good any project will accomplish for the enterprise. Sales will soar. Productivity will go up to the point two people are now accomplishing the work done previously by ten. You can still make those projections. You had better be able to prove them. The best way to prove that you and your business partner believe those projections is to offer a contract that they will be attained. You need a concrete amount and a deadline. The benefit should be stated that at a defined point from the final implementation of the project changes the enterprise will realize a defined amount of benefit. If the benefit is an increase in sales, state the amount. If the benefit is a decrease in costs, eliminate the costs from the budget for that period and following. The business will be expected to achieve the benefit or the business leader and the enterprise architect will have to explain to the leadership why they failed to deliver.
Project and on-going costs are generally understated
There are two dynamic at work here. First, there is that tendency toward rosy projections again. The project team is certain that they can deliver the solution early and under budget. After all, this is a great project and everyone is motivated to do great things. Somewhere between here and the final implementation, the team will be slogging through the “pit of despair”, polishing their resumes, and not showing proper focus on the things to be done to bring the project home. Timeframe will slip and costs will grow.
Then there are those “missed” cost increases in other areas of the business, most likely in IT. There was no plan for the increase in complexity to the IT systems or for the increase in maintenance costs after the project is implemented. There was no mention that another business area would have to change what they were doing to complete the work that would be passing into the new process. This is just cost shifting. Your business leader might think it’s fine but the affected business leader will not. Especially so since he wasn’t warned it would happen.
You do what you measure
The best way to ensure that something is being done inside a large enterprise is to create a metric and make the attainment of that metric a goal for everyone. This is a very objective point on the annual review or other discussion about someone’s future in the organization. Every initiative should have a metric that can be used to see whether the initiative is meeting its goal. I discussed that idea in the benefits section but this is more far-reaching. The important thing to remember is that the metric should be a measure of accomplishment, not a measure of activity. This is a fatal flaw in many metrics used in businesses today.