How Did Job Design Transform the Program Administrator Role at Pepperdine University?

Job design can turn an overloaded “catch-all” administrator role into a clear, scalable operating model—without killing autonomy or meaning. Using Pepperdine’s MSOD context as an example of a complex, high-touch academic program, this article shows how to diagnose the job, redesign it using proven job design principles, and measure results with practical templates you can reuse. (Program structure references are based on publicly available Pepperdine MSOD information.) (Pepperdine Graziadio Business School)

Why job design matters for program administration in universities

Program administrator roles in higher education often become the “system glue” for admissions coordination, student experience, faculty logistics, and compliance-heavy operations. Over time, that can produce:

• Role ambiguity (“everything is my job”)

• Too many exceptions and escalations

• Overdependence on one experienced person

• Service variability across cohorts

• Burnout risk—and brittle continuity when someone leaves

Job design is the structured practice of reshaping responsibilities, decision rights, workflows, and interfaces so the role is sustainable and aligned to outcomes—not just tasks.

A useful starting point is the Job Characteristics Model (skill variety, task identity, task significance, autonomy, feedback). These dimensions explain why some jobs feel motivating and “whole,” while others feel fragmented and draining. (ScienceDirect)

The Pepperdine context (what we can verify publicly)

Pepperdine Graziadio’s MSOD is a hybrid program with multiple intensive sessions and international components, which increases coordination complexity and stakeholder touchpoints (students, faculty, travel sites, course materials, academic policies). (Pepperdine Graziadio Business School)

That kind of program structure is exactly where job design pays off: a single role can become a bottleneck unless responsibilities, handoffs, and decision rights are deliberately engineered.

Common failure modes when redesigning an administrator role

1) “Add responsibilities” without redesigning the system

Organizations respond to efficiency pressure by piling on more programs, cohorts, or classes—without changing workflows, tools, or support.

2) High autonomy without clarity

Autonomy is motivating, but without explicit decision boundaries it turns into constant interruption and escalations.

3) Dependence on tribal knowledge

If success depends on a 10–15 year veteran “knowing how things work,” the job is not designed—it’s improvised.

4) No measurement baseline

Teams don’t define what “better” means (cycle time, student satisfaction, error rates, escalations, faculty experience), so the redesign becomes subjective.

Step-by-step: How to redesign a program administrator role (the practical method)

This is the same approach OrgEvo would use in a consulting engagement—built to be implementable by a university department, school, or program office.

Step 1: Define outcomes and service levels (not tasks)

Inputs: program calendar, stakeholder expectations, known pain pointsRoles: program leadership, administrator(s), faculty director, finance/registrar interfacesOutputs (examples):

• Student response time SLA (e.g., 1 business day)

• Registration accuracy rate

• On-time readiness for intensives (materials, rooms, travel, LMS setup)

• Faculty support satisfaction score

Quick check: If you can’t measure it monthly, it’s not an outcome yet.

Step 2: Map the “program operations value stream”

Create a simple flow of the program lifecycle:

1. inquiry → admissions coordination

2. onboarding → registration/fee workflows

3. course delivery support → issues handling

4. progression → academic policy events

5. graduation → alumni handoff

Deliverable: a 1–2 page process map + a list of recurring exceptions (the real workload).

Step 3: Diagnose the current job using a structured lens

Use either:

• Job Characteristics Model (great for motivation and role enrichment) (ScienceDirect)

• Work Design Questionnaire (WDQ) (more comprehensive; task/knowledge/social/context dimensions) (Morgeson)

What you’re looking for:

• Where is skill variety “good variety” vs “chaotic variety”?

• Where is task identity broken by too many handoffs?

• Where is task significance high but invisible (no feedback loop)?

• Where is autonomy creating risk (inconsistent decisions)?

• Where is feedback delayed or absent (errors discovered late)?

Step 4: Redesign responsibilities around “work packages”

Instead of listing 40 tasks, group work into work packages that can be owned, measured, and improved.

Example work packages for an MSOD-like program:

• Cohort readiness (intensive/session readiness checklist, vendors, materials, LMS)

• Student lifecycle support (case management model, tiered escalation)

• Faculty delivery enablement (standard request intake, templates, timelines)

• Academic administration (registration, finance touchpoints, policy events)

• Program improvement (issue log → root causes → fixes)

Each work package should have:

• owner (RACI)

• input triggers

• standard workflow

• SLA/quality metrics

• escalation rules

Step 5: Rebalance the role with decision rights (the hidden lever)

A program administrator role becomes sustainable when decision rights are explicit.

Define three levels:

• Admin-owned decisions (e.g., routine approvals, vendor coordination within budget rules)

• Consult decisions (needs faculty director input)

• Escalate decisions (policy exceptions, budget exceptions, student conduct/academic integrity issues)

This reduces interruptions and creates consistency across cohorts.

Step 6: Rebuild the support model (so the role scales)

If the program structure is complex (multiple intensives and international components), scale usually requires a support design such as:

• part-time coordinator for logistics peaks

• shared services for finance/registration

• student success coordinator for routine requests

• documented templates + intake forms + ticketing/CRM

The point isn’t “more people.” It’s right work to right role, with peak-load coverage.

Step 7: Implement a 30–60–90 day rollout plan

0–30 days

• baseline metrics + exception log

• process map + RACI draft

• “do not do” list (cut low-value admin work)

31–60 days

• publish SLAs and decision rights

• standardize intake forms and templates

• pilot with one cohort/session

61–90 days

• refine based on metrics

• finalize documentation

• cross-train a backup role (continuity)

Step 8: Measure outcomes and lock in continuous improvement

Suggested monthly metrics:

• student response SLA attainment

• number of escalations (and category)

• readiness checklist completion rate

• error/rework incidents (registration, materials, logistics)

• stakeholder satisfaction pulse (students + faculty)

Templates you can copy

1) Program Administrator Role Charter (1 page)

• Role purpose: (why this role exists)

• Primary outcomes: (3–6 measurable outcomes)

• Work packages owned: (list 4–6)

• Decision rights: own / consult / escalate

• Interfaces: registrar, finance, faculty director, IT/LMS, vendors

• Cadence: weekly ops review + monthly improvement review

2) RACI snippet (example)

Work package	Responsible	Accountable	Consulted	Informed
Cohort readiness	Program Admin	Faculty Director	IT/LMS, Facilities	Students
Registration exceptions	Program Admin	Registrar liaison	Faculty Director	Finance
Faculty delivery requests	Program Admin	Faculty Director	Instructional design	Students

3) Readiness checklist (minimum viable)

• faculty roster confirmed

• course shells ready in LMS

• materials ordered and delivered

• rooms/vendor contracts confirmed

• student comms sent (schedule, expectations, policies)

• escalation contacts published

• contingency plan documented

Practical example scenario (illustrative; not a case study)

Imagine a program with six in-person intensives plus online foundations and international elements. (Pepperdine Graziadio Business School)Without redesign, the administrator becomes the bottleneck for logistics, student case handling, and faculty support. With a work-package model + decision rights + readiness checklists, the same headcount can often reduce errors and escalations while improving student response time—because work is standardized and measurable, not heroic.

DIY vs. expert help

You can DIY if…

• leadership agrees on outcomes and SLAs

• you can map workflows and exceptions

• you have authority to clarify decision rights and interfaces

Consider expert help if…

• the program is expanding rapidly (new cohorts, new sites, new formats)

• multiple departments disagree on ownership (registrar/finance/program office)

• the role redesign impacts titles, compensation bands, or organizational structure

• you need a capability-based operating model, not a one-off job description

(Helpful internal reading on related operating-model topics:

• https://www.orgevo.in/post/how-can-you-implement-effective-work-design-workforce-diversity-and-wellness-programs-in-your-comp

• https://www.orgevo.in/post/how-can-you-implement-an-effective-organizational-design-in-your-company

• https://www.orgevo.in/post/how-can-you-implement-effective-job-enrichment-and-total-reward-strategy-in-your-company

• https://www.orgevo.in/post/how-to-implement-effective-human-process-interventions-in-your-company)

Conclusion

A transformed program administrator role isn’t created by “adding tasks” or rewriting a job description. It’s created by redesigning the system: outcomes, work packages, decision rights, interfaces, and metrics. In complex hybrid programs like Pepperdine’s MSOD—with multiple intensives and international components—job design can be the difference between scalable excellence and chronic bottlenecks. (Pepperdine Graziadio Business School)

CTA: If you want help redesigning critical roles and program operations using a systems/enterprise-architecture approach, contact OrgEvo Consulting.

FAQ

1) What’s the difference between job design and job description writing?

Job design changes the actual operating model (responsibilities, workflows, decision rights, interfaces, measures). Job descriptions usually document the role after design is done.

2) How do we redesign an admin role without reducing autonomy?

Keep autonomy for defined decisions, but add clarity: decision boundaries, standard workflows, and escalation rules. This protects autonomy by reducing noise.

3) What’s the best framework to diagnose a job quickly?

The Job Characteristics Model is a strong starting point for motivation and enrichment. (ScienceDirect)If you need deeper diagnosis across social/context factors, use WDQ. (Morgeson)

4) How do we stop the “everything funnels to one person” problem?

Create work packages with owners, publish decision rights, and standardize intake (forms/ticketing). Add peak-load support where the calendar demands it.

5) What metrics should a program office track after job redesign?

Response time SLA, escalation volume, readiness completion, rework/errors, and stakeholder satisfaction pulses (students + faculty).

6) How do we ensure continuity if a long-tenured administrator leaves?

Document workflows and templates, cross-train a backup, and formalize interfaces. Continuity is an operating-model outcome, not an individual trait.

References

• Hackman, J. R., & Oldham, G. R. “Motivation through the design of work: Test of a theory.” (1976). (ScienceDirect)

• Morgeson, F. P., & Humphrey, S. E. Work Design Questionnaire (WDQ) and related materials. (Morgeson)

• Pepperdine Graziadio MSOD program schedule/design and course information (public program structure). (Pepperdine Graziadio Business School)

• Image taken from Pepperdine Graziadio Website