Hyperion Planning Implementation Team Makeup

For a typical Hyperion Planning project (3-4 months) I believe the following resources are sufficient. This is assuming the etl duties are owned by the customer. This is often not the case and the
I believe most Hyperion Planning projects can be implemented with a team consisting of the following makeup:

customer: 4 resources
#1 part time project manager
#2 subject matter expert business
#3 subject matter expert business
#4 tech / infr resource
#5 erp system resource (in charge of extracting necessary data)

Now on the consulting side (consulting team) this would be my breakdown if I had a choice (3 necessary, 4 optional):

#1-part time project manager (not the customer) that is there during the presales phase. This resource is onsite full time in the beginning and then tapers off to 8-12 hours a week. They don't have to be an expert on Hyperion Planning but this person should know the basics. The goal of this person is to be MR Change Control (or MS). On a recent project, my "part time project manager" played this role to such a tee, the meer mention of his name would stop all discussions of new functionality that was deemed essential but not discovered during the design phase


#2 -planning architect
It's good to have someone that's performed at least 5 Hyperion Planning implementations. But if this person is not a hard core essbase guy then you'd better have a ringer as your #3.

#3 essbase architect
-essbase architect. I'd much rather have someone that knows essbase hard core than a 2nd chair in planning in this role.

#4 (optional) junior resource
-someone to build web forms and reports

Here's a key point. The more seasoned and senior your resources, the fewer bodies you'll need. I once heard about a project where recruiters said they needed 14 hyperion planning resources. I ended up passing because they were a little stingy on the rate and something didn't seem right. It turns out that the project was shutdown after a few months. I'm not sure the scope of the project but there are only so many consultants that can work on a planning system at the same time. There's only 1 outline per plan type and only 1 person can make changes to the hierarchies at any point in time. I just can't see how to coordinate that many consultants with business requirements that always change on the fly.

In choosing your resources for your project team take a little time to read the resumes of the actual worker bees that will be showing up. Many times the tech guru that was present during the dog and pony show is not available when the project actually gets started.

Also, when choosing candidates, you're much better off getting a seasoned essbase developer (4.x, 5.x 6.5, or even 7.x) on the team than you are having 3 additional planning resources or even requiring system 9 experience. (have you guessed I'm an essbase guy. Yes, I'm proficient in 9.3.1 p1 but as stated, I'll take a real essbase developer over someone that's implemented planning 9 times. I can teach planning to an essbase guy in under a day but you can't teach essbase in 1 day) System 9 experience on essbase doesn't really require too many additional skills. I'll write about this later. "what you need to know about essbase to retool up to system 9".

In closing, there are too many Hyperion Planning projects going south out there. Why are they having problems? Because their database size is out of this world. In most every case, having a real essbase developer on the team (the gruff type that tells you when you are being stupid) could have provided insight as to the feasibility of the design months before go live. Remember the underlying database is essbase. All essbases rules of thumb apply (block size, database explosion, calc times, etc.). By having a hard core essbase developer on site, you likely could have even changed direction (scope, functionality) to hit the live date. Given the fact that there is currently a resource shorttage of system 9 folks out there, if I were a hiring manager, I'd start paying more attention to all those resumes of essbase developers that do not have system 9 experience and throw them on my key Hyperion Planning projects.

just a thought.

hj

Hyperion Planning 9.3.1: Time to upgrade

Having been fortunate enough to work with the various version of planning from 1.0 (ha, ha) to the latest 9.3.1.1, I can say with a clear conscience that Planning is ready for prime time with version 9.3.1.1. I just came off of a 9.2.3 project and I was really impressed with the stability. The only 2 issues that annoyed me were
-the open ldap directory getting out of sync with microsoft active directory (a batch utility is available to sync these)
-smartview not allowing ad hoc users to lock and send into essbase directly (now included functionality in 9.3.1. This is enabled by a new security role called "essbase write access")

Now with 9.3.1.1 there have been some improvements.
9.3.1.1 has 3 new security roles:
-offline user (might not be new to 9.3.1.1)
-mass allocation
-essbase write access

One dangerous feature is the addition of the mass allocation security role. This feature is initiated by planners selecting it via the web forms. In the docs it is specifically stated that users have the ability to allocate to cells and dimension intersections where they do not specifically have write access. While I'm going to ponder the use of this new feature, it's important for everyone to know that enabling this security role could have far reaching consequences. I think I'll stick to writing customized business rules for allocations for at least the next 9 months.

The best feature that might warrant upgrading is the addition of something called "composite webforms". This allows you to create one web form that is a combination of 2 or more web forms. The ways to use this are endless.
ex1.
-actuals could be in to top panel
-budget can be in the lower panel

ex2.
-top panel could be total entity or company consolidated
-bottom panel could be the current budget

While this is a great leap forward, you cannot resize the 2 combined forms. The size is fixed to half of the screen (either vertical or horizontal). I think we can live with this.

One drawback of the latest planning is the fact that Oracle/Hyperion no longer wants us to use HAL for maintenance of the planning tree. Our choices are now "enterprise architect" and DIM. There's nothing wrong with using HAL but you'll have to get special permission to find / download the software. It's not on the download site any more without special permission.

After asking around, "enterprise architect" seems a little green. One issue I have with the tool is that once you create or modify the planning hierarchy using architect, you can no longer use the planning web to modify the outline. Now we are forced to manage planning via the "classic planning administration" option.

DIM (informatica with planning plugin) is pretty nice (a little hard to figure out from the docs) but it appears that it might have a short life span. It appears that this product will be replaced by something else from Oracle. This is a shame because it looks like a really nice tool.

The best part of this verison of planning was that I was able to make a new planning application without manually editing any confiugration files. The new app appeared on the web also with no need to bounce any services.

hj