Building scalable enterprise digital commerce for a global pharma giant
Digital transformation around the e-commerce services across multiple geographies and business divisions for a globally leading pharma company.
Software Development Outsourcing Issues
For most companies, outsourcing is an interesting option, but they are reluctant to explore this option. Many companies are not even aware of outsourcing possibilities. Occasional failures of outsourced software projects have been
1. Insurance
The outsourcer should have adequate public liability insurance against loss or liability through injury or damage.
2. Third party suppliers
The arrangements as to which party (purchaser or outsourcer) will hold and which party will administer the terms of any agreements currently in place between the purchaser and other third party suppliers. It is advisable to transfer the Maintenance contracts to the outsourcer unless the outsourcer has agreed to provide maintenance services for all equipment and software.
3. Software licenses
Where third parties supply software used to provide outsourced services, the appropriate licenses must be obtained. Any licenses currently held by the purchaser that relate to services being provided may need to be extended to cover the activities of the outsourcer.
4. Ownership of information
The ownership of data and information needs to be agreed. Should a dispute arise and the agreement be terminated, it needs to be clearly stated who owns the information and data.
5. Contract duration and commencement
The commencement date of the contract should be decided as early as possible to minimise transition difficulties when service provision is handed from the purchaser to the outsourcer. Given the complex problems that can arise during the handover of information technology services, it may be prudent to include a defined transition period as part of the term of the contract.
The length of term will depend entirely upon the nature of the outsourced services and the business requirements of the purchaser. From an outsourcer’s perspective, the price of the services is likely to be influenced by the capital costs involved in providing the resources required to maintain service delivery. An initial term of three years is typically seen as a minimum term. The terms of renewal should be based on performance and current conditions at the time.
6. System specification
The system specifications should be defined for function, performance and availability as part of the RFI and RFP phases. The service specifications such as response times and system reliability should likewise be defined at the RFI and RFP phases.
7. Service level agreements
Service level agreements are put in place to define the minimum level of service that must be provided. They are, therefore, the basis for measuring the outsourcer’s performance. SLAs will typically be included in the contract schedules and cover a number of areas of service including:
Measuring and monitoring service levels can be achieved through user satisfaction surveys and analysis of performance data such as system response and job turn around times. It is not always easy to identify performance measures that accurately reflect the standard of service required by the purchaser’s users. Moreover, SLAs can be ineffective documents unless the purchaser has practical and realistic remedies in the event of non-performance. Such remedies might include the withholding or deduction of agreed rebates from fees otherwise payable to the outsourcer, should the agreed level of performance not be maintained. Both purchaser and outsourcer need to be aware that SLAs are not inflexible and there should be a review period in the SLA to cover changing purchaser requirements and new technology.
8. Reporting and review
Closely linked to the SLA is management reporting and review of performance. Procedures for reviewing the performance of the outsourcer should be defined in consultation between the purchaser and the outsourcer during regular meetings. Each party should nominate dedicated representatives who will be responsible for liaising with the other party’s representative and communicating information and decisions. Such meetings should regularly involve the senior management from both parties and include adequate focus on future developments and forward planning.
9. System access and security
Access to the purchaser systems by the outsourcer needs to be considered in the context of current New Zealand privacy legislation, which is intended to protect personal information about identifiable individuals. An outsourcer may only require system access at certain levels to enable them to perform their service.
The level of security measures required to protect the purchaser’s system and information from unauthorised access will continue to require rigorous planning, implementation and management. Outsourcing services will bring additional issues of protection, confidentiality and ethics that the parties will need to ensure are documented and agreed with regard to their responsibilities and obligations.
10. Facility ownership and control
If the outsourcer is going to perform certain services using the purchaser’s equipment, who will own these assets? The outsourcer may enter into an arrangement to purchase these assets or they may be handed back upon termination of the outsourcing arrangements. In either event a detailed inventory of assets will need to be compiled.
What will be the relationship with suppliers of third party services such as communications or network services? Outsourcers may need to rely on competitors to supply services to enable them to provide service to the purchaser. This may require facilitation by the purchaser.
11. Personnel issues
Although the issue of personnel is often crucial, it is sometimes overlooked by those involved in outsourcing. People are fundamental to a business and are required to maintain business continuity during the transition period.
The arrangements for the retention, redeployment or other options for existing staff must be negotiated. This issue is critical as the outsourcer will require the institutional knowledge of the purchaser’s staff. Business continuity must be maintained during the transition, which requires that the purchaser’s staff be kept fully informed where appropriate.
Staff may need to be transferred from the payroll of the purchaser to the payroll of the outsourcer and a transition plan should be used to minimise the risk of service disruption and employment-related legal claims.
The employment contracts and/or collective agreements under which the purchaser’s staff are employed may require negotiations to be held with the relevant staff or their representatives. The early involvement of professional human resource managers and employment law specialists to advise and assist with contractual and privacy issues is critical to any transition to outsourcing.
The purchaser may also specify that a certain number of staff should be hired by the outsourcer and the outsourcer may require a certain number of people for the purpose of acquiring system and corporate knowledge. In these cases there should be an agreed process for the outsourcer to select, assess and engage the appropriately skilled staff from the purchaser.
The purchaser should also be made aware if any of the outsourcer’s staff are being shared with other clients.
12. Intellectual property indemnity
Each party should generally indemnify the other against claims of intellectual property rights infringement arising from the use of facilities and resources that they supply to the other as part of the outsourcing arrangements.
13. Warranties
Appropriate warranties should be provided including:
o warranty of authorisation and title
o performance warranty
o compliance with specifications
o service quality.
14. Disaster recovery
Agreement should be reached between the purchaser and the outsourcer concerning business continuity, should any of the outsourcer’s facilities fail.
people to entertain the various options that the fast changing globally competitive markets have to offer. Whether it is a service or a product to sustain an organization’s competitiveness, one has to relentlessly pursue cost reduction goals without compromising the quality of the solutions. Thanks to the Internet and the experience of Indian software professionals, outsourcing software has become an excellent service for the talent starved high tech industries.
Much like any other business, the pioneers reap the best benefits, although the early attempts are full of small failures. Thanks to the pioneers, the model has now been perfected and offers a complete scope for all types of companies to venture into outsourcing software to promising IT companies.
Contrary to popular perceptions, the potential benefits are derived best from small and growing companies. They are flexible and focus on delivery of services and solutions in time without compromising quality. Also when you work with such companies, chances are that you will often deal with the top management of the companies who understand the importance of working with clients and satisfying their needs.
There are a few logical and important guidelines that any organization has to follow to be successful in outsourcing software to offshore businesses. India has established itself as one of the most competitive destinations for software development services.
Unlike in house development or on site development, the offshore development has certain peculiarities associated with its process. Most of the steps that are involved in onsite development are present in offshore development. Critical steps have been included in the process to ensure successful completion of the project.
Are you confused about what to expect when you need to outsource software development?
There are common steps in the process, which may vary according to the size of the project.
Defining Requirements Specification
The first step towards successful offshore software development is the creation a complete and thorough document, which may be difficult, however it is worth it.
In the interest of the project, the client must ensure delivery of a complete set of documents, which clearly state the following.
The Purpose of the Project:
This is more of a vision-like document, which clearly spells out the business objective behind the project. The document should also explain, to the development team, some basic information about your industry.
This is common even when you develop specific applications meant for a target industry. The knowledge will pave way for an easier and quicker understanding of the project and the underlying logics that may be applied to the case. In most cases, software solutions are not just purely technical solutions, but business solutions as well. Therefore, the functional knowledge is as equally important as the technical knowledge. The Internet can be a useful guide. Information about your business is usually available on the net and therefore, you are able to direct consultants to the right locations in the Internet.
Goals:
Goals direct the efforts to specific deliverables. For example, a business, which launch’s its Internet site may want to provide all of its offerings through the website. However, this particular phase of the project may have specific goals, such as streamlining the sales process using Internet technologies and facilitating order placement by the customers. Such goals help narrow down the thinking of the developers to see the specific solutions in the global context and fit them into the project at the proper stages. In future the same system can be expanded and integrated with the other business processes.
Major Features:
Major features help people further redefine the scope of a project and open lines of communication to enhance understanding between the client and the vendor. For example, a web project for a retail store may have several features such as admin module, inventory module, storefront and backend database. These modules are identified with a name and hence easy for the people to understand each other. It is also advisable to define specific terms with specific explanations in a glossary section so that all terminology is understood completely. The language used should be simple, concise and to the point. However, wherever explanations are required, it is better to explain them with examples and in great detail. Ambiguity can often lead to serious complications as a project moves forward.
Compatibility issues:
Compatibility issues arise when software that is under development becomes part of an existing software or hardware system. It is best to address these issues at the commencement of a project thus taking steps to avoid further complications during implementation.
Human Interface Issues:
Human interface issues, at times, relate to the way the people envision the finished product. This is also subjective and cannot be exactly defined especially when you are developing e-commerce solutions. The web interfaces are what matters to the customers. It is often better to freeze the human interface as quickly as possible so that the developers will be able to comprehend and visualize the system from the beginning of the project. It helps to have complete graphic documents, screen shots, mock pages and interfaces made even at the beginning of the project.
It is well known that revising the user interface late in the project is costly, expensive, adds to the bugs and will delay the delivery.
Maintenance and Support:
Software that is developed by a vendor, especially an overseas vendor, should be covered by round the clock support. This would be part of the contract. You must also make sure that the software company has presence internationally as well as connection to the Internet in the same manner and staffed adequately to handle such contingencies. Make sure the contract explicitly mentions all of these terms.
Documentation and Training:
It is important that you insist on complete documentation of the entire process including logic and coding. Also insist that the software developed be supplied with a good user manual so that users can easily understand it. If you are interested in working with the upgrades of the software, it would be immensely useful.
Terms and Conditions for the project:
Here you will spell out your terms and conditions for the project so that the vendor can adequately prepare its offer, taking in to consideration all terms and conditions. Undefined or unclear terms and conditions can lead to misunderstanding of the project at a later stage leading to development delays and additional costs.
Depending on the completeness of this document, vendor(s) involved in the proposal process may need to make inquiries and revisions to it before it becomes an adequate basis for a bid.
Analysis Proposal
When all of these previous documents are supplied, the vendor will come back and deliver a document. These documents may be a refinement of your prior supply of documents. The refinement would help both side understand the terms, requirements and deliverables. Normally there are some compromises and trade-offs made at this stage so that the final delivery meets with your expectation in all aspects. Also the vendor is clear of the scope and terms.
TheF the project
Cost and time estimates
A basic project plan
A definition of deliverables
Acceptance criteria
Any terms and conditions required
Any assumptions used to make the proposal
The scope of the Project:
The scope explains the exact understanding of the vendor based on your requirement elicitation.
This document would help you assess the vendors understanding of your requirements. In some cases, you will be able to improve upon your requirement or limit the same, based on the vendor’s advice, capabilities and other constraints such as time for launch of the software and your business objectives.
Cost and Time estimates:
When it comes to cost and time estimates, there are three approaches with off shore projects.
In any case, before commencement of the project all parties must estimate the time for completion of the project. However, if the definition of the user requirement or the vendors understanding of the scope of the project is not clear, then there is always room for delay in the implementation of the project. It is important to remember that the software development process is entirely a human effort involving many people no matter where it is done. Communication plays a major role, as it ensures documentations, discussions and clarification sessions. Although these sessions and processes may be long and tiresome, it is better to ensure that all parties are clear of their needs. Otherwise, delays and risks will come into play in the development process.
A Basic Project Plan:
The software development team will work based on a project plan to minimize risk and ensure that the promises made are fulfilled. There are some sophisticated development tools and project management systems available. Each vendor follows his own system of project management which suites them best. In any case they will have a project plan for the project. You can insist on a project plan, which would indicate possible details such as the number of people required for the project and their skill sets, estimated time of arrival to milestones, the sequence of activities to be completed, the critical tasks and the role and responsibilities of the client. A good project plan with specific milestones will help the client make sure that the project is being executed on time.
With out such a plan the uncertainty will only increase and corrective actions will become difficult to implement. A seasoned software project manager can understand and estimate the project complexity and judge the capabilities of the team based on the project plan. Although it is not very easy to predict the development time accurately, it is important to have one for the purpose of the management of the project.
Terms and Conditions as Agreed by the Vendor:
This section of the document will ensure that both the vendor and client agree to the terms and conditions in order to start the work with a clear understanding. The client’s expectation, according to the request for proposal, sometimes may not be fully agreed upon by the vendor, or, there may be exceptions to some of the clauses.
Executed contract
Frequently, the client requests revisions of the proposal. Once those are agreed upon and the proposal is accepted, the contract is drawn up and executed. This document should include:
Pricing is usually on either a fixed-price or time-and-materials basis. Payments on fixed price contracts are expected at project commencement. The vendor meets milestones upon final acceptance by the client.
Payment terms for time-and-materials contracts are variable with weekly to monthly invoicing on agreed terms of credit.
Preliminary Project Plan
The project plan is created by whoever is managing the project. It should include:
Both the client and the vendor should sign off on this document.
Analysis
1. Functional Specification
Through interaction with the client, the vendor creates this document. It should contain:
2. Preliminary Design
The preliminary design should include:
3. Project Plan revised
Update the project plan to reflect the information in the functional specification and changes in available resources and technology.
4. Development Proposal
5. Final versions of analysis proposal
6. Executed contract
Design
Design Specification
Once the vendors devise a set of alternate, top-level designs, the vendors should take the clients through a walk-through. Once this walk-through is complete, the vendor should complete the design process and create a design specification.
This specification should include:
The specification should include all of the functionality stated in the Functional Specification.
Quality Assurance Test Plan
This test plan should include:
It may include more than one Alpha or Beta cycle and other intermediate cycles such as Gamma.
Update project plan to reflect the information in the design specification and acceptance plan.
Communication Protocols and remote monitoring of the projects:
When software development is outsourced to an overseas vendor communication protocols play a vital role in successful completion of the project.
During the early phase of the project, it is better to have a one on one meeting with the key development team members and the project representative from the client side. The representative from the client side must be empowered to decide on the requirement and modification thereof during the negotiations as well as development process.
With Internet, emails, chats, video conferencing, collaborative tools and project management software, it is realistically feasible to monitor the project effectively and successfully.
During such communication sessions, if the discussions are not based on final documents, they tend to lead to misunderstanding between the developers and clients. Explaining all the details with conversations is not easy. The risk is increased especially if you do not have a vendor representative close to you. It is also important that people understand the cultural differences between the working teams. For example, in order to be polite, the vendor sometimes may not come out with accurate delivery schedules and strive to complete complex tasks to serve the client better. However, in the event of failures, the clients will not be able to appreciate the efforts of the vendors, they would rather be disappointed.
It is also important that both sides of the project understand the problems that the different time zones they are working in may cause. In most cases, these different time zones help people continue to work based on the feedback from the previous day’s work. In some cases, people are forced to work late hours and/or come in early to meet each other online and exchange ideas.
Such adjustments in working hours cannot be avoided.
The informality of the email communication ensures that people are well connected. However, even while exchanging emails, it is important to be focused on specifics and arrive at decisions for specific issues. Similarly the chat sessions lead to long conversations and negotiations, which have to be concluded with specific decisions for implementation. It is very essential, that after each chat session, the teams agree on the specific issues on which decisions were taken and confirmed with email documents.
Direct meetings and video conferencing are strongly advocated for GUI related discussions and ideas, which are complex and need to be expressed by textual messages.
The vendor usually supplies QA
Bug fixes and minor feature enhancements.
Development engineers fix bugs reported by the QA and by the client. Minor feature enhancements, as agreed upon by client and vendor are incorporated.
Final code submission
Client and vendor should agree upon criteria for final code submission.
Acceptance
Acceptance testing
The client performs acceptance testing as specified in the QA test plan, possibly with the vendor present.
Operation
Warranty-period technical support
Vendors should offer to fix problems caused by vendor free of charge for a certain period of time.
The warranty period depends on the size of the project; however, 30 days is common.
Maintenance
This is usually a separate contract, detailing any maintenance requirements including:
Project post-mortem
Client and vendor should get together to discuss the project. Topics usually include:
If these steps are followed, the risks involved in software development can be mitigated and success can be achieved.
