When Tools Collide: Managing the Clash of Vendor and Internal Toolsets

As a technology leader at your institution, you are facilitating the implementation of a major new technology tool. You have engaged a partner for assistance, executive approval is in place, and your team is prepared. The implementation partner presents the project plan, task structure, and process outline, all of which will be managed through the partner's project management platform. The implementation partner also insists that all communications about the project be submitted through this tool rather than through standard email communications. This technology, along with the methods and behaviors expected from the implementation partner, is foreign to your organization.

Does this scenario sound familiar?

Every higher education institution develops norms and practices regarding how it organizes, prioritizes, and executes work. Whether formally or informally, projects are typically managed using a set of tools that are well-known within that environment. Colleges and universities with an established project management office often have mandated tools, templates, and structures designed to support governance processes, institutional prioritization, resource capacity tracking, forecasting, and related activities. These frameworks serve a specific purpose, and challenges can arise when processes or resources do not align with them.

Implementation partners also rely on a standardized playbook and project templates to ensure consistent results across clients. While this structured approach allows vendors to efficiently replicate their processes, it may not meet the specific needs of the institution. This raises several important customer service-related questions: Should customers be expected to adapt to a new tool and alter their organizational workflows, or should the provider be responsible for aligning service delivery in a way that offers value to the customer and elevates the customer experience? In other words, is there a more collaborative and effective way to manage technology implementations?

First, let's outline the role of project and portfolio management (PPM) software in a higher education institution. PPM applications help support the following business processes:

• Governance processes
• Organizational prioritization
• Forecasting and strategic planning
• Resource capacity tracking
• Project planning and task management

The first three processes can be tracked at a macro level by both the implementation partner and the customer. Resource capacity tracking may introduce challenges depending on how closely each partner manages its resources. Integration partners typically have data on average implementation times, but customers often find that initial estimates do not align with the actual effort required. More accurate resource estimates could benefit future engagements for implementation partners if they have access to their customers' task-level data. However, since customers are responsible for tracking and possess varying skill sets, the value of this data for generating accurate estimates is questionable.

The processes that present the most significant problems with disparate systems are project planning and task management. Most implementation partners have a pre-built set of files with a generic outline of the various project phases they use for clients (see figure 1).

Figure 1. Simplified Project Implementation Timeline with Key Milestones

This plan can be easily adjusted to meet individual client needs and timelines, and the initial tasks are typically outlined at a high level. For example, data integrations with key systems, such as an enterprise resource planning (ERP) or a customer relationship management (CRM) system, would simply be captured as "configure the data integration to system A."

From there, the customer would break this complex task into numerous subtasks involving various teams and colleagues. The project manager for the customer institution would then assign and track those granular tasks, due dates, and dependencies. Here lies the central dilemma: Should these steps be managed within the vendor's tool (which may be unfamiliar to and resisted by internal teams), or should project teams utilize their own internal systems to facilitate these efforts? The decision to use two tools can significantly impact workflows, as managing tasks across two systems increases the administrative burden on both vendor and customer project managers. Through the lens of Lean Six Sigma principles, this duplication is nothing but waste through excessive processing.

So, what are the options?

Option 1: Do Nothing

For institutions that do not have mature project management processes, doing nothing may be a reasonable solution. The implementation partner would provide the framework, project management system, and overall project management structure for the work (see figure 2). The implementation partner should also ensure that the software is configured in a way that minimizes the onboarding effort and ensures licensing is not an impediment for the customer. For smaller teams, this may be the most feasible option.

Figure 2. Implementation Partner Supplied Software and Structure

Option 2: Use the Toolset and Processes Familiar to the Customer

Negotiating how the work will be managed can be an important step in the evaluation or contracting process. Institutions with mature project management offices or larger teams often have several other projects underway and make use of established tools and processes (figure 3). Using the organization's established project oversight helps to ensure timely completion while minimizing disruption to the teams. The implementation partner can provide the task framework and general timelines in formats that can be imported into the customer's project management tool, ensuring a consistent overall structure. The key is to meet the customers where they are in their own system.

Figure 3. Organization Supplied Software and Structure

Option 3: Use Two Systems Strategically and Minimize Duplication

It is possible to use two separate systems and minimize the duplication of effort required to keep them in sync. One system could track the higher-level framework (such as the implementation partner's software), while the other system could provide more granular details of customer tasks. This approach enables the customer to benefit from an agile project management method rather than a traditional waterfall plan. The customer would focus on the next set of tasks for each sprint, while the implementation partner oversees the broader timeline and progress toward the project's major milestones (see figure 3).

Figure 4. Hybrid Use of Project Structures

While systems that streamline and integrate communication within the tool can be valuable (for example, all communication is provided by and captured within the project system), this approach rarely works effectively across implementation partners and customers. Customers are typically involved in multiple initiatives simultaneously. Expecting customers to log in to multiple systems to communicate basic questions or updates is unrealistic. Forcing customers to communicate only through the project platform results in a poor customer experience and lays the groundwork for an adversarial relationship.

Option 4: Apply a Decision Framework to Determine Which System to Use

A clear decision framework or rubric can help determine which system should serve as the primary source of truth. For instance, if the implementation partner is carrying out most of the work, it often makes sense for the customer to use the partner's system to streamline coordination and reduce duplication. If the implementation partner has a large team assigned and is responsible for completing most of the tasks, it may make sense for the customer to adapt to the partner's system. In other words, a large part of the decision is about the resources.

It may be helpful to outline the expected project management framework and methodology during the contracting phase, whether the organization is the provider or an implementation partner. The best time to define and agree on the framework and methods for implementing the project is during the contract negotiation or request for proposal stage. This is a great time to request a tour of the project plan, ask to be added to the partner's system, understand the communication norms, and negotiate the options described above. Changes and negotiations become extremely difficult after the master services agreement and statement of work are countersigned. Plan early and iterate until you are comfortable with the methodology.

Institutions with robust project management processes should bring in the project managers early to ensure a practical solution is designed. Those that lack mature project management capabilities may welcome a partner that does the heavy lifting on their behalf. Regardless, it's important to have a clear understanding of the work to be done and its complexity.

Conclusion

Successful project implementation requires flexibility, communication, and collaboration between the customer and the implementation partner. A single methodology or tool that primarily serves the needs of the implementation partner should not be the only option. By considering the options outlined above, colleges and universities can find a balance that minimizes internal disruption and maximizes efficiency. Early planning and negotiation are crucial to ensuring that both parties are aligned and that the project management strategy effectively serves the customer's needs. Ultimately, the goal is to achieve a successful project outcome that benefits both the customer and the implementation partner.

---

Curt Herridge is Associate Chief Information Officer for Data and Application Services at Southern Methodist University.

Rachel Mulry is Associate Chief Information Officer for Planning and Customer Services at Southern Methodist University.