Requestor Name Goes Here (Requestor Department Goes Here)
Why a requirement attached to a department instead of a person becomes an ERP risk no one can negotiate.
A year into one of the largest ERP implementations I have been involved with, well into configuration, one of the workstreams raised a requirement no one had planned for. The project would need a new third-party module the institution had never licensed, which meant a formal procurement action now stood between us and a requirement no one had scoped. The reason offered was that the function required it.
I was skeptical, but yielded on the condition that we run a limited bid rather than a full RFP that would take months. Weeks later, I learned the limited bid was not permitted. A full RFP would be required, with real pressure on the go-live date. I asked for one thing: a date at which we would revert to the current solution if procurement slipped. The answer was that procurement would make the date, and that we should flag it if it began to slide. I said as plainly as I could that this is exactly the wishful thinking that puts these projects at risk. On this point, I was overruled.
Weeks later I learned the rest. The module had not been required by compliance or policy. It was the preference of a single manager. Had that been clear to me, a direct conversation with that person might have produced an accommodation that never put the timeline at risk. In today’s Dispatch, I examine why assigning ERP requirements to departments rather than individuals puts implementations at risk, and how listing a specific name with every requirement is a fundamental prerequisite for success.
The big picture
Every ERP implementation runs on three levers: scope, resources, and timeline. The three are not independent variables. They form a system in which controlling any two determines the third. Fix the scope and the resource level, and the timeline becomes a calculated result rather than a target. Fix the timeline and the resources, and the scope is defined by what that combination can realistically accomplish. Fix the scope and the timeline, and the staffing requirement is set for you whether the budget supports it or not. A project that appears to be in trouble on one dimension is almost always constrained on the other two as well. The levers move together.
The timeline is a lever in the earliest phase of a project, when scope and resources are still being mapped, and nothing has been formally committed. After that window closes, moving it carries a specific and considerable cost. In higher education, go-live dates attach almost immediately to enrollment cycles, payroll schedules, and fiscal year boundaries. Slipping a date does not mean slipping a few weeks. It means waiting for the next cycle, often six to twelve months later, while consultants remain on the clock. Few institutions can absorb that cost. The deadline is not a negotiating position. It is a fact of institutional life, and the project absorbs it as such.
Resources cannot move either, at least not in the way the lever implies. Adding people to a late project is almost always counterproductive. The work requires knowledge of how the institution operates, and that deep knowledge takes months to acquire. A new consultant or a borrowed analyst arrives without the background context that makes the existing team productive. They consume the time of experienced staff before they begin to contribute. Pulling this lever usually slows the project down.
That leaves scope. When the date will not move and the team cannot grow, scope is the only remaining variable. Cutting scope means deciding which requirements survive and which are deferred, and that decision is a negotiation conducted under time pressure among people who do not all want the same outcome. The outcome of that negotiation determines whether the institution crosses the go-live line in a position to function effectively, or spends the following months struggling to operate a system that was not ready for the community it was supposed to serve.
This is why scope management is the defining discipline of ERP implementations. When a project underdelivers, the cause is rarely technical. It is the way institutional power arrangements impact project leadership, and the requirements matrix is where that power becomes visible. The project team holds almost no institutional standing relative to the offices whose requirements it is asked to satisfy. Faced with pressure they cannot redirect, project teams do what project teams do: they say yes and work harder. Most cost overruns and go-live failures trace directly to that dynamic.
The Structural Flaw of Faceless Requirements
A common practice in project management is to list departments as the owners of specific requirements. A tracking tool has a requirement owner that shows “Legal Affairs” or “Financial Aid” next to a highly customized workflow. This is a structural error, and it is the error that makes scope negotiation nearly impossible.
A department is an institutional abstraction, it’s a machine built to execute rules predictably. You cannot look a department in the eye. You cannot ask a department to weigh tradeoffs, acknowledge resource constraints, or compromise on an entrenched process. When “Legal Affairs” owns a requirement, that requirement becomes an immovable monolith. It is stripped of its human context and insulated from scrutiny.
The alternative is to associate a specific identity with each requirement. Marshall Rogers, the General Counsel, is a person. He operates with judgment, not only rules. He understands institutional risk. He manages budget constraints. He knows the operational realities of his division and the political cost of delaying a campus-wide initiative. A project manager can negotiate with Marshall Rogers. Marshall Rogers can examine a clunky legacy process and make a rational decision to alter it. “Legal Affairs” can do none of these things. The difference is not cosmetic. It is the difference between a requirement that can be negotiated and one that cannot.
The Higher Authority Tactic
A requirement assigned to a department does more than obscure its practical owner. It hands the project team’s stakeholder counterparty a ready-made negotiating move: the appeal to absent higher authority. Karrass identified this as one of the most effective ways to resist a concession, and it works precisely because of the standing gap already described. When a mid-level subject matter expert tells a project manager that compliance requires a custom workflow, that expert is borrowing the political clout of an entire division. The borrowed clout becomes a barrier to change. The stakeholder avoids the discomfort of change, and the status quo survives untouched.
The move works because it removes the decision from the project room. No one present can question a compliance standard, because standards are not a person who can be questioned. The requirement survives not because anyone has defended it, but because no one in the room can overrule it. The project team, already short on influence, is now arguing with a decision no one present has the authority to change.
Defeating this move requires returning the conversation to human terms. Voss describes calibrated questions as the instrument for exactly this work. The response to “the department needs this” is to ask who specifically owns the risk if the process is simplified. The question forces the requirement out of the abstract and locates a named leader who can weigh the tradeoff. Once that person is identified, bargaining can begin. Until then, the project team is not negotiating. It is absorbing.
Work Simplification Requires a Name
Naming a requirement’s owner is the precondition for simplifying the work, and simplification is what cutting scope actually demands. Isaacman has argued that simplification requires breaking old habits, challenging assumptions, and accepting calculated risk. Inside an ERP project, that means reducing non-value-added time and removing legacy logic that no longer earns its place. It is a process of deciding what to stop doing, and someone has to decide it. That requires people actively negotiating.
A department will not volunteer for that. Institutional abstractions default to safety, and safety means preserving the existing process, whatever it costs the new system. Simplification is uncomfortable because it requires spending political capital to change how people work, and a department has no political capital to spend. A named leader does. Only a person with standing can look at a convoluted, decades-old process and decide the institution no longer needs to do it that way. Without that person, the old logic survives, and the new system is customized to accommodate it.
This returns to where the three levers left off. Scope is the only lever that can actually move, but people move it, not abstractions. A requirement owned by a department cannot be cut, because no one can be asked to cut it. The faceless requirement is not a neutral documentation choice. It quietly removes scope from what the project can negotiate, which removes the one lever the institution had in the first place.
The final word
ERP implementations are human negotiations disguised as software projects. Because the timeline is fixed and added resources rarely help, scope is the variable that drives success, and scope can only be managed through negotiation with the people who own the work. When project tracking obscures those people, the institution loses its capacity to conduct that negotiation. It finds itself bargaining with ghosts.
The correction is concrete. Audit the requirements matrix. Examine every line item and every requested customization. Where a department is listed without a corresponding human being, the project is carrying unmanaged risk and has quietly surrendered its only lever. Demand a name. Put that person in the room and ask them to defend the requirement. Make the requirement human, and negotiate the work.