Last week we covered Design and in the weeks before that we discussed Design, Discovery, and Pre-assessment/Scoping / Kick Off, this week we are going to cover
The rules/formulas were worked on in design stage. It is one thing to write the words down in a design document or even read and understand what was written in the design document. You have to take it to the next level when you translate the language of the design document into the configuration/pseudo code that make the compensation system actually function. Typically, you need to find a way to create the credits associated to the expected transactions. Then there are normally formulas employed to sum up the credits or possibly sum up the credits and perform a calculation against them. Some systems allow the implementations to build formulas on top of other formulas in order make the calculation that is required.
The key often is to keep it as simple as you can, but still get the calculation done. The greater the amount of complexity you build, the harder it will be to update or reuse what you have built.
In many cases one plan will be very similar to another plan. Often times you can reuse some of even all of what you built for one plan and use it in another plan. It can be helpful sometime to start with the simpler formulas or plans and reutilize them making them more complex with each iteration and subsequent plan.
Building the report is a similar process to building the plan. You have to take what was written in a report design and translate it into something that actually has the ability to display calculations and convey messages to the user. Did the payee meet quota, did the payee did not meet quota, did the payee obtain a bonus, or perhaps the payee did not obtain a bonus? The Mock Ups from the design document help, but here again just making the reports for the compensation system look like the Mock Ups will not be enough. The report writer has to understand the business and calculations involved and create something that is meaningful and accurate for the end user.
Just like the configuration, it is not unusual to reemploy report queries for multiple reports and user types. Starting with the simple reporting queries first and reutilizing what you have built on subsequent reports can be a true time saver.
We did most of the mapping during the design phase. At this stage, we are tweaking the mapping based on new information, possible change requests, and many times for the needs of the configuration itself. Often times if the data can be made available the right way, it can actually simplify the way the configuration and manner in which the calculations occur. Where possible the client should be requested to keep the data as simple as possible and provide it in a manner that works with the inherent structure of the compensation system. This is not a requirement; however, it often saves the team a lot of headache in the future when it comes time to update plans or add new ones.
From what we have seen in the past, the more rigid the formatting is for the source data at the start the more complex the configuration will be.
Don’t forget to make sure your team does adequate Unit Testing and System Testing of the configuration/build they have put together. Yes, there is always a configuration/build deadline to meet; however, just throwing your work over the fence without a proper unit test will lose a lot of support with your customer/client. This is one of the corners many teams cut. Project managers need to ensure that the team does a good job on this activity. It would be wise to make the team show evidence that this activity has actually taken place. You are getting close to the end of the project now, so be sure to make the interaction with the client/customer a positive one prior to moving on to User Acceptance Testing.