Steps to Create a Custom Software Plugin

A month ago, almost halfway into a year-long project I have been working on, I was tasked with taking some address book functionality from an application, and including the same address book functionality into the application I was working on. The address book functionality at a high level had the basic requirements: add, edit, delete and select functionality. After a code review on what had been developed for the address book and deciding what would be the easiest way to use this functionality in other applications, we made the decision that we must extract the address book functionality into its own plugin project so it could be included independently into any applications that may require its functionality. Our goal was to make a standalone plugin component that was self contained and could easily be used in any desired application or project in the future.

In a developer team meeting we came up with a few steps to make the transition to creating and using this plugin as simple and reusable as possible. I will review, break down and throw my personal experience into each step to try and make it understandable and justify why we used this process to create a decoupled plugin component:

1. Get the functionality working as expected while embedded in the application.

•  A team member start off by creating the address book functionality inside of an application to ensure it was working as designed. I took over from the project when the majority of the functionality had been completed. Separating the functionality into a separate plugin project does not mean it cannot be updated and changed with ease. It was simply to make sure we could get the functionality of the address book working before worrying about any problems that may come with separating it out. Any problems or issues that arise from the core functionality should not be mixed with issues that may arise from separating out the plugin component. Our teams thinking is that it will save a lot of time because everything is contained in one project and there will not be the hassle of updating and building a dependency just to test out new functionality.
• In my case I was not in charge of creating the address book functionality, only decoupling it from existing project so it could be reused. It was a good start to the process because it forced me to fully understand and code review for one of my team member’s code.

2. Create a new project and copy over everything that is used for the plugin functionality.

• When creating a new self-contained plugin it is very similar to creating a new small project. In this scenario my team is using an MVC architecture, so in addition to the visible UI features for the address book I also had to create a model and controller. The model was responsible for maintain the list of address book entries while the controller was responsible for saving new and updated entries.
• For consistency and maintainability of the plugin I also included the same template used in the applications so the components and workflow would work look, and act the same as they did when it was included in the application. From the applications perspective, we did not want there to be any change in experience so it all seemed to be part of the same process.
• Creating a constructor for the component was interesting as I had to remember to keep simplicity and reusability in mind. It would be too easy to pass the entire state of the application into the plugin and use it, but then it would be very hard to use that plugin in any other scenario that may not have been as complex as the initial application. All said and done, the constructor really only contained a few variables that would populate the address book data appropriately. It was recommended that if anything “unusual” was being added to the constructor it should be an overloaded constructor, documented in the readme, and have a good reason for being there in the first place.
• As with any theoretical vs. practical dilemma, I would be lying if I said the plugin was completely decoupled and independent from the application containing it. There was one thing that I could not figure out how to decouple in the time given to do the task, so I did the next best possible thing. I was not able to create a separate settings file in the plugin that would extend the containing applications settings file. The settings file contained timeouts and settings used by the plugin and application. I had to include the settings for the plugin in the application. However I made the plugin safe by creating a check when the plugin was used in an application. On initialization of the plugin I made sure that the settings needed were included in the application settings file, and if they were not I threw a detailed Initialization exception telling them exactly what to add in order to get the plugin to work.

3. Use notifications and events in the plugin to update listeners in the application.

• Create notifications and events in the plugin that will update the application. The event will be responsible for storing all and only the information needed by the application when an updated is made. The notification is responsible for triggering whenever a new updated needs to be sent and received by all of its listeners.
• A list of listeners should be added to the plugin, all of which will be updated when the notification triggers. It is the responsibility of the application to add a listener on the plugin component which will be triggered by the plugin notification events. The application can do whatever is needed to update its state with the plugin event information without the plugin needing to know.
• The plugin is only responsible for triggering an update with the event information whenever it is notified, and the application is responsible for adding a listener to the plugin even and using its information to update its state accordingly. We use this pattern so that the application only knows about the plugin component if it is included and used in the containing application. In this scenario, the notifications and events were only triggered when an address book entry was selected, as the application used this information to store the owner of its product.

4. Remove the plugin functionality from application.

• Similar to where I copied everything from the application to a new plugin project, now I needed to remove it all from the application. I removed anything related to the address book and their related dependencies from the project (except for the settings of course). I recompiled after I believed everything was removed to make sure there were no compile time errors.
• At this point, I had completely removed the address book functionality from the application. I ran it confirmed the application still ran as expected without the address book functionality.

5. Include the plugin and listeners in the application.

• Include the dependency for the new address book plugin into the application. I actually had some difficulty here as my project was trying to import two different version of the base template, and obviously failing to do so. I ended up updating the plugin dependency (I am using Maven POM files for dependency control) so that it had access to a range of version and was able to use the same version as the containing application.
• The last (and most rewarding!) step was to create an instance of the component and add it to the view. Finally, I added a listener on the plugin component and used the events contents to update the application state whenever a new address book entry was selected.

6. Retest.

• Since the address book plugin is now decoupled from the of application, if a bug is found or something is not working as expected that was related to the address book, it was an quick updated to fix it and rebuild it into the application. In addition I also tested the points of integration and made sure that the listeners on the application were being updated when I expected with the content I expected.
• Testing was really the easiest part of the plugin process as it now has a very high cohesion, so finding an issue is much easier when there is far less code to dig through.

Creating this plugin was an exciting chance to step away from my everyday application development and take on a new challenge and create a process going forward with plugin components. It was nice to given guidelines by the team, but also given the freedom to develop the plugin my way to these standards. It gave me a chance to create a plugin that would be compatible with multiple applications that followed the core principles of software development: high cohesion and loose coupling.

The address book plugin project is still being fine-tuned for approval, but thanks to plugin all that is required to update new changes is a version update of the plugin in the application. I believe that we created a process that is easy to follow and maintain while still being cost effective. I hope to be able to apply this process to future similar projects that come my way.

If you have any specific questions or comments feel free to leave a comment or contact me a riley.pickerl@mnp.ca.

Rational Team Concert Tips to Efficiently Get The Job Done

For the past two years I have been working with IBMs Rational Team Concert (RTC) as it is my team’s project collaboration tool. Using some sort of collaboration tool is essential in any software project setting to manage timelines, priority and team member task ownership. Not using the proper collaboration tool is going to become a nightmare for project managers especially, but also all other team members involved because constant updates will be required. It will inevitably lead to loss of maintainability of items; traceability of when an item is being worked on and by whom; and creates overhead in calculating timelines and assigning work to team members. RTC is the perfect tool that has been designed to be a perfect fit for software development teams.

I have used RTC for numerous sprints and even across different projects. It has a large effect on how my team and I progress through and manage our time on a project. I have been on projects with both Agile and Water-Scrum-Fall based methodologies and we have found ways to modify RTC to work effectively for both. I am going to share some of the easiest modifications and techniques used in RTC that resulted in a better workflow for our team. Some of the ways to improve our process are due to customizations we have made in the workflow of how we use RTC. I will not go into the details of how to make these customizations in this article, but I will instead explain what we customized to improve our development and management process. I have compiled a list of the most effective techniques and modifications made with RTC that our team uses that work for the diversity of members and roles involved on the project.

1.  Always assign a Priority (and Severity) when creating an item – A side from placing an item in a sprint, setting the priority and Severity of each item should determine the workflow of the project. It is an easy way for managers to make sure that developers are working on the most important functionality for the business. Each day when I come into work I check a query in RTC that shows me the highest priority and highest severity items that are either unassigned or assigned to me. If I am not working on the highest priority item then I might need to stop what I am working on and switch to something more important. It can be very easy for a developer to get side-tracked and work on something that might be a low (or really have no priority) so this is approach will help to keep them focused on delivering the most important functionality to the business. Severity is very important but is only used on defects for our projects. The severity of a defect will usually determine the priority, but not in all cases. Businesses may also have regulations that determine if a defect is deemed very severe no one’s leaving until the defect is resolved or at least the severity is reduced.
2. Give the Summary/Title a meaningful and descriptive name – Use accurate and descriptive keywords in the summary of the work item. It will make all the difference when you want to quickly search existing tasks. One of my favorite features of RTC is how accurate and easy it is to search. You can search for anything within an RTC item, but usually if you are trying to search for something you will only try keywords that would be related to what the task is trying to do. Creating meaningful titles will also help reduce clutter and duplicate tasks. I have come across too many items with names like “Complete Step 3” instead of “As a User, I should be able to enter my credit card information”. I would recommend that if you come across tasks with generic titles to change them to something descriptive. Your team will thank you later.
3. Create templates for clarity– Similar to creating descriptive summaries for items it is also ideal to create a pattern in the description so when a team member opens a new item they know exactly what is expected on them. In our team we have come up with a set of steps we use when a defect is reported that we require before working on it. The form is as follows and is located in the description field of defects:
   

   a. Description – brief description of the issue.

   b. Steps to reproduce – Steps on how to reproduce the reported issue.

   c. Definition of done – What needs to be done so that the defect can be closed as resolved.

   d. Signoff person – Who needs to approve that this defect has been tested and resolved.

4. Always assign new items to a team member – By assigning tasks to a user you are increasing the traceability of that task. Assigning tasks to a user puts that individual in charge of it. RTC will also by default email the user if it is assigned to them so they will not be stuck with an unknown task at the end of a sprint. If a new task is entered and the user is unsure of whom to assign it to, assign it to the lead developer and they can reassign it to the individual in charge of the item. I have seen quite a few unassigned tasks not get completed because they were never placed in the scope of a sprint and the team was too busy with other items to pick up an item that could have been more important.
5. Tag users in comments when asking questions on an item – Tagging users will by default email them with the question you are asking. Without tagging a team member in a work item they may have no idea you are asking or need anything from them. Usually questions can be a blocker to completing an item and getting a quick response is always desirable. As well, I would highly recommend asking questions related to items though RTC instead of directly through email as it will keep a trail of conversation for traceability. Therefore, when any member looks at the task they can easily understand exactly what is going on.
6. Update the status workflow to match your environment promotion process – RTC allows you to customize the status and workflow of items. Working on a project with multiple test environments, we have found it extremely useful to include in the status which environment the item is in. For example, the status of an item would go from New -> In Progress -> In DEV -> In QA-> In PROD. Therefore, you can always check if an update has been applied to a specific environment, and if something is wrong with the update you know what environment it can be found in.
7. Create a standard when determining item estimates – One of the hardest things I have found to do as a team member is accurately estimate the time required to complete for each item. Within our team to get the most accurate estimate we try to get the person who is assigned to, or most involved with the item to make the estimate as they will best understand what is required. Additionally, we have a standard that you must include the time it will take to promote this update to production so that you have some ‘slack’ and do not underestimate and create frustration with managers.
8. Create queries that highlight outstanding and important items – RTC allows users to create a private or public custom query to show any list of items. Use these to your advantage and add them to your dashboard so at a first glance it is clear what the top priority is and what can be picked up if needed. I find these really helpful so I can see which members are working on the top priority items and who has a heavy list of items and who has some availability to do a code review. My project lead created queries that show the “top priority” items as well as “To be picked up” items which were ordered and if someone was looking for something to work on it could pick taken off the top off the list so there is no confusion as to what needs to be done.  

As part of any good software lifecycle each sprint and project is followed up with a retrospective which has given us time to think about how we can better improve our process using RTC. RTC has been a very effective tool for our team because we have learned to use and modify it to meet and adapt to our team’s needs. The list provides simple ways we believe have helped us deliver a better product more efficiently.

It has been our exposure and experience with RTC that helps our team keep on track and deliver the best possible product to our clients. I would highly recommend RTC as a collaboration tool for any Agile or Scrum based projects. Our team has enjoyed using it and we hope that with each retrospective we can come up with new and better ways to improve our process. Hopefully you can use these tips to help improve the process used with your collaboration tools.

Using Vaadin to Deliver World-Class Functionality

For the past few months I have been involved on a project with a client that involves updating a customer portal. The first steps of the project were to conduct POCs to determine what frameworks and technologies we would use to update the portal. As a team we chose to use Liferay as a portal framework and decided to use Vaadin as out application development framework. For the past two weeks I have been working with Vaadin consistently to create some of the core functionality in the portal. Our team even went through a three day training session to learn Vaadin’s capabilities, patterns and best practices.

Our team chose Vaadin over other web application frameworks because of its ease of use, versatility, and its cross-browser consistency. Aside from these key factors there were also some larger project based variables that seemed to align well with Vaadin’s target market as expressed in Hildeberto’s overview.

Vaadin is built off of Google’s Web Toolkit (GWT) so it is backed by a strong core and provides a variety of popular features for building web apps. In addition to building web apps we will also be using Vaadin to create portlets within Liferay. One of the nice things about Vaadin is that it is all Java based, similar to the Java Swing framework, there is no explicit JavaScript or html required to create a fully functional portlet or application.

Vaadin 7 was recently just released in April 2013 and would be a good baseline for development, however due to restrictions with browser support our team will be using Vaadin 6 in our environment. The “deal breaker” for not using Vaadin 7 is its compatibility with outdated version of Internet Explorer. Vaadin 7 only supports IE 8+ browsers, where Vaadin 6 supports IE 6+ browsers. A large percent of the projects current portal user base still uses IE 7 (and a much smaller but still accountable percent use IE 6).

Currently, most of my development with Vaadin has consisted of displaying table contents. The portal allows the client to display needed information to its customers, and the most intuitive way of doing this is through a tabled view. My role has involved working on an advanced table view which offers the customers an extensive list of options for viewing information within the table. The list of features I have been working on incorporating for the project consists of a:

• General search – Searches all columns for the search criteria.
•  Advanced search –Lets the user search for criteria within a specific column.
• Collapsible columns – Columns can be shown or hidden from the table.
• Reordered columns – Columns can be reordered throughout the table by drag and dropping them into the desired order.
• Sorted Columns – The contents can be sorted in ascending or descending order by column when clicking on the header.
• Table Export – The contents that are displayed in the table can be exported to excel, pdf and/or xml.
• Print – The contents that are displayed can be printed in a user friendly table.

Naturally, the majority of these features are supported in Vaadin’s API making them very easy to implement. If they were not we may have needed to reevaluate our framework choice.  However, a few of the features are supported as Vaadin add-ons which are side projects created by individuals and shared with the community. The add-ons have been very helpful however for implementing desired functionality quickly. However, I have come across a problem where some of these features are not compatible with other available features.  For example the advanced search (filter table) and the excel export will not work together without some modifications. Our team will have to look into how we can incorporate these features together to give the customer the greatest benefit of using our advanced table’s functionality.

One concern about Vaadin that a colleague brought to my attention is that Vaadin is very concentrated framework and if there is functionality that you want to create that is outside that scope of what Vaadin has to offer it might be very difficult to implement and take much more time than it would with a JSF framework. In training we were taught about how to create widgets and custom functionality for Vaadin using the GWT. I am currently working on some customizations to that Vaadin table that may fall under this category as the functionality I am trying to customize is not functional and would include modifications to how Vaadin’s components work. If all goes well the customizations will be quick and painless, and if not… you may be hearing from me again. A framework that limits a developer’s freedom to customize is not one to be highly praised.

All in all I have really enjoyed working with Vaadin. It has provided a vast variety of functionality quickly and consistently across browsers. After the training session it became apparent as to how to utilize Vaadin in our portal project to take advantage of all the features it can provide on both the client and server side. I have been really happy with the integration of Liferay and Vaadin having no issues with the two frameworks working together. Vaadin’s API has provided a majority of the functionality required for the project and it will be interesting to see how easily customizations to Vaadin’s components can be applied. If anyone has any experience with Vaadin or is interested in learning what patterns our team has used feel to leave a message.

Liferay Competes Against Software's Top Dogs

Portals are essential in today's Internet driven society. Portals are a gateway to transfer related knowledge and data between a provider and a user. Although portals may seem to be obtrusive, they are in fact beneficial to both the user and the provider, making them a "no-brainer" when identifiable users are required. Users benefit from portals because they enhance user experience, allow personalization, and provide a gateway to view and create data associated with the provider's organization. Providers benefits from a portal because they can track account information and usage, easily create and share organizational data, as well as increase business values by providing a simple medium for users to interact with them.

Over the past couple of weeks I have been doing research at work for a large web portal that we are about to build with a client. A large part of my role has been to research and test existing portal frameworks. There is quite a variety of portal frameworks available on the market, but really only four that are leaders in the field. The leaders list (which was created in a study on portal evaluations by Gartner) consists of Microsoft'sSharepoint, IBM'sWebSphere, Oracle'sWebCenter and Liferay. I would guess if you are unfamiliar with portal frameworks that you have heard of all of those companies except for one... Liferay, being a hopeful cost-effective option as it is an open-source enterprise portal framework. Open-source software (OSS) is becoming increasingly popular in the software community and is usually desired if the reliability and functionality meets or exceeds that of competitors. Although cost is a bonus factor to OSS, a large technology factor that should never be overlooked is the product support and available help for the software and lifetime. Even though OSS may have associated licensing costs for production use, it is often a much cheaper solution then competitors if the business goals can be met.

The viewpoint that I have had in evaluating portals is that of the users. Although I am a developer and would love to dive into the technical and programming side of the evaluation, a more important role that must pass evaluation first is the general usability of the portal. The usability of the framework features provided to organizational users and the clientele users is much more important than the difficulty of the programming integration with the framework. Why? Because user experience is the heartbeat of all web applications. Keep the users happy, and the site will live a long and healthy life, don't, and you can watch the site sick on life support till it dies.

To evaluate the portal I was only looking for what the framework provided off the shelf (OTS). By OTS, I mean no programming or hooks to change the functionality of the framework. Strictly downloading and unzipping the server instance… that is all. In evaluation of the Liferay portal there were guidelines and test criteria that were an essential "must" to meet business goals and be considered further. One factor I kept notice of was to make sure that if some criteria's needed functionality was not currently supported, could it be? And if so, how difficult and time consuming will the modifications be? The specific guidelines and criteria that are desired in a framework vary for the different types of business goals and value looking to be delivered. However, with my research and experience with the Liferay portal I have created a list of the OTS features that I like and dislike about it from a usability standpoint, as well as a developer about to be arms deep in it.

Liferay features that make me glad to be using the framework:

1. The 60+ portlets that come integrated in the Liferay framework to help get started.
2. Intuitive feature layout to help customize and create the portal architecture quickly.
3. The simplicity of having portal configuration options easily accessible all in one place on the browser.
4. The ability to "Impersonate" users of the portal to check their permission on sensitive data quickly.
5. An active community forum that helps get quick answers to any questions.
6. It’s easy integration with Liferay Developer Studio (Eclipse) allowing programmers to quickly get their hands dirty.

Suggested changes to Liferay to increase the framework's popularity:

1. Create intuitive saving options. Currently after saving, the saved changes window does not close automatically, leaving the user confused and frustrated.
2. Allow the user to set up role specific permissions on content AS it is being created/uploaded. Instead of making the user set role specific permission on content AFTER it has already been created/uploaded.
3. Increase documentation and tutorials on the features the portal has to offer.

Learning new technology and what it provides is a crucial part of my job. Developers deem themselves as being "lazy", meaning that we will never re-invent the wheel if there is a perfectly capable wheel available for use. If frameworks can be provided that will help meet business goals and reduce costs, it's no longer a question of "should we use one", but instead "which one should we use". Liferay has been a fun framework to research and work with, and I hope that it will continue to impress my team and I with the functionality that it offers to help deliver a world class portal.

User Experience Tips to Keep Your Site Trending

User experience (UX) is quite possibly the single most important attribute to consider, when implementing website design. Due to the rapid development of new hardware and software technologies it can be difficult for organizations to supply a satisfying web experience that meets the expectations of all it's demanding users. With so many options for the users to browse, the goal is to make them hooked on your site. Maintaining a users attention can be caught in a number of ways. An extreme example would be to go over the top and impress the user by providing tools or services that others may not. A good example of this is Ford's vehicle comparison tool. A more realistic example however, is to follow the latest recommended UX trends in web design. These trends help to create a holistic website experience for the user. By keeping your website in touch with the most current user trends, users find it more difficult to navigate elsewhere.

In preparation for a new project that my team and I are about to participate in at work, I have been researching world class UX designs and features. In the process, I have reviewed some of the highest customer satisfaction websites as determined by third party sources, as well as many UX magazine articles that provide information related to creating a good web atmosphere and experience. Through my research, I have found a number of similarities that are consistent among all the world class websites designs. I will list an overview for you on the key attributes I have found to be required to ensure a good UX in any website. My list consists of:

1. Minimal front-end loading: An increasing number of web users are using tablets and smart phones to access the Internet. These devices are great, as they allow users access to website content from remote or wireless locations. A limitation however, is that their signal strength may not be as strong as desired in a wired community, so if they have to load a video or massive amounts of images just to view the homepage they may become agitated with the delay and leave. It is imperative to ensure that at a minimum, a user can navigate to a website homepage and view their options without an uncomfortable waiting period.
2. Easy navigation: Technology advances have created impatient users. Time is non-refundable, so if a user wants certain information, then the website should be able to give it to them quickly. If a user cannot navigate to the desired webpage in three steps or less then they are likely to become frustrated and give up. The difficulty in creating a good UX design is finding the proper trade-off between efficient navigation and a simple, clutter free website.
3. Interface simplicity: Simplicity is the game-changer. It is the difference between the household website names and its inferior competitors. Take Google for example. Why does it dominate the search engine regime? Because it has one text field that every web user knows exactly how to use. The problem with older versions of Bing and the other players is that they clutter their search pages with news, images and other complexities that confuse the user of its exact use. How many times have you opened a browser and been at the MSN homepage only to navigate over to Google to search? More then once I'm sure. Remember, keep it simple to make confusion minimal.
4. Layout consistency: The layout of the website ties to the simplicity of the interface, but it plays a large role in website UX so I thought it needed to be explicitly stated. The color scheme and theme of a website are important to give the user a good feel for the website, but more important is consistency of the template used throughout the entire website. The human brain is better at recognition then memorization. Using this principle, by placing elements in referable locations consistently throughout the website, users can both recognize and memorize the elements and their functions effortlessly. There are recommended positions for each element (or group of elements) of a website based off of extensive research. The results help designers understand where a user is likely going to look to find a desired action. Keeping navigation, settings, and website specific options in the same location throughout the user's website experience is needed and expected to avoid irritation.
5. Resolution and browser compatibility: With the numerous number of devices used to access the Internet these days it is critical to support all screen resolutions and browsers to keep the growing audience happy. Using cutting-edge style sheet technologies likeresponsive design, CSS grid systems, and boilerplate's, all help keep a consistent UX throughout the varying browsers and display sizes. One of the biggest changes in recent UX trends is that websites now need larger text and buttons to accommodate for smaller touch screen devices. A single modular website design that takes these issues into consideration can satisfy users on all screen resolutions and browsers without the hassle of scrolling, zooming and non-compatible features.

The list contains the bare necessities needed to satisfy the current UX trends. However, the purpose of the website may change how these necessities are obtained and which ones require more focus and detail then others. A good website user experience is always preferred by both the stakeholder(s) and the user, so it is hard to imagine why any new website designers would not take these principles into consideration.

Offshore Outsourcing... Enter at Your Own Risk!

Offshore outsourcing is a touchy topic in the Information Technology field. Many organizations ship projects overseas and see nothing more than a bill and an upset customer at the end of the day. Others, with great success, have an awesome releasable product at a reduced expense.

I became interested in offshore outsourcing after a brief experience with it this summer. I wanted to know why outsourcing experiences are so hit and miss. I recently finished a paper on managing offshore outsourced projects, and with my research and personal experience I now better understand why so many projects have failed to meet budget targets and other expectations.

The problem begins with estimating the time and cost for an offshore team to work on a project. It all seems so simple… pay $20/hour for services offshore instead of paying a local employee $100/hour to do the same job. It’s a no brainer, right? Outsourcing reduces employee costs and can therefore increase potential project profit. How could this fail? How could a project being outsourced for a fifth of the price end up costing more than having a local team do it?

Where inexperienced managers go wrong is they forget to accommodate the cost of cultural differences, language barriers and the added time they will have to commit to project initiation and maintenance. An offshore team cannot simply replace a local team of the same size. Although technical skills may be equivalent, an offshore team will lack the soft skills to efficiently communicate with local management. Managers also underestimate the amount of initial time and money they will have commit to get the project running. In North America, it is commonly believed that sending detailed documentation to the offshore team will clarify their roles and expectations for the project. Wrong. Interpretations of the documentation are misunderstood and the project can start off in the wrong direction quickly. It is important to always keep in contact with the offshore team on a daily basis and monitor the work outcome regularly. Face to face communication is the most recommended communication medium as you have a visual sense of the confidence or uncertainty in the team’s roles and assignments during the project. In an agile environment, expenses can also accumulate because you either have to arrange for the offshore team to directly associate with the client regularly, or have local team members interpret potential changes to the plan with limited hours for face to face dialogue due to work time variations.

What a client envisions and what a client describes are usually different. Clients often do not know exactly what they want so it is important that all three partners, the client, the local management team and the offshore team know what is expected from the project. Most often, the problem with offshore teams is that the project is contract-based. Therefore, whatever the contract states becomes the expectations of the offshore team. However, the offshore team has to realize, and the project manager needs to clarify that the course of the project may change as the clients desires change. It is expected of the offshore team to follow up on changes to the contract identified along the way.

The stories of success often come from experienced managers who have been consistently working with offshore teams for quite some time. Most of them agree that outsourcing is not a “quick fix” to budgeting issues and that most projects will not see any benefits to the outsourcing process for about nine months. The outsourcing process takes time to learn how to estimate project costs effectively and account for hidden costs that will undoubtedly surface along the way.

Here are some final words of wisdom if you are planning on outsourcing a project:

1. Be patient. The cost savings are not immediate.
2. Managers or lead team members will still have to commit as much or more time to the project.
3. Cultural differences and language barriers will always increase the cost.
4. The right project has to be picked for the offshore team. Not just any project will work.

If you have any experience or insight on offshore outsourcing, please comment on your experience.