The Technical Staffers

The technical staffers on the project are responsible for installing and customizing the system, handling the setup and administration of the various systems involved, testing, rollout support, and performing ongoing support and enhancements. There are many ways to set up the technical team. How you do it depends on how much the integrator can do, what can be handled by the internal IT staff, and how much you want to farm out.


A critical and sometimes overlooked role of the technical staff is to contribute to the requirements definition and to the selection of the tool and of the integrator from a technical perspective. Much of the technical work during the selection process can be handled by the IT owner, but it's likely that he or she will want to confirm specific points with specialists on the IT team, or sometimes with outside consultants. It's also a good strategy to allow the technical staffers to work directly with the vendor's technical team; experience shows that technical workers are often remarkably candid when talking to their technical peers. During the implementation phase, the technical staffers may be called upon to play a variety of roles depending on how much the integrator is doing. This includes:

  • Providing system configuration and administration services. There can be minimal requirements for the IT group during the coding phase if the work is done at the integrator site, but that still leaves open the issues of the testing environment and the production environment. (We'll come back to why having three environments for development, testing and production is ideal; see , "Implementing a CRM System.") The need for system configuration and administration typically heats up towards the end of the implementation cycle as the full system nears deployment. System administration needs extend from the server to the network, the database, and desktop or laptop systems. Significant tuning requirements may exist as well.
  • Installing the tool. This can be a rather involved operation, and almost always is for high-end systems. It is best attempted with the vendor's or the integrator's assistance.
  • Customizing the system. This is often the prerogative of the integrator, but even when an integrator is involved there's a lot of value in having IT staff members participate in the design and coding of the system. If nothing else, they will have to provide support for the customizations in the long run. Customizing the system almost always involves coding, although some simple customizations may be done through a simple interface with no coding required.
  • Integrating the system with other systems. If integration is required with a legacy or other system, the expertise for those systems often comes from the IT group. Unlike the IT staffers who work on other parts of the customization, the system specialists bring their knowledge to the integrator's team rather than learning from them.
  • Testing the system. Just as the super-users have a hand in creating use cases that capture the business requirements for the tool, the technical staffers create the criteria for load testing as well as the use cases for administering the tool. The technical staffers run the tests, or at least check they have run successfully, throughout the project.
  • Support for the rollout and beyond. The technical staffers are completely or partially responsible for supporting the tool. Support requirements at rollout are usually very high as users may stumble a bit despite the training, and problems may develop despite the testing that was done. Technical staffers are also on the frontline when it comes to providing ongoing support, including reviewing and incorporating enhancement requests.


The requirements for the technical staffers are as varied as their responsibilities. Except for very simple projects, many different functions participate in the project:

  • System administrators for all the systems involved.
  • Database administrators.
  • The network managers.
  • The app programmers for the CRM tool itself and for all the tools that may be linked to, in any way, by the project, whether a complete integration is required or something lighter-weight.
  • UI specialists, especially for the customer portion of the rollout.
  • Web designers.

It's obvious that complex projects need many, many more technical staffers than modest ones. At one extreme, for a minimalist project and a very user-friendly tool, the IT staff may only need to provide a machine to install the tool while the business function handles all the customization and maintenance work. Very few projects are that simple. One of the key decisions that should be made before the project starts, and therefore well before a tool is selected, is the level of technical resources that can be applied to the project. This requirement will shape the selection of the tool: don't overreach. Beyond the total size of the technical team, the big issue for the IT staffers is to define the respective responsibilities of the integrator versus the in-house IT staff. Generally speaking, it's a good idea to farm out the customization work. The expertise is rarely available in-house and the volume of resources required is huge: why hire a whole bunch of people for a time-limited project? However, even if an integrator is involved, it's critical that in-house technical staffers be an active part of the project if it is to succeed in the long run. In particular:

  • The IT staff must play an active role in selecting the tool. No integrator can ever understand your IT landscape as well as you do, so no integrator should be allowed to make the decision for you. Remember that all tools are "easy" for integrators since they work with them everyday.
  • The IT staff must participate in the requirements definition for the implementation phase. They have or can find answers to many of the questions that will come up about how the tool can be integrated into the IT environment. Working with the IT owner, the IT staffers can provide many technical details about the inner workings of the IT infrastructure, anticipating the issues that must be resolved in order for the project to be a success.
  • Even if the integrator is handling all customizations, and even when the in-house app programmers must start from scratch and go to vendor-sponsored classes, they must be involved in the coding part of the implementation. It may seem strange to apparently delay the project for the sake of bringing non-key programmers up to speed. The reason for doing this is that a few weeks' apprenticeship with the coding staff of the integrator is invaluable both in terms of learning how customizations are really done and to provide a smooth handoff to the support phase.
  • The IT staff must be involved in setting up the environment required for testing and production. They can be assisted by the integrator, to be sure, but they need to fully understand the setup so they can support it. Moreover, many companies restrict access to their internal systems for security reasons.
  • Unless the integrator will provide full support after the rollout, which is very rare, the IT staffers will have to provide ongoing maintenance after the rollout. This should be planned during the project so that appropriate staff can be hired, trained, and brought up to speed on the customized app.

The individual time requirements can be quite small for each technical staffer. For instance, the requirements of the network administrator are likely to be limited to only a few days during the entire process, but skipping that step may lead to real problems later.