2025 project trends: Do more with less

Five case studies where project managers improved user adoption using targeted change strategies

Executive summary

Current environments require program leaders and project managers to think differently about change. Rather than using a peanut butter approach, targeted organizational change solutions help project teams avoid people-related risks and costly fixes. Five case studies of projects show how targeted organizational change solutions achieve better outcomes, reduce risks, and avoid costs.

The same thinking that got you here won’t get you there.

For 70 percent of project teams, “here” means failure. Projects are still far more likely to fail than to succeed.

There are many reasons why projects fail. Common mistakes and missteps are well-documented.

Poor user adoption is always in the mix because let's face it, people are complicated.

Despite widespread use of organizational change toolkits, methodologies, and professional change management practitioners, project teams still haven’t mastered the people side. With current resource-constrained environments, more project teams are exploring different ways to address this perennial challenge.

Change is a complicated and expensive problem for organizations of all sizes. Organizations have tried many ways of solving it:

• Hiring expensive consulting firms
• Rolling out toolkits
• Using internal practitioners, such as training and communication professionals
• Adding change duties to the project manager’s responsibilities
• Staff augmentation through organizational change management contractors
• And, now, many are looking at how AI can fill gaps

Finding a solution to the change challenge is particularly difficult for technology-based projects, where things move fast and have more complexity. It can be high risk and high cost. Often, these types of investments get made once a decade, and budgeting for the people side can be ambiguous.

The roles that repeatedly face this challenge are program leaders and project managers. They combine the internal business and IT professionals with external experts to implement the solution. They are also the people who have to figure out how to do more with less in resource-constrained environments like what's happening right now.

This Project Trends Report reviews five case studies that improved user adoption, reduced people-based risks, and avoided costs. These projects achieved better outcomes not by spending and doing more, but by being smart about why and what they were doing on the people side.

The best practices and principles identified help program leaders and project managers think differently about user adoption, regardless of the size of the project or size of the organization.

Stop using a peanut butter approach to organizational change

Before jumping into the case studies, let’s review an important fundamental shift that savvy leaders and project managers make: They stop using a peanut butter approach to organizational change. They start getting targeted about solving people risks.

Consider this: Many projects are solving change as though they needed only one IT professional to deliver application architecture, API integration development, and security provisioning.

Is it possible to find one person who can do it all? Of course.

Will all those activities get done well? Probably not.

The same logic applies to the people side of projects. As the complexity increases with specific technology implementation projects, there’s even more risk in approaching the people side using a single professional.

Consulting teams with deep benches address this gap, but that expensive solution is out of reach for many organizations. It's simply not an option when resources are tight.

Despite these types of constraints, project managers are finding new ways to get smart about project-based change. Let’s look at five targeted, innovative ways that real projects have used to address user adoption challenges in resource-constrained environments.

1.  Gather feedback to strategically influence people

Projects have become synonymous with change.

Very few people have a positive, confident feeling when they hear “change is coming” or “a new project is being launched”. Most people respond fearfully, with dread and apprehension.

There’s too much of it, it’s happening too fast, it’s being done “to” me, and I don’t have a history of successfully navigating it. It’s no wonder people find project-based change frustrating.

Project managers know that sometimes leaders need to hear feedback about this challenge directly from stakeholders. It’s a coaching-up method effective at helping leaders build empathy for users.

In one financial recordkeeping system implementation, the project manager supported a targeted survey of finance team members to understand whether the resources assigned to the project team had enough time to complete their activities.

They suspected this answer was “No” but a survey would bring forward actionable data to share with leaders.

Feedback was collected anonymously via an online survey so that employees felt comfortable sharing concerns:

“What project? I haven’t heard about this yet. I don’t know what you’re talking about.”

“When are we going to get trained?”

“Who’s going to help me?”

The survey revealed that several finance team members were overwhelmed by the addition of project activities on top of their regular job duties.

This was an especially large risk for one key role. This person would significantly expand their responsibilities, including managing twice as many users, which meant double the security provisioning duties (a tedious task in the new system).

That one key role became a people-based risk, representing a single point of failure for the entire multimillion-dollar project.

The survey also revealed that less than 10 percent of functional users felt confident about the project team’s ability to deliver on the business case--the promise to make their jobs easier. This was based on long memories from the last implementation, in which users were poorly supported.

The comments in the survey about training timing were an indicator of change resistance. If not addressed early and consistently, the resistance would grow.

As a result of the survey feedback, key team members were identified to begin leading informal demonstrations with their peers as the system was being built. This helped the core project team build confidence. Those same experts would become “go-to” help for their peers during the go-live.

What risks were reduced and costs avoided?

This project avoided two key risks:

1. Identifying the need for additional support in a key role. Adjusting early avoided this role from becoming a single point of failure for the project.
2. Failed user adoption among the core functional users. By building skills early within the team, a broad-based support network was created within the function, capable of teaching and supporting peers during the rollout. This would have been an expensive mistake and reputational risk, given that the launch coincided with the annual budgeting cycle in which finance team members were front and center in the organization.

Using a simple survey that helped project and business leadership understand people’s perceptions and beliefs about the change surfaced these and other risks.

2.  Front-load organizational change activities

Successful project teams front-load organizational change activities. They understand that change is more than PowerPoint training decks and email blasts delivered at go-live.

Let’s look at a case study where a successful project started change activities early in its six-month deployment.

The project was a core HCM Workday implementation (not including payroll). It impacted approximately 600 users in the United States who were part of a division of a larger enterprise that had already implemented a full suite of Workday HCM.

The obvious organizational change solution would have been to dust off the communications and training materials used in the prior deployment. Had the team used that approach, they would have missed three critical things:

1. A unique role specific to this division’s location-based approach to supporting managers and employees. This role would continue to support payroll-based questions, but would not have Workday access.
2. An unclear WIIFM for managers and employees who needed to check two systems (Workday and the existing payroll system) to find answers to the most common questions about pay.
3. The vital responsibility of the HR business partner to understand support flows for their business team partners so they could direct people to get help/answers fast.

Starting conversations early with stakeholders about existing business processes and roles uncovered these critical change impacts early enough to address them. This uniqueness required different activities from just reusing the training and launch communication materials to prepare the team.

What risks were reduced and costs avoided?

This project avoided two key risks:

1. Creating user backlash from location supervisors and employees by failing to equip existing embedded resources – the unique role identified early -- with the ability to answer common pay questions. This role needed access to both Workday and the existing payroll system. Security adjustments were made early enough to avoid backlash from users.
2. Failed user adoption among the core functional users. By involving the HR team early in reviewing roles and responsibilities, these professionals became experts in the entire solution. They understood how to perform transactions in the system, but they also knew who did what, so they could resolve questions and support quickly. They were the ones to identify and advocate for the unique role to have access to Workday in addition to the payroll system. 

The program manager was savvy by insisting on early change assessment activities to uncover change impacts. Like most platforms, Workday HCM has its benefits and challenges when implementing.

3.  Design project team activities as on-the-job learning

Thus far, we’ve looked at two targeted ways project managers can improve user adoption early on in projects:

1. Gather feedback to influence people strategically
2. Front-load organizational change activities to prevent risks

A third best practice done early on serves a dual purpose. What needs to get done, and:

3.  How might this project activity be used to develop people?

In one Workday HCM implementation, the program manager looked at the iterative rounds of development needed and the high workload of the core project team and questioned whether the deployment timeline was even realistic.

Options were brainstormed, including having the system implementers take on some responsibilities. Rather than outsource and incur extra costs, the team relied on its internal subject matter experts within each specialty area.

The team leveraged a watch one-do one-teach one approach to build internal capabilities.

Workstream leads facilitated internal demos during the configuration phase, participated in stakeholder preview sessions within the broader organization, completed testing activities, and finally, helped fine-tune training documentation. Some team members even led training sessions.

This program leader recognized the importance of using project activities as on-the-job learning for key people. Clear expectations were established early with the internal workstream lead role, along with providing them the support to do it.

They understood that on-the-job learning would set them up for success at go-live, and their peers would see them as experts.

Successful project teams leverage design thinking to help project teams achieve more without doing more by using project activities as on-the-job learning.

What risks were reduced and costs avoided?

This project avoided:

1. Extra expenses by doing the activities in-house rather than outsourcing them.
2. Failed user adoption among the core functional users. By building skills early within the team, core subject matter experts became capable and confident to teach others.
3. Missing the launch date.

By understanding who needed to develop key skills and how project activities could enable that through on-the job learning, this project avoided costs and timeline risks. It also helped the core team feel confident and capable.

4.  Involve users to avoid surprises

The middle of any project is where things get messy. It requires being nimble, adaptable, and focused. A high degree of uncertainty persists while the technical solution is being developed, and things are not yet clear to the project team and stakeholders.

The messy middle is where project managers take the possibility of success and increase the likelihood of it by involving stakeholders to avoid surprises.

With the uncertainty of a system that’s not yet ready, project managers might think waiting to share it with stakeholders is the safer route. It also takes sophisticated people skills to coordinate the demo sessions, collect feedback, and facilitate actions from the sessions.

But savvy project managers know that those additional activities of involving users early help avoid potentially costly surprises. People are more likely to feel a sense of ownership when they have input early that influences decisions.

One example of this was a full suite implementation of Workday HCM, Payroll, and Financials in an organization that had more than doubled in size through a recent acquisition.

The project team delivered preview demos to an extended set of leaders within the newly combined organization. These previews helped identify core business processes and role differences between the two previously distinct companies.

There were entire groups of people and roles that needed to be mapped to system responsibilities. Those gaps would not have been identified without the early user demos.

Systems such as Workday HCM make this iterative process easy to do. Successful projects incorporate this method so that they identify “gotcha” moments early and have time to address gaps in functionality. It’s better to find a surprise gap during design and build than after go-live.

What risks were reduced and costs avoided?

This project avoided:

1. Costly security and business process configuration fixes post-go-live.
2. Failed user adoption and a reputational hit by overlooking existing roles and processes in the two organizations.

5.  Influence from within the project team

Project managers sometimes find themselves in unfamiliar situations that require deep subject matter expertise, such as a project that supports a specialized function. It’s these kinds of projects that can be high-risk because they are complex from both a technology and business perspective.

These projects require help translating from within the business team. Let’s return to the case study of the financial recordkeeping implementation.

The project manager identified the need for a business representative from within the finance team.

This finance professional provided much-needed support as a liaison to peers within the finance function. They supported the project manager by:

• Translating business requirements for the technical team
• Leading the role-based security provisioning to make sure each finance team member had the right access
• Coordinating the testing of those requirements by the right finance specialists to help reduce defects
• Updating the finance team on progress formally through finance team meetings and informally through hallway conversations and impromptu discussions.

This liaison to the finance function served as a business change lead. They effectively supported the project manager through a regular rhythm of involving stakeholders that reduced surprises, which are the typical cause of frustration for users. This person was also the "go to" coordinator within the function whenever people had questions. It saved the project manager hours!

What risks were reduced and costs avoided?

This project avoided:

1. Costly design mistakes by coordinating feedback from finance users. 
2. Higher project management costs as a result of the PM spending time coordinating finance user feedback, and questions.
3. Costly oversubscription of licenses by not clearly defining role-based security requirements for finance users.

Project managers who deliver successfully look for resources within the team to help manage stakeholders, a somewhat less tangible type of change activity that supports building clarity during the messy middle of projects.

The business change lead role is one where projects build capabilities while improving people-related outcomes.

Successful projects get smarter about reducing risks and costs using innovative, targeted organizational change activities. They do more with less.

Project managers who want to deliver better outcomes on their projects look for ways to increase the probability that things will be delivered on time, on budget, and meet quality expectations.

In current environments, that's even more challenging. But constraints are also an opportunity to look at how to do things differently.

These five case studies show how to do more with less by:

1. Using feedback to strategically influence people
2. Front-loading organizational change activities
3. Designing on-the-job learning through project activities
4. Involving stakeholders to avoid surprises
5. Influencing from within through the business change lead role

The days of using a peanut butter approach to organizational change are over. The trends of project-based change are to do more with less. That helps teams be strategic and nimble using targeted approaches.

Download the one-page tip sheet summarizing these best practices and targeted solutions so you know what to watch for in your projects. 

Learn about my Change Advisory services that help leaders and project managers design targeted change solutions to do more with less.