Something isn’t working.
You already know that much.

In 2009, a credit union acquired a call center from a major insurance provider. The Transition Services Agreement gave the team six months to build a new data center and move every system and phone line from Minnesota to Texas, without members noticing a thing.

The hardest part wasn’t the build. It was that almost no one could explain how the applications actually connected to each other. Most of that knowledge lived in one local IT person’s head. So the team mapped it the analog way: sticky notes, string, and a walk through exactly what happens when a member calls in. Once the map existed, the migration became a sequencing problem instead of a mystery.

The switchover went smoothly, and credit union executives later told the press it gave members a “new level of service.”

The Texas story above started with an acquisition, and that’s the more common shape of M&A work for a credit union: absorbing a branch, a portfolio, a call center, a piece of another institution, on a clock set by someone else’s agreement.

A merger closes in the boardroom, but members experience it at the branch counter, in the app, and on the phone. Behind that, four things have to come together on a clock someone else set: who can sign in to what (identity), the systems people use (applications), the technology underneath them (infrastructure), and the contracts and partners that keep it all running (vendors). The test is simple: can a member tell anything happened? The value of the deal is protected, or lost, in the execution.

Vendors deliver their scope. Your team absorbs everything around it: coordinating schedules, chasing decisions, reconciling status, pulling the right people into meetings, on top of the job they already had. A good vendor project manager owns the vendor’s work. They don’t own your competing priorities, your other vendors, or how it all fits into the rest of your portfolio. That stays with you.

One vendor-based initiative is manageable. Five at once, on top of everyone’s normal day-to-day work, is how good people quietly stall or burn out, usually without the training to run a project like this in the first place. The usual fix is another hire, or stretching the people you already have. Neither one scales cleanly with work that rises and falls. Capacity that scales with the work does.

ROPE (Results Oriented Project Execution) is the operating framework underneath everything on this page. It's not a one-time waterfall plan; it's four phases that run as a continuous cycle, repeating for every wave of work until the initiative is done.

Most approval problems come down to not counting capacity before saying yes. One way to count it is a monthly set of credits that stands for your organization’s actual capacity, drawn down by the work in front of you.

Every month, your organization has a set number of credits: your actual capacity, not a guess. Each incoming initiative gets sized S, M, L, or XL based on real complexity, and draws down against what’s left.

That turns a vague conversation into an obvious one. Room left this month? Approve it, and it moves to Now. No room? It moves to Next, or it bumps something lower on the list out to make space. If that keeps happening to the same kind of work, that’s not a scheduling problem anymore. It’s telling you it’s time to add capacity, not ask people to work more hours.

You can’t fit ten pounds of initiatives into a five-pound sack. Credits make the sack visible before it’s everyone’s problem at once, instead of one decision made early.

You don’t need anything formal to start. List what’s in flight, size each piece, and count what’s left against what your people can really absorb.