How Pflugerville and BerryDunn are pushing the envelope on parks and recreation innovation

We’ve all heard stories about organizations spending thousands on software projects, such as Enterprise Resource Planning (ERP), Electronic Health Record (EHR), or Student Information Systems (SIS) that take longer than expected to implement and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, Commercial Off-The-Shelf (COTS) enterprise system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost overruns).

These systems are complex, and implementation efforts impact both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

1. Should we purchase software that similar organizations have purchased?
   As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undefined? One way to identify your organization’s needs—and to avoid costly mistakes down the road—is to identify requirements during the procurement process.

2. What are the functional and technical requirements of the system?Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:
   
   Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses.” Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.
   
   Technical requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be requirements that define what database the system must support. For example, “The system must support use of the client preferred database.” They may also describe security capabilities of the system, the ability to import or export data, or the ease of use and overall end-user interface.

3. Who should help define and document requirements for the new enterprise system?
   
   When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.
   
   Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and those not so eager to change will help build the best system.
    
4. When do you revise enterprise system requirements? 
   It is always important to begin the software procurement process with a documented set of requirements; you need them to identify the best solution. The same goes for the implementation process where vendors use the requirements to guide the setup and configuration of the new system. But be prepared to revise and enhance requirements when a vendor solution offers an improved capability or a better method to achieve the results. The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and often delivers enhanced capabilities.

Be sure to document system requirements for an efficient process

There may be thousands of requirements for an enterprise system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

• Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
• Requirements help determine specific tasks and activities to address during the implementation process. While applications can’t always meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
• Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.

Our experienced consultants have led many software procurement projects and have firsthand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

There’s a good chance that your organization is in the position of needing to do more with less under the strain of staffing constraints and competing initiatives. With fewer resources to work with, you’ll need to be persuasive to get the green light on new enterprise technology initiatives. To do that, you need to present decision makers with well-thought-out and targeted business cases that show your initiative will have impact and will be successful. Yet developing such a business case is no walk in the park. Perhaps because our firm has its roots in New England, we sometimes compare this process to leading a hiking trip into the woods—into the wild. 

Just as in hiking, success in developing a business case for a new initiative boils down to planning, preparation, and applying a few key concepts we’ve learned from our travels. 

Consensus is critical when planning new technology initiatives

Before you can start the hike, everyone has to agree on some fundamentals: 

Who's going? 

Where are we going? 

When do we go and for how long? 

Getting everyone to agree requires clear communication and, yes, even a little salesmanship: “Trust me. The bears aren’t bad this time of year.” The same principle applies in proposing new technology initiatives; making sure everyone has bought into the basic framework of the initiative is critical to success.

Although many hiking trips involve groups of people similar in age, ability, and whereabouts, for your business initiative you need to communicate with diverse groups of colleagues at every level of the organization. Gaining consensus among people who bring a wide variety of skills and perspectives to the project can be complex.

To gain consensus, consider the intended audiences of your message and target the content to what will work for them. It should provide enough information for executive-level stakeholders to quickly understand the initiative and the path forward. It should give people responsible for implementation or who will provide specific skills substantive information to implement the plan. And remember: one of the most common reasons projects struggle to meet their stated objectives (and why some projects never materialize to begin with), is a lack of sponsorship and buy-in. The goal of a business case is to gain buy-in before project initiation, so your sponsors will actively support the project during implementation. 

Set clear goals for your enterprise technology project 

It’s refreshing to take the first steps, to feel that initial sense of freedom as you set off down the trail. Yet few people truly enjoy wandering around aimlessly in the wilderness for an extended period of time. Hikers need goals, like reaching a mountain peak or seeing famous landmarks, or hiking a predetermined number of miles per day. And having a trail guide is key in meeting those goals. 

For a new initiative, clearly define goals and objectives, as well as pain points your organization wishes to address. This is critical to ensuring that the project’s sponsors and implementation team are all on the same page. Identifying specific benefits of completing your initiative can help people keep their “eyes on the prize” when the project feels like an uphill climb.

Timelines provide additional detail and direction—and demonstrate to decision makers that you have considered multiple facets of the project, including any constraints, resource limitations, or scheduling conflicts. Identifying best practices to incorporate throughout the initiative enhances the value of a business case proposition, and positions the organization for success. By leveraging lessons learned on previous projects, and planning for and mitigating risk, the organization will begin to clear the path for a successful endeavor. 

Don’t compromise on the right equipment

Hiking can be an expensive, time-consuming hobby. While the quality of your equipment and the accuracy of your maps are crucial, you can do things with limited resources if you’re careful. Taking the time to research and purchase the right equipment, (like the right hiking boots), keeps your fun expedition from becoming a tortuous slog. 

Similarly, in developing a business case for a new initiative, you need to make sure that you identify the right resources in the right areas. We all live with resource constraints of one sort or another. The process of identifying resources, particularly for funding and staffing the project, will lead to fewer surprises down the path. As many government employees know all too well, it is better to be thorough in the budget planning process than to return to authorizing sources for additional funding while midstream in a project. 

Consider your possible outcomes

You cannot be too singularly focused in the wild; weather conditions change quickly, unexpected opportunities reveal themselves, and being able to adapt quickly is absolutely necessary in order for everyone to come home safely. Sometimes, you should take the trail less traveled, rest in the random lean-to that you and your group stumble upon, or go for a refreshing dip in a lake. By focusing on more than just one single objective, it often leads to more enjoyable, safe, and successful excursions.

This type of outlook is necessary to build a business case for a new initiative. You may need to step back during your initial planning and consider the full impact of the process, including on those outside your organization. For example, you may begin to identify ways in which the initiative could benefit both internal and external stakeholders, and plan to move forward in a slightly new direction. Let’s say you’re building a business case for a new land management and permitting software system. Take time to consider that this system may benefit citizens, contractors, and other organizations that interact with your department. This new perspective can help you strengthen your business case. 

Expect teamwork

A group that doesn’t practice teamwork won’t last long in the wild. In order to facilitate and promote teamwork, it’s important to recognize the skills and contributions of each and every person. Some have a better sense of direction, while some can more easily start campfires. And if you find yourself fortunate enough to be joined by a truly experienced hiker, make sure that you listen to what they have to say.

Doing the hard work to present a business case for a new initiative may feel like a solitary action at times, but it’s not. Most likely, there are other people in your organization who see the value in the initiative. Recognize and utilize their skills in your planning. We also suggest working with an experienced advisor who can leverage best practices and lessons learned from similar projects. Their experience will help you anticipate potential resistance and develop and articulate the mitigation strategies necessary to gain support for your initiative.

If you have thoughts, concerns, or questions, contact our team. We love to discuss the potential and pitfalls of new initiatives, and can help prepare you to head out into the wild. We’d love to hear any parallels with hiking and wilderness adventuring that you have as well. Let us know! 

BerryDunn’s local government consulting team has the experience to lead technology planning initiatives and develop actionable plans that help you think strategically and improve service delivery. We partner with you, maintaining flexibility and open lines of communication to help ensure that your team has the resources it needs.

Our team has broad and deep experience partnering with local government clients across the country to modernize technology-based business transformation projects and the decision-making and planning efforts. Our expertise includes software system assessments/planning/procurement and implementation project management; operational, management, and staffing assessments; information security; cost allocation studies; and data management.  

Read this if your organization is planning on upgrading or replacing an enterprise technology system.

It can be challenging and stressful to plan for technology initiatives, especially those that involve and impact every area of your organization. Common initiatives include software upgrades or replacements for:

• Financial management, such as Enterprise Resource Planning (ERP) systems
• Asset management systems
• Electronic health records (EHR) systems
• Permitting and inspections systems

Though the number of considerations when planning enterprise technology projects can be daunting, the greatest mistake you can make is not planning at all. By addressing just a few key areas, you can avoid some of the most common pitfalls, such as exceeding budget and schedule targets, experiencing scope creep, and losing buy-in among stakeholders. Here are some tips to help you navigate your next project:

Identify your IT project roles and resources

While most organizations understand the importance of identifying project stakeholder groups, it is often an afterthought. Defining these roles at the outset of your project helps you accurately estimate the work effort.

Your stakeholder groups may include:

• An executive sponsor
• A steering committee
• A project manager
• Functional leads
• A technical team

Once you’ve established the necessary roles, you can begin reviewing your organization’s resources to determine the people who will be available to fill them. Planning for resource availability will help you avoid delays, minimize impact to regular business processes, and reduce the likelihood of burnout. But this plan won’t remain static—you can expect to make updates throughout the project.

Establish clear goals and objectives to keep your technology project on track

It’s important that an enterprise technology project has established goals and objectives statements. These statements will help inform decision-making, provide benchmarks for progress, and measure your project’s success. They can then be referenced when key stakeholders have differing perspectives on the direction to take with a pending decision. For example, if the objective of your project is to reduce paper-based processes, you may plan for additional computer workstations and focus technical resources on provisioning them. You’ll also be able to measure your success in the reduction of paper-based tasks.

Estimate your IT project budget accurately

Project funding is hardly ever overlooked, but can be complex with project budgets that are either underestimated or estimated without sufficient rationale to withstand approval processes and subsequent budget analysis. You may find that breaking down estimates to a lower level of detail helps address these challenges. Most technology projects incur costs in three key areas:

• Vendor cost: This could include both one-time software implementation costs as well as recurring costs for maintenance and ongoing support.
• Infrastructure cost: Consider the cost of any investments needed to support your project, such as data center hardware, networking components, or computing devices.
• Supplemental resource cost: Don’t forget to include the cost of any additional resources needed for their specialized knowledge or to simply backfill project staff. This could include contracted resources or the additional cost of existing resources (i.e., overtime).

A good technology project budget also includes a contingency amount. This amount will depend on your organization’s standards, the relative level of confidence in your estimates, and the relative risk.

Anticipate the need for change management

Depending on the project, staff in many areas of your organization will be impacted by some level of change during a technology implementation. External stakeholders, such as vendors and the public, may also be affected. You can effectively manage this change by proactively identifying areas of likely change resistance and creating strategies to address them.

In any technology implementation, you will encounter change resistance you did not predict. Having strategies in place will help you react quickly and effectively. Some proven change management strategies include communicating throughout your project, involving stakeholders to get their buy-in, and helping ensure management has the right amount of information to share with their employees.

Maintain focus and stay flexible as you manage your IT project

Even with the most thought-out planning, unforeseen events and external factors may impact your technology project. Establish mechanisms to regularly and proactively monitor project status so that you can address material risks and issues before their impact to the project grows. Reacting to these items as they arise requires key project stakeholders to be flexible. Key stakeholders must recognize that new information does not necessarily mean previous decisions were made in error, and that it is better to adapt than to stick to the initial direction.

Whether you’re implementing an ERP, an EHR, or enterprise human resources or asset management systems, any enterprise technology project is a massive undertaking, involving significant investment and a coordinated effort with individuals across multiple areas of an organization. Common mistakes can be costly, but having a structured approach to your planning can help avoid pitfalls. Our experienced, objective advisors have worked with public and private organizations across the country to oversee large enterprise projects from inception to successful completion.

Contact our software consulting team with any questions.

Read this if you are interested in building a thriving workforce.

As businesses across the country continue to struggle to find and keep employees during the pandemic-influenced Great Resignation, it is time to build a workplace that sends a clear message to employees: “We care about you as a person. We trust you to do great work. Your well-being matters.” 

Many leaders and HR teams will send communications that emphasize the importance of people and the value of well-being. Despite this messaging, many organizations are missing opportunities to make well-being a natural part of day-to-day operations. The resulting disconnect between messaging and reality can result in employee frustration, disengagement, and cynicism. We’ve compiled a list of some of the most common workplace factors that can disrupt an organization’s intentions to build a strong well-being culture. 

Negative influences on building a strong well-being culture

 

Overcoming the challenges to your well-being goals takes time. And while it is natural for organizations to think of employee well-being as the responsibility of human resources and leadership, in reality well-being is a product of every part of the employee experience. In other words, it’s everyone’s job.

Well-being program considerations

Understanding the pain points for employees is an essential element of any successful well-being program, even if those pain points exist outside the domain of traditional well-being and wellness programs. Here are some things to consider:

• Find out what matters to your employees, as every organization is different. Use surveys, interviews, and focus groups to understand priorities and do something meaningful with what you learn.
• Make a plan to address operational challenges. Put simply, outdated technology and inefficient business processes stress employees out.
• Assess your well-being strategy to identify strengths, gaps, and opportunities for improvement.
• Develop and implement a strategic well-being plan that aligns with your organizational culture and goals. 
• In the midst of planning a big system implementation of organizational change? Consider ways to integrate well-being as part of high-stress initiatives. 

Does your organization’s messaging about well-being line up with the employee experience? Have questions or need ideas about your specific situation? Contact our well-being consulting team. We’re here to help.

Read this if your agency is planning to procure a services vendor.

In our previous article, we looked at three primary areas we, or a potential vendor, consider when responding to a request for services. In this follow-up, we look at additional factors that influence the decision-making process on whether a potential vendor decides to respond to a request for services.

• Relationship with this state/entity―Is this a state or client that we have worked with before? Do we understand their business and their needs?
  
  A continuing relationship allows us to understand the client’s culture and enables us to perform effectively and efficiently. By establishing a good relationship, we can assure the client that we can perform the services as outlined and at a fair cost.
• Terms and conditions, performance bonds, or service level agreements―Are any of these items unacceptable? If there are concerns, can we request exceptions or negotiate with the state?
  
  When we review a request for services our legal and executive teams assess the risk of agreeing to the state’s terms and compare them against our existing contract language. States might consider requesting vendors provide exceptions to terms and conditions in their bid response to open the door for negotiations. Not allowing exceptions can result in vendors assuming that all terms are non-negotiable and may limit the amount of vendor bid responses received or increase the cost of the proposal.
  
  The inclusion of well-defined service level agreements (SLAs) in requests for proposals (RFPs) can be an effective way to manage resulting contracts. However, SLAs with undefined or punitive performance standards, compliance calculations, and remedies can also cause a vendor to consider whether to submit a bid response.
  
  RFPs for states that require performance bonds may result in significantly fewer proposals submitted, as the cost of a performance bond may make the total cost of the project too high to be successfully completed. If not required by law that vendors obtain performance bonds, states may want to explore other effective contractual protections that are more impactful than performance bonds, such as SLAs, warranties, and acceptance criteria.
• Mandatory requirements―Are we able to meet the mandatory requirements? Does the cost of meeting these requirements keep us in a competitive range?
  
  Understanding the dichotomy between mandatory requirements and terms and conditions can be challenging, because in essence, mandatory requirements are non-negotiable terms and conditions. A state may consider organizing mandatory requirements into categories (e.g., system requirements, project requirements, state and federal regulations). This can help potential vendors determine whether all of the mandatory requirements are truly non-negotiable. Typically, vendors are prepared to meet all regulatory requirements, but not necessarily all project requirements.
• Onsite/offsite requirements―Can we meet the onsite/offsite requirements? Do we already have nearby resources available? Are any location requirements negotiable?
  
  Onsite/offsite requirements have a direct impact on the project cost. Factors include accessibility of the onsite location, frequency of required onsite participation, and what positions/roles are required to be onsite or local. These requirements can make the resource pool much smaller when RFPs require staff to be located in the state office or require full-time onsite presence. And as a result, we may decide not to respond to the RFP.
  
  If the state specifies an onsite presence for general positions (e.g., project managers and business analysts), but is more flexible on onsite requirements for technical niche roles, the state may receive more responses to their request for services and/or more qualified consultants.
• Due date of the proposal―Do we have the available proposal staff and subject matter experts to complete a quality proposal in the time given?
  
  We consider several factors when looking at the due date, including scope, the amount of work necessary to complete a quality response, and the proposal’s due date. A proposal with a very short due date that requires significant work presents a challenge and may result in less quality responses received.
• Vendor available staffing―Do we have qualified staff available for this project? Do we need to work with subcontractors to get a complete team?
  
  We evaluate when the work is scheduled to begin to ensure we have the ability to provide qualified staff and obtain agreements with subcontractors. Overly strict qualifications that narrow the pool of qualified staff can affect whether we are able to respond. A state might consider whether key staff really needs a specific certification or skill or, instead, the proven ability to do the required work.
  
  For example, technical staff may not have worked on this particular type of project, but on a similar one with easily transferable skills. We have several long-term relationships with our subcontractors and find they can be an integral part of the services we propose. If carefully managed and vetted, we feel subcontractors can be an added value for the states.
• Required certifications (e.g., Project Management Professional^® (PMP^®), Cybersecurity and Infrastructure Security Agency (CISA) certification)―Does our staff have the required certifications that are needed to complete this project?
  
  Many projects requests require specific certifications. On a small project, maybe other certifications can help ensure that we have the skills required for a successful project. Smaller vendors, particularly, might not have PMP®-certified staff and so may be prohibited from proposing on a project that they could perform with high quality.
• Project timeline―Is the timeline to complete the project reasonable and is our staff available during the timeframe needed for each position for the length of the project?
  
  A realistic and reasonable timeline is critical for the success of a project. This is a factor we consider as we identify any clear or potential risks. A qualified vendor will not provide a proposal response to an unrealistic project timeline, without requesting either to negotiate the contract or requesting a change order later in the project. If the timeline is unrealistic, the state also runs the risk that the vendor will create many change requests, leading to a higher cost.

Other things we consider when responding to a request for services include: is there a reasonable published budget, what are the minority/women-owned business (M/WBE) requirements, and are these new services that we are interested in and do they fit within our company's overall business objectives?

Every vendor may have their own checklist and/or process that they go through before making a decision to propose on new services. We are aware that states and their agencies want a wide-variety of high-quality responses from which to choose. Understanding the key areas that a proposer evaluates may help states provide requirements that lead to more high-quality and better value proposals. If you would like to learn more about our process, or have specific questions, please contact the Medicaid Consulting team.

Read this if your agency is planning to procure a services vendor. 

Every published request for services aims to acquire the highest-quality services for the best value. Requests may be as simple as an email to a qualified vendor list or as formal as a request for proposal (RFP) published on a state’s procurement website. However big or small the request, upon receiving it, we, or a potential vendor, triages it using the following primary criteria:

1. Scope of services―Are these services or solutions we can provide? If we can’t provide the entire scope of services, do we have partners that can?
   As a potential responding vendor, we review the scope of services to see if it is clearly defined and provides enough detail to help us make a decision to pursue the proposal. Part of this review is to check if there are specific requests for products or solutions, and if the requests are for products or solutions that we provide or that we can easily procure to support the scope of work. 
2. Qualifications―What are the requirements and can we meet them?
   We verify that we can supply proofs of concept to validate experience and qualification requirements. We check to see if the requirements and required services/solutions are clearly defined and we confirm that we have the proof of experience to show the client. Strict or inflexible requirements may mean a new vendor is unable to propose new and innovative services and may not be the right fit.
3. Value―Is this a service request that we can add value to? Will it provide fair compensation?
   We look to see if we can perform the services or provide the solution at a rate that meets the client’s budget. Sometimes, depending upon the scope of services, we can provide services at a rate typically lower than our competitors. Or, conversely, though we can perform the scope of services, the software/hardware we would have to purchase might make our cost lower in value to the client than a well-positioned competitor.

An answer of “no” on any of the above questions typically means that we will pass on responding to the opportunity. 

The above questions are primary considerations. There are other factors when we consider an opportunity, such as where the work is located in comparison to our available resources and if there is an incumbent vendor with a solid and successful history. We will consider these and other factors in our next article. If you would like to learn more about our process, or have specific questions, please contact the Medicaid Consulting team.
 

Read this if you are planning for, or are in the process of implementing a new software solution.

User Acceptance Testing (UAT) is more than just another step in the implementation of a software solution. It can verify system functionality, increase the opportunity for a successful project, and create additional training opportunities for your team to adapt to the new software quickly. Independent verification through a structured user acceptance plan is essential for a smooth transition from a development environment to a production environment. 

Verification of functionality

The primary purpose of UAT is to verify that a system is ready to go live. Much of UAT is like performing a pre-flight checklist on an aircraft. Wings... check, engines... check, tires... check. A structured approach to UAT can verify that everything is working prior to rolling out a new software system for everyone to use. 

To hold vendors accountable for their contractual obligations, we recommend an agency test each functional and technical requirement identified in the statement of work portion of their contract. 

It is also recommended that the agency verify the functional and technical requirements that the vendor replied positivity to in the RFP for the system you are implementing. 

Easing the transition to a new software

Operational change management (OCM) is a term that describes a methodology for making the switch to a new software solution. Think of implementing a new software solution like learning a new language. For some employees, the legacy software solution is the only way they know how to do their job. Like learning a new language, changing the way business and learning a new software can be a challenging and scary task. The benefits outweigh the anxiety associated with learning a new language. You can communicate with a broader group of people, and maybe even travel the world! This is also true for learning a new software solution; there are new and exciting ways to perform your job.

Throughout all organizations there will be some employees resistant to change. Getting those employees involved in UAT can help. By involving them in testing the new system and providing feedback prior to implementation, they will feel ownership and be less likely to resist the change. In our experience, some of the most resistant employees, once involved in the process, become the biggest champions of the new system.  

Training and testing for better results

On top of the OCM and verification benefits a structured UAT can accomplish, UAT can be a great training opportunity. An agency needs to be able to perform actions of the tested functionality. For example, if an agency is testing a software’s ability to import a document, then a tester needs to be trained on how to do that task. By performing this task, the tester learns how to login to the software, navigate the software, and perform tasks that the end user will be accomplishing in their daily use of the new software. 

Effective UAT and change management

We have observed agencies that have installed software that was either not fully configured or the final product was not what was expected when the project started. The only way to know that software works how you want is to test it using business-driven scenarios. BerryDunn has developed a UAT process, customizable to each client, which includes a UAT tracking tool. This process and related tool helps to ensure that we inspect each item and develop steps to resolve issues when the software doesn’t function as expected. 

We also incorporate change management into all aspects of a project and find that the UAT process is the optimal time to do so. Following established and proven approaches for change management during UAT is another opportunity to optimize implementation of a new software solution. 

By building a structured approach to UAT, you can enjoy additional benefits, as additional training and OCM benefits can make the difference between forming a positive or a negative reaction to the new software. By conducting a structured and thorough UAT, you can help your users gain confidence in the process, and increase adoption of the new software. 

Please contact the team if you have specific questions relating to your specific needs, or to see how we can help your agency validate the new system’s functionality and reduce resistance to the software. We’re here to help.