Last week we covered Discovey and the week before that we discussed Pre-assessment/Scoping / Kick Off, this week we are going to cover
At this point the project team has asked the probing questions – now they need to communicate it back to the client and let the client know what the project team is going to configure, along with when and how they are going to do that configuration
The project team has already obtained insight with regards to the clients Plans, Payees, Reports and Data. Now that they have all that information they must do three main things
First, there is mapping or interface stream of work related to Data,
Second, there is configuration design
Third, there may be a report or dashboard design (depending on the vendor tool being used)
The key thing to remember about these three things is that they are all interrelated.
Often the configuration design comes first followed very closely by integration or data mapping and finally the report design.
The client does need to have an idea about what reports they would like need up front as that could impact the way the project team designs the configuration of the system and what data they need to pull into and push out of the system.
To the greatest extent possible the project team should typically try to configure as much of the calculations as they can in the system and a few as required on the reports.
One important thing to remember is try to obtain as many examples from the clients as possible up front and include those examples in the design documents that get delivered to the clients.
In order to configure the compensation plans into the system the project team needs to have a deep understanding of the calculations. If the calculations are not completely understood at this phase, it will most likely result in a flawed design and that may not be caught until User Acceptance Testing by the client. Unfortunately, at that point considerable rework will be required to fixed what has been configured incorrectly. Even though project teams are always in a rush to start the configuration, the more time spent on understanding the calculations at the design stage the better because it typically reduces rework once the users start their testing.
Make sure the project team understands how the payee data is going to be loaded into the system. Will it be a onetime load or will it be reloaded on a regular basis? Will the relationships between payees be key component to the calculations or will the payee titles be the driver in the calculation and the classification? The payee data is probably one of the most important data to be considered second only in importance to the transaction data itself.
The transaction data therefore must be given even greater consideration. The Data analysis stage as part of design is where project team typically begins their mapping. The mapping they are doing is trying to determine where the data is currently and how they are going to translate that in a way so that it is meaningful to the compensation system they are working with. If the project team is fortunate, they won’t have to change the mapping too many times or very much during the configuration/build phase.
The report and dash boards
Most compensation applications come with some canned or base reports; however, often times reports and dashboards can be customized with minimal effort and provide significantly more value. While it is true the project team doesn’t want to just rebuild what the client was already using for reports, it is important to work with the client to build mock ups of reports and dashboards that would provide them with the greatest value. Mocks up confirmed with the end user are the key to a good design and time spent up front with the users on mock ups pays dividends during the testing phase.