---
title: You Implemented the New Tool. Now You Have to Make It Stick.
description: How to Make New Systems Stick | Implemented a new tool but struggling with adoption? Here's 7 steps to make new systems part of daily work.
image: https://www.kerriequeen.com/hubfs/ChatGPT%20Image%20Oct%2026%2c%202026%2c%2011_42_44%20AM-2.png
---

[Skip to content](https://www.kerriequeen.com/patterns/software-adoption-after-implementation#main-content)

# Patterns INSIGHTS

[All posts](https://www.kerriequeen.com/patterns/all)

 October 26, 2026

# You Implemented the New Tool. Now You Have to Make It Stick.

![Picture of Kerrie Queen](https://app.hubspot.com/settings/avatar/09cfd2178550ec1983a95f27fd2b1bdf) By   Kerrie Queen  ·   8 minute read

Organizations spend a lot of time selecting and implementing technology. But the real goal was never to launch a tool. **The goal was to change how work gets done.**

The new project management system is live. You've built your workflows, configured and mapped your fields, and the team has been onboarded and completed training.

**Now, three weeks later:**  
Projects are still tracked in spreadsheets, client requests are sitting across inboxes, someone created their own way to use the system, and every status meeting starts with "So...where are we with this?"

**The implementation?** Done.  
**The adoption?** Not so much.  
And that distinction matters.

## ![02-implementation-vs-adoption](https://www.kerriequeen.com/hs-fs/hubfs/02-implementation-vs-adoption.webp?width=1448&height=1086&name=02-implementation-vs-adoption.webp)

## Implementation and adoption are different things.

**Implementation asks:**  
Is the system ready for people to use?

**Adoption asks:**  
Is this actually how people work now?

**And those are very different milestones.**

- You can configure a help desk perfectly, yet still have employees emailing requests directly to their favorite person.
- You can build a beautiful project management system, and account managers continue maintaining private spreadsheets.
- You can automate client onboarding, and someone keeps a handwritten checklist beside their computer because they trust it more.

None of those necessarily mean you chose the wrong technology.  
**It shows the new system has not replaced the old behavior yet.**  
And that requires more than training.

 

### Training teaches the tool. Enablement changes the work.

Training usually sounds something like this:

- Here is how you create a project.
- Here is how you update a status.
- Here is where you assign a task.
- Here is how you submit a request.

**Useful?** Absolutely.  
**Enough?** Usually not.

Because most employees do not need to know everything a tool *can* do.  
They need to know what **they are expected to do differently on Monday morning.**

The new process may be technically better. But if employees still think: "When something is urgent, I'll just message Sarah," then nothing has really changed.

**Your software has simply become another place information is supposed to go.**

 

## ![01-editorial-artwork](https://www.kerriequeen.com/hs-fs/hubfs/01-editorial-artwork.webp?width=800&height=600&name=01-editorial-artwork.webp)

## Design a system people actually use in 7 steps.

The best time to think about adoption is before implementation begins.

But even if the system is already live, the same principles can help identify why people aren't using it and what needs to change.

 

---

 

### 01 Start with the behavior that needs to change.

If you cannot clearly describe the behavior that should stop and the behavior that should replace it, the team probably cannot either.

Before any configuration begins, document the old behavior and the behavior that should replace it.

![03-old-vs-new-behavior](https://www.kerriequeen.com/hs-fs/hubfs/03-old-vs-new-behavior.webp?width=800&height=600&name=03-old-vs-new-behavior.webp)

These changes may sound simple, but they're the foundation of the entire system. **The goal isn't to recreate the old process inside new software. It's to establish a better way of working and use technology to support it.**

 

---

 

### 02 Design around the moments people actually need the system.

**Most people do not wake up thinking:**  
*"I would really like to use our project management platform today."*

**They are thinking:**  
What needs my attention?  
What am I waiting on?  
What does the client need?  
What is overdue?  
Who owns this?  
What happens next?

**Those are the questions your system should be designed to answer.**

Before configuring dashboards, workflows or automation, walk through how people actually work, what information they need, and what actions they need to take.

#### 1. What does each role need to know and do?

An account manager needs visibility into their clients, project status, upcoming milestones, and blockers.

An operations manager needs to understand workloads, ownership, deadlines, and exceptions.

Leadership needs to identify projects at risk, resource constraints, and potential client impact.

Same system. Different responsibilities. Different needs.

#### 2. How should that information be presented?

Rather than asking everyone to navigate the same dashboards, records and reports, create an operating view designed around their daily decisions.

For example:

**Account Manager**  
My active clients → Current projects → Status → Next milestone → Blockers

**Operations Manager**  
All active work → Owner → Priority → Due date → Capacity

**Leadership**  
Projects at risk → Delayed milestones → Client impact → Resource constraints

The goal is to make the right information immediately accessible, without requiring people to search for it.

#### 3. What actions should people be able to take?

Visibility alone isn't enough.

If an account manager sees that a project is delayed, can they quickly identify the blocker and who owns the next step?

If operations sees an overdue task, can they reassign it or adjust its priority?

If leadership identifies a project at risk, can they understand the impact without scheduling another status meeting?

The system should help people move work forward, not just report on what happened.

**Good system design starts with the decisions people need to make and the actions they need to take.**

 

---

 

### 03 Make the new way the easiest way to work.

Organizations sometimes design a new process but leave the old habits and workarounds intact.

That creates a choice.

- Submit a ticket **or** send an email.
- Update the project **or** tell someone in Slack.
- Add the client note **or** keep it in your personal document.
- Check the system **or** ask someone for an update.

Guess which option people choose when they are busy?  
Usually the one they already know.

Adoption becomes much harder when the ***official process requires more effort*** than the workaround.

**The new system should remove work, not simply relocate it.**

- If submitting a request requires twelve fields, people will avoid it.
- If project managers have to update the same information in three places, one of those places will eventually stop being updated.
- If account managers cannot quickly see the information they need, they will create their own tracker.

When adoption is low, do not immediately blame the users.  
**Study the friction.**  
Find out what makes the intended process harder than the alternative, then fix it.

 

---

 

### 04 Define where information lives.

One of the biggest reasons systems lose credibility is that nobody agrees on where information should live.

A project status exists in a spreadsheet. A deadline changes in an email. An approval happens in Slack.

The problem isn't necessarily that people are using different tools. It's that no one knows which one holds the most current, reliable information.

**Define a source of truth for each type of information, and make it clear who is responsible for keeping it accurate.**

That doesn't mean every conversation needs to happen inside the system.

People can collaborate in Slack, discuss projects in meetings, and communicate through email. But when those conversations result in a decision, a new task, a change in ownership, an updated deadline, or a client commitment, that information needs to be reflected in the appropriate system.

Otherwise, decisions happen in one place while the information people rely on lives somewhere else. And eventually, those two versions diverge.

**A system becomes valuable when people can trust the information inside it. And that trust depends on clear ownership, consistent updates, and knowing where to find the truth.**

 

---

 

### 05 Enable people around how they actually work.

Once you've defined the new operating model and designed the system around it, you need to help people make the transition.

**This is where enablement goes beyond traditional software training.**  
**Instead of organizing training around features, organize it around real work.**

An **account manager** shouldn't just learn how to update a project record. They should understand

- Where to start their day?
- How to identify clients needing attention?
- How to manage blockers or request help?
- Where to find information?

Operations managers and leadership will need guidance designed around their own responsibilities and decisions.

#### Teach people the workflows they'll actually use, in the situations where they'll need them.

That might include role-specific walkthroughs, short tutorial videos, simple process documentation, or hands-on practice with real examples.

**But enablement also requires clarity around expectations.**

- What information must be entered?
- Who is responsible for entering it?
- When does it need to be updated?
- What should someone do when a situation doesn't fit the defined process?
- And who should someone contact when something doesn't work as expected?

People should leave training knowing more than how to navigate a platform.  
They should understand how their work fits into the larger process and what is expected of them.

**The goal isn't to make everyone an expert in the software. It's to make everyone confident in the way they're expected to work.**

 

---

 

### 06 Make the system part of how the organization operates.

You tell the team that everything needs to be updated in the new system.

Then Monday rolls around, and leadership asks everyone to send over their spreadsheets.

Or a manager messages the team: "Can everyone send me their project updates?"

The team learns very quickly what actually matters.

**If managers continue requesting information outside the system, employees have little incentive to maintain it accurately.**

**Instead, make the system part of regular operations.**  
✔️ Run meetings from the project dashboard.  
✔️ Review overdue work directly from the system.  
✔️ Use ticket queues to discuss customer issues.  
✔️ Review ownership, priorities, and deadlines where they're recorded.  
✔️ When a status is missing, ask why it wasn't updated rather than simply requesting a verbal update.

This shifts the system from being a place where employees are told to enter information to the place where the organization actually manages its work.

And it creates a practical reason for people to keep information current.

If someone knows their project status will be reviewed directly in the system every Monday, maintaining that status becomes part of their regular responsibilities.

**Adoption gets stronger when leadership starts operating from the system, not just expecting everyone else to use it.**

 

---

 

### 07 Measure real behavior and continuously improve.

Your first version of the system won't be perfect. *That's fine.*

The people using the process every day will discover things you didn't anticipate.

A field is confusing.   
A status is missing.   
A notification arrives too late.   
Two categories mean almost the same thing.   
Someone has to click through four screens to answer a question they get ten times a day.

These aren't necessarily signs that the system is failing.  
**They're opportunities to improve it.**

#### 1. Create feedback loops immediately.

During the first few weeks after launch, actively collect feedback from the people doing the work.

**But ask specific questions.**

- Where did you leave the system to get something done?
- What did you have to enter twice?
- What information did you need but couldn't find?
- What steps felt unnecessary?
- What did you have to ask another person because the system couldn't tell you?

Those answers are far more useful than asking, "Do you like the new tool?"

But don't stop at collecting feedback. **Establish who is responsible for reviewing feedback, prioritizing changes, and making sure problems are addressed.** Otherwise, employees stop reporting issues and gradually return to their old workarounds.

#### 2. Measure adoption through behavior, not logins.

A login isn't adoption.  
Neither is completing a training session.

Look at whether the intended behavior is actually happening.   
**For a project management system, that might mean measuring:**

- Are active projects being updated?
- Are owners assigned?
- Are deadlines current?
- Are overdue tasks being addressed?
- Are teams using the agreed statuses consistently?
- Are managers running meetings from the system?

The question isn't simply, **"Are people using the tool?"**

The better question is:  
**"Is the work now happening the way we designed it to happen?"**

#### 3. Don't automate around bad adoption.

This is an important one.  
Organizations often see inconsistent usage and respond by adding more automation.

➕ More reminders.  
➕ More required fields.  
➕ More workflows.  
➕ More rules.

Sometimes that helps.  
Sometimes it just automates around a process nobody understands.

If people are not updating project status, first understand **why**.

Maybe they forget, or the status options do not match reality, or ownership is unclear, or updating the project requires too much work, or nobody actually uses the status after they enter it, or the organization has not agreed on what "On Track" means.

**Automation can reinforce a good operating model. It cannot create one.**

The goal is to keep learning from how people work, remove friction, clarify expectations, and improve the system over time.

Because adoption doesn't happen all at once.  
It happens as the designed system meets reality, and the organization adjusts.

 

## ![04-rollout-cycle](https://www.kerriequeen.com/hs-fs/hubfs/04-rollout-cycle.webp?width=800&height=600&name=04-rollout-cycle.webp)

## The rollout is not finished when the tool goes live.

A successful rollout isn't a single event.   
It's a continuous cycle: 

- Design the process around how work should happen.
- Enable people to follow that process.
- Use the system in daily operations.
- Improve what isn't working.
- And repeat as the organization's needs evolve.

**This is the part that many organizations miss.**  
They treat implementation as the finish line, when it's really the beginning of a new way of working.

Technology changes quickly. Teams grow. Responsibilities shift. Processes evolve.  
A system that worked perfectly on launch day may need to change six months later.

Building adoption into your approach means creating a system that can adapt along with the organization.

## A good system eventually becomes boring.

That is probably the best outcome.

Nobody celebrates that they successfully updated the project status.  
Nobody marvels at the ticket routing workflow.  
Nobody talks about how exciting the client request form is.

**They just work.**

- A request comes in.
- The right person gets it.
- Everyone can see what is happening.
- The next action is clear.
- The client gets an answer.
- The project moves forward.
- Nobody has to ask where the spreadsheet went.

**That is what successful technology adoption looks like.**

Not more people using software.  
A better way of working becoming the normal way of working.

[envelope icon](mailto:?body=https://www.kerriequeen.com/patterns/software-adoption-after-implementation)

Kerrie Queen   |   Patterns   |  Services   |  Collaborate   |   Start a Project

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Kerrie Queen",
    "url" : "https://www.kerriequeen.com/patterns/author/kerrie-queen"
  },
  "dateModified" : "2026-10-26T16:32:11.060Z",
  "datePublished" : "2026-10-26T16:16:39.000Z",
  "headline" : "You Implemented the New Tool. Now You Have to Make It Stick.",
  "image" : [ "https://www.kerriequeen.com/hubfs/ChatGPT%20Image%20Oct%2026%2c%202026%2c%2011_42_44%20AM-2.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://www.kerriequeen.com/patterns/software-adoption-after-implementation",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://www.kerriequeen.com/hubfs/4%20Dot%20Circle%20Logo%2c%20Transparent%20Background.png"
    }
  }
}
```

```json
{
  "@context" : "http://schema.org",
  "@type" : "Article",
  "author" : {
    "@type" : "Person",
    "name" : [ "Kerrie Queen" ]
  },
  "datePublished" : "2026-10-26T16:16:39+0000",
  "description" : "How to Make New Systems Stick | Implemented a new tool but struggling with adoption? Here's 7 steps to make new systems part of daily work. ",
  "headline" : "You Implemented the New Tool. Now You Have to Make It Stick.",
  "image" : "https://246717309.fs1.hubspotusercontent-na2.net/hubfs/246717309/ChatGPT%20Image%20Oct%2026%2c%202026%2c%2011_42_44%20AM-2.png",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://246717309.fs1.hubspotusercontent-na2.net/hubfs/246717309/4%20Dot%20Circle%20Logo%2c%20Transparent%20Background.png"
    },
    "name" : ""
  },
  "url" : "https://www.kerriequeen.com/patterns/software-adoption-after-implementation"
}
```