FAQ

• ​Will this new system provide workers with the correct hiring salary?
• ​Will the data provided on the roster match the information provided on the dues report? As of now, there are more dues paying members listed on the dues file, than listed on the roster.
• ​The new system should include a salary history for workers to access on the online system to a certain point. Then could salary history and changes be archived to be retrieved on request?
• ​Where will Unions fall on the timeline implementation? Will training be provided for Union end-users?
• ​Can PDD (Personal Development Day) be placed on the paystub? Can this be done now?
• ​How will this affect when we get paid?
• ​How will this affect how pay gets auto delivered to the financial institutions where the employee deposits their paycheck?
• ​Are you implementing a completely electronic timesheet?
• Why are we opening this up to outside vendors when we have IT professionals within the numerous agencies that use these systems who should be front runners in this or developing a custom product?
• ​Are we able to request a demo of the CSPS Solution at this point in the project?

As with the current system, the new system will generate a Notice of Personnel Action (NOPA) which provides the employee with specifics surrounding their appointment, including salary and range placement. However, in the current state, the turnaround to provide this documentation to the employee can be anywhere from 30-60 days after appointment. Due to the real-time nature of the future system, employees will be provided this information much sooner after they are appointed.

Future state has requirements for the reporting of union membership and deductions, however specifics of what will be provided will be determined when the system integrator is onboarded.

Salary data will be stored and accessed by authorized users as necessary. Reporting needs of historical data and retention timeframes will be determined during the design phase of the project.

​The implementation timeline has not been determined yet.  Training will be provided for all identified stakeholders which will include end-users.

For future state, PDD will be on the paystub once it is available for use. Due to limited resources for current state, PDD will remain a usage only leave type and will be visible on the paystub once it is used.

The CSPS Project is considering several opportunities to improve payroll operations.  As soon as we are able to share specific information about these potential changes, we will notify all employees.

Direct deposit will be processed the same way it is today, except without paper forms and the process will be automated in the solution. Future state will provide the functionality for employees to manage their bank account information on the solution, which will reduce Direct Deposit Forms (STD.699) processed by SCO. The solution will validate banking information for an employee with a direct deposit payment method.

​It is unknown at this time whether departments will fully implement the CSPS Time Management component or continue to utilize their current time management solution. As soon as we are able to share specific information about these potential changes, we will notify all employees.

State staffing on the CSPS project has been extensive, including dozens of IT personnel, business analysts and subject matter experts from multiple agencies. We are not pursuing a "turnkey" solution where the state has no involvement. Instead, we anticipate continued state involvement in planning, design, configuration, testing and training throughout the project.
The CSPS Project Team conducted market research in 2020 on solution alternatives, including discussions with several other state governments on their projects. In looking at the option to build our own custom system, we found:
Custom development would be prohibitively expensive due to the size of the employee base, changing regulatory and compliance requirements, and the need for a significant leap in technology. Commercial payroll systems have been available in the marketplace for over forty years, and building a custom system would very much involve "reinventing the wheel". A custom developed system poses significant risk for error. While commercial systems have been production-tested by hundreds or even thousands of governmental entities across the U.S., a custom system would have no such baseline. Finally, this alternative fails to take advantage of innovations already developed and tested in the commercial marketplace, leaving the state with an unproven solution that it alone possesses. In this approach, the State absorbs all the risk inherent in a large enterprise project and absorbs all the risk for ongoing maintenance as well. 
We also spent a significant amount of time investigating the option of making improvements to our existing systems. That analysis showed:
Incremental improvements cannot fully support the movement to industry standards and best practices that are critical to reaching our goals. Overall, the State does not possess enough resources to achieve its goals and desired benefits in  a timely fashion. Meeting agency and departmental operational needs requires a faster timeline than this approach can support. Does not solve the problem of being the only government on the solution, again forcing the state to assume all risk for implementation and on-going maintenance.

​Once we have a chosen solution and system integrator onboard, we will have a detailed schedule of when we can provide a demo. Might be possible that the solution vendor will have canned demo videos available for review.