I’ve been on both sides of the fence when it comes to developing systems both doing the work, and as a certified Project Management Professional (PMP), managing some great people who have been on my teams. Having lived and labored in both camps, I’ve unfortunately seen several projects run into issues. To be more precise, and for the purposes of this post, I’m speaking specifically about projects that involve the integration of two different marketing systems and some of the common pitfalls that occur during these projects. We’re lucky to live in an age where all sorts of systems integrate with one another – even Twitter and a cat feeder. Currently, my role focuses on the integration of student inquiry management systems (IMS) with customer relationship management (CRM) systems or student information systems (SIS). Integrating systems means there is a communication going on between two disparate systems. This communication can occur in one-direction (like an IMS system sending data to an analytics server for reporting purposes) or it can involve both systems generating and consuming data that is created by the other system (this is usually referred to as a bi-directional integration). My team and I have worked on both types of integrations in order for systems to exchange inquiry, analytics, and overall marketing and admissions data. And when integrating two systems there is only one thing for certain, “anything that can go wrong will go wrong.” To help you avoid some of the most common issues, I’ve put together a list of four pitfalls that can easily be avoided.
One of the biggest issues I see when working on integrations, and projects in general, is when the scope of what is being done is not adequately defined. In short, we missed something that needed to be included during the scoping phase of the integration. When we dig into the real reason why this happens, the cause usually falls into one of two buckets:
Getting ahead of these problems can be as simple as outlining a time to spend on scoping for any project that will be worked on, no matter how simple or complex you deem the effort to be and making sure that a scope document is created to capture everything that is called out during the scoping phase. By providing yourself with adequate time to outline you’ll also give yourself enough time to fully understand what you’re building.
So you’ve put time on the calendar for scoping and got all of the relevant teams together to understand what was needed. You’ve planned everything out and the team has an understanding of what’s needed in the integration. Execution started and the integration is nearly ready for testing, but some early testing has revealed that something just isn’t right with the integration. So what happened and where did you go wrong? The odds are that if you scoped properly and put together the plan correctly, you just did not follow the plan so one of the following things happened:
Even for integrations that look very simple from a high-level business process standpoint, there can be a great deal of technical details that need to be defined in order for an integration that carries student marketing and admissions data between systems to work properly. If this level of detail is missing from technical design documents, it can mean the difference between success and failure, so make sure that your teams are keeping good technical design documents in addition to the business process documents that outline how the integration works from a high level.
Sometimes it can feel like defining and building an integration with your student information system or CRM is a major undertaking. However, one of the biggest parts of the build is in the testing of the integration. Just like you plan how and what to build, it’s equally important to plan how to test what was built. Creating an explicit test plan for your integration will help to reduce uncertainty, ensure that what was planned/designed is what was actually built, and helps address issues earlier in the development cycle thereby reducing the cost associated with a defect. The test plan should include unit testing (automated tests created by developers to validate the system at a code-method level), integration tests (that check the data moving through the integration is valid when going from point A to point B), and end to end tests that validate the entire business process when the integration is in place. While, this is by no means an exhaustive list of issues that can occur when integrating student prospect marketing and admissions systems together, addressing these issues at the start can help cut down on major headaches that can occur later on.