Volkswagen of America: Managing IT Priorities

Team Eight's Thoughts and Answers to Each Question:

a. The IT budgets are controlled by an “IT steering committee,” or ITSC. This was a group of senior business and IT representatives, and they were responsible for approving IT project selection and prioritization. However, Dr. Matulovic also has some additional “pull” in terms of budget allocating decisions, in that even though the process is for the ITSC to make the priority list and approve projects, he still has the capability to make special exceptions, find additional funding, or reallocate funding to other projects if he so decides. He also has control over the $16 million that was set aside for “stay in business” IT initiatives, and that could be spent at his discretion.

It is also important to note that the ITSC fell under the realm of the Executive Leadership Team (ELT), so within the ELT, the group of the ITSC made decisions on IT funding.

b. First and foremost, the new process, if simplified, could make a lot of sense, but the many, many committees, groups, and teams, all with their own acronyms, lead to a very high level of confusion and unclear division of roles and responsibilities. This excessively convoluted organizational strategy did not help make the IT funding process simple. IT funding decisions are complex to begin with, but the organizational structure further added to the complexity.

Our team does feel that the overall outline and process of making IT funding decisions makes a lot of sense, and really analyzes all aspects of each proposed project, as well as how each project fits in with the overall goals and strategies of the company. In particular, we thought the categorization of investment types (stay in business, return on investment, option-creating investment), and categorization of technological application types (base-enterprise IT platform, enterprise applications, customized point solutions) were very intelligent, well-thought out ways to classify each proposal, and this system really gets to the heart of each project and where it fits in with the company’s budget, bottom line, and strategy.

We think some appropriate criticisms of this process was the way that projects were re-categorized late in the game, how projects could get pushed out year after year based on completion or delays of other projects, or how projects were presented (or sometimes, misrepresented) to align with enterprise goals, to increase the chances of the project getting funded. This “tricking the system” was a major downfall to this decision-making process, and did not result in an honest look at each project and how they fit in with the goals of the company. However, the way this decision-making system was set up, almost invited people to “trick the system” to get their projects funded.

Given all of that information, we do believe that this system is better than the previous system. Many people are involved in the process from across the company, so each department and group is represented, which is critical to any IT funding decision-making process. Also, the way each proposed project was categorized based on those six criteria mentioned above, was an excellent way to approach analyzing each proposal. We feel that each proposed project was fully scrutinized and evaluated, and looked at to ensure alignment with overall corporate strategy. The entire process, while it did have some flaws, was far more in-depth and comprehensive than many other companies, which is very positive.

c. We do not feel that the money set aside for stay in business projects is unfair at all. Stay in business projects are just that – necessary for the company to stay in business. While some people in the company may have been angry that their projects were not funded, it is safe to assume they would be far more upset if the company went under due to not having the funding for IT projects related to legislation, business continuity, or some other type of mandate. It is understandable that people were upset that their projects were not selected, but the stay in business projects should remain separate, because without them, the company could not continue to operate, so they should not be viewed as “competition” for funding or similar.

Budget should be set aside for these stay in business projects, to ensure that there is money available to complete them. If money was not set aside, it is very likely that the funding saved from not setting aside money would be used up by the many other IT projects that people wanted approved. If that happened, there would be no money left over to complete the stay in business projects, and the company would be susceptible to legislative action, or other negative events that would seriously threaten the company’s viability.

d. We recommend that Matulovic take into consideration each complaint and special-treatment-request, and think about how that could impact the new process. While the process for the current year cannot be changed, if people have legitimate complaints or concerns, solutions could be integrated into the process in future years. While this does not solve people’s primary complaints about their projects not getting funded, it will go a long way if they feel their concerns are being heard and solutions are being worked into the system in the future. One of the key problems with this process is that the people who did not get funded are feeling angry, unimportant, and rejected. They are more likely to resist this process in the future if their concerns are not addressed immediately. Matulovic should listen to the thoughts and opinions, and ensure that people understand he will do his best to address those concerns in the future.

We also recommend that Matulovic stick to the process and not try to re-work anything at this point. That would only serve to diminish the importance of this process, and lead to people not respecting the process in the future. Without employees’ support, no program or process can be successful in any company. People must also understand that the process cannot be manipulated simply by being the squeaky wheel after decisions have been made. When the committee makes their decision, that decision should be final. However, if by any chance, any additional funding is left over, Matulovic should analyze where that funding should be spent, such as on some of the smaller, below the line, unfunded projects. These projects could be analyzed by the team to see where they fit in with the company’s strategies, and which projects, if any, can be fit into the budget that year.

As such, there is not a lot Matulovic can do regarding the unfunded supply flow project. He must try to maintain the integrity of the new decision-making process, and cannot backtrack and reallocate funding for this initiative. We recommend Matulovic move forward with some of the options presented in the case, such as helping the team make an argument for funding the project through alternative sources as well as using this project as an argument for adapting the decision-making process in the future by showing how this project was not well-served by the new process.

e. Any IT project should go through a cost-benefit analysis prior to actually deciding to move forward with that project. While doing this analysis, it is critical that benefits are not overestimated and costs are not underestimated, as well as keep in mind that some IT costs are hard to hypothesize – the true cost may only be unveiled while the project is in process.

IT funding decisions are unfortunately not as simple as a cost/benefit analysis and cannot be made based solely on that information. IT funding decisions should be made with the input of people across the company and in different functional areas. All departments within a company should be represented in the process, and should be able to voice their own needs and opinions. Of course, the CIO and other IT representatives should be part of the process, so they can weigh in on how much each project will cost, how feasible it will be, and how much time it will take to complete each project, etc. Each project must be fully justified and have some significant benefit to the departments who are requesting the project.

A list of IT project requests can be made based on this cross-company input, and upper-management representatives from across the company, including the CIO, should prioritize the list based on the costs, benefits, and alignment of each project with overall company strategy and goals.