Identifying the top challenge that we encounter on integration projects is easy: managing the dependencies. Anyone who has worked on non-trivial software projects already knows this: dependencies can quickly and unexpectedly push your project off its rails. Most experienced project managers recognize that and they will appropriately go out of their way to reduce or eliminate all dependencies.
But what do you do for integration projects? Those projects are by their very nature all about dependencies! So you obviously cannot avoid the dependencies, they are everywhere! You have dependencies to all the systems you are interfacing with: you can have dependencies on internal systems, external systems, internal project teams, external organizations, network infrastructure, messaging infrastructure, enterprise directories, document repositories, data warehouses, audit trails, reporting services, etc, etc. Will they need to be modified? Will they provide you with the info you need in a timely fashion? Will they be ready to test when you are? Are they existing systems or in-flight projects? As you can surely see, this exposes any non-trivial integration project to a lot of risk.
So what can you do about it? Since you cannot eliminate those dependencies, you need to manage them proactively and plan for the worst by implementing risk mitigation strategies and contingency plans. As you are estimating your project, you must allow for a lot of extra time to compensate for delays that are out of your control. You must plan for what you will do in case each dependency becomes an issue. You must ensure that you have a point of contact for each dependency with someone that has enough bandwidth and authority to exert the appropriate pressures. You should also ensure that you have the proper level of management support to escalate issues when they become critical. For each dependency, you should investigate possible contingency plans. For example, is there another system or solution that could temporarily replace one that is not ready in time?
I could go on forever, but I think you get the point: you must plan and plan again to mitigate the risk brought by those dependencies! It is really no different then what you would do for any significant software project; it is just that the problem here is an order of magnitude bigger due to the nature of enterprise integration projects. So you must greatly increase your risk planning effort, add some contingencies to both your project plan and your budget, and obtain the right authority and escalation paths. Last but not least, you must constantly communicate so that all parties involved know exactly what is expected of everyone, and what the status of their project is. If you can detect issues early, you are much more likely to be able to deal with them without major disruptions to your project.
So manage your dependencies, or else!
I will be speaking on the subject of BizTalk 2004 and SOA at DevTeach 2005 in June. If you've never heard of this conference, I encourage you to check it out. It's is not only affordable, but it offers an roster of speakers, and it is set in one of the world's best cities.
Check it out: http://www.devteach.com/
I’ve participated in a lot of Enterprise Application Integration projects and Trading Partner Integration projects during the last 5 years. I’ve recently started looking back at that experience to try and identify what are the top challenges that keep coming back on every such project. I’m not talking necessarily about technical challenges, but also program management challenges. This gave me the idea of starting a series of blog entries to discuss those challenges. Stay tuned for more in the coming days.