Enterprise Applications: 4 Characteristics of Successful Client Teams
Qualities That Make or Break Client Software Teams
Imagine if you will that you work for a software vendor who develops, sells, and deploys a large enterprise application (EA) for their clients. Specifically, you lead an implementation team – the vendor team – responsible for everything related to rolling out an off-the-shelf software system to your client. The principal mechanism in helping you formulate and get approval for the details of a fully implemented system is the client team. First, what constitutes an Enterprise Application?
Enterprise Application (EA): A large-scale application software package(s) that support business functionality & processes, information flows, reporting, and data analytics in organizations. An EA is a scalable, component-based, distributed, and hyper-configurable system. For our purposes here, the EA is an off-the-shelf software assembly.
The major types of EAs include:
- Enterprise Resource Planning (ERP)
- Supply Chain Management (SCM)
- Customer Relationship Management (CRM)
- Content Management System (CMS)
- Healthcare Management System (HMS)
There are more classifications, but the system type is not the issue here. The general challenges faced are the same whether it’s an ERP system or a major manufacturing control system. For an idea of the breadth of functionality involved with an EA – consider Axelerate’s article “A Brief History of Project Portfolio Management,” and the nature of a system that models complex organizational strategic, work, resource, process, data and financial information. For an examination of typical problems encountered during an EA rollout, read "Avoid These Mistakes and Roll-out New Software like a Boss, Part I." Virtually all of the issues identified here are team related.
The Nature of EA Implementations
The modern EA rollout is a complex affair. Properly implementing the bountiful sets of feature functionality along with the highly involved business processes requires a focused client team working side-by-side with the EA experts from the vendor team.
A supremely committed client team can overcome almost any challenge or deficiency in another area – but nothing can compensate for a team that lacks or loses interest.
The conditions under which these engagements are conducted may vary wildly. From a medium-sized company performing an incremental, out-of-the-box rollout; to a large organization executing a single ‘big-bang’ effort attempting to replace multiple, complex, interfaced legacy applications in one fell swoop. Another rollout may be phased over years. Still others may involve numerous technical enhancements prior to go=live. Clients may insist on rigid emulation of their existing systems and processes or they may request a blue-sky ‘tell us how to do it’ engagement. The possibilities are endless.
Why Client Teams are the Deciding Factor
Let’s assume that the client organization is determined to succeed, willing to do whatever is necessary to successfully complete a new EA rollout. Two variables now control the outcome of the initiative almost to the exclusion of all others – the vendor’s implementation team and the client’s implementation team. This article will examine 4 major characteristics of a successful client team.
The client team will be responsible for making decisions and acting as the approval authority for the high-level scope down to the design of a report down to the specifics of a custom attribute, all while keeping a wary eye on the project’s progress. The commitment, composition, readiness, and overall quality of the client team are the most important factors in determining whether an EA deployment meets with success or failure.
Client Team Commitment
It is required that functionally diverse personnel providing representation horizontally and vertically across the organization work together to form the client team. This can present challenges to EA implementations. Simply put, the team’s personnel have other jobs and interests – and those commitments could be exhausting in and of themselves. There will be times – during peak periods of work – when keeping the client team’s attention to the project is a challenge. Accommodating this eventuality is the responsibility of both vendor and client. Vendors are familiar with these situations and their implementation practices should reflect their best efforts to accommodate client team ups and downs without crippling the rollout.
A supremely committed client team can overcome almost any challenge or deficiency in another area – but nothing can compensate for a team that lacks or loses interest. It is critical that an EA engagement make the most efficient possible use of the client team’s availability.
How does one quantify or even qualify team commitment? A team’s commitment is directly related to their willingness to relentlessly work the problem in order to bring about a successful end-game.
Client Team Composition
Adequate consideration must be given to the proper personnel composition of a client team. Lean and mean teams are best. Leadership will be provided by whichever business unit will ‘own’ the EA. The EA client team should provide balance across the organization in terms of the user disciplines, major functional stakeholders, business leaders and executive sponsorship. Avoid a client team that exceeds about 12 members – this is the “committee of congressmen” syndrome. The moniker speaks for itself. Here is a robust team layout:
- Project Leadership
- Business Unit Representation
- Functional Representation
- Executive Sponsorship – A very good implementation can get a marginal grade if the executives don’t get what they thought they were paying for – whether they bothered to tell you or not. The Executive Sponsor can and should provide relief here with her vested business interest in the project from kickoff to close. This can mean the difference between success and failure.
- User Representatives – In certain circumstances, you may require functional user rep(s) from the rank & file operators.
Beware of the following client team conditions – first, functionally lopsided teams will result in lopsided roll-outs and those who weren’t represented will be the first to find fault. If a business unit or functional representation is missing in an organization-wide rollout, alarm bells should sound. Second, although I haven’t seen this in some time, an organization (even a large one) may attempt an implementation with a single representative to act as the de facto client team. This represents extremely high risk. Attempting to use a single individual as an approval clearing house, regardless of their talent, running back and forth between vendor team and client subject matter experts to synthesize the large amount of decision-making data, will very likely cause the implementation to fail.
Client Team Readiness
When the vendor implementation team arrives at the client’s site, the client teams of mature organizations will be prepared and ready. They’ve had enough familiarization training and exposure to begin to formulate their plan. They understand their needs and those needs have been clearly communicated to the vendor team. This might include artifacts like the overall scope, draft requirements and even a draft functional specification. If this is the case, the vendor and client teams can start right into the nitty-gritty of validating those documents and moving forward with the design and build/configuration of the EA. This is the ideal situation.
On the other end of the spectrum, the client team’s only preparation may have been a pre-sales viewing. This viewing can amount to a large scale, time-constrained, functional bombardment of the client team. The client team is saturated and unfocused. This occurs for three reasons:
- First, unless the client team is extremely familiar with a particular EA, they will be overwhelmed with product information; EAs can encompass a significant amount of functionality crossing numerous disciplines.
- The vendor will want to show off the system’s functional capabilities as much as possible.
- The client will want to inspect all system capabilities of in order to assess the longer-term possibilities, or out of pure interest.
If the volumes of information are not channeled efficiently, the net effect of this arrangement is information overload and the client team starts the implementation off-balance – very possibly not even certain what high-level functional modules are in-scope. The team may feel unprepared and works to become system experts instead of organization and domain experts they need to be. The tail is now wagging the dog resulting in an attempt to formulate organizational doctrine around scantily understood EA capability. All of this with the specter of a major system implementation hanging overhead.
Vendor consultants are trained to design system configurations under conditions of defined circumstance – they build a model of a functional ecosystem if you will. A blue-sky opportunity doesn’t necessarily help the vendor’s implementation. Vendor consultants differ in their capacity to resolve and/or assist their clients with this situation. The resulting indecision, circular discussions, and waste of time can be debilitating.
The ideal situation is for client teams to be familiar with EA functionality and have determined scope and detailed requirements, providing them to the vendor prior to the project kickoff. This document allows the vendor to channel EA information to the client team and provides the vendor a model of the client’s organizational processes and structures from which to begin their analysis.
Client Team Quality – EA Success Factors
Assess your EA implementation client team quality by its alignment to the following 10 tenets:
- The client team is over any reservations which existed heretofore and are standing by to ‘dive in.’ They are committed.
- The client team’s composition is thought out and balanced.
- The client team’s readiness is established.
- The client team has considered the organizational change that must be absorbed and is prepared to engage it.
- The team commits to a firm schedule and is prepared to do everything in its power to see it through.
- The client team does not over-affiliate with the system. This means that the client team does not concern itself with every known aspect and function an EA can provide. They understand that vendor personal are the system experts and they focus on working with the vendor team to get the system that solves their problems and satisfies their needs.
- The client team members are domain experts within their part EA functional ecosystem.
- The team understands that even though modern EAs are hyper-configurable, there will inevitably be situations in which the system cannot create a perfect emulation of a n agreed on model. The team should be demanding but flexible.
- The team understands that phased roll-outs making use of out of the box functionality to start is the smart play. Early excursions into customizations before any organizational experience with the system or before the accumulation of operational data will expose the rollout to unnecessary risk.
- The team – in whatever scenario they find themselves – is smart enough to ask the question, “does this particular approach make sense?”
If the client team can put check marks in these 10 blocks, they pass the team quality test.
While simple enough in concept, in practice the performance of a client team on an EA project can be problematic. Different perspectives, backgrounds, temperaments, and notions of success can wear on the cohesion of any group. Roll-outs that drag out result in a team wide fatigue – a feeling that it will never end. Failure to correctly formulate the client team is doubly detrimental.
While no level of compliance with a single set of criteria can guarantee success in every undertaking, I can think of no better starting point and means to mitigate the risks of off-the-shelf EA deployments than following the recommendations provided here.
Join Our Community
Latest Posts from the
Managing Software Vendors – 6 Practices for Project Success
This paper addresses the most common issues facing companies that make use of vendors and sub-contractors in a software development environment. It attempts to address the myth that you can exercise little control over vendors and sub-contractors.
Application Portfolio Management 101 – Method and Benefits
APM is one of the single most effective IT management paradigms ever developed. When implemented properly, its impacts on the software inventory, its associated infrastructure and the cost of external organizations supporting it are astonishing.
3 Stages of PPM Maturity
Our third and final stage of PPM Maturity establishes 3 different sets of functions. First – Infrastructure is developed, meaning Services, Assets, and Applications as the infrastructure components of Enterprise PPM. Second, external Products and Services that the organization sells are defined. Finally, we add a Benefits Realization process to capture both tangible and non-tangible benefits.
PLEASE – What is Project Governance Really About?
The accepted definition and associated conventions of project governance have arrived. The challenge will be how individual organizations introduce, standardize and mature it into and along with the breadth of their project, program, and portfolio systems.
Projects, Programs & Portfolios in Action
The architecture of our portfolio models provide continuous visibility into the current state, the future state and progress to date of our organizational initiatives and allows us to adapt to the internal and external drivers of change