Wednesday, September 24, 2008

HPT Infrastructure: Top 5 wastes of an infrastructure consultant’s time

Top 5 wastes of an infrastructure consultant’s time

There are many reasons a project can go over-budget. In the world of Hyperion Infrastructure the most common ones can be avoided. If you take the time to completely understand all the tasks needed of them before your infrastructure consultant arrived, you would save a great deal of money. Or, perhaps, be able to spend that time learning about your environment and its care and feeding.

1) Download the software before the consultant gets there.

When in doubt, download it. If you download something that you don’t need it is ok, but if you don’t get everything you pay for a consultant to watch a status-bar!

2) Create your databases and give the proper permissions.

Normally you'll receive a list of Databases (or user/schemas in the case of oracle) along with a list of permission. Make sure you follow this, in the case of FDM there are special requirements that need to be met.

3) Order the servers AS SOON AS POSSIBLE.

I know that no-one wants to have capital expenses depreciating on their cost center any longer than they have to. But please remember that your IT department is likely to be very busy with everyone else’s requests. Furthermore next day shipping doesn’t mean that the vender has the servers in stock or that they are even built, it just means when they get around to shipping it, you’ll get it the day after. I've honestly been stuck waiting (and billing) until Wednesday of the *SECOND WEEK* for equipment to be ready. My record before that was noon on a Friday (in that case we were merely waiting for a network cable to be plugged in). In any case I cannot stress enough ORDER YOUR EQUIPMENT EARLY PLEASE!

4) Ensure that you have the appropriate meetings with your infrastructure consultant ahead of time.

Only you can know what’s appropriate. I’ve had simple customers want 10 meetings about something simple (waste of your time) and I’ve had extremely complex customers with complicated (and battling) political factions have only one short meeting. If you have 1 it guy that can do it all, have one good meeting. If you have a complicated it department (even if the environment isn’t) get all the parties involved. It's NOT going to help anything if we finish an installation with automatic deployment, get ready to go live, and find out that your IT department won’t support you because it has to be manually deployed with custom ports!!! This HAS HAPPENED more than once!

5) Ensure that your IT department is on-board with the installation.

I've been at customers who ticked their IT department off so badly that they wouldn’t provide simple DBA support. I can handle this if given the keys to the kingdom, and most likely if your IT department behaves like this your environment will be better off with me doing everything anyways. However, I will one day leave. While I very much appreciate all the after hours billing, you won’t appreciate waiting for me to be done for the day with my present client so that I can put your production environment back together after someone mistakenly trashed it!

6) Get involved with the installation (you didn’t think that I would actually stop at 5 did you?)

The preferred method of installation is for me to build the first environment so that your applications consultants (or internal people) can get working/testing ASAP (remember the applications consultants are billing you too). This is the fastest way to bring an environment up. But on the second installation PLEASE sit with me in a conference room (bring a projector please) and we'll do the installation with you driving. Don’t get me wrong, I’d love to bill you every single day to Webex in and handle your minutia, but it's far more efficient if you understand your environment and can handle these things by yourself. I suggest having at least one IT person in the room and your Hyperion support person as well. This way there is always at least 2 people who understand exactly what Hyperion is doing, and can come to the rescue at quarter end when the CFO is shaking his/her fist at you because they don’t have the numbers to report.


pp

Tuesday, August 19, 2008

HPT Implementation: hyperion planning users will use the webforms, really?

HPT stands for hyperion planning tips

**start of disclaimer**
Contrary to my statement above, webforms can be a very useful data input tool. This blog entry is an attempt to address a shortcoming every project must address. The implementation of hyperion planning where existing excel spreadsheets are turned into web forms does no one any favors. The entire budgeting process should be analyzed and where possible turn the budget data entry items into driver based metrics (ie. some expenses go up as headcount goes up, etc.). By creating more of a driver based budgeting tool, users can get into the mode of testing out different versions in the same time it might take to perform the raw data entry task of the old system.
**end of disclaimer**

Bottoms up budgeting really does mean bottoms up.

With many implementations, an initial r0llout is to a regional head. They'll do the budget for all their facilities. That's the thought until they realize they have to go into these webforms for every location that they manage. So, if they are in charge of 80 locations, someone is going to have to open a web form, select a dropdown, select go, then update the web form. Then hit save. This process multiplied by 80 or 100 is overwhelming, especially when the web form has 100 rows on it. At one client, I let them worry about this until I let the cat out of the bag and showed them the excel addin. This was on system 9.2.3 where smartview wasn't really "up to snuff". The only problem was they saw that "crutch" as the panacea to all their problems. Fortunately I was able to convince them to use this for only certain metrics that were drivers for the system by location. Smartview could help make the web forms less painful but make sure you prototype your solution before showing it to the customer. There is definately a learning curve with this tool. There is a reason why the essbase security role was added to planning in 9.3.1.

Hyperion Planning users: will your users really use the web forms?

This question really need to be addressed at the beginning of the project and not at the end. I've seen multiple (many) occasions where a system is not only designed but built with the thought that web forms will be used exclusively.

Watch out. When that UAT session takes place be sure to duck for cover when users realize they will have to retype their entire budget into a web form. All the work that has gone into tweaking their spreadsheet budgeting is now thrown out.

For some customers this can be forced upon the users but for most companies your controllers and other users are already swamped with work.

This leads us back to that good old trusted essbase - excel addin. Using this tool, you can create templates that can be slammed into essbase directly without the overhead of planning (web forms, smartview, app servers, web servers). The drawback however is that this is not something that you can hand out to your users on the eleventh hour without customizations. Due to the freeform nature of the tool, some training definately needs to happen. It's even relatively easy to add some custom vba to lock it down but this is development. Development takes time. This data entry method should really be vetted out during the design phase and not the UAT sessions.

In closing, there is nothing wrong with web forms. With the new composite form they can be really powerful. You can have the top half show a high level total and the bottom half could consist of various drivers. After updating a driver you can see the results on the same screen without having to change forms.

This topic was just one of many reoccuring themes that every hyperion planning implementation needs to address.


hj

Tuesday, May 27, 2008

HPT Implementation: taking care of your resources...

As planning projects are getting larger and more complicated it's more important than ever to have the right resources. One key to getting the right resources is to provide 4 day workweeks and avoid at all possible the working on weekends. I haven't been on a project yet where working a weekend straight through will result in a successful project. There is usually so much input required from the customer that having consultants working crazy hours without end users to validate the system is just wasted money. In every case that I have witnessed, the need for this type of work schedule was due to changing requirements from the customer that were somehow missed (either the right questions were not asked during creation of the design document or the customer had new ideas after the system was already designed).

If you're with a consulting firm and this is not a #1 initiative for your consultants then your consultants will be leaving very soon. Your competitors are offering this if you fail to. If you're the final customer your pain will be even greater because it is very difficult getting hyperion resources hired.

Let's say you get phase 1 of your project complete and you're ramping up for phase 2 only to realize that all of your resources (employees, contractors, etc) have all decided not to follow you into battle. Think how much talent the customer just lost by having all the developers walk out the door? Was it really worth hitting that deadline to lose your entire technical team? I was at a customer where 3 employees quit within a week after being fed up with working xmas, new years, and endless weekends. The real pain point that that these employees were there for the duration of the 3 year project only to leave right after go live of phase 1. The best part of that project was that the 3 project sponsors, who didn't work any weekends and who were responsible for changing scope got big promotions for hitting their live dates while some of the employees on the team didn't have jobs after the project was over.

I've been present at a client when the "style" was to use profanity at my team. Profanity in and of itself has never really bothered me but it's a little different when it's directed directly at you with the words "this is unacceptable. You're all going to be bleeping fired." It's a little dishearting to hear these words on week 2 of a 5 month project. How motivated do you think we were to go over and above? How much extra stuff do you think snuck into the scope without a change order request?

hj