7 Questions to Ask an Application Integration Service Provider

Software development outsourcing is often a good alternative to in-house development when you use specific talents of niche providers instead of hiring and training in-house expertise. The wealth of knowledge and practice in different software technologies and platforms is essential to make an application integration initiative a success. While hiring an offshore company can be beneficial and return reduced costs in both time and resource, there are seven questions you need to ask prospective service providers to ensure a good match.

Quick Assess Check List:

Use this check list to rate capabilities of the outsourcing partner to complete the application integration project:

• Did they complete similar projects before?
• Do their skills cover a range of integration products and technologies?
• Do they offer software design alternatives?
• Do they identify possible technical issues?
• Do they offer prove-of-concept to handle discovered issues?
• Does their proposal address security issues?
• How easy do your IT leaders and offshore developers understand each other?

Offsite software implementation and integration solutions require a highly skilled partner to collaborate with your team and build a design that integrates easily into existing applications without any major changes. Skilled partners can also integrate proper security, which should not be overlooked. Below we will discuss the mentioned aspects in more details.

Project Requirements

There are many, many, many, many, many, many articles, cliche’s and of course peoples opinions on requirements writing and gathering, most of them stress the importance of thinking of the specifics of how a product should function before starting any development work. In this article I will briefly touch the surface of this topic and implicitly describe my experiences with some of the requirements documents I have read.

The importance of good requirements definition is difficult to argue with, the fact is that if you are presented with good specification documentation that is presented in a logical way that is easy to follow and presents requirements for all possible cases the development work becomes a lot easier. However, proper requirements writing is underrated in how much time should be spent writing specifications and how difficult it is.

How is this relevant to project management? Regardless of the methodology you decide to use and aside from the fact that requirements writing must be taken into account when creating a plan for the project. Good requirements are the basis for a well defined project road-map; Project requirements are often the bridge between the business and the technical team and they must be understood by both technical people and business people. If the requirements are vague and do not describe all features which will be included in the product or iteration correctly, then it is not possible for even remotely accurate development time estimations to be defined. The development time estimations will be little more than guesses, it is difficult enough to estimate the time it would take to develop a functionality if the specifications are clear and well defined but with vague requirements it becomes next to impossible. I would argue that this is one of the main causes for projects that do not meet the deadline.

So how are some ways we can improve our requirements writing skills? One of the differences between a well written and a badly written requirements document is the language used. This does not only mean that if the development team only speaks English then the requirements should be in English . This also means that you should only use words that you understand ( look them up in a dictionary if you are unsure of their meaning ). Another way that requirements can be improved is that they must be written using a logical hierarchical structure, with many titles, subtitles and bullet points grouping relevant pieces of information under single subtitles. It must not be written in the form of an article or essay. This of course assumes that the person writing the requirements knows what the requirements should be, that’s a completely different issue and I won’t go into that, yet…

Common Understanding

There is a big difference between finishing a project and releasing a project. This may be an obvious statement but it’s a lesson I had to learn the hard way recently when there was a misunderstanding that occurred between me and my technical contact. When I asked when is a realistic time to get a finished product out the answer was week 22. In his mind this meant that development would be finished, in my mind it meant that I could schedule a release on this week. We both made assumptions as to what was meant by a finished product and in the end this meant that I had to reschedule the release of the product one week later than expected, which no-one is ever happy with.

Communication is a key element in releasing any project successfully. I’m certain that anyone who has been in team project knows this, if the communication fails then the project fails. The problem is that failure in communication is not always easy to spot. In the example I gave above it was clear to both parties what the finish date was, however because both of us assumed our own definition on what it meant to have a finished product the communication failed and the project was delayed one week.

The point is, that when defining aspects of a project with another person, be that a technical decision, business decision or whatever, it has to be clear that all parties understand the same thing and that no assumptions are made as to the definition.