How To Work Out A Software Development Contract With An Overseas Provider

You may be surprised to know that many companies in the US and UK do not put together a water tight contract when dealing with an overseas software services provider. Most of the agreements are done via email with little or no regard to important aspects such as dispute resolution, intellectual property rights, confidentiality issues and employee infringement. If you plan to use an offshore provider soon, here are some basic tips on how to draw up a workable contract which safeguards the interests of both parties:

Define deliverables: Since software development is mostly intellectual work and has many grey areas in its definition, it is advisable to define deliverables in a detailed fashion. This helps in making sure that the understanding of the work is clear on both sides and there is no miscommunication of any kind with the supplier. You can also choose to define the change management process and the number of revisions allowed as it makes the deliverables more structured.

Mention the acceptance clause: What is good for the goose may not be good for the gander. Though an old saying, there is a huge amount of truth in it. Sometimes the software services provider may consider the work completed whereas you might not accept it. Thus the goal or the premises on which the work will be accepted should be clearly mentioned to both parties concerned.

Confidentiality rights on both sides: Sometimes companies get an NDA signed with the service provider and expect it to hold true even when working on the project for a long time. This method is not advisable. A suitable contract must be drawn up in the case of ongoing work so that issues such as confidentiality of information are maintained by the service provider. Though some customers feel that their projects do not warrant such a clause, the information exchanged may even be about the company, business or related information which has been given out unknowingly.

Employee Infringement: Approaching a service provider's employee directly is one of the cardinal sins which can be committed by a client. Thus as a service provider, it is necessary that this clause is mentioned in a contract. The opposite can also happen where the service provider may approach the client's personnel for indirect or direct gain. An employee infringement clause keeps a check on such practices and provides a legal route if there is substantial evidence of the infringement.

Force Majeure: The relatively recent natural calamities of the Tsunami and Hurricane Katrina have made it necessary for many large companies to seriously consider the Force Majeure clause. This is necessary to protect the interests of both parties.

Last but not least, pricing: This is probably the most common reason for arguments between a supplier and vendor and is applicable in all industries throughout the world. A clear mention of the total project pricing and milestones at which the charges will be paid should be included as an important schedule within the contract.

There might be other specific terms and conditions which may have been agreed by you and the supplier. These should all be mentioned in the contract not only for the sake of posterity but also for ensuring continuity of work in case of personnel change in the supplier's company.

Oracle E-Business Suite Integration & Development – Software Factory Approach

When we talk about implementation, customization, integration, data conversion and tailoring the ERP for large corporate business or non-profit organization, we need to formalize and structure software development project. This approach is also referred as Software Development Factory.

The Software Factory concept is based on a production line for systems from user requirements to software delivered. This production should be done without any direct communication between developers (production line workers) and users, system analysts and designers (customer side), based upon a scope, schedule, costs and quality standards.

A software development process is a fundamental piece to a software factory success, it considers all software development cycle and help project activities and resources management (plan and control). The activities could be categorized as following:

• Project Management: project scope definition activities; version control; work, quality and risk plans; human resources organization, training and allocation, and so far;

• Business Requirements Mapping: based on specific business requirements and Oracle Applications functionalities gaps, customizations (extensions) will be planned and developed;

• Module Design and Build: activities to estimate, plan, design, build, test and document custom program modules (forms, reports, database, etc);

• Business System test: integrated approach to testing the quality of all application system elements;

• Performance Testing: these activities helps the project team define, build, and execute a performance test on specific system modules and configurations;

• Adoption and Learning: accelerates the implementation team’s ability to work together through organization-specific customizations learning.

Other important development process features are standards names for file structures, tables, fields, variables and others key elements used during development activity. This facilitates upgrades procedures and applications maintenance.

Oracle E-Business Suite: Software Factory Development Process

The Software Factory concept is based on a production line for systems from user requirements to software delivered. This production should be done without any direct communication between developers (production line workers) and users, system analysts and designers (customer side), based upon a scope, schedule, costs and quality standards.

A software development process is a fundamental piece to a software factory success, it considers all software development cycle and help project activities and resources management (plan and control).

Software Factory for Oracle E-Business Suite Projects uses a software development process based on AIM Advantage (Application Implementation Method). AIM Advantage is a proven, comprehensive method and toolkit to successfully guide implementation of an Oracle Applications solution. Developed and sold by Oracle Corporation, AIM is used by Oracle consultants, partners and customers when implementing Oracle Applications.

Talking about Oracle Applications extensions only, AIM offers templates and tools for all extensions development cycle, considering problem definitions phase, business requirements analysis, system analysis, design, build, test and transition to production environment. The activities executed can be categorized as follow:

• Project Management: project scope definition activities; version control; work, quality and risk plans; human resources organization, training and allocation, and so far;

• Business Requirements Mapping: based on specific business requirements and Oracle Applications functionalities gaps, customizations (extensions) will be planned and developed;

• Module Design and Build: activities to estimate, plan, design, build, test and document custom program modules (forms, reports, database, etc);

• Business System test: integrated approach to testing the quality of all application system elements;

• Performance Testing: these activities helps the project team define, build, and execute a performance test on specific system modules and configurations;

• Adoption and Learning: accelerates the implementation team’s ability to work together through organization-specific customizations learning.

Other important development process features are standards names for file structures, tables, fields, variables and others key elements used during development activity. This facilitates upgrades procedures and applications maintenance.

If you would like to see how an Oracle Applications customization would be using such a techniques you can contact us, we are able to work with you on your company specific needs with great results and quality with affordable costs.

The Benefits of Custom Software Development vs. Generic Applications

In the world of computers being used for business, it is essential to have quality software regardless of the type of business you offer or the size of it. While technology is a great thing, it can be complicated especially when it comes to the issue of software. You don’t want to purchase general applications that are difficult to use and maneuver. You also don’t want to have additional features that you will never use. This is why custom software development is often a much better choice.

Custom software development starts with identifying your goals and the needs of your business. In many cases custom software development is less expensive than a general application because it is designed to meet your business needs. You also don’t have additional programs and features that you will never use. You will also get the software to do exactly what you need it to do, saving time for yourself and the other employees who may use the software.

It is important to choose a software programmer or developer who has taken the time to understand the type of business you conduct and what you want the software to do for your business. Check their references and that they are credible. You will want to find out about training, customer support, and a refund in the event you are not happy with your software. There are many reputable software programmers you can find in the newspaper, the yellow pages, and on the internet. It is a good idea to get an estimate for the work, what the software functions will be, and the completion date. All of this information as well as the training time and customer support should be in writing before you pay any money for services.

The 80:20 Software Product Development Lifecycle

The argument about off-the-shelf software products versus customized software has been ongoing for quite some time. As the industry matures, a mid-path has been achieved by ready made software manufacturers. This concept is the 80:20 software product development process which captures the benefits of off-the-shelf as well as customized software products.

Software architects have come up with the option where most of the common modules of the software is developed and a part of it is left to be customized later on. Thus eighty percent of the software is actually ready and twenty percent of customization allows the customer to get highly flexible software for a fraction of the cost of fully customized software. Benefit analysis shows that it is definitely better to pick up this software development concept rather than go for development from scratch as it helps save time and money and boosts the bottom-line of the business.

The cost of development of up to eighty (or thereabouts) percent of the software is divided over a number of customers and this makes the product very affordable when compared with 100% customized software.

So is there a downside of the 80:20 software product development lifecycle? It depends. The 80:20 software development process requires good management skills from the customer as well as the vendor end to ensure that the benefits really accrue to the customer. The vendor of the software should be able to demonstrate the software correctly to the customer and show him which sections can be customized. Similarly the customer should be able to spec out the customization sheet accurately for the vendor to get the software as per his or her requirement.

This process has a good level of success with large software manufacturers as they have started developing many applications which can be purchased by customers and then customized for them by third party suppliers. Most database software companies operate with this business model. Not only can the software manufacturer concentrate on developing good base software, third party software development companies can build competencies in customizing it.

Customization in 80:20 software products is usually done on the user interface, the navigation system and also within the database tables. Additional modules can also be added depending on the requirements of the customer. Costs of modifications are usually governed by the time that the vendor would require to do the work. Sometimes the vendor can also give a flat fee for various modules and the customer is free to choose which modules are required by their business.

However, 80:20 software development processes are not the only way to go. Many organizations with special needs will continue to work with customized software and organizations with limited budgets will work with off-the-shelf software products. Requirements and budget will remain the key reasons which will govern the choice and each option is liable to have its pros and cons.

How to Successfully Deploy Productivity Software Across Teams

Part 1 of 4: Software, Change and Missionaries

In 25 words or less, what would you define as the critical success factors for rolling out project and performance management software across a workgroup or team?

If you were to start today, what would be on your list for doing what works, and avoiding what doesn't? If you aren't sure, but interested, maybe even slightly uncomfortable at the prospect, you are not alone. Rolling out a project management or groupware solution is enough to make all of us in the position of management at some time or another cringe. It starts the voices in the back of the head. They are quite persistent in their warning that there is trouble ahead. The voices say that to launch on such a venture is to:

* Enlist direct reports and peers in learning "one more" software package amidst their protests that they are already swamped, and frankly don't need or want another tool,
* Incur high frustration, something akin to "herding cats" or "pushing a wet noodle up a hill,"
* Expose oneself to being publicly challenged, defied, and/or defeated,
* Fail to generate the outcomes expected, promised, or hoped for,
* Engage in risks such as spending money, taking on resistance and for what exactly?

In fact introducing new software to be applied across a team or group looks a lot like engaging in a change management effort amidst numerous risks. It is. Employing new software tools, especially as part of a step forward in performance and productivity, requires a change in the way people work. Let me say it again more directly, it changes the way people work. For many people in management, the software rollout (change) process means embarking with the expectation that "things are going to be different." And as we will see, often without having clearly defined and worked through with the group receiving the software what exactly is going to be different and why.

This article is a four-part review of our findings and recommendations in this area. But before we continue, let's be clear about what to avoid in implementing software, or as we like to describe it...

The course of the hapless missionary.

The typical process of implementation often starts with a technology adopter or visionary who becomes a "missionary" (for use of a software tool). By that we mean someone who decides that a software package is a valuable solution for others. Sometimes they arrive at this decision point out of personal experience; sometimes they arrive at this conclusion based upon what they think someone else on their team needs, e.g. "You really need to be more organized."

Having uncovered value in the software, they determine that it would be beneficial to have others, if not everyone, share in their discovery, and experience the benefits of using this software tool. They begin the process of attempting to convert others. They may or may not encounter interest, but they always encounter some form of opposition, passively if not actively. Everyone is not convinced they should convert to the new "betterment" tool.

Part of the missionary approach to tools, is the belief that others would share in their appreciation or value or benefit from this tool...if they would "just try it." However sharing their perspective and tools, even if done enthusiastically, is usually not enough to convert the team or group to a new tool. Typical results yield only a couple of converts within a workgroup of six to twelve, with regular usage by others limited to a cursory review and/or try it approach (drive it around the block and then back to the lot). This is further anchored or underscored by the belief position of other team members that:

1. "I'm too busy to learn a new tool," and
2. "I'm doing basically OK with the (preferred) tools I presently know how to use," e.g. so why do I need to change.

Encountering this type of reaction, an effort that started out with such zeal easily becomes thwarted. Our findings indicate that "missionaries" are eaten by the "cannibals" (give up on the software conversion due to resistant staff) within six months, if not supported by insistence from a person or position of power. What do we mean by that? Despite the lofty commitment to values of increased performance, productivity or simply reduced work effort, the average implementation across a group drifts into what might be called an aspiration. As aspiration to improve that is not realized, and is only moderately enhanced by a command from above. From inspiration to aspiration... without a successful deliverable turns out to be bad business. It's not just an unsuccessful attempt that generates little return on investment; it can leave individuals frustrated and the workgroup less collaborative.

Purchasing and installing productivity software from this purview parallels what one might expect to be the life cycle of the average piece of home workout equipment. The average consumer starts out with gusto in the inspired phase. Shifts to an aspiration as usage declines, and then concludes in storage or a garage sale. From inspiration to aspiration to storage on the sidelines as one more goal unachieved, due to the requirements of more work, more effort, more discipline... more of something than was unavailable to resource the change in behavior.

The good news is that we have also identified not only the painful average life cycle of (marginally successful) groupware implementation; we have also identified the patterns of what works in successful software introduction. Patterns that emerge in the three best practice areas mentioned above. We'll start with the first practice, "Shed illusions about performance improvement and replace with four key reality concepts" in part two.

Outsourcing Software Development Offshore

The trend to offshore outsourcing is continuing at pace, with Gartner estimating that a quarter of all technology jobs will be based in low-cost countries such as India by 2008. These are the lessons learned from a year of offshore outsourcing.

When starting any offshore outsourcing venture:

1. Make an effort to understand the cultural issues
2. Concentrate a lot of effort on communication
3. Start small and build up, try a model office and when its working take it offshore
4. Pilot what you want to do
5. Expect work to take 2-3 times longer while you develop your processes
6. Don't underestimate the management effort required to make the venture work
7. Document your processes in detail and make sure everyone understands them
8. Involve the offshore team from the beginning of a project and in the planning process
9. Don't assume implicit understanding of "the way things are"
10. Make an effort to understand why things aren't working, don't assume you know

These are some of the other important findings:

1. Make sure you have strong project managers offshore. Indian developers are not good at managing themselves and grind to a halt if they do not have clear goals and objectives set for them
2. Expect around a 30 per cent staff churn. Loyalty does not seem strong and employees seem to have no compunction about going down the road for a few Rupees more
3. Almost all of the companies seem to exaggerate their capabilities and worry about it later. Do not take industry certification (Capability Maturity Model etc.) as a sign that they actually operate according to it. Agree in advance the processes and procedures necessary for your business
4. Don't be blinded by the claims of huge financial savings. Sure, the costs are low, but you will spend a lot managing the relationship and man managing the Indian resources remotely
5. Outsourcing is suitable for large well-defined projects. Do not consider it for smaller pieces of work it is not worth it
6. Do not put all your eggs in one basket. Keep some internal resource, you will need them believe me

Offshore outsourcing can work given the right conditions and plenty of forward planning, but don't be fooled into thinking it's a bed of roses. There are plenty of thorns on the way to success.