IT Funding Processes

Like many corporations, Microsoft has many business units, and many IT groups.  Enterprise Architecture has a lot to keep track of.  The big win, for EA, is in helping to decide what projects are funded.  Once a project is funded, the opportunities to guide, direct, and influence the project drops dramatically.  So let's talk about funding processes.  This post is generally about funding, and less so about EA's role.

Before I describe bits of our funding process, let me give a generalized definition.  Most folks will have something similar, but probably organized differently.

A funding process, in general, is a rationalization process whereby the needs of the business are weighed against the capacity and capabilities of the IT group.  Projects that overlap are combined, and projects that provide a low level of business value drop in priority, often to the bottom of the list.  The IT group accepts as much work as they can do, some projects are outsourced, other projects go away (and sometimes come back the next time around).  Companies will run through a funding process on a periodic basis.  Sometimes annually, sometimes semi-annually, sometimes quarterly.  At each iteration, all projects and all capacity is considered, so provisions have to be made for in-flight projects.

From that definition, there are bits of both "what" and "why."  The reason for having a funding process is simple.

1. IT is a constrained resource.  An IT group can only handle a fairly fixed amount of work every quarter.  Each project needs to be estimated from a standpoint of the number and type of resources that it will consume, so that one part of IT is not overbooked, while another part is wanting.
    
2. Planning reduces churn and makes an IT environment work.  People like to work less than 50-hour work weeks.  By accepting the right amount of work, and then setting expectations about when the work will begin, the staff in the IT department doesn't feel pressured to kill themselves to deliver "everything, all at once."
    
3. Good ideas come from many sources.  An innovation that can help the business compete may be described by many people, and come to IT in many different costumes.  If IT is lucky, they will recognize the overlaps and, if the process is engineered right, the projects can be combined to produce the business effect with a single investment.  Analogy: my wife and I both drive a car.  If my car starts to break down, it would be foolish for both of us to buy a new car without talking to the other.  We need one car.  Both of us saw that.  We should agree on what that new car will do, and go to the dealership together.  IT is the dealership.  The project builds the car.
    
4. The business doesn't always see the interdependencies between projects, or the need for infrastructure investments.  A funding process provides a way to surface projects that must be done before another project is started, all in support of a business strategy. 
    
5. Some ideas from the business should not be funded.  We've all seen the 'squeeky wheel' syndrome, where the person with the loudest voice got what they wanted, regardless of whether it was the business needed.  This happens in IT projects as well.  Sometimes the business will request a project, and they may even be able to justify it with an ROI, but the business shouldn't be asking, and the IT group shouldn't be doing it.  Why?
    
   1. No Fund reason #1: The project may take the company into an area of business where the executives are not interested in going.  Reality is that the most important decision a company can make is not "where to compete," but rather "where not to compete."  That decision, in a large company, may have to be made many times, or made once and enforced many times.  Sometimes, a good idea just shouldn't be pursued. 
       
   2. No Fund reason #2: The project may fail to recognize all of the costs, either the costs of change or the operational costs, associated with their 'business plan.'  It may look like the amount of revenue resulting will easily overcome the IT costs, but I've seen projects will small IT costs that couldn't break even, because it required massive retraining of staff or required three full-time business people dedicated to managing business relationships. 
       
   3. No Fund reason #3: The project may wildly overestimate the revenue.  This is simply optimistic business planning.  Let's say that you have a supply chain, and you figure that if you offer a service to your own suppliers, they will pay you for it.  So you calculate the benefits to the suppliers, come up with a 'price' for your service, and then predict, optimistically, that 80% of your suppliers will 'buy' the service.  What if no one buys it?  What if your suppliers have a lot of 'say' in other areas of the business, or you are a small consumer of their products, and they can safely ignore you?  What if the costs of change, on their part, are too high to get a benefit out of your service, even if they want to use it?  What happens to your return on investment if no one buys the 'product?'  I saw this one first-hand.  IT projects that are part of "new business opportunities" are part of a business risk.  They need to be vetted by the business at another level altogether, before IT gets involved.
       
   4. No Fund reason #4: Some ideas serve particular business departments in terms of cost containment or 'annoyance control' (as in: let's automate this task... it's really annoying to do).  There may be no impact on revenue, or quality of service, or turn around time.  It may be more efficient for the business to have people do the work.  It may be expensive, or simply wrong, to automate the task.  There may be compliance problems with automating the task.  These kinds of projects may be dropped because they are an example of people spending money to make their lives easier, not because it benefits the bottom line.  If the person pushing this kind of project wants it to be funded, they need to find a way to tie it to business strategy or measurables. 

So when we discuss a funding process, the challenge is "where does Enterprise Architecture add the correct amount of value."  What are we responsible for, and what are we supposed to overlook or leave to others?

The Enterprise Architect needs to be an agent that

• points out gaps where the IT group should be funding projects, but where projects are not appearing in the stream of requests, and works to get projects queued up. 
• points out overlapping requirements across projects between teams, and works to combine projects where it makes sense to do so.
• places specific requirements on specific projects where, doing so, moves the entire IT ecosystem towards a future vision that they have ALREADY created and gotten buy-off on.
• asks if all of the other compliance checkpoints have been checked off, but does not withold approval on the basis if another group failing to provide a check off (that is the EPMO's job). 

In addition, architects who are not working in Enterprise Architecture, but rather are aligned with the project teams themselves, need to add another layer of information.  They need to be agents that:

• helps 'vet' the operational costs for a project where those costs exist in IT or are necessitated by the tools.
• helps insure that the development, test, and deployment costs are correctly calculated and are including the costs of development that may vary based on training or readiness. 
• places specific requirements on specific projects where, doing so, moves a segment of the IT ecosystem towards a future vision that is aligned to, and supports, both the EA vision and the goals of the IT team.

There are interdependencies between stakeholders, of course, and politics.  That is part of a later post.  Just wanted to put out, on the table, the generic role of EA in a funding process, and ask you, gentle reader, if your company is organized similarly, or differently.