For the last few weeks, I have been working on my FY09 budget that runs from July of this year through June of next year. It can be quite the challenge to predict the needs of the future year especially when you try to take an entrepreneurial approach to IT. There are the obvious items like end user computer upgrades, upgrades to the server backup infrastructure, and annual software licensing costs. There are also things that you know you are going to do but are hard to budget due to not being 100% defined. For FY09, that project is going to be a CRM for the two tech transfer offices. I know some of the features, but I am still trying to decide between using an incremental and iterative process to build the application internally or buying something off the shelf. The last part of the budgeting unknown are the things that I cannot currently predict or foresee. That's where the innovation budget will come in.

Each year I build a small portion of the budget for the incidental expenses like replacing broken hardware or small one-off software purchases. This year though I am going to add a special line item called the innovation budget. A little inspired by Google in how they give their employees time to work on whatever projects they want to do, the idea of the innovation budget is to give people in IT a funding source for being creative to solve real business problems or capitalize on business opportunities. While the line item will not be enough to do large projects, it will be big enough to try out at least a couple prototypes for a couple thousand dollars each. In order to access the funds in the innovation fund, an IT person will have to present a business case for the expenditure and get at least one non-IT person to sign-off on being willing to work with IT to try it out. Part of the business case will also need to include at least one metric of success and thoughts on whether it could be deployed to the whole organization. If I think the case is legitimate and the funding enough, then I'll sign off on the project going forward.

The most important aspect of the outcome though will be that failure is completely acceptable. Even if a prototype is never achieved or fails to meet any measure of success, it will still teach us something about IT and our organization. By making failure an acceptable outcome, I am hoping that IT and others in the organization will be willing to take a chance on making a significant breakthrough on how we do our work. A similar concept seems to have worked at Google at least.