Software factories

To help serve our clients, we have state-of-the art software factories in Noida, Calcutta and Chennai. These factories have the best networks, high-speed Internet connectivity, latest software and hardware infrastructure. Each of these factories also support dedicated centres of excellence, on-going high technology projects and dedicated offshore development centres in addition to the various projects executed by these factories. Some of our facilities are also capable of providing video-conferencing.

In addition to software factories, we also set up and manage offshore development centres, and offsite centres depending on the client's requirements.

Offshore advantage

HCL has an extensive offshore software development infrastructure in India. This state-of-the-art infrastructure, which comprises software development centres located strategically across the country, is designed to take advantage of the high productivity and scalability as well as the relatively lower cost of software development in India. These software factories are all linked by high-speed satellite and terrestrial communication facilities with HCL offices and clients across the world.

Offshore Model is supported by the Software Factory in India allowing the Client to take advantage of the cost and productivity benefits offered in India.

Benefits

The Offshore methodology offers a distinct competitive advantage and has the following benefits:

• Rapidly build skills that are otherwise difficult to obtain from the market
• Effectively handle variations in workload (by scaling or descaling resources)
• Use multi-platform skilled resources (for marrying technologies)
• Provide benefits of HCL's established and proven IT practices · Lower unit costs with bigger capacities
• Reduce risk of project overruns, occurring due to attrition & shortage of skilled persons
• Client can free (and motivate) in-house resources for new opportunities and work in business critical areas

Types of Projects that can be executed.

Projects of on-going nature: These projects are of Maintenance, Production Support nature. These projects have fixed resource requirements and are usually charged on a Time and Material (T&M) basis.

Projects of one-off nature: These projects are of Re-engineering, Migration, Development nature. These projects have widely varying resource requirements over the various stages of the SDLC. These projects are usually charged on Fixed Cost Basis (with provision for Change Requests)

Why we succeed

HCL has refined and fine-tuned this methodology over the years resulting in long term mutual benefits. Some of the critical success factors for the success of this methodology are:

Quality of people and their commitment to excellence

Total Quality Management Commitment

Commitment to Intellectual Property Protection

Capability to build and sustain teams with desired skills.

ODC Project Management Methodology

At ODC, for all Projects and development activity right from the initial stages of requirement gathering to final delivery and implementation, guidelines are laid down in our Quality Management System (QMS).

ODC project management methodology broadly covers:

Planning

The basis for start-up of the project is a signed contract between the customer and HCL. Apart from the two primary contracting parties, any other third parties present are identified and their roles specified in the contract. Prior consensus between the Client and ODC as to the nature, content and time of the deliverables is also agreed upon.

At the start up phase of the project, the project manager prepares following plans:

Software Project Management Plan (SPMP): This will be a base document, which establishes the charter of authority and direction for the project, and identifies the roles and responsibilities during execution. As part of the SPMP, potential risks are identified and the mitigation and control procedures are outlined. SPMP includes disaster and recovery plans. Based on project needs, a separate Risk Management Plan (RMP) is also prepared.

Software Quality Assurance Plan (SQAP): This plan will detail the quality objectives for the project, and will include the standards, practices and conventions, review and audit plans, problem reporting and corrective action methods and methods for code and media control. This plan includes Goals setting in the projects.

Software Configuration Management Plan (SCMP): This plan will address the configuration identification, change control, configuration status reporting, audits and reviews. The plan will identify the software configuration management activities to be done, which is responsible, when they are to happen and what resources are required. This plan identifies each data (information, software, data, coade, work product) received from customer and/ or produced during the development process as a configurable item and provides the mechanism for storage, retirieval and dissemination of this information.

All these documents and other relevant documents prepared during the course of the project are filed with the document controller as per the guidelines of QMS.

Execution

The plans developed by the Project Manager in the earlier phase are carried out accordingly. During this phase, the first activity consists of gathering all the requisite information required for the development. This would consist of studies at Client location. All data and information collected (including test plans and data provided by Client) are duly recorded and maintained as Project Data and managed. Any data or information provided by the Client whether expressly declared confidential or implicit is treated by ODC as strictly confidential and appropriate security and IPR guidelines as laid down by QMS are followed.

The environment for the project is set up consisting of allocation of requisite hardware, software, network infrastructure, work spaces etc. Parallelly based on the data and information collected, the requirements of the client are converted to designs. The same are reviewed with the Client and accepted designs are filed as per standards. Subsequent to the acceptance, the development activity takes place. This takes place as per the Coding standards of ODC.

All programs, data and information generated in the course of the project, including the data and information collected from the Client are tracked for updates using configuration management (version control) processes and tools. This ensures elimination of redundancy as well as facilitates storage and retrieval of appropriate version and content at the required time.

Reviews and Risk Management

Once the development is completed, Unit testing is performed. Subsequent to the Unit tests, System and Integration tests are performed. All test plans, results and data are documented and filed.

Throughout the entire duration of the project periodic reviews are conducted and project status and progress is reviewed. Client participated reviews are also conducted. All reviews are mapped with original Plans drawn by the project manager and any variances with respect to costs, times and schedules are identified and managed with appropriate action plans.

At all reviews, the risks identified are evaluated for their severity and prioritized and tracked till closure. The experiences of other projects in controlling the risk are also taken as inputs for mitigation. The details of the same are also discussed with the Client if required and documented in the RMP.

Subsequent to the testing, the developed software / code is handed over to the client for Acceptance and implementation. Procedures for the handover of the code and their acceptance are laid down by QMS.

Subsequent to the acceptance, as part of the project closure all Client supplied products, data and information are returned back to the Client. The document Controller ensures that the updated and appropriate versions of all the relevant documents generated for the Client are handed over to the Client.

Risk Management

Risk Management Plan

The following Section describes HCL's Risk management Process

Purpose
The practice of risk management involves two primary steps, risk assessment and risk control. Risk Management helps avoiding
· Disaster
· Rework
· Overkill

Risk Management Process

Risk Management Procedure

Entry Criteria
· Risk management guidelines are available with OSSP (Organization Standard Software Processes) Database.
· Project requirements are known.

Input
· Risk management document.
· HCL project requirements.
· OSSP guidelines.

Task
· Risk identification.
· Risk Analysis.
· Risk Classifying and Prioritizing.
· Risk Planning.
· Risk tracking.
· Risk Mitigation and control.
· Communication and documentation.

Verification and Validation
· Review of Software project Plan (SPMP).
· Risk mitigation plan, Risk table.
· Risk tracking.
· Senior Management review and QAG Review.

Output
· Updated Software Project management plan.
· Project Risk management Plan, Risk table.
· Unified Risk management plan

Exit Criteria
· Updating SPMP with potential risks.
· Review of Risk management plan.
· Risks are tracked during project execution.

Metrics
· Risk classification and priority.
· Risk impact/ probability table, Individual project Risk list.
· Risk attribute metrics.
· Project monthly metrics report.
· Risk status report.

HCL Continuous Risk Management

HCL prepares a Unified Risk Management Plan across all the projects. This plan contains potential risk factors affecting the projects, planning strategies, risk evaluation and risk mitigation planning. The objectives of Unified Risk Management Plan are to identify, address, and eliminate software risk items before they become threats to success or major sources of rework in projects. Using the risk management techniques, project teams can lighten the harm or loss in a software project.

Continuous Risk Management can be applied to any development process, hardware, software, systems, etc. It provides a disciplined environment for proactive decision making to assess, determine risk factors in the projects and to implement strategies to avoid or to reduce the risk effect.
The process for risk management requires identifying and managing risks routinely throughout all phases of the project's life. The HCL continuous risk management functions are,

· Identifying Risks
· Analyzing Risks
· Risk Mitigation Planning
· Tracking
· Risk Control
· Communication & Documentation.

The above activities occur continuously, concurrently and iteratively in all HCL projects. Risks are usually tracked simultaneously while new risks are identified and analyzed and the mitigation plan for risks are continuously updated and reviewed.

Risk Identification

This activity is to search for and locate risk factors in all the projects . Items or events that may have a significant negative impact on the project are identified in earlier stage of the projects. (Such as changes in customer requirements, new development technologies, or a change in target systems).

The purpose of identification is to consider risks before they become problems and to incorporate this information into the project management process. Anyone in a project team can identify risks to the project. Each individual has particular knowledge about various parts of a project. Uncertainties and issues about the project are transformed into distinct risks that can be described and measured.
Identification is done by the following two ways,

· Input from HCL project teams and lessons learned from past.
· Risk identification checklists / Questionnaire.

Based on the input a risk statement is prepared. Risk statements in standard format must contain two parts,

· The condition - Focuses on what is currently causing concern; it must be something that is true or widely perceived to be true. This component provides information that is useful when determining how to mitigate a risk.
· The consequence - Focuses on the intermediate and long-term impact of the risk. Understanding the depth and breadth of the impact is useful in determining how much time, resources, and effort need to be allocated to the mitigation effort.

The condition-consequence format provides a complete picture of the risk, which is critical during mitigation planning. Team members' individual contributions and teamwork improves the chances of identifying new risks.

Risk Analysis

Risk analysis is to transform risk data into decision-making information. The impact of a risk may affect many aspects of software projects. Once risks are identified, decision analysis, cost risk analysis, schedule analysis, reliability analysis, and similar techniques and models are used to analyze the risks. Each risk is then evaluated to assess the potential impact of the risk on a project. The objectives of risk analysis are.
· Evaluate impact, probability, and timeframe - The loss or negative effect on the project due to risk, the likelihood the risk occur in the project, and the period when the action must taken in order to mitigate the risk.
· Classify the risks - To understand the nature of the risks facing the project and to group any related risks so as to build more cost-effective mitigation plans.
· Prioritize risks - To sort through a large number of risks and determine which are most important and to separate out which risks should be dealt with first (the vital few risks) when allocating resources.

Three main steps are used to analyze the software risk in HCL projects,
· Find out the probability of the occurrence of a particular risk in a project.
· Estimate the impact to the project of the particular risk.
· Analysis to determine the overall risk to the project.

Risk Classification and Priority

There are several ways to classify, group and prioritize the risks. When two or more risks are equivalent or the subject is the same the risks are combined into one risk factor. Prioritizing involves partitioning the risks or groups of risks based on it effect on the project. Conditions and priorities may change during the execution of the project and so Risk analysis is being a continual process in all HCL projects.

The following table demonstrates sample values that might be used to evaluate a risk's attributes:

Using estimates on risk probabilities and impacts, the overall risk to a project is measured. In figuring out the overall risk, how this risk may impact other risks on the project is considered. Matrices are also used to determine the overall risk for each of effort, performance, and schedule. A sample matrix is given below:

Impact/Probability Matrix

Plan for Risks

Planning is the function of deciding what, if anything, should be done about a risk or set of related risks. This activity translates risk information into decisions and mitigating actions and use to implement the actions. This is being done based on the current knowledge of project risks.

After analyzing software risks, a plan is formulated to address each risk. Planning stages cover the following issues

· The importance of risk.
· Information needed to track the status of the risk.
· Project persons responsible for the Risk Management activity.
· Resources needed to perform the activity.

A detailed plan of how the risk will be prevented and/or mitigated is created for all the projects. This may contain the following two topics

· Action planning - To mitigate the risk via an immediate response. The potential impacts of the risks are mitigated by dealing with the problem early in the projects.
· Contingency planning - Used to monitor the risk and invoke a predetermined response.

There are four options to consider when planning for risks

· Explore: Plan to research all risks in detail.
· Accept: Decide to "accept" the risk(s) and document the rationale behind the decision.
· Monitor: Monitor risk conditions for any indications of change in probability or impact (tracking of metrics are established and documented).
· Mitigate: Allocate resources and assign actions in order to reduce the probability or potential impact of risks.

Risk Tracking

Tracking of risk is to monitor the risk indicators and the mitigation actions. This process involves activities by which risk status data are acquired, compiled, and reported. Once the mitigation plan has been developed for a risk or risk set, both the mitigation plan and the risk attributes are tracked. Tracking the mitigation plan will indicate whether the plan is being executed correctly and/or on schedule. Following are some of the techniques used for Risk tracking in HCL projects,

· Tracking risks is done as a part of overall project monitoring.
· Collaborative tools are used to track and monitor risks continuously. This provides timely risk visibility and resolution.
· Risks are tracked through software Project Management Plan, Risk mitigation plan, and project Manager's monthly reviews and senior management reviews. Highlighting risk-item status in monthly project reviews.
· A risk history table is maintained and updated with every senior management review.
· Individual Checklists are used to track the risks at project level.
· Risk metric sheets are also used to track the risks and to provide effective decision-making.
· Monthly review of risks in all projects done by HCL Quality Assurance Group also tracks the over all identified risk.

The entire project is informed about the risks and their impact. Based on the type of risks resources are allocated to track the risks. Milestone tracking, tracking of top risks, continual risk reassessment, and periodical reviews are some of the other techniques that are followed in each HCL project to monitor the risks.

Control risks

The purpose of risk control is to make informed, timely, and effective decisions regarding risks and their mitigation plans. Controlling risks involves analyzing the status reports, deciding how to proceed, and then implementing those decisions. The goal is to obtain a clear understanding of the current status of each risk and mitigation plan relative to the project and then to make decisions. This process tracking status information and decides exactly what to do based on the data available,
· Whether there is a significant change in risk attributes.
· The effectiveness of mitigation plans within the context of project needs and constraints.

Controlling risks includes the following activities:

· Close the risk - A closed risk is one that no longer exists or is no longer cost effective to track as a risk. This occurs when: the probability falls below a defined threshold, impact lies below a defined threshold, or the risk has become a problem and is tracked.
· Re-planning - A new or modified plan is prepared when the threshold value has been exceeded, analysis of the indicators shows that the action plan is not working, or an unexpected adverse trend is discovered by the project group.
· Invoke a contingency plan - A contingency plan is invoked when a trigger has been exceeded or some other related action needs to be taken.
· Continue tracking and executing the current plan - No additional action is taken when analysis of the tracking data indicates that all is going as expected or project personnel decide to continue tracking the risk or mitigation plan as before.

Communication & Documentation

The purpose of Communicate and Document is for all project team members to understand the project's risks and mitigation alternatives as well as risk data and to make effective choices within the constraints of the project.

· The project management plan, risk mitigation plan and the risk metrics are documented online and are accessible to entire project team. All team members are given permissions to review the plans.
· In risk identification, risk statements are communicated to the project team.
· Project personnel communicate information about impact, probability, and timeframe attributes to others and Risk classification involves grouping risk information communicated by individuals.
· Action plans are developed and communicated to project teams.
· The decisions made during tracking and controlling are communicated and recorded to project teams.
· HCL encouraging free-flowing information at and between all project levels.

Project Assets

All programs, data and information generated in the course of the project, including the data and information collected from the Client are handed over to Library and known as project assets. This includes lesson learnt, project metrics and plan documents. All master data set used for testing are also included in project assets.

Offsite centres

Offsite Centres Offsite Centres are similar to our offshore facilities, but are however set up in the same city/location of the client. These allows the client to save valuable infrastructure resources, at the same time giving the client the reach and proximity required in some mission critical projects, allowing the client to interact/monitor in a more closer manner across the various stages of the project.

ODC Methodology

Project Scoping

Project Scoping includes a short study by us to scope the project and subsequent Project definition within the scope. This phase comprises the activities that define the scope of the project, doing high level project estimates and risk analysis. Boundaries or major functions are defined Activities in this phase are governed by fixed milestones and timeframes. This phase would ensure the boundaries of the proposed solution are marked.
This activity is carried out onsite at client work area.

Analysis/ Requirements Management

This phase covers activities directed towards the development of software requirements. The user requirements are arrived based on a study of the existing systems in place and discussions with users. These are analysed to arrive at a proposed solution for the system in terms of the software. Requirement Management spans across the complete life cycle of product development.
This activity is normally carried out onsite at client work area.

Design

The design process maps the "What to do" of the requirements specification to the "how to do it" of the design specification. Design starts with defining the design objectives for the proposed system. The components constituting the software system are identified. The system architecture is defined and the designs of the database and/or the file systems to be adopted are completed.Techniques such as data modelling, process modelling, object modelling and prototyping may be used for tasks such as identifying alternative designs and defining user interfaces.
This activity is carried out offshore at one of our software development centres.

Construction and Unit Testing

Construction transforms the detailed design representation of a software product into program source codes. This phase produces the source code, database, files and the documentation constituting the physical manifestation of the design. In addition, the code and the database/files are integrated.
This activity is carried out offshore at one of our software development centres. Incase of version releases we also conduct Regression testing, which covers the Re-running of test cases:

Integration & System Testing

System Testing focuses on a complete integrated system to evaluate compliance with specified requirements. Extensive testing is done to ensure a quality product. Integration Testing focuses on combining units to evaluate the interaction among them.
This activity is carried out offshore at one of our software development centres.

Acceptance Testing

Based on the pre-defined acceptance criteria, Client conducts the acceptance test during this phase. The Project team provides support, if required. As part of preparation for acceptance testing installation testing is also carried out. This test is to determine how well and how easily a product installs onto a variety of platform configurations:

• Operating Systems
• Browsers
• Modems
• Printers
• Application combinations etc.
  
  This activity is normally carried out onsite at client work area.

Implementation

This is the last stage of the project and is carried out at the Client Work Area

Maintenance & Support

This is an on-going activity and can take place either at the client area or at our Software Development Centers depending on the nature of the agreement. In case it is done at our centers, updates/releases/patches are sent to the client at agreed intervals for implementation.

::          ::          ::