Seamless integrations & Project Management

“Seamless” is one of the most misused words when talking about integration projects. Whether it be a new process flow in an existing application, or whether it be introducing a new application into an existing application landscape, everyone – sales managers, product managers, developers - promises that the integration would be “seamless”.

I like integrations. Having had the luck of starting my career with an enterprise software maker – Dutch ERP company Baan (today ‘Infor Global’) – and continuing with end-user organizations using enterprise software, integrations have been a large part of every project I worked on or managed. Seamless integrations, of course :-)

Jokes apart, it is almost inevitable that organizations have embraced multiple (sometimes, hundreds of) software applications over a period of time - Client server applications, Enterprise applications (CRM, Procurement, ERP), the omnipresent legacy applications and more recently, cloud based applications. As applications become embedded in the application landscape, it becomes more difficult to prise out the dead wood. Organizations want, naturally, that their business processes should flow “seamlessly” through the labyrinth of applications but in practice, that seldom happens. As a Project Manager, what is the secret formula to successfully managing your next integration project?

To go back to the basics, when I plan out a project depending on complex integration requirements, I like to split the integrations into two distinct parts:

• Functional integration
• Technical integration

Functional integration:

This involves mapping the organization’s business processes across (new and old) applications or across (new and old) process flows. This is where business people from the organization should be heavily involved. These people don’t need to know – or care – about the underlying technology of constraints such as legacy software, but they need to know everything about what the business need is and what the required functionally should be to achieve those needs.

Remember, when trying to define the business need (thus the functional part of the integration across applications), the biggest mistake can be talking about “what SAP can do” or “what Siebel or Oracle EBS cannot do”. At this point of time, it doesn’t matter. Start off by assuming the ideal scenario that standard Enterprise Applications built for your industry can achieve what you need.

The next step involves translating these business needs into application flows. Here is where functional experts with a strong knowledge of the current application landscape should be involved. At this stage, “what SAP can do” turns into a valid question and choices need to be made to bring the software and the requirement in line with each other. Being “IT aware” is very important in this step in order to make good choices. If necessary, the functional experts should be aided by IT people with a strong architectural background, so that the chosen solutions are as “standard” and architecturally sound as possible.

This step is also where the biggest mistakes can be made. In many organizations, technical people with weak architectural skills help make the translation from business need to application (software) flow. Often these people are in the lead because of their knowledge about the existing application landscape, and as correct as that sounds, it can lead to biased decisions. Often during this step, political games are also played where application owners / managers try to push their applications to be the centerpiece of the proposed solution.

I have sat in meetings where (functional) architectural decisions have been made by voting (No kidding!). An important lesson - Democracy and architecture do not mix. When you make the incorrect choices here, you can forget about “seamless” integrations regardless of what CRM, ERP or middleware you use, and whether your application(s) exists in the cloud or on-premise.

Technical integration:

Naturally, for integrations to work, there needs to be a lot of complex, technical work done – agreeing on schema and interface definitions, decisions on whether the integrations should be real time, batch or a combination of both, implementing the integrations as Web Services or Message based communication etc. These could lead to beautiful discussions but as long as the business needs are met, the details couldn’t worry me less. Where I am concerned, this is the part where the technical guys rule the roost, of course with the help of an experienced Technical Architect. The expertise of the Architect is here again of great importance, because there are always multiple technical route possible for every solution, and the implemented solution can be great or less than great, depending on the technical choices made. It is not much more complicated than this.

Why is this important?

My experience tells me that integrations are often seen as the domain of the technical guys, and it is a fact that the technical stuff is where most of the energy and time in integration projects is focused. I even know organizations where the middleware programmers are called “integration specialists” because in the views of most organizations, it’s the technical connectivity between applications (thus the middleware) which makes integrations work. To put it simply, I don’t agree.

Let’s be clear that both the functional part and the technical part plays a crucial role in the end result of your integration project. In my experience, however, problems relating to the technical part of integrations are way easier to troubleshoot and fix, compared to fixing software built on incorrect functional choices. Furthermore, technology keeps improving with time, which means that the technical implementation would never be written in stone. However, the functional processes within organizations would be less likely to change drastically (but never say never).

To end this post, I want to highlight what you, as Project Manager, need to look out for to ensure that your integration project doesn’t end up as countless others – a big mess. The list is small (and definitely not complete) but just focusing on the essentials here:

• Get the right people involved: It sounds so simple but countless projects fail because the wrong people make the choices – functional as well as technical. There is no golden rule as to how you can recognize the right people. It’s just people who seem to understand the bigger picture; people who consider multiple alternatives to choose the best one.

• Place accountability on people: The terms “responsibility” and “accountability” are often used interchangeably but for me, there is one big distinction. Everyone in a team should be “responsible” for delivering a great piece of software, but “accountability” has to be very specific. if everyone is accountable for the overall success, then often that in reality, no one is accountable. Make it clear – who is the person in the team with the “functional” accountability; who is the person in the team with the “technical” accountability?

• Respect “standard” application behavior: Often, integration projects try to re-invent the wheel, or customize processes that are defined in an “industry best practice” way in standard (enterprise) applications such as CRM, ERP etc. Ensure that the standard flows have been examined in detail before trying to customize software. You could save everyone, including yourself, a lot of pain.

• Be careful of the “fire and forget” principle: When processes flow across applications, and you hear team members say “Once I click this button, it goes out of my application. I don’t know or care any more what happens. It is fire and forget”, it’s time to worry. The team needs to understand that it’s not enough for the process to work “inside your application”. If everyone fires and forgets, you can forget seamless integrations.

• Mind the politics: Whether it be with getting one’s own application at the heart of the new solution, or getting your favorite people into good positions inside the project, politics exist in every organization. As Project Manager, you must work along with the client organization, be diplomatic and build bridges (that is part of the job description), yet be aware of the dangers of being a Yes-man. Success has many friends, failures none. Compromises made due to political influences will only reflect badly on one person – the Project Manager responsible for the failed project. Standing your ground may not endear you to everyone but it will increase the chances of delivering a successful project.

• Go look for trouble: I have a simple philosophy – Find trouble before trouble finds you. Integration projects are complex stuff. They usually go wrong at some stage or other. The best way to avoid trouble is by actively searching for it. What could go wrong – make a list of 10 things, and keep refreshing the list at intervals. If a 11th crops up which wasn’t in the list, then it’s just bad luck and a lesson learnt for the future. If any of the 10 turn up, you already have a back-up plan in mind. Great to be so pessimistic, isn’t it?

• Follow your intuition: While there are plenty of project management tools around that allow you to be on top of your project at all times, I find intuition to be my strongest project management tool. If I “feel” that there is something amiss, there probably is, and all the lights being green on the project tracking tool will not convince me otherwise. You don’t have to follow a course to build up this skill. Just keep taking up more and more projects, and your intuition just keeps getting stronger.

So, what are we waiting for? Let’s make that next integration project work…. Seamlessly!

Note about the author: The author is an experienced Project Manager, with a background as Software Architect. He can be contacted for consulting opportunities, second opinions or even free advice on how to manage complex integration projects.