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.