How to Manage Your Team's Time and Energy During a Salesforce (or Ticketure) Implementation

When it comes to big tech projects, it's not the dollars that cause delays.

It’s the hours...

The meeting hours.

The review hours.

The testing, re-testing, and “Can we hop on a quick Zoom?” hours.

And the energy those hours are costing your team. 

The success of your project comes down to the amount of time that you invest in your implementation. 

Because while you can easily set aside a monetary budget, protecting your team’s time and energy is not so straightforward. 

When you plan for time the same way you plan for dollars, you can avoid impacting the project's momentum. 

Let’s walk through how to do that — so your next implementation delivers the transformation you’re counting on without draining your team. 

1. Start With a Time Budget, Not Just a Dollar Budget

This might sound obvious, but it bears repeating. 

Budgeting dollars is straightforward. 

Everyone knows how to budget dollars. 

It’s neat and predictable. 

$XX for implementation
$XX/month for the tool
$XX for support

But time is messier, it’s fluid and difficult to nail down. 

It’s also very common to underestimate how much internal staff time is needed.

Here’s how to approach it:

• Identify which staff members need to participate week-to-week. (And take into consideration that it’s often your busiest, most knowledgeable people.)
  
  
• Estimate how many hours each of them can realistically give, not in a perfect world, but in the reality of running programs, serving visitors, and fundraising.
  
  
• Add a buffer. Projects will overlap with events, staff leave, or simply the “unexpected” that pops up in nonprofit life.

Foglight rule of thumb: At least 20% of your total project timeline should be reserved for testing and training.

2. Define Stakeholder Roles Early

One of the fastest ways to lose momentum is to let every decision swirl around in a big group. That leads to long meetings, slow approvals, and endless revisiting of decisions.

Instead, map out roles before you start:

• Product Owner: The end all be-all - the person with the authority to say yes or no. This keeps the project from stalling in decision fatigue-land.
  
  
• Subject Matter Experts: Staff who know the processes and data and can offer input on what needs to change. Often, this will be the head of the affected departments.
  
  
• Champions: Team members who are eager to model new behaviors and encourage adoption among peers.

Above all, the key is: clear expectations. 

Everyone should know why they’re at the table and what’s expected of them.

Larger organizations prone to consensus-oriented decision-making may want to consider decision frameworks like RAPID.

TL;DR

Keep the core decision-making team small. Involve others through structured checkpoints (like reviewing a prototype or testing a workflow) rather than pulling everyone into every meeting.

3. Create a Plan for Humans, not Robots 

Technology is a robot. 

You give it instructions, a code, and it acts on that. 

Humans are NOT robots. (As much as many organizations would like them to be.)

And change is tricky for us humans. 

Even for those who are excited about the change. They’re juggling dozens of competing priorities (inside and outside of work!) And learning a new way of working is intense and energy-draining. 

That’s why protecting people’s project time - and by extension, their energy - is essential.

Here are a few ways we’ve seen it work well: 

• Block time on calendars for recurring meetings and make them non-negotiable.
• Anticipate when workload will be heavier (like fundraising season, summer break, or a new exhibit) and avoid overlapping your project with them.
• Invest in training as a cornerstone of the project. Adoption requires repetition, iteration, and space to practice.
• Budget time for homework and other internal decision making.

Foglight insight: Weekly engagement beats occasional attendance every time. A consistently present core team drives momentum, while “drop-in” participation almost always derails it.

4. Build in Breathing Room

Even the best-planned, well-thought-out project timelines hit delays. 

And that is completely normal. Once again, it’s a sign you’re working with humans.

In addition to protecting your team’s time and energy, we recommend you add in a good chunk of wiggle room. 

• Allow extra time for decision-making. Approvals will take longer than you think.
• Plan for iteration. Your first draft workflow will rarely be your last, and that’s okay… it means you’re adapting the system to fit your real-world needs.
• Expect surprises. Staff turnover, a last-minute board request, or an urgent program can all shift priorities.

Pro tip: Add 10–15% flex time into your overall timeline, which usually amounts to around 6-weeks of wiggle room. A little breathing room now prevents frantic scrambling later.

How to Budget Time Strategically

We’ve spoken pretty conceptually above. 

So now we want to give you some realistic parameters around the time you and your team will ACTUALLY spend on a software implementation. 

For our typical projects, we recommend budgeting 4–8 hours per week of team participation over 6–8 months. 

For some key team members (especially product owners), this can be closer to 10–15 hours a week, and at certain phases, nearly a full-time job.

Knowing that, it’s important to build your project timeline backwards from your desired go-live date—and then pad it. 

Padding your project with extra weeks of contingency can be the difference between anxiety-ridden staff and smooth execution.

Every client and project is unique, and something will inevitably come up, be it surprise requirements, technical, or personnel.

And ALWAYS, always, always avoid going live during your busy seasons!

For zoos, museums, and aquariums, that means avoiding your Gala season, year-end fundraising, and periods of peak foot traffic.

Another factor impacting the schedule is often the expiration of the legacy system.

Here again, you want to leave some padding. 

Foglight Fun Fact: 75% of our projects have gone live in the 4 weeks of late September or Early October.)

Here’s what we’ve seen make the biggest difference:

Choose team members who want to own this. 

A single knowledgeable, excited power user can shift an entire department’s willingness to adopt a new system.

Take a true pause for training.

The more you formalize the training period, the more you cement the change. 

We highly recommend holding training on-site and in person because it creates a true sense of occasion and helps solidify this shift as part of your culture. 

In addition, it's important to keep training as close to go-live as possible. 

Plan a lunch-and-learn. Host an on-site walk-through.

Create an environment where your team has the space and capacity to really absorb what’s happening. 

Training that feels like an event will always stick better than a passive webinar.

Plan for post-launch support

You’ll need tweaks.

Questions will pop up.

Some staff may need an extra touch. 

Budget time and money for a “stabilization phase” after go-live to avoid frustration and backslide.

Budgeting Time & Energy = Happy, Engaged Employees!

You can buy best-in-class software.
You can hire a gold-standard implementation partner.

But if you don’t make time for your team to engage, learn, and lead the change, you’ll be stuck with an underused system and frustrated staff.

Buy yourself space.
Buy your team clarity.
Buy a timeline that respects your mission and your humans.

You don’t have to do it all—
Just do it intentionally.

P.S. Ready to start planning your system upgrade the right way? We’d love to help you map your calendar, assess your team’s bandwidth, and find your best window for success.