CRM integration - 5 takeaways from the PM's perspective
In early 2018 we did a site remake for the Trigo Group, and as part of it we took over the sales lead management from the legacy system. This way we stored personal data in the Drupal for a giant company with many branches in dozens of countries and even more sales colleagues. But as the company grew, a more mature CRM system was needed to handle all the requests. Today we celebrate the 1st anniversary of starting the planning phase of the Microsoft Dynamics CRM integration into our Drupal system and due to this event, we share our experiences and lessons we've learned from a project management perspective.
1. Define the roles and responsibilities
In a 3-sided communication (client & vendor & client's dev team)*, everything takes longer, mainly if you are dealing with organizations of complex hierarchy. Answering a simple question might take days due to the many stakeholders and authorities in the organization. And if you don't know who's in charge of what and who to ask in some specific situations, you will end up waiting and waiting without making any progress. So clarify all the roles and channels in advance. Also, make sure that all the involved parties know, what are your responsibilities in the project.
* client - Trigo
vendor - the company responsible for the Microsoft Dynamics customization
client's dev team - Brainsum
2. Keep everyone updated
Closely related to the previous point, to overcome any misunderstandings and waiting queues, have regular update calls. But keep in mind that they will work only if you can get all the decision-makers at the table for 60 minutes per week to resolve the blocking issues. Make it clear for every involved member that the regular meetings will help to move on with the project and deliver it on time while making the best quality out of it.
Anyway, find a way to always update the stakeholders and track your progress. The only way how they can step-in in time if something goes wrong is if you let them know about the status of the project.
3. Plan your resources
As part of the Agile methodology, everyone calculates the estimated time of work for a feature. But you can't really foresee the factors that are independent from you, like a pro-longed testing phase or a constantly changing request list. You can, however, clarify the resources you are willing to provide for the feature once the development from your side is considered as done. Also if you have specified the definition of the MVP (minimum viable product) in advance and the client has agreed on it, you can always refer to that as something that is ready to be launched and improved later on. A never-ending project costs a lot not just for the client but for the developer team also. Emphasize the importance of the cost of delay for the decision makers: What would it cost us if this was delayed by 1 month/2 months/6 months?
4. Ask for feedback from the very beginning
It's in our human behavior that we don't want to show our product until it's done, or at least in pretty good shape, but this mentality has plenty of pitfalls.
- First of all, maybe your understanding of a function was different than the client's understanding and if they try out the result only in the last phases, it's harder to change it.
- It also may happen that even if the product was designed in a way, in live-action it won't work as intended, so you have to change it.
- You may face some troubles that could have been overcome by different approaches in a shorter time than fixing the original idea, but the decisions can be made only by the PO.
- You may come up with other ideas that can be a better fit for the product.
And probably many other reasons popped-up in your head already while reading this list. Anyway, the point is to provide an environment for the client to test everything that has been done and give the opportunity to share their findings with you from the very beginning of the development. If they start the testing on time, you will spare yourself, your team and your client some stressful weeks prior to the launch. Everyone will know what to expect and the client will learn what are you capable of in a certain amount of time, this way their change requests may be more feasible and tolerable at the end.
5. 70% planning, 30% implementation
Yes, I know, it sounds silly! But still.
As I mentioned in the beginning, 3-sided communication makes everything harder and longer. And for planning and consulting it applies exponentially. Usually, P&C takes around 20-30% of the time of a project, but as the number of the stakeholders rises, so does the time spent on communication. And this might be nerve-racking. Mainly, if you are not used to it. But it is really important that all the members get to the same page and everyone knows how to proceed. And sometimes the only way you get there is by dedicating more time to communication, than ever before. But from my experience, nothing wrong comes from being available and transparent.
The biggest takeaway, for me at least is, that the size does not matter. Even big companies with thousands of employees and billions of revenues consist of the same as our company: people. And sometimes people make mistakes, forget about things or even don't deliver a product on time. But it's also the people who correct these nitches in the process, so do not be afraid to rely on them. And also on the points written above. ;)
One more thought on the technology side of this project: BRAINSUM is an open-source company committed to creating value which is reusable not only by us. During this project, we created and published a module for easier Drupal Microsoft Dynamics integration. We believe that via this open-source contribution we brought real benefits to our client: we prevented a vendor lock-in situation and opened up the door for community testing and contribution for better sustainability and quality in the long-run.