During interviews for my current role, plans for a cloud-based ERP system came up often. I recommended an independent advisory firm that could help the University structure a credible product selection process. I had worked with the firm previously. The team arrived during my second week on the job. Before its formal presentation to stakeholders, we had some candid time alone. One of their recommendations surprised me. The advisers thought the University should recruit a project leader who had already led an implementation of the selected product at a major university.
My blunt response surprised them more. “Absolutely not. No way.”
I believed the University already had the stakeholder and IT leadership needed to lead the institutional work. As a veteran of five implementations, I could provide guardrails and advice to senior executives. Consultants could supply product expertise, while an independent project management firm can provide verification.
But my response also came from experience. Years earlier, I had inherited a struggling ERP implementation led by a “star quarterback” hired from outside the university. Several new technical employees had arrived with him, all earning considerably more than employees who had served the institution for many years. Morale cratered. Within my first month, the quarterback left to follow my predecessor to their new job. I quickly hired another experienced outsider. That person did not work out either.
The project hit its stride only when I turned to an early-career employee already inside the institution. This person had little ERP experience but possessed the right competencies: communication, empathy, and the ability to earn trust and respect. We placed technical expertise around her, but we could not purchase the standing she earned. Many people thought she was in over her head, but she proved them wrong.
In today’s Dispatch, I make the case behind my emphatic response. The advisers were right that the project required experienced leadership. But implementation expertise can be purchased; the authority to lead the University’s work must rest with people who have earned its trust and will live with the consequences after the go-live.
Why it matters
An ERP implementation is an institutional redesign expressed through software. It changes how a university hires and pays its people, manages its budgets, and reports its finances. Every configuration decision distributes formal authority: who can start a purchase, who approves it, and which office owns a process once the design is locked.
Building the system depends on a different capacity. It requires candid participation and workable decisions from people spread across colleges, operating units, and committees. Senior executives commission the project, functional staff guide the design, and everyone else absorbs the consequences. No one holds the whole picture. Failure rarely arrives as a single break down; it accumulates through queue time and unresolved decisions. ERP leadership is a people problem before it is a technical one.
Experience is essential, leadership is institutional
The consultants advising the selection, discussed in the opening, have a strong case. Experienced practitioners recognize the recurring failure patterns. Vendors understate complexity, institutions postpone hard process decisions, and design delays consume testing time while status reports stay reassuring after the schedule has begun to slip. Institutional knowledge alone can struggle to see these signals. A university should purchase the strongest implementation expertise it can find.
The need for product and implementation experience does not establish where institutional leadership should best reside.
Implementation expertise can be supplied by the implementation partner, the vendor, and an outside assurance team. Institutional leadership requires knowledge of the university and two different forms of authority. Formal authority comes from the org chart: a mandate, control of resources, and reporting lines. It determines who directs work, approves decisions, and escalates issues. Governance authority is the practical capacity to move a university through decisions that cross boundaries. It grows when colleagues know a leader’s judgment and believe hard concerns will be heard rather than treated as resistance, and it depends on institutional knowledge , fulfilled obligations, and the expectation that the leader will stay to bear the consequences.
An externally hired leader can be granted formal authority on the first day. A title, a budget, and reporting lines can compel participation and set deadlines. That authority is real, and it is necessary. It does not create governance authority, which cannot be assigned in the same way. An ERP project repeatedly asks people to expose weaknesses in their own processes and accept new obligations they will live with after go-live. Formal authority can require a decision. Governance authority affects whether that decision is informed, accepted, and carried into practice. It also shapes how a leader reads local variation, some of it mere habit, some of it required by law or mission. A leader carrying another institution’s playbook cannot easily tell them apart.
Authority belongs with those who bear the consequences
Authority should sit with those who remain exposed to the consequences after go-live. An external project leader gains compensation and a resume addition when the implementation succeeds, and keeps an exit option if it turns too difficult. Internal leaders remain responsible for the workflows, the staffing burden, and the disruption. This is a problem of incentives and risk allocation, not of anyone’s commitment.
The compensation gap sharpens it. A highly paid newcomer placed above long-serving staff creates a two-tier structure inside a project that depends on those same employees to share knowledge and name risk. The danger is not open resistance. It is guarded compliance. Formal authority produces attendance and completed tasks while weakening the candor governance authority requires. The suppressed risks often surface later, when they cost far more to reverse. An ERP implementation also teaches internal leaders to decide across boundaries and own enterprise impacts. Handing the central role to an outsider weakens the institution’s own bench.
The president, provost, and chief financial and administrative officer bear ultimate responsibility and form the project’s executive governing body, obligated to resolve the conflicts no single project leader can settle. They set the mandate, define the boundaries for cost, risk, and timeline, and decide whether the institution will knowingly move past a guardrail, in decision meetings, not project documents.
Day-to-day leadership belongs to an internal chief stakeholder who already holds the campus’s trust and respect. This overall project leader needs enough formal authority to direct the work and escalate decisions, and enough governance authority to work across units that do not report to the project. The person need not be a technologist, but must be able to lead the ERP IT leader and engage the CIO as an equal.
The CIO doesn’t lead the project. The CIO serves as chief guardrails and adviser to the executives, keeping enough independence to flag when separate decisions, or their cumulative effect, threaten the budget or timeline. The role resembles the architect during construction, who does not own the building or supervise workers, but protects the design and warns when accumulated decisions endanger cost or schedule.
Build the team, then surround it with expertise
The ERP IT leader runs the technical team under the overall project leader. Much of that team comes from the staff who support the existing ERP, and those same people must keep the legacy environment running while they build its replacement. This is a capacity problem rather than a scheduling inconvenience. ERP is an all-hands undertaking for all of the IT organization. Leadership has to decide which existing work will stop or slow, because a plan resting on invisible overtime is not credible.
The functional work streams sit beneath the central leadership team: payroll, human resources, benefits, budget, and procurement. Institutional process owners lead them. Their existing roles give them formal authority over the processes they manage, and their relationships and judgment give them governance authority with the people whose work will change. Corresponding staff from the ERP IT leader’s team connect each functional choice to its technical design and integration consequences.
Consultants work inside the work streams. They challenge assumptions and show how similar choices played out elsewhere. The process owners keep decision authority, because they will operate the resulting processes and absorb the obligations created during design. Every decision belongs in a log recording what was decided, who held authority to decide it, and which consequences were knowingly accepted. Escalation paths have to be real. A decision that waits three weeks for the right meeting can threaten the schedule more than a technical task that takes three days. The operating culture should reward scrutiny while the design is still soft. To lead with friction is to treat disciplined disagreement as a service to decision quality, cheaper now than as conflict discovered after go-live when disruption is costly.
Everyone with institutional decision authority in this structure comes from the university. Outside expertise belongs in three defined places. The consulting implementation partner supplies methods, specialists, and delivery capacity. The software vendor’s executive support team supplies product expertise and an escalation route beyond the account team. An independent assurance team checks plans, assumptions, and reported progress across the university, the partner, and the vendor, reconciling competing accounts and raising concerns when the project drifts past its guardrails. This keeps any single external party from both defining project performance and supplying the evidence used to judge it. It buys expertise, challenge, and verification without transferring institutional decision authority.
The final word
Expertise can be purchased through an implementation partner, vendor support, and third-party assurance. Formal authority can be assigned through a mandate, reporting lines, and defined decision rights. Governance authority operates on a different clock. It grows from trust and respect, a record of judgment, deep institutional knowledge, and the expectation that the leader will remain to bear the consequences.
A sound ERP structure requires both forms. It keeps ultimate responsibility with the president, provost, and chief financial and administrative officer. It places day-to-day leadership with a respected institutional stakeholder who holds both formal and governance authority. It uses the CIO for guardrails and independent advice, and gives functional and technical staff real authority over the work they inherit. Consultants and outsiders strengthen institutional judgment. They do not replace it.
An ERP implementation is among the most demanding leadership-development opportunities a university ever creates. Led from the inside, it should leave the institution with more than functioning software. It should leave it with a bench of leaders who have earned greater trust, shown their judgment across institutional boundaries, and grown readier for whatever difficult undertaking comes next.