This is the every customer's dream! And it's not an impossible one
To answer this question, I will divide the "fast" from the "successful"!
For a "fast" deployment I would like to draw your attention to 2 points:
- Mapped (or documented) processes.
- Integration with other systems.
For a "sucessful deployment:
- Expectations well aligned.
- Well-defined controls.
- The moment processes are mapped, they are also standardized. It is common for each member of the business team to work differently. And if the consulting firm needs to survey in every way to come up with a unified way of working, it will take many hours of survey and discussion to address a subject that the company itself could have done on its own.
- During process documentation, this is the time when the manager will also define how he expects his team to work.
- Process documentation can start with the desire to deploy a business management tool. This process will mature the team itself for the arrival of a system.
- The consulting firm will have material to quickly understand the business process and point out project gaps and challenges.
Deployment with other systems: Do you want a fast or an integrated project?
Of course, in some projects the integration is a critical point to achieve the desired goals. But be aware that this will hardly be a fast project (less than 2 months), unless both systems are from the same vendor or an extremely simple integration (which is never the case!).
- Bringing in an integration for the scope of a small project is to ensure that it will take at least 4X longer (consequently 4x more expensive).
- Being radical: We don't believe in a sucessfull deployment done in less than 3 months with bi-directional integration with other software that has another responsible consulting firm. For the following reasons:
- Calendar availability of both companies. The entire integration strategy will need to be defined, documented and signed.
- Resource availability from 2 companies to work on a single project / schedule.
- Technical definitions:
- Will webservice development be required? Reportings? TXT files?
- Which tables will be replicated? Will they all have bi-directional replication? How often will the base update? What will the conflict resolution rules look like? What are the de-duplication rules for data already entered in the legacy system.
- Which new entries will be entered in which system? Must the registration be completed on the target system with attributes that concern only to it?
- There will be "from / to" information? Ex: ERP Sex: M or F, CRM: Male / Female.
- What values will be filled in in the required base base fields that do not exist in the source base?
Well-aligned Expectations: Sounds obvious, but good to mention!
- Expectation aligment between: the sales team manager X the sales team X the deployment team.
- What indicators / charts does the manager expect to have at the end of the project?
What is the difficulty?
In business team automation projects there is often a dichotomous choice. Who will be happy? The Manager or the Salesperson?
This is because the manager wants to implement as much control as possible, and the salesperson wants as little control as possible. If the system becomes bureaucratic the manager will have all of his indicators and salespeople will hate the system, if the system gets "loose" salespeople will use CRM only for the things they think are necessary and the manager will not have their indicators (regardless of which tool the company has chosen).
It is common for managers to attend the first meeting. Let sellers drive how deployment should be done (after all they know the process) and come back on the last day to see the outcome of the system. In these cases, the manager tends to leave not satisfied because he will not have the indicators that motivated the company when hiring the project.