top of page

The 45-Day Implementation Isn’t Luck. It’s Scoping

6 days ago
3 min read

What a vendor’s 45-day plan taught me about why legal tech rollouts stall.

I once implemented an e-billing platform in under 45 days. People still ask me how. The first part of the answer is that the 45-day schedule wasn’t mine. It was the vendor’s.

They came to kickoff with a proven onboarding plan, and our job was to make it happen together. Not every vendor earns the title of business partner. This one did, from leadership to sales to onboarding. The whole team was fabulous, and the onboarding team knew exactly what they needed from us and when.

The other half of the answer is that we were ready. A great onboarding team can’t hit a date with a client who is still deciding what they want. That readiness came down to one discipline, scoping.

Why most rollouts stall

Most legal technology rollouts don’t stall because the software is wrong. They stall because the team tries to configure everything at once. Every stakeholder’s wish list becomes a launch requirement, every edge case gets its own workflow, and six months later the platform is still “almost ready.”

The alternative is a minimum viable setup. Launch with what drives your reporting, put it in the hands of real users, and improve it once it has had time to run.

Do the homework before the RFP

Readiness starts well before the vendor’s clock does. Run short pilots first, especially in platforms you already own. A few weeks of real use tells you what you actually need, and what you only think you need.

Then ask your users what is and isn’t working today, and follow up with one more question, “If you could have anything, what would it be?” Those answers belong in your request for proposal (RFP), not on a post-launch wish list. Sometimes those wishes are surprisingly easy to meet, and delivering on them builds real excitement for the new platform.

If you’re migrating from another platform, clean your data before you move it. Bad data comes along for the ride and undermines trust in the new tool on day one.

Scope to the fields that drive reporting

Before you configure anything, decide which three to five fields your team cannot live without, the ones your leadership reporting runs on. Everything else can wait.

For a contract management tool, I would start with client or vendor, effective date, total contract value, term length, and contract type. For e-billing, I would start with firm or vendor, matter name, practice area, invoice total, and invoice date. Get those right, required, and clean, and you have a reporting foundation from week one.

Decide how you’ll launch

Scope how you go live, too, because the right approach depends on the platform. For a contracting tool, start with a group whose work doesn’t require special handling, so standard agreements go first and the bespoke deals with unique approval paths come later. For e-billing, the decision is which firms and vendors come over at launch and which do not. Settle that list before you sign, since your contract terms will often drive it.

After go-live, let it run before you sprint

A working minimum viable product (MVP) creates momentum that a long configuration project never does. Users see the tool working, and a small core group of users and stakeholders forms around it.

Hands off the configuration for at least a month after go-live. Fix only what is critical, so your priorities come from real usage rather than first-week noise. Then move into improvement sprints with a simple rhythm.

  1. Open a feedback channel in Teams or Slack where any user can flag what needs fixing or improving.

  2. Prioritize the list, then pick one or two items per two-week sprint.

  3. Ship the change, let it run for a few weeks, and review whether it worked.

  4. Come back monthly or quarterly for the bigger improvements.

Users see their feedback land, and that keeps them using the platform.

The real lesson

Forty-five days came from a vendor partner with a proven plan, a team that showed up ready, and a clear agreement on what “done” meant for launch.

I learned a lot from that vendor about shortening the path from onboarding to go-live. Those lessons now shape the MVP project schedule I use, one that strips out the noise, focuses on what launch actually requires, and scales from there.

What’s one thing your team always has ready before a vendor’s clock starts?

I help legal departments select and implement technology their teams actually use. Learn more at mvlegalops.com.

Comments


bottom of page