Wednesday, August 9, 2017

Planning Rehabs

It's been quite a while since I last posted.  I had planned to post for frequently but frankly just let it slide to the back burner.  I'll be looking to post more regularly from here.

Recently, I seem to have developed more business rehabbing Hyperion Planning implementations.  Although I have also completed two full implementations (one PBSC and one on-prem) and also worked on a major bug fixing/enhancement project, I've been called into a few clients who's planning systems were challenging or even borderline unusable.  Generally, the responsibility was shared between the company and the integrator.  But when I get the call, the company has tried to move past blame and is interested in salvaging their investment.  Happily, I've been able to re-engineer the systems successfully.  Given the current business environment in which many company's have squeezed budgets and time frames and in which they have been sold a bill of goods that planning systems can be build faster and cheaper than ever, I believe there are a lot of struggling planning systems out there.

Rehabbing such a system can be very complex.  Often documentation was squeezed out.  Requirements were unclear and are now remembered poorly.  As-built quality can be adequate to very poor.  Stakeholders are generally frustrated, discouraged, even giving up.  However, there is a path to recovery.  I recently completed such a rehab for a manufacturing client who's implementation in 2016 was overly complex and frustrating.  Their partner tried to build to every requirement and failed to document much of the system.  The developers showed an understanding of Planning and Essbase at a mechanical level.  But they did not seem to have had a very experienced architect, so the cube and rules designs were sloppy and inefficient.

In addition to needing a rehab, the company had decided to upgrade from to  They created all new instances which provided a clean new platform but also meant additional manual migration since LCM is not completely effective across releases.  This was completed prior to my engagement.  I would have recommended an in-place Dev upgrade and new QA and Prod systems.

My approach started with realistic scope and a clear project plan.  I insisted that the business users be engaged and dedicate time from their schedules as demanded by the project pplan.  Although there were a couple of new major mandatory design requirements, the project scope was limited to those enhancements and the upgrade.  During the project, I was able to redesign specific parts of their application where the bang for the buck was high and as time allowed.  But generally, a significant part of the project was keeping the project in scope and helping the client to start an enhancement tracking system so that out of scope requirements had a landing place.  This helped the users feel that they had been heard and their requests would not be lost.

I recently completed my involvement in the project, leaving behind a functioning system ready for 2018 planning, 200+ pages of documentation, and a trained internal architect to take the reins.

During the project, one of my partners, American Partners (@AMPTalent) offered me a speaking slot at Kscope17.  Given my recent experience, rehabbing planning implementations was a natural topic.  I am pleased to report that the presentation went smoothly and the reviews were very positive (4.5 stars out of 5).  If you would like a copy of the presentation, drop me an email.  If there is a recording, I'll link to it when it's available.

These sorts of projects can be very challenging and require a range of high-end skills (business, technical, management).  But they are very rewarding when completed successfully.

- Jonathan Cohen

No comments:

Post a Comment