While I don’t recommend any specific technology business management tool, I have lead two separate Apptio implementations. Each program had slightly different goals, but some of the challenges I faced popped up in both instances. Here are some lessons learned:
It’s important to realize that no tool is going to fix dysfunctions in your organization. This seems like an obvious point, but when a company is making this type of investment, there is a tendency to look at the tool as the cure all. A project like this can galvanize the function or it can lead to further division. It’s really a function of your culture.
Data is at the heart of everything you are trying to accomplish. Having accountable data owners will not only speed up the project but will ensure you have a culture of accountability. Make sure you have dashboards that highlight poor data quality. Use those dashboards to drive responsibility.
Your data will never be clean enough to utilize all functionality in the tool. When you are trying to “sell” the tool internally, there will be dashboards and modules that some senior folks will fall in love with. Don’t over promise before you understand the deficiencies in your data set.
Don’t make too many changes at once. This seems counter intuitive during a transformation project but you need to separate the impact to allocations driven by the engine itself from the methodology changes. Otherwise, validation of the output will be much more difficult. This isn’t to say that you can’t setup your new world in an ideal state; just don’t blame unintended consequences purely on the tool.
Get buy in up front. Make sure your internal stakeholders realize that a project like this will drive change. But that’s what we’re going for, right? Opinions about change in an isolated room can be very different than the real world impact of those changes. Your stakeholders will eventually need to defend the tool. Make sure they understand they are accountable too.
Keep the vendor AND your own people on track. I’ve seen very aggressive implementation timelines given to Apptio rollouts. Those are possible if your own people are working as hard as the vendor. Unlike the vendor, your people have day jobs that can redirect focus away from the goal. This is usually the biggest culprit when it comes to delays.
Decide on a testing time frame, and double it. Most implementations endpoints are trying to coincide with a new fiscal year. As delays happen during the configuration cycle, testing periods suffer. I warn you against this. In most Apptio rollouts, there are separate Actuals, Budget and Forecast modules. Make sure you have time to test all of these appropriately. There is a tendency to think that budget and forecast will behave the same. This isn’t a given. Give yourself time.
Document everything. The vendor can document how the pipes and plumbing work within your model. They can’t document the thought process behind the decisions that have been made. Assume that your methods will be challenged in the future by others that have reasonable points of view. Also assume you will have turnover within the group responsible for implementation. Without documentation, you be working blind a year from now.
Don’t sign off on anything until you are completely satisfied. As the project nears the end, Apptio will push for signoff so their team can move to other billable projects. That’s not your problem. If you discover issues down the line, you’ll end up paying out of pocket. Be a hard ass and make sure you are covered.