Onsite Software Development: Customer Processes & IT Infrastructure

In my previous article on the peculiarities and risks of onsite software development, I considered the difficulties that both a customer and a contractor may face in the process of communicating and formulating business requirements for a project. Now I would like to talk about the conditions in which onsite engineers work: the customer’s software development processes they follow and the customer’s IT infrastructure and equipment they use. What risks can be associated with them, and how can these risks be mitigated?

Customer Processes

When cooperating onsite, engineers usually have to follow the customer’s processes, and one of the most frequent problems that can cause difficulties in onsite projects is the workday schedule. For example, a customer’s workday may be strictly regulated and start much earlier than that in a software development company. This is connected with a certain risk: engineers who find themselves in unusual conditions may lose their productivity and motivation.

Auriga usually considers this risk when selecting engineers for a project. Here are some practical recommendations to mitigate this risk:

  • In addition to the professional and technical skills of the engineers, it is also important to consider their personal characteristics and preferences regarding the working process.
  • The workday schedule and conditions in the customer’s office should be discussed during the interview with an engineer. If an employee meets the project needs in terms of technical skills but, according to the project manager (PM), he/she will not be able to share knowledge onsite efficiently, then it is better to consider other specialists.
  • If the selected engineers ask about possible changes in the workday schedule, it is necessary to negotiate it with the client at the start of the project. It is often possible to work out a compromise that suits both sides.

A more significant problem may be related to the customer’s software development processes. The PM from the software R&D service company may find the client’s software development methodology inefficient. He/she may have his/her own idea of project management; however, when a team comes onsite, there is often no opportunity for changes. Service providers have to adapt and follow the processes adopted by the client. For example, the customer wants to cut costs and, therefore, categorically refuses to include such important phases as unit and functional testing in the development process. Thus, the customer risks getting software that does not meet the expected quality in the stated time frame.

Normally, this risk is on the client’s side, as is the choice of software development processes and methodologies. Nevertheless, given our experience, Auriga is ready to help the client and offer several recommendations:

  • We always inform the customer of this risk at the start of the project.
  • We can also suggest options for improving the software development process. However, the customer’s consent and assistance are required.
  • To perform routine work, such as unit and functional testing, we can use engineers with lower qualifications (juniors, for example) for a fixed time.

Save the tip: Think ahead about whether you are ready to compromise and make changes in the onsite engineers’ workday schedule. Consult about software development processes and their effectiveness with the provider’s PM.

Why is it important? Joint efforts to improve software development processes help the provider’s team to adapt faster and directly affect the speed and quality of the project. Moreover, it allows you to apply good practices in the future, both in internal initiatives and in projects carried out together with contractors.

IT Infrastructure and Equipment

Onsite engineers use the customer’s IT infrastructure and equipment. The IT infrastructure includes the main software development equipment (engineering workstations, build servers, version control servers, test servers, servers with databases, etc.), internal network (intranet), security policies (accesses, role models), and the third-party software used in the development process. Internet access may be limited or unavailable.

On the one hand, this gives some benefits to the software development company: they do not have to involve their own technical staff, there is no need to purchase equipment and licenses, Internet traffic is not consumed, etc. Accordingly, this keeps overhead expenses down. On the other hand, this may cause issues.

Customers’ security policies often limit the rights of third-party engineers (namely, the engineers of the outsourcing vendor team). Contractors may not have the necessary access to the customer’s resources, or obtaining this access may require lengthy coordination due to the client’s procedures. Here, a serious risk of unanticipated downtime among engineers arises. We consider this risk to be mitigated jointly by the client and the software R&D company. Auriga offers its customers the following practices:

  • At the project start, we document the customer’s resources need for the project and formulate the access requirements to clarify the access procedures and terms. Based on this information, Auriga optimizes the project schedule to minimize possible downtime (and the customer’s costs).
  • In the course of work, the PM constantly monitors the status of access and, in the case of deadline violation, escalates problems to the customer’s higher management.
  • When accessing is impossible, the PM and the customer representative develop an alternative project plan. For instance, part of the project’s tasks may be delegated to the in-house engineers.

Another infrastructure-related problem may be the restriction of engineers’ access to internal resources of the outsourcing company that are not directly connected with the project. We often notice, for example, that the lack of access to our corporate email, version control system, corporate training portals, and bug and task trackers reduces engineers’ interest in the project, makes them feel uninvolved in corporate life, and limits their career development. Sometimes engineers ask to join another project just to have the opportunity to work in their own office. To mitigate this risk, Auriga does the following:

  • We ask the client if our engineers can have the Wi-Fi router, to which the Yota-modem is connected, to access the Internet and the corporate resources from the client’s office. Customers allow it, as a rule.
  • If the client does not mind, the Auriga Training Center organizes courses (foreign language classes and others) for our engineers in the customer’s office.
  • Our engineers should have the opportunity to participate in Auriga’s corporate events, and we negotiate it with the client.

Save the tip: Make a list of resources required for the project in advance. Check your security policies and determine the timeframe within which new engineers can gain access. Do not deprive the onsite engineers of access to their corporate resources that may be unavailable due to remote work. Familiarize onsite engineers with the security policies adopted in your company.

Why is it important? Employees who feel their relevance and involvement in corporate life are more active and motivated. The less downtime they have, the lower the risk of project delay.

In the next and final part of this series, I will discuss such onsite support features as remote project management and increased responsibility of contractors. Please stay tuned to the Auriga blog!