Effort Certification System Implementation

1. Effort CertificationSystem Implementation Andres Chan Senior Manager, University of Southern California & Jason Jacobs Senior Manager, Attain

2. Agenda • Overview of Effort Reporting • System Implementation Life-cycle • Business Requirement/Proposed Solution • High Level Design (Functional Specifications) • Detailed Design (Detail Specifications) • System Configuration, Customization, Development and Testing • System Implementation • System Support and Maintenance • Future Enhancements

3. Why do Effort Reporting? • Sponsored Research • OMB A-21 • NIH Salary Cap Requirements • Cost Sharing • Flexibility for additional regulatory requirements • Institutional Policy/Procedure Rules • Controls on Uncommitted/voluntary Cost Sharing • “Knowledgeable Person” policy based on employee being certified (exempt vs. non-exempt certifiers) • Funding source coverage for cost sharingOTC cost sharing

4. Challenges of Effort Reporting • Cumbersome to faculty • Timeliness • Accuracy • Tracking and enforcing commitments • Enforcement of Federal requirements outlined in OMB A-21 circular • Enforcement of other institutional and state requirements • Documenting and reporting cost sharing • Amended effort reports

5. PRE-AWARD POST-AWARD Faculty Appointments and Hiring Staff Preparing the Proposal Budget Charging Salary Certifying Effort • Employment terms are established, including # months (contract period), % full time, salary base • Effort is proposed, a commitment is made to the sponsor • Effort is charged, in a real time manner consistent with activity • Effort is monitored • Effort is attested to, after activity has occurred LEADERSHIP, POLICIES, TRAINING, SYSTEMS Business Process Integration “Effort Reporting is more than just a certification statement…” NCURA FRA-IX – New Orleans, LA – February 26, 2008

6. Problem Areas for Research Compliance in ERP Systems • Chart of Accounts and Cost Sharing • Determining IBS across multiple jobs • Inconsistent Rate of Pay across multiple jobs • Inconsistent Rate of Pay on additional pay / overloads • Additional Pay / Overload not distinguishable as IBS • Defining FTE % accurately • Allocation of leave accruals upon termination

7. People Review Skills, Knowledge, Support Review Workload Balancing Review Organizational Skills Full-Life Cycle Stakeholder Analysis Process Review Current Business Processes Integration of Connected Processes Review Workflow and Separation of Duties Evaluate Business Process Alternatives Technology Configuration Settings Control Settings System Integration Evaluate Technology Alternatives Holistic Approach to Projects:People, Process and Technology

8. Implementation Phases & Activities

9. Business Requirements and Proposed Solution • Phase where your business requirements are finalized, the software package is learned, and a solution using the package is defined to meet the business requirements.

10. Business Requirements and Proposed Solution University Implementation Partner Defining Governance: Stakeholders, Strategic Alignment, Decisions Ensure requirements define true business need, not current solution approach Designing for full life-cycle Address requirements and issues at source Business process change in upstream and downstream systems • Identified vulnerability in current system • Advantage of systems implementation to Kuali • Pitched idea to decision makers

11. Full Life-cycle Design:

12. High-level Process Requirements

13. High-level Process Requirements

14. High Level Design – Functional Specifications • The planned solution is further clarified by functionally specifying how the system will operate.

15. High Level Design – Functional Specifications University Implementation Partner Involvement (and buy-in) from Full life-cycle stakeholders Apply criteria based on true business need, not “how it used to be done” Consider Business Process Change (full life-cycle) when evaluating solutions Understanding limitations of system comparisons and demos • Involvement from: • Office of Financial Analysis • Office of Compliance • Systems Implementation Team • Campus Community Representatives • Team provided wish-list items • Positive/Negative functionalization items • Team compared wish-list items to Workday EC & Kuali EC (alternative was to also go with vendors)

16. Detail Design – Detail Specifications • Detailed design specifications are developed (e.g., table values are defined, specifications as to exactly how reports will look and work are developed, etc.)

17. Detail Design – Detail Specifications University Implementation Partner Challenges of business process and system changes in up-stream and down-stream systems Designing for future state while within the current state Considering all real-world business scenarios (devil is in the details) • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Identified various modules needed for implementation • Modules: Integration from payroll, Salary Expense Transfer, Cost Sharing, User Interphase, etc.

18. System Configuration, Customization, Development and Testing • The system is “programmed” by setting up its parameters and tables with the values defined in the previous phases. Interfaces, data conversion and customized programming are also done in this phase. Quality assurance (systems and user testing) is done here

19. System Configuration, Customization, Development and Testing University Implementation Partner Scripting full life-cycle scenarios (inputs, direct processes, and outputs) Avoiding pitfalls of staged data and invalid variation on scenarios The right skills, tools and participants – they are different from the design phase • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Very tedious work • Develop very intimate/in-depth knowledge of new system/payroll inter-workings • Challenging due to moving target

20. System Configuration, Customization, Development and Testing (cont.) University Implementation Partner Calling on Governance model and effective decisions documentation from earlier phases Re-designing when things don’t work out Having a contingency plan • Development and testing • Will our wish-list items make the cut? • Are we talking the same language? • Are promises being broken? • Keep notes, notes, and more notes on what is promised by development team. • Expect to get push back on some items

21. System Implementation • The system is implemented and operations are converted to the new system.

22. System Implementation University Implementation Partner Clearly define and tested cut-over strategy, plan and schedule Having a contingency plan Understanding Change Management – it’s not just training and communication • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Other system owners • Very tedious work • Develop very intimate/in-depth knowledge of new system/payroll inter-workings • Challenging due to moving target

23. Integration of project management and change management Solution is designed, developed and delivered effectively(Technical side) + Solution is embraced, adopted and utilized effectively(People side) = SUCCESS Complimentary disciplines with a common objective

24. Who “does” change management? Each ‘gear’ plays a specific role based on how they are related to organizational change

25. Common Problems Possible Tactics Change Management with ER System Projects Poorly aligned Stakeholder Groups Multiple business process changes at once – Appointment and Payroll Management, Commitment Enforcement, on-line certification System enforces rule that were never system enforced Payroll / Effort is not right; “I’m getting errors!” Properly Defined, Managed and Executed Governance Well designed and clearly communicated business processes; advance communication; coordination of training topics; cut-over approach Training on institutional and regulatory guidelines and audit risks Evaluate upstream business processes to correct data before this stage

26. System Support and Maintenance • The post implementation phase where the system is turned over to the normal support and maintenance process.

27. System Support and Maintenance University Implementation Partner Production Support Strategy It shouldn’t begin here! Knowledge Transfer Plan Realistic Support Cut-over Strategy Celebrate! Roadmap and Plan for the Enhancements – Make sure Phase 2 Arrives • Involvement from: • Office of Financial Analysis • Systems Implementation Team Business Analyst • Payroll Office • Different team members due to changing from in-house payroll to cloud system in Workday

28. Where Others have Gone: Turning a Negative into a PositiveFull Life-Cycle Faculty Workload Management