By The Way

Even though my last two posts that dealt with lessons learned had a lot of items that can be considered negatives — I still love this product and am excited about the prospects of it in the future.   As the politically incorrect saying goes — the pioneers take the arrows.  

What I thought we knew 6 months ago is nothing compared to what we know today.  I can only imagine where we will be 6 months from now.  

Really goes to show that book learning can only get you so far and is no substitute for real life experience.

More Lessons While I Am At It

Since I get a breather today to get caught up on things like e-mail and a couple other projects here are a couple more lessons learned that have come to mind:

1. If a user is in two or security roles, the user will receive the permissions that are the MOST LIBERAL and not the most restrictive.   Meaning if onje of your security roles has permission set to NONE for the members of a certain dimension and one of your security roles has permissions set to READ + WRITE for that same dimension, they receive the READ + WRITE permissions.  I personally think this goes against good system security design which should err on the side of caution when a conflict arises.
2. You will be amazed by the sheer number of times you will open the same form template, tweak it, save it and republish it to get it “just right”.
3. You can’t get through a project without some form of MDX coding.  It just ain’t gonna happen.
4. You might get through a project without some VBA coding behind the sceens but don’t count on it.
5. Believe it or not, you can have enough dimensions and dimension members on a form that it is too large to submit because how the data is parsed in the backend.   This will stress you and the client out to the n-th degree. 

I am sure there will be more along the way.

Most Recent Lessons Learned

So right now we are finally seeing the light at the end of the tunnel on one of our current PPS Planning projects.  Hopefully, as the saying goes, it isn’t the headlight of an oncoming train.   If you see me at the BI conference spending every moment on my cell phone looking more and more stressed, you will know I have just been hit by a train.  The week I (and another team member on this project) are in Seattle is the go-live week for this project.

So what new things have I learned on this latest project?  I have more I am sure, but here are 10 that came to mind as I sat down to write this:

1. Make sure you know for absolutely sure if you need to allow data entry at all levels BEFORE you initially save your model and begin creating forms.   Since you can’t change it afterwards, you can waste a huge amount of time recreating your model(s) to turn this switch from False to True.
2. If you are going to use Annotations, you can never stress enough times that Annotations can only be entered in at leaf level and NO OTHER LEVEL.   If you allow data entry at all levels (see #1) and have roll-ups, be ready for someone to forget about this.  It will most likely happen during user testing after you are well into the project and it is too late to do anything about it.
3. The “Include Workbook” function works great in theory but two things happen in real life:  a) users forget to check the “Include workbook” check-box before they submit and then you are out of luck and b) an approver cannot see the information outside of the matrix in the included workbook unless they drill-down and open up the contributor’s actual assignment.  It is an extra step and makes doing approvals more time consuming.  Why would you have to do “Include Workbook” in the first place?  Well see #2 above and that will give you some insight.
4. If you are testing revisions to published forms and that form exists in multiple different cycles/assignments, in our experience you can end up getting some inconsistent testing results.   And if you have lots of cycles out there, testing different things, it is easy to forget about one here or there.
5. Replicating exactly what works for data collection in a flat format Excel spreadsheet does not necessarily translate into the ideal format for a PPS Excel Add-In format and model design.
6. Eventually, the save and refresh function of the PPS Planning Business Modeler will drive you insane as it takes you back to the root level and you have to re-navigate each time to where you were every time you refresh.   Same thing goes with the amount of mouse clicks and lookups.  You know, sometimes it is just quicker to type in the information than to look it up.
7. Allowing any form of actual data entry into the system before you have implemented and tested each and everyone of your back-end rules is a sure way to increase the stress of writing rules by a factor of 100 if you have rules that if written wrongly can overright data.  However, to test, you need data, and you need real data so you can confirm the results are what you are expecting.   For some one-time data loads creating a repeatable package to integrate just does not make project budget financial sense, so you have to have users manually enter.  So do you have them enter in multiple times?  It is a tough issue with which to have to deal.
8. To test properly you will need more sample domain accounts than you think you will.  This project we had 3 and one was in the Modeler role which makes true testing problematic.  I wish we had 10 test accounts and then a separate account for each team member.
9. Not being able to assign roles (only individuals) to a submission hierarchy increases the amount of back-end maintenance that has to happen.  If you have a 2 month+ budgeting cycle within a large organization, think of how many people involved in budgeting will change roles/positions or leave/join the company during that time.
10. A completely automated method of taking a testing environment and then moving it to production and vice versa would save tons of time.  Working with command lines and .csv files is tedious.

Like I said, there are more, but this is enough for now.  Keep them in mind as each one of these will impact your delivery time and potentially your project budget.

Still Alive

Right now we currently have 4 PerformancePoint projects on the go (3 Planning, 1 M&A) that have been taking up most of my time.   All of these have tested our skills in some shape or form at some point.   While, it really is amazing what this product can do, don’t forget that it is still a relatively new product and the Planning components are still at a v1 functionality level.   The best advice I can currently give for planning projects is that they will take more time than you think and they will take more budget than you think.   Don’t underestimate these two items.