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.

Key signs of provider’s capability

Previous experience adds predictability.

The developers’ expertise in diverse technologies, along with practical experience and analytical skills is the key to a sophisticated solution. The developers obtain knowledge of technology’s strengths and weaknesses that is rarely covered in documentation and some time documentation can even mislead important technical decisions. Those who tried and played with the technology understand how to better use its benefits and avoid issues.

For example, Sun JMS technology is recognized as an essential tool for building enterprise applications and is loved by developers as a very flexible and capable Message-Oriented Middleware to integrate applications. However, experts know that in very specific situations, for example when used in AJAX web applications, it generates visible performance bottlenecks. The latency issues may destroy all your efforts and make your application unusable. The experts will pro-actively help you avoid such design mistakes and offer suitable workaround patterns.

For the outsourcing providers, create a short list of things to evaluate such as which technologies were applied in similar projects to address customer’s needs. This information can typically be found in case studies or by inquiring directly.

Products and technologies provide alternatives.

Advertised advantages of aggressively promoted products are not always the best or the only possible way to develop a software solution. Often the same need can be addressed with differently priced products or even open-source software. If the provider has experience in several alternative products, they will be able to help you making a choice.

It happened for one of our customers who made an opinion that WebSphere middleware was the best choice for their integration portal although most of their integrated applications were Oracle-based. If they followed this belief, they would have spent more time and money for development and support. Fortunately, they happen to ask around for advice. We did further research and found out that Oracle would address their technological needs as well as WebSphere, but it required fewer efforts for integration and better suited business needs. Knowledge of alternative products and the abilities of the provider suggested a better ratio of costs and benefit savings for their budget.

I have no doubt that you will check what a provider says about its previous experience and skills. But you should also make sure that the proposed technologies fit your specific software solution. Ask engineers – if this is not mentioned in their proposal – what technologies they have evaluated and what arguments influenced their choice.

Design alternatives are essential.

It is necessary to evaluate implementation alternatives to install the best functionality and reduce software development costs. It’s no doubt that qualified software designers will ask about your goals and known limitations and then ensure that the proposed technologies fit those conditions.

It is a typical situation when the beta version of the technology or product that is still under development provides much better functionality to exactly fit customer’s needs. On the other hand, it is unstable and becomes quite risky to use it. This was exactly the case with a customer of ours, who wanted to develop a customizable component to be used on a number of web sites. The new version of web development framework offered great personalization and customization functions, and promised huge budget savings. We sat with our client and analyzed advantages and disadvantages of the both alternatives. Counting the costs and timelines, the customer finally made a decision to go with the new framework, but also knew and prepared for all the associated risks.

Ask your candidates which options they have considered and see if their proposal offers several choices with advantages and disadvantages outlined. Also, make sure that they will evaluate a couple of the most promising implementation options at the stage of software design. Still, the final decision should be made by business owners, who can consider costs, added value and associated risks within the entire project context.

Technical issues may help.

Application integration is one of the most challenging areas of software development, and one obstacle is the technical issues inherited from the existing software systems. You can easily deal with the provider who is able to identify the weaknesses of the existing solution. I remember a case where we were asked to migrate B2B transaction software. The system was used to transfer financial data and invoice images over the Internet, and because the information was very sensitive only highly secured channels were used. At the same time, there was a hole through which an advanced user could access confidential data directly from the server, outflanking defensive frontiers. If your provider is able to detect and remove such holes, the developers are more likely able to guarantee they posses the experience you need.

Do you know the critical issues in the integrated applications? Make sure that your provider is able to identify them and use those issues to assess your candidates’ skill and attention.

Spending on proof-of-concept saves cost.

When placing your order with niche professionals, you expect them to know the best solution for your needs. Although this is true, the very specific problem of your solution or emerging technology may introduce an unknown limitation.

Such limitations can become the Trojan horse that can crush your solution. There was a case where one of our customers insisted on using BPEL implementation that became available to one of Java application servers.. Time-to-market governed decisions, and we didn’t insist on prototyping. During development, several unpleasant surprises surfaced. The BPEL development cycle used provided tools that became significantly slower than if we had used plain EJB. The resulting performance became significantly lower than expected. Because the implementation code was already generated, the team had no reasonable means to improve the performance. The solution was breaking, because of a single overlooked detail. The new technology failed because of performance issues.

Prototyping is a tool that helps to explore alternatives and how the technology matches to your needs and is a checkpoint to see if it truly adds value to your software. Never agree to straightforward projects where new technologies are planned to be used without any proof-of-concept.

Advanced security skills add value.

Integration of different applications brings security to the top of the solution design. The platforms and application servers usually cover company’s critical security needs, but the developers’ design craft lies in the use of these techniques.

For example, B2B transactions are often secured through digital signatures, but in most cases the message integrity can be easily achieved using simple SSL and client authentication. This can dramatically reduce hardware requirements and simplify software configuration at the same time, while effectively providing the same level of security for the solution. The decision can be made after considering current security requirements, future software development plans and available technical metrics. Only after this can we effectively communicate the security proposal to the client and prove the selected concepts and technologies from a wide choice of the traditional and emerging techniques.

If the provider doesn’t address software security issues in their technical proposal, you should become very cautious. At minimum, ask how they will ensure a secure data exchange. Read more about possible software security vulnerabilities here http://www.axmor.com/software-consulting/security.aspx to ensure that security will be addressed by your outsourcing partner.

Communication.

Integration means that developers will deal with existing corporate applications and should interact with your IT leaders to build an adequate solution. Do your bidders show a good understanding with your developers? Are they able to communicate and address technical issues effectively?

Invest time and effort to perform due diligence of the potential suppliers. It is essential to check skills and experience in details. Additionally, we recommend paying most of your attention to the technical proposal and evaluate the provider’s approach to the solution design. If you are still not sure, start with a small project and measure the supplier’s potential in the areas described above.

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…

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.