During an implementation for MSS, we came across an interesting issue on Talent Management iView. The manager had 40 odd direct and and indirect employees under him. List of employees appeared correctly in Team Calendar. But when accessing Talent Management iView, we saw 40 entries with employee names repeating 16 times for 1 employee, and twice for other two employees.
Data in PA0002 was accurate and the fact that Team Calendar did show correct names for all employees, we discarded the possibility of bad data. The issue was reported after setting up structural authorizations but employee names repeated multiple times did not make sense.
Here is what I found after some debugging.
FM HRMSS_GET_QUALIFICATIONS called by Talent Management application calls FM HR_READ_INFOTYPE inside a loop for each employee selected by OADP configuration. Note highlighted part in the code. Exception handling is commented out for FM, internal table LT_0002 and work area LS_0002 are not cleared after each loop pass.
FM HR_READ_INFOTYPE checks for structural authorization of user in class CL_HRPAD00AUTH_CHECK_STD, method CHECK_CONTEXT_AUTH_OBJ. In case of missing authorizations to read PA0002 for an employee, FM HR_READ_INFOTYPE returns empty internal table LT_0002.
Now consider a case where the manager has authorization to read PA0002 for employee 1 , employee 17, employee 19, employee 20, and employee 21 and employee 23 to employee 40. Because of the code, even though HR_READ_INFOTYPE returns empty internal table LT_0002 for employee 2 to 16, employee names for these employees will be populated as employee 1 only i.e. employee 1 reperating 16 times and so on.
So output in view like Competency Matchup would show,
employee 1
employee 1
employee 1.
...
...
..employee 1 ( 16 times ),
employee 17
employee 17
employee 19
employee 20
employee 21
employee 21
employee 23
employee 24
...
...
employee 40
Lessons learned. 
Yes, we need to set up structural authorizations properly, but never miss recommended best practices below.
1) Judiciously use CLEAR on internal table and work area inside a loop.
2) Code appropriate error handling after FM call.
Also learnt was the lesson that if you have correct data in backend ECC and missing/confusing data on portal iView, do not rule out authorization issues early.
What is there in a name? Well, name does matter when a manager wants to match up employee competency for a position. 
I hope this helps in others facing similar issues.