Effort CertificationSystem Implementation

Andres ChanSenior Manager, University of Southern California

& Jason Jacobs

Senior Manager, Attain

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

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 sharing OTC cost

sharing

3

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

4

Business Process Integration

NCURA FRA-IX – New Orleans, LA – February 26, 2008

LEADERSHIP, POLICIES, TRAINING, SYSTEMS

•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

Preparingthe Proposal

Budget

ChargingSalary

CertifyingEffort

Faculty Appointments

and Hiring Staff

PRE-AWARD POST-AWARD

“Effort Reporting is more than just a certification statement…”

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

Holistic Approach to Projects:People, Process and Technology• 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

Implementation Phases & Activities

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.

Business Requirements and Proposed Solution

University• Identified vulnerability in

current system• Advantage of systems

implementation to Kuali• Pitched idea to decision

makers

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

Full Life-cycle Design:

High-level Process RequirementsBusiness Area Requirement

Definition of IBS

Multiple JobsCross-departmental AppointmentsUse of Additional PayConsistent Rate of Pay

Part-time EmployeesConsistent use of FTEMultiple Jobs

Begin/End Date Funding / Spending Controls

Salary prevented before grant begin date and stopped on Grant End Date

Cost Transfers – Up to 30, 60 or 90 accounting days after Grant End Date

Cost Transfers – Only allowable on earning periods

High-level Process RequirementsBusiness Area Requirement

Controls on Cost Transfers

Adjusted original transactions must be identifiable on cost transfer transaction

Original transaction date must be in audit trail

Justification for cost transfer must be provided on the transaction

Cost Sharing Separate Account Code needed to reflect this requirement

Other IssuesEncumbrances crossing fiscal years

Encumbrance / Expense distribution change when grant funding expired

High Level Design – Functional Specifications

• The planned solution is further clarified by functionally specifying how the system will operate.

High Level Design – Functional Specifications

University• 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)

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

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.)

Detail Design – Detail Specifications

University• 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.

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)

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

System Configuration, Customization, Development and Testing

University• 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

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

System Configuration, Customization, Development and Testing (cont.)

University• 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

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

System Implementation

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

System Implementation

University• 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

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

Integration of project management and change management

Complimentary disciplines with a common objective

Solution is designed, developed and delivered

effectively(Technical side)

Solution is embraced, adopted and utilized effectively

(People side)

= SUCCESS

+

Project management

Change management

Current Transition FutureCurrent Transition Future

Copyright Prosci 2009

Who “does” change management?

Each ‘gear’ plays a specific role based on how they are related

to organizational change

Middle managersand supervisors

Middle managersand supervisors

Changemanagement resource/team

Changemanagement resource/team

Executives andsenior managersExecutives andsenior managers

Project team

Project team

Projectsupport

functions

Projectsupport

functions

Copyright Prosci 2009

• 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

Common ProblemsChange 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!”

Possible Tactics

System Support and Maintenance

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

System Support and Maintenance

University• 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

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

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