Terms

We use simple and convenient rules when working with our Customers. Typical conditions are described below, although all rules can be modified according to Customer's wishes.

Confidentiality

• Company NDA. We ensure very high-level protection of the data received from our Customers while executing their orders. We are ready to sign any Non-Disclosure Agreement both in this particular form and in any other form, you provide.

• Employee NDA. All our employees sign a very strict contract with the Company, preventing disclosure of any information.

Property Rights

Intellectual Property (IP) constitutes results of our work. We use clear and convenient transition rules for the IP, which are covered, in our standard contract. All IP is transferred along with results. That would be either in middle of project execution or at the end depending on the specifics of the project and/or special needs of our Customer.

Communication with a Customer

Communications are foundation for successful software projects. That is why we use all possible means of communication. We help our customers to establish convenient communication channels. In Russia’s office, we hire professionals and managers with fluent English to ensure better communications. Besides, our typical process includes standardized reporting on the state of projects (see below Project lifecycle).

How project is started

At the beginning stage, we identify the scope and requirements for the new project together with the customer. The result of this stage is a vision of the project with clearly defined goals and needs of the customer. That is a foundation for all next stages. That's why the quality of this vision is very important. Therefore at that stage we engage our best project managers and technical experts (usually system architects) having experience in the customer's business area to help our customer and our sales manager perform analysis of goals and needs, gather requirements, and set priorities for the needs. At the end of this step both our customer and we have more precise vision of What Should Be Done.

Next step is project estimation, preliminary planning, and refinement of requirements, needs and their priorities. The result of that stage is a Technical Proposal, which includes description of the requirements and needs, iterative project schedule, preliminary resource plan, risk and quality management plans, project results and deliverables, and price estimation. Such approach ensures the Visibility of the project for the customer and our team. Technical Proposal demonstrates the feasibility of the project and provides the overall picture of how the project will go. What is important the Technical Proposal describes how we are going to perform communications during the project go. The result of this stage shows How That Should Be Done.

Having the needs, requirements, plan and price estimation for the new project we are ready to negotiate and amend, if needed, plans and requirements to adjust that all to customer's expectations and goals. The results of this step are amended Technical Proposal, Contract, and Statement of Work (SOW) for the project.

One notable part of the Contract and Statement of Work is Acceptance Plan. The Acceptance Plan specifies acceptance criteria and especially how the Customer will accept deliverables and results of the project.

Project lifecycle

Project officially starts once we sign the Statement Of Work (SOW). Project phases are described in the project plan. The project plan also describes in general all entire project lifecycle along with project risks, top-level requirements and architecture. The plan defines regular status reports on the project. The exact representation of these reports is agreed with the customer in order to reflect his/her business needs. Usually Project Status Report (PSR) includes the following parts:

1. Achieved results (in terms of deliverables defined in SOW and Plan, or in terms of system features);

2. Work done vs. work planned (in terms of person/hour efforts);

3. Status of Change Requests;

4. Status of Risks;

5. Proposed changes to the initial project plan

If (when) changes to initial requirements appear during the project flow (i.e. Change Requests), they are recorded in a selected Change Management database (this would be either special application like Bugzilla or Rational ClearQuest, or even a custom Excel table for smaller projects). Re-planning of the project for the changes is performed according to SOW and agreed with the customer. All changes of the project plan accrued from Change Requests or Risks are negotiated and agreed with the customer according to the rules defined in SOW (see figure below). The above-mentioned Project Status Report is a way for communicating project changes.

For complex systems, the quality of results usually depends on quality of components. That's why we employ QA procedures on certain points of project flow in order to achieve the balance between the cost and the quality of results to meet your business needs. A means to achieve quality are:

1. Recording all requirements and changes

2. Managing risks

3. Peer reviews for technical deliverables and intermediate results such as Project Architecture, Requirements, Code and Units;

4. Planned testing activities

5. Internal acceptance of work

This ensures the quality of all software deliverables on all levels (requirements, architecture, system units and modules, entire system)

The Project Acceptance Plan (PAP) is a guiding rule for acceptance of every project phase. It is based on project requirements and your business goals and needs. The PAP is signed by both parties and is an inseparable part of SOW. For smaller projects PAP is included right in the text of SOW.

We meet customer's expectations

On the one hand, correctly specified requirements are a basis for project success. On the other hand, day-to-day contact with a customer is also primary key for understanding customer's goals, and project requirements in particular.

Therefore, we refine project's specifications continuously based on communication with our customer. It allows us to meet customer's expectations, and even to exceed them.

Results (consist of what)

All project results are listed in project plan, in other words, they are described and agreed with a customer in advance.

Project acceptance procedure is also defined in advance, with SOW. Accordingly; sequence of delivering these results is also defined in those documents. Among project results first of all we can call project schedule with resources engaged, risk plan, PAP, configuration management plan, testing plan, etc, as well as project reports.

Naturally, main result of software project is executable code, and to accept this code acceptance plan is created. Software Requirements Specification Document (SRS) and, most often, testing plan are the basis for the acceptance plan.

Besides main project executables, often creation of project prototypes is necessary. Usually programming code is supported by documentation. Depending on type of project, it can be Business Vision, Architectural Vision, SRS, deployment instructions, user manual, technical specifications. Of course, executables are accompanied by well-commented source code.

Results check list:

• Binary code (executables)

• Source code

• User Manual (optional)

• Deployment/Installation Instructions

• Build Instructions (optional)

• Technical documentation (optional)

  • Project Plan and Schedule

  • Project Acceptance Plan (PAP)

  • Project Test Plan (PTP)

  • Software Requirements Document (SRS)

  • Software Architecture Document (SAD)

A Customer may ask for any additional documentation.

How payment is done

We usually divide plans for the projects on separate phases/stages with accordance to the selected project lifecycle. Every phase corresponds to a certain milestone with its own results. Project Acceptance Plan includes transfer of these results to the customer and acceptance procedures and criteria for the results. Our typical contract binds payments to such milestones. We prefer to divide projects on near-monthly phases. That’s why it is convenient to think that payments are made on the monthly basis. A contract for a fixed price project usually includes pre-payment terms for every its phase.

Warranty and Product Maintenance

• 60 days cost-free bug fixing. Our standard offer is 60 days cost-free bug fixing (after release to the Customer of his/her product final version), when all bugs found by the Customer are fixed free of charge. Releasing itself is also coordinated with the Customer, and is possible only after Customer performs acceptance procedures agreed in Acceptance Plan and is certain of work completion. In addition, if the Customer finds bugs within 60 days after acceptance, we fix such bugs free.

• Consultations. After expiration of this period, we provide Customer with consultations on the project (concerning source code, architecture, configurations, etc.).

• Product support. If necessary, we offer to Customer support services for created product, like modification of the product and creation of successive versions, product setup, customization, and administration at the Customer's servers, and end user support.

• Support team. The same specialists that participated in the project development group carry out bug fixing and product support; therefore, such tasks are fulfilled with a maximum performance and quality.